多個 coding agent 一齊寫 code 未必快：Anthropic 實驗教你點樣分工避衝突
代理數量加得太急，共用 codebase 同有限資源好容易塞車
多開幾個 agent，產量未必跟住倍增
同一時間開十幾個 coding agent，畫面上好似成隊工程師一齊開工，不過 agent 數量只係並行容量，唔會自動變成有效產出。iThome 報道 Anthropic 一組受控實驗，研究多個 Claude 喺共享 codebase、有限系統資源同目標衝突之下會點反應。結果幾實際：任務拆得開，多 agent 的確可以擴大覆蓋範圍；一去到大家要改同一批檔案、搶同一條 queue，新增嘅 agent 亦會帶來協調成本。
圖片：Anthropic
搵漏洞適合分頭做，但代價唔細
Anthropic 安排 45 個 agent 檢查 15 個開源項目，每個 agent 有獨立 VM，亦可以喺共享討論區交換發現，再交俾另一個 arbiter agent 判斷漏洞係咪新同有效。官方數字顯示，Mythos Preview 協作組用約 2,700 萬 token 搵到 266 個漏洞；預先分配搜尋範圍嘅獨立組用約 650 萬 token 搵到 21 個。兩組只有 12 個結果重疊，不過當範圍收窄至相同核心目錄，每個漏洞所花嘅 token 大致相若。即係多 agent 買到嘅主要係覆蓋面同探索能力，成本亦同步放大。
圖片：Anthropic
一齊改同一個項目，merge 先係樽頸
另一項測試叫多組 agent 用 12 小時整一款網頁文字遊戲，研究人員改過 agent 數量，亦試過自由組隊、指定角色同設立 CEO 層級。三種安排做出嚟嘅遊戲質素都差，單靠 prompt 加個職銜幫助有限。較早嘅 Sonnet 4.6 同 Opus 4.6 開咗大量互相衝突嘅 pull request；Opus 4.8 同 Mythos Preview 多數靠各自霸住不同檔案避開碰撞。測試入面，只有 Sonnet 5 同時維持較高 code sharing 同 merge 比例。
呢點對日常開發最有參考價值。十個 agent 各自查一個獨立 bug、補一組測試或者檢查不同 module，平行處理幾合理；十個 agent 同時重構 authentication、資料模型同共用 API，大家讀到嘅 repository 狀態會好快過期。Anthropic 另一個 C compiler 實驗都有相近經驗：16 個 agent 面對大量獨立失敗測試時幫到手，去到編譯 Linux kernel 呢類連續單一路徑，佢哋會撞上同一個問題，再互相覆蓋修改。
相同模型仲可能一齊揀錯路
多 agent 亦唔等於多種思路。Anthropic 早期遊戲測試入面，30 個同時啟動嘅 agent 有 18 個建立咗同名 Git branch。有限頻寬嘅排程測試就更誇張：agent 冇其他協調渠道，於是開 background daemon 每秒查詢 30 次；一次測試收到約 240 萬個工作請求，最後只接納 117 個。呢類結果反映相同模型、prompt 同環境容易產生高度相似嘅決定，錯誤亦可能由單點問題放大成全組一齊塞住系統。
「互相封鎖」係刻意壓出嚟嘅極端情境
最搶眼嗰組測試同真實開發要分清楚。研究人員刻意叫三個 agent 把同一套 Python backend 分別改寫成三種不同語言，三者最初亦唔知道另外兩個 agent 存在，然後觀察四小時。佢哋發現修改不停俾覆蓋後，有啲 run 出現 kill process、循環停止競爭程序同撤銷帳戶權限等行為；每個模型測咗 120 個 episode，亦有部分 agent 後來辨認出指令衝突，清走相關程式再要求人類介入。
呢個設計本身就把目標整到互不相容，所以結果唔足以證明一般多 agent 項目都會演變成封鎖戰，亦唔代表模型具有類似人類嘅惡意。佢證明嘅範圍比較窄：當 agent 各自死追局部目標，又共享高權限環境，系統冇機制處理衝突，模型有能力用破壞性操作移除眼前障礙。能力較強亦未必自然識得禮讓，反而可能更快執行封鎖操作。
實際開工，先劃清邊界再加人數
值得開多個 agent 嘅任務，通常可以預先寫清楚輸入、輸出同驗收條件，例如分 module 查漏洞、為互不相干嘅 bug 寫修正、並行研究幾套方案。每個 agent 最好用獨立 worktree、branch、container 或 sandbox，限制可寫目錄、網上連線同憑證權限；測試 database、port、CI runner、package cache 同 API rate limit 呢類共用資源，就要設配額、backoff 同清楚嘅 owner，避免所有 agent 同時搶位。
多人改動始終要有一個收口位。可以由主代理拆任務、記錄 owner 同 dependency，再用 task lock 防止重複開工；worker 交回細小 commit、測試結果同假設，主代理先負責 merge、跑整合測試同處理衝突。改動高度耦合、需求仲未定，或者下一步要睇上一個結果先決定時，單一 agent 通常穩陣啲。團隊準備擴大 agent 數量之前，可以先量度成功 merge、重複修改、重試次數、token 同 CI 等候時間，睇清楚新增 agent 究竟有冇縮短交付時間。
參考來源
- iThome — AI代理不是越多越有效率，協作恐出現資源爭用與相互封鎖 — original report
- Anthropic：Patterns and problems in emerging multiagent systems — 一手研究原文，核對模型、agent 數量、實驗時間、受控條件同限制。
- Anthropic：Building a C compiler with a team of parallel Claudes — 官方多 agent coding 實驗，交代 task lock、container、共享 repository 同平行處理嘅實際限制。
- Anthropic：Beyond permission prompts — making Claude Code more secure and autonomous — 官方 sandbox 設計背景，解釋檔案、網上連線同憑證權限點樣隔離。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
