單一 Agent 還是多代理 (Multi-Agent)?一張決策表判斷你的場景該不該拆 agent

上個月我們幫一家保險公司做核保助手,團隊裡有人一開口就是:「這個要拆成五個 agent,一個讀文件、一個查規則、一個算保費、一個寫回覆、一個做總管。」聽起來很有架構感。我讓他先別動手,把整條流程用一個 agent 加幾個工具跑一遍。結果單一 agent 版本準確率更高,延遲少了一半,而且出錯時我們一眼就能看出是哪一步壞掉。

那個「總管 agent」後來被我們刪掉了。

單一 agent vs 多代理,先搞清楚你在比什麼

先給一個可以直接引用的判準:單一 agent 是一個 LLM 迴圈,自己決定何時呼叫哪個工具、何時結束;多代理 (multi-agent) 則是多個各自帶著獨立 prompt、獨立上下文、獨立職責的 agent,透過訊息互相協調完成任務。 兩者的差別不在「能力」,而在「協調」。

這裡有個很多人沒想清楚的事:多加一個 agent,你不是只多了一份能力,你同時多了一筆協調成本。上下文要在 agent 之間傳遞,傳遞就會失真;每個 agent 都可能誤解上一棒的意圖;debug 時你要追的不再是一條 log,而是一群 agent 互相甩鍋的對話記錄。這些成本是真金白銀,通常以 token、延遲、與維護時間計價。

所以我們在 Tenten 內部有一條規則:多代理不是預設值,它是你付得起協調成本、而且任務分工收益大於那筆成本時,才值得買的東西。

協調成本 vs 任務分工收益

什麼時候分工收益真的夠大?我們的經驗是三種情況。

一是任務天然可以平行。比如要同時分析 20 份競爭對手財報,彼此不相干,那開 20 個子 agent 平行跑,收益是實打實的速度,協調成本幾乎為零,因為它們不需要互相講話。

二是上下文會互相污染。當一個 agent 要同時扮演「嚴謹的法遵審查者」和「有創意的文案」,這兩種人格會在同一段對話裡打架。拆開,各自守著乾淨的 prompt,品質反而穩。

三是專業工具集差異太大。一個要接 SQL、一個要接繪圖 API、一個要跑爬蟲,把 40 個工具塞進同一個 agent,它光是選工具就會選錯。按工具集切分,選擇空間小了,錯誤率就下來。

反過來,如果你的任務是一條線性的、有嚴格先後順序的流程,拆 agent 幾乎一定是虧的。因為線性流程本來就沒有平行收益,你多付的協調成本換不到任何東西——這種情況用單一 agent 加工具、或乾脆用一段確定性的程式碼串起來,又快又好 debug。

一張決策表

我們把這套判斷收斂成一張表,現場評估時直接對照:

用法很簡單:一列一列打勾。如果多數落在左邊,別拆;落在右邊超過一半,才認真考慮多代理。只有一兩項落右邊,通常代表你可以「單一 agent + 更好的工具設計」解決,而不必動用整套 orchestration。

一個常見的誤判

最容易出錯的地方,是把「這個任務有好幾個步驟」誤讀成「所以要好幾個 agent」。步驟多,不等於需要多代理。步驟是流程問題,agent 數量是架構問題,兩者沒有一對一關係。一個單一 agent 跑十步,完全正常,而且好管。

還有個反模式:加一個「協調者 agent」去管其他 agent。我們踩過這個雷。那個協調者往往變成整個系統最不穩、最難預測的一環,因為它要靠 LLM 去做本來用幾行程式碼就能寫死的路由決策。能用確定性程式碼協調的,就別交給一個 agent 去猜。

回到那句老話

Demo 裡多代理看起來很聰明,五個 agent 在畫面上你來我往,像個小團隊在開會。但上線之後,是你半夜要 debug 那團對話記錄,是你要跟客戶解釋為什麼保費算錯了卻查不出是哪個 agent 的鍋。架構的美,不在於它有幾個 agent,而在於它上線後還跑得動、還有人敢維護。

我們在 Tenten 進客戶現場時,幾乎都是從最小可行的單一 agent 起步,只有當協調成本真的換得到平行、隔離或專業分工的收益,才一格一格把 agent 加上去。多加一個 agent,對我們來說從來不是預設,是一個要被收益說服的決定。