# 多Agent规模法则：协调税与塌方线 ## 概述 过去两年最流行的Agent叙事是"加Agent就能涨点"——从"More Agents Is All You Need"到各类Swarm营销，把多智能体等同于更强的推理能力。但2026年Google与MIT联合发表的《Towards a Science of Scaling Agent Systems》用180组配置的受控实验给出第一份量化规模法则，直接戳破了这个神话：**在串行推理任务上，几乎所有多Agent变体都让性能下滑39–70%**。与此同时，清华大学MACNET在并行可分解任务上复现出类似神经网络的幂律扩展。本文以规模法则为骨架、以协调税为血肉，拆解多Agent协作的经济学真相：协调开销(40–150%的token税)、协调天花板、并行/串行分水岭，以及混合架构的崛起，并给出一份能直接落地的预算分配与拓扑选型账本。 ## 多Agent扩展策略对比 | 策略 | 核心机制 | 规模法则形态 | 协调税 | 适用任务 | |------|----------|--------------|--------|----------| | 朴素并行投票(N-agent Ensemble) | 多Agent独立解→多数表决 | 任务难度门槛上方单调改善 | 低(无通信) | 离散选择题、HumanEval | | 串行流水线(Pipeline) | 角色1→角色2→…→角色N | 误差累积，N↑性能↓ | 中(单向) | 软件工程SOP、文档生产 | | 辩论/共识(Debate) | 多轮互评收敛 | 收敛后边际骤降 | 高(全互联) | 事实校验、安全审查 | | DAG协作网(MACNET) | 有向无环图编排推理 | 接近幂律(C∝N^k) | 中(拓扑受限) | 数学竞赛、可分解推理 | | 层级经理-工人(Hierarchy) | 调度器分发+聚合 | 受分解度约束 | 中(树形) | 复杂任务分解 | | 混合自适应(Hybrid) | 单Agent默认+按需扩展 | 帕累托最优 | 动态 | 生产系统主力 | ## 一、"More Agents Is All You Need"的塌方线 2024年的"More Agents Is All You Need"(Li等)用实验声称LLM性能随Agent数量单调上升，这一结论迅速被市场放大成"加人就能赢"。2026年Google Research联合MIT的论文(arXiv:2512.08296)用**180组受控配置**重新审视，得到了第一份量化Agent规模法则，结论与流行叙事相反：在像PlanCraft这类**串行推理任务**上，团队测试的每一个多Agent变体都让性能**退化39–70%**。 退化的根因不是模型变弱，而是协调引入了三类损耗：上下文在Agent间传递时的**信息蒸馏损失**、轮次增加带来的**误差累积**、以及Agent之间对中间状态的**不一致假设**。论文进一步指出，性能拐点(塌方线)取决于任务的**可分解度**——可分解为独立子任务时扩展有效，强串行依赖时扩展有害。这与朴素直觉吻合：一个需要严格逻辑链的任务，把它切成多段、由不同Agent接力，每一段都在重复"重新理解上文"，等于在逻辑链上插入若干个失真节点。 变现/训练营评估：这一发现是绝佳的"反共识"内容素材——市面上绝大多数多Agent课程仍在贩卖"加Agent涨点"的旧叙事。一个以"规模法则+协调税"为主题的实战训练营(180配置复现→找出自己的塌方线→设计混合架构)具有高差异化价值，且能直接挂钩企业成本优化痛点。 ## 二、MACNET：被验证的幂律扩展在何处成立 并非所有扩展都是骗局。清华大学MACNET(arXiv:2406.07155，ICLR 2025)用**有向无环图(DAG)**组织Agent，通过拓扑编排实现交互式推理，在数学推理等**可分解任务**上复现出形如神经网络的幂律扩展曲线。其关键洞察是：受神经规模定律启发，推理规模的收益也服从可预测的幂律，但前提是协作结构必须与任务的依赖图同构。 MACNET的设计要点是把Agent组织成DAG而非全互联：每个节点接收上游输出、产出下游消费的中间表示，拓扑本身编码了任务分解。这种约束使得扩展(增加节点/层)在不引入指数级通信开销的前提下持续提升性能，逼近`C(N) ∝ N^k`的形式。与全互联辩论相比，DAG把协调复杂度从O(N²)压到O(E)(E为边数)，是规模法则得以成立的工程前提。 代码片段(MACNET式DAG编排核心思想)： ```python # DAG节点：每个Agent消费上游节点输出，产出供下游使用的中间表示 class DAGNode: def __init__(self, agent, predecessors=None): self.agent = agent # 角色化Agent self.predecessors = predecessors or [] # 拓扑约束：限制通信面 def run(self, task): # 聚合上游中间表示而非全文转发 —— 降低蒸馏损失 upstream = [p.output for p in self.predecessors] self.output = self.agent.solve(task, context=upstream) return self.output # 拓扑同构：依赖图与协作图一致时扩展才服从幂律 graph = build_dag_from_task_dependency(task) # 关键：先建依赖图再配Agent ``` ## 三、协调税：40–150%的token黑洞 把"协调"翻译成钱，账本会变得刺眼。多家2026年的实测数据指向同一个区间：**多Agent协调带来40–150%的token开销**。来源agentmarketcap的实测指出，Agent间通信、上下文传播与冗余工作叠加，让单位任务的token消耗显著膨胀；更有极端案例(DEV社区"15x token tax")记录了配置不当的协调层让token消耗放大15倍。 协调税有三层来源。第一层是**上下文传播**：每个下游Agent都需要上游的中间状态，若直接转发完整上下文，token按轮次近似二次增长(quadratic growth)。第二层是**冗余工作**：缺乏分工边界时，多个Agent会对同一子问题重复求解。第三层是**协议开销**：心跳、状态同步、结果序列化，在大规模Swarm(50–1000 Agent)中会占据可观比例。 降低协调税的工程杠杆有三：**(1)结构化中间表示**——用紧凑schema(如JSON摘要)替代全文转发；**(2)拓扑裁剪**——用DAG/树替代全互联，把通信面从O(N²)降到O(N)；**(3)共享黑板**——单一可寻址状态库替代点对点广播，读写按需进行。这三条分别对应蒸馏损失、通信复杂度、协议冗余三个税源。 ## 四、协调天花板：加人即变差的拐点 "协调天花板"是被实战反复确认的现象——存在一个Agent数量阈值，越过之后系统性能开始**下降而非饱和**。这与参数规模法则的"边际递减"不同：那是收益变缓，而协调天花板是**收益转负**。 Pratiti等的技术分析把天花板归因于一个反馈环：Agent越多，协调开销越大；协调开销越大，单Agent可用预算/上下文越被挤压；预算越被挤压，单Agent产出质量越低；最终聚合质量反而劣于更小的团队。这正是Google/MIT在串行任务上观测到39–70%塌方的微观机制。 实战中定位天花板的方法是**规模扫描**：在固定任务与固定总token预算下，跑N=1,2,4,8,16,32的配置，画出"性能–Agent数"曲线。曲线的拐点就是你这个任务+这套拓扑的天花板。值得注意的是，天花板不是常数——提升单Agent能力、改用DAG拓扑、引入预算分配机制都能把天花板右移。这也解释了为什么同样的"5-Agent系统"在不同团队手里效果天差地别：天花板是工程产物，不是自然常数。 ## 五、并行/串行分水岭：决定胜负的任务结构 整个规模法则争议的根源，是两类任务被混为一谈。**可分解(并行)任务**：子任务彼此独立(如多题批改、多模块开发、多方案生成)，多Agent能拿到近线性的吞吐或经投票/集成提升准确率。**强依赖(串行)任务**：子任务存在严格逻辑链(如多步规划、长链推理)，多Agent接力反而引入失真节点。 两份对照数据足以说明分水岭。代码生成领域vibecoding的实测显示，多Agent在SWE-bench Verified上达到**72.2%**，优于单Agent约60%的基线——因为软件工程可分解为"定位-编辑-测试"的可并行子流程。而Google/MIT在PlanCraft(强串行规划)上看到的是39–70%的塌方。同一套多Agent框架，换一类任务，结论完全相反。 选型红线因此清晰：**先判任务的依赖图**。若依赖图是宽而浅的(可分解度高)，多Agent+并行集成是正收益；若依赖图是深而窄的(强串行)，应让单Agent承担主链、仅在分叉处启用并行子Agent。盲目套用"辩论型5Agent"于串行任务，是生产事故的高发模式。 ```mermaid flowchart TD A[任务输入] --> B{依赖图分析} B -->|宽而浅·可分解度高| C[并行集成拓扑] B -->|深而窄·强串行| D[单Agent主链 + 分叉处并行] C --> E[N-Agent独立解 → 投票/聚合] D --> F[主链单Agent推进] F --> G{遇到可分解分叉?} G -->|是| H[临时起并行子Agent] G -->|否| I[继续单Agent] H --> F E --> J[输出] I --> J style B fill:#fef3c7 style C fill:#d1fae5 style D fill:#dbeafe ``` ## 六、混合架构：Why Not Both arXiv:2505.18286的研究明确指出MAS与SAS(Multi/Single Agent System)的**性能落差**本身就具有信息量，并据此设计了混合自适应系统：默认走单Agent(成本低、无协调损失)，当置信度低于阈值或任务出现可分解分叉时，动态扩展为多Agent。这与Microsoft Azure的决策树、以及多家厂商2026年的部署实践一致——**单Agent在准确率、成本、平均故障恢复时间(MTTD)上往往占优，直到任务复杂度越过某个门槛**。 混合架构的工程核心是**触发器设计**：什么信号触发扩展？常见的有三类——**(1)置信度触发**：单Agent自评不确定时拉入评审Agent；**(2)结构触发**：依赖图分析发现可分解分叉时并行展开；**(3)预算触发**：剩余token预算充裕且任务价值高时启用更贵的多Agent。这种"按需扩展"避免了静态多Agent系统的协调税常态，又保留了复杂任务的扩展能力，是2026年生产系统的事实最优解。 训练营可围绕"混合触发器"设计实战作业：给定一个混合框架骨架，让学员实现三类触发器并对比成本-准确率曲线。这个练习同时覆盖了规划、评估、成本优化三个高价值技能点。 ## 七、预算分配经济学：从定额到拍卖 当确需多Agent时，token预算如何在Agent间分配？朴素做法是**定额均分**，但这违背了"子任务难度不等"的事实——把预算平均切给一个简单子任务和一个硬子任务，等于在硬子任务上饿死Agent。更优的是**基于价值/难度的动态分配**，甚至引入**拍卖机制**：每个Agent对"给我多X token能提升多少"做报价，调度器按边际收益排序分配。 实践中常采用简化版：调度器先用一个轻量预估Agent对子任务打难度分，预算按难度加权分配；运行中若某Agent报告"剩余预算不足以完成"，触发二次预算迁移(从已完成的Agent回收)。这套机制把"协调税"部分转化为"投资"，让每token都流向边际收益最高的地方。 可量化的对照：kspl.tech的实测显示，一个10-Agent生产系统月成本在**3,200–13,000美元**区间。引入预算分配+混合架构后，同等任务质量的成本通常可压到原来的30–50%——因为大量请求其实被单Agent路径处理，只有少数高价值任务才进入昂贵得多Agent路径。这正是FinOps进入Agent时代的核心抓手。 ## 八、生产规模法则的落地检查清单 把上述发现凝练为可直接执行的工程清单，便于团队在引入或扩展多Agent前自检： 1. **先画依赖图**：任务能否分解？宽浅→并行集成；深窄→单Agent主链。 2. **跑规模扫描**：固定预算下扫描N=1..32，找到本任务的天花板，不要超过它。 3. **量协调税**：统计每条任务的多Agent token / 单Agent token比值，>1.5即需优化结构化表示。 4. **默认混合**：以单Agent为主路径，仅按置信度/结构/预算触发扩展。 5. **预算按难度分配**：弃用定额均分，改加权或轻量拍卖。 6. **拓扑裁剪**：全互联→DAG/树/黑板，把通信面压到O(N)。 7. **设熔断**：协调开销或轮次超阈值时降级回单Agent，防塌方。 这份清单的价值在于把"规模法则"从论文概念变成CI/CD管线里可监控的指标——协调税率、天花板余量、单/多路径占比，应成为多Agent系统的核心SLO。 ## 推荐方案 - **追求准确率且任务可分解**(如代码生成、批量评审、方案生成)：MACNET式DAG + 并行集成，接受中等的协调税以换取72%级的准确率。 - **强串行推理任务**(如多步规划、长链推理、数学证明)：单Agent主链，仅在可分解分叉处临时起并行子Agent；警惕39–70%的塌方线。 - **成本敏感的生产系统**：混合自适应架构为默认，单Agent为主路径，按三触发器扩展，配合预算动态分配——这是把月成本从13K压到4K级的关键路径。 - **训练营/产品包装**：以"规模法则+协调税+塌方线"为主题，做180配置复现+天花板扫描+触发器实现的三段式实战，差异化显著且直接挂钩企业降本痛点。 ## 参考来源 1. [Towards a Science of Scaling Agent Systems (Google Research / MIT)](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/) — 180组配置的首份量化Agent规模法则，串行任务塌方39–70% 2. [Towards a Science of Scaling Agent Systems — arXiv:2512.08296](https://arxiv.org/abs/2512.08296) — 论文原文，给出可分解度与扩展有效性的关系 3. [Scaling Large Language Model-based Multi-Agent Collaboration (MACNET, ICLR 2025)](https://arxiv.org/abs/2406.07155) — 清华DAG协作网，可分解任务上的幂律扩展 4. [The Multi-Agent Coordination Tax: Why Agent-to-Agent Communication Burns Tokens](https://agentmarketcap.ai/blog/2026/04/05/multi-agent-coordination-tax-context-propagation-token-burn) — 实测协调开销40–150%的token税 5. [Single-agent or Multi-agent Systems? Why Not Both? — arXiv:2505.18286](https://arxiv.org/abs/2505.18286) — 混合自适应系统，MAS/SAS性能落差的设计信号 > [!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 等场景全覆盖。