MCP 协议和 A2A 协议如何协同工作？请设计一个同时使用两者的多 Agent 系统架构
参考答案
**MCP 是 Agent 的”手”**，让 Agent 能操作工具和数据。
**A2A 是 Agent 的”嘴”**，让 Agent 之间能对话和协作。一个设计良好的多 Agent 系统，两个协议缺一不可。
协同模式是：每个 Agent 内部通过 MCP 协议连接它需要的工具和数据源，这是它的内部能力。对外通过 A2A 协议和其他 Agent 交互，接受任务委派、返回执行结果、协商工作分配。
就像公司里每个员工都有自己的工具和系统权限，这是 MCP；员工之间开会、派活、交付成果，这是 A2A。
拿一个”智能客服系统”来看具体架构：系统里有 3 个 Agent，前台接待 Agent 负责理解用户问题并路由，技术支持 Agent 负责解决技术问题，订单处理 Agent 负责处理订单操作。前台 Agent 通过 A2A 协议把用户请求分发给合适的后端 Agent，每个后端 Agent 内部通过 MCP 连接自己的工具，技术 Agent 连知识库和工单系统，订单 Agent 连订单数据库和物流 API。
扩展知识
请求流转的完整链路
用一个具体场景把两个协议的协同串起来：用户说”我的订单 #12345 一直没收到，能帮我查一下吗？如果确实有问题，帮我提个工单”。
1）前台 Agent 理解用户意图，判断需要订单处理 Agent 和技术支持 Agent 协作
2）前台 Agent 通过 A2A 协议给订单处理 Agent 创建一个 Task：”查询订单 #12345 的物流状态”
3）订单处理 Agent 收到 Task 后，内部通过 MCP 调用订单数据库 Server 查订单信息，再调用物流查询 Server 查物流状态
4）订单处理 Agent 通过 A2A 协议把结果返回给前台 Agent，Artifact 里包含物流信息
5）前台 Agent 发现物流确实异常，通过 A2A 协议给技术支持 Agent 创建另一个 Task：”为订单 #12345 创建物流异常工单”
6）技术支持 Agent 通过 MCP 调用工单系统 Server 创建工单，返回工单号
7）前台 Agent 整合两个 Agent 的结果，给用户一个完整的回答
整个过程中 A2A 负责 Agent 之间的任务分配和结果交换，MCP 负责每个 Agent 内部的工具调用，各司其职。
MCP 和 A2A 的核心区别
| 维度 | MCP | A2A |
|---|---|---|
| 解决的问题 | Agent 如何调用工具和数据 | Agent 之间如何对话协作 |
| 通信双方 | Agent ↔ 工具/数据源 | Agent ↔ Agent |
| 协议模型 | Client-Server，同步调用为主 | Task 驱动，支持异步长任务 |
| 核心概念 | Tool、Resource、Prompt | Agent Card、Task、Artifact |
| 发现机制 | MCP Server 列表配置 | Agent Card 注册与发现 |
| 典型场景 | 查数据库、调 API、读文件 | 任务委派、结果交换、多 Agent 编排 |
Agent Card 的设计
A2A 协议的一个关键设计是 Agent Card，相当于 Agent 的”名片”。每个 Agent 在注册中心发布自己的 Agent Card，里面声明自己能干什么、接受什么格式的输入、返回什么格式的输出。前台 Agent 在分发任务时，先查注册中心的 Agent Card，找到能力匹配的 Agent 再派活。
这个机制的好处是解耦。新增一个 Agent 只需要注册一张 Agent Card，前台 Agent 不用改代码就能自动发现并使用新能力。生产环境中 Agent Card 一般用 JSON 格式描述，包含 Agent 名称、能力描述、支持的 Task 类型、认证方式等字段。
设计中容易踩的坑
错误传播要想清楚。某个 Agent 通过 MCP 调用工具失败了，它需要通过 A2A 向请求方 Agent 报告失败，请求方 Agent 再决定是重试、换一个 Agent、还是直接告诉用户。整个错误链路必须清晰，不能某个 Agent 失败了就静默吞掉。
鉴权体系要端到端打通。用户的权限需要在 A2A 的 Task 中一路传递，确保下游 Agent 调 MCP 工具时用的是正确的权限级别。不能出现”用户没权限看 VIP 订单信息，但订单 Agent 因为自己有数据库完整权限就把信息返回了”这种越权问题。
不要过度设计。如果系统只有 1 个 Agent，MCP 就够了。只有确实需要多个 Agent 协作，才引入 A2A。协议是为了解决问题，不是为了堆技术栈。初期建议先用 MCP 跑通单 Agent 场景，等业务复杂度上来了再拆分 Agent 引入 A2A。
面试官追问
提问：如果某个下游 Agent 处理任务特别慢，比如要跑 5 分钟，前台 Agent 应该怎么处理？
回答：A2A 协议天然支持异步 Task。前台 Agent 给下游 Agent 创建 Task 后，不用一直阻塞等着，Task 会有状态流转，submitted → working → done。前台 Agent 可以先告诉用户”正在处理中”，然后通过轮询或者 SSE 监听 Task 状态变化。对用户侧可以用流式响应，先返回已经拿到的部分结果，等慢任务完成后再补充完整。超时兜底也得有，5 分钟还没完成就主动取消并告知用户。
提问：多个 Agent 之间通过 A2A 通信，怎么保证不出现循环调用？比如 A 调 B，B 又调回 A？
回答：最简单的办法是在 Task 里带一个调用链路追踪 ID 和调用深度计数器。每次 Agent 转发 Task 时深度 +1，超过阈值直接拒绝，一般设成 5 层就够了。更严格的做法是在编排层定义好 Agent 之间的调用拓扑，只允许有向无环的调用关系。生产环境中还要配合审计日志，一旦检测到环路调用就告警。
提问：A2A 协议里的 Agent Card 和微服务的服务注册有什么区别？
回答：形式上很像，都是在注册中心发布自己的能力描述，调用方通过注册中心发现可用服务。但 Agent Card 比服务注册多了”能力语义描述”这一层。微服务注册的是接口契约，精确到每个 API 的参数和返回值；Agent Card 描述的是 Agent 能处理什么类型的任务，用自然语言描述能力范围。前台 Agent 在路由时可以根据语义匹配来选择下游 Agent，灵活度比微服务的硬编码路由高很多，但也意味着路由准确性依赖 LLM 的理解能力。