南京大學人工智能學院博士生朱俊澤為本文第一作者，主要研究大模型多智能體理論、方法與框架；南京大學人工智能學院助理教授吳震為本文通訊作者，戴新宇教授為本文合作者。

現在，多智能體系統正成為大模型應用的主流范式。為了讓模型完成更復雜的任務，人們開始把搜索、代碼、視覺、總結等能力接入同一個系統：有人負責找資料，有人負責編程，有人負責調用工具，有人負責檢查結果。架構圖越來越復雜，執行日志越來越長，系統看起來也越來越像一支會分工協作的 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。