A2A vs MCP

可视化演示

展示A2A与MCP两大Agent通信协议：MCP的Client-Server架构展示Host/Client/Server三层工具调用；A2A的P2P架构展示Agent间对等协作；互补模式展示两者在多Agent系统中的协同。

A2A 协议：Agent 间的协作契约

市场部经理王姐要把「新品上线」的消息传给客服部经理李哥。她不会直接闯进客服部喊一嗓子，而是发一封标准的任务交接邮件、约一次对齐会议、再跟进一张进度表。这些「先约定好再沟通」的流程，就是部门之间的协作契约。

在 AI 世界里，当多个 Agent 要共同完成一个复杂任务时，同样需要这样的契约，这就是 A2A 协议。A2A 全称 Agent-to-Agent，由 Google 等机构推动，专门定义 Agent 之间如何通信与协作。它的核心目的是解决多 Agent 系统的互操作问题：让不同团队开发的 Agent，能像不同部门用统一邮件模板那样互相理解。

A2A 协议里有三个关键组件：Agent Card 就像部门门口挂的「服务简介牌」，写明这个 Agent 能干什么、怎么联系；任务生命周期规定了任务从创建、运行到完成的各种状态，相当于「待办→进行中→已验收」的流程管理；消息传递机制则定义了 Agent 之间用什么格式交换信息。有了这三样，Agent 之间不仅能互相「自我介绍」，还能顺畅地委派任务、回报进度。

$$\displaystyle Agent_i \xrightarrow{\text{A2A}} Agent_j$$

1. 发送方 Agent_i：发起协作请求的智能体，相当于主动打电话找对方部门的王姐。

$$Agent_i$$

2. 通信机制 A2A：两个 Agent 共同遵守的协作语言与流程，相当于公司统一的邮件模板和会议制度。

$$\xrightarrow{\text{A2A}}$$

3. 接收方 Agent_j：接受请求、处理任务并回报结果的另一个智能体。

$$Agent_j$$

4. 整体流向：从 Agent_i 到 Agent_j 的协作消息传递，箭头方向代表委托关系，实际协作中消息也会反向流动。

$$Agent_i \xrightarrow{\text{A2A}} Agent_j$$

就像王姐和李哥靠交接单完成协作一样，A2A 协议让两个「素不相识」的 Agent 也能高效配合——这正是多 Agent 系统能够协同工作的基石。

MCP 协议：Agent 的万能工具插口

李哥拿到了市场部的交接单，要查「新品的预售数据」。他不会用算盘去拨珠，而是坐在工位上，用键盘鼠标操作数据库软件。键盘和鼠标之所以好用，是因为它们有统一的接口标准——插上就能用，不用管背后是机械键盘还是触控板。

MCP 就是智能体世界里的那个「标准插口」。MCP 全称 Model Context Protocol（模型上下文协议），由 Anthropic 推出，它标准化了「模型」与「外部工具」之间的连接接口。打个比方，一个 Agent 想查天气、读文件、调数据库，它不用为每个工具学习一套「特殊用法」，只需要通过 MCP 客户端接入，就能像用 USB 口连接不同设备一样连接各种工具。

MCP 采用了客户端-服务器架构：Agent 内置 MCP 客户端，工具供应商提供一个 MCP 服务器，两者之间通过 JSON-RPC 2.0 这种「公共普通话」通信。更重要的是，MCP 还管理上下文——工具调用的结果会被注入到模型对话中，让 Agent 在一次任务里持续引用最新数据。这正是它聚焦单 Agent、服务工具调用的体现：一个 Agent 可以同时连接多个 MCP 服务器，每个服务器背后是一项具体能力。

$$\displaystyle Agent_i \xrightarrow{\text{MCP}} Tool_k$$

1. 调用方 Agent_i：发起工具调用请求的智能体，相当于想用电脑办公的员工。

$$Agent_i$$

2. 调用机制 MCP：一套统一的协议层，屏蔽了不同工具之间的差异，就像 USB 口屏蔽了鼠标、键盘、U 盘的差异。

$$\xrightarrow{\text{MCP}}$$

3. 目标工具 Tool_k：被调用的具体工具或数据源，可以是数据库、API、文件系统等。

$$Tool_k$$

4. 整体含义：Agent_i 通过 MCP 这条「标准插口」驱动 Tool_k 完成任务，调用结果会作为上下文返回给模型。

$$Agent_i \xrightarrow{\text{MCP}} Tool_k$$

现在回头看：王姐和李哥之间靠交接单协作是 A2A，而李哥用键盘鼠标操作电脑是 MCP。一条管「人跟人」，一条管「人用工具」，两条链路互不替代，各管一段。

核心区别：对内协作与对外调用

回到公司的比喻，你能直观感受到两者的差别：王姐和李哥在走廊里聊天、开会对齐，这是「部门之间」的事情；而李哥回到工位敲键盘、用数据库软件，这是「员工跟工具」的事情。A2A 和 MCP 的区别，正藏在这两句话里。

A2A 关注的是多 Agent 系统的互操作。它回答的是「谁来做、做什么、做得怎样」这些协作问题：多个智能体如何发现彼此、如何委派任务、如何同步状态、如何协商分歧。MCP 关注的则是单 Agent 的工具调用：一个智能体如何按标准方式找到工具、传参、拿到结果，以及如何管理调用过程中的上下文。一个是「Agent 与 Agent 的关系」，一个是「Agent 与工具的关系」。

从使用方向也能看出差异。A2A 的通信往往是双向的、对等的——Agent 双方在协商与回传中来回沟通；MCP 的调用则清晰地分为「调用方」和「服务方」，Agent 是主动方，工具是被动方。在具体场景里，需要协调多个智能体的任务规划时用 A2A；需要让智能体访问外部数据或执行动作时用 MCP。两者组合起来，才能支撑一个完整的复杂系统。

$$\displaystyle \text{A2A}: A_i \leftrightarrow A_j \qquad \text{MCP}: A_i \xrightarrow{\text{调用}} T_k$$

1. A2A 的双向箭头：表示 Agent 之间会来回传递信息，像部门间的协商与反馈。

$$A_i \leftrightarrow A_j$$

2. MCP 的单向箭头：表示 Agent 主动调用工具，工具返回结果后一次交互结束。

$$A_i \xrightarrow{\text{调用}} T_k$$

3. 对象差异：A2A 的两端都是 Agent，MCP 的一端是 Agent、另一端是工具，这是最本质的区分。

$$A_i \; vs \; A_j \quad \text{与} \quad A_i \; vs \; T_k$$

4. 语义差异：A2A 承载「协作意图」，MCP 承载「执行意图」，一个偏管理、一个偏操作。

$$\text{协作意图} \neq \text{执行意图}$$

所以别再纠结「选 A2A 还是 MCP」了——就像你不会问公司「到底该要部门协作制度，还是该发电脑」，两者服务的是完全不同的两层面的问题。

互补共融：双剑合璧

一家成熟的公司，既要有王姐和李哥之间的跨部门协作流程，也要保证每位员工手里的工具插口好用。如果市场部把需求记在本子上不交给产品部，公司就转不动；如果员工连电脑都不会用，再好的流程也产不出成果。两者不是二选一，而是各管一摊、互为支撑。

放到复杂 AI 系统里，A2A 和 MCP 的互补关系更加明显。一个典型的多 Agent 任务会这样流转：负责「感知」的 Agent 通过 MCP 调用数据库或 API 获取数据；负责「决策」的 Agent 收到数据后进行处理，再通过 A2A 把结果转交给「执行」的 Agent；执行 Agent 又通过 MCP 调用具体工具落地动作。整条链路上，MCP 负责「让每个 Agent 有能力」，A2A 负责「让能力之间能传递」。

这也是当前业界的主流做法：既采用 A2A 保证多 Agent 间的互操作，也采用 MCP 规范工具调用。两者在协议设计上并不冲突，反而形成了「感知—决策—执行—传递」的闭环。许多复杂系统的实际方案，正是由「MCP 打通工具层」与「A2A 打通协作层」两部分共同组成的。

$$\displaystyle \text{协作系统} = \underbrace{\left( A_i \xrightarrow{\text{MCP}} T_k \right)}_{\text{工具调用层}} + \underbrace{\left( A_i \xrightarrow{\text{A2A}} A_j \right)}_{\text{Agent 协作层}}$$

1. MCP 部件：括号里的 MCP 链路，负责让 Agent 调用工具、获取外部世界的数据。

$$\left( A_i \xrightarrow{\text{MCP}} T_k \right)$$

2. A2A 部件：括号里的 A2A 链路，负责让不同 Agent 之间传递任务和结果。

$$\left( A_i \xrightarrow{\text{A2A}} A_j \right)$$

3. 加号：表示两者「同时存在、缺一不可」，而不是先后交替的互斥关系。

$$\text{工具调用层} + \text{Agent 协作层}$$

4. 整体价值：两层叠加，才构成一个既能感知世界、又能协同分工的完整智能系统。

$$\text{协作系统} = \text{能力} + \text{协同}$$

如果说 MCP 是右手——负责把工具抓起来用起来，那么 A2A 就是左手——负责把接力棒稳稳交给下一个伙伴。两只手都在，系统才能真正跑起来。

技术栈分工：协议各司其职

在公司组织架构里，人力资源部负责「员工关系与文化沟通」，IT 部负责「办公设备与软件系统」。两个部门职责分明：前者处理的是人与人之间的协作规则，后者处理的是人与机器之间的连接问题。谁也不抢谁的饭碗。

在技术栈中，A2A 和 MCP 也分别处在不同的抽象层。A2A 位于 Agent 协作层，处理的是智能体间的协调：能力发现、任务编排、状态同步、协商仲裁——这些都属于「智能体社会」层面的内容。MCP 位于工具接入层，处理的是 Agent 与外部资源的连接：API 封装、参数校验、权限控制、上下文注入——这些都属于「工具接口」层面的内容。

从系统架构设计角度看，这两个协议可以同时出现在同一条调用链里。比如在智能客服系统里，A2A 负责让「订单查询 Agent」和「售后处理 Agent」互相配合，而每个 Agent 内部又通过 MCP 调用各自的订单系统、物流系统接口。架构图上，A2A 画在 Agent 之间的虚线上，MCP 画在 Agent 与工具之间的实线上，两条线一上一下，各安其位。

$$\displaystyle \text{Multi-Agent Stack} = \underbrace{\text{A2A}}_{\text{Agent 间协调}} + \underbrace{\text{MCP}}_{\text{工具接入}}$$

1. 上层 A2A：位于技术栈上层的 Agent 协作层，解决智能体之间的沟通与编排问题。

$$\underbrace{\text{A2A}}_{\text{Agent 间协调}}$$

2. 下层 MCP：位于技术栈下层的工具接入层，解决智能体与外部世界的连接问题。

$$\underbrace{\text{MCP}}_{\text{工具接入}}$$

3. 加号：表示两层在架构中纵向叠加，Agent 本体在中间充当「翻译官」。

$$\text{Agent 间协调} + \text{工具接入}$$

4. 架构含义：中间是 Agent 本体，向上用 A2A 与同伴对话，向下用 MCP 与工具交互。

$$\text{Agent} \uparrow \text{A2A} \quad \text{Agent} \downarrow \text{MCP}$$

架构设计最怕「万金油」式的协议，什么都想管。A2A 和 MCP 这种清晰的职责分层，反而让系统更容易设计、调试和扩展。

实践应用：复杂任务中的配合战

一个新品发布会项目要成功，靠的不是单打独斗：市场部要查舆情数据，产品部要调设计素材，最后都要把成果汇总到项目经理那里。员工查数据用工具，经理间传信息走流程——这条链路，正是多 Agent 系统落地的缩影。

在实际开发中，A2A 与 MCP 的结合显著提升了任务完成质量和系统可靠性。以电商客服系统为例：用户问「我的手机什么时候送到」，主控 Agent 先通过 A2A 把任务分派给订单 Agent 和物流 Agent；订单 Agent 通过 MCP 查询订单数据库，物流 Agent 通过 MCP 查询物流 API；两个 Agent 再把结果通过 A2A 回报给主控 Agent，由它统一回答。一旦用户提出「改了地址」，售后 Agent 还能通过 MCP 调用变更接口，整个过程自动闭环。

为什么这种组合能提升可靠性？因为 MCP 保证了「每个环节的工具调用是标准化的」，减少了大模型瞎猜接口格式的幻觉；A2A 保证了「环节之间的交接是结构化的」，任务状态清晰、可追踪、可重试。两者配合，让复杂任务从「一锤子买卖」变成了「一条可追溯、可恢复的生产线」。

$$\displaystyle \underbrace{A_1 \xrightarrow{\text{MCP}} T}_{\text{查询数据}} \;\xrightarrow{\text{A2A}}\; \underbrace{A_2 \xrightarrow{\text{MCP}} T'}_{\text{执行动作}}$$

1. 第一步 MCP 查数：第一个 Agent 通过 MCP 调用工具 T，获得任务所需的原始数据。

$$\underbrace{A_1 \xrightarrow{\text{MCP}} T}_{\text{查询数据}}$$

2. 第二步 A2A 传递：Agent 1 把整理好的结果通过 A2A 协议交给 Agent 2，完成协作接力。

$$\xrightarrow{\text{A2A}}$$

3. 第三步 MCP 执行：Agent 2 接到结果后，通过 MCP 调用工具 T'，完成实际落地动作。

$$\underbrace{A_2 \xrightarrow{\text{MCP}} T'}_{\text{执行动作}}$$

4. 链路整体：三个环节串成一条链，MCP 负责「干活」，A2A 负责「交接」，环环相扣。

$$\text{查数} \rightarrow \text{交接} \rightarrow \text{执行}$$

一个项目的成功，既离不开「工具用得顺」，也离不开「部门传得快」。A2A 与 MCP 的配合战，正在无数生产系统里上演。

AI 应用场景

Python 演示

class Tool:    """模拟一个外部工具，比如天气查询 API"""    def __init__(self, name, data):        self.name = name        self.data = data     def query(self, key):        # 模拟返回工具数据        return self.data.get(key, "无数据")  class MCPClient:    """模拟 MCP 协议：Agent 通过它标准化地调用工具"""    def __init__(self, tool):        self.tool = tool     def call(self, key):        # MCP 的核心：把 Agent 的请求包装成标准调用        return self.tool.query(key)  class Agent:    """一个同时具备 MCP 与 A2A 能力的 Agent"""    def __init__(self, name, mcp_client):        self.name = name        self.mcp_client = mcp_client        self.outbox = []     def fetch(self, key):        # 通过 MCP 调用工具，拿到数据        data = self.mcp_client.call(key)        self.outbox.append((key, data))        return data     def send_to(self, other, key):        # 通过 A2A 协议发送消息给另一个 Agent        message = {"from": self.name, "key": key, "data": self.outbox[-1][1]}        other.receive(message)     def receive(self, message):        # 通过 A2A 接收其他 Agent 的消息        print(f"[A2A] {self.name} 收到来自 {message['from']} 的消息：{message['key']} = {message['data']}")  if __name__ == "__main__":    # 模拟一个天气数据源作为工具    weather_tool = Tool("weather", {"北京": "晴", "上海": "小雨"})    # 检索 Agent 通过 MCP 连接天气工具    retriever = Agent("检索Agent", MCPClient(weather_tool))    # 汇报 Agent 没有工具，专注接收和汇总    reporter = Agent("汇报Agent", None)     city = "北京"    weather = retriever.fetch(city)          # 这是 MCP 链路：Agent -> 工具    print(f"[MCP] 检索Agent 通过 MCP 查询到 {city} 的天气：{weather}")    retriever.send_to(reporter, city)        # 这是 A2A 链路：Agent -> Agent

1. class MCPClient:模拟 MCP 协议中的客户端角色，统一封装工具调用入口。
2. def call(self, key):对应 MCP 的「调用工具」请求，屏蔽了不同工具的差异。
3. self.outbox.append(...)Agent 把 MCP 调用结果暂存，为后续 A2A 传递准备数据。
4. def send_to(self, other, key):对应 A2A 协议的核心动作：给另一个 Agent 发消息。
5. other.receive(message)对应 A2A 的消息接收端，被调用的 Agent 按协议处理消息。
6. retriever = Agent("检索Agent", MCPClient(weather_tool))让一个 Agent 同时具备 MCP 工具能力。
7. reporter = Agent("汇报Agent", None)没有工具的 Agent 也能参与协作，A2A 不要求双方都有 MCP。
8. retriever.fetch(city)完整走一遍 MCP 链路：Agent → MCP 客户端 → 工具 → 返回数据。
9. retriever.send_to(reporter, city)完整走一遍 A2A 链路：检索 Agent → 汇报 Agent，交接的是 MCP 成果。

常见误区

面试题