一句话：多智能体的好处，是挑任务发的
9 月 17 日提交的论文「Rethinking Multi-Agent Collaboration: When More Is Less」（arXiv 2609.19759）问了一个被热潮掩盖的基本问题：多智能体协作到底什么时候真的值？作者的答案不是站队，而是画边界——多智能体的系统性收益集中在「长程任务且子任务间依赖稀疏」的场景；而在紧耦合的顺序工作流里，单 agent harness 反而更优。
顺带说清与此前讨论的区别：过去几个月的多篇研究质疑的是多智能体的成本口径与评测方法——「省成本」的账算不平；这篇走得更前一步，它不满足于拆台，还给出了正面的机制设计：SAIGE，一种基于语义感知增量图演化的轻量协作机制。
边界是怎么画出来的
论文通过系统分析，把任务按两个维度切开：时间跨度（是否长程）与依赖结构（子任务之间耦合松紧）。结论相当清晰：当任务够长、而子任务彼此独立可并行时，拆给多个智能体有系统性收益——大规模检索综合、并行调研是典型；当每一步都精确依赖上一步的输出时，拆分反而引入协调开销与信息损耗，单 agent 走到底更快——多步代码改造、状态机式的流程是典型。
由此推出一个反直觉但诚实的推论：扩大 agent 池、加深递归层级，并不会单调提升结果。更多 agent 不等于更智能——拆分的收益由任务结构决定，而不是由 agent 数量决定。这个结论对当下流行的「堆 agent 数」式产品叙事，是一剂清醒剂。
SAIGE：把协作结构从设计时挪到运行时
机制层面，SAIGE 的核心动作是三个。其一，节点按需生成：agent 实例不再是预设好的固定团队，而是任务进行中按需产生、用完即弃——需要谁就生成谁，不养闲人。其二，边是语义依赖：智能体之间连不连线，不看组织架构图，看内容——通过基于内容的信息检索，判断谁的信息对谁有用，语义相关才建边。其三，图随任务演化：协作拓扑不是一次性画好的，而是随任务推进增量更新，新信息进来，图跟着长。
这套设计与主流「管理者—工作者」金字塔的差别在于信息流向：固定编排里，协调者要维护全局视图，上下文越滚越大；SAIGE 里，结构从内容里长出来，协调开销跟着实际语义依赖走，而不是跟着预设层级走。论文的实验显示，SAIGE 在长程复杂任务基准上，于上下文效率与任务成绩之间取得了更好的折中。
这个结果该怎么用
对正在设计多智能体系统的团队，这篇论文提供了一份可以照着做的检查单。拆分前先看任务结构：子任务之间是「松耦合可并行」，还是「紧耦合顺序依赖」——前者拆，后者别拆，硬拆就是花钱买协调税。拆完之后控制两个变量：agent 池规模与递归深度，两者都不是越大越好，收益递减来得比直觉早。
更值得吸收的是方法论：把「谁该参与协作」交给运行时的语义判断，而不是设计时的角色表。这一点对工具生态爆炸的今天尤其实际——智能体面临的候选工具、候选数据源越来越多，静态编排的维护成本会指数上涨，按内容动态建边是一条可行的出路。
放在领域脉络里看
近两个月的几篇研究，正在合力给多智能体热退烧：有的拆穿成本口径，有的给出效率评测的危机清单，这篇则把「何时该用」正面回答了。三者拼起来的图景是——多智能体不是通用加速器，而是一种有明确适用条件的架构选择，条件由任务结构决定。
这个共识的形成速度，比很多从业者预期的快。当「更多 agent」的叙事红利见顶，下一轮竞争的抓手会落在结构设计上：按需生成、语义建边、增量演化这些思路，很可能会被吸收进主流框架的下一版编排器里。对工程团队而言，现在值得做的不是急着重构，而是先给自己的核心场景画一张依赖结构图——你的任务是左边还是右边，答案就在那张图上。