A2A 协议深度解析:多 Agent 协作的通信标准
前言
在了解了 MCP 协议之后,一个自然的疑问随之而来:A2A 协议又是什么?它和 MCP 有什么区别?
这也是大模型应用开发岗中的高频面试题。本文将从底层逻辑出发,系统梳理 A2A 协议的设计动机、核心概念,以及它与 MCP 的关系。
一句话总结
MCP 解决的是「单个 Agent 如何连接工具与数据」,A2A 解决的是「多个 Agent 之间如何分工协作」。 两者互补,不冲突——MCP 向下连工具,A2A 向上连 Agent。
为什么需要 A2A?——单 Agent 的天花板
要理解 A2A 的价值,首先需要认识到单个 Agent 的能力边界。
一个 Agent 的本质可以拆解为三个维度:
| 维度 | 限制 |
|---|---|
| 工具数量 | 不可能给一个 Agent 挂载上百个工具,模型处理效率会急剧下降 |
| 上下文窗口 | 即使有 128K tokens,复杂任务产生的中间产物(搜索结果、草稿、反思记录)会迅速填满窗口 |
| 专业能力 | 同一个 Agent 既做代码审查又做市场分析,不如各自配备专用 Agent 效果好 |
一个具体的例子
假设任务是:「做一份 AI 编程工具的竞品分析报告,包含行业趋势、技术对比、商业模式分析和 SWOT」。
让单个 Agent 处理会遇到两个问题:
- 上下文溢出:搜索结果和草稿不断累积,等到写 SWOT 时,前面的行业趋势分析早已被挤出有效注意力范围。
- 能力稀释:市场调研和技术分析需要完全不同的知识侧重,一个 Agent 很难兼顾。
自然的解决方案:把任务拆分给不同的专业 Agent 并行处理,最后汇总。这就是 A2A 协议要解决的核心场景。
A2A 的核心概念
1. Agent Card——Agent 的「名片」
多 Agent 系统有一个绕不开的问题:Agent A 要委托任务给 Agent B,它得先知道 B 能做什么。
最原始的方案是硬编码配置,但这样维护成本极高。A2A 的方案是让每个 Agent 主动发布一张「名片」——即 Agent Card。
每个 A2A Agent 在 /.well-known/agent.json 路径下公开自己的 Agent Card,内容包括:
- 名称与描述:这个 Agent 是干什么的
- Skill 列表:能承接哪些类型的任务(如「竞品分析」「行业趋势分析」),并附带示例输入
- 能力声明:是否支持流式返回、是否支持异步回调(Push Notification)
{
"name": "市场分析 Agent",
"description": "专注于行业趋势调研与竞品分析",
"skills": [
{
"name": "竞品分析",
"description": "对指定领域的竞品进行全面分析",
"example_input": "分析 AI 编程工具赛道的主要玩家"
}
],
"capabilities": {
"streaming": true,
"push_notification": true
}
}
调度 Agent 通过读取这些 Skill 描述来做任务路由决策——判断当前任务应该分配给哪个 Agent。
这套机制让整个系统变得可插拔:新增一个 Agent 只需发布它的 Agent Card,调度 Agent 就能自动发现并利用它,无需修改任何已有代码。
2. Task——协作的基本单位
A2A 中任务协作的核心抽象是 Task(任务)。
- 调度 Agent 委托子任务 → 创建一个 Task
- 接收方执行 Task → 产出 Artifacts(文本、文件等)
- 完成后将结果返回给调用方
Task 拥有完整的生命周期状态机:
submitted → working → completed / failed
| 状态 | 含义 |
|---|---|
submitted | 任务已提交,等待处理 |
working | 正在执行中 |
completed | 执行成功,可获取结果 |
failed | 执行失败 |
为什么需要状态机? 因为 A2A 专门为长时间异步任务设计。例如一个「竞品分析」任务可能需要几分钟——先搜索、再整理、再撰写报告,不可能让调度 Agent 同步阻塞等待。
调度 Agent 的工作流非常清晰:
- 向 Agent B 提交一个 Task
- 通过轮询或 Push Notification 获知任务完成
- 获取 Artifacts(任务产出)
整个过程中,调度 Agent 无需知道 Agent B 内部调用了什么工具、请求了几次 LLM——完全黑盒,这正是解耦的意义所在。
A2A 的架构本质——Agent 的微服务化
如果你有后端开发经验,A2A 的设计模式会非常眼熟:它本质上就是 Agent 世界里的微服务架构。
| 微服务概念 | A2A 对应 |
|---|---|
| 独立部署的 HTTP 服务 | 每个 A2A Agent 就是一个 HTTP 服务 |
| API 文档 | Agent Card |
| 服务注册中心 | /.well-known/agent.json |
| 异步消息队列 | Task 状态机 + Push Notification |
每个 A2A Agent 对外暴露标准 HTTP 接口,不绑定特定 AI 框架,不依赖特定编程语言。任何支持 A2A 协议的系统都可以发现它、向它派发任务、接收结果。
A2A 与 MCP 的关系——一纵一横,各管一层
理清两者关系最直观的方式是看方向:
| 协议 | 方向 | 解决的问题 |
|---|---|---|
| MCP | Agent 向下连接工具 | 单个 Agent 如何标准化地调用数据库、浏览器、代码执行器等外部工具 |
| A2A | Agent 向外连接其他 Agent | 多个 Agent 之间如何发现彼此、分配任务、异步协作 |
在复杂系统中的协同
在一个完整的多 Agent 系统里,两者通常同时在用:
- MCP 负责每个 Agent 内部与工具之间的纵向连接
- A2A 负责 Agent 之间的横向协作通信
┌─────────────────────────────────────────┐
│ A2A 协议层 │
│ Agent A ←→ Agent B ←→ Agent C │
└────┬────────────┬────────────┬──────────┘
│ │ │
MCP MCP MCP
│ │ │
数据库 浏览器 代码执行器
MCP 让工具成为独立的标准化服务,A2A 让 Agent 成为独立的标准化服务。 两层协议各管一个维度,合在一起才能支撑起真正复杂的 Agent 系统。
总结
| 对比项 | MCP | A2A |
|---|---|---|
| 提出者 | Anthropic | Google(2025) |
| 解决问题 | Agent ↔ 工具/数据 | Agent ↔ Agent |
| 核心抽象 | Tool、Resource、Prompt | Agent Card、Skill、Task |
| 通信模式 | 同步调用为主 | 支持异步长任务 + 流式推送 |
| 类比 | 数据库驱动 / SDK | 微服务架构 |
| 关系 | 互补,不冲突 | 互补,不冲突 |
一句话记忆:MCP 管「Agent 能用什么工具」,A2A 管「Agent 之间怎么合作」。在实际的多 Agent 系统中,二者缺一不可。