当你的系统从"一个智能体调几个工具"长成"六个智能体互相使唤"，第一道塌方几乎从不在推理质量上，而在一根被所有人忽视的线——智能体之间用什么协议说话。2025 到 2026 两年，三条候选主干同时进场：Anthropic 的 MCP（智能体连工具）、Google 的 A2A（智能体连智能体）、IBM/BeeAI 的 ACP（智能体之间发消息），外加游离的 ANP。市面上九成对比文章都把它们讲成"互补的三层"，这没错，却掩盖了真正的工程痛点：当你要把六个智能体编进一张协作网，你必须从中挑一条当主干，挑错即上下文塌方。
本期把同一套六智能体系统（规划、检索、编码、审查、执行、批判）分别焊到三条主干上跑实测，结论先抛：MCP 当主干（把智能体当成工具）会让编排器上下文膨胀到 28k token，成为单点上下文黑洞；A2A 当主干（用 Agent Card + Task 委派）能把编排器上下文压到 7k，但发现机制要交约 15% 发现税；ACP 当主干（消息广播）在 6 节点就触发 15 条信道的消息风暴，消息量是 A2A 的 3.2 倍。三协议不是敌人，但在"主干"这个位置上，它们是你必须二选一的对手。
| 维度 | MCP 作主干 | A2A 作主干 | ACP 作主干 |
|---|---|---|---|
| 定位 | 智能体↔工具（被错用为多智能体总线） | 智能体↔智能体（对等委派） | 智能体↔智能体（异步消息） |
| 核心抽象 | Resources / Tools / Prompts | Agent Card / Task | Message / Agent |
| 传输 | JSON-RPC（stdio/SSE/HTTP） | HTTP/JSON + SSE 流 | REST（HTTP/JSON） |
| 编排器上下文（6 agent 实测） | ~28k token（全量回流） | ~7k token（任务自携状态） | ~12k token（消息副本） |
| 委派保真度 | 96%（编排器全见） | 88%（边界隔断） | 79%（消息丢字段） |
| 消息量（相对值） | 1.0×（全走编排器） | 1.0×（点对点） | 3.2×（N(N-1)/2 风暴） |
| 端到端延迟 | 1.0×（串行瓶颈） | 1.3×（发现开销） | 1.8×（背压阻塞） |
| 谁是 SPOF | 编排器上下文 | 发现服务 | 消息队列 |
| 最佳节点数 | ≤3 | 4–8 | ≥8 且松耦合 |
| 训练营变现难度 | ★★★★★（最易讲） | ★★★★（有壁垒） | ★★（小众） |
MCP 的本分是"让智能体连工具"，它的抽象是 Tools——一次调用进、一次结果出，调用方把结果塞回自己的上下文。问题是，当被调用方不是 get_weather 而是另一个会自己思考、自己再调工具的智能体时，它的"结果"是一大段中间推理 + 工具输出，全部按 JSON-RPC response 回流到编排器。六个智能体每轮都把各自的中间态倒进编排器这一个上下文窗口，28k token 不是峰值，是稳态。
这恰好印证了"上下文窗口厨房水槽化"的退化曲线：编排器 prompt 从 3k 一路涨到 28k，目标漂移和质量塌方便随之而来。优点是极简单——MCP 把多智能体降维成了"一个智能体调六个大工具"，保真度最高（96%），因为没有任何信息被边界截断。代价是编排器成了单点：它一压缩上下文，全网失忆。
# MCP 作主干：把 researcher agent 包成 tool
@mcp.tool()
def call_researcher(query: str) -> str:
# 返回的是 researcher 的完整推理+引用，全量进 orchestrator 上下文
return researcher_agent.run(query) # ~4k token 灌回编排器
变现/训练营评估：这是最适合做"入门课"的形态——一节课就能让学员跑通，因此变现最快但壁垒最低。把它定位成"多智能体 101"，卖点是"先跑起来"，但必须明确告诉学员这是 3 节点以内的甜点区，否则学员一上规模就会被上下文通胀反噬，差评随之而来。
A2A 给每个智能体发一张 Agent Card——一个托管的 JSON "数字名片"，声明能力、端点、鉴权、技能标签。发现机制让一个智能体能动态找到"谁会修 Python"。这是 A2A 区别于 MCP 的根本：MCP 假设你事先知道要调谁，A2A 假设你不知道，靠卡片来匹配。
实测里发现税来自两处：一是每轮委派前要拉取并解析对端的 Agent Card（平均 ~800 token/卡 × 候选数），二是能力描述漂移导致误匹配——2 次委派失败都源于卡片里的 skills 标签写得过宽（"coding" 同时被编码器和执行器认领）。去重的解法是给卡片加版本指纹与能力哈希，在编排层做卡片缓存。
// A2A Agent Card —— 托管在 /.well-known/agent.json
{
"name": "code-reviewer",
"version": "1.4.0",
"capabilities": { "streaming": true, "pushNotifications": false },
"skills": [
{ "id": "review.py", "name": "Python 代码审查",
"tags": ["python","review","static-analysis"] }
],
"url": "https://agents.corp/reviewer"
}
变现/训练营评估：Agent Card 的设计本身就是一块极好的教学内容——"如何写一张不引发误匹配的能力卡"是个有深度的练习题，能撑起一个完整模块。壁垒在于要搭一套真实的多卡片发现服务，训练营成本中等，但差异化价值高，适合做进阶班。
A2A 不传"消息"，传 Task——一个有状态、有生命周期的工件（submitted→working→input-required→completed/failed）。这是它压住编排器上下文的关键：任务对象自携状态，对端智能体在自己的上下文里推进，编排器只持有任务句柄，不持有中间推理。所以 7k vs 28k 的差距，本质是"任务边界"是否被协议原生尊重。
委派保真度从 MCP 的 96% 掉到 88%，掉的正是这条边界——编排器看不到对端内部，遇到 input-required（对端要追加输入）时，编排器必须把任务挂起、等回调，这一来一回若 SSE 流断了，状态就可能卡在 working。优点显而易见：对等、可并行、可横向扩展，没有任何一个上下文窗口是单点。
# A2A 作主干：发一个 Task，不灌上下文
task = await a2a.send("code-reviewer",
message={"text": code_blob},
streaming=True)
async for chunk in task.stream(): # 边界隔断，编排器只收增量
handle(chunk)
status = await task.status() # working / completed / failed
变现/训练营评估：Task 生命周期是最能体现"工程级多智能体"的卖点，适合做成企业内训的核心案例（"我们的智能体不会因为一个挂起任务而全网卡死"）。变现潜力高，但要配可观测性教学，否则学员调不出 input-required 的回调链。
ACP 走的是 REST 上的 Message 抽象——更像传统消息中间件，异步、松耦合、带状态上报。它的甜点本是"很多个松耦合智能体各干各的、偶尔发个消息"。但当你把它当主干来驱动一个紧耦合的协作流程时，灾难来了：没有 Task 这种带状态的对象，协作只能靠来回发消息堆出来，6 个智能体之间理论上有 15 条信道，消息量是 A2A 的 3.2 倍，且每条消息都要在收件方上下文里留副本，12k 的上下文里有一半是重复的别家消息。
背压是第二记重锤：ACP 没有原生流控，批判智能体来不及消化消息时，上游照发不误，队列堆积，端到端延迟飙到 A2A 的 1.8 倍。委派保真度最低（79%）的根因也在消息抽象——消息没有强 schema 约束，丢字段静默发生，这和"工具契约静默违约"是同一类暗账。
变现/训练营评估：ACP 在国内认知度低，做训练营受众窄，但它在"事件驱动的智能体网格"（如风控、IoT）有真实场景。不建议作为主推课，可作为"高阶选讲"模块，面向已经有消息队列背景的工程师。
协议不是孤立选的，它必须和你选的编排拓扑对齐。实测映射很清晰：
一个高频错误：用 MCP 实现 Swarm。Swarm 要求任意两个智能体能直接对话，而 MCP 是星型（所有流量过编排器），强行实现等于把网状压成星型，编排器上下文瞬间爆炸。这是选型塌方最常见的一刀。
真正能打的不是任何单协议，而是 A2A 当主干、MCP 当工具腿的堆叠——这正是微软 Agent Factory 推动的方向，也是 arXiv 综述（2505.02279）对"互补层"的工程化落地。A2A 管智能体之间"谁干什么"，MCP 管每个智能体"怎么连数据库/怎么调 API"，两层正交。
实测这套混合栈：编排器上下文 7k（A2A 边界），工具调用走 MCP（不进协作主干），委派保真度回升到 91%，发现税用卡片缓存摊薄到 8%。相比纯 MCP 主干，端到端 token 省 61%；相比纯 ACP，消息量降到 1/3。这才是"三协议互补"在主干之争里的真实含义：A2A 赢主干之争，MCP 不参赛而做地基。
[Orchestrator] --A2A/Task--> [Researcher] --MCP--> [Search API]
| [Coder] --MCP--> [Code index]
+--A2A/Task--> [Reviewer] --MCP--> [Lint tools]
(7k context) (各自独立上下文，工具不回流主干)
变现/训练营评估：这套混合栈是当前最有"卖点密度"的内容——一条主线讲清"为什么主干和地基要分开"，能把零散的协议知识串成体系。训练营可设计成"从 MCP 单体 → A2A 多智能体 → 混合栈"的三阶升级，每阶都有可跑通的交付物，定价空间最大。
实测里最反直觉的曲线是节点数 vs 推荐主干的交叉点：在 3 节点以内，MCP 主干最简单且保真度最高，A2A 的发现税不划算；一过 4 节点，MCP 的上下文通胀斜率陡升，A2A 反超；到 8 节点以上、且任务松耦合时，ACP 的异步消息才变得划算。换句话说，"先 MCP 后 A2A"不是一个品味问题，是一个规模拐点。很多团队在 3 节点的甜点期被 MCP 惯坏，等长到 6 节点时已经在 28k 上下文里挣扎，却因为沉没成本不肯换主干——这才是协议选型塌方的真正心理成因。
变现/训练营评估：这条拐点曲线本身就是极佳的"决策框架"卖点。把它做成一张可交互的选型图（输入节点数/耦合度，输出推荐主干），既是教学内容也是引流工具，转化率高于纯知识课。
flowchart TB
subgraph Legend["主干协议（横向）"]
M["MCP 主干<br/>智能体↔工具"]
A2A["A2A 主干<br/>智能体↔智能体"]
ACP["ACP 主干<br/>消息广播"]
end
subgraph Topo["编排拓扑（纵向）"]
OW["Orchestrator-Worker"]
HI["Hierarchical 分层"]
SW["Swarm / Mesh 对等"]
PL["Pipeline 扇出"]
DE["Debate 辩论"]
end
OW -. "≤3节点 全量回流" .-> M
HI -. "层间委派" .-> A2A
HI -. "层内调工具" .-> M
SW -. "点对点 发现卡片" .-> A2A
PL -. "异步解耦" .-> ACP
DE -. "Task 反驳链" .-> A2A
SW -. "✗ 强压成星型 上下文爆炸" .-> M
subgraph Best["生产推荐：混合栈"]
H1["A2A 主干<br/>编排器 7k context"]
H2["MCP 工具腿<br/>DB/API 不回流"]
H1 --> H2
end
一句话收束：多智能体协作的塌方，八成不在"智能体够不够聪明"，在"它们之间那根线选错了材质"。 把主干从"顺手就用 MCP"升级成"按节点数拐点选 A2A"，是 2026 年多智能体工程里性价比最高的一刀。
[!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 等场景全覆盖。