昨天刚写了「双脑协作」，今天就被 Stanford 的研究打脸了：多 Agent 系统在控制算力后，并没有你想象的那么强。Swarm Tax（多 Agent 税）是真实存在的——但它什么时候适用，什么时候不适用？

先说结论

多 Agent 系统（MAS）并没有原生的架构优势。

这是 Stanford 大学 Dat Tran 和 Douwe Kiela 在论文 「Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets」（arXiv:2604.02460）中的核心发现。他们用三个主流模型家族（Qwen3、DeepSeek-R1-Distill-Llama、Gemini 2.5）做了严格控制变量的实验：当思考 token 预算相同时，单 Agent 系统（SAS）一致地匹配或超越多 Agent 系统。

这个结论不是「多 Agent 不好」，而是「多 Agent 好的原因被错误归因了」。

目录

二、Swarm Tax 是什么

Swarm Tax = 多 Agent 架构的隐性算力成本。

传统观点认为多 Agent 系统的优势来自「分工」和「协作」，但 Stanford 的研究指出这个归因是错的。真正的优势来源是：多 Agent 系统消耗了更多算力。

具体来说，多 Agent 系统通过以下方式消耗额外算力：

当你控制住思考 token 预算（即只让每个系统用相同量的推理算力）时，多 Agent 的优势消失了。

传统比较（不公平）：
  单 Agent：1000 token 思考 → 75% 准确率
  多 Agent（3个Agent）：3500 token 思考 → 82% 准确率
  → 结论：多 Agent 更好 ✗（其实是算力差异）

Stanford 的控制变量比较（公平）：
  单 Agent：1000 token 思考 → 75% 准确率
  多 Agent（3个Agent，思考 token 均分）：1000 token 总预算 → 71% 准确率
  → 结论：单 Agent 更好 ✓（同等算力下单 Agent 更高效）

Swarm Tax 就是那 4% 的准确率损失，来自多 Agent 协作的协调开销和信息损失。

三、Data Processing Inequality：为什么多 Agent 会引入信息瓶颈

Stanford 的理论贡献是提供了信息论的解释：Data Processing Inequality（数据处理不等式）。

这个不等式的核心思想是：信息在经过处理节点时，只能减少，不能增加。

应用到多 Agent 系统：

任务信息
    ↓
Agent 1（分析）→ 提取信息子集 → Agent 2（实现）→ 提取信息子集 → 结果
         ↑                  ↑
      信息损失            信息损失

每个 Agent 只能处理完整上下文的一部分，然后把自己的「理解」通过文本通信传给下一个 Agent。这个文本化的过程必然丢失信息——你无法用有限的 token 完美表达你对一个问题的全部理解。

相比之下，单 Agent 在统一的上下文中进行连续推理，没有跨 Agent 的信息传递损失：

任务信息 → 连续推理（上下文始终完整）→ 结果

这就是为什么在同等算力下，单 Agent 的信息利用效率更高。

四、Stanford 论文的实证结果

4.1 核心实验设置

论文在三个模型家族上测试了多种多 Agent 架构（Planner + Executor、Role Playing、Debate、Tool-specialized），控制变量是每个系统的思考 token 总预算。

4.2 主要发现

发现 含义
SAS 在所有三个模型家族上匹配或超越 MAS 这个结论是跨模型通用的，不是某个模型的特性
MAS 的优势随预算增加而增加 当算力不受限时，多 Agent 可以「堆算力」来弥补架构劣势
API 预算控制存在 artifacts Gemini 2.5 的 API 层面思考 token 控制不稳定，导致测量偏差
标准 benchmark 存在漏洞 通过改写问题措辞可以暴露 benchmark 的过拟合问题

4.3 关键：「SAS-L」技巧

论文还测试了一个增强版单 Agent 策略：Single-Agent with Systematic Thinking（SAS-L）。

核心思路：不是让单 Agent 直接推理，而是在 Prompt 中引导它主动列出歧义、测试备选方案：

# 普通单 Agent Prompt
"分析这个需求，给出实现方案"

# SAS-L Prompt
"分析这个需求：
1. 列出所有可能的歧义点并分别给出解释
2. 针对每个歧义提供一个备选实现方案
3. 标注每个方案的风险
4. 选择最优方案并说明理由"

SAS-L 让单 Agent 充分「消耗」它的思考预算，而不是快速跳到第一个看起来对的方案。这让单 Agent 的表现进一步提升。

五、什么时候多 Agent 真正有价值

Stanford 的理论框架也预测了多 Agent 什么时候能赢：

5.1 单 Agent 的上下文利用率下降时

当任务涉及超长上下文或高度异构的信息源时，单 Agent 的上下文窗口会变得拥挤，有效利用率下降。此时多 Agent 可以分工，每人处理上下文的一个子集：

例子：代码库重构（10万行代码）
- 单 Agent：上下文塞不下，需要频繁的上下文加载/遗忘
- 多 Agent：Agent A 负责数据模型，Agent B 负责业务逻辑，Agent C 负责测试
  → 每人只关注自己那部分，上下文利用率反而更高

5.2 任务需要不同专业能力时

当任务需要本质上是不同领域的知识时，多 Agent 可以各自配备专用的系统 Prompt（角色）：

例子：前端 + 后端 + DevOps 的联合开发
- Agent Frontend：专注 UI/UX、系统提示词强调设计规范
- Agent Backend：专注 API、数据模型，强调安全最佳实践
- Agent DevOps：专注部署、监控、基础设施

每个 Agent 的「上下文」和「推理模式」天然就不同，分工不会损失信息——因为本来就不是同一种信息。

5.3 需要外部验证回路时

当任务的正确性需要独立的验证 Agent 来检查时：

例子：安全关键代码审查
- Agent Coder：生成实现
- Agent Security：独立审查（不使用 Coder 的推理上下文）
- Agent Review：综合两者给出最终判断

这里的「独立」是关键词——Security Agent 不能复用 Coder 的推理，否则就是 Data Processing Inequality 的受害者。

5.4 获得额外未计入算力时

当多 Agent 可以消耗比单 Agent 更多的实际算力时（不设上限），多 Agent 确实可以赢。但这时你需要问自己：你愿意为这个提升付多少 Swarm Tax？

六、单 Agent 充分释放能力的策略：SAS-L

对于大多数日常 AI 编程任务，先用足单 Agent 的能力。

6.1 强制歧义列出

在任务 Prompt 中加入：

在给出最终方案之前，先列出：
- 这个需求中可能存在的歧义（至少3个）
- 每个歧义的可能解释
- 每个解释对应的实现路径

6.2 备选方案强制生成

给出方案 A，同时给出：
- 方案 A 的替代实现路径（方案 B）
- 方案 A 和 B 的权衡分析
- 你选择 A 而非 B 的具体理由

6.3 显式思考预算分配

告诉 Claude Code 你愿意给它多少「思考预算」：

这个任务比较复杂，请：
1. 先花 3-5 分钟分析问题（不要急着写代码）
2. 列出分析过程的关键发现
3. 再开始实现

6.4 分步验证而非一次性实现

第一步：先实现核心数据模型（不包含业务逻辑）
第二步：运行测试验证数据模型正确性
第三步：添加第一个业务逻辑模块
第四步：重复第三步直到完成

每一步都在单 Agent 的高上下文利用率下执行，比一次性写完整个模块然后发现方向错了要高效得多。

七、架构决策框架：四步判断法

在决定用单 Agent 还是多 Agent 之前，问自己这四个问题：

第一步：这是多跳推理任务还是分工协作任务？

第二步：上下文长度是否超过单 Agent 的舒适区？

第三步：有没有额外的算力预算？

第四步：Agent 间通信是否会丢失关键信息？

八、给实际工作的建议

建议一：默认选单 Agent，再为它优化

对于 80% 的编程任务，单 Agent 够用。与其一开始就用多 Agent 架构，不如先把单 Agent 的使用技巧（SAS-L、分步验证）练熟。

建议二：只在出现明确信号时才拆分多 Agent

出现以下信号才考虑多 Agent 拆分：

建议三：如果用多 Agent，按「专业分工」而非「推理步骤」拆分

错误的拆分（按推理步骤）：

Agent 分析 → Agent 设计 → Agent 实现 → Agent 测试

每个步骤都在损失信息，Swarm Tax 最大化。

正确的拆分（按专业域）：

Agent Frontend（专业：UI/UX）
Agent Backend（专业：API/业务逻辑）
Agent QA（专业：测试/质量）

每个 Agent 的专业上下文不同，损失的信息是可以接受的领域边界。

建议四：记录你的 Swarm Tax

如果你在使用多 Agent 系统，记录：

这些数据才能告诉你，你的多 Agent 系统是否真的值得它的 Swarm Tax。

总结

多 Agent 系统不是银弹。它的优势往往来自更多的算力消耗，而不是架构本身的价值。这份「Swarm Tax」在以下情况是值得的：

但对于大多数日常编程任务，先充分释放单 Agent 的能力（SAS-L、分步验证），再考虑多 Agent 拆分。盲目的多 Agent 化只是在支付不必要的税，而得不到相应的回报。

记住：好的架构是那些在约束下仍然有效的架构，而不是那些只有在无限算力下才显得强大的架构。

参考文献