A2A 实战:用 Go 搭一个支付诊断 MVP
A2A 不是单纯的聊天协议,它更像一套“任务协议”:客户端先通过 Agent Card 发现服务能力,再把用户问题作为 Task 发送给远端 Agent,最后根据 Task 状态、History 和 Artifact 把完整结果取回来。
这篇文章基于你给出的 Go 代码,整理成一个支付失败诊断 MVP。这个 Demo 的目标很明确:
- 客户端能自动解析 Agent Card
- 服务端能暴露 JSON-RPC 接口和 Agent Card
- 任务执行过程中能持续推送状态
- 结果不只返回一句话,而是带结构化 Artifact
一、MVP 框架结构
可以把这套代码拆成四层理解:
| 层 | 职责 | 关键对象 |
|---|---|---|
| 客户端 | 发现 Agent、发送消息、接收流式事件、再次拉取 Task | a2aclient.Client |
| 服务端 | 暴露 Agent Card 和 JSON-RPC /invoke | a2asrv.NewJSONRPCHandler |
| 业务执行层 | 把“诊断支付失败”拆成状态更新和 Artifact 输出 | PaymentDiagnosisExecutor |
| 领域模型层 | 生成诊断报告和结构化数据 | DiagnosisReport |
一个完整请求的路径大概是这样:
二、A2A 在这个 MVP 里做了什么
这份 Demo 里最关键的不是“问答”,而是“任务”。
AgentCard用来告诉客户端:我是谁、我支持什么协议、输出什么格式SendMessage/SendStreamingMessage用来发起任务Task用来保存执行上下文、历史消息、状态和附件Artifact用来返回结构化结果,适合放 markdown 和 JSONGetTask用来在流式完成后再取回完整任务
也就是说,A2A 把“远端智能能力”从一次性回答,变成了可追踪、可回放、可扩展的业务任务。
三、服务端源码:Agent Card 和 JSON-RPC
服务端的入口很短,核心就是两个动作:挂载 Agent Card,挂载 /invoke。
| |
这里有三个点最重要:
SupportedInterfaces把 JSON-RPC 地址写进 Agent CardCapabilities.Streaming = true表示这个 Agent 支持流式事件Skills描述这个 Agent 会做什么,客户端不需要预先硬编码能力
四、业务执行层:把一个问题变成 Task 流程
真正的业务逻辑在 incident 包里。它不是“直接返回诊断结论”,而是一步步把执行过程变成 A2A 事件。
执行流程如下:
- 第一次进来先创建
SubmittedTask - 把任务状态改成
Working - 分阶段写入进度消息
- 生成
Artifact - 最后改成
Completed
核心 Execute 逻辑可以这样看:
| |
这段代码体现了 A2A 的核心价值:不是“立刻吐一个答案”,而是让任务状态可见、过程可追踪、结果可落盘。
五、诊断报告:Markdown + JSON 双输出
业务模型层把诊断结果组织成两种视图:人类可读的 markdown 和机器可读的 JSON。
生成 Artifact 时,两个 part 会一起挂到任务上:
| |
这个设计很实用:
- markdown 给人看
- JSON 给后续系统接
LastChunk = true表示这个 Artifact 已经写完
六、客户端源码:发现能力、发送消息、回收任务
客户端做三件事:解析 Agent Card、发消息、再取完整 Task。
然后按 stream 参数决定走流式还是非流式:
流式版本会实时打印事件:
| |
最后再拉一次完整任务:
这一步很关键,因为流式事件适合看进度,GetTask 适合拿完整上下文、History 和 Artifacts。
七、示例业务:为什么 order-10086 支付失败
这里的示例诊断逻辑非常明确:
| |
这说明一个 MVP 不一定要连真实系统,但必须把业务边界说清楚。A2A 负责承载任务流转,业务函数负责给出稳定、可解释的结论。
八、一次请求的完整流程
如果用户问:
为什么
order-10086这笔订单支付失败?
整个链路会是:
- 客户端解析 Agent Card
- 客户端发送
SendStreamingMessage - 服务端创建
SubmittedTask - 服务端持续发
Working状态 - 服务端生成
Artifact - 服务端发
Completed - 客户端通过
GetTask拉回完整结果
这套流程的价值在于,前端、网关、外部系统都能按 Task ID 继续追踪,而不是只拿到一次性文本。
九、总结
这份 A2A MVP 的重点不是“做了一个问答接口”,而是把一个远端 Agent 做成了可发现、可流转、可追踪的任务系统。
如果你要把它继续往下做,最值得补的三块是:
- 把
DiagnoseQuestion换成真实订单、支付、风控查询 - 把
Artifact接到对象存储或知识库 - 把
trace日志接到统一观测平台
A2A 的落点很清楚:让 Agent 不只是会回答,而是能真正进入业务流程。