协议A2A协议AgentGoogle

A2A (Agent-to-Agent Protocol)

Google 提出的 Agent 间通信协议，让不同平台、不同框架的 AI Agent 能互相发现、协商、协作。

什么是 A2A

A2A（Agent-to-Agent Protocol）是 Google 于 2025 年提出的开放协议，解决不同 Agent 之间如何通信和协作的问题。

如果说 MCP 解决的是"Agent 如何连接工具"，那 A2A 解决的是"Agent 如何连接其他 Agent"。

解决什么问题

当前 Agent 生态是孤岛：

Coze 上的 Agent 不能调用 Dify 上的 Agent
Claude Code 不能委派任务给 Manus
企业自建 Agent 不能与外部 Agent 协作

A2A 提供标准化的通信协议，让任何 Agent 都能：

发现 — 找到其他 Agent 的能力
协商 — 确认对方能否完成任务
委派 — 把子任务交给最合适的 Agent
回调 — 接收其他 Agent 的结果

这与 SOA / 微服务时代解决"服务怎么互相找到对方"是同一类问题。A2A 借鉴了 OpenAPI（自描述）和 OAuth（鉴权）的成熟模式，但把对象从"服务"换成"Agent"，多出了「长任务」「流式回包」「人在回路」三个 Agent 特有需求。

工作原理

Agent Card

每个 Agent 暴露一个 Agent Card（类似名片），描述自己的能力：

{
  "name": "code-review-agent",
  "description": "Reviews code for bugs, security, and style",
  "capabilities": ["code-review", "security-scan"],
  "endpoint": "https://example.com/a2a/agent",
  "auth": "bearer-token"
}

Agent Card 一般挂在固定路径（如 /.well-known/agent.json），客户端通过 HTTP GET 拉取——和 OpenAPI 的 swagger.json 一个套路。

任务流程

Agent A: "我需要代码审查"
  ↓
发现 Agent B 的 Agent Card → B 能做代码审查
  ↓
A 向 B 发送任务请求（附带代码）
  ↓
B 接受任务，开始审查
  ↓
B 返回审查结果给 A
  ↓
A 整合结果，继续主任务

一次请求长什么样

A2A 在 HTTP 上跑 JSON-RPC 风格的方法，常见三个：

// 1. 发起任务（异步，立刻返回 taskId）
POST https://example.com/a2a
{
  "jsonrpc": "2.0", "id": 1,
  "method": "tasks/send",
  "params": {
    "id": "task-001",
    "message": {
      "role": "user",
      "parts": [{ "type": "text", "text": "Review this diff: ..." }]
    }
  }
}

// 2. 查询任务状态（轮询或 SSE 订阅）
{ "method": "tasks/get", "params": { "id": "task-001" } }

// 3. 取消任务
{ "method": "tasks/cancel", "params": { "id": "task-001" } }

任务状态机：submitted → working → input-required → completed / failed / canceled。input-required 是 A2A 比传统 RPC 多出来的一档——长任务跑到一半需要补输入时，可以挂起等回包。

A2A vs MCP

维度	MCP	A2A
连接对象	Agent ↔ 工具	Agent ↔ Agent
提出者	Anthropic	Google
通信模式	同步调用	异步任务 + 流式回包
状态	单次往返为主	长任务有完整生命周期
适用场景	工具调用	任务委派
关系	互补	互补

两者可以组合使用：Agent A 通过 A2A 委派任务给 Agent B，Agent B 通过 MCP 调用工具完成任务。

A2A vs Webhook / 普通 REST

新人常问"A2A 和我自己写个 Webhook 调对方 API 有啥不一样"——主要差异在三处：

维度	自写 REST/Webhook	A2A
能力发现	自己读对方文档	Agent Card 标准化
长任务支持	自己实现轮询/回调	协议内置任务状态机
多 Agent 编排	每对 Agent 单独适配	一套协议接入所有 Agent
鉴权	各家一套	标准 OAuth2 / Bearer
流式中间态	自己定 SSE 格式	协议规定 message parts 流式回包

简言之：能用 REST 解决的双方对接，A2A 并不省事；它的价值在 N×M 互联——一个 Agent 同时要调多家 Agent 服务时。

五分钟接入清单

第一次让你的 Agent 接受 A2A 调用，建议这个顺序：

挑一个能力点先暴露——不要一上来就 mapping 所有内部函数，先选一个无副作用、文档清楚的（比如「查某 ID 的状态」）。
写 Agent Card——name / description / capabilities / endpoint / auth 五个字段先填上，跑个 GET /.well-known/agent.json 能拿到 200 就算第一关过。
实现最小三方法——tasks/send / tasks/get / tasks/cancel。返回先用 mock 数据，验证客户端能正确解析。
接真实业务——把 mock 换成真实逻辑，注意区分同步立返和异步长任务两种返回。
加 Auth——Bearer Token 起步，生产环境上 OAuth2。不要在没鉴权前把 Agent Card 暴露到公网。

常见踩坑

Agent Card 字段写"我什么都能干"——客户端会按 capabilities 路由，写得太宽会被发各种意外任务。capabilities 写具体动词（code-review、generate-image），不要写形容词（smart、powerful）。
同步阻塞 tasks/send——任务超过几秒就应该立即返回 submitted 让对方轮询/订阅；阻塞返回会让客户端的 timeout 各种炸。
状态机偷懒——只用 completed 和 failed，跳过 working 和 input-required，客户端就没法显示进度，也没法做人在回路。
没做幂等——同一个 taskId 被重发（网络重试），如果你的实现会再跑一次，副作用就会重复执行。tasks/send 必须按 ID 去重。
Agent Card 缓存太久——能力升级了但客户端拿到的还是老 card。带 ETag 和合理的 Cache-Control，或者在 Card 里放 version。

什么场景不该用 A2A

只有两个 Agent 长期一对一调用——直接 REST 调用更轻，A2A 是为 N×M 准备的。
延迟敏感（< 100ms）的内部调用——A2A 那套任务状态机 + 状态轮询有协议开销，进程内函数调用更合适。
强一致事务——A2A 是异步任务模型，不保证 ACID。账户转账这种场景应该用传统 RPC + 分布式事务。
纯工具调用而非 Agent 协作——用 MCP，工具调用走 A2A 是杀鸡用牛刀。

生态现状

A2A 协议较新（2025 年提出），目前支持的平台：

Google AI Studio / Vertex AI
部分 LangChain Agent
尚未被 Coze / Dify 等主流平台广泛支持

未来如果 A2A 普及，将出现"Agent 市场"——不同平台上的 Agent 可以自由组合协作。当下阶段（2026 中），生产引入需谨慎：协议本身在迭代，客户端 SDK 成熟度有限，先在内部 PoC 跑通了再考虑跨组织对接。