單一 Agent vs 多代理 Multi-Agent:什麼情境該用哪一種?

上季我們幫一家保險公司收拾一個爛攤子。他們的技術團隊照著網路上最紅的架構,搭了一套七個代理人的核保助手:一個規劃師、一個檢索員、一個計算保費的、一個查法規的、一個寫理由書的、一個審核的,最上面還有一個 orchestrator 統籌。架構圖畫出來很壯觀,投影片上每個人都很興奮。

上線兩週,平均一筆核保要跑 40 秒,而且大約每六筆就有一筆最後的建議自相矛盾:計算保費的代理人用了 A 版費率,寫理由書的代理人卻引用了 B 版。使用者開始不信任它。

我們把它拆掉,重寫成一個單一 Agent,配三個工具函式。回應時間掉到 9 秒,矛盾幾乎消失。同一批需求,少了三分之二的程式碼。

這不是在說多代理沒用。是在說,單一 Agent vs 多代理這個選擇,大多數團隊一開始就選錯了方向。

先給一個能直接引用的定義

單一 Agent 是「一個大語言模型 + 一組工具 + 一段記憶」,在同一個推理迴圈裡自己決定下一步該呼叫哪個工具。多代理 (Multi-Agent) 是「多個各自獨立的 Agent,各有自己的提示詞、工具與上下文,透過訊息傳遞或一個協調者互相協作」。

關鍵差別不在「聰不聰明」,在於上下文是共享還是切割。單一 Agent 全程看得到完整脈絡;多代理則刻意把脈絡切成好幾塊,分給不同角色。切割帶來專注,也帶來資訊落差——上面那個保費費率的矛盾,本質就是資訊落差。

「多代理一定比較強」是怎麼來的迷思

這個迷思來自一個直覺類比:公司裡分工合作比一個人全包強,所以 AI 也該分工。聽起來很順,但它忽略了一件事——人類分工之所以有效,是因為溝通成本相對低,而且每個人都有常識去補上下文。LLM 代理人之間的溝通成本高得驚人:每一次交棒都要把上下文序列化成文字再塞回去,token 在膨脹、延遲在累積、資訊在每一跳流失。

分工在人類世界是省力,在 LLM 世界常常是加稅。你多養一個代理人,就多一層提示詞要維護、多一個會幻覺的環節、多一次交棒可能掉資訊。三個代理人的系統,除錯難度不是單一 Agent 的三倍,是接近九倍——因為錯誤會跨代理人傳染,你得同時看好幾份 log 才知道是誰在哪一步歪掉的。

什麼時候單一 Agent 更省、更穩

我們現在的預設是:先用單一 Agent,除非有明確理由才拆。以下情況,單一 Agent 幾乎總是贏:

任務是線性的、步驟之間高度相依。像核保、報價、審件這種「每一步都要看前一步結果」的流程,切割上下文只會製造落差,不會製造效率。

需要低延遲、即時回應。客服 Copilot、業務即時查詢這類場景,使用者等不了三次交棒。每多一個代理人,你就多押上兩到三秒。

團隊還在早期、需求在動。單一 Agent 的心智負擔小,改一個提示詞就能調整行為;多代理你改一處,常常要重新驗證整條協作鏈。

什麼時候多代理才真的值得

多代理不是不能用,是要用在它的甜蜜點上。我們判斷是否該拆的三個訊號:

第一,子任務可以真正平行,而且彼此不需要對方的中間結果。例如同時對一份併購標的做財務、法務、市場三份獨立盡職調查,最後再彙總——這種 fan-out/fan-in 的形狀,多代理能吃到並行的紅利。

第二,上下文大到單一視窗裝不下,或需要隔離。研究型任務要讀上百份文件,把檢索分散到多個 subagent、各自壓縮再回報,是為了對抗 context 稀釋,不是為了「分工」。

第三,不同子任務需要天差地遠的工具權限或人格。一個能動生產資料庫的代理人,和一個只能讀公開資料的代理人,基於安全該隔離——這時多代理是權責邊界,不是效能選擇。

一個實用的順序:先把單一 Agent 做到極限,量出它到底卡在哪——是延遲、是上下文爆掉、還是工具打架。等你能明確說出「就是這個瓶頸」,再針對那個瓶頸拆出一個代理人。不要為了架構圖好看而拆。

我們在替客戶做 Agentic 工作流時,幾乎都是從一個 Agent 起手,把它推上生產線、看真實使用率,再依實際卡點決定要不要長出第二個代理人。Demo 裡七個代理人合唱很好看,但真正扛得住每天幾千筆請求、還讓人願意一直用下去的,常常是那個安靜、便宜、好除錯的單一 Agent。