## 概述 2026 年的多智能体领域，两场混战同时收尾。**协议层**上，2025 年初 Anthropic 的 MCP、Google 的 A2A、IBM 的 ACP 三足鼎立，到 2026 年已收敛为清晰的两层栈：MCP（模型↔工具）+ A2A（智能体↔智能体），ACP 于 2025 年 8 月并入 A2A，MCP 于 2025 年 12 月捐入 Linux 基金会旗下的 Agentic AI Foundation。**编排层**上，行业从"列举三四种拓扑"的混乱描述，沉淀出五种控制流各异的编排模式——Fan-out、Pipeline、Debate、Supervisor、Swarm——它们的区别不在图形长什么样，而在成本结构与失败形态。本文基于 2026 年的实测数据与官方资料，拆解这两层如何在生产中落地，以及为什么 Supervisor 成了 2026 的生产默认。 ## 双栈与五式：一图看懂 ```mermaid flowchart TB subgraph ORCH["编排层 · 控制流（与拓扑形状无关）"] direction LR O1[Fan-out 并行扇出] O2[Pipeline 串行链] O3[Debate 辩论裁决] O4[Supervisor 层级委托] O5[Swarm 动态交接] end subgraph A2AL["A2A 层 · 智能体↔智能体（协调）"] D[Agent Card 发现] T[Task 委托/状态] M[Message·Parts 多模态] end subgraph MCPL["MCP 层 · 模型↔工具（模型协议）"] S1[文件系统 Server] S2[数据库 Server] S3[外部 API Server] end ORCH --> A2AL --> MCPL ``` 关键认知：**MCP 是模型协议，不是智能体协议**。它扩展的是单个模型能看见、能操作的边界，不处理"两个自主智能体如何相互委托、协商、分工"。后者正是 A2A 要解决的。把两者混为一谈，是 2026 年生产事故的高发源头之一。 ## 协议战争如何收尾 把 2025–2026 的协议演进拉成一条时间线，"归一"的轨迹非常清楚： ```mermaid timeline title 三协议归两层栈 2024.11 : MCP 发布 (Anthropic) ~2M 下载 / 50 Server 2025.3 : ACP 发布 (IBM, BeeAI) 2025.4 : A2A 发布 (Google, 50+ 合作伙伴) 2025.6 : A2A 移交 Linux 基金会 (100+ 公司) 2025.8 : ACP 并入 A2A 2025.12 : MCP 捐入 Agentic AI Foundation 2026.3 : MCP 97M+ 下载 / 10000+ Server 2026 初 : A2A v1.0 生产就绪 ``` MCP 的渗透速度是理解整张图的基准：从 2024 年 11 月的约 200 万次 SDK 下载、50 个 Server，到 2026 年 3 月的 **9700 万+ 下载、10000+ Server**。期间每个里程碑都由巨头采用推动——OpenAI 接入后冲到约 2200 万、Microsoft Copilot Studio 后约 4500 万、AWS Bedrock 后约 6800 万。到 2026 年，Claude、ChatGPT、Copilot、Gemini 都原生说 MCP。2025 年 12 月，Anthropic 将 MCP 连同 OpenAI 的 AGENTS.md、Block 的 goose 一起捐给新成立的 Agentic AI Foundation（Linux 基金会下），标志着 MCP 从"某家公司的私有协议"变为"中立托管的标准层"。 A2A 的轨迹则是一部"合并史"。Google 在 2025 年 4 月推出 A2A，首批拉来 Atlassian、Salesforce、SAP、ServiceNow、PayPal、MongoDB 及 Accenture、Deloitte、McKinsey、PwC 等 50 余家伙伴；6 月转入 Linux 基金会 LF AI & Data，支持方扩到 100 多家。IBM 早在 3 月就发布了同属智能体间通信的 ACP，设计上别有特色——用标准 HTTP 约定（可用 cURL/Postman 直接调）、默认异步、刻意框架无关。但仅仅五个月后的 2025 年 8 月，IBM 宣布 ACP 并入 A2A，理由很务实：两个协议解决同一个问题，并存只会碎片化。IBM 的 BeeAI 平台随之迁移，通过 `A2AServer` 适配器合规、用 `A2AAgent` 类接入外部 A2A 智能体；DeepLearning.AI 上的 ACP 课程也在 2026 年 2 月由 A2A 课程取代。Kate Blair（IBM Research 主管）进入 A2A 技术指导委员会，与 Google、Microsoft、AWS、Cisco、Salesforce、ServiceNow、SAP 的代表共治。 **结论：智能体间通信协议的"战国"在 2025 年下半年就已结束，A2A 是唯一存活并进入生产的标准。** 仍在为"该押 ACP 还是 A2A"纠结的架构选型，本质是在打一场已经结束的仗。 ## A2A 的四个核心原语 A2A 的设计把"两个智能体协作"拆成最小可操作单元，值得逐条吃透： - **两类角色**：Client Agent（发起任务、沟通需求）与 Remote Agent（执行任务、回传结果）。这层角色划分让"调用方"与"被调用方"的边界在协议级固定下来，而不是靠每个应用自己约定。 - **Agent Card**：发布在 `/.well-known/agent.json` 的 JSON 元数据，声明能力、输入输出格式、鉴权要求。它本质是"智能体的服务注册表"——Client 读 Card 决定某个 Remote Agent 是否胜任当前任务。 - **Task**：A2A 的基本工作单元，支持长时运行与状态更新。当一个智能体可能要几分钟甚至几小时才能完成，Task 机制让"发起→轮询/流式状态→取回结果"成为协议内建行为，而非应用层补丁。 - **Message 与 Part**：承载实际数据交换，原生支持文本、结构化数据、文件乃至音视频流，反映了智能体世界远不止文本。 一个最小可用的 Agent Card 长这样： ```json { "name": "invoice-processor", "description": "从发票中抽取结构化数据并写入 ERP", "url": "https://agents.corp.example/invoice", "version": "1.0", "capabilities": { "streaming": true, "pushNotifications": true }, "authentication": { "schemes": ["oauth2"] }, "defaultInputModes": ["text", "file"], "defaultOutputModes": ["application/json"] } ``` A2A v1.0（2026 年初）补齐了生产所需的关键能力：gRPC 传输与原有 JSON-RPC、HTTP 三种绑定形式等价互认；Agent Card 用 **JWS + JSON 规范化签名**做身份加密验证（跨组织信任的前提）；原生多租户（单一端点安全托管多个智能体）；双向 TLS；以及异构环境互操作。同时保持对 v0.3 的向后兼容，允许智能体同时声明支持两版以平滑过渡。 ## MCP vs A2A：别把两层栈拍扁 最常见的认知错误是把 MCP 和 A2A 当成竞争关系。实测来看，二者是**正交的两层**： | 维度 | MCP | A2A | |------|-----|-----| | 全称 | Model Context Protocol | Agent2Agent | | 提出方 | Anthropic | Google | | 发布 | 2024.11 | 2025.4 | | 作用层 | 模型 ↔ 工具 | 智能体 ↔ 智能体 | | 协议本质 | 模型协议（扩展单模型边界） | 智能体协议（协调多个自主体） | | 典型动作 | 调工具、读资源 | 发现、委托、交换结果 | | 2026 状态 | 标准层（Linux 基金会托管） | v1.0 生产就绪 | 一句话判据：**如果一个动作是"模型去够一个工具"，用 MCP；如果是"一个智能体去找另一个智能体干活"，用 A2A。** 一个生产级多智能体系统通常同时跑这两层——上层 Supervisor 通过 A2A 委派任务给各专家智能体，每个专家再用 MCP 调自己的工具集。把 A2A 当 MCP 用（让智能体去发现"工具"），或把 MCP 当 A2A 用（让一个工具假装成智能体去协调别人），都会在鉴权、长任务状态、多模态这些点上踩坑。 ## 五式编排：按控制流分，不按图形分 编排层是 2026 年最容易混淆的地方。大量文章把模式归纳为"三种"——Pipeline、Supervisor、Swarm——把 Fan-out 折进 Pipeline、把 Debate 折进 Supervisor。这种折叠在博客里图省事，在生产里却会要命，因为**它掩盖了真正影响成本与失败形态的差异**。实测下来应分成五种： | 模式 | 控制流 | 协调开销 | 成本结构 | 典型失败形态 | 代表实现 | |------|--------|----------|----------|--------------|----------| | **Fan-out** | 分片并行 → 聚合 | 低 | 与分支数线性 | 部分支失败（需聚合策略） | Map-Reduce 类 | | **Pipeline** | 串行链式 | 低 | 与阶段数线性 | 级联污染（中段错则后段全错） | 工作流编排 | | **Debate** | 同题多答 + 裁决 | 高 | ≥2× 单模型 + 裁决 | 裁决偏袒、共识但同错 | Copilot Council | | **Supervisor** | 层级委托 + 综合 | 中 | 与子任务数线性 | 单点瓶颈、综合失真 | Claude Code / LangGraph | | **Swarm** | 动态对等交接 | 高 | 与 Agent 数近线性 | 交接丢上下文、漂移 | Kimi K2.6 | 两个关键辨析： **Fan-out 与 Pipeline 的协调开销一样低，但失败模式完全不同。** Pipeline 失败是级联——一个中段出错，会污染其后所有阶段的输入；Fan-out 失败是局部的——一条分支挂掉，剩下的还能用，问题转化为"如何聚合不完整结果"。这是两类截然不同的工程问题，把它们都叫"pipeline"会让排障方向跑偏。 **Debate 与 Supervisor 都有"裁判/协调者"，但成本结构相反。** Supervisor 把**不重叠的**子任务委派给专家并综合各自独立结果，成本随子任务数线性增长；Debate 把**同一个问题**发给多个智能体、等它们产生分歧、再裁决冲突，天生至少 2× 单模型成本，还没算裁决模型。把 Debate 当 Supervisor 用，账单会无声翻倍。 ## Supervisor：2026 的生产默认 五种模式里，**Supervisor 是 2026 年事实上的生产默认起点**。三个主流 SDK 不约而同地把它做成一等公民： - **Claude Agent SDK**（`@anthropic-ai/claude-agent-sdk`，2025 年 9 月 29 日由 `@anthropic-ai/claude-code` 更名而来）的 subagent 默认就是**一级深度**的 Supervisor——主智能体委派给若干专家子智能体，再综合结果。 - **LangGraph v1.0** 用 `create_agent`（取代旧的 `create_react_agent`）配合 `StateGraph`，原生支撑 Supervisor 拓扑。 - **OpenAI Agents SDK** 的 handoff 原语（接替已归档的 OpenAI Swarm）同样落在 Supervisor 形态。 一个典型 Supervisor 用 LangGraph v1.0 的写法： ```python from langgraph.graph import StateGraph, MessagesState, START, END from langgraph.prebuilt import create_agent researcher = create_agent(model, tools=[search], prompt="你是研究员") writer = create_agent(model, tools=[], prompt="你是写手") def supervisor(state): # 路由：决定下一步交给谁，或结束 goto = llm_router.invoke(...) # -> "researcher" | "writer" | "FINISH" return Command(goto=goto) g = StateGraph(MessagesState) g.add_node("supervisor", supervisor) g.add_node("researcher", researcher) g.add_node("writer", writer) g.add_edge(START, "supervisor") g.add_edge("researcher", "supervisor") g.add_edge("writer", "supervisor") app = g.compile() ``` 为什么 Supervisor 胜出？因为它在"可控"与"可扩展"间取得平衡：单一协调点让状态、可观测性、人在回路中断都好实现；不重叠的子任务委派让成本随任务数（而非视角数）线性增长。对"编码 + 研究 + 评审"这类跨域组合，Supervisor 几乎总是对的起点，再视需要叠加 Fan-out 扩展或 Swarm 规模。用 OpenAI Agents SDK 表达同样结构： ```python from agents import Agent, Runner researcher = Agent(name="Researcher", handoff_description="负责资料检索", tools=[...]) writer = Agent(name="Writer", handoff_description="负责成稿", tools=[...]) triage = Agent(name="Triage", instructions="按需交接给专家智能体", handoffs=[researcher, writer]) result = Runner.run_sync(triage, "写一份两页的 A2A 协议简报") ``` ## Debate 的真实代价：2.5× 税 Debate 不是"免费的质量增益"，它有明确价格标签。Microsoft 的 **Copilot Council** 就是 Debate 模式的标尺案例——并行跑 GPT-5.4 与 Claude，再用一个 Judge 模型裁决，整体成本约为单模型的 **2.5 倍**。两段式的 Critique 变体在此基础上再加约 20%。 这个 2.5× 不是偶发，而是 Debate 的结构性下限：同题多答 ≥ 2 个智能体 + 1 个裁决模型，三者都得跑。所以 Debate 的正确用法是"当赌注值得这个溢价时"——高风险决策、需要多视角对抗的评审、对单点幻觉零容忍的关键环节。把它当"默认质量开关"随手打开，月底的成本曲线会替你做出反面证词。值得注意的是，Debate 的失败形态也很特别：多个智能体可能"共识但同错"（共享同一盲区），此时 2.5× 的钱买到的只是虚假的确信。这也是为什么 Debate 的裁决模型应与被裁智能体异构（不同厂商/不同训练分布），以打破共享盲区。 ## Swarm 前沿：Kimi 的 300-Agent 量级 Swarm 是 2026 年的前沿模式，目前唯一把它做成"一等原生原语"并跑到极端规模的是 Kimi。**Kimi K2.5** 协调多达 100 个专家子智能体，并行执行约 1500 次工具调用，靠 Parallel-Agent 强化学习训练；**K2.6**（2026 年 4 月 20 日）把这个规模推到 **300 个智能体的 Swarm、单次自主编码长达 12 小时**。没有其他框架把 Swarm 作为原生原语支撑到这个量级——LangGraph 能"拼出"Swarm，Claude Agent SDK 在 Debate 和 Swarm 上则需要较多自写代码。 Swarm 的吸引力在于去中心化与上下文流体传递：智能体之间直接交接控制，而不是绕中央 Supervisor 路由。但它的代价也最重——协调开销随 Agent 数近线性上升、交接处易丢上下文、长时间自主运行易漂移。300-Agent、12 小时这种规模，已经进入"需要专门的可观测性、检查点、漂移检测"的工程范畴，远不是教程里三五个 Agent 的演示能代表的。 ## 框架 × 模式矩阵：先定模式，再选框架 2026 年选型顺序应当是**先确定你的主流模式，再选框架**，而不是反过来。把九大主流框架与五式编排交叉，呈现出清晰的能力分布： - **LangGraph v1.0** 最广——五种模式原生或可拼。 - **Claude Agent SDK** 在 Supervisor 与 Fan-out 上最锋利（一级 subagent、并行委派），Debate 与 Swarm 需自写代码。 - **OpenAI Agents SDK** 的 handoff 原语天然贴合 Supervisor 与轻量 Swarm。 - **CrewAI / AutoGen** 等偏角色协作，适合 Supervisor 与 Pipeline。 - 想要 Debate 与 Swarm 的工程化支撑，LangGraph 仍是稳妥底座。 API 细节上，2026 年生产代码必须用当前命名：`@anthropic-ai/claude-agent-sdk`（不是 `claude-code`）、LangGraph 的 `create_agent`（不是 `create_react_agent`）、OpenAI Agents SDK 的 handoff（不是已归档的 Swarm）。沿用旧包名，会在 2026 年内先撞 deprecation 警告。 ## 推荐方案：按场景押栈 - **跨域组合（编码/研究/评审）**：双层栈 + Supervisor。上层 Supervisor 用 A2A 委派，每个专家用 MCP 调工具。Claude Agent SDK 或 LangGraph 起步。 - **大规模同构并行（批量处理/检索增强）**：Fan-out。协调开销低、失败局部可聚合，是最划算的"加机器换吞吐"模式。 - **高风险关键决策（合规/医疗/法律初审）**：Debate，且裁决模型与被裁模型异构。接受 2.5× 成本作为"对抗单点幻觉"的保险费。 - **长时自主编码/探索**：Swarm，但前提是已具备检查点、漂移检测、取消语义等长跑基建。Kimi 的实践是目前的天花板参考。 - **跨组织/跨厂商协作**：必须以 A2A 为底——这是它唯一解决的问题。MCP 无法替代。 - **纯单智能体增强工具集**：只需 MCP，不必引入 A2A 的协调复杂度。 一句话收束：2026 年的多智能体不再是"还能不能用"的问题，而是"协议层选 MCP+A2A、编排层按控制流选五式之一"的工程选择题。协议的仗打完了，剩下的功夫在编排的取舍与长跑的稳定性上。 ## 参考来源 1. [MCP vs A2A vs ACP: How Three Rival Agent Protocols Became a Two-Layer Stack](https://agentmarketcap.ai/blog/2026/04/05/mcp-vs-a2a-vs-acp-agent-communication-standards) — 三协议（MCP/A2A/ACP）如何收敛为两层栈，含 MCP 下载量增长与 ACP 并入 A2A 的时间线。 2. [Multi-Agent Orchestration: 5 Patterns That Work in 2026](https://www.digitalapplied.com/blog/multi-agent-orchestration-5-patterns-that-work) — 五种编排模式（Fan-out/Pipeline/Debate/Supervisor/Swarm）的区分、成本结构与失败形态，含 Copilot Council 与 Kimi K2.6 数据。 3. [Google A2A 官方仓库](https://github.com/google/A2A) — Agent Card、Task、Message 原语与 v1.0 规范的权威来源。 4. [The Agent Protocol Stack: Why MCP + A2A + A2UI Is the TCP/IP Moment](https://subhadipmitra.com/blog/2026/agent-protocol-stack/) — 把 MCP（agent-to-tool）与 A2A（agent-to-agent）视为正交两层的分层论述。 5. [MCP and A2A Protocols in 2026: The Standardization Layer](https://skillgen.io/mcp-a2a-protocols-standardization-2026) — MCP 捐入 Agentic AI Foundation、A2A v1.0 生产就绪的标准化进程分析。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。