摘要： Cohere 在 2026 年 10 月 14 日發表一篇關於 coding agent 團隊的研究，用自建的受控測試環境逐一檢驗多 agent 協作的設計選項。結論很實用：團隊確實比單一 agent 強，但把額外的算力花在哪個階段、由什麼模型承擔，比單純增加人數重要得多。對正在設計 agent 系統的 builder 來說，這是一份直接影響成本結構的參考。
團隊有效，但帳單很誠實
多 agent 團隊的成果在業界已經有幾個標誌性案例：16 個 Claude agent 寫出能編譯 Linux kernel 的十萬行 C 編譯器，花了約 2,000 次 agent session 和兩萬美元 API 費用；Cursor 用數百個 agent 在一週內寫出超過百萬行的瀏覽器；Bun 從 Zig 移植到 Rust 只花 11 天，高峰期同時跑 64 個 agent。這些案例彼此差異很大——有的用對等協作加 lock file 搶任務，有的用階層式規劃，有的給每件工作固定配一個實作者、兩個對抗審查者和一個修復者。
Cohere 引用 Factory 對自家系統的研究來點出問題：他們的三角色循環在重建 GDAL 這個任務上，reward 是單一 agent 的兩倍多，但成本是 14 倍、時間是 13 倍。所以真正的問題不是「多個 agent 有沒有用」，而是這筆額外的推理開支該怎麼分配才值得。
測試環境：一次只改一個變數
Cohere 建了一個刻意精簡的 harness，每個 agent 都透過 bash tool 在同一個共享 workspace 工作。lead agent 收到任務後用 delegate_agent 工具分派工作，可以選擇開新的 worker（乾淨的 context window）或續用曾經派過任務的 worker（保留先前的 context）。他們在這個基礎上變動五件事：lead 把工作委派到哪些階段、lead 等待時是阻塞還是非同步、各角色用什麼模型、團隊規模多大、以及 agent 之間是否可以直接通訊。
測試基準是 ProgramBench 的 200 個程式重建任務：agent 拿到一個只能執行不能閱讀的原始程式和它的文件，要靠執行去摸索行為，再寫出表現一致的替代品。題目從 jq 這類小工具到 SQLite、FFmpeg 這種大型系統都有。主要比較的是三個 GPT-5.6 模型——由弱到強、由便宜到貴分別是 Luna、Terra 和 Sol。
三個對成本敏感的發現
第一，委派的位置比委派的數量重要。在非同步團隊裡，只把「探索與規劃」交給 worker 的 lead，reward 達到 63.6%，跟把三個階段全部委派出去（63.2%）幾乎一樣，但成本減半：249 美元對 510 美元。以每 100 美元換到的 reward 計算，規劃階段的效率大約是次佳階段的兩倍。原因在於任務本身是黑盒，行為得靠反覆執行來發現——多個 planning worker 可以平行探測程式的不同介面，把發現交給 lead，由 lead 掌握全貌後自己寫程式。
第二，強 lead 配便宜 worker 能逼近旗艦表現。一個 Sol lead 指揮 16 個廉價的 Luna planning worker，達到 61.8% reward，只比全 Sol 團隊的 63.2% 低一點多，但成本從 510 美元降到 155 美元——大約省下七成。這也是標題那句「三成成本到達前沿」的由來。
第三，非同步 lead 加速但未必加分。在 PIV（規劃、實作、驗證）流程下，非同步團隊比阻塞式快了 19.5%，reward 差不多；但在最精簡的 prompt 下，非同步 lead 乾脆自己多做、只委派 4.4 次，團隊優勢縮水到 3.8 分，甚至輸給用 PIV prompt 的單一 agent。
對 builder 的實際含義
如果你正在評估多 agent 架構，這份研究指向幾個可以直接套用的決策：先問任務的瓶頸在哪個階段，再把平行算力投進去，而不是讓每個階段都堆人；讓最貴的模型只待在需要判斷力的位置，把跑腿的探測和規劃交給便宜模型；非同步帶來的是時間上的節省，別預期它自動提升品質。
這種「在哪個環節花錢」的思路，跟之前談過在 Cursor 裡調整 Gemini 4 Argon effort 等級這個成本旋鈕 是同一件事：推理成本的槓桿往往不在總量，而在配置。Cohere 也坦承這是針對程式重建任務的結論，Commit0-Lite 只是次要驗證——換一個規格已經明確的任務型態，哪個階段值得委派可能會不同。動手之前，值得先在自己的工作負載上量一次。