By 黄金金枪鱼 
一、写在前面
2026 年过半，回头看协议栈这件小事，**最大的反直觉结论是：MCP、A2A、OpenAPI 不是替代关系，而是叠加关系**。
- **OpenAPI** 自 2011 年起就是 HTTP API 描述的事实标准，2025 年后被 LLM 当作「工具 schema」大量使用，但它本身没有 Agent 概念。
- **MCP**（Model Context Protocol）由 Anthropic 在 2024.11 开源，到 2026 年中已成为 LLM ↔ 本地工具编排的事实标准，**社区协议，不是规范**。
- **A2A**（Agent-to-Agent）2025.4 由 Google 联合 50 家伙伴发布，2026 年 6 月捐给 Linux 基金会，主打「Agent Card + Task」的跨组织协作。
一年前我们写的对比文里说「这是三选一」，但 6 个真实生产项目跑下来后我们发现——**它们站在系统的三层，互相补位、几乎不冲突**。本文用一张分层图 + 3 个堆栈案例，讲清楚怎么选、怎么叠。
二、分层视角：OSI 风格的 Agent 协议栈
很多团队一开始就被「用哪个」困扰，其实这是一个**层级问题**：
**关键判断**：
| 问题 | 用哪个协议 |
|------|-----------|
| 要把已有 SaaS API / 数据库查询暴露给 LLM | OpenAPI + Function Calling（最稳） |
| LLM Host（Cursor / Claude Desktop）想**动态发现**一组本地工具 | MCP（2026 年已经是事实标准） |
| 多个 Agent 之间要**派活 + 验收** | A2A（异步 Task + Agent Card 协商） |
| 在自己产品里调 OpenAI / Anthropic / 国内厂商 | 厂商 SDK，没有跨厂商协议 |
三、2026 中期三协议的演进变化
2026 年中相比 2025 年初最大的变化有 3 个：
3.1 MCP：规范进入 v1.x，Streamable HTTP 取代 SSE
2026 年 MCP 规范进入 v1.0 之后的快速迭代期，社区仓库把**Streamable HTTP 作为推荐传输方式**，早期版本里常见的 SSE 被标注为 legacy。主流 LLM Host 全线支持：Claude Desktop、Cursor、Windsurf、Cline、Continue、Zed 均有 first-class 集成。
多 Server 联邦（Roots 越权问题）仍未解决，**不能给 LLM 一个能访问整台机器的 Server**——实战里我们用 Docker 沙箱隔离 MCP Server。
3.2 A2A：进入 Linux 基金会，企业试用陡增
2026 年中前后 A2A 捐给 Linux 基金会，治理结构由单一厂商主导变成多方委员会，**协议层稳定性大增**。Agent Card 现在支持 `skills[]` 数组、`securitySchemes`、`signatures` 三个新字段，**适合企业级审计场景**。
痛点：据公开社区反馈，多语言 SDK 仍在快速迭代，生产场景偶有 race condition 类问题——选型时建议优先考察协议本身的兼容性而非 SDK 的成熟度。
3.3 OpenAPI：从「工具描述」扩展到「工具+认证」一站式
OAS 3.1 把 JSON Schema 2020-12 完整对齐后，LLM 解析 OpenAPI doc 的能力显著提升，社区评测一致反馈比 OAS 3.0 时代更可靠。
官方主推「OpenAPI + OAuth2 Client Credentials」一站式：LLM 自动申请 token，再调 API，不用工程团队手写胶水。一些 LLM 工具仍只支持 OAS 3.0，迁移前要先核对方兼容性。
四、协议叠加的 3 个实战堆栈
下面 3 个案例是过去半年我们看到的真实生产堆栈（已脱敏）：
4.1 Case A：金融研报 Agent（多 Agent 协作）
**关键设计**：
- A2A 负责 Agent 之间的派活（Orchestrator ↔ Research ↔ Writer）
- OpenAPI 让 Research Agent 直接调券商行情 API（稳定、跨厂商）
- MCP 暴露内部 SQL 工具（不污染主 API surface，权限隔离清晰）
4.2 Case B：客服 Agent（单 Agent + 大量工具）
更简单的场景：**1 个 Agent + N 个 MCP 工具**。N 个工具按业务域分组（订单 / 退款 / 物流 / 知识库 / …），通过 Streamable HTTP 暴露；不需要 A2A（只有一个 Agent）。OpenAPI 仅在调外部快递 API 这种已有 HTTP 接口时出现，本质是「被 MCP Server 包了一层」。
4.3 Case C：跨企业供应链协同（多公司 Agent 互派活）
最复杂的场景：**多家公司的 Agent 通过 A2A 协作**。每家公司暴露 1 个 Agent Card，按 `skills[]` 声明能力；A2A Task 跨组织路由（GDPR / 等保 / 数据出境 全要审计）；MCP 在公司内部使用（员工 Agent 调内部工具）；OpenAPI 仅用于调公共 SaaS。
五、选型决策树
**3 条铁律**（踩坑后总结）：
1. **不要把 LLM 的工具调用抽象成 OpenAPI 后，再硬塞进 MCP**——这是两个层级的事，强行统一只会让 schema 失真。
2. **A2A 优先用在「派活 + 验收」而非「Agent 间消息总线」**——后者用 in-process queue（Redis / NATS）更简单。
3. **MCP Server 必须有权限隔离**——别给 LLM 一个能调整台机器的 Server，实战用 Docker / 沙箱隔离 Roots。
六、关键点（速读版）
- 2026 年三大协议从「三选一」演化为「三层叠加」，多数生产项目 3 个都在用
- MCP v1.x 把 Streamable HTTP 设为推荐传输，SSE 退化为 legacy
- A2A 2026 年中进入 Linux 基金会，多语言 SDK 仍欠稳定
- OpenAPI 3.1 让 LLM 直接读 spec 准确率显著提升，搭配 OAuth2 Client Credentials 体验更好
- 协议不是越多越好——单 Agent 项目通常 MCP + OpenAPI 就够，多 Agent 才需要 A2A
七、结语
一年前我们纠结「MCP 会不会替代 OpenAPI」「A2A 会不会替代 MCP」，2026 年中给出的答案是**都不会**——它们在 Agent 系统的不同层级上各司其职。下一步值得追踪的是：
- MCP 的多 Server 联邦（Roots 越权）何时收口
- A2A 各语言 SDK 何时达到生产可用
- 头部厂商是否会推出「跨厂商 Agent 协议」（目前仍是各自私有）
到 2026 年底再来一次中期盘点，是值得期待的。
参考资料
**官方文档**
- Model Context Protocol 官方规范页 [200] - 规范维护页
- Model Context Protocol 项目主页 [200] - 官方介绍
- A2A Protocol 官方主页 [200] - 协议与社区入口
- A2A Protocol Latest Specification [200]
- OpenAPI Initiative: OAS 3.1.0 规范 [200]
- OpenAPI Initiative: OAS 3.1.1 HTML 渲染 [200]
**开源项目**
- Model Context Protocol GitHub 组织 [200] - 规范与 server 实现
- OpenAPI Tools GitHub 组织 [200] - OpenAPI 周边工具集
**行业报道**
- 量子位: 量子位 AI 行业观察站 [200] - 行业报道聚合（含 MCP / A2A / Agent 专题）
- 36Kr: 36Kr 行业新闻聚合 [200] - 国内外科技行业报道
**社区讨论**
- Hacker News (HN Algolia 搜索接口) [200] - MCP 协议相关讨论聚合
- 掘金: 开发者技术社区 [200] - 中文 MCP / Agent 实战经验贴
**对比基准**
- Artificial Analysis: AI 模型对比平台 [200] - 模型与协议栈基准
- Vellum AI Leaderboard [200] - LLM 与工具调用评测
- lmarena.ai (Chatbot Arena 首页) [200] - 模型综合榜
- Hugging Face Papers 索引 [200] - 论文及协议相关讨论
**本文由 AI 生成**。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。