原文：https://mp.weixin.qq.com/s/Gjngm7j1Uh8MfM3qjHJ8UA
一个让人不舒服的研究结论
2025 年 12 月，Google DeepMind 发布了一篇论文：《Towards a Science of Scaling Agent Systems》。
他们测试了 180 种 Agent 配置，跨越 5 种架构模式，使用 GPT、Gemini、Claude 三个模型族。结论里有一句话让很多人不舒服：
"在需要严格顺序推理的任务上（比如规划），我们测试的每一种多 Agent 变体都让性能下降了 39% 到 70%。"
不是某些配置变差了，是所有测试过的多 Agent 配置都变差了。
这不是小样本数据，是 180 种配置的系统性测试。多 Agent 在并行化任务上的收益是真实的------金融分析场景里，最优配置能带来 81% 的性能提升。但在顺序推理任务上，多 Agent 的性能退化同样是真实的，而且退化幅度更大。
更多 Agent 不等于更好的结果。 这个判断值得认真对待。
为什么多 Agent 会让顺序推理变差
理解这个问题，需要先理解多 Agent 的成本结构。
成本一：协调开销
5 个 Agent 的系统，协调延迟约 200ms；50 个 Agent，超过 2 秒。这是通信和状态同步的固定成本，和任务复杂度无关。
成本二：上下文碎片化
当推理需要跨多个步骤连贯地进行，把这个过程拆给多个 Agent，每个 Agent 只能看到自己的那一部分。协调者需要汇总所有 Agent 的输出，再做下一步判断------这个汇总过程本身就是信息的损耗。
成本三：错误放大
MAST 研究（2025 年 3 月）分析了 1,642 个执行轨迹，发现独立多 Agent 系统会将错误放大最高 17.2 倍。一个 Agent 的小错误，通过多 Agent 的传递链条，变成了大错误。
单 Agent vs 多 Agent：怎么判断
在决定用多 Agent 之前，应该先回答三个问题。
问题一：任务真的可以并行吗？
把任务列出来，问自己：这些子任务可以同时进行，还是大多数都要等前一步完成？
如果任务有强依赖关系（B 需要 A 的结果才能开始），多 Agent 的并行优势消失了，只剩下协调成本。这种情况，单 Agent 的 TodoWrite 按顺序执行往往更快、更可靠。
问题二：子任务真的需要"不同的专业"吗？
多 Agent 的价值来自专业化------不同 Agent 有不同的上下文和工具集，处理不同类型的问题。如果所有子任务都是同类型的工作，分给多个通用 Agent 处理，收益微乎其微，但协调成本是真实的。
问题三：现有的单 Agent 方案有具体的性能瓶颈吗？
Microsoft 的建议是：用单 Agent 证明价值，再投资多 Agent 协调。在没有具体数据证明单 Agent 遇到瓶颈之前，不要假设多 Agent 会更好。
三个框架各自怎么看这个问题
OpenClaw：多 Agent 是"可以做"，但不是默认的
OpenClaw 的多 Agent 支持通过 sessions_spawn 实现，主 Agent 派发子任务，子 Agent 独立执行后汇报结果。
官方文档对多 Agent 的适用场景描述比较保守：长期研究任务（需要并行探索多个方向）、内容创作（不同 Agent 分别完成研究、写作、审校）、系统监控（多个 Agent 各自负责不同的监控指标）。
注意这些场景的共同特征：子任务之间的依赖关系弱，可以真正并行，结果汇总相对简单。
maxConcurrent = 8 的硬上限------这不是技术能力的上限，更像是一个对"超过这个数量协调成本开始失控"的隐性承认。
Claude Code：官方明确给了单 Agent 优先的建议
Claude Code 官方文档对单 Agent 和多 Agent 的选择给出了明确的建议：
优先考虑单 Agent 的情况：
-
任务步骤有明确的先后依赖关系
-
修改同一个文件或共享状态
-
任务复杂但可以顺序执行
考虑多 Agent 的情况：
-
任务需要跨前端/后端/测试等不同层面并行推进
-
子任务真的可以独立并行，相互依赖少
-
需要相互验证、挑战方案的独立视角
推荐的生产甜点配置：2-5 个 Teammate，每人 5-6 个任务。 超过 5 个 Teammate，协调开销开始超过并行收益。
这和 DeepMind 的研究结论高度一致：3-5 个 Agent 的精简配置，持续优于大型多 Agent 团队。
子任务不要直接用 Agent Teams，而是用 Subagents------通过 AgentTool 派发，主 Agent 不等待子 Agent 完成就继续其他工作，结果返回后再处理。更轻量，协调成本更低。
Hermes Agent：通过成本设计来反映应该谨慎使用
Hermes 的多 Agent 设计在架构上选择了"一个 Gateway 对应一个 Agent"------不是限制，是设计哲学：每个 Agent 应该有清晰的职责边界，不应该用复杂的内部路由来模糊这个边界。
需要多个 Agent 时，启动多个 Hermes 实例。这让多 Agent 的成本显式化------你需要主动决定启动第二个实例，而不是在配置里轻描淡写地增加一个 Agent。
显式的成本，天然地抑制了滥用多 Agent 的冲动。
Hermes 的 Skills 共享目录是多 Agent 之间协调的替代方案：一个 Agent 积累的经验放进共享目录，其他 Agent 受益------不是实时的 Agent 间通信，而是通过知识积累实现的异步协调。这避开了实时多 Agent 协调的高成本。
多 Agent 的正确使用场景
综合研究数据和三个框架的实践，多 Agent 真正有价值的场景：
场景一：真正可并行的子任务前端开发、后端开发、测试编写可以同时进行，相互依赖少。Agent Teams 在这种场景下的效果有案可查。
场景二：需要独立视角的验证一个 Agent 实现，另一个 Agent 独立审查------审查者不读实现者的推理过程，才能真正独立。（如果读了全部推理过程，就失去了独立性。）
场景三：不同领域的专业分工协调者用便宜快速的模型做任务路由，执行者用高质量模型做核心工作------这不只是多 Agent，也是模型分层的成本优化。
场景四：需要持续监控的多维度系统多个 Agent 各自监控不同的指标，异常时汇报------子任务完全独立，不需要实时协调。
什么时候单 Agent 更好
顺序依赖任务： 步骤 B 需要步骤 A 的结果。单 Agent 用 TodoWrite 顺序执行，不需要协调开销。
修改共享状态： 多个 Agent 同时修改同一个文件，产生冲突的概率超过了并行收益。
任务不够复杂： 简单任务的协调成本可能超过任务本身的执行成本。
调试优先： 单 Agent 的执行轨迹是线性的，出了问题知道在哪里。多 Agent 的问题可能在任何一个 Agent 里，调试难度指数级上升。
团队还没有多 Agent 的运维经验： 多 Agent 系统的可观测性需要额外投入------每个 Agent 的状态需要单独追踪，错误传播需要跨 Agent 追溯。在建立这个能力之前上多 Agent，往往是增加了风险而不是收益。