tRPC-Agent-Go：Agent 工程化的重点不是 prompt，而是运行边界

Agent 框架真正的分水岭，不是能不能调用模型，而是能不能进入企业工程体系。tRPC-Agent-Go 值得关注，正因为它把 Agent 看成一个需要生命周期、协议边界、评测、可观测性和部署纪律的后端服务。

如果说许多 AI 框架解决的是“怎么快速做出一个能回答的助手”，tRPC-Agent-Go 更像是在回答另一个问题：当这个助手要长期在线、要被前端消费、要和其他 Agent 协作、要留下 trace、要可取消、要可评测时，Go 服务团队该怎么组织代码。

Agent 工程化的核心，不是 prompt

企业里很多 Agent 项目失败，不是因为模型完全不会做，而是运行边界不清楚：工具权限过大，Session 不可追踪，前端只能看到最终答案，出错时不知道是模型、工具、网络还是业务数据的问题。更严重的是，没有评测闭环，质量退化只能靠用户投诉发现。

tRPC-Agent-Go 的设计把这些问题拆成模块：Runner 管执行，Session 管多轮状态，Tool 管能力边界，Graph 管确定性流程，AG-UI 管前端事件，A2A 管 Agent 互通，Evaluation 管质量，Telemetry 管观测。这种结构比单纯堆 prompt 更接近可维护软件。

它给 Go 团队的启发

• Agent 不应该是一个附着在业务系统上的神秘协程，而应该有清楚的 request、session、run、event 和 trace。
• 工具调用不是“模型自由探索”，而是受限的服务接口；每个工具都需要超时、过滤、错误处理和审计。
• 能画成流程图的任务，就应该逐步从 prompt 迁移到 Graph 工作流。
• 前端要看到过程，而不是只等一个最终字符串；否则取消、审批和人机协作都很难做。
• 质量必须用 eval set 和线上 trace 来度量，不能只靠开发者主观感觉。

为什么协议边界重要

tRPC-Agent-Go 同时接 MCP、AG-UI 和 A2A，这很容易被误解成“协议越多越先进”。真正重要的是边界清晰：MCP 是工具边界，AG-UI 是人与界面的交互边界，A2A 是 Agent 间协作边界。边界不清楚时，系统会出现两类问题：要么所有内部过程都暴露出去，要么所有能力都藏在一个黑箱里。

它的 A2A 文档明确讨论了 trace、工具调用、reasoning 等执行细节是否应该跨 Agent 传递。这比简单“支持 A2A”更有价值，因为企业协作场景下，内部执行链路往往包含敏感数据、权限信息和不应外泄的工具参数。

最推荐的采用方式

不要一上来就把所有模块打开。先从一个最小 Runner 开始，接一个只读工具和内存 Session；确认事件流、取消、错误处理都能进入你的服务框架。第二步再接真实 MCP 工具和持久化 Session。第三步把稳定流程改成 Graph。第四步再加 Evaluation 和 Telemetry。最后才考虑 A2A 对外暴露。

这种渐进方式能避免 Agent 项目常见的失控：先做了很多酷的多 Agent 协作，最后却没有一个任务能稳定上线。

结论

tRPC-Agent-Go 的意义，是把 Agent 项目从产品演示拉回软件工程。它不保证模型一定聪明，但它提供了一套更适合 Go 后端团队管理复杂度的骨架。对企业 AI 来说，这类“无聊的工程层”往往比炫目的模型能力更关键。