MCP 与 A2A：工具接入与智能体互通
MCP 解决"应用怎么调用工具和数据"，而让"一个智能体找另一个智能体办事"是另一类问题。2025-04 Google 提出 Agent2Agent 协议（A2A），2025-06 起交由 Linux Foundation（AGNTCY 项目）治理。两者定位互补而非竞争，本章讲清边界与配合方式。
A2A 是什么
A2A 面向智能体之间的互操作：一个智能体发现另一个智能体的能力、用 JSON-RPC 发消息、把任务委派出去并跟踪其生命周期（进行中/完成/失败，结果可推送或轮询）。它关心的是"找谁办事、如何交接"，而不是"用什么工具干活"。协议细节以 A2A 官方规范为准。
agent card：让智能体被发现
每个 A2A 智能体用一份 agent card 声明自己是谁、能做什么、端点在哪，形如：
{
"name": "订单助手",
"description": "处理订单查询与售后",
"url": "https://example.com/a2a",
"version": "1.0.0",
"skills": [{ "id": "order-query", "name": "订单查询" }]
}
客户端智能体先拉取这张卡片判断对方能力是否匹配、如何对接；字段名与必填项随规范演进，以官方规范为准。
一次典型协作的流程
- 客户端智能体读取远程智能体的 agent card，确认能力匹配；
- 通过 JSON-RPC 创建任务，附上目标与必要上下文；
- 远程智能体执行任务——内部通常再用 MCP 调工具、读数据；
- 客户端跟踪任务状态（进行中/成功/失败），结果轮询或由对方推送；
- 任务完成，双方各自保留自己的工具链与数据边界。
与 MCP 的定位对比
| 维度 | MCP | A2A |
|---|---|---|
| 目标 | 应用 ↔ 工具/数据/资源 | 智能体 ↔ 智能体 |
| 参与者 | 宿主/客户端 + 服务器 | 客户端智能体 + 远程智能体 |
| 核心消息 | 工具调用、资源读写 | 任务创建与状态跟踪 |
| 描述能力 | 工具的 inputSchema | agent card |
| 类比 | 把能力做成"可调用 API" | 让团队之间"互相派活" |
| 一句话区分：MCP 让 AI 用得上你的工具，A2A 让 AI 找得到并接得上别的 AI。 |
两者并用是常见架构
2025-2026 年企业落地的典型形态是"多层混用"：底层用 MCP 把内部工具、数据库、知识库暴露给每个智能体；上层用 A2A 把这些智能体连成协作网络——A2A 负责派单与交接，接到任务的智能体再用 MCP 调工具干活。
应用 A ──A2A──► 应用 B（智能体）──MCP──► 数据库 / 文件 / 内部工具
对普通接入方而言：你只需要把工具暴露给 AI，用 MCP 就够了；只有当你要"让多个独立智能体互相协作、跨团队交付任务"时，才需要引入 A2A。
选型速断
- 要做工具/数据接入：MCP（本章教程主线）；
- 要做智能体间互操作、任务委派：A2A；
- 两者都出现：MCP 层与 A2A 层各司其职，互不替代。 演进很快，两家协议都在迭代：MCP 以 modelcontextprotocol.io 为准，A2A 以官方规范与 AGNTCY 项目资料为准。 小结：MCP 管"应用用工具"、A2A 管"智能体找智能体"，定位互补；常见架构是 A2A 负责智能体协作、MCP 负责给每个智能体接工具与数据，按需混用、以双方官方文档为准。