最近看到一个说法我觉得挺到位的：很多Multi-Agent系统本质上是在用人脑的限制去套AI。人类之所以有产品经理、前端工程师、后端工程师、测试工程师这些分工，是因为一个人的精力和认知带宽有限，不可能精通所有工种。但AI没有这个限制。把人类的组织架构原封不动搬到AI上，结果就是花了几倍的Token，效果反而更差。
Google和MIT的一项研究发现了一个"45%阈值规则"：如果单个Agent的基础准确率超过45%，增加更多Agent通常会让性能下降，而不是上升。在顺序任务上，添加Agent和工具甚至导致性能下降高达70%。这个数据挺打脸的。
多Agent到底浪费在哪里
最直接的浪费是Token。每个Agent都有自己的上下文窗口，Agent之间传递信息需要反复加载和传输上下文。Anthropic自己的研究表明，并行subagent架构的Token消耗是单Agent的15倍。Reddit上有人报告自己的多Agent系统每月烧400美元Token，其中55%是浪费。
系统提示词也要重复加载。每次调用一个Agent，都要把system prompt塞进去一遍。如果你有5个Agent，同样的指令就要重复5次。这不是智能，是重复劳动。
更麻烦的是错误会级联。一篇叫《Agents of Chaos》的arXiv论文发现，多Agent系统中一个Agent犯错时，其他Agent往往不会纠正它，反而会"从众"认同错误答案。错误在系统里越滚越大，而不是被修正。
还有工具膨胀的问题。连接多个MCP服务器会把整个工具目录注入Agent的上下文窗口，Agent得先花大量Token"阅读手册"才能开始干活，结果就是"工具抖动"和幻觉。
实际产品已经证明了这一点
看看现在的AI编程工具就知道了。Claude Code本质上是单Agent架构，Opus 4.5在SWE-bench上拿到80.9%。OpenAI的Codex CLI也是单Agent，GPT-5.3在Terminal-Bench 2.0上拿到77.3%。OpenAI Frontier团队用单Agent运行，3到7个工程师零手写代码，产出了大约100万行生产代码，单次Agent运行能持续6小时以上。
反观多Agent架构的代表Devin，$500计划已经取消了，用户反馈是"更难预测、更难控制"。Cursor 2.0搞了一个三层架构（规划者、执行者、评审者）去构建浏览器，独立审查发现发布时代码无法编译，100个最近的commit里每一个都有某种失败，页面加载需要整整一分钟。CEO自己的评价是"It kind of works"——勉强能用。
Reddit r/AI_Agents上一个帖子标题很直白："Multi agent systems are a total nightmare in production"（多Agent系统在生产环境就是噩梦），拿了57票和64条评论。另一个帖子引用了Google/DeepMind/MIT的论文，标题是"Single Agents win against Multiple Agents"（单Agent赢了多Agent）。
人类分工的本质是什么
回到最开始的问题。人类社会的分工体系是亚当·斯密在《国富论》里讲的那个道理：每个人专注于自己最擅长的事情，通过交换来获得整体效率的提升。但这个逻辑的前提是——人的能力有上限。一个人不可能同时是优秀的外科医生、律师和程序员。
AI没有这个限制。一个模型可以同时理解代码、法律文档和医学影像。它的"能力带宽"不是固定的。用人类的组织架构去约束AI，就像给一辆汽车装上四条腿——你可以这么做，但为什么要这么做？
Karpathy说"90%的AI建议是噪音"，单Agent循环的扩展性超出预期。Anthropic和OpenAI都说了同一句话：先最大化单Agent能力，再考虑多Agent。唯一被验证有效的多Agent形态是层级式的——一个编排Agent加多个专职子Agent，而不是一群平等的Agent互相传话。
什么情况下多Agent才有意义
不是说多Agent永远没用。Google的研究也说了，当单Agent基础能力低于45%时，多Agent协作确实有帮助。但这时候多Agent更像是一种"集思广益"的策略，而不是模拟人类分工。
真正需要多Agent的场景是：任务可以被拆分成完全独立的子任务，并且这些子任务之间不需要频繁交换上下文。比如同时处理100个独立的文件转换任务，用多个Agent并行处理是合理的。但如果是一个需要深度推理的连贯任务，拆成多个Agent只会增加通信开销和出错概率。
一个务实的选择：用一个强大的单Agent加上精心设计的工具集，只在真正需要时引入层级式的多Agent协作。不要因为人类是这么组织的，就觉得AI也该这么组织。人类的限制不是AI的限制，把人的框架硬套在AI上，浪费的不只是Token，还有想象力。