多智能體不是簡單把任務分給幾個 Agent 就行，怎麼讓它們協作而不是互相強化錯誤，是個更難的問題。Google 最近開放原始碼的 Teamwork 框架給了個答案，它在數學、硬體模擬、開源最佳化這些前沿領域都有實測成果，我看了它的設計思路，覺得對做 Agent 的人挺有啟發。

這篇文章主要拆解它的設計原理，看看它到底怎麼解決多智能體協作的問題。

原文連結：https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner

一、問多 Agent 難的不在分工，而在組織

常規任務用基礎多智能體方法通常夠用，但碰到困難的研究和工程問題，麻煩就來了。鬆散組織的 Agent 很快會偏離軌道，一個 Agent 早期犯的錯，其他 Agent 會跟著認同，然後在有缺陷的想法上繼續建構。

核心矛盾不是"用幾個 Agent"，而是"怎麼組織它們"。Anthropic 之前做過一個實驗，對比了協調 swarm 和獨立平行 agents 在找軟體漏洞上的效果。結果顯示，協調 swarm 能找到更多漏洞，而且這種差距在複雜任務上更明顯。

這說明鬆散組織的 Agent 會偏離軌道，是多 Agent 系統的通病。Teamwork 解決的問題是：讓多個 Agent 在數小時甚至數天裡，互相挑戰對方的工作，在進一步建構前先找缺陷，把最強的部分組合成可用的解決方案。

二、Teamwork 如何讓 Agent 互相糾錯？

Teamwork 把很多研究和工程問題通用的結構變得具體且可配置：生成候選方案、壓力測試、把最佳想法組合成更強的方案。圍繞這個循環，它做了三個關鍵設計。

從生成方案到測試、組合，再進入下一輪

這個循環是 Teamwork 的基礎。不是簡單的任務分發，而是讓候選方案經過測試後，把好的想法提取出來，形成更強的下一輪候選。人類負責定目標和做最終驗收，Agent 負責執行整個迭代過程。

模式是規格，不是可執行程序。它不包含編排程式碼，框架讀取模式後自動啟動合適的 Agent。這樣專門的機制（比如對抗性批評循環）可以跨領域移植，不用改程式碼。

這個設計的價值在於：協作邏輯和每個 Agent 具體幹什麼分開了，你寫好的編排策略可以復用到完全不同的領域。

框架根據任務需求動態決定生成多少 Agent，不是預設數字。Agent 數量和團隊結構可以在運行過程中隨著問題的展現而改變。每次任務執行是一個活的過程，不是固定管道。

這個設計解決了一個常見問題：很多框架要求你事先想好要用幾個 Agent，但複雜問題的結構往往在做的過程中才清晰。

三、五種問題，需要五種不同的協作方式

不同問題需要不同的協作方式。問題的結構決定了該怎麼組織 Agent，Teamwork 針對不同類別的問題提供了專門模式。

不可拆的任務，在測試中反覆迭代

有些問題沒法拆成獨立子任務，需要反覆試錯和精煉。這個模式通過緊密的 Agent-測試-精煉循環逐步改進，每個測試結果直接反饋給下一輪修改。

能拆開的任務，交給多個 Agent 平行推進

對於能拆成多個獨立部分的工程任務，這個模式把工作扇出到多個平行工作者，同時安排批評者審查每個工作者的產出。

編排器根據問題決定部署多少 Agent、跑多少輪，核心角色固定，但執行規模動態調整。

數學開放問題，讓不同路線先接受挑戰

數學和理論電腦科學的開放問題有個特點：很多有希望的方法最終會失敗，而且缺陷往往要到深入嘗試後才可見。這個模式讓每個候選方案在推進前必須經過壓力測試。

每走一步，都先驗證這一步是否成立

深度優先的數學推理需要在每一步都嚴格自檢，這個模式把驗證嵌入到推理過程中，而不是等完整答案出來後再檢查。

審查論文，用固定維度組織批評意見

對論文和技術文件的審查需要結構化的分析，這個模式用固定的審查維度來組織 Agent 的批評意見。

四、失敗的證明路線，也能留下有用的東西

長證明模式值得單獨拆解，因為它處理的是最難的開放問題。它的設計不只是"生成然後驗證"，而是一個完整的"生成、對抗、綜合、學習"循環。

給每個候選方案安排一個專門的反駁者

多個候選策略平行生成，每個策略配一個偽造者，偽造者的唯一工作是打破這個策略。綜合樹把候選策略和它們的報告組合起來。

被駁倒的路線留在過程中，附帶反對意見。一個破碎的路線可能仍包含有用的想法，這是這個設計的關鍵洞察。

把長證明拆成帶依賴關係的子問題

選定的策略擴展成證明計畫，子問題有明確的目標和顯式的依賴關係。依賴圖讓獨立子問題平行運行，依賴子問題按拓撲順序執行。

這樣長證明被拆成可管理的部分，同時保持整體邏輯的連貫。

讓不同方案在錦標賽中逐層合成

在綜合樹中，每個節點讀取候選樣本及其批評，產生改進的解決方案。如果綜合解決方案失敗，網路會用累積的反對意見重新運行。

這個機制讓失敗變成有用的資訊，而不是簡單丟棄。

這一輪踩過的坑，下一輪不再重來

失敗的草稿保留給下一次嘗試。驗證者的發現提煉成答案無關的陷阱登錄檔，記錄常見錯誤模式。共享知識目錄保存已證明的結果、失敗的方法、相關參考。

這些經驗積累讓後續嘗試不會重複踩坑。

Teamwork 的設計原理有幾點值得借鑑。

不是簡單分任務，而是要設計好壓力測試機制、結果綜合策略、跨輪學習機制。鬆散組織的 Agent 會互相強化錯誤，這點在官方文件裡也反覆強調。

一套協作模式，可以遷移到不同領域

編排邏輯和 Agent 描述解耦後，你寫的協作策略可以移植到不同領域。這個設計思路不只適用於 Teamwork，做自己的多智能體系統時也值得考慮。

不要預設固定的團隊結構，讓 Agent 數量和組織方式根據問題的展現動態調整。複雜問題的結構往往在做之前無法完全預見。

Anthropic 的研究還發現了一個值得注意的問題：當多個 Agent 面對相同情況時，會表現出比人類更高的相似性。一個 Agent 的錯誤決策會被其他 Agent 複製，形成系統性失敗。

Teamwork 的設計（如偽造者機制、批評循環）正是為了對抗這種從眾效應，讓每個候選方案在推進前都要經過獨立的壓力測試。

小模型配上好編排，也能解決高難度問題

用日常開發用的 Flash 級模型配上精心設計的編排邏輯，能在複雜問題上解鎖強勁性能。TCSBench 71% 的得分裡，有三個結果是 Flash-tier 模型首次產生博士等級的數學研究。

不一定非要用最大的模型，關鍵是編排邏輯的質量。

看完 Teamwork 的設計原理，我的感受是：多智能體的未來不在於堆更大的模型，而在於怎麼設計好協作機制。它把生成、測試、組合、學習這個循環做得足夠細，讓小模型也能在前沿問題上發揮作用。

對正在做 Agent 系統的人來說，最值得參考的是它的三個設計決策：編排邏輯和 Agent 描述解耦、執行階段自適應、把失敗當成有用資訊。這些思路不只適用於多智能體，單 Agent 系統裡也能用。

Anthropic 的多 Agent 研究則提醒我們，多 Agent 協作還有隱性問題，比如從眾效應。設計編排機制時，需要特別考慮如何避免 Agent 之間互相強化錯誤。

如果要深入學它的機制，建議重點看長證明模式的錦標賽網路設計。這個模式處理的是最難的開放問題，它的策略搜尋、分解、跨輪學習機制，對理解怎麼讓多個 Agent 真正協作有很大幫助。 (Datawhale)

彙整鉅亨號中所有使用「AI協作」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`