Google 最新力作：Teamwork
多智能體不是簡單把任務分給幾個 Agent 就好，怎麼讓它們協作、而不是互相強化錯誤，才是更難的問題。Google 最近開源的 Teamwork 框架給出了一個答案，它在數學、硬體模擬、開源最佳化這些前沿領域都有實測成果。我看了它的設計思路，覺得對做 Agent 的人相當有啟發。
這篇文章主要拆解它的設計原理，看看它到底怎麼解決多智能體協作的問題。
原文連結：https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner
一、多 Agent 的難題不在分工，而在組織
一般任務用基礎的多智能體方法通常夠用，但碰到困難的研究與工程問題，麻煩就來了。組織鬆散的 Agent 很快就會偏離軌道，一個 Agent 早期犯的錯，其他 Agent 會跟著認同，接著就在有缺陷的想法上繼續建構下去。
核心矛盾不在「用幾個 Agent」，而在「怎麼組織它們」。Anthropic 之前做過一個實驗，比較協調式群集（coordinating swarm）與獨立並行 agents 在找尋軟體漏洞上的效果。結果顯示，協調式群集能找到更多漏洞，而且這種差距在複雜任務上更加明顯。
這說明組織鬆散的 Agent 會偏離軌道，是多 Agent 系統的通病。Teamwork 要解決的問題是：讓多個 Agent 在數小時甚至數天的時間裡，互相挑戰彼此的工作，在進一步建構之前先找出缺陷，再把最強的部分組合成可用的解決方案。
二、Teamwork 如何讓 Agent 互相糾錯？
Teamwork 把許多研究和工程問題共通的結構變得具體且可設定：生成候選方案、壓力測試、把最好的想法組合成更強的方案。圍繞這個循環，它做了三個關鍵設計。
從生成方案到測試、組合，再進入下一輪
這個循環是 Teamwork 的基礎。它不是單純的任務分發，而是讓候選方案經過測試後，把好的想法萃取出來，形成更強的下一輪候選。人類負責設定目標與最終驗收，Agent 負責執行整個迭代過程。
把協作模式和 Agent 本身分開
模式是規格，不是可執行的程式。它不包含編排程式碼，框架讀取模式後會自動啟動合適的 Agent。如此一來，專門的機制（例如對抗性批評循環）就能跨領域移植，不需要改程式碼。
這個設計的價值在於：協作邏輯和每個 Agent 具體要做什麼是分開的，你寫好的編排策略可以重複運用到完全不同的領域。
團隊規模不預設，邊做邊調整
框架會根據任務需求動態決定要生成多少 Agent，而不是預先設好數字。Agent 數量和團隊結構可以在執行過程中隨著問題的浮現而改變。每一次任務執行都是一個活的過程，而不是固定不變的管線。
這個設計解決了一個常見問題：很多框架要求你事先想好要用幾個 Agent，但複雜問題的結構往往要到實際動手做的過程中才會清楚。
三、五種問題，需要五種不同的協作方式
不同問題需要不同的協作方式。問題的結構決定了該怎麼組織 Agent，Teamwork 針對不同類別的問題提供了專門的模式。
不可拆解的任務，在測試中反覆迭代
有些問題沒辦法拆成獨立的子任務，需要反覆試錯和精煉。這個模式透過緊密的「Agent—測試—精煉」循環逐步改進，每個測試結果都直接回饋到下一輪修改。
可以拆開的任務，交給多個 Agent 並行推進
對於能拆成多個獨立部分的工程任務，這個模式會把工作扇出（fan-out）給多個並行的工作者，同時安排批評者審查每個工作者的產出。
編排器會根據問題決定要部署多少 Agent、執行多少輪，核心角色固定，但執行規模動態調整。
數學開放問題，讓不同路線先接受挑戰
數學和理論電腦科學的開放問題有個特色：很多看起來有希望的方法最終會失敗，而且缺陷往往要深入嘗試後才看得出來。這個模式讓每個候選方案在推進之前，都必須先通過壓力測試。
每走一步，都先驗證這一步是否成立
深度優先的數學推理需要在每一步都嚴格自我檢驗，這個模式把驗證嵌入推理過程之中，而不是等完整答案出來後才檢查。
審查論文，用固定維度組織批評意見
對論文和技術文件的審查需要結構化的分析，這個模式用固定的審查維度來組織 Agent 的批評意見。
四、失敗的證明路線，也能留下有用的東西
長證明模式值得單獨拆解，因為它處理的是最難的開放問題。它的設計不只是「生成然後驗證」，而是一個完整的「生成、對抗、綜合、學習」循環。
給每個候選方案安排一個專門的反駁者
多個候選策略並行生成，每個策略都配上一個偽造者（falsifier），偽造者唯一的任務就是打破這個策略。綜合樹再把候選策略和它們的報告組合起來。
被駁倒的路線會留在流程中，並附帶反對意見。一條破碎的路線可能仍然包含有用的想法，這是這個設計的關鍵洞見。
把長證明拆成帶有依賴關係的子問題
選定的策略會展開成證明計畫，子問題有明確的目標和顯式的依賴關係。依賴圖讓獨立的子問題並行執行，有依賴關係的子問題則按拓撲順序執行。
這樣一來，長證明被拆成可管理的部分，同時保持整體邏輯的連貫。
讓不同方案在錦標賽中逐層合成
在綜合樹中，每個節點會讀取候選樣本及其批評，產出改進後的解決方案。如果綜合出來的解決方案失敗，網路會用累積的反對意見重新執行。
這個機制讓失敗變成有用的資訊，而不是被簡單丟棄。
這一輪踩過的雷，下一輪不再重來
失敗的草稿會保留給下一次嘗試。驗證者的發現會被提煉成與答案無關的陷阱清單，記錄常見的錯誤模式。共享的知識目錄則保存已證明的結果、失敗的方法和相關參考資料。
這些經驗的累積，讓後續的嘗試不會重複踩到同樣的雷。
五、對做 Agent 的人的啟發
Teamwork 的設計原理有幾點值得借鏡。
多智能體的核心是編排邏輯
重點不是單純分配任務，而是要設計好壓力測試機制、結果綜合策略和跨輪學習機制。組織鬆散的 Agent 會互相強化錯誤，這一點在官方文件中也被反覆強調。
一套協作模式，可以遷移到不同領域
編排邏輯和 Agent 描述解耦之後，你寫的協作策略就可以移植到不同領域。這個設計思路不只適用於 Teamwork，在自己打造多智能體系統時也值得考慮。
不要提前鎖死 Agent 數量
不要預設固定的團隊結構，讓 Agent 數量和組織方式根據問題的浮現動態調整。複雜問題的結構往往在動手之前無法完全預見。
必須有人專門提出反對意見
Anthropic 的研究還發現了一個值得注意的問題：當多個 Agent 面對相同情況時，會表現出比人類更高的相似性。一個 Agent 的錯誤決策會被其他 Agent 複製，形成系統性失敗。
Teamwork 的設計（如偽造者機制、批評循環）正是為了對抗這種從眾效應，讓每個候選方案在推進之前，都必須經過獨立的壓力測試。
小模型配上好編排，也能解決高難度問題
用日常開發就會用到的 Flash 等級模型，搭配精心設計的編排邏輯，就能在複雜問題上發揮強勁的效能。TCSBench 71% 的得分當中，有三個結果是 Flash 等級模型首次產出博士等級的數學研究。
不一定非要用最大的模型，關鍵在於編排邏輯的品質。
寫在最後
看完 Teamwork 的設計原理，我的感想是：多智能體的未來不在於堆疊更大的模型，而在於怎麼把協作機制設計好。它把生成、測試、組合、學習這個循環做得夠細，讓小模型也能在前沿問題上發揮作用。
對正在打造 Agent 系統的人來說，最值得參考的是它的三個設計決策：編排邏輯與 Agent 描述解耦、執行時自適應調整、把失敗當成有用的資訊。這些思路不只適用於多智能體，在單一 Agent 系統裡也用得上。
Anthropic 的多 Agent 研究則提醒我們，多 Agent 協作還有潛藏的問題，例如從眾效應。在設計編排機制時，需要特別考慮如何避免 Agent 之間互相強化錯誤。
如果想深入研究它的機制，建議把重點放在長證明模式的錦標賽網路設計。這個模式處理的是最難的開放問題，它的策略搜尋、分解和跨輪學習機制，對於理解怎麼讓多個 Agent 真正協作有很大的幫助。