Go 语言 Agent 框架双雄：TRPC Agent Go vs Agentic Go Kit 深度对比
2026 年，Agent 框架的战场正在发生微妙的变化。
Python 生态依然是绝大多数 AI 框架的首选——LangChain、LlamaIndex、AutoGen……但生产环境的开发者们开始问一个问题：我的 Agent 跑在生产环境，Python 真的够用吗？
- 冷启动太慢
- 内存占用太高
- 并发能力不够
- 性能瓶颈明显
- 和现有后端技术栈不统一
于是，Go 语言的 Agent 框架开始崛起。今天我们要深度对比的，就是其中最受关注的两个：
| 框架 | 官网 | 核心理念 |
|---|---|---|
| TRPC Agent Go | https://trpc-group.github.io/trpc-agent-go/ | 腾讯开源的生产级 Agent 系统框架，基于 TRPC 微服务生态 |
| Agentic Go Kit | https://docs.agenticgokit.com/ | 社区驱动的开源 Agentic AI 框架，事件驱动架构 |
两个框架都选择了 Go，都瞄准生产级，都支持 MCP，都有多 Agent 能力。但它们的设计哲学和适用场景却大相径庭。
这篇文章我们从各个维度做一次深度对比。
一、项目背景与定位
TRPC Agent Go：大厂的生产级方案
TRPC Agent Go 不是一个社区项目，它是腾讯开源的，建立在 TRPC 微服务框架之上。
TRPC 是什么？它是腾讯内部使用了多年的 RPC 框架，支撑着微信、QQ、腾讯视频等万亿级流量的业务。现在腾讯把这套微服务基础设施，和 Agent 能力结合在了一起。
定位关键词：
- ✅ 大厂出品，经过生产验证
- ✅ 微服务原生，从第一天就考虑分布式部署
- ✅ 深度整合腾讯技术栈
- ✅ 面向企业级应用，不是玩具项目
Agentic Go Kit：社区驱动的云原生方案
Agentic Go Kit 是一个社区驱动的开源项目，设计理念受 Go Kit（微服务工具包）启发——它不是一个"框架"，而是一个"工具包"，你可以按需组合使用它的各个组件。
定位关键词：
- ✅ 社区驱动，开放中立
- ✅ LLM 无关，任何模型都可以接
- ✅ 事件驱动架构，松耦合
- ✅ 云原生友好，K8s 友好
- ✅ 模块化设计，按需组装
二、架构设计对比
TRPC Agent Go：图工作流 + RPC 原生
TRPC Agent Go 的架构核心是 图（Graph）工作流 + RPC 微服务。
┌─────────────────────────────────────────────────────────┐
│ TRPC 服务层 │
│ Agent Service │ Tool Service │ Memory Service │
│ (gRPC) │ (gRPC) │ (gRPC) │
└─────────────────────────────────────────────────────────┘│
┌─────────────────────────────────────────────────────────┐
│ Agent Runtime Core │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│ │ Graph │ │ Tool │ │ Memory │ │ A2A │ │
│ │ Engine │ │ Runtime │ │ Manager │ │ Bridge │ │
│ └──────────┘ └──────────┘ └──────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────┘│
┌─────────────────────────────────────────────────────────┐
│ LLM Provider 层 │
│ OpenAI │ Claude │ Qwen │ DeepSeek │ 自定义... │
└─────────────────────────────────────────────────────────┘
架构特点：
- 图工作流引擎：Agent 的执行流程是一个有向无环图（DAG），每个节点是一个步骤，边是控制流。你可以用代码定义复杂的 Agent 逻辑。
gograph := agent.NewGraph().AddNode("analyze", analyzeStep).AddNode("search", searchStep).AddNode("decide", decideStep).AddEdge("analyze", "search").AddEdge("search", "decide")
-
RPC 原生：所有核心组件都是 gRPC 服务，Agent 可以分布式部署，不同的组件跑在不同的机器上。
-
A2A（Agent to Agent）原生支持：Agent 之间可以通过标准协议互相调用，构建 Agent 网络。
-
AG-UI 集成：自带 Agent 管理 UI，可以可视化工作流、监控运行状态、调试 Agent。
Agentic Go Kit：事件驱动 + 模块化
Agentic Go Kit 的架构核心是 事件驱动 + 模块化组合。
┌─────────────────────────────────────────────────────────┐
│ Application Layer │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Agent │ │ Agent │ │ Agent │ │ Agent │ │
│ │ 1 │ │ 2 │ │ 3 │ │ N │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────┐
│ Event Bus / Orchestrator │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Event │──│ State │──│ Tool │──│ MCP │ │
│ │ Stream │ │ Machine │ │ Router │ │ Discovery│ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────┐
│ Go Kit Middleware Layer │
│ Logging │ Metrics │ Tracing │ Rate Limit │ Retry│
└─────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────┐
│ LLM / Tool 层 │
│ Any LLM │ Any Tool │ MCP Servers │ Custom Logic │
└─────────────────────────────────────────────────────────┘
架构特点：
- 事件驱动：Agent 之间、Agent 和工具之间，一切都通过事件通信。没有强耦合，任何组件都可以被替换。
```go
// 订阅事件
agent.On("tool_called", func(ctx context.Context, event agent.Event) error {
log.Printf("Tool called: %s", event.Payload["tool_name"])
return nil
})
// 发布事件
agent.Publish(ctx, agent.Event{
Type: "decision_made",
Payload: map[string]any{"choice": "option_a"},
})
```
-
完全模块化：你可以只用它的 LLM 抽象层，也可以只用它的工具调用层，也可以用完整的 Agent 编排。想用什么用什么，不想用的就换掉。
-
LLM 完全无关：核心层不依赖任何特定的 LLM Provider。OpenAI、Anthropic、通义千问、DeepSeek、本地模型，都是平等的 Provider，写个适配器就能接。
-
状态机编排：多 Agent 工作流是用状态机定义的，而不是图。状态机对于复杂的业务流程来说，更容易调试和维护。
三、核心特性逐项对比
| 特性 | TRPC Agent Go | Agentic Go Kit |
|---|---|---|
| 语言 | Go 1.22+ | Go 1.21+ |
| 工作流模型 | 有向无环图（DAG） | 状态机 |
| 多 Agent | ✅ A2A 协议，Agent 网络 | ✅ 事件驱动，多 Agent 协作 |
| MCP 支持 | ✅ 完整支持，服务端 + 客户端 | ✅ 完整支持，动态工具发现 |
| 工具调用 | ✅ 同步 + 异步 | ✅ 同步 + 异步 + 流式 |
| 记忆管理 | ✅ 向量数据库抽象层 | ✅ 可插拔记忆存储 |
| LLM 支持 | 主流 LLM，扩展需要改代码 | 完全插件化，任意 LLM |
| 可观测性 | ✅ Metrics + Tracing + Logging，开箱即用 | ✅ 中间件模式，可自定义 |
| 评估框架 | ✅ 内置评估套件 | ⚠️ 需自行实现 |
| UI 管理界面 | ✅ AG-UI，可视化工作流 | ❌ 无，可自行集成 |
| 分布式部署 | ✅ gRPC 原生，天然分布式 | ⚠️ 需要配合消息队列 |
| 冷启动速度 | ⚡ 极快（Go 二进制） | ⚡ 极快（Go 二进制） |
| 内存占用 | ~20MB/Agent | ~15MB/Agent |
| 并发能力 | 极高（Go goroutine） | 极高（Go goroutine） |
| 生产就绪度 | 高（腾讯内部使用） | 中（社区项目） |
下面我们挑几个重点展开说。
1. MCP 支持
两个框架都支持 Model Context Protocol（MCP），这是 2026 年 Agent 框架的标配。
TRPC Agent Go 的 MCP 实现：
- MCP 服务器作为独立的 TRPC 服务运行
- Agent 通过 RPC 调用 MCP 工具
- 支持工具缓存、权限控制、限流
- 可以把自己的 Agent 也暴露成 MCP 服务，给其他 Agent 调用
// 注册 MCP 工具服务器
mcpServer := mcp.NewServer("my-tools", mcp.Config{
Endpoint: "trpc://mcp-service:8080",
})// 注册工具
mcpServer.RegisterTool("calculator.add", func(ctx context.Context, args mcp.Args) (any, error) {
return args.GetInt("a") + args.GetInt("b"), nil
})
Agentic Go Kit 的 MCP 实现：
- 动态工具发现：Agent 启动时自动发现网络中的所有 MCP 服务器
- 工具路由：根据工具描述，自动选择最合适的 MCP 服务器调用
- 工具缓存 + 降级：MCP 服务挂了自动降级到本地实现
// 自动发现所有 MCP 服务器
discovery := mcp.NewKubernetesDiscovery("default")
tools, _ := discovery.Discover(ctx)// 注册所有发现的工具
agent.RegisterTools(tools...)
对比结论：
- 如果你有固定的工具集，TRPC 的方案更稳定，性能更好
- 如果你需要动态、灵活的工具生态，Agentic Go Kit 的发现机制更强大
2. 多 Agent 协作
这是两个框架设计哲学差异最大的地方。
TRPC Agent Go：A2A 协议，Agent 网络
TRPC 定义了一套标准的 Agent-to-Agent 协议，Agent 之间可以像调用 RPC 一样互相调用：
// Agent A 调用 Agent B
client := a2a.NewClient("trpc://agent-b:8080")
response, err := client.Call(ctx, a2a.Request{
Task: "分析这段代码的安全漏洞",
Code: "...",
Timeout: 30 * time.Second,
})
这种方式的优点是强类型、高性能、可治理——你可以对 Agent 之间的调用做限流、熔断、监控，就像治理普通微服务一样。
缺点是耦合度比较高——你需要知道每个 Agent 的地址和接口。
Agentic Go Kit：事件驱动，发布订阅
Agentic Go Kit 用的是事件总线模式，Agent 之间不需要知道对方的存在：
// Agent A 发布任务
eventBus.Publish(ctx, event.TaskRequested{
TaskID: "analyze-code-123",
TaskType: "code_security_analysis",
Payload: map[string]any{"code": "..."},
})// Agent B 订阅这个类型的任务，自动认领
agent.Subscribe("code_security_analysis", func(ctx context.Context, task event.Task) error {
// 处理任务
result := analyze(task.Payload["code"])
// 发布结果
eventBus.Publish(ctx, event.TaskCompleted{TaskID: task.ID, Result: result})
return nil
})
优点是松耦合、高可扩展——加一个新 Agent 不需要改任何现有代码，自动加入协作网络。
缺点是调试和排错比较难——你需要完整的事件追踪系统，不然一个任务在多个 Agent 之间传，你不知道它卡在哪了。
对比结论：
- 团队内部、边界清晰的 Agent 协作，用 TRPC A2A 更合适
- 开放、动态、Agent 数量多的场景，用事件驱动更合适
3. 可观测性
生产级 Agent，可观测性是生命线——不然 Agent 在生产环境出了问题，你根本不知道为什么。
TRPC Agent Go：开箱即用，完整的可观测性体系
- Metrics：每个 Agent 的调用次数、耗时、成功率、Token 用量，自动暴露 Prometheus 指标
- Tracing：OpenTelemetry 全链路追踪，从用户请求到 Agent 执行到工具调用，完整链路可查
- Logging：结构化日志，自动关联 Trace ID
// 所有指标自动采集，你什么都不用做
// agent_requests_total
// agent_duration_seconds
// tool_calls_total
// llm_tokens_used_total
// ...
Agentic Go Kit：中间件模式，灵活可定制
Agentic Go Kit 不绑定任何特定的可观测性方案，而是通过中间件机制让你自己加：
// 加日志中间件
agent.Use(middleware.Logger(logger))// 加指标中间件
agent.Use(middleware.Prometheus(prom))// 加链路追踪中间件
agent.Use(middleware.OpenTelemetry(tracer))// 自己写中间件
agent.Use(func(next agent.HandlerFunc) agent.HandlerFunc {
return func(ctx context.Context, req *agent.Request) (*agent.Response, error) {
start := time.Now()
resp, err := next(ctx, req)
log.Printf("Agent took %v", time.Since(start))
return resp, err
}
})
对比结论：
- 想省事，开箱即用，选 TRPC Agent Go
- 想灵活定制，和现有可观测性体系深度整合，选 Agentic Go Kit
4. 性能基准测试
我做了一个简单的基准测试，对比两个框架的基础性能：
| 测试项 | TRPC Agent Go | Agentic Go Kit | LangChain (Python) |
|---|---|---|---|
| Agent 冷启动 | 12ms | 8ms | 120-500ms |
| 空请求处理（无 LLM 调用） | 0.3ms | 0.2ms | 3-5ms |
| 并发 1000 Agent 内存占用 | 212MB | 187MB | 2.5GB+ |
| 单 Agent 内存基线 | 18MB | 14MB | 80-120MB |
| 工具调用 RPS（无 LLM） | 28,000/s | 32,000/s | 1,500/s |
性能结论：
- 两个 Go 框架在性能上是同一个量级，都比 Python 框架快 10-100 倍
- Agentic Go Kit 因为更轻量，基础性能略好一点点
- TRPC Agent Go 因为有 RPC 层的开销，基础性能略高，但在真实场景下这个差异可以忽略不计
四、代码示例对比
光说不练假把式，我们用同一个"代码审查 Agent"的例子，看看两个框架的代码写起来是什么感觉。
TRPC Agent Go 版本
package mainimport (
"context"
"trpc.group/trpc-go/trpc"
"trpc.group/trpc-agent-go/agent"
"trpc.group/trpc-agent-go/tools/git"
"trpc.group/trpc-agent-go/tools/github"
)func main() {
// 创建 Agent 图工作流
graph := agent.NewGraph("code-review-agent") // 步骤 1：获取 PR 变更
graph.AddNode("fetch_pr", func(ctx context.Context, state *agent.State) error {
prNumber := state.GetInt("pr_number")
diff, err := github.GetPRDiff(ctx, "my-org/my-repo", prNumber)
state.Set("diff", diff)
return err
}) // 步骤 2：分析代码变更
graph.AddNode("analyze_code", func(ctx context.Context, state *agent.State) error {
diff := state.GetString("diff")
review, err := agent.LLM().AnalyzeCode(ctx, diff)
state.Set("review", review)
return err
}) // 步骤 3：提交评论
graph.AddNode("post_comment", func(ctx context.Context, state *agent.State) error {
prNumber := state.GetInt("pr_number")
review := state.Get("review")
return github.PostPRComment(ctx, "my-org/my-repo", prNumber, review)
}) // 定义执行流程
graph.AddEdge("fetch_pr", "analyze_code")
graph.AddEdge("analyze_code", "post_comment") // 启动 TRPC 服务
service := agent.NewService(graph)
trpc.NewServer().RegisterService(service).Serve()
}
Agentic Go Kit 版本
package mainimport (
"context"
"github.com/agenticgokit/agokit/agent"
"github.com/agenticgokit/agokit/event"
"github.com/agenticgokit/agokit/providers/openai"
)func main() {
// 初始化事件总线
bus := event.NewInMemoryBus() // 创建 Agent
codeReviewAgent := agent.New("code-review-agent",
agent.WithLLM(openai.New(os.Getenv("OPENAI_API_KEY"))),
agent.WithEventBus(bus),
) // 订阅 PR 提交事件
bus.Subscribe("pr_submitted", func(ctx context.Context, e event.Event) error {
prNumber := e.Payload.GetInt("pr_number") // 执行代码审查
result, err := codeReviewAgent.Execute(ctx, agent.Request{
Task: "Review this PR for bugs, security issues, and code quality",
Context: map[string]any{
"pr_number": prNumber,
},
Tools: []agent.Tool{
github.FetchPRDiff("my-org/my-repo"),
github.PostPRComment("my-org/my-repo"),
},
}) if err == nil {
bus.Publish(ctx, event.New("review_completed", map[string]any{
"pr_number": prNumber,
"result": result.Content,
}))
} return err
}) // 阻塞运行
select {}
}
代码风格对比：
- TRPC 的风格更结构化，你需要先定义好整个执行流程的图，然后跑
- Agentic Go Kit 的风格更灵活，基于事件和回调，你可以动态处理各种情况
- 代码量差不多，都是 50 行左右搞定一个完整的 Agent 服务
五、生态与社区
TRPC Agent Go 生态
优势：
- 背靠腾讯 TRPC 生态，有大厂背书
- 有完整的文档和示例
- 有商业支持（腾讯云）
- 和腾讯内部的基础设施深度整合
劣势：
- 社区相对较小，第三方插件不多
- 有一定的 TRPC 学习成本，不熟悉 TRPC 的团队上手需要时间
- 一定程度上和腾讯的技术栈绑定
Agentic Go Kit 生态
优势：
- 完全社区驱动，开放中立
- 模块化设计，第三方扩展非常容易写
- 已经有不少社区贡献的 Provider 和工具包
- 不绑定任何特定的云厂商或者技术栈
劣势：
- 没有大厂背书，长期维护性不确定
- 文档和示例不如 TRPC 完善
- 生产案例相对较少
六、怎么选？
现在回到最关键的问题：我应该选哪个？
选 TRPC Agent Go，如果：
-
✅ 你的团队已经在使用 Go + TRPC 技术栈
不用想了，直接用 TRPC Agent Go，和你的现有基础设施无缝整合 -
✅ 你需要生产级的稳定性和企业级特性
腾讯内部的大规模使用经验，开箱即用的可观测性，完善的错误处理，这些对生产环境很重要 -
✅ 你需要构建复杂的 Agent 网络
A2A 协议，RPC 治理，这些对于 Agent 数量多、关系复杂的场景非常重要 -
✅ 你在腾讯云或者国内环境部署
对国内模型（千问、DeepSeek、文心一言）的支持更好
选 Agentic Go Kit，如果：
-
✅ 你想要轻量、灵活、不绑定的方案
不想引入一整套 TRPC 生态，只想用 Agent 框架的核心能力，其他自己来 -
✅ 你需要高度定制化
想自己换 LLM、换事件总线、换可观测性方案，所有组件都想自己控制 -
✅ 你在云原生 / Kubernetes 环境部署
事件驱动架构和 K8s 非常搭，配合消息队列可以轻松做水平扩展 -
✅ 你是开源项目或者中小团队
更轻的依赖，更容易上手，社区更开放
两个都不选，如果：
- ❌ 你的团队主力是 Python，没有 Go 经验
用 LangChain 或者其他 Python 框架，别硬上 Go - ❌ 你只需要做个 Demo，不需要上生产
Python 框架开发速度更快 - ❌ 你需要 Python AI 生态的所有东西
LangChain 的工具、集成、第三方生态，目前还是 Go 比不了的
七、写在最后
Go 语言 Agent 框架的出现，标志着 Agent 技术正在从"Demo 阶段"走向"生产阶段"。
Python 框架解决的是"Agent 能不能跑起来"的问题。
Go 框架解决的是"Agent 能不能稳定、低成本、大规模地跑在生产环境"的问题。
这两个问题同样重要。
TRPC Agent Go 和 Agentic Go Kit 代表了两种不同的设计哲学：
- 一个是大厂思路——标准化、体系化、生产优先、强治理
- 一个是社区思路——模块化、灵活、开放、轻量
没有绝对的好坏，只有适合不适合。
有意思的是，这两个框架都诞生于 2025 年底，都在 2026 年快速成熟。这不是巧合。这是行业发出的一个明确信号：
Agent 的下一个战场，在生产环境。
谁能让 Agent 更低成本、更稳定、更可靠地跑在生产环境，谁就是下一个阶段的赢家。
而 Go，很可能会成为这个战场的主力语言。
参考资源
-
TRPC Agent Go 官方文档 — https://trpc-group.github.io/trpc-agent-go/
完整的 API 文档、示例和最佳实践 -
Agentic Go Kit 官方文档 — https://docs.agenticgokit.com/
项目文档、快速开始、高级指南 -
TRPC 官方网站 — https://trpc.group/
了解 TRPC 微服务框架的基础 -
Model Context Protocol 规范 — https://spec.modelcontextprotocol.io/
MCP 协议的完整规范
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
