人多沒有比較穩。一起犯錯才麻煩。
最近玩了一下 Anthropic 那篇 multi-agent 研究，放在一起看其實很有意思。
很多人現在一講到 multi-agent，直覺都是「多開幾個 agent，吞吐就會上去」。但那篇研究給我的感覺剛好相反，人數變多只是把 coordination 問題放大，不會自動把協作變好。
最亮眼的數字當然是漏洞掃描那段。45 個 agent 掃 15 個開源專案，協作 swarm 在 2700 萬 token 找到 266 個漏洞，獨立平行法在 650 萬 token 找到 21 個，而且兩邊只重疊 12 個。這代表什麼，我自己的解讀是：分工有價值，但前提是 agent 之間真的有形成不同搜尋路徑和角色。不然你只是花更多 token 去重複撞同一面牆。
我更在意的是後面那些失敗案例，因為那才比較像我們平常會踩到的坑。
像做文字冒險遊戲那組實驗，早期模型的 PR merge rate 很差，這不意外。比較有意思的是，後面有些模型看起來「比較會合作」了，其實只是大家默契地少碰彼此的檔案。衝突少了，merge 當然比較高，但那不等於真的學會協作。只有 Sonnet 5 同時維持比較高的 code sharing 和 PR throughput，這個訊號很重要，因為它比較接近真實團隊的樣子。
另外幾個數字就更值得 workflow 設計的人抄下來了。30 個 agent 裡有 18 個自己取一樣的 branch 名 mvp-game-loop，這超寫實。不是因為 branch naming 很難，是因為大家在相同 context 下會做出相同選擇。再來，沒有協調機制時，agent 會把有限頻寬系統打爆，一次 run 出現 240 萬個 job request，最後只接受 117 個。這種事放到 production，很可能就是 queue 爆滿、rate limit 失效、大家以為系統壞了，結果其實只是 agent 太一致。
還有 pricing game 那段也很有警示性。agent 到第 3 輪就自己講 price floor，等於你如果把一群同質 agent 丟進市場，不只不會自然競爭，還可能很快出現 collusion。這件事放到產品設計也是一樣，同一批 agent 如果拿同一套 reward function、同一份上下文、同一組工具權限，最後通常會一起偏，不會自然互補。
所以我現在比較相信一件事，multi-agent 的核心不是「多」，而是故意做出差異。
差異可以來自角色，也可以來自權限、評估指標、工作節奏。有人負責發散，有人專門 review，有人只能讀不能寫，有人只在特定 budget 內行動。你如果沒有先把這些 boundary 設好，agent 數量越多，只是把同一種錯誤複製得越快而已。
整理成一句實務心得就是，先設計 divergence，再追求 parallelism。前者決定系統會不會一起翻車，後者才是你能不能把吞吐拉起來。
作者：AutoKitty