## 概述 多智能体系统真正的成本不在模型，而在"传话"。当智能体从一个变成一群，智能不会复合，开销却会复合——一次 2025 年 12 月覆盖 180 组配置的实测发现，协调开销（coordination overhead）在某些任务上可超过基线 token 消耗的 150%，意味着智能体之间互相"说话"烧掉的 token 比干活还多。本文把六种主流通信栈摆上同一张工作台实测：直接调用、自然语言信道、共享黑板、消息队列、结构化契约、A2A 协议。核心发现是一条无情的因果链——**传话即失真**：信道越像人话（自然语言），保真度越低、token 烧得越快；信道越像机器（直接调用、结构化契约），保真度越高、但耦合与刚性越强。没有免费的午餐，每一次跨智能体跳转都是一次"失真+收税"，选错信道，整条流水线就在传话里空转。 ## 六栈对比总表 | 通信栈 | 介质形态 | 保真度 | 序列化开销 | 典型 token 税 | 失真主因 | 适用规模 | 代表实现 | |--------|----------|--------|-----------|--------------|----------|----------|----------| | 直接调用 | 同进程函数参数 | ★★★★★ | 近零 | <5% | 无（强类型） | 单进程 2–5 体 | 自研编排 | | 自然语言信道 | 对话历史文本 | ★★ | 高 | 40–150% | 二次解读/幻觉 | 2–5 体辩论 | AutoGen/CrewAI/ChatDev | | 共享黑板 | 结构化状态表 | ★★★★ | 低 | 10–20% | 脏读/竞态 | 5–20 体协作 | bMAS/SE-Blackboard | | 消息队列 | 发布订阅事件 | ★★★★ | 中 | 15–30% | 乱序/背压 | 10–100 体流水线 | Kafka/Redis/AutoGen 0.4 | | 结构化契约 | Pydantic/JSON Schema | ★★★★☆ | 中 | 10–25% | schema 漂移 | 跨语言团队 | LangGraph/LangChain | | A2A 协议 | JSON-RPC over HTTP | ★★★☆ | 极高 | 200–1500% | HTTP 鉴权/序列化 | 跨厂商企业 | Google A2A/ACP/ANP | > 保真度衡量"上游意图经一次跳转后，下游实际接收到的精确程度"；token 税衡量"通信本身相对单体内执行多烧的比例"。后者引用了多份 2025–2026 协调开销实测的区间。 --- ## 深度分析：六栈逐一拆解 ### 一、直接调用栈——同进程传参，零失真但零可扩展 **架构原理。** 直接调用是最朴素的"通信"：智能体本质是一个函数，输出作为下一个函数的入参，全程在同一个进程、同一个内存空间完成。没有序列化、没有网络、没有中间格式——参数是什么类型，下游就拿到什么类型。这使它成为六栈里**唯一保真度可标定为 100% 的信道**，因为信息根本没有离开强类型系统。它的失真主因标注为"无"，意味着这是基准线（baseline），其余五栈都相对于它折损。 **代码片段。** ```python # 直接调用：函数参数即通信介质 def coder(task: Task) -> CodeArtifact: # 强类型契约 ... def reviewer(code: CodeArtifact) -> Review: ... code = coder(task) # 第一段 final = reviewer(code) # 第二段，参数原样透传 ``` **优缺点。** 优点是确定性最强、调试最容易、成本最低——没有"听不懂"的问题，断点一打到底。缺点是**零可扩展性**：所有智能体必须同语言、同进程、同部署，跨厂商、跨团队协作彻底无解。它也无法处理"需要等待外部事件"的场景。在多智能体语境下，直接调用更像是"伪多智能体"——名义上有分工，实则是分阶段函数。 **变现/训练营评估。** 变现价值低，因为客户买多智能体要的就是"分布式、可扩展、跨厂商"的幻觉，直接调用讲不出故事。但作为训练营的**第一课基准线**极有价值：先用直接调用跑通端到端，再逐步替换为其他信道，让学员肉眼看见"每换一次信道，token 涨多少、失真多多少"。这种"对照实验式"教学是付费课程的高复购点。 ### 二、自然语言信道栈——表达力天花板，保真度地板 **架构原理。** 这是当下最主流、也是最危险的信道。AutoGen、CrewAI、ChatDev 等"角色扮演式"框架的核心机制是：**把整个对话历史作为通信介质**。程序员智能体产出的内容以自然语言写进对话，审查员智能体再把这段话连同全部历史重新喂进上下文，"读"出意图后回应。表面上是协作，本质是"互相重新理解一遍"。这就是失真的根源——下游不是在"接收"上游的输出，而是在"重新解读"上游的输出，每一次跳转都过一次 LLM 的概率滤镜，幻觉、省略、跑题都有概率渗入。 **代码片段。** ```python # AutoGen 式自然语言信道：对话历史 = 通信总线 coder = AssistantAgent("coder", llm_config=cfg, system_message="你是资深程序员，只写代码") reviewer = AssistantAgent("reviewer", llm_config=cfg, system_message="你是审查员，挑出所有 bug") # initiate_chat 会把 coder 的产出以自然语言塞进 reviewer 的上下文 await coder.initiate_chat(reviewer, message="任务：实现二分查找。请审查我写的版本：...") ``` **优缺点。** 优点是表达力最强、最灵活——能辩论、能谈判、能处理模糊任务，搭原型极快。缺点集中且致命：**token 随轮次近似平方增长**（第 N 轮要重读前 N-1 轮全文），协调税最高（实测可达基线的 40–150%），且保真度地板级——审查员"以为"看到了代码，实际可能漏读一个函数。这正是为什么"错传即雪崩"会成为多智能体的头号失败模式。 **变现/训练营评估。** 这是**训练营最容易卖、也最容易翻车**的一栈。卖点是"两行代码搭起一个会吵架的团队"，对小白有奇效；翻车点是学员真上线后发现"三个智能体吵了 20 轮，烧了 8 块钱，结论是错的"。把它包装成"通信税可视化训练营"——让学员在第三课就被 token 账单震到——能顺理成章地推销后面五栈作为"省税方案"。 ### 三、共享黑板栈——token 最省，但竞态最阴 **架构原理。** 黑板（blackboard）是经典 AI 架构的现代复活。所有智能体不直接对话，而是读写一张共享的状态表（`spec` / `code` / `review` 等结构化字段）。每个智能体只读它需要的字段、只写它负责的字段。信息以**结构化数据**而非自然语言流动，下游无需"重新解读"，所以 token 税极低（10–20%）。2025 年的 bMAS 论文（arXiv 2507.01701）正是把这个思路搬进 LLM 时代，证明黑板的"动态、token 高效协调"特性在多智能体里反而成了优势——因为**通信不再是"说一遍整句话"，而是"改一个字段"**。 **代码片段。** ```python # 共享黑板：结构化字段即通信，智能体只读写自己负责的列 board: dict = {"spec": None, "code": None, "review": None} board["code"] = coder.run(board["spec"]) # 读 spec，写 code board["review"] = reviewer.run(board["code"]) # 读 code，写 review # reviewer 只看到 code 字段，不被 spec 的历史污染 ``` **优缺点。** 优点是 token 经济性仅次于直接调用，且天然解耦（智能体互不感知）、字段级权限清晰。缺点是**竞态条件**与**脏读**——若两个智能体并发写同一字段，最后写入者覆盖前者；若读取发生在写入完成前，下游拿到的是 `None`。这正是"共享即撕裂"的另一面：共享不是问题，**谁来同步**才是。需要锁、版本号或 CRDT 来兜底，复杂度被转移到了并发控制层。 **变现/训练营评估。** 适合做"高并发省税"进阶课。卖点很硬——同样三个智能体，黑板比自然语言信道省 60–80% 的 token，账单立竿见影。坑点在于并发控制教学成本高，小白容易写出死锁。建议把它定位为"中阶课"，前置一节并发基础。 ### 四、消息队列栈——解耦之王，背压暗坑 **架构原理。** 把智能体之间的通信从"直接喊话"改成"往主题（topic）里丢事件"——发布者不关心谁在听，订阅者不关心谁在说。AutoGen 0.4 的彻底重写正是走这条路：从 0.2 的"对话式"架构转向**事件驱动（event-driven）架构**，每个智能体订阅感兴趣的事件、产出新事件。这让它成为大规模流水线（10–100 体）的工程首选，可横向扩展、天然异步、故障隔离好（一个体挂了不阻塞整条链）。代价是失真主因从"听不懂"变成**"乱序、背压、丢消息"**——网络层的可靠性问题取代了语义层的理解问题。 **代码片段。** ```python # 事件驱动：智能体通过 broker 通信，互不感知 @broker.subscribe("code.ready") async def on_code(msg: Event): review = await reviewer.run(msg.payload) # 处理代码事件 await broker.publish("review.done", review) # 产出审查事件 @broker.subscribe("review.done") async def on_review(msg: Event): if msg.payload.approved: await broker.publish("merge.request", msg.payload.code) ``` **优缺点。** 优点是可扩展性极强、解耦彻底、能扛住单个智能体故障。缺点是**调试地狱**——事件链路长，一次失败要追 5 跳日志；背压（生产快于消费）会让队列堆积，长任务直接 OOM；幂等性必须显式保证，否则重试会导致重复执行。它把"传话失真"问题转化成了"分布式系统工程"问题——对工程团队是降维，对 AI 团队是升维。 **变现/训练营评估。** 这是**企业级落地课**的核心栈。客户最爱听"我们的智能体团队扛住了双十一"这种故事，而只有消息队列能讲这个故事。训练营可以把它包装成"从原型到生产"的关键一跳，配合可观测性（OpenTelemetry/事件溯源）一起卖，客单价能拉到最高。 ### 五、结构化契约栈——用 Schema 给传话立规矩 **架构原理。** 这一栈的精髓是把"通信"从模糊的消息升级为**带类型校验的契约**。上游智能体的产出必须符合一个 Pydantic 模型或 JSON Schema，下游拿到的是已被校验、已被类型化的对象，而不是一坨需要重新解读的文本。LangGraph、LangChain 的 Tool/Structured Output 机制本质都是这个路子。它不是独立的信道，而是**叠加在任意信道之上的保真层**——你可以用契约跑直接调用、跑队列、甚至跑 A2A。失真主因是**schema 漂移**：上游偷偷改了字段，下游没跟上，契约在运行时炸开。 **代码片段。** ```python from pydantic import BaseModel class CodeArtifact(BaseModel): # 通信契约，由 schema 保证结构 files: list[File] tests: list[Test] coverage: float @reviewer.tool def review(art: CodeArtifact) -> Review: # 入参已被校验，无需"理解" return Review(...) ``` **优缺点。** 优点是**显著抬高了保真度天花板**——校验失败即时暴露，而不是"审查员读了三遍才发现函数名拼错"。缺点是 schema 维护税：每改一次业务逻辑，契约、文档、下游都要同步，跨团队时这一步最容易扯皮。它治标不治本——能挡住结构错误，挡不住"字段都在、语义全错"。 **变现/训练营评估。** 变现点在于"可靠性工程"。很多企业卡在"智能体偶尔产出垃圾 JSON 导致整条链崩"，结构化契约是直接解药。可做成"多智能体可靠性专项"——契约 + 重试 + 校验三位一体，定位中高阶，面向已经在踩坑的团队，付费意愿强。 ### 六、A2A 协议栈——跨厂商通天塔，税也是最重的 **架构原理。** 2025–2026 年最大的变量是 A2A（Agent2Agent）协议——Google 主推的开放标准，让不同厂商、不同框架的智能体能跨 HTTP 互通，基于 JSON-RPC over HTTP/SSE，配套有 Agent Card（智能体名片）发现机制、任务生命周期管理。它与 Anthropic 的 MCP（模型上下文协议，解决"智能体如何接工具"）互补：MCP 是"智能体↔工具"，A2A 是"智能体↔智能体"。同期还有 ACP（IBM/Linux 基金会）、ANP 等竞争标准，2026 年被业内称为"协议战争"年。A2A 让多智能体第一次能**跨组织协作**，这是前五栈都做不到的——你公司的智能体可以调用我公司的智能体，像调用 API 一样。 **代码片段。** ```python # A2A：每个智能体是 HTTP 服务，通过 Agent Card 发现彼此 POST https://agent.acme.com/tasks/send { "jsonrpc": "2.0", "method": "tasks/send", "params": { "id": "task-123", "agentId": "https://reviewer.partner.com/agent.json", "message": { "role": "user", "parts": [{"text": "..."}] } } } # 响应经 SSE 流式回传，全程 JSON-RPC 序列化 + 鉴权 + TLS ``` **优缺点。** 优点是**互操作性天花板**——打破厂商锁定，是真正的"智能体互联网"基础设施，企业级集成刚需。缺点是**税也最重**：每次通信要过 HTTP 建连、TLS 握手、JSON-RPC 序列化、Agent Card 发现、鉴权校验，单跳延迟从毫秒级跳到百毫秒级，token 税可达 200–1500%（有实测称跨 HTTP 协调可放大至 15 倍 token）。它的失真不在语义，而在**网络不可靠**——超时、重试、部分失败全是分布式系统的老问题。 **变现/训练营评估。** 这是**2026 最热、也最虚**的一栈。热在于"协议战争"自带流量，每个企业都想搞跨厂商协作；虚在于绝大多数团队根本用不到跨组织，把简单内部协作硬套 A2A，等于用大炮打蚊子还自付炮弹钱。训练营可以讲，但必须诚实标注"仅当真有跨厂商需求时才值"——否则就是卖概念。 --- ## 通信栈架构与失真传导图 ```mermaid flowchart TB classDef high fill:#e8f5e9,stroke:#2e7d32 classDef mid fill:#fff8e1,stroke:#f57f17 classDef low fill:#ffebee,stroke:#c62828 subgraph Source["信息源（上游意图）"] A[真实意图 I₀] end subgraph Channels["六种通信信道"] C1[直接调用
保真100%
税<5%]:::high C2[自然语言信道
保真★
税40-150%]:::low C3[共享黑板
保真★★★★
税10-20%]:::mid C4[消息队列
保真★★★★
税15-30%]:::mid C5[结构化契约
保真★★★★☆
税10-25%]:::mid C6[A2A协议
保真★★★
税200-1500%]:::low end subgraph Sink["下游接收"] R1[I₁ ≈ I₀] R2[I₁ ≈ I₀ ⊕ 噪声] end A -->|强类型传参| C1 -->|零跳转| R1 A -->|对话历史重解读| C2 -->|幻觉/省略| R2 A -->|字段读写| C3 -->|脏读/竞态| R2 A -->|事件发布| C4 -->|乱序/背压| R2 A -->|Schema校验| C5 -->|漂移| R2 A -->|HTTP JSON-RPC| C6 -->|超时/序列化| R2 R2 -.失真累积.-> N["N 跳后 I_N = I₀ ⊕ Σ噪声
跳数越多，越远离原意"] ``` 图中绿色信道（直接调用）是唯一把意图近乎无损送达的；黄色信道（黑板/队列/契约）把失真问题转化为可工程化的并发与契约问题；红色信道（自然语言、A2A）失真与税都最重，但分别换来了"灵活性"和"互操作性"——这正是**传话即失真**命题的完整图景：每一次跳转，要么付语义税（听不懂），要么付工程税（同步难），要么付带宽税（序列化贵）。 --- ## 失真传导的量化推演 把六栈放进同一条 N 跳流水线（N=1…5），失真与成本的曲线分野极其清晰： | 跳数 | 直接调用累计 token 税 | 自然语言累计税 | 黑板累计税 | A2A 累计税 | |------|---------------------|---------------|-----------|------------| | 1 | ~5% | ~50% | ~15% | ~250% | | 3 | ~15% | ~200% | ~45% | ~900% | | 5 | ~25% | ~450% | ~75% | ~1500%+ | > 自然语言列的平方增长源于"每跳重读全部历史"；A2A 列的线性陡增源于"每跳重付全套 HTTP 序列化与鉴权"。这正是为什么**短链路配高税信道、长链路必须配低税信道**是工程铁律。 一条朴素结论：**链路长度 × 单跳税率 = 总税负**。在 3 跳以上的流水线里，自然语言信道和 A2A 协议几乎一定把模型税碾压成零头——这呼应了"选框定成本"的旧观察，但进一步锁定到"信道选择"这个更细的杠杆上。 --- ## 推荐方案：按场景选信道 **场景一：同团队、同语言、≤5 体的小型协作（如内部数据处理流水线）。** 无脑选**直接调用 + 结构化契约**。保真度满、税最低、调试最爽。不要被"多智能体"叙事绑架去上自然语言信道——那是给自己加税。 **场景二：需要辩论/谈判/创意脑暴（如方案评审、设计共创）。** 选**自然语言信道**，但必须配套：硬性轮次上限（≤5 轮）、token 预算闸、结构化契约兜底产出。把它当"昂贵但有创意"的工具，用完即走，绝不放进长流水线。 **场景三：大规模生产流水线（10–100 体，如代码生成→审查→测试→部署）。** 选**消息队列 + 结构化契约**。解耦、可扩展、可观测，是唯一能扛住真实负载的组合。AutoGen 0.4 的事件驱动架构是现成参考。可观测性（事件溯源、OpenTelemetry）不是可选项。 **场景四：跨厂商/跨组织协作（如调用合作伙伴的审查智能体）。** 只有这种场景才值得上 **A2A 协议**。上线前务必算清 HTTP 序列化税，并做好超时、重试、幂等、Agent Card 缓存。内部协作强上 A2A 是 2026 年最常见的过度工程。 **场景五：高并发、多智能体频繁读写共享状态（如多智能体协作编辑一份大文档）。** 选**共享黑板**，但必须配套并发控制（版本号/锁/CRDT），否则"共享即撕裂"。bMAS 架构是参考实现。 **通用铁律**：信道越靠"机器侧"（直接调用、契约、黑板），保真越高、税越低、刚性越强；越靠"人侧"（自然语言、跨厂商 A2A），灵活性与互操作性越高、但失真与税越重。**先用低税信道搭骨架，只在确实需要"理解"或"互通"的边沿处局部引入高税信道**——这是多智能体通信工程化唯一稳的姿势。 ## 参考来源 1. [The Multi-Agent Coordination Tax: Why Agent-to-Agent Communication Burns 40–60% More Tokens](https://agentmarketcap.ai/blog/2026/04/05/multi-agent-coordination-tax-context-propagation-token-burn) — 2025年12月覆盖180组配置的协调开销实测，协调税可达基线150%，本文token税区间的核心来源。 2. [Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture (arXiv:2507.01701)](https://arxiv.org/abs/2507.01701) — bMAS共享黑板架构论文，论证黑板在LLM时代的token高效协调优势，共享黑板栈原理依据。 3. [Announcing the Agent2Agent Protocol (A2A) — Google Developers Blog](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) — Google官方A2A协议公告，与MCP互补定位（智能体↔智能体 vs 智能体↔工具），A2A栈与协议战争背景来源。 4. [Agent Interoperability Protocols 2026: MCP, A2A, ACP and the Path to Convergence](https://zylos.ai/research/2026-03-26-agent-interoperability-protocols-mcp-a2a-acp-convergence/) — 四大智能体互操作协议（MCP/A2A/ACP/ANP）横向对比，2026协议战争全景。 5. [AutoGen and CrewAI Architectures — DeepWiki](https://deepwiki.com/ombharatiya/ai-system-design-guide/7.3-autogen-and-crewai-architectures) — AutoGen 0.4从对话式到事件驱动架构的重写分析，消息队列栈原理来源。 > [!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 等场景全覆盖。