“上多智能体”几乎是 Agent 项目的默认动作：一个主 Agent 调度几个子 Agent，看起来分工更清晰、能力更强。一篇 10 月 2 日挂出的论文（arXiv 2610.03010）用一组硬碰硬的测量，给这个默认动作泼了冷水：在五个软件工程任务上，多智能体设计平均多烧 6.36 倍的电、多跑 6.07 倍的时间，而准确率提升有限且高度依赖任务——最坏的单个任务硬件组合，慢到 160 倍。它要回答的不是“多智能体有没有用”，而是“你为多出来的 Agent 付的账，值不值”。
三个配置，同一组任务
研究者对比了从“非智能体单查询”到“多智能体工作流”的一串配置，覆盖六个开源权重模型、两种提示策略、三种硬件平台，任务包括代码生成、技术债识别、漏洞检测、日志解析与分析。结果里最扎眼的是帕累托前沿：在 66 个帕累托最优配置里，59 个落在非智能体或单 Agent 一侧。也就是说，当你同时权衡准确率、延迟和能耗，绝大多数“最优解”根本不需要多智能体。多智能体真正能稳定赢的，只有漏洞检测这一项——它靠子 Agent 分头试探，准确率确有提升，但其余四个任务并没有被证明值得那份开销。
“先跑基线”应成纪律
论文没有给出“永远别用多智能体”的结论，反而把发现翻译成了设计准则：在采纳多智能体流水线之前，先把同一批任务当成单查询、当成单 Agent 各跑一遍，记下 token、墙钟时间和通过率，只有当多智能体在噪声之外真正胜过基线时，才保留额外的 Agent。模型选型和提示策略也会随任务改变方向，不存在放之四海皆准的默认。研究者也坦承局限：只测了开源权重模型，没碰前沿闭源模型协调子 Agent 的情形，任务也是标准基准而非长达一周的重构。但这恰恰说明，很多团队在订阅额度或 API 账单上感受到的“变慢变贵”，可能正是无差别开多智能体带来的 6 倍乘数——而它常常没有换来等比例的准确率。
给工程实践的提醒
对真在跑 Agent 的团队，这篇研究的增量认知很实用：把“多智能体”当成可调开关而非默认开关。上线前做一张最小对照表，证明多出来的 Agent 在目标任务上确实赢过单 Agent 基线，再放行；否则，轻量配置往往既快又省，还更好解释。它和近期关于过程级评测、上下文精简的研究指向同一处——Agent 的竞争力正从“堆多少”转向“算得清”：算清每一次扇出的成本、算清每一步的轨迹是否可靠。可持续的智能体，不是最热闹的架构，而是每一次额外拆分都能在准确率、延迟、能耗三本账上说出理由的那一个。
值得一提，这篇研究的局限也决定了它的用法：它只测了开源权重模型，没碰前沿闭源模型协调子 Agent 的情形，任务也是标准基准而非长达一周的重构。但恰恰因为局限清晰，结论反而更值得信任——它没声称“多智能体没用”，只说“在你证明它值之前，默认开多智能体是贵的”。对中小团队尤其如此：没有规模化评测能力时，先用单 Agent 基线交差，往往既快又省，还更好解释给老板听。当订阅额度在午饭前就见底、API 账单月底吓人时，那 6 倍乘数会立刻现形。Agent 的竞争正从“堆多少”转向“算得清”，这篇论文给的正是这记提醒，也顺手给“无脑堆 Agent”这股风气泼了盆冷水：在没跑基线证明之前，多开的每一个子 Agent 都是成本而非能力，账本不会因为你叫它智能体就网开一面。先问一句值不值，再决定加不加人。