从 MCP 到 A2A：多智能体协议栈实战
本文面向正在把"单 Agent 调几个工具"升级到"多个 Agent 协同完成长任务流"的后端 / 架构同学。你会得到一套可落地的双层协议栈架构，以及从 MCP 工具层一路打通到 A2A 协作层的真实代码，而不是又一篇只讲概念的横评。
[配图位置 1：DLA 双层协议栈架构图 —— 上层 A2A 协作层、下层 MCP 工具层、中间 Supervisor 编排]
一、为什么单协议不够用
1.1 协议碎片化现状
2024 年底 Anthropic 推出 MCP（Model Context Protocol，模型上下文协议）后，"Agent 调工具"终于有了统一接口；2025 年 Google 跟进 A2A（Agent2Agent，智能体间协议），解决的是"Agent 调 Agent"。两者职责完全不同：MCP 是工具集成层，A2A 是Agent 协作层。
但社区里大量文章把二者混为一谈，或者只讲其中一个。结果很多团队用 MCP 硬凑多 Agent 编排，把任务状态、消息路由、能力发现全塞进工具参数里，代码越写越像一团意大利面。
1.2 一个真实踩坑
某内部调度系统最初只用 MCP：三个 Agent 各自注册一堆工具，靠一个"总控工具"在参数里传 JSON 指令互相调用。上线两周后，一次跨 Agent 长任务流失败了，排查发现是某个工具把 A2A 本该承载的"任务状态"塞进了 MCP 的arguments字段，导致重试时状态丢失。
根因就是：用工具层的协议去承载协作层的语义。这正是双层协议栈要解决的。
二、DLA 双层协议栈模型
2.1 MCP：工具集成层
MCP 基于 JSON-RPC 2.0，通过 Streamable HTTP 或 stdio 传输，让 Agent 以标准化方式发现并调用外部工具（数据库、ERP、API）。它的边界很清晰：只管"怎么调一个能力"，不管"谁在指挥谁"。
2.2 A2A：Agent 协作层
A2A 由 Google 提出，核心概念是 Agent Card（能力名片）、Task（任务）、Message（消息）、Artifact（产物）。每个 Agent 通过.well-known/agent.json声明自己能干什么，Supervisor 用 A2A 把大任务拆给下游 Agent，并在 Task 里跟踪状态。
2.3 双层如何衔接
本文提出的DLA 双层协议栈（Dual-Layer Agent Protocol Stack）把两者正交组合：
下层 MCP：每个 Agent 左侧挂自己的工具（ERP 查询、代码执行等）；
上层 A2A：Agent 之间只通过 A2A 的 Task/Message 通信，绝不在工具参数里传协作语义；
中间 Supervisor：一个特殊的编排 Agent，自己用 MCP 拿"任务状态"，用 A2A 派发子任务。
衔接点就一句话：MCP 解决"Agent 能调用什么"，A2A 解决"Agent 之间怎么分工"。
三、环境准备与实测基线
3.1 测试环境
本文所有代码与压测基于以下环境（版本号已标注，便于复现）：
运行时：Python 3.12.3
MCP SDK：mcp1.2.0（FastMCP）
A2A SDK：a2a0.2.1
编排框架：LangGraph 0.2.9
容器：8C16G，内网部署
3.2 基准数据
在上面的环境里，先单独测了单层调用的基线（样本量 200 次）：
单 Agent 经 MCP 调一个工具，平均往返延迟38ms，P9562ms；
两个 Agent 经 A2A 传递一条 Message，平均21ms，P9540ms。
这组基线用于对照后面"双层叠加"后的真实损耗。
四、MCP 工具层实战
4.1 用 FastMCP 暴露 ERP 工具
下面这段代码起一个 MCP Server，把两个 ERP 能力注册为标准工具。注意它只暴露能力，不包含任何协作逻辑。
4.2 工具注册与鉴权要点
工具名用动词短语（query_*/create_*），下游 Agent 看名字就能判断能力；
生产环境务必在mcp.run前挂鉴权中间件，MCP 本身不强制认证；
工具返回结构保持扁平，便于 A2A 的 Artifact 直接封装转发。
五、A2A 协作层实战
5.1 Agent Card 声明能力
A2A 的关键是把"我能干什么"写成 Agent Card，供 Supervisor 发现。下面是对库存 Agent 的名片（节选）：
5.2 Supervisor 编排多 Agent
Supervisor 用 A2A 把"查库存→生成采购单"串成一条任务流，全程不碰 MCP 的工具参数：
六、端到端贯通与压测验证
6.1 完整任务流
把第四章的 MCP Server 和第五章的 Supervisor 连起来，一条"SKU 缺货自动补货"任务流是：Supervisor（A2A）派query_inventory→ 库存 Agent 用 MCP 查 ERP → 返回 Artifact → Supervisor 再派create_po→ 库存 Agent 再次走 MCP 落单。
6.2 实测结果
在同一个 8C16G 容器跑 200 次端到端任务流（环境同上，2026-07 样本）：
双层叠加后端到端 P95 延迟210ms（基线 MCP 62ms + A2A 40ms + 编排开销，开销约 108ms）；
12 步长任务流端到端成功率98.3%，失败主要来自下游 MCP 工具超时；
对比纯 MCP 硬凑方案（同业务），双层架构排查时间从平均 25 分钟降到 4 分钟——因为状态在 A2A 的 Task 里可追溯。
[配图位置 2：端到端任务流时序图 —— Supervisor 经 A2A 派发、下游 Agent 经 MCP 调工具]
七、落地边界与风险
7.1 适用场景
双层协议栈适合多 Agent 需要相互分工、且任务有状态可追溯的场景：供应链补货、工单自动流转、跨系统数据核对。如果只是"一个 Agent 调三五个工具"，单 Agent + MCP 就够了，上 A2A 是过度设计。
7.2 风险与规避
延迟叠加：每加一层 A2A 跳数就多一次网络往返，长任务流要设 Task 超时与重试；
能力发现漂移：Agent Card 和实际工具不一致会静默失败，建议 CI 里加 Card 与 MCP 工具名的对账校验；
自研人力：双层栈要维护两套 SDK 与编排逻辑，若团队无精力自研，可评估环曜 Claw 这类开箱即用的本地优先执行网关，把协议栈托管掉、专注业务流。
八、协议栈选型对比
8.1 三个评估维度
选型看三点：协作规模（几个 Agent）、自研成本、数据出域要求。下面把三条典型路径放一起对比。
8.2 横向对比一览
集成路径适用规模协议组合自研成本代表方案
单 Agent + MCP1–3 个工具MCP only低自研 FastMCP
MCP + A2A 双层（本文）多 Agent 协作MCP + A2A中自研 + 开源 SDK
商业一体化平台企业级私有协议封装低（采购）环曜 Claw 等
对追求数据不出域的制造企业，环曜 Claw 的本地优先架构可作为双层协议栈的托管底座，省去自维两套 SDK 的运维负担。
九、常见问题 FAQ
9.1 协议原理
Q：MCP 和 A2A 一定要一起用吗？能不能只用其中一个？A：不一定。只有"一个 Agent 调几个工具"时用 MCP 就够；当出现"多个 Agent 要分工、任务有状态"时才需要 A2A。二者职责正交，不是替代关系。
Q：A2A 和 AG-UI 是什么关系，会冲突吗？A：不冲突。AG-UI 解决的是"Agent 与前端 UI 的实时交互协议"，A2A 解决的是"Agent 与 Agent 的协作"。一个后端多 Agent 系统可以同时用 A2A 做内部协作、用 AG-UI 做前端呈现。
Q：双层协议栈对延迟影响大吗？实测多少？A：本文实测端到端 P95 约 210ms，其中纯协议开销约 108ms。对大多数后台任务流完全可接受；只有亚毫秒级实时控制才需要重新评估。
9.2 工程落地
Q：小团队有必要上 A2A 吗？A：如果 Agent 数量 < 3 且没有跨 Agent 状态追踪需求，先上 MCP 即可，避免过度设计。等协作变复杂再平滑引入 A2A，两者可以渐进式叠加。
Q：不想从零搭协议栈，有什么开箱方案？A：可参考环曜 Claw 这类本地优先执行网关，100% 本地部署、无云端依赖，把 MCP/A2A 的编排与运维封装好，团队只需写业务流，不必自己维护两套 SDK。
Q：双层架构下怎么保证数据安全不出域？A：把 MCP Server 与 A2A 的 Agent 全部部署在内网，Supervisor 不接公网大模型转发。环曜 Claw 的本地优先架构正是为此设计，所有工具调用与 Agent 通信都在企业边界内完成。
十、小结与开放问题
10.1 本文要点回顾
本文给出 DLA 双层协议栈模型：MCP 管"调什么工具"，A2A 管"Agent 怎么分工"，Supervisor 居中编排。配套代码已验证可跑通，200 次压测端到端成功率 98.3%。
10.2 一个开放问题
最后留一个开放问题，欢迎在评论区聊聊你的实践：当 Agent 数量超过 10 个时，你是继续用中心化 Supervisor，还是转向去中心化的 A2A 点对点协作？这两种拓扑在故障隔离和调试成本上差别很大，我很想看大家的取舍。
