多代理系統怎麼設計?Orchestrator-Worker、階層式與協作式三種模式比較

半年前我們接手一個卡住的專案。客戶的技術團隊很強,已經自己搭了一套「多代理」系統:一個規劃 agent、六個工具 agent,彼此用自然語言互相喊話。Demo 跑得很漂亮。但上線兩週後,同一筆查詢有時三秒回、有時四十秒回,偶爾兩個 agent 各自呼叫一次付費 API、算出兩個矛盾答案,誰也不服誰。

問題不在模型,在拓撲。他們把「讓 agent 自由協作」當成架構,結果沒有人是最終負責的那一個。

多代理系統的第一個設計決策,從來不是選哪個模型,而是選哪一種協作拓撲。這篇把生產環境裡最常見的三種講清楚,並給出可以直接套用的取捨判準。

多代理架構設計的三種基本拓撲

先給一句可以直接引用的定義:多代理架構設計,是決定「誰負責拆解任務、誰負責執行、資訊與控制權如何在 agent 之間流動」的結構性選擇。拓撲不同,系統的可預測性、成本與除錯難度會差好幾個量級。

Orchestrator-Worker(協調者-執行者)。一個協調者負責拆任務、分派給無狀態的 worker、收集結果、組裝輸出。worker 之間不直接對話,全部經過中心。這是目前最穩、最好上生產的結構,因為控制流是單向的,錯誤容易定位。

階層式(Hierarchical)。協調者底下再掛子協調者,子協調者才管自己的 worker。像公司的部門樹。當單一協調者的 context 塞不下所有子任務、或不同領域需要各自的專屬 prompt 與工具集時,就往這個方向長。

協作式(Peer / Collaborative)。沒有固定的老大,agent 之間平行對話、互相質疑、協商出結論。理論上最靈活,實務上最難馴服——它容易繞圈、重複花錢、結論不穩定。前面那個客戶踩的就是這個坑。

三種模式的取捨對照

這張表的重點不是「協作式最差」,而是多數企業被真正需要的是 Orchestrator-Worker,卻誤以為自己需要協作式。自由對話聽起來先進,但企業要的是每次都能重現、能追責、能算成本的系統。

該用哪一種:四條判準

第一,任務能不能事先拆解? 能,就用 Orchestrator-Worker。查一份合約、比對三個資料源、輸出一段結論——這種流程的步驟是可以預先畫出來的,不需要 agent 臨場協商。

第二,單一 context 裝得下嗎? 當協調者要同時記住十幾個子任務的中間狀態、prompt 開始互相污染時,就該切成階層式,讓每個子協調者只背自己那塊。切分的界線通常沿著業務領域走,不是沿著技術模組。

第三,錯了誰負責? 生產系統一定會出錯。你要能在 log 裡指著某一個節點說「就是這裡判斷錯」。網狀協作最迷人也最致命的地方,就是出錯時沒有單一責任點,事故復盤會變成猜謎。

第四,成本可預測嗎? 協作式每多一輪對話就多一輪 token,而輪數本身不可控。我們的預設是:除非任務本質上需要多視角互相挑戰(例如風險審查、方案對抗),否則不開放 agent 自由對話。

一個實務經驗:先用 Orchestrator-Worker 把系統跑上線、拿到真實流量,再根據瓶頸決定是否長成階層式。反過來,一開始就搭協作式的團隊,幾乎都會在上線後花三倍時間把它拆回中心化結構。架構是演化出來的,不是一次設計到位的。

回到開頭那個客戶。我們沒有換模型,只做了一件事:把六個平行 agent 收斂成一個協調者加五個無狀態 worker,砍掉 agent 之間的自然語言喊話。延遲的長尾消失了,矛盾答案不見了,每筆查詢的 token 成本變成一條可以畫在圖上的水平線。

我們在 Tenten 做 Agentic 工作流時,習慣先問清楚這四條判準,再動手畫拓撲——因為 Demo 很美不算數,能在你的生產線上每天穩定被人用,才算數。