A2A 协议不是 MCP 的替代品——多 Agent 通信到底该怎么选
A2A 协议和 MCP 不是竞争关系，而是互补的两层——理解清楚之后，多 Agent 系统的架构就清晰了。
多 Agent 系统里最容易被低估的环节是什么？
不是 Agent 本身的推理能力，不是工具调用的稳定性，是 Agent 之间怎么说话。
这半年我在搭多 Agent 系统，走通了从单 Agent 到多 Agent 协作的整个链条。过程中发现自己在一个问题上反复纠结：A Agent 跟 B Agent 之间，到底应该怎么通信？直接调 API？走消息队列？还是用某种协议？
后来深入看了 Google 推的 A2A（Agent-to-Agent Protocol），才算真正想清楚这个问题。
先说结论：A2A 不是另一个 MCP。它们是解决不同问题的两层。把这两层分清楚，多 Agent 架构就顺了。
先搞清楚 MCP 干了什么
很多人把 A2A 和 MCP 放在一起比，一上来就问 "选哪个"。
这个问题本身就错了。
MCP 解决的是 Agent 跟工具的连接问题。你的 Agent 需要读文件、查数据库、调 GitHub API，这些事 MCP 来做。它把工具封装成统一的接口，就像 USB-C 统一了充电口一样——你只需要写一个 MCP Server，所有支持 MCP 的客户端都能复用。
没有 MCP 的时候，接入一个工具的成本是 "工具数 × LLM 数"。GitHub + GitLab + 文件系统，再乘以 GPT + Claude + DeepSeek，适配代码写到你手软。MCP 把这个乘法变成了加法。
但 MCP 管不到 Agent 跟 Agent 之间的事。
因为工具和 Agent 有一个根本区别：工具是无状态的。你调一个搜索 API，传 query 进去，返回结果出来，一次调用就结束了。Agent 不是这样的。Agent 需要协商、需要确认、需要多轮交互——更像是两个人在对话，而不是一个程序在调函数。
A2A 解决的是什么问题
想象一个场景。你的多 Agent 系统有一个研究 Agent 搜集信息，一个分析 Agent 处理数据，一个写作 Agent 生成报告。
这三个 Agent 可能用不同的框架写的：研究 Agent 用 LangGraph 搭的，分析 Agent 是 CrewAI，写作 Agent 是自己撸的。它们部署在不同服务器上，甚至可能来自不同团队。
问题是：它们怎么发现彼此？怎么把任务递过去？怎么知道对方做完了？
这就是 A2A 要解决的问题。
A2A 定义了一套标准的通信方式，让 Agent 之间可以互相发现、发送任务、跟踪进度、获取结果。不管底层是什么框架、什么模型、什么基础设施。
Agent Card：A2A 最聪明的设计
A2A 的核心设计，在我看来是 Agent Card。
每个支持 A2A 的 Agent 都需要暴露一个 JSON 文件，相当于自己的名片。名片上写着：我叫什么、我能干什么、怎么调用我。
{
"name": "Research Agent",
"description": "信息搜集 Agent，擅长互联网调研和数据整理",
"url": "https://agent.example.com/a2a",
"capabilities": {
"streaming": true
},
"skills": [
{
"id": "web_search",
"name": "网页搜索",
"description": "使用搜索引擎获取互联网信息"
},
{
"id": "data_analysis",
"name": "数据分析",
"description": "分析结构化数据并生成报告"
}
]
}
这段配置的价值在于：它让 Agent 之间的协作变成了声明式的。
以前你想让 A Agent 调 B Agent，你需要手写适配代码，处理 B 的 API 格式、认证方式、错误处理。现在 A 只需要读 B 的 Agent Card，就知道 B 能干什么、怎么调用。发现和调用是标准化的。
而且这个设计隐含了一个重要的能力：Agent 的自治性。B Agent 不需要暴露内部逻辑，不需要共享内存，不需要开放工具列表。A 只知道 B 能干什么，不知道 B 是怎么干的。这对生产系统来说很关键——你不想让别人看到你 Agent 内部的 prompt 策略和工具链。
任务生命周期的设计很到位
A2A 定义了一套完整的任务状态机：
submitted → working → input-required → completed
↓
failed → canceled
这看起来只是一个简单的状态流转，但实际做过多 Agent 系统的人就知道它有多重要。
Agent 之间的任务不是函数调用。你丢给 B Agent 一个任务，它可能需要几秒、几分钟、甚至几十分钟才能完成。这中间可能发生各种情况：B 发现缺信息需要问你、B 挂了、B 返回的结果不满意需要重做。
如果没有标准的状态协议，你只能自己搞一套轮询机制 + 状态编码 + 异常处理。每个项目一套，互不兼容。A2A 把这套东西固定下来了，所有 Agent 共用同一个理解。
A2A + MCP：完整的 Agent 栈
这是最值得说清楚的部分。
单独看 A2A 和 MCP 都很轻，但组合起来才有力量。一个典型的多 Agent 系统，通信架构应该是三层：
底层是 MCP，连接每个 Agent 和它需要的工具。研究 Agent 通过 MCP 调搜索 API，分析 Agent 通过 MCP 查数据库。
中间是 Agent 本体，跑 LLM 推理，做决策。
上层是 A2A，让 Agent 之间互相发任务、收结果。
┌──────────────────────────────────────┐
│ A2A: Agent ←→ Agent │
│ (任务分配、状态追踪、结果返回) │
├──────────────────────────────────────┤
│ Agent A Agent B Agent C │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ MCP │ │ MCP │ │ MCP │ │
│ └────────┘ └────────┘ └────────┘ │
│ 搜索API 数据库 GitHub API │
└──────────────────────────────────────┘
MCP 解决的是 Agent "做事"的问题，A2A 解决的是 Agent "找人"的问题。两件事本来就是分开的。
我在搭自己的系统时踩过一个坑：一开始没有区分这两层，想把 Agent 间的通信也用 MCP 的 Tool 机制来做——把一个 Agent 包装成另一个 Agent 的工具。结果发现根本行不通。Agent 之间的交互是多轮的、有状态的、可能需要回退的，用无状态的 Tool 语义去描述，代码写得极其别扭。
A2A 的任务生命周期和 Artifact 机制天然就是为这种场景设计的。
什么时候该用 A2A
不是所有场景都需要 A2A。我的判断标准是三条：
-
Agent 是独立部署的。如果所有 Agent 都在同一个进程里，用进程内通信或者框架自带的编排就够了，不需要引入协议。
-
Agent 可能来自不同团队或组织。这是 A2A 最强的场景——A Agent 不知道 B Agent 的实现细节，但通过 Agent Card 知道它能干什么。
-
任务执行时间不确定。几秒完成的任务可以用同步调用，几分钟甚至更长的任务需要 A2A 的状态追踪机制。
反过来，如果你的系统就是一个进程里的几个函数，硬上 A2A 就是在给自己找麻烦。
A2A 的现状和生态
截至 2026 年 5 月，A2A 已经进入 Linux Foundation 托管，不再只是 Google 的项目。生态上的几个信号值得关注：
Python、TypeScript、Java、Go、C# 都有了官方 SDK。这意味着你的 Agent 不管是哪个语言写的，都能接入。
MCP 社区已经有 8000+ 个 Server，生态比 A2A 成熟得多。但从架构视角看，这不是问题——MCP 比 A2A 早发布接近一年，生态规模大是正常的。两者不是一个维度的事。
我自己的做法是：先把 MCP 跑起来，让 Agent 能调用工具。然后等 Agent 的数量超过两个、且它们需要互相协作的时候，再引入 A2A。不要一开始就上全套，容易把自己绕晕。
一点个人判断
A2A 目前最缺的不是协议能力，是落地案例。
协议本身的设计是干净的——Agent Card、任务状态机、SSE 流式传输，这些东西都经得起推敲。但大部分关于 A2A 的文章还在介绍概念层面，真正在生产环境跑起来的案例不多。
这也是可以理解的。多 Agent 系统本身就没到成熟期，Agent 间的通信协议更是前沿中的前沿。如果你打算现在就吃螃蟹，建议先用 Python SDK 搭一个 Demo，走通一个 Agent 把任务委派给另一个 Agent 的完整流程。走完这一步，对 A2A 的理解会比你读十篇文章都深。
某种意义上，A2A 正在经历 MCP 一年前经历过的阶段：协议定了，SDK 有了，但生态要靠第一批实践者来验证。这个阶段反而最有意思。
评论
发表评论