Stanford DeLM：拿掉中央 orchestrator，多代理推理成本砍半

瀏覽次數: 4

多代理系統（multi-agent system, MAS）這兩年幾乎長成同一個樣子：一個 main agent 當 orchestrator，負責把問題拆成子任務、分派給 worker、收集結果、再合併成最終答案。這個架構很直覺，問題是——只要子任務數量一上去，中央那個節點就變成通訊與整合的瓶頸：所有更新都得流經它、它的上下文會被各 worker 的原始輸出塞爆、token 成本與延遲也全堆在它身上。

Stanford 的 Yuzhen Mao 與 Azalia Mirhoseini 在 2026 年 6 月發表的 DeLM（Decentralized Language Models，arXiv 2606.10662） 給出一個反過來的設計：把中央 orchestrator 拿掉，讓每個代理各自去任務佇列認領工作，再讀寫同一份「共享驗證脈絡（shared verified context）」。論文回報，在 SWE-bench Verified 上最高把成功率拉高 10.5 個百分點，同時把每題成本砍掉約一半。對任何正在跑 multi-agent pipeline 的團隊，這個方向值得認真讀一遍。

本文大綱

一、中央調度，其實一直在收三種稅

先把「為什麼要去中心化」講清楚。傳統 orchestrator-worker 架構在子任務變多時，會持續對你收三種隱形的稅：

通訊稅：每個 worker 的進度都要回報給中心、再由中心轉發給其他 worker。子任務數量 N 一大，溝通與整合就成了塞車點。
脈絡稅：主代理為了「合併」，往往要把各路的原始輸出都吞進自己的 context window，於是它的上下文最先爆掉，也最貴。
重工稅：worker 之間彼此看不到對方做過什麼，常常重複探索同一條死路，或對同一份文件重複摘要。

DeLM 的主張很單純：如果代理之間能共用一塊「只放精華、而且保證可靠」的記憶，協調這件事就不必再經過任何一個中心節點。

二、運作原理：三個原語撐起整個系統

DeLM 由三個原語組成——任務佇列（task queue, 𝒯）、平行代理（parallel agents）、共享驗證脈絡（shared verified context, 𝒞）。每個代理跑的是同一個非同步循環：

從佇列認領一個子任務 → 讀取共享脈絡裡已累積的進度 → 做本地推理 → 把結果壓成一條精簡更新，通過驗證後寫回脈絡。

沒有人負責分派，也沒有人負責合併。協調完全發生在那份共享脈絡上——論文稱它為「共同的通訊基底（common communication substrate）」，代理是在彼此已驗證的進度上往下疊，而不是把每筆更新都繞過一個中央控制器。

共享脈絡為什麼不會爆：coarse-to-fine 三層結構

關鍵在於共享脈絡不存原始輸出，而是分三層、由粗到細：

Gist（要點）：約 100 tokens 的高度壓縮要點，所有代理都看得到，作為導覽。
Reference-grounded summary（帶引用摘要）：放在後備儲存，用 ref-tag 標出原文逐字的頭尾片段，可回溯來源。
Raw（原始來源）：完整內容，只有真的需要時才展開。

代理平常只讀最上層的 gist；當某條線索值得深挖，才往下「展開」到摘要、甚至原文。這種 coarse-to-fine 的存取方式，讓共享脈絡能服務一大群代理而不撐爆任何人的 context。

去中心化最怕發散，DeLM 用「驗證閘門」收斂

去中心化系統最直覺的疑慮是：沒有中央仲裁，代理會不會把錯誤、幻覺彼此污染、越滾越歪？DeLM 的答案是一道入庫驗證（admission-time verification）閘門——更新不是寫了就算數，要先過驗證：

對推理軌跡：由一個 LLM verifier 檢查這條 gist 是否忠實地反映了它聲稱的發現或限制。
對來源類內容：做兩層查核——摘要必須被原文支持（靠 ref-tag 的逐字片段比對）、gist 必須保留摘要中已被支持的論點。
不被證據支持、或被扭曲的更新，會被拒絕或要求重新生成。

換句話說，DeLM 不靠一個中央大腦來保證一致性，而是靠「只有通過驗證的精簡更新才准進共享脈絡」這條規則來收斂。也因為脈絡是共享的，代理讀得到別人踩過的雷——論文舉的例子是：某個執行緒發現「改 AbstractPythonCodePrinter 不影響 lambdify 的輸出」，這條負面結論被寫回後，其他執行緒就不會再重複這段調查。重工稅，就是這樣省下來的。

三、數字與限制：先看前提，再看數字

所有數字都來自論文（arXiv 2606.10662），以下標註各自的設定，不要跨設定亂套：

SWE-bench Verified（軟體工程 test-time scaling）

用 Gemini 3 Flash：DeLM 拿到 65.7% Avg@1、72.9% Pass@2、77.4% Pass@4，Avg@1 比最強的平行基線 AOrchestra-Parallel 高 9.3 個百分點；成本壓到 每題 $0.12，而各基線約 $0.24–$0.26——這就是「砍半」的來源。
用 Claude Opus 4.6：78.0% Avg@1、80.7% Pass@2、82.5% Pass@4，每題 $0.63。
跨各設定，最高的準確率增幅約為 10.5 個百分點。

LongBench-v2 多文件 QA（長脈絡推理）

DeLM 在四個前沿模型家族上都拿到最高平均準確率：GPT-5.4 60.1%、Claude Sonnet 4.6 59.8%、Gemini 3 Flash 61.5%、DeepSeek-V4-Pro 67.5%，比最強基線最高高出 5.7 個百分點。

消融（ablation）告訴我們什麼在起作用

拿掉驗證閘門：LongBench-v2 從 60.1% 掉到 55.2%。
拿掉階層式摘要（三層結構）：掉到 57.7%。

也就是說，省成本、拉準確率的功勞，主要落在「驗證」與「階層壓縮」這兩個設計上，而不只是「多開幾個代理平行跑」。

它不擅長什麼（論文誠實列出）

結構化資料是弱點：在 OOLONG 上，原版 DeLM 只有 53.3%、$0.47/題，因為這類任務需要精確的逐列彙總與「以程式碼執行」的運算，而 DeLM 的自然語言脈絡不擅長精確的結構化處理。論文的解法是混搭——DeLM+RLM hybrid 拉到 64.0%、$0.40/題。
分解品質決定上限：拆得太粗，代理拿到的子任務太含糊；拆得太碎，又會生出一堆不必要的代理。
驗證有開銷：入庫驗證是拿「一點額外成本」換「更強的可靠性保證」。
prompt 需要按模型家族微調：不同模型可能要不同提示才能誘導出預期行為。

四、什麼時候該用、什麼時候別用

適合 DeLM 的場景：問題能乾淨地切成可平行的子任務、子任務之間有可累積的中間發現、而且工作主要在「自然語言層」——例如倉庫級的 issue 修復（SWE-bench 那類）、跨多份文件的長脈絡問答與研究彙整。這些情境下，中央合併本來就是瓶頸，把它換成共享脈絡，省的是真金白銀。

先別急著上 DeLM 的場景：任務本質是精確的結構化運算（表格彙總、需要 code execution 的精算）、子任務之間幾乎沒有可共享的中間狀態（那共享脈絡就沒價值）、或者你的問題小到單一代理一次就能解完——多代理的協調與驗證開銷，這時候只會是淨虧。

核心的 trade-off 一句話：DeLM 用「驗證閘門的計算開銷」換掉「中央 orchestrator 的通訊與脈絡瓶頸」。當後者比前者貴，它就贏；反之則不必。

五、對工程團隊的可操作意義

就算你近期不打算照搬 DeLM，這篇論文有幾個能直接帶走的設計觀念：

協調的載體可以是「共享記憶」，不一定是「中央調度者」。如果你現在的 multi-agent 卡在 orchestrator 的 context 成本，先問：這些更新有沒有可能寫進一塊共享狀態，讓代理自己去讀？
共享狀態要分層、要壓縮。別把原始輸出整包丟進共享記憶；存「~100 token 的要點 + 可回溯引用」，需要才展開，這是控制 context 成本的關鍵手法。
去中心化必須配一道驗證閘門。沒有中央仲裁時，「只有通過驗證的更新才准入庫」這條規則，是防止代理互相污染、系統發散的承重牆——消融數字證明它不是裝飾。
把『負面結論』也寫回共享脈絡。讓代理看得到彼此踩過的雷，是省下重工成本最便宜的一招。

DeLM 不是要你拆掉所有 orchestrator，而是提醒：當多代理開始變貴、變慢，瓶頸往往不在模型，而在你把「協調」放在了一個中心點上。換個放法，帳就不一樣了。

來源

論文：Yuzhen Mao, Azalia Mirhoseini, 《Decentralized Multi-Agent Systems with Shared Context》, arXiv:2606.10662（2026/06/09，Stanford University / SAIL）— https://arxiv.org/abs/2606.10662
專案頁與程式碼：https://yuzhenmao.github.io/DeLM/ ｜ https://github.com/yuzhenmao/DeLM
媒體報導：VentureBeat,《Stanford's DeLM cuts multi-agent task costs 50% — without a central orchestrator》— https://venturebeat.com/orchestration/stanfords-delm-cuts-multi-agent-task-costs-50-without-a-central-orchestrator