tRPC-Agent-Go Ecosystem Development Guide
This document analyzes the modules in the tRPC-Agent-Go framework that need ecosystem development, explains the interfaces that need to be implemented, and provides contribution guidance.
Note: All community-built components are contributed directly to the corresponding directory under the GitHub open source repository, such as model/somemodel
, tool/sometool
, agent/someagent
, etc.
When contributing, create a reasonably named subfolder under the corresponding contribution module directory, then implement the corresponding module interface, and provide rich test cases and example samples.
Ecosystem Development Module Analysis
1. Agent Ecosystem
Goal: Encapsulate and adapt third-party Agent frameworks
Interface Definition: agent.Agent
Existing Implementation Reference: LLMAgent
Implementation Notes:
- The
Run
method must return an event channel, supporting streaming responses - The
Tools
method returns the list of tools available to the Agent - The
Info
method provides basic information about the Agent SubAgents
andFindSubAgent
support Agent composition patterns- Reference LLMAgent implementation to understand event handling and error handling mechanisms
Implementation Example:
Open Source Components That Can Be Integrated:
- LangChain adapter
- LangGraph adapter
Contribution Method:
- Create components under the corresponding directory (create a subdirectory with the corresponding component name)
- Contribute directly to
https://github.com/trpc-group/trpc-agent-go/agent/
2. Model Ecosystem
Goal: Support more model providers
Interface Definition: model.Model
Existing Implementation Reference: OpenAI Model
Implementation Notes:
- The
GenerateContent
method must support streaming responses, returning an event channel - Distinguish between system-level errors (return error) and API-level errors (Response.Error)
- Implement the
Info
method to provide basic model information - Reference OpenAI implementation to understand request building and response handling
- Support context cancellation and timeout control
Implementation Example:
Open Source Components That Can Be Integrated:
- Google Gemini model support
- Anthropic Claude model support
- Ollama local model support
Contribution Method:
- Create components under the corresponding directory (create a subdirectory with the corresponding component name)
- Contribute directly to
https://github.com/trpc-group/trpc-agent-go/model/
3. Tool Ecosystem
Goal: Integrate more third-party tools
Interface Definition:
- tool.Tool - Single tool interface
- tool.ToolSet - Tool collection interface
Existing Implementation Reference: DuckDuckGo Tool
Implementation Notes:
Single Tool Implementation:
- The
Declaration
method must return complete tool metadata - The
Call
method receives JSON format parameters and returns results of any type - Use JSON Schema to define input and output formats
- Reference DuckDuckGo implementation to understand tool calling and error handling
- Support context cancellation and timeout control
Tool Collection Implementation:
- The
Tools
method returns available tool lists based on context - The
Close
method releases resources held by the tool collection - Support dynamic tool loading and configuration
- Implement tool lifecycle management
Implementation Example:
Single Tool Implementation:
Tool Collection Implementation:
Open Source Components That Can Be Integrated:
- Search engine tools (Google, Bing)
- Weather query tools
- Calculator tools
- File operation tools
- API tool collections (REST API toolkit)
- Database operation tool collections
- File processing tool collections
Contribution Method:
- Create components under the corresponding directory (create a subdirectory with the corresponding component name)
- Contribute directly to
https://github.com/trpc-group/trpc-agent-go/tool/
4. Knowledge Base Ecosystem
Goal: Integrate mature RAG components
Interface Definition: knowledge.Knowledge
Existing Implementation Reference:
Implementation Notes:
- The
Search
method supports context and history records - Returns relevant documents and relevance scores
- Supports search parameters and result limits
- Reference InMemory implementation to understand search logic and result processing
- Supports vectorized search and semantic matching
Implementation Example:
Open Source Components That Can Be Integrated:
- Weaviate vector database
- Pinecone vector database
- Qdrant vector database
Contribution Method:
- Create components under the corresponding directory (create a subdirectory with the corresponding component name)
- Contribute directly to
https://github.com/trpc-group/trpc-agent-go/knowledge/
5. Session Ecosystem
Goal: Support multiple session storage backends, manage user session state and events
Interface Definition: session.Service
Existing Implementation Reference:
Implementation Notes:
- Implement complete Session lifecycle management (create, get, delete, list)
- Support state storage and event recording
- Implement connection pooling and error handling
- Support transactions and consistency
- Can reuse storage module clients
- Reference InMemory and Redis implementations to understand Session management logic
Implementation Example:
Open Source Components That Can Be Integrated:
- PostgreSQL session storage
- MongoDB session storage
- MySQL session storage
- Cassandra session storage
Contribution Method:
- Create components under the corresponding directory (create a subdirectory with the corresponding component name)
- Contribute directly to
https://github.com/trpc-group/trpc-agent-go/session/
6. Memory Ecosystem
Goal: Support multiple memory storage backends, manage user long-term memory and personalized information
Interface Definition: memory.Service
Existing Implementation Reference: InMemory Memory
Implementation Notes:
- Implement complete Memory lifecycle management (add, update, delete, search, read)
- Support memory topic classification and search
- Provide memory tool integration (memory_add, memory_search, etc.)
- Implement connection pooling and error handling
- Can reuse storage module clients
- Support memory limits and cleanup mechanisms
- Reference InMemory implementation to understand memory management logic
Implementation Example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 |
|
For quick implementation, you can directly integrate with existing Memory platforms/services (such as mem0). Recommendations:
- Provide implementation in
memory/mem0/
, following thememory.Service
interface. - Reuse existing
memory/tool
tools (memory_add
,memory_search
,memory_load
, etc.), expose throughTools()
. - Map topics and search according to target service capabilities, maintain lightweight local indexes when necessary to enhance query experience.
- Optional: Reuse
storage
module client management for unified authentication, connection and reuse.
Example skeleton (simplified):
Implementation points:
- Configure authentication and rate limiting according to target service guidelines.
- Return values strictly align with
memory.Entry
andmemory.Memory
, use UTC for time fields. - Tool declarations should accurately describe input and output for frontend and model understanding.
- Add README, examples and tests to ensure compatibility with
runner
,server/debug
combinations.
Open Source Components That Can Be Integrated:
- PostgreSQL memory storage
- MongoDB memory storage
- Elasticsearch memory storage
- Redis memory storage
Contribution Method:
- Create components under the corresponding directory (create a subdirectory with the corresponding component name)
- Contribute directly to
https://github.com/trpc-group/trpc-agent-go/memory/
7. Observability Ecosystem
Goal: Provide unified observability capabilities based on OpenTelemetry standards, covering Logging, Metrics, Tracing, facilitating ecosystem expansion and replacement.
Core Packages and Interfaces:
- Logging:
trpc-agent-go/log
(log.Logger
interface andlog.Default
global logger). - Metrics:
trpc-agent-go/telemetry/metric
(globalmetric.Meter
andmetric.Start
initialization). - Tracing:
trpc-agent-go/telemetry/trace
(globaltrace.Tracer
andtrace.Start
initialization). - tRPC Integration:
trpc/log.go
,trpc/telemetry/galileo/
.
Logging
- Interface Definition:
log.Logger
definesDebug/Info/Warn/Error/Fatal
and their*f
variant methods, facilitating replacement with any implementation. - Default Implementation:
log.Default
useszap
'sSugaredLogger
by default. - Dynamic Level:
log.SetLevel(level)
supportsdebug/info/warn/error/fatal
. - tRPC Integration:
trpc/log.go
injectstlog.DefaultLogger
aslog.Default
and refreshes with tRPC plugin lifecycle.
Example (using global logger):
Example (in tRPC through configuration to disk/remote):
Contribution directions:
- Adapt any Logger (such as zerolog, logrus): implement
log.Logger
interface, and setlog.Default = yourLogger
during initialization. - tRPC pluginization: reference
trpc/log.go
'splugin.RegisterSetupHook
usage.
Metrics
- Package:
telemetry/metric
. - Global Object:
metric.Meter
, defaultnoop
, points to OTel Meter after callingmetric.Start
. - Initialization:
metric.Start(ctx, metric.WithEndpoint("host:4317"))
. - OTLP Export: uses
otlpmetricgrpc
, supports environment variable override: OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
.OTEL_EXPORTER_OTLP_ENDPOINT
(fallback).- Resource Identification: automatically fills
service.namespace/name/version
.
Example (start metrics and report Counter):
Contribution directions:
- Exporter ecosystem: encapsulate more OTel Exporter convenient startup methods (such as Prometheus pull/OTLP http).
- Metrics library: agree on common metric naming and label conventions, provide helper methods.
Tracing
- Package:
telemetry/trace
. - Global Object:
trace.Tracer
, defaultnoop
, points to OTel Tracer after callingtrace.Start
. - Initialization:
trace.Start(ctx, trace.WithEndpoint("host:4317"))
. - OTLP Export: uses
otlptracegrpc
, supports environment variable override: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
.OTEL_EXPORTER_OTLP_ENDPOINT
(fallback).- Propagator: enables
TraceContext
by default.
Example (start tracing and create Span):
Contribution directions:
- Exporter ecosystem: encapsulate Zipkin, Jaeger (direct push) and other startup methods.
- Span conventions: agree on common Span names/attribute keys, provide helpers (can be placed in
telemetry/
).
8. API Service Ecosystem
Goal: Provide unified, extensible API service encapsulation for frontend Chat interfaces (such as ADK Web, AG-UI, Agent UI), covering session management, conversation sending, streaming transmission, tool calls, observability and authentication capabilities, and align with various UI protocols for plug-and-play.
Existing Implementation Reference:
- ADK Web Compatible HTTP Service:
server/debug
. - Endpoints (implemented):
GET /list-apps
: List availableAgent
applications.GET /apps/{appName}/users/{userId}/sessions
: List user sessions.POST /apps/{appName}/users/{userId}/sessions
: Create session.GET /apps/{appName}/users/{userId}/sessions/{sessionId}
: Query session.POST /run
: Non-streaming conversation inference, returns aggregated event list.POST /run_sse
: SSE streaming inference, returns token-level event stream.GET /debug/trace/{event_id}
: Query Trace attributes by event.GET /debug/trace/session/{session_id}
: Query Trace list by Session.
- Features: Built-in CORS, pluggable session storage (default In-Memory), integrated with
runner.Runner
, observability instrumentation (exports key Spans). - A2A Server:
server/a2a
. - Service encapsulation for A2A protocol, built-in
AuthProvider
and task orchestration, suitable for platform-to-Agent integration scenarios.
Alignment with Frontend Protocols:
- ADK Web: Already aligned with request/response and event Schema, see
server/debug/internal/schema
. - AG-UI: Reference
https://github.com/ag-ui-protocol/ag-ui
. - Required capabilities:
- Session list/create/query.
- Text conversation and SSE streaming increment; support tool calls and function response fragment display.
- State/usage metadata, error expression alignment.
- Rich media support (InlineData) for files/images and server-side storage integration.
- Authentication (API Key, JWT, Cookie session) and CORS.
- Recommend providing implementation in
server/agui/
, reuse common model and event mapping tools, complete protocol layer adaptation in Handler. - Agent UI (agno): Reference
https://docs.agno.com/agent-ui/introduction
. - Focus: SSE/WebSocket streaming, Tool call streaming UI feedback, session/artifact persistence.
Key Design Points:
- Schema Mapping:
- Input: Map UI's
Content
/Part
to internalmodel.Message
. - Output events: Map internal
event.Event
to UI-expected envelope/parts, structure tool calls and tool responses to avoid duplicate text display. - Streaming Transmission:
- SSE already implemented in
server/debug
, prioritize reuse; WebSocket can be ecosystem extension. - Non-streaming endpoints need to aggregate final messages and tool responses according to UI expectations.
- Session Storage:
- Inject specific implementation through
runner.WithSessionService
, reusesession
module. - Observability:
- Reuse
telemetry/trace
andtelemetry/metric
.server/debug
already demonstrates how to export key Spans and event attributes for UI-side debugging and positioning. - Authentication and Security:
- Support API Key/JWT/custom Header; add rate limiting and cross-domain control for sensitive endpoints.
- Open Specifications:
- Recommend attaching
openapi.json
/README.md
to eachserver/*
submodule for frontend/integration party integration.
Minimal Example (reuse ADK Web compatible service):
AG-UI Adaptation Suggestion (skeleton):
Ecosystem Directions and Contribution Standards:
- Target UI/Protocols:
- AG-UI: Provide HTTP + SSE adaptation in
server/agui/
, with examples andopenapi.json
. - Agent UI (agno): Provide HTTP + SSE / WebSocket adaptation in
server/agentui/
. - WebSocket/Bidi Streaming: Align with ADK
run_live
, provide real-time audio/video channels (depends on model-side support). - Implementation Requirements:
- Clear event Schema, complete mapping, ensure tool calls/responses have good experience in UI.
- Support pluggable session storage, default In-Memory, recommend supporting Redis/MySQL etc.
- Built-in CORS, authentication middleware (API Key/JWT), expose health check endpoints.
- Observability: integrate
telemetry
, provide minimal Trace and Metric examples. - Documentation: README, OpenAPI, end-to-end examples (include simple frontend or curl scripts).
Link references:
server/debug
(ADK Web compatible) and itsopenapi.json
.server/a2a
(A2A protocol encapsulation).
9. Planner Ecosystem
Goal: Provide diverse planners to adapt to different models and workflows, including built-in thinking capability adaptation and explicit planning (ReAct/Reflection, etc.).
Interface Definition: planner.Planner
.
BuildPlanningInstruction(ctx, invocation, llmRequest) string
: Build or inject system prompts and request configurations for planning.ProcessPlanningResponse(ctx, invocation, response) *model.Response
: Post-process model responses for planning (optional).
Existing Implementation Reference:
planner/builtin
: Adapt O series, Claude, Gemini and other models with reasoning parameters, through configuringReasoningEffort
,ThinkingEnabled
,ThinkingTokens
.planner/react
: Provide explicit planning instructions and response post-processing, agree on/*PLANNING*/
,/*ACTION*/
,/*REASONING*/
,/*FINAL_ANSWER*/
and other tags.
Ecosystem Directions:
- Reflection Planner: Self-reflective correction and multi-round re-planning.
- LangGraph style Planner: Align with Pregel parallel and checkpoint mechanisms.
- Tool-first Planner: Selection and constraints for Tool-First processes.
Integration Example (skeleton):
Combination and Usage: Inject Planner when creating agent/llmagent
, or select different Planner strategies at runner
layer as needed, combine with Tool
and Session
management for end-to-end implementation.
Contribution Suggestions:
- Provide implementation and README, test cases, examples in
planner/<name>/
. - Combine with
docs/overall-introduction.md
's Observability andserver/debug
endpoints to provide end-to-end examples for frontend UI demonstration. - Follow goimports and error message style, add periods at end of comments, code line breaks around 80 columns.
Component Relationship Description
Relationship between Storage, Session, and Memory
These three components have different responsibilities and relationships in the architecture:
1. Storage (Storage Layer)
- Responsibility: Provide unified storage client management, provide infrastructure support for Session and Memory
- Function: Register, manage and obtain clients for various storage backends (Redis, PostgreSQL, MongoDB, etc.)
- Characteristics: As an infrastructure component, can be shared and used by Session and Memory components
2. Session (Session Layer)
- Responsibility: Manage user session state and events
- Function: Create, get, delete sessions, manage session state, record session events
- Dependency: Can reuse Storage module clients
- Data Characteristics: Temporary data, can be cleaned up after session ends
3. Memory (Memory Layer)
- Responsibility: Manage user long-term memory and personalized information
- Function: Add, search, update, delete user memories, provide memory tools
- Dependency: Can reuse Storage module clients
- Data Characteristics: Persistent data, maintained across sessions
Relationship Diagram:
Usage Example:
Contribution Guidance
Contribution Guidance
Suitable Components:
- Various third-party service and tool integrations
- Open source component adapters
- Standard protocol support
- Framework functionality extensions
Contribution Process:
- Fork
https://github.com/trpc-group/trpc-agent-go
- Create components under the corresponding module root directory (such as
model/somemodel
,tool/sometool
,agent/someagent
) - Implement corresponding interfaces
- Write tests and documentation
- Submit Pull Request
Directory Structure Example:
Summary
Ecosystem development is an important direction for tRPC-Agent-Go development. By implementing standard interfaces, various third-party services and tools can be easily integrated to expand the framework's capabilities.
Key Contribution Points:
- Reference existing implementations to understand interface usage
- Choose appropriate contribution paths based on component types
- Follow unified interface specifications and code standards
- Provide complete test cases and documentation
Determining Contribution Location:
- All components are contributed directly to the corresponding module directory on GitHub
Storage, Session, Memory Component Characteristics:
- Storage: Provides unified client management, can be shared by Session and Memory
- Session: Manages temporary session data, can reuse Storage clients
- Memory: Manages persistent memory data, can reuse Storage clients
- The three components are decoupled through interfaces, supporting independent implementation and combined usage