TRPC-Agent-Go on Zampo Blog

God Prompt → MCP → Agent Skills：AI Agent 工程的三次架构演进

Sun, 28 Jun 2026 00:00:00 +0000

引子

前几天看到一个视频，标题很猛：“Anthropic just made AI agents 10X better with new standard”——讲的是 agentskills.io。评论区一片叫好，但很少有人问一个更根本的问题：为什么我们需要一个新标准？

Anthropic 发过的标准不少了。MCP 是其中一个，去年底发布的 agentskills.io 是另一个。但这两个标准解决的根本不是同一类问题——MCP 解决的是连接问题，Skills 解决的是行为问题。而且，这中间还有一整个被大多数人忽略的时代：God Prompt 时代。

如果你只用 1 个 Agent，写个 2000 字的 system prompt 完全够用。demo 能跑，生产也能跑，顶多偶尔出点小毛病。但当你开始维护 5 个、10 个 Agent 时，God Prompt 的维护成本会指数级上升——这不是模型能力问题，是工程架构问题。

这篇文章不讲 agentskills.io 的规范细节（感兴趣自己去看官网），而是用我这两年实际使用和构建 Agent 系统的体感，讲三个阶段各自对应的架构思维，以及你现在到底该用什么。

第一块：God Prompt 时代——Monolith

为什么大家都这么写

2024 年初我刚接触 Agent 开发时，第一个 reflex 就是往 system prompt 里堆东西。这不是我懒，是整个生态都在这么做。LangChain 的 AgentExecutor、早期的 Claude function calling demo、各种开源 Agent 模板——没有一个不是在示范"把所有逻辑写进 prompt"。

理由很朴素：简单、直接、见效快。

你不需要写框架，不需要设计接口，不需要考虑复用。三个工具、两个工作流、五条边界规则——一个 markdown 文件全搞定。改行为就是改 prompt，不用重新编译、不用部署、不用走 CI。对于原型验证阶段来说，这几乎是完美的方案。

tRPC-Agent-Go 深度实践：生产级 Agent 的工程落地之道

Fri, 26 Jun 2026 14:00:00 +0800

从 Demo 到生产

跑通 tRPC-Agent-Go 的 Demo 只需 5 分钟，但上线生产，真正的工程问题才开始浮现：

Agent 跑了 5 分钟、调了十几个工具，网络抖了一下——整个流程要重来。审批类场景下，Agent 分析完需要人点头，但很多框架把 Agent 设计成全自动黑盒，压根没有中断点。团队有 30 个 Agent，每个挂不同的 prompt 和脚本，靠什么管理？其他团队的 Agent 服务（也许是 Python 的 ADK）怎么调？外部的 MCP 工具怎么接？

tRPC-Agent-Go 的三个核心深度特性正好回答这些问题：GraphAgent 检查点（状态持久化与恢复）、Skills 系统（可复用工作流）、A2A + MCP 协议集成（Agent 与外界通信）。

GraphAgent 检查点与 Human-in-the-Loop

GraphAgent 是 tRPC-Agent-Go 最大的差异化能力。但没有检查点的图工作流是「玩具」——跑一半断了就是真断了。

检查点支持两种持久化模式：谱系持久化（保存节点执行轨迹，适合审计合规）和原子持久化（保存完整状态快照，适合长耗时的数据处理流水线）。启用方式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


sg := graph.NewStateGraph(graph.MessagesStateSchema())
sg.AddNode("analyze", analyzeNode)
sg.AddNode("approve", approveNode)
sg.AddNode("execute", executeNode)
sg.AddEdge("analyze", "approve")
sg.AddConditionalEdges("approve", approvalRouter, map[string]string{
 "approved": "execute",
 "rejected": "__end__",
})

cp := checkpointer.NewInMemoryCheckpointer()
ga := graphagent.New("audit-workflow",
 graphagent.WithStateGraph(sg),
 graphagent.WithCheckpointer(cp),
)

每个节点执行后框架自动持久化。恢复执行时传入检查点 ID：

tRPC-Agent-Go 快速上手：Go 生态终于有了自己的 Agent 框架

Fri, 26 Jun 2026 10:00:00 +0800

引子：Go 生态的 Agent 空白

如果你是一个 Go 后端开发者，过去两年一定被各种 AI Agent 框架刷过屏。LangChain、CrewAI、AutoGen、LangGraph…… 清一色 Python。而你手上的 Go 项目要做 Agent 能力，选项屈指可数：要么嵌一个 Python 子进程（运维噩梦），要么自己手搓胶水代码（重复造轮子），要么指望社区那几个半成品框架。

这个局面在 2025 年中开始改变。腾讯 tRPC 团队开源了 tRPC-Agent-Go，到今天刚好 13 个月，115 个 Release，1.4k Stars，已经在腾讯元宝、腾讯视频、腾讯新闻等业务线跑过了生产流量。

这篇文章的目标很简单：用 10 分钟让你知道 tRPC-Agent-Go 是什么、能不能用、怎么上手。第二篇再深入工程落地。

tRPC-Agent-Go 是什么

一句话：tRPC-Agent-Go 是腾讯 tRPC 团队出品的 Go 语言生产级 Agent 框架，对标 Python 生态的 LangChain / LangGraph / CrewAI。

它的定位不是"Go 版的 LangChain"，而是自顶向下重新设计：以 Agent 接口为核心执行单元，以图工作流为高级编排手段，以事件流为通信载体。覆盖了单 Agent 对话、多 Agent 协作、图工作流、MCP/A2A/AG-UI 协议、RAG、可观测性、评测等全栈能力。

关键背景数据：

腾讯 tRPC 是覆盖近 200w+ 节点、5w+ 服务的内部 RPC 框架，tRPC-Agent-Go 是其 AI 方向的延伸
已生产验证于腾讯元宝、腾讯视频、腾讯新闻、IMA、QQ 音乐等业务
要求 Go 1.21+，Apache-2.0 协议
不强制依赖 tRPC 框架，可以独立使用

核心概念速览（点到为止）

tRPC-Agent-Go 的核心抽象只有五个 Agent 类型 + 一个 Runner + Tool + Memory，一看就懂。