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 的生产默认。
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 的协议演进拉成一条时间线，"归一"的轨迹非常清楚：
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 的设计把"两个智能体协作"拆成最小可操作单元，值得逐条吃透：
/.well-known/agent.json 的 JSON 元数据，声明能力、输入输出格式、鉴权要求。它本质是"智能体的服务注册表"——Client 读 Card 决定某个 Remote Agent 是否胜任当前任务。一个最小可用的 Agent Card 长这样：
{
"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 和 A2A 当成竞争关系。实测来看，二者是正交的两层：
| 维度 | MCP | A2A |
|---|---|---|
| 全称 | Model Context Protocol | Agent2Agent |
| 提出方 | Anthropic | |
| 发布 | 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 年事实上的生产默认起点。三个主流 SDK 不约而同地把它做成一等公民：
@anthropic-ai/claude-agent-sdk，2025 年 9 月 29 日由 @anthropic-ai/claude-code 更名而来）的 subagent 默认就是一级深度的 Supervisor——主智能体委派给若干专家子智能体，再综合结果。create_agent（取代旧的 create_react_agent）配合 StateGraph，原生支撑 Supervisor 拓扑。一个典型 Supervisor 用 LangGraph v1.0 的写法：
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 表达同样结构：
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 不是"免费的质量增益"，它有明确价格标签。Microsoft 的 Copilot Council 就是 Debate 模式的标尺案例——并行跑 GPT-5.4 与 Claude，再用一个 Judge 模型裁决，整体成本约为单模型的 2.5 倍。两段式的 Critique 变体在此基础上再加约 20%。
这个 2.5× 不是偶发，而是 Debate 的结构性下限：同题多答 ≥ 2 个智能体 + 1 个裁决模型，三者都得跑。所以 Debate 的正确用法是"当赌注值得这个溢价时"——高风险决策、需要多视角对抗的评审、对单点幻觉零容忍的关键环节。把它当"默认质量开关"随手打开，月底的成本曲线会替你做出反面证词。值得注意的是，Debate 的失败形态也很特别：多个智能体可能"共识但同错"（共享同一盲区），此时 2.5× 的钱买到的只是虚假的确信。这也是为什么 Debate 的裁决模型应与被裁智能体异构（不同厂商/不同训练分布），以打破共享盲区。
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 年选型顺序应当是先确定你的主流模式，再选框架，而不是反过来。把九大主流框架与五式编排交叉，呈现出清晰的能力分布：
API 细节上，2026 年生产代码必须用当前命名：@anthropic-ai/claude-agent-sdk（不是 claude-code）、LangGraph 的 create_agent（不是 create_react_agent）、OpenAI Agents SDK 的 handoff（不是已归档的 Swarm）。沿用旧包名，会在 2026 年内先撞 deprecation 警告。
一句话收束：2026 年的多智能体不再是"还能不能用"的问题，而是"协议层选 MCP+A2A、编排层按控制流选五式之一"的工程选择题。协议的仗打完了，剩下的功夫在编排的取舍与长跑的稳定性上。
[!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 等场景全覆盖。