首页科技快讯 ICML 2026｜重新认识多智能体系统中的Orchestrator

ICML 2026｜重新认识多智能体系统中的Orchestrator

来源：晰数塔互联网快讯时间：2026年07月06日 16:31

南京大学人工智能学院博士生朱俊泽为本文第一作者，主要研究大模型多智能体理论、方法与框架；南京大学人工智能学院助理教授吴震为本文通讯作者，戴新宇教授为本文合作者。

现在，多智能体系统正成为大模型应用的主流范式。为了让模型完成更复杂的任务，人们开始把搜索、代码、视觉、总结等能力接入同一个系统：有人负责找资料，有人负责编程，有人负责调用工具，有人负责检查结果。架构图越来越复杂，执行日志越来越长，系统看起来也越来越像一支会分工协作的 AI 团队。但一个更基础的问题是：这支 AI 团队真的会协作吗？

来自南京大学 NLP 实验室的 ICML 2026 论文Recognize Your Orchestrator: An Entropy Dynamics Perspective for LLM Multi-Agent Systems指出：在当前主流的 Orchestrator-Executor 多智能体架构中，系统失败往往并不首先来自某个执行器不会干活，而是来自负责全局调度的 Orchestrator 逐渐失去对任务的掌控。换句话说，多智能体系统真正需要被重新认识的，是那个负责指挥所有 Agent 的 “调度中枢”。

论文标题：Recognize Your Orchestrator: An Entropy Dynamics Perspective for LLM Multi-Agent Systems作者：Junze Zhu, Weihao Chen, Xuanwang Zhang, Zhen Wu, Xinyu Dai单位：计算机软件新技术全国重点实验室；南京大学人工智能学院会议：ICML 2026论文链接：arXiv:2606.01351项目 / 代码：NJUNLP/orchestrator_entropy

多智能体系统的瓶颈：

Orchestrator 的脆弱性

在一个典型多智能体系统中，Executor Agent 负责执行具体任务，Orchestrator 更像一个项目经理，负责理解用户目标、拆解任务、选择合适的执行器、读取反馈，并决定下一步该做什么。这套结构看起来很自然：复杂任务被拆给不同 “专家”，各自完成后再汇总。但当任务链路变长时，问题就开始显现。

工具越多，历史日志越长，异常反馈越复杂，Orchestrator 面临的信息压力就越大。它可能派错 Agent，误读 Executor 的输出，陷入重复循环，提前终止任务，或者在遇到错误反馈后无法恢复。此时，系统失败并不是因为某个工具完全不可用，而是因为 Orchestrator 没有把工具用对。

论文对 Deep Research、Agent Coder、GUI Browser 和 Agentic RAG 等典型多智能体系统进行了失败归因分析。结果表明，在四类场景中，Orchestrator 承担了主要失败责任。这一发现将分析重点从 “单个 Agent 是否足够强” 转向了 “调度过程是否稳定”。

图 1：多智能体系统失败归因分析。Orchestrator 在四类系统中均承担主要失败责任。

用 “调度熵” 观察系统如何失序

Orchestrator 作为多智能体系统的调度者，每一步它都需要回答一个问题：下一步应该调用谁？当它非常确定时，选择会集中在少数几个合适的 Agent 上；当它不确定时，选择会在多个方向之间摇摆。这种调度分布的分散程度，就是论文关注的调度熵。从直观上看，Orchestrator 的调度过程受到两股力量影响：

任务推进带来的聚焦力：随着任务逐渐被解决，系统应该越来越清楚下一步该做什么，不确定性下降，调度行为趋于稳定。上下文累积带来的扩散力：每一轮工具调用、历史日志、异常反馈和中间结论都会进入上下文。信息越堆越多，噪声也随之增加，调度者反而可能被历史信息淹没，重新变得不确定。

因此，多智能体系统的稳定性，本质上取决于 Orchestrator 能否在越来越复杂的上下文中持续维持清晰判断。论文提出的Mean-Field Entropy Dynamics框架，正是用熵动力学刻画这一过程：任务解决带来 “聚焦”，上下文累积带来 “扩散”，二者共同决定系统是逐步收敛，还是走向失稳。这个视角的意义在于，它不再只是看最终结果，而是试图描述多智能体系统内部的不确定性如何随时间演化。

IWG：让过程变得可检查

要分析 Orchestrator 的调度过程，仅有最终答案远远不够。传统 benchmark 往往只提供初始问题和最终答案。对于多智能体系统来说，这相当于只知道项目最后是否成功，却不知道中间哪一步派错任务、读错反馈、哪个节点导致后续连锁偏差。

为了克服高质量智能体工作流轨迹中检查锚点的稀缺性，论文提出Inverse Workflow Generation（IWG）。它的核心思想是：不从问题正向采集轨迹，而是从目标答案出发，反向构造一个可执行、可验证的交互环境。整个流程包含三个组件：

Scout Agent：从最终答案倒推必要的中间任务，形成能力感知的任务标记。Wrapper Agent：将抽象任务落地为具体环境状态和工具反馈，而不是直接泄露答案。Validation Committee：通过多层验证保证任务可解、路径一致、事实可靠。

IWG 并不生成 Orchestrator 的执行轨迹，而是构造一个带有中间检查点的任务环境。真正的调度轨迹仍然由被测模型在该环境中自行生成。基于 IWG，研究者能观察到 Orchestrator 在每一步如何决策，以及它从什么时候开始偏离、震荡或坍缩。

图 2：IWG 系统流程。Scout、Wrapper 与 Validation Committee 共同构造具备中间检查点的可验证任务环境。

模型强，不等于会做 Orchestrator

图 3：完整模型测评主表。该表同时展示 System-Level 与 Orchestrator-Level 指标，是本文全部结果的主图。

论文搭建了一个包含 7 个 Executor Agent 的多智能体系统，并让不同大模型担任 Orchestrator，完成任务分解、执行器选择、反馈读取和异常处理。论文没有把结果简单处理成模型排行榜，而是同时考察两个层面：一是 System-Level，即整个系统最终是否完成任务；二是 Orchestrator-Level，即调度者每一步是否成功、是否忠实利用执行器输出、能否处理异常，以及整体轨迹是否保持一致。

实验显示，System-Level 与 Orchestrator-Level 并不总是同步。有些模型生成的工作流结构看起来接近参考路径，但最终任务完成并不稳定；也有些模型最终成功率不一定最高，却在 Step-SR、Consistency 等过程指标上表现更稳。这说明，多智能体系统中的 Orchestrator 能力，不能简单等同于单轮推理能力，也不能只用最终答案衡量。一个好的调度者，不只是 “聪明”，还要能在长链路、多工具、高噪声的上下文中维持稳定的全局判断。

从熵动力学角度看，不同模型呈现出不同调度风格：有些模型初始探索幅度大、路径切换频繁，能够快速展开候选方案，但更容易在后续步骤中失去稳定性；另一些模型调度更稳、熵增长更慢，更擅长在长程任务中维持一致性。

图 4：Mean-Field Entropy Dynamics 拟合结果。曲线展示任务推进与上下文累计如何共同塑造调度熵演化。

Reasoning Trap：想得越多，

不一定调度越稳

论文最反直觉的发现之一，是重推理模型在多智能体调度场景中未必更占优势。在封闭式推理任务里，更长的思考链通常意味着更充分的推理。但 Orchestrator 面临的是另一类问题：它每一步都必须读取用户目标、系统约束、历史执行日志、多个 Executor 的反馈和异常信息。如果模型在此基础上继续生成大量内部思考，有限的注意力预算就可能被自我生成内容挤占，导致外部关键信号被稀释。论文将这一现象称为 Reasoning Trap：模型不是不会推理，而是被自己的推理链挤压了用于观察外部环境的空间。

图 6：Reasoning Trap 实验。降低推理深度后，模型在调度效率和步骤成功率上反而呈现更稳趋势。

论文比较了不同推理深度设置下的模型表现。结果显示，抑制过度思考后，模型在调度效率和步骤成功率上反而更稳。这意味着，适合做 Orchestrator 的模型，并不一定是 “想得最长” 的模型，而是能够在复杂上下文中快速过滤噪声、理解反馈，并稳定决定下一步行动的模型。

写在最后

多智能体系统的能力上限，不只取决于执行器是否强大，也取决于 Orchestrator 是否能在长链路、多工具、高噪声上下文中保持稳定。论文提出的 Mean-Field Entropy Dynamics，为分析 Orchestrator 提供了一个可解释的动力学视角；IWG 则为过程级评估提供了可验证数据基础。

随着 Agent 系统继续走向更复杂的任务环境，单纯堆更多工具、更长上下文或更强执行器，可能并不足够。

未来更关键的问题是：

我们能否识别、度量并约束那个真正负责调度全局的 Orchestrator。

发布于：天津