A2A 协议深度解析:多 Agent 协作的通信标准

May 1, 2025·
1ch0
1ch0
· 2 min read

前言

在了解了 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 处理会遇到两个问题:

  1. 上下文溢出:搜索结果和草稿不断累积,等到写 SWOT 时,前面的行业趋势分析早已被挤出有效注意力范围。
  2. 能力稀释:市场调研和技术分析需要完全不同的知识侧重,一个 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 的工作流非常清晰:

  1. 向 Agent B 提交一个 Task
  2. 通过轮询或 Push Notification 获知任务完成
  3. 获取 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 的关系——一纵一横,各管一层

理清两者关系最直观的方式是看方向

协议方向解决的问题
MCPAgent 向下连接工具单个 Agent 如何标准化地调用数据库、浏览器、代码执行器等外部工具
A2AAgent 向外连接其他 Agent多个 Agent 之间如何发现彼此、分配任务、异步协作

在复杂系统中的协同

在一个完整的多 Agent 系统里,两者通常同时在用

  • MCP 负责每个 Agent 内部与工具之间的纵向连接
  • A2A 负责 Agent 之间的横向协作通信
┌─────────────────────────────────────────┐
│              A2A 协议层                  │
│   Agent A  ←→  Agent B  ←→  Agent C    │
└────┬────────────┬────────────┬──────────┘
     │            │            │
   MCP          MCP          MCP
     │            │            │
  数据库       浏览器       代码执行器

MCP 让工具成为独立的标准化服务,A2A 让 Agent 成为独立的标准化服务。 两层协议各管一个维度,合在一起才能支撑起真正复杂的 Agent 系统。


总结

对比项MCPA2A
提出者AnthropicGoogle(2025)
解决问题Agent ↔ 工具/数据Agent ↔ Agent
核心抽象Tool、Resource、PromptAgent Card、Skill、Task
通信模式同步调用为主支持异步长任务 + 流式推送
类比数据库驱动 / SDK微服务架构
关系互补,不冲突互补,不冲突

一句话记忆:MCP 管「Agent 能用什么工具」,A2A 管「Agent 之间怎么合作」。在实际的多 Agent 系统中,二者缺一不可。