A2A 协议的工作流程是怎样的？
- 标签：大模型、AI、A2A
🏛 业务架构师
A2A 的典型工作流程可以串成一个采购协同的例子：
1. 发现：Agent A 需要物流报价，从目录服务或已知地址获取 Agent B 的 Agent Card，确认对方支持"询价"能力及所需认证。 2. 建立会话：A 按 Card 声明的鉴权方式（如 OAuth2）完成认证，发送任务请求。 3. 任务执行：B 接单后进入 running 状态；若任务长，A 不阻塞等待，通过 SSE/Webhook 接收进度通知；中间需要补充信息时，B 把任务切到 input-required 状态，A 补料后继续。 4. 交付：B 完成，返回 Artifact（报价单 PDF 或结构化 JSON），任务标记 completed；A 校验成果并结束会话。 5. 异常：失败或超时按协议返回明确状态码，由调用方决定重试或降级。
业务视角：这套流程映射的是现实中"发询价单—等回复—收成果"的协作惯例，只是执行者换成了 Agent。对企业而言，价值在于把原本需要 API 对接、邮件往来的跨组织流程压缩为分钟级自动化，且每个状态都可审计——这是向管理层和合规部门证明 Agent 协作可信的关键。
🏗 系统架构师
我把 A2A 工作流程按一次真实任务的生命周期讲，这就是一个标准的分布式长任务编排：
- 发现：Client Agent 拉取目标 Agent 的 Agent Card（
/.well-known/agent.json），确认技能、模态、认证要求匹配； - 任务提交：通过
message/send或message/stream发起，携带任务描述和可选的上下文；服务端返回 task 对象和 task_id——这个 ID 是后续一切交互的锚点； - 执行与状态同步：远程 Agent 执行期间（可能调用自己的工具、甚至自己的 LLM），客户端通过 SSE 流式接收 status-update（进度）和 artifact-update（中间产出）事件；非流式场景轮询
tasks/get； - 交互中断点：任务进入 input-required 状态时挂起，等客户端补充信息后继续——这是它比一次性 API 强的地方，支持多轮协作；
- 终结：completed/failed/canceled 是终态，产出 Artifact 可含多模态内容。
架构师点评：状态机 + 幂等 task_id + 流式推送 + 可中断，这四个设计让 A2A 能承载分钟级甚至小时级的跨组织任务，这是同步式 Function Calling 完全做不到的。超时、重试、补偿都要围绕状态机来设计。
💻 全栈开发专家
A2A 的典型工作流程（以我做的「客服 Agent 调用外部退款 Agent」为例）：
- 发现：启动时（或首次调用前）请求远端
https://refund-agent.example.com/.well-known/agent-card.json，解析出能力列表（支持「售后退款处理」skill）、鉴权要求（OAuth 2.1）、支持传输方式。 - 鉴权：按 Agent Card 声明的方式获取 token（client_credentials 拿 access_token）。
- 发起任务：
message/send或message/stream提交用户请求，服务端创建 Task，返回task_id和初始状态submitted。 - 异步推进：退款要走内部审批，任务进入
working；若选了 stream 就通过 SSE 收状态变更事件。中途需要用户补充信息时，任务转为input-required，客户端收集后再message/send续传。 - 完成取件：任务到
completed，从 Artifact 拿结构化结果（退款单号、金额），失败则拿 error 信息决定重试或降级。
工程细节：一定要做 task_id 的幂等存储和超时兜底（我们设 10 分钟强制查询一次 task/get，防止 SSE 断连丢状态）；A2A 请求体要带 traceparent 头，把分布式链路串起来，否则跨 Agent 排查问题全靠猜。