最佳實踐：Google
最近各個廠商都在深入研究多智能體協作。讓多個智能體工協作，各自負責一塊任務，共同完成一個複雜目標。聽起來邏輯很通，一個智能體搞不定的事情，多叫幾個一起來幹不就行了？
但真正搭過的人都知道，這裡面的水比看上去深。系統跑起來了，效果卻未必好，有時還不如單個智能體單獨干。問題出在那？是模型不夠強，還是提示詞沒寫好，或者根本沒有一套可遵循的最佳實踐？
論文地址：https://arxiv.org/abs/2512.08296這正是 Google Research、DeepMind 和 MIT 最新發佈的聯合研究想回答的問題。他們做了 260 個受控配置，橫跨 6 個基準、5 種架構、3 個模型家族，把可能影響結果的變數都控制住。他們得出的結論是，多智能體的效果不取決於你用了多先進的模型，而取決於任務結構適不適合分工協作。
他們把這套判斷方法整理成了三條可查詢的判據和一個貫穿約束。以前「什麼時候該用多智能體」「用那種架構」是憑經驗的啟髮式說法，這篇論文把它換成了能算的預測模型。輸入任務特徵和模型能力，就能算出該用那種架構。
下面先說三個任務原型的答案。
一、規劃、分析、工具密集三類任務，多智能體的用法完全不同
論文用了三個任務原型來示範這套方法怎麼用。
第一個是規劃任務。在 3D 環境裡合成物品，查配方、拿材料、放進合成格、取出成品。這類任務工具少、單智能體基線已經不錯，結論是直接用單智能體。
第二個是分析任務。給一家公司做財務盡調，收入、成本、市場因素各成一塊，可以分頭研究再彙總。單智能體基線中等，結論是用 Centralized 架構。這種架構有一個中央節點，負責把任務分給不同智能體，並在彙總結果前交叉核驗它們的輸出。
第三個是工具密集任務。比如 Workbench，提供 16 種工具。單智能體基線已經很高，但工具多意味著可平行的維度多，結論是用 Decentralized 架構。這種架構沒有中央節點，智能體之間直接通訊、互相質詢。
三種任務，三種架構，沒有一種是「多智能體更強」的答案。架構選得對不對，取決於任務長什麼樣、單智能體已經能做到那。
二、五種架構的完整對比
論文實際測試了五種架構。除了上面示範的 Centralized 和 Decentralized，還有三種：SAS（單智能體系統）是基線，所有多智能體的效果都跟它比；Independent 三個智能體平行無通訊，實現最簡單但收益最低；Hybrid 是 Centralized 和 Decentralized 的組合，既有層級控制又有橫向通訊，但在順序任務上退化最少。
從表裡能看到幾種架構的核心差異。Independent 三個智能體平行無通訊，通訊開銷為 0，LLM 呼叫次數是 O(nk)，代價最低但收益也最低。Centralized 有 orchestrator 做層級協調，通訊開銷 O(r·n)，在聚合前插入驗證。Decentralized 沒有中央節點，智能體之間 sequential debate，通訊開銷 O(d·n)，平行度最高。Hybrid 是層級加橫向靈活性的組合，通訊開銷 O(r·n+p·m)，最複雜也成本最高。
這五種架構不是隨意選的，主要覆蓋了協調的兩個關鍵維度。Independent 只有平行沒有通訊；Decentralized 只有通訊沒有層級；Centralized 只有層級沒有橫向；Hybrid 兩者都有。SAS 作為基線，用來衡量多智能體到底帶來多少收益。
三、怎麼判斷，先看基線，再看任務能不能拆
這套判據背後有三個判斷依據。
第一個是基線水平。 單智能體已經能拿到大部分分數時，剩餘空間有限，而協調開銷是實打實付出的。論文給出的分界線是 45%。基線低於這條線，多智能體有發揮空間；超過這條線，協調收益遞減。這是全文最穩健的一條發現。
第二個是任務能不能平行分解。 工具越多，可平行的維度越多，協調結構能拿到的分解收益越大。但要注意，「可分解」不是「任務能不能拆成子任務」，而是「拆開之後，各部分還需不需要通訊」。如果步驟順序固定、狀態共享，加協調是浪費；如果不同部分提供互補資訊，加協調是槓桿。
第三個是防錯靠什麼。 獨立平行跑的智能體之間沒有任何通訊，談不上協調，收益只有 2 到 4 個百分點。而能在聚合結果前插入驗證環節的架構，比如 Centralized 靠中央節點交叉核驗、Decentralized 靠智能體之間互相質詢，成功成本比最高。防錯靠的是驗證環節，不是智能體數量。 協調不足時多出來的智能體沒有驗證機制，只是把同一個提示詞跑幾遍取平均。
四、智能體數量有最優值，加得越多收益漲得越慢
除了這三個判斷依據，還有一個橫跨所有架構的約束。
智能體數量有最優值，而且代價漲得比神經網路參數還快。推理輪次隨智能體數超線性增長，對照神經網路參數縮寫的經典指數 0.76，智能體數的指數是它的兩倍多。每加一個智能體，它要參與同步、接受驗證，還可能傳播錯誤。
每多一個智能體，協調成本就高一截，而性能收益在某個點後開始遞減。最優值出現在「新加的智能體帶來的收益剛好被它的協調成本吃掉」的位置。論文裡的實測資料是 6 個智能體大約 69 輪推理。
為什麼協調成本漲得這麼快？除了同步和驗證本身的開銷，還有一個更麻煩的問題。一個智能體的錯誤輸出會成為另一個智能體的輸入，錯誤在系統裡滾雪球。Independent 架構在工具少時收益只有 2 到 4 個百分點，正是因為它的智能體之間不通訊、不驗證，錯誤一旦產生就直接帶進最終結果。Centralized 和 Decentralized 能拿到更高收益，不是因為它們平行度更高，而是因為它們在結果彙總前插入了驗證環節，把錯誤攔在了傳播路上。
這條約束的實際操作是「先證明小規模有效，再決定要不要擴展」。不要一開始就設計 10 個智能體的系統，先用 2 到 3 個驗證核心邏輯，確認性能收益能覆蓋協調開銷後，再逐步增加。反過來，如果一個 6 智能體系統效果不好，第一反應應該是減少智能體數量，而不是換更強的模型。
加智能體不是簡單的做加法。每多一個，協調成本就多一截，錯誤傳播的風險就高一層。這個代價是累加的，不是一次性付清。所以「多叫幾個一起來幹」這個思路，在多智能體系統裡不成立。
寫在最後
設計多智能體系統時，最該花的功夫是先確認任務值不值得協作。
單智能體基線已經能拿 45% 以上，加了只會變差。任務步驟固定、狀態共享，加了就是浪費。工具少、沒有可平行的維度，加了也拿不到分解收益。這三個條件任何一個命中，第一反應都應該是「別加」，而不是「換個更強的模型試試」。
真正需要多智能體的場景很窄。基線低、工具多、各部分獨立，同時滿足這三件事，協調收益才可能超過協調開銷。而即使滿足了，也要先小規模驗證，確認 2 到 3 個智能體能跑通核心邏輯，再決定要不要擴展。
下次設計多智能體系統前，先問自己這三個問題。答完再動手，比先堆 10 個智能體再調 prompt 要省事得多。
畢竟，加智能體不是免費的。每一分協調開銷，都要從推理預算裡出。 (Datawhale)