如何以低 70% 的成本達到前沿程式碼水準——專訪 Cohere 的 Nouha Dziri

Cohere 資深研究員 Nouha Dziri 主張，多代理（multi-agent）程式開發團隊能用大約低 70% 的成本，達到前沿模型的水準——但前提是算力要花在真正卡住任務的那個階段，而不是平均分攤給整個團隊。整場演講大部分篇幅是一項受控研究，探討團隊設計的各種選擇（組織方式、溝通方式、團隊規模、模型指派，以及把 worker 放在軟體工程哪個階段），實驗跑在 Program Bench 逆向工程基準上；最吸睛的成本數字出現在接近尾聲，而且取決於一組特定配置。

Dziri 在 Mila 擔任產業副研究員（associate industry member），同時在 Allen Institute 兼任 PI，這項研究是在 Cohere 完成的。對讀者來說，價值在於一組實測出來的取捨，而不是單一訣竅：團隊最多比單一代理高出約 10 分，但預設成本是 4–7 倍；由強力 lead 搭配便宜 worker，能用一小部分價格拿回大部分的獎勵；而同儕之間互相傳訊息，在這些實驗裡並沒有幫助。最後幾分鐘轉向多代理安全，Dziri 稱之為當務之急。

團隊勝過單一代理，但預設成本是 4–7 倍

Dziri 把多代理團隊定位為推論時算力的第三個軸向，與兩個既有軸向並列：讓單一代理思考更久（序列擴充套件），以及平行取樣多個獨立嘗試。這兩種做法在長時程的代理工作上都會失靈——例如在大規模 repo 中穿梭、修改程式碼、花好幾小時除錯——因為上下文視窗會塞滿，而每個平行嘗試仍然得獨自完成整個任務。把工作切開，則能讓 lead 掌握全貌，worker 從乾淨的上下文出發，讀檔案、跑測試，只回傳精簡的結果。

她刻意打造了一套極簡的階層式框架（harness），好讓每個設計選擇都能一次只變動一項。lead 收到任務後，透過一個叫 delegate agent 的工具分派工作；每個 worker 只看得到自己的子任務，完成後回報。lead 會動態決定團隊規模，可以讓 worker 繼續執行或直接終止，也能介入監督。所有代理都透過 bash 工具在同一個共享工作區裡工作。lead 測了兩種變體：阻塞式 lead（blocking lead）負責分派子任務後等待結果；非同步 lead（async lead）則在結果陸續回傳的同時繼續工作與監督。

基準是 Program Bench，一項逆向工程任務：代理從空白工作區開始，只有一個能執行但不能讀取的編譯後執行檔，外加檔案，必須自行探測這個二進位檔的介面與邊界情況，再寫出功能相符的實作。任務包括 SQLite、PHP 解譯器與 FFmpeg；Dziri 說，在官方排行榜上，最好的模型也只通過 FFmpeg 測試的 10%。

非同步 lead 的失靈模式很具體：它不知道什麼時候該等還在探索的 worker，開始憑自己的猜測往下做，接著不是忽略回傳的報告，就是把工作重做一遍。有時它在 worker 還在跑的時候就宣告任務完成，那些產出於是被丟棄。阻塞式 lead 不會有這個問題，因為它會先整合再提交。

額外代理要花在瓶頸階段才划算

Dziri 的核心設計原則是：代理放在哪裡，比加了多少個更重要。她測試了每次只把 worker 給一個階段——規劃／探索、實作，或驗證——其餘階段由 lead 自己扛。

在 Program Bench 上，規劃階段的 worker 效果壓倒性最好。只給規劃階段的團隊，獎勵大約等同於完整加重版提示的團隊，成本卻只要一半左右；而且花在規劃上的每一塊錢，換到的獎勵約是花在其他任何階段的 1.6 倍。把 worker 加到實作或驗證階段，只會拉高成本，獎勵卻沒有超過單一代理的基準。

背後的機制是上下文。單一探索代理只在一個上下文裡探測檔案，容易漏掉邊界情況；多個規劃代理各自在乾淨的上下文中探測程式的不同部分，再回傳精簡報告，lead 因此能學到比自己單幹更多的東西。Program Bench 只提供黑箱執行檔，所以「探索」才是真正的瓶頸。

分派的時機也印證這點。有了規劃指引，所有分派都集中在最開始一次爆發完成，那時一行程式碼都還沒寫。換成完整的 PIV 指引、又沒有針對階段分配，同樣的開頭爆發還是會發生，但 lead 之後會一路持續分派——多出 830 次呼叫，換來同樣的獎勵，卻多花約 500 美元。規劃指引每次呼叫換到的獎勵是 2.4 倍。

flowchart TD
    A["任務送達 lead"] --> B{"哪個階段卡住任務？"}
    B -->|"黑箱探索"| C["開頭一次爆發派出規劃代理"]
    B -->|"骨架與測試已給定"| D["派出實作代理"]
    B -->|"不明確"| E["完整 PIV 指引"]
    C --> F["worker 在乾淨上下文中探測，精簡回報"]
    D --> F
    E --> G["lead 一路分派，成本上升但獎勵沒增加"]
    F --> H["lead 整合後提交"]
    G --> H

這條規則取決於任務，並非放諸四海皆準。在 Commit0 上，檔案與單元測試都已提供，規劃不是瓶頸，計畫基本上等於現成。在那裡，把代理加倍投入實作階段帶來最大的增益。Dziri 請讀者參閱論文附錄看這些結果。

實作 worker 敗在基礎太弱與越界

當 lead 獨自負責探索、worker 只負責實作時，結果令人失望，原因有兩個。第一，lead 的探索有限，留下的基礎太弱，而每個 worker 只拿到很窄的一片，看不到整個任務，功能實作起來就前後不一致。第二，給 worker 更多上下文反而適得其反：它們不守自己的任務邊界，多做沒人要求的額外功能，還互相踩線。

實作者之間的協調也失敗了。worker 原本應該自行協商誰做什麼，以避免衝突與重複，但 84% 的訊息直接送給 lead，沒有人知道別人在做什麼。lead 有時會被淹沒，無法把問題回饋給正確的 worker。lead 最後只能替這個缺口買單，把重複的工作縫合起來，結果延遲變長、獎勵下降、成本上升。

強力 lead 搭配便宜 worker，用一小部分價格達到前沿水準

Dziri 測試了三種 GPT-5.6 變體——Luna、Terra、Sol，能力與成本依序遞增——並套用在不同的角色指派上。以 Sol 當 lead、Luna 當 worker，團隊效能幾乎與全 Sol 相同，成本卻低約 60%。反過來則不成立：便宜的 lead 救不回來，再強的 worker 也沒用。Terra 帶 Luna worker 拿到 51%，而 Sol 單獨作業是 57%。

「lead 決定天花板，worker 決定價格。」

Dziri 指出，這與 Meta 近期一項推理研究相符：更好的控制器能拉高同一批 worker 的表現。接著她改由自己設定團隊規模，不讓 lead 決定（先前平均是五個 worker）。把規劃代理從 2 個擴到 16 個，以 Sol 當 lead、Luna 當規劃代理，結果持續改善。16 個規劃代理的團隊比全 Sol 的規劃團隊便宜 38%，比每個階段都配 worker 的完整 PIV 配置便宜 70%——這就是開頭那個指標數字的來源。她提醒，天花板一定存在，但預算不允許再往上測。把實作或驗證團隊擴大則完全沒有幫助。

代理預設走向階層制，同儕傳訊沒有回報

每個代理都有一個 send message 工具，可以聯絡沙箱裡任何其他代理。它們大多不橫向使用：84% 的訊息是 worker 傳給 lead，worker 對 worker 的流量每個任務不到一則。這個模式跨模型都成立，包括 Claude Opus 4.7 與 Gemini——即使能自由對話，代理的行為仍像階層組織。lead 對 worker 說的話，遠多於 worker 彼此之間說的。

Dziri 很謹慎，不就此斷定同儕傳訊沒有必要。她預期隨著團隊規模擴大，傳訊會變得不可或缺，因為所有事情都繞經主管，並不符團隊實際運作的方式。她把這個零結果部分歸因於自己的框架——lead 把工作切成彼此獨立的片段，worker 也看不到沙箱裡還有誰存在，若有個留言板也許行為會不同——部分歸因於任務本身。這點留給未來研究。

分派能力在前沿模型之間差異極大

把另外五個模型家族放進完全相同的框架與工具，Dziri 發現 lead 必須做對兩件事：決定要分派，以及真的用上回傳的成果。GPT-5.6 團隊分派頻繁，獎勵最多提升 7 分。Claude 提升近 6 分，但很少分派。Grok 與 Gemini 的分派頻率與 GPT-5.6 相當，卻毫無增益。

未解問題：自我組織、規模化溝通與多代理安全

Dziri 在固定階層下最多測到 16 個 worker。她想知道數千個代理的團隊該如何組織、如何溝通、如何花算力，以及代理能否在給定任務、預算與期限的情況下自行設計團隊。她認為為每個任務手工調校一份加重版提示並不現實——她的團隊就是這樣才拿到 PIV 的增益——lead 應該自行推斷該用什麼組織。

談到安全，她提到自己所稱的 Penny Lane 事件，並主張如今能力強大的代理團隊全天候自主執行、無人監督，因此保護系統與基礎設施、對齊這些模型已是當務之急。她感謝共同第一作者 Kenan 與 Daniel，並請聽眾透過 QR code 取得論文與部落格文章。

貫穿這些結果的主軸是：多代理程式開發，本質上是預算問題，其次才是能力問題。實測到的勝利，來自讓團隊結構對上任務的瓶頸，以及把錢花在 lead 而不是人力數量上；實測到的損失，來自過了有用時點還繼續分派，以及不帶來任何新資訊的協調開銷。還有兩個張力尚未解決：同儕溝通的結果受到框架幹擾，因為 worker 彼此不知道對方存在；而 70% 的成本降幅，建立在一次規劃代理擴規模的實驗上，那次實驗在找到飽和點之前就撞到預算上限。這兩點都值得在後續研究中持續關注，同時也要看階段瓶頸規則在 Program Bench 與 Commit0 之外的基準上是否依然成立。