編排計畫模擬

資料來源#

摘要#

這個領域的每一項多代理程式基準測試都會端到端執行整個系統，因此分數是編排品質、工作者能力、工具可靠性與環境雜訊的總和——無法從總分中單獨讀出第一項。OrchBench（Zhenzhen Ren、Jiyan He、Xinpeng Zhang、Zhenxing Qian、Ke Han、Shuxin Zheng、GuoBiao Li、Xiaoqing Zhang——復旦大學／中關村學院／倫敦瑪麗女王大學，arXiv 2607.25656，2026-07-28，empirical）採取事後看來顯而易見的做法：**移除工作者。**受評估的模型只產生一份計畫；確定性模擬器沿著計畫傳遞品質、時間與 tokens，並回傳分數和協調失敗清單。

讓這項方法實用的主張，是模擬到真實執行的關聯：模擬分數與實際 Claude Code 執行品質的 Pearson 相關係數為 r = 0.816，同時只耗用 1.3% 的 tokens 和 10.3% 的實際時間。讓它值得關注的主張，則是它接著量測到的現象——在工作流程規模下，編排品質受限於資訊保存，而非代理程式數量。

「計畫」的形式化定義#

這一節最經得起時間考驗：一份已發表、可供檢驗的定義，說明編排所產生的產物是什麼。

固定輸入（明確不屬於編排決策）：任務 DAG G = (V, E)，其中邊 (u, v) 表示 v 需要 u 的輸出；每個代理程式的上下文限制 L；代理程式數量上限 A_max。每個子任務都包含描述、輸入／執行／輸出 token 預算、時間預算，以及 {robust, balanced, fragile} 壓縮敏感度類別。

計畫為 π = (α, R)。指派函數 α 將每個子任務對應至一個代理程式。R 宣告跨代理程式的資訊傳遞；每次傳遞都帶有介於 (0, 1] 的保留率 e，表示上游輸出有多少能在交接後保留下來。同一代理程式內的相依內容會在本地重複使用，不計成本。研究定義並評分兩類錯誤：

遺漏傳遞——相依邊跨越不同代理程式，但計畫未宣告資訊傳遞。模擬器會記錄此事件，並將父項的貢獻乘上懲罰值 λ = 0.5。
無效傳遞——宣告了傳遞，卻沒有對應的邊。遺漏子任務、超出 A_max、使用無效識別碼或宣告非法傳遞的計畫，分數都會是零。

規劃器不會逐一列舉指派方式，而是以 JSON 輸出精簡的宣告式 workflow_script，再由確定性直譯器依拓樸順序展開：agent_pools（名稱＋數量）、依序比對任務階段並指定代理程式池與指派 strategy（round_robin、dependency_locality、load_balance）的 rules、default 規則，以及比對父項／子項階段並帶有 cross_agent_only 旗標與 compression 比率的 transfer_rules。這是一套完整公開的第三方編排計畫詞彙——下方的 Dynamic Workflows: An Algebra for Agents 連結說明了這為何重要，以及它仍未解決哪些問題。

模擬器#

六個階段呼應真實框架的生命週期——相依解析、代理程式排程、取得上下文、管理上下文、執行子任務、更新狀態——並依固定拓樸順序處理，因此相同計畫永遠得到相同結果。這套運作機制是參數化的，而非實測所得：

機制	模擬成本
壓縮至比例 `e`	品質乘上 `e^γ`，其中 `γ` 對 robust／balanced／fragile 分別為 0.35／0.85／1.25；最低保留率為 0.08／0.22／0.55
一次壓縮事件	壓縮前封包大小的 2.5%（以 tokens 計），另加一個時間單位
傳遞 `x` 個保留 tokens	`x` 個通訊 tokens，`max(1, ceil(x/5000))` 個時間單位
每個啟用的代理程式	1,200 個啟動 tokens、2 個啟動時間單位
遺漏必要交接	上游品質乘上 `λ = 0.5`，不耗用 tokens 或時間

評分是三項指標的不加權平均：品質 Q（終端任務的宏平均）、E_time = min(1, C/M)（接近關鍵路徑上限的程度），以及 E_token = min(1, T_single/T)（相對於單一代理程式序列執行基準的 tokens 效率）。

請仔細看 token 指標。它是以單一代理程式序列執行為基準，最高只計到 1，因此多代理程式計畫無法因為比序列執行更省成本而得分——實際上也沒有任何一個計畫接近這點。整體結果中，多代理程式的 token 效率介於 0.56 至 0.74，也就是說，光是代理程式啟動、通訊和壓縮的開銷，編排大約就耗用單一代理程式序列執行 1.5 倍的 tokens。在這套計算方式下，編排從不節省 tokens；它換來的是上下文壓力下的品質，以及較短的實際執行時間。

資訊傳遞覆蓋率比代理程式數量更關鍵#

這是最重要的發現，也是消融實驗證明該基準確實旨在觀察的現象。

依 DAG 大小排列的診斷指標與結果之間的 Pearson 相關係數（表 5）：

n	代理程式數量–Q	覆蓋率–Q	代理程式數量–分數
10	0.468	0.952	-0.481
20	0.720	0.807	0.218
50	0.470	0.829	-0.189
100	-0.021	0.614	-0.676

到了 100 個子任務時，代理程式數量與品質完全不再相關；在規模兩端，它與總分甚至呈現負相關。資訊傳遞覆蓋率則始終具有參考價值。最清楚的單一比較，是 n = 100 時兩個規劃器在其他重要方面都相近：Gemini-3.1-Pro-Preview 和 Doubao-Seed-2.0-Mini 都執行約 63 個代理程式；兩者遺漏傳遞的數量分別為 0.07 和 22.70，品質分數則分別為 0.690 和 0.443。

代理程式預算也會各自飽和。在六個規劃器和 50 個 DAG 上，將 A_max 依 {1, 2, 4, 8, 16, 32, 64} 掃描（圖 4），品質與分數從 1 增至 8 時大幅上升，之後便趨平：從 16 增至 64，代理程式數量增加一倍以上（約 13 個增至約 29.5 個），分數卻只變動約 0.01。

難度也不是由規模決定。依 DAG 的自然平行度切分 100 個任務的結果（表 18），顯示兩種不同的失敗模式，而非單一漸進變化：低平行度圖會執行 39.25 個代理程式，覆蓋率為 0.858、遺漏傳遞 23.47 次，最終分數卻仍是最高的 0.585；高平行度圖會執行 79.58 個代理程式，覆蓋率為 0.992、遺漏傳遞 1.77 次，最終分數卻是最低的 0.494。低平行度 DAG 因資訊鏈斷裂而失敗；高平行度 DAG 則付出協調成本。

可靠性斷崖式下跌，而且因模型而異#

在 A_max = 100 下將 n 擴大至 {200, 500, 1000}（圖 5），Claude-Opus-4.8 在 500 至 1,000 個子任務間的資訊傳遞覆蓋率，從 0.981 暴跌至 0.441；DeepSeek-V4-Flash 則從 0.981 暴跌至 0.398——分別遺漏 872.3 和 907.4 次傳遞——而 Gemini-3.1-Pro-Preview 保持近乎完整的覆蓋率，品質也明顯較高。這不是緩慢下滑，而是斷崖式變化；而且不是每個模型都會如此。端到端基準測試也看不出這點，只會回報執行結果不佳。

同樣地，沒有任何模型能在所有規模都勝出：GPT-5.5 在 n = 10 領先、GLM-5.1 在 20 領先、Claude-Opus-4.8 在 50 領先、Gemini-3.1-Pro-Preview 在 100 領先——而同一來源系列內，前兩名的差距最小可達 0.0007。研究將 Claude-Opus-4.8 描述為保守交接型規劃器：它幾乎從不遺漏傳遞（n=10 和 n=20 時遺漏數為 0.00），並能保留品質；但它的綜合分數較低，因為綜合分數也會計入速度與 tokens。最終分數是 Pareto 摘要，不是品質排名。

多代理程式是解決上下文溢出的手段，不是能力倍增器#

這是最能直接用於部署的結果。以相同 50 個 DAG 掃描每個代理程式的上下文限制（表 6 和表 19），多代理程式相對於單一代理程式序列執行的品質優勢單調遞減：

L	單一代理程式 Q	多代理程式 Q	Δ
16k	0.423	0.725	+0.302
32k	0.649	0.821	+0.172
64k	0.792	0.852	+0.060
128k	0.852	0.859	+0.007

到了 128k，平均優勢幾乎消失，結果分布也已經反轉：**在 82% 的模型－問題配對中，多代理程式品質低於單一代理程式。**正向平均完全由 100 個子任務的問題帶動；在這些問題中，單一代理程式仍須承受約 240 次壓縮事件，多代理程式品質高出 0.362。至於 10、20 和 50 個子任務的問題，單一代理程式早已勝出。Doubao、Kimi 和 Qwen 在 128k 時都低於單一代理程式基準。

作者自己的說法是：當工作狀態超過單一上下文視窗時，增加代理程式會有幫助；而**「一旦狀態放得進視窗，協調就可能只剩開銷。」**

生產端的呼應，以及雙方都未測試的另一半#

上述兩項發現——協調結構比代理程式數量更重要，以及多代理程式的優勢來自上下文容量效應——都在一項早八天發表、未使用模擬器的生產研究中找到對照。Cursor 重建代理程式群集的研究（Agent swarms and the new model economics，2026-07-20，case-study）以舊、新兩套 harness 從頭重建 SQLite，並固定模型和時間預算。單靠協調機制，就將合併衝突從超過 70,000 次（而且持續加速增加）降至 <1,000 次；最熱門檔案的衝突數從 7,771 降至 47；crate 數量從 54 降至 9；引擎行數從 64,305 降至 9,908，同時維持相同的測試通過等級（Parallel Agent Orchestration）。

兩項研究有兩個直接的交集，不只是類比：

Cursor 解決規劃器互相干擾的方式，就是一種資訊傳遞機制。代理程式會把決策記錄在共用設計文件中；相依程式碼會帶上經過編譯器檢查的參照，指回相應文件；整合器會合併互相矛盾的文件，再由參照將解決方案往下游傳遞。這是在代理程式之間宣告、具型別且強制執行的資訊傳遞——正是這項基準以 R 隔離的物件，而編譯器則藉由拒絕建置，扮演遺漏傳遞懲罰的角色。
**Cursor 將群集擴展的原因歸於上下文效率，而非平行度。**這與上下文掃描得出相同結論，來自一套使用真實工作者的系統（Multi-Agent Collective Intelligence）。

**但兩項研究改變的是互不相交的變數，彼此都沒有測試對方的變數。**OrchBench 掃描代理程式數量和上下文限制，並將協調機制固定為抽象設定；Cursor 重建協調機制，卻從未回報或改變代理程式數量。因此，「結構勝過規模」的兩半各有一項來源支持，但沒有研究端到端驗證整個主張。謹慎的共同結論比表面看來更有限：增加代理程式會飽和（模擬測得）；打造協調層值得投入（實測，但未做消融，而且研究由供應商撰寫）。Cursor 也與一項可部署推論相矛盾——它聲稱拆解工作「即使在中等大小的任務中」也有幫助，但上下文掃描指出，一旦狀態能放進單一視窗，優勢就應該消失。

用真實情況驗證模擬器#

研究分成三個獨立驗證面向，結果並不一致。

結果一致性。在 MultiAgentBench 上，模擬最終分數與實際 Claude Code 任務品質的 Pearson 相關係數為 r = 0.816（p = 0.047），Spearman 相關係數為 0.771（p = 0.103）。模擬的時間和 token 相關係數分別為 -0.264 和 -0.607，兩者均未達顯著；作者將此歸因於框架差異（跨框架時間相關係數為 -0.104；在 Claude Code 內，時間和 token 使用量的相關係數為 -0.126），並將兩者降為診斷指標。因此，綜合分數有三分之二只在內部量測上得到驗證。

**結構一致性。**模擬與真實編排行為在模型層級的一致程度：宣告的代理程式數量 0.973、委派傾向 0.928、工作流程深度 0.887、啟動的代理程式 0.829、平行使用率 0.768、完成任務的代理程式 0.749、資訊損失率 0.664（p = 0.157）。七項中最弱的指標，量測的正是遺漏資訊傳遞——論文核心發現所依據的確切機制。

**成本。**每項任務的成本：WideSearch 從 17.35M tokens 降至 44.61K（389 倍），時間從 56.13 分鐘降至 0.51 分鐘（110 倍）；MultiAgentBench 從 383.09K 降至 5.16K（74 倍），時間從 5.61 分鐘降至 0.58 分鐘（9.7 倍）。

論文只從有利方向呈現的但書#

以上所有結果都只建立在六個模型上。逐一移除模型的表格是論文中資訊量最高的部分，正文卻只引用了其中最佳的一列：

設定	Pearson r	p
原始結果	0.816	0.047
移除 GLM-5.1	0.949	0.033
移除 Kimi-K2.6	0.790	0.108
移除 Qwen3.6-A3B	0.719	0.167
移除 DeepSeek-V4-Pro	0.682	0.192
移除 DeepSeek-V4-Flash	0.677	0.183
移除 Doubao-Mini	0.421	0.500

移除最弱的規劃器後，相關係數從 0.816 降至 0.421，p 值為 0.500。七列中只有兩列達到 p < 0.05。較誠實的解讀是：**r = 0.816 表示模擬器能區分好規劃器和差規劃器，不代表它能準確預測兩個實力相近的規劃器誰高誰低。**這也符合論文實際展示的用途——它主張的是篩選能力（Top-1 模型選擇涵蓋率為 61.5%，歷史最佳基準為 38.6%；只執行分歧最大的五項任務後，排名一致性 Spearman 相關係數為 0.754，隨機挑選則為 0.176），而非排名能力。作者自己的建議是「先做初步篩選，再於目標框架中驗證」。

另一個令人意外的結果：真實框架彼此的一致性更低#

跨框架驗證（圖 3）被列為穩健性檢查——OrchBench 與 Claude Code／SWE-mini／OpenHands／Crush 的 Pearson 相關係數分別為 0.82／0.73／0.63／0.39。但同一個矩陣也顯示，**Claude Code 與 SWE-mini 的相關係數為 0.37、與 OpenHands 為 0.27、與 Crush 為 0.08。**四種真實 harness 彼此之間的模型排名一致性，低於模擬器與其中任何一種 harness 的一致性。這顛倒了通常的層級：如果「以真實執行驗證」指的是對照單一 harness，而它的排名幾乎無法推廣至隔壁的 harness，那麼真實執行作為基準的說服力就不如聽起來那麼強——這是模擬器忠實度問題底下的量測工具差異問題。

消融實驗是少見而清楚的構念效度說明#

對相同計畫逐一停用個別機制後重播，並量測 n = 100 時強規劃器（Gemini）與弱規劃器（Doubao）之間的差距：

設定	Δ品質	Δ分數
完整基準	0.247	0.079
無遺漏傳遞懲罰	0.011	0.001
自動補齊遺漏的傳遞	0.035	0.020
自動補齊＋無損壓縮	-0.001	0.008

將兩種資訊損失機制都停用後，**兩個規劃器的 Q 都落在約 0.933，無從區分。**從另一側看，λ 掃描也得到相同結論：λ = 1（沒有懲罰）時，跨模型品質標準差降至 0.022，Gemini 與 Doubao 的差距降至 0.011；選擇 λ = 0.5，則是為了保留 σ = 0.081 和 0.247 的差距。

兩種解讀都成立。善意來看：這項基準的區辨力完全來自兩個明確列出、可供檢查的機制，而不是不透明的綜合指標；這展現的構念效度，比多數基準都更充分。較不客氣地說：**OrchBench 量測的是壓縮下的資訊保存，而它用「編排能力」來稱呼這件事。**能完美傳遞資訊、排程卻一團糟的規劃器，受罰不重，因為研究刻意讓排程不成為變異主要來源。

將它用作診斷工具#

最具實務意義的部分規模最小。在 20 項 MultiAgentBench 任務中（由 DeepSeek-V4-Flash 執行，V4-Pro 評估），研究者為每個基準工作流程 A 增添且只增添一次由模擬器選出的跨角色交接，產生工作流程 B，其他條件保持不變。真實執行的平均分數從滿分 5 分的 3.754 升至 4.150，而模擬的遺漏傳遞次數從 6.80 降至 5.85。

值得記錄的是：模擬品質從 0.1452 升至 0.5111，變化達 3.5 倍；真實分數卻只上升約 10%。**模擬器的敏感度遠高於它所預測的結果。**診斷資訊（哪一次交接被遺漏）能轉移到真實執行，變化幅度則無法轉移。

第二個較弱的驗證面向：給 DeepSeek-V4-Pro 一份生成的 500 子任務 DAG，而非只有原始任務描述，在十項任務上將準確率從 2/10 提升至 3/10。n = 10 時只有一項任務翻轉——方向上有啟發性，統計上卻毫無定論；論文也如此呈現。

它沒有評估的項目#

**任務分解是固定輸入。**DAG 已經給定。如何切分任務——可能是編排中較困難的那一半，也正是可由代理程式擴展的工作圖所動態處理的部分——按設計不在範圍內。
**工作者從不執行。**結果品質只是經由保留率和壓縮指數，由父項品質傳遞而來的純量。計畫不會因代理程式誤讀任務簡述而失敗，也不會有能力出眾的代理程式挽救糟糕計畫。語料庫中所有關於代理程式轉述未經查證的子代理程式主張、只做到目標字面要求，或覆蓋彼此工作的案例，在這裡全都看不見。
**DAG 由 LLM 生成，也由 LLM 審查。**抽樣的 70 個 DAG 中，有 24 個（34.3%）至少遭到一名評審拒絕；剩餘的失敗模式都屬於語意問題——重複的驗證層（9.6%）、未依據起始內容的任意切分（6.7%）、人為過度分解（6.3%）、在最終彙整前漏掉分支（5.0%）、人為建立全域同步屏障（5.0%）。兩名 LLM 評審對通過審查的 DAG 也有顯著分歧（不同目標大小下，Gemini 給予的整體分數為 71.50–98.40，GLM 則對相同圖給出 75.75–85.00）。
**運作機制是自行設定的，並非實測所得。**壓縮指數、2.5% 的壓縮開銷、代理程式啟動所需的 1,200 個 tokens，以及 λ = 0.5 全都是參數；消融實驗也顯示結果至少對 λ 相當敏感。

延伸閱讀#

Open-Ended Discovery Harnesses — 本基準按設計排除的情境，並以真實代理程式測量。OrchBench 在固定分解的相依 DAG 上為計畫評分，編排者的任務是在子任務之間傳遞資訊；開放式探索完全沒有預先分解，編排者要做的是將一群代理程式分配到彼此競爭的方法。兩者從相反方向得出相容的解讀——此處能擴展的是被傳遞的資訊；彼處則發現，傳遞過多資訊（每個代理程式都能讀取的共用記憶體）會使整個群體收斂到同一種方法。該研究的規模掃描，是對代理程式數量上限掃描的真實執行補充：五項任務中有四項的最佳固定寬度 × 深度組合不同，而最寬的設定從未最理想
Measuring Beyond Accuracy Saturation — 方法論上最相近的研究，從相反方向得出相同結論。該文在執行後拆分模型和 scaffold，發現兩種 scaffold 會讓準確率相差約 44 個百分點，且在 31% 的任務上意見不一；本文則完全不執行，讓計畫成為唯一變動因素。兩者都是重新設計量測方式，而非直接退役並替換既有方法；兩者也都發現，變異來自堆疊中非模型的部分。本文的跨框架矩陣也提供一項該文模型與 scaffold 小節暗示卻未量測的數據：四個真實 harness 之間，對相同模型的 Pearson 相關係數僅為 0.08–0.84，因此「scaffold 很重要」和「真實執行是嘈雜的基準」其實是同一件事
Parallel Agent Orchestration — 提供該文供應商證據中缺少的「何時分散工作」量化數據。Opus 5 卡片在每個代理程式 1M tokens 下測得多代理程式 Pareto 優勢；OrchBench 的上下文掃描則顯示，這項交換中屬於品質的優勢，會從 16k 時的 +0.302 降至 128k 時的 +0.007；在高端設定中，82% 的模型－問題配對由單一代理程式勝出。這為提示指南中「限制委派」的提醒提供了有明確門檻的理由，也量化了指南只提及、未估價的開銷——在任何品質收益之前，就要付出約為序列執行 1.5 倍的 tokens
Dynamic Workflows: An Algebra for Agents — 兩個直接交集。OrchBench 的真實執行部分就是在動態工作流程設定下執行 Claude Code，這是該功能首次出現的外部量測。此外，它的 workflow_script 是一套公開的計畫詞彙，恰好對應 Cherny 所稱的「代理程式代數」：代理程式池、依序比對的規則、指派策略，以及每條邊都設有壓縮率的資訊傳遞規則。請留意這套詞彙不包含什麼——它是在固定 DAG 上宣告比對規則，而非序列／平行組合子；因此它展示了公開的編排詞彙可以是什麼樣子，卻沒有透露 Anthropic 尚未公開的那套詞彙
Context Lifecycle Management — 相同的取捨以成本函數而非政策呈現。Self-GC 量測哪些上下文編輯會破壞未來相依資訊；OrchBench 則模擬這點：fragile／balanced／robust 指數是「不要遮蔽稀疏表格和堆疊追蹤」的參數化形式，遺漏傳遞則是以 λ = 0.5 計價的定位資訊／即時狀態損失項目。兩者在精確意義上互補——Self-GC 為前綴快取中斷計價，並將資訊損失視為應避免的事；OrchBench 為資訊傳遞計價，並將上下文限制視為需要繞道處理的事。只有上下文壓力下才出現的多代理程式優勢，是 Self-GC 的單一代理程式內部結果在架構層面的推論：將狀態分散到不同代理程式，以及管理單一代理程式內的狀態，是處理同一種溢出的兩種方法；而當視窗夠大時，第一種方法便不再值得投入
Client-Side Agent Optimization — 使用第二種工具佐證規劃器角色的發現。AgentOpt 發現，在 HotpotQA 上最強的模型反而是最差的規劃器（Opus 4.6 繞過了自己的解題器）；OrchBench 透過設計隔離規劃器角色，發現沒有任何模型能在所有規模領先，同一來源系列內前兩名差距小到 0.0007，且不同模型有各自的編排風格（Claude-Opus-4.8 交接謹慎，Doubao 則過度啟動代理程式，同時少宣告資訊傳遞）。規劃能力並非一般模型能力的投射——如今已有兩種量測方式支持這點：一種是在真實流程上使用多臂賭徒演算法，另一種則以模擬器評估計畫
Multi-Agent Collective Intelligence — 對多代理程式擴展定律的近期同質群體測試，在群體規模這個面向得到負面結果：當工作者完全相同、只有計畫不同時，能力不會隨群體大小提升（到了 n = 100，代理程式數量與品質不再相關，且與綜合分數呈負相關），群體只在工作狀態超過單一上下文視窗時才勝過單一代理程式。真正能擴展的是資訊保存。需要保留的界線是：模擬工作者無法專門化，因此這項結果界定的是平行化因子，對透過專門化帶來多樣性則沒有定論。該文如今也提出一個解釋本文平坦曲線的候選機制，證據來自控制理論測試平台，而非代理程式；值得一讀的原因在於，兩者如何調和取決於需要記憶的狀態是否能夠切分。此處可以切分：計畫會將每項子任務指派給一個代理程式，因此群體規模會增加有效上下文；視窗夠大之前，多代理程式確實有優勢。彼處則無法切分：每個代理程式面對相同擾動，因此增加寬度無法平均掉任何結構性因素，能力下限與群體大小無關。兩者最後都同意真正可部署的部分——能擴展的是對共用結構的覆蓋率，而非人數
Ticket-Driven Agent Orchestration — Symphony 的 blocked_by 相依圖，是 OrchBench 輸入在實際部署中的形式；兩者的差異在適用範圍：Symphony 的 DAG 可由代理程式擴展（代理程式會建立後續工單，圖在執行期間持續增長），而 OrchBench 將 DAG 視為既定輸入並凍結。基準中的跨代理程式傳遞物件，也明確指出工單模型未明說的一件事——當一張工單的輸出是指派到其他代理程式的另一張工單之先決條件時，必須有某種方式承接結果，而品質量測結果正是在這次交接上變化
Cursor — 生產環境中的代理程式群集，重建成果呼應本文「結構勝過規模」的發現；其中經過編譯器檢查的設計文件參照，則是已部署的資訊傳遞物件
Claude Code — 真實執行的驗證面向，也是模擬到真實執行的對照目標；在四個框架中，也是唯一公開動態工作流程編排模式的框架
Claude Opus 4.8 — 被描述為保守交接型規劃器：小規模時幾乎不會遺漏傳遞，n = 50 時綜合分數最佳，但子任務從 500 個增至 1,000 個時，資訊傳遞覆蓋率從 0.981 暴跌至 0.441
Intra-Trace Parallel Planning (SPRINT) — 從相反方向切入相同物件，也就是任務 DAG：OrchBench 在工作者執行前為計畫圖評分；SPRINT 則在推理軌跡已經執行後（讓第二個模型為其加上標註）還原圖，再將它訓練回生成器
Task-Specific Organizational Hierarchies — 在不同領域、不同「結構」意義下，呈現同一種需要評論者來檢驗自動生成結構的模式：OrchBench 自行生成的任務 DAG，有 34.3% 在使用前遭 LLM 評審拒絕；ORCH 生成的代理程式階層若沒有評論者，則深度明顯較高、平衡性較差，在相同四種基準下的分數是 43.63%／52.53%，而非人工設計結構的 63.97%／74.29%——兩者都顯示，模型提出的協調結構可以使用，卻無法自行證明可靠

尚待解答的問題#

r = 0.816 的模擬到真實執行相關性，在一群實力相近的規劃器中是否仍然成立？逐一移除模型後，移除六個模型中最弱者，相關係數就降到 0.421（p = 0.500）；七列中只有兩列達 p < 0.05，因此忠實度主張可能完全來自強弱模型間的差距。要解決這個問題，需要對十個以上的前沿級規劃器執行測試，並排除能力較弱的尾端樣本。
多代理程式與單一代理程式的交叉點，在真實執行中是否依然成立？模擬中的優勢從 16k 時的 +0.302 降至 128k 時的 +0.007，且在 82% 的模型－問題配對中反轉；但模擬中的單一代理程式只承受壓縮損失，沒有為注意力退化、分心或長上下文回憶失敗計價，而且論文從未在真實執行中比較單一代理程式。若以相同任務實際比較 128k 單一代理程式與多代理程式，就能判定 128k 究竟是真正的交叉點，還是單一代理程式模型條件過於有利的產物。
資訊傳遞覆蓋率的結果，說明的是編排能力還是懲罰設定？當 λ 設為 1 或自動補齊遺漏的傳遞時，強弱規劃器之間所有量測到的差距都消失；λ = 0.5 是為了區辨力而選定，並非根據觀察到的交接損失估算。要解決這個問題，需要進行執行研究，量測真實框架中實際遺漏一次交接會讓下游品質損失多少。

資料來源#

OrchBench: Evaluating Multi-Agent Orchestration Plans in Isolation via Deterministic Simulation — Ren、He、Zhang、Qian、Han、Zheng、Li 與 Zhang（復旦大學／中關村學院／倫敦瑪麗女王大學），OrchBench: Evaluating Multi-Agent Orchestration Plans in Isolation via Deterministic Simulation，arXiv 2607.25656，2026-07-28，empirical。問題形式化（計畫表示為指派＋傳遞映射；區分遺漏與無效傳遞）；方法（透過 k99／n 自然平行度建立 DAG、六階段模擬器、壓縮類別）；表 1–3（結構一致性、結果一致性、逐一移除模型）、表 4（n = 10／20／50／100 的主要結果）、表 5（診斷相關係數）、表 6 和表 19（上下文限制掃描）、表 7–8（選擇效益、資源耗用）、表 9（模擬器引導的精煉）、表 10 和表 20（機制消融、λ 掃描）、表 14–16（DAG 生成失敗模式與驗證）、表 18（平行度分組）、附錄 G（成本計算參數）。依圖片雙階段規則檢視圖 3（跨框架相關矩陣）、圖 4（代理程式數量上限掃描）和圖 5（極大規模，n = 200／500／1000）。另與 Agent swarms and the new model economics 交叉比對（Wilson Lin，cursor.com，2026-07-20，case-study），用於生產端比較：「Failure modes at 1,000 commits per second」（設計文件／編譯器檢查參照整合器）、「A deep dive into the runs」（衝突、crate 和行數變化）、「What the tree does for memory」（上下文效率勝過平行度）。解析備註：表 9 在原始 Markdown 中儲存格併合，透過 pdftotext -layout 還原；表 1、3 和 5 已與 PDF 核對且內容完整；表 4 採四面板配置，解析時面板標籤位置錯亂——已依正文確認面板對應（n = 100 的 Gemini／Doubao 比較，以及 n = 10 的遺漏傳遞範圍皆吻合）