通信即烧钱：多智能体消息税六栈实测

概述

把一群智能体扔进一个聊天室，让它们"自己协作"——这是 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 从 3→5（同轮数 5），倍率从 8× 跳到 13×，正是平方律在起作用。越过 n≈15–20 后，多头收益饱和而税负指数化——拐点就落在这里。

二、六栈总览对比

三、深度拆解（六栈）

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²) 的教科书来源。

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。子智能体只读自己关心的键、只写自己的槽，从根上避免了"全员重读全部历史"。

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] 显式声明只接收上游的输出而非完整对话。智能体之间不直接对话，靠"任务产物"单向流动，天然线性。

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（一个小字典），之前的整段对话被丢弃。通信是阶跃式的：要么不通信，要么一次交接。

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。通信是任务级而非消息级，所以消息数线性可控。

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 约束成结构化线性，冗余天然低。

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 软件工厂"卖点最硬。

四、通信拓扑实测图

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 之间必须上稀疏化。

六、推荐方案

通用减税三件套（任意栈都该上）：① 给团队硬性设消息上限 MaxMessageTermination(15)，把 n 钉在拐点内；② 用分组/稀疏化（GroupDebate、S²-MAD 思路）替代全员广播；③ 能用共享状态/reducer 就别用全量 transcript 重读。把这三条焊进任何训练营，就是最硬的差异化卖点。

参考来源

1. S²-MAD: Breaking the Token Barrier to Enhance Multi-Agent Debate Efficiency (arXiv 2502.04790) — 提出选择性稀疏辩论，量化多智能体辩论的 token 浪费与削减比例
2. GroupDebate: Enhancing the Efficiency of Multi-Agent Debate Using Grouping (arXiv 2409.14051) — 通过分组降低多智能体辩论的 token 成本
3. Multi-LLM-Agents Debate: Performance, Efficiency, and Scaling Challenges (ICLR 2025 Blog) — 系统研究智能体数量与辩论频率的收益饱和与扩展挑战
4. AutoGen Discussion #7049: How does AutoGen count token consumption? — 官方确认 GroupChat 中"每智能体接收全量历史"导致的 token 快速增长
5. Agent2Agent (A2A) Protocol — Official Documentation 与 Google Developers Blog: Announcing A2A — 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 等场景全覆盖。