互操作协议概览：MCP、A2A 与协议层演进
前置知识
一句话定义
MCP（Model Context Protocol）标准化「智能体 ↔ 工具与数据」的垂直连接，A2A（Agent2Agent）标准化「智能体 ↔ 智能体」的水平协作；两者共同把多智能体系统从「框架内私有约定」推向跨厂商、跨组织的开放互操作。
直观类比
MCP 是 USB-C：不管什么品牌的设备（工具），插上就能被电脑（智能体）用，不用为每个设备写专属驱动。A2A 是公司间的商务接口：两家公司不必开放内部组织架构，只要约定报价单（能力名片）与订单流程（任务生命周期）就能合作。
为什么重要
没有协议层时，每个框架的工具接入是私有的（LangChain 的 Tool 与 AutoGen 的函数注册互不通用），智能体间协作被锁死在同一框架内。MCP 把 N 个智能体 × M 个工具的 N×M 适配压缩为 N+M 个协议实现；A2A 则让不同厂商、不同框架的智能体可以互认能力、互派任务——这是把 MAS 从「单机应用」变成「网络生态」的前提，也是 1990 年代 KQML/FIPA 未竟之事的当代重试（kp-003 的历史回声）。
前置知识
kp-012（消息与结构化输出——协议是跨组织边界的消息契约）。
核心概念
MCP（Anthropic，2024 年开源）：基于 JSON-RPC 2.0 的协议，三方角色——宿主（Host，智能体应用）、客户端（Client，宿主内的连接器）、服务器（Server，能力提供方）；三类原语——Tools（可调用函数）、Resources（可读取数据）、Prompts（可复用提示模板）。解决「智能体如何安全、统一地发现并调用外部工具与数据」。
A2A（Google 发起，2025 年开源并捐入 Linux 基金会）：核心概念——Agent Card（智能体能力自述名片，声明能做什么、如何联系）、Task（有生命周期的任务对象：提交、working、完成、失败）、支持长时任务与流式更新（SSE）、支持多模态载荷。设计上强调「不透明协作」：调用方只看能力与任务状态，不侵入对方内部提示与记忆。解决「异构智能体之间如何发现、委派与跟踪任务」。
原理与机制：两条正交的轴
两协议解决的是正交问题，组合而非竞争：
| 维度 | MCP | A2A |
|---|---|---|
| 连接方向 | 垂直：智能体↔工具/数据 | 水平：智能体↔智能体 |
| 解决的痛点 | N×M 工具适配爆炸 | 跨框架/厂商的协作孤岛 |
| 核心抽象 | Tools / Resources / Prompts | Agent Card / Task 生命周期 |
| 协作假设 | 工具是被动的、无状态的 | 对方是自主的、可能长时运行 |
| 典型场景 | 智能体接数据库、浏览器、内部 API | 客户端智能体把法务子任务派给外部法务智能体 |
一个典型组合：你的主管智能体通过 MCP 连接自家工具箱，遇到超出能力的子任务时，通过 A2A 找到外部智能体的 Agent Card，创建 Task 委派并轮询/订阅进度。选型含义：框架内协作（同进程、共享状态）不需要 A2A；跨信任边界协作才需要——协议自带安全边界含义，跨边界的每次委派都是权限与数据外泄面的扩张（kp-026 的治理议题）。
常见误区
- 误区一：MCP 与 A2A 是竞争关系。 正交互补：一个管工具接入，一个管智能体互联；
- 误区二：上了协议就解决了协作质量。 协议只保证「说得通」，不保证「说得对」——交接包质量（kp-012）、验收与防护（kp-022）依旧全在你；
- 误区三：单机系统也该上 A2A。 同进程的智能体协作用函数调用或消息即可，引入跨网络协议纯属开销。
实例或案例
企业内「差旅助手」：通过 MCP 接入机票、日历、报销三个内部系统（各封装为一个 MCP Server，员工端 Host 一次接入全员复用）；行程中遇签证材料问题，通过 A2A 发现公司合作的法务智能体（读取其 Agent Card 确认能力与鉴权要求），创建签证咨询 Task 并流式接收补件清单。
图示
┌─────────── 你的智能体(Host) ───────────┐
│ │ │ │ │
MCP│ MCP│ MCP│ │A2A
▼ ▼ ▼ ▼
[数据库] [浏览器] [内部API] [外部法务智能体]
Server Server Server (Agent Card / Task)
└── 垂直: 统一工具接入 ──┘ └── 水平: 跨边界协作 ──┘与其他知识点的关系
本知识点是 kp-003「通信语言标准化」脉络的当代续章；协议层的扩张直接改变 kp-029 前沿生态的形态；跨边界委派的安全治理见 kp-026。
自测题
- MCP 的三方角色与三类原语？
要点：Host/Client/Server；Tools/Resources/Prompts。
- A2A 为什么强调「不透明协作」？带来什么权衡？
要点：保护各方内部实现与记忆隐私、只通过能力名片与任务对象交互；权衡是可观测性下降，审计只能依赖任务状态与凭证。
- 判断：同一框架内两个智能体协作需要 A2A 吗？
要点：不需要——A2A 面向跨信任边界；框架内用消息/共享状态即可（kp-012/kp-013）。
延伸阅读
MCP 与 A2A 的官方规范文档（以名称检索即可获得最新版本）；KQML/FIPA ACL 的历史教训见 kp-003。