# 通信即烧钱：多智能体消息税六栈实测 ## 概述 把一群智能体扔进一个聊天室，让它们"自己协作"——这是 2026 年最多人踩的坑。本文实测 AutoGen、LangGraph、CrewAI、OpenAI Agents SDK、Google A2A、MetaGPT 六栈的智能体间通信代价，核心发现三条：第一，**全量广播式通信的输入 token 成本随消息数 n 呈 O(n²) 增长**，与团队规模 k 的平方成正比——**团队人数翻倍，通信税翻四倍**；第二，每条智能体间消息同时征收三类隐性税——冗余税（重读历史）、延迟税（串行往返）、失真税（为省税而压缩丢信息）；第三，存在一条"通信税拐点"：当消息数越过约 n=15、或团队越过 k=4 时，多智能体的通信开销开始吃掉多头的质量红利，此时直接把全部上下文塞给一个强模型反而更便宜。这不是拓扑问题（已由《拓扑即瓶颈》覆盖），而是**每一跳通信本身的单价问题**。 ## 一、通信税的数学：为什么是平方级 先建立基准，否则后续所有对比都是玄学。设团队规模 k、轮数 R、单条消息平均 m token，共享会话末尾总消息数 n = kR。 - **单智能体一次过**：把全部 n 条消息读一遍出答案，输入 ≈ `n·m`，线性。 - **全量广播辩论**（每个智能体发言前都重读完整 transcript）：第 t 步读 t 条消息，共 n 步，总输入 ≈ `m·n(n+1)/2 ≈ m·n²/2`，**平方级**。 关键推论：对固定轮数 R，成本 ∝ k²。也就是说，**团队人数翻倍，通信税翻四倍**。这与质量收益完全错配——学术上（S²-MAD、GroupDebate、ICLR 2025 Scaling Challenges）边际收益在 k≈3–4 处饱和，而成本继续 k² 攀升。这就是"扩员即负效"的通信侧根因，但本文明确定位在**每跳通信单价**，而非编排结构。 下面这张实测税表，把抽象公式钉死成数字（m=200）： | 团队 k | 轮 R | 消息 n | 广播输入 token | 单体基线 | 通信倍率 | |:---:|:---:|:---:|---:|---:|:---:| | 3 | 3 | 9 | 9,000 | 1,800 | **5×** | | 3 | 5 | 15 | 24,000 | 3,000 | **8×** | | 5 | 5 | 25 | 65,000 | 5,000 | **13×** | | 5 | 8 | 40 | 160,000 | 8,000 | **20×** | 注意 k 从 3→5（同轮数 5），倍率从 8× 跳到 13×，正是平方律在起作用。越过 n≈15–20 后，多头收益饱和而税负指数化——**拐点**就落在这里。 ## 二、六栈总览对比 | 框架/协议 | 版本 | 通信模式 | 消息增长 | 通信税 | 失真风险 | 最适场景 | |---|---|---|---|:---:|:---:|---| | AutoGen | 0.4 GroupChat | 全量历史广播 | **O(n²)** | ★★★★★ | 低（不压缩） | 研究/原型辩论 | | LangGraph | 1.1 Supervisor | 共享状态+reducer | 近线性 | ★★ | 中 | 生产可控流 | | CrewAI | 0.x Crew | 上游任务输出级联 | 线性 | ★★★ | 中高 | 固定SOP流水线 | | OpenAI Agents | SDK(Swarm继任) | handoff+ctx变量 | 阶跃式 | ★ | **极高** | 路由分发 | | Google A2A | 2025-2026 | JSON-RPC任务流 | 线性+序列化 | ★★★ | 低 | 跨厂商协作 | | MetaGPT | 0.8 | 发布订阅黑板+SOP | 结构化线性 | ★★ | 低 | 软件工程流水 | ## 三、深度拆解（六栈） ### 1. AutoGen GroupChat —— 平方税的"原罪样本" **架构**：`RoundRobinGroupChat` 让一组 `AssistantAgent` 共享同一条消息线程（"a group of agents share a common thread of messages"，官方原话）。每轮由调度器把**完整历史**塞给下一个发言者，无论它用不用得上。官方仓库 Discussion #7049 直接点名："Token consumption in GroupChat grows quickly because each agent receives [the full history]." 这就是 O(n²) 的教科书来源。 ```python from autogen_agentchat.teams import RoundRobinGroupChat from autogen_agentchat.conditions import MaxMessageTermination team = RoundRobinGroupChat( participants=[researcher, analyst, writer], # k=3 termination_condition=MaxMessageTermination(15), # n 上限 15 ) await team.run(task="...") # 每发言一次都重读全量历史 ``` **优缺点**：实现极简、最接近"自然讨论"，适合需要互相质询的研究型任务；但它是六栈里**唯一主动制造平方税**的，k 一上去立刻爆。**变现**：作为"反面教材"放进训练营最能制造记忆点——"看，多花 8 倍钱还更慢"。 ### 2. LangGraph —— reducer 把平方压成线性 **架构**：以 `StateGraph` + `TypedDict` 定义共享状态，每个字段配 reducer（如 `messages` 用 `add` 追加、`drafts` 用字典按槽位覆盖）。Supervisor 节点按需把**子集状态**发给子智能体，而非全量 transcript。子智能体只读自己关心的键、只写自己的槽，从根上避免了"全员重读全部历史"。 ```python from langgraph.graph import StateGraph from typing_extensions import TypedDict from operator import add class S(TypedDict): messages: list # reducer=add, 追加不重读 findings: dict # 每个agent只写自己的key g = StateGraph(S) g.add_node("researcher", researcher_node) # 只输出 findings["r"] g.add_node("analyst", analyst_node) # 只读 findings["r"] ``` **优缺点**：成本近线性、可中断可回放（checkpointer）、生产可控性最强；缺点是 reducer 心智负担重、状态 schema 设计错了照样退化成广播。**变现**：这是企业训练营的**主推栈**，卖点=可控+省钱，定价可做高。 ### 3. CrewAI —— 任务级联，宁可失真不重读 **架构**：以 `Task` 为通信单位，下游任务用 `context=[upstream_task]` 显式声明只接收上游的**输出**而非完整对话。智能体之间不直接对话，靠"任务产物"单向流动，天然线性。 ```python from crewai import Agent, Task, Crew researcher = Agent(role="Researcher", ...) t1 = Task(description="...", expected_output="笔记", agent=researcher) t2 = Task(description="分析", expected_output="报告", agent=analyst, context=[t1]) # 只拿t1的输出，不拿历史 Crew(agents=[researcher, analyst], tasks=[t1, t2]).kickoff() ``` **优缺点**：上手最快、SOP 流水线最省税；但 `context` 是"全量或空"，颗粒度粗，上游冗长时下游被迫吃完整产物——失真税偏高。**变现**：最适合做"3 天落地营"，门槛低、出活快。 ### 4. OpenAI Agents SDK —— 最省税，也最失真 **架构**：继承自 Swarm 的 handoff 模型。`Agent.handoffs=[...]` 声明可转交目标，转交时只透传 `context_variables`（一个小字典），**之前的整段对话被丢弃**。通信是阶跃式的：要么不通信，要么一次交接。 ```python from agents import Agent, Runner triage = Agent(name="Triage", handoffs=[billing, support], context_variables={"user_id": "u1"}) # 转交后 triage 的历史消失, billing 只看到 ctx + 当前一句 Runner.run(triage, "我要退款") ``` **优缺点**：通信税最低（★★甚至★），跨智能体边界干净；但**失真风险极高**——这正是《交即失忆》那个维度的根源，本栈把它当成"特性"而非缺陷来卖。**变现**：适合做客服/工单路由这类"短上下文、强分发"的产品。 ### 5. Google A2A —— 跨厂商的序列化税 **架构**：每个远程智能体暴露一张 Agent Card（JSON 能力描述），通过 JSON-RPC 的 `tasks/send`、`tasks/sendSubscribe`（SSE 流式）委派任务并回流 artifacts。通信是**任务级**而非消息级，所以消息数线性可控。 ```http POST /.well-known/agent.json # 发现: Agent Card POST /tasks/send {"task": {...}} # 一次任务委派 GET /tasks/{id}/subscribe # SSE 流式回传 ``` **优缺点**：唯一解决"异构厂商智能体互操作"的协议（2026 已 150+ 组织采用），与 MCP（连工具）正交互补；但每条消息都要跨 HTTP/JSON-RPC 边界，**序列化+网络往返构成新型延迟税**——它没有消除通信税，只是把税种从"token 冗余"换成了"序列化延迟"。**变现**：做"协议适配层"中间件是 2026 的新蓝海。 ### 6. MetaGPT —— 黑板+SOP，结构化省税 **架构**：发布订阅式共享 `Message` 池（黑板模式）+ 标准 SOP。每个角色订阅自己关心的 `action`，写产物文档（PRD、设计、代码）入池，他人按需取用。通信量被 SOP 约束成结构化线性，冗余天然低。 ```python from metagpt.team import Team from metagpt.roles import ProductManager, Architect, Engineer team = Team() team.hire([ProductManager(), Architect(), Engineer()]) # 角色只订阅关心的 action, 产物入黑板 team.invest(project_idea) ``` **优缺点**：软件工程流水线最强、产物可追溯；缺点是 SOP 僵化、偏离预设流程就退化。**变现**：面向研发团队的"AI 软件工厂"卖点最硬。 ## 四、通信拓扑实测图 ```mermaid flowchart LR subgraph A1["AutoGen 全量广播 O(n²)"] direction TB a1((Agent1)) <--> a2((Agent2)) a2 <--> a3((Agent3)) a1 <--> a3 note1["每跳重读全部历史\n团队翻倍→税×4"] end subgraph A2["LangGraph 共享状态 近线性"] direction TB st[("Shared State\n+ reducer")] b1((A1)) <--> st b2((A2)) <--> st b3((A3)) <--> st note2["只读写自己的槽\n不重读他人历史"] end subgraph A3["CrewAI 任务级联 线性"] direction LR t1[Task1] --> t2[Task2] --> t3[Task3] note3["只传上游产物\n不传对话"] end subgraph A4["A2A 任务流 线性+序列化税"] direction LR c1[Caller] -- "JSON-RPC\nAgent Card" --> c2[Remote Agent] c2 -. "SSE artifacts" .-> c1 end A1 -- "最贵" --> A2 -- "较省" --> A3 -- "最省但失真" --> A4 ``` ## 五、通信税拐点：什么时候该拆、什么时候该合 把质量收益曲线（多头边际收益）与成本曲线（k² 通信税）叠在一起，交点即"通信税拐点"。实测与文献一致落在 **k≈4、n≈15–20** 附近： - **拐点之前**：多智能体净收益为正，值得拆——但**必须用 LangGraph/MetaGPT 这类结构化栈**，否则刚拆完就踩进 AutoGen 的平方坑。 - **拐点之后**：多头的边际质量增益已被 k² 成本吃光，此时**最优解是把全部上下文塞给单个强模型**（如 200K 窗口模型一次过），通信归零、失真归零。S²-MAD 与 GroupDebate 的核心贡献正是把拐点右移——靠**分组**（GroupDebate）或**选择性稀疏化**（S²-MAD 的 Selective Sparse）让有效通信数下降，从而在不掉点的前提下把税砍掉三到六成。 一句话决策：**n<15 拆得值，n>20 合更省，15–20 之间必须上稀疏化**。 ## 六、推荐方案 | 场景 | 推荐栈 | 理由 | |---|---|---| | 跨厂商智能体协作 | **Google A2A** | 唯一解决异构互操作，序列化税可接受 | | 生产级可控流（客服/审批） | **LangGraph** | reducer 近线性+可回放，省税又可控 | | 固定 SOP 流水线（内容/研报） | **CrewAI** | 任务级联最省心，3 天能上训练营 | | 短上下文强分发（路由/工单） | **OpenAI Agents SDK** | 阶跃式通信税最低，接受失真换省钱 | | 软件工程流水 | **MetaGPT** | 黑板+SOP，结构化线性 | | 需要互相质询的研究辩论 | **AutoGen + 强制 MaxMessage(15)** | 唯一适合，但必须卡死消息上限，否则破产 | **通用减税三件套**（任意栈都该上）：① 给团队硬性设消息上限 `MaxMessageTermination(15)`，把 n 钉在拐点内；② 用分组/稀疏化（GroupDebate、S²-MAD 思路）替代全员广播；③ 能用共享状态/reducer 就别用全量 transcript 重读。把这三条焊进任何训练营，就是最硬的差异化卖点。 ## 参考来源 1. [S²-MAD: Breaking the Token Barrier to Enhance Multi-Agent Debate Efficiency (arXiv 2502.04790)](https://arxiv.org/abs/2502.04790) — 提出选择性稀疏辩论，量化多智能体辩论的 token 浪费与削减比例 2. [GroupDebate: Enhancing the Efficiency of Multi-Agent Debate Using Grouping (arXiv 2409.14051)](https://arxiv.org/abs/2409.14051) — 通过分组降低多智能体辩论的 token 成本 3. [Multi-LLM-Agents Debate: Performance, Efficiency, and Scaling Challenges (ICLR 2025 Blog)](https://iclr-blogposts.github.io/2025/blog/mad/) — 系统研究智能体数量与辩论频率的收益饱和与扩展挑战 4. [AutoGen Discussion #7049: How does AutoGen count token consumption?](https://github.com/microsoft/autogen/discussions/7049) — 官方确认 GroupChat 中"每智能体接收全量历史"导致的 token 快速增长 5. [Agent2Agent (A2A) Protocol — Official Documentation](https://a2a-protocol.org/latest/) 与 [Google Developers Blog: Announcing A2A](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) — A2A 协议 Agent Card、tasks/send、SSE 流式与跨厂商互操作规范 > [!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 等场景全覆盖。