过去两年，几乎所有多智能体基准都在讲同一个故事：把任务拆给一群 Agent，质量就比单 Agent 高。但 2026 年 4 月斯坦福 Tran 与 Kiela 的一篇论文（arXiv 2604.02460）拆穿了这个叙事——当把"思考 token 预算"钉死，单智能体在三个模型族、五种多智能体架构的围攻下，准确率更高、算力更省。被隐藏的变量叫思考预算：大多数基准允许多智能体花 2–4 倍的推理 token 去赢，赢的不是"集体智慧"，而是"想得更久"。一旦把预算拉平，多智能体的规模红利瞬间蒸发，剩下的只有一条规模税曲线——每加一个 Agent，协调开销就吞掉一份有效算力，每次交接都在漏信息。
本文用 180 组配置实测、SWE-bench 真实轨迹方差分析、三大框架分账数据，把这条"规模税曲线"量出来，并给出加 Agent 还是加预算的工程决策拐点。
| 维度 | 单智能体（基线） | 多智能体（典型 4–10 Agent） | 规模税说明 |
|---|---|---|---|
| 峰值 Prompt Token | ≈8,000 | LangGraph 15,010 / AutoGen 10,750 | 框架账单 +35%–88% |
| 协调开销占比 | 0 | 40%–150%（部分任务超基线） | Agent 在"对账"而非"干活" |
| 每跳上下文重复 | — | 20%–40% 负载（IBM ContextForge） | 委派链越长漏得越多 |
| 等预算准确率 | 最高（DPI 保信息） | 5 种架构全部更低 | 信息论硬约束 |
| 运行间方差 | 中 | 极高（同任务 10×） | 预测 Pearson r < 0.15 |
| 月度运维成本 | 低 | 10-Agent 系统 $3,200–$13,000/月 | 账单随 N 超线性涨 |
| 通信复杂度 | O(1) | mesh=O(n²) / star=O(n) | 拓扑决定税基 |
一句话：单智能体赢在"信息无损 + 零协调"，多智能体只有在"任务可天然并行、且上下文可物理隔离"时才可能赢回这笔税。
绝大多数多智能体 vs 单智能体的对比，都犯同一个错：放任多智能体跑更长的轨迹、更多的中间步、更多的协调轮次，然后用"它准确率更高"下结论。这等于让马拉松选手和短跑选手比马拉松，再宣布马拉松选手更会跑。斯坦福实验做的第一件事就是把思考 token 预算焊死：在 Qwen3、DeepSeek-R1-Distill-Llama、Gemini 2.5 三个模型族上，从 100 到 10,000 thinking token 等量配给，再让单智能体去打顺序、子任务并行、并行角色、辩论、集成五种 MAS 架构。
结果是干净的——预算拉平后，单智能体的准确率在三个模型族上全部更高，算力消耗反而更少。那些"多智能体更强"的结论，本质是花更多 token 买来的，而不是结构带来的。更刺眼的是方法论里的一句话：Gemini 2.5 API 在预算控制上存在"显著伪影"，单智能体被要求固定 token 时常常提前收手，而多智能体因为拆成多次调用反而"绕过"了上限。这意味着过去整整一年的架构选型决策，有不少是建立在不公平的标尺上。
为什么钉死预算后单智能体必赢？根因是香农 1948 年的数据处理不等式（DPI）：信息经过任何后续处理，都不可能增加，只能保持或丢失。把一个推理链拆给两个 Agent，第一棒把它的理解压缩成一段消息传给第二棒，这段压缩就是有损的——第二棒拿到的永远是不完整的世界观，再多轮协作也补不回那部分信息。
graph LR
A[原始任务信息量 I0] -->|Agent1 压缩为消息| B[传递信息 I1 < I0]
B -->|Agent2 再压缩| C[传递信息 I2 < I1]
C -->|AgentN 整合| D[最终输出 I_n ≤ I0]
A -.不可逆损耗.-> E[每跳损失 20%–40%]
style E fill:#fdd,stroke:#c00
style D fill:#ffd,stroke:#a80
这条规律解释了"五票同错"和"传话链精度雪崩"之外的另一面：哪怕你精心设计分工、每个 Agent 都很聪明，信息论已经从上限上判处了多智能体的有损性。辩论能纠错，但纠错本身也要耗预算；当预算被拉平，纠错的算力就是从主任务里抢的。所以等预算下，把 N 个 Agent 的交接损耗，加总后一定大于一个 Agent 连续推理的损耗——这不是工程问题，是数学问题。
抛开信息论，纯工程上多智能体还背着三笔刚性开销。每次 Agent A 把活派给 Agent B，必然发生：上下文播种——B 必须被初始化一份足够独立运作的上下文，这是 A 状态的副本或大子集；结果整合——A 要把 B 的输出吞回自己的上下文窗口，窗口随之膨胀；开销复合——委派链每多一跳，就重复 20%–40% 的上下文负载（IBM ContextForge 对 A2A 协议部署的实测）。这三段凑成了所谓的"协调税"。
一项跨越 180 个多智能体配置的研究（2025 年 12 月）量化了这个数字：协调开销最高可达基线 token 消耗的 150% 以上——也就是说，你的 Agent 群花在互相说话上的 token，比花在干正事上的还多。而且这笔税是累退的：任务越简单，协调税占比越高，因为"正事"本身花的 token 少，固定的播种/整合开销就显眼。这就是为什么把一个三行代码的任务丢给 10 个 Agent，账单能比单 Agent 贵 6.2 倍——贵的几乎全是税，不是货。
同样是多智能体，框架选择直接决定你交多少税。OpenAgents 2026 基准给出了少见的同口径对比：在同一个代表性任务上，单智能体基线约 8,000 tokens；AutoGen 的对话式多智能体循环因为所有 Agent 消息对编排者全程可见，跑到 10,750 tokens，高出基线约 35%；LangGraph 更夸张，状态机架构要求图的每个节点都吞下累积的状态对象，状态随每步增长，峰值冲到 15,010 tokens，光框架自身的上下文管理就造出 88% 的开销，还没算任何 Agent 间通信。
CrewAI 走了第三条路：用模块化推理循环，不把完整历史塞进每次 LLM 调用，于是 token 用量在三大框架里最低，但代价是延迟最高——更受限的上下文逼着它走更多串行推理步。这揭示了一个框架级的不可能三角：低 token、低延迟、高上下文保真，三者最多得其二。选 LangGraph 你为可追溯的完整状态付 88% 税；选 AutoGen 你为对话可见性付 35%；选 CrewAI 你用时间换 token。没有任何框架能逃掉规模税，区别只在税基放在哪个账户。
团队规模这个变量，杀伤力取决于你怎么连。网状（mesh）拓扑——AutoGen GroupChat、早期 OpenAI Swarm 那种——Agent 两两可通信，信道数随 N 平方增长，N=10 时已有 45 条潜在交互链，token 燃烧速率失控。星型（supervisor/中心编排）把通信收拢到中心，复杂度降到 O(N)，但中心 Agent 的上下文窗口变成整个系统的单点膨胀瓶颈，N 越大编排者越早撑爆。流水线（pipeline）把 Agent 串成单向链，复杂度 O(N)，且每个 Agent 只看相邻输出，上下文最省——但这也意味着最不能纠错，DPI 损耗叠满。
graph TB
subgraph Mesh["mesh: O(N²) — 信道 45 @N=10"]
m1((A1)) <--> m2((A2)) <--> m3((A3))
m1 <--> m3
end
subgraph Star["star: O(N) — 中心即瓶颈"]
s0((Orch)) --> s1((A1))
s0 --> s2((A2))
s0 --> s3((A3))
end
subgraph Pipe["pipeline: O(N) — 单向、最省、最不纠错"]
p1((A1)) --> p2((A2)) --> p3((A3))
end
Mesh -.税基最高.-> T[Token 燃烧]
Star -.税基中.-> T
Pipe -.税基最低.-> T
style T fill:#fdd,stroke:#c00
一条经验线：mesh 只在你真的需要任意两 Agent 协商时才用，且 N 严控 ≤4；绝大多数生产任务应该用 star 或 pipeline，把税基从平方压到线性。"加 Agent" 在 mesh 拓扑里是给税基乘方，在 pipeline 里只是线性加法——同一个 N，账单能差一个数量级。
规模税不只是均值更贵，更隐蔽的是方差爆炸。对真实 SWE-bench 轨迹的首次实证分析发现，Agent 系统的总 token 消耗几乎无法事前预测——预测值与实际值的 Pearson 相关 r < 0.15，而同一任务的运行间方差可达 10 倍。一个今天花 5 万 token 跑完的工作流，明天同样输入可能要 50 万 token，因为某个 Agent 多绕了一轮、某个委派链多了一跳。
这对企业预算是致命的。一份 2026 年的运维数据指出，一个 10-Agent 生产系统月开销在 $3,200–$13,000 之间浮动，这个区间本身就是方差税的直接体现。更有个团队公开复盘：在烧掉 $47K 之后才回头 benchmark 单智能体替代方案，发现后者既便宜又准。多智能体让"成本不可预测"从例外变成常态——因为 N 越大，可能的状态组合、委派路径、重试级联越多，方差随 N 放大而非收敛。规模税的复利，主要体现在不确定性上。
那是不是永远单智能体最优？也不是。规模税存在一个甜区：当任务能被物理切分成上下文互不污染的子块时（例如独立文件审查、独立检索源、独立测试模块），加第二个、第三个 Agent 能带来真实的并行收益，且协调税还在可承受区间。MetaGPT、CAMEL 等框架实践中，2–5 个 Agent 是公认的高性价比区间，"More Agents Is All You Need"（arXiv 2402.05120）报告的 scaling 也主要发生在这个区间内——而且它的本质是 sample-and-voting 的推理预算 scaling，不是结构红利。
一旦超过 5–7 个，边际收益开始平坦甚至转负：协调税、DPI 损耗、方差爆炸三股力量同时抬头，新增 Agent 带来的质量提升跑不赢它引入的开销。Google Research 在《Towards a Science of Scaling Agent Systems》（arXiv 2512.08296）中点破了这个机制的本质——tool-coordination trade-off：Agent 数量与可用工具之间存在权衡，加 Agent 不等于加能力，往往只是把同一个工具调用拆成多个 Agent 的接力，徒增交接损耗。
xychart-beta
title "团队规模 N 与 质量/成本/延迟 三曲线（示意）"
x-axis "Agent 数量 N" [1, 2, 3, 5, 7, 10, 15]
y-axis "相对值（单Agent=100）" 0 --> 350
line "质量%" [100, 118, 128, 131, 130, 126, 119]
line "成本%" [100, 190, 280, 470, 640, 910, 1360]
line "方差%" [100, 160, 230, 360, 520, 780, 1150]
读图要点：质量曲线在 N=3–5 见顶后回落，成本与方差曲线则一路超线性攀升——三条曲线的张口，就是"加 Agent"的真实代价。
把上面七层压成一条可执行规则：先问任务能否物理并行。能——子块上下文天然隔离、可独立验证——那加 Agent（pipeline 或 star，N≤5），并给每个 Agent 单独的护栏。不能——任务是有逻辑依赖的单一推理链——那别加 Agent，去加思考预算或换更强的单模型，后者在 DPI 上是严格更优的。判断标准很硬：如果你加的 Agent 之间需要频繁传话、共享同一份背景，那就是在制造交接损耗，结构性必亏。
变现层面，这条规律天然适合做成"多智能体成本体检"训练营或 SaaS：用等预算基准为客户测出当前 N-Agent 系统的规模税，给出"砍掉几个 Agent / 提高单 Agent 预算"的降本方案。一个 $3,200–$13,000/月的多智能体系统，压回单 Agent 或 2-Agent pipeline，常常能省 40%–70% 且质量不降。这个"减员增效"的卖点，比"加更多 Agent"更能打动为账单焦虑的技术负责人——因为过去一年他们看到的，恰恰是多智能体越加越贵、越加越难预测。
[!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 等场景全覆盖。