agents 合輯 10/19/2026

多 Agent 協作架構：主控、多層、對等、交接與工作圖

#agents#architecture#ai-collaboration#workflow

來源核對：2026-10-19。本文依論文與框架原始文件整理架構；選型與網站案例是本站的工程分析，未重現各文的效能實驗。本文的分類用於比較設計，不宣稱是一套統一標準。

先分開四個設計問題

多代理系統（Multi-Agent System, MAS）關心的是多個代理之間的控制權、資訊流、狀態及協調規則。同一模型可以支撐多個獨立代理；換幾個模型、開幾個聊天視窗，則不足以描述協作架構。

協作綜述將通訊結構、合作策略與靜態／動態協調分開討論 [1]。以下沿用這種分層思路，整理成四個設計問題：

設計面向	要決定什麼	常見選項
控制與通訊拓樸	誰派工、誰能向誰傳訊、誰決定下一步	中央主控、階層式、對等網路
工作流與調度	哪些任務有依賴、何時並行、如何匯合	流水線、平行分支、DAG、含循環的狀態圖
互動與裁決策略	代理如何互補、挑錯或整合分歧	主控綜合、產生與審查、辯論、投票、候選整合
狀態與通訊載體	哪些資訊共享，如何保留證據與版本	私有上下文、訊息、結構化產物、共享黑板

因此「主控式 + 平行研究 + 獨立審查 + 共享證據庫」可以是同一系統。子代理、群聊或 Skills 各只描述其中一部分。

控制拓樸：一主多工、多層管理與對等協作

一主多工：Supervisor／Orchestrator–Worker

主控代理拆解任務、委派專家、接收結果並整合；工作代理通常只看自己需要的上下文。Anthropic 的研究系統是這種模式的具體工程案例 [2]。

重要的是區分路由器（Router）與持續主控：路由器可只在入口分類、分流；主控則可能在取得結果後重新規劃、補派工作。兩者都能集中控制，但生命週期不同 [3]。

適用： 可分割的跨來源研究、跨領域分析、需統一輸出的任務。
設計重點： 每份子任務有明確範圍、輸入、產出格式、證據與回傳條件。
代價： 主控成為決策與上下文瓶頸；工作結果過度壓縮可能遺失限制或反證。

子代理可被包成主控可呼叫的工具，但「有子代理」不表示會並行執行，也不表示可任意彼此通訊。

階層式：Hierarchical Delegation

在主控與執行代理之間，再加入可派工的團隊主管。例如總協調者把工作分給研究組與工程組，組內各自分工。只把代理命名為 PM、工程師、QA，並不代表已有多層控制。

這是將局部規劃、協調與結果整合分散到不同層級的設計 [1]。可減少頂層需要直接管理的細節，但每層都會增加交接成本及資訊壓縮；跨組依賴仍需要明確接口。

對等網路：Peer-to-Peer／Decentralized

協作決策分散在多個代理，代理依局部資訊與通訊規則協調。網路可以是稀疏連接，不需要所有人與所有人互傳 [1]。

分散部署與去中心控制是兩回事。 多台機器仍可由一位主控決定所有工作；反過來，同一程序也能模擬對等協作。

對等設計的難點是任務認領、衝突解決、資訊傳播與結束判定。即使沒有唯一主控，也不能省略協調規則。

工作流：順序、交接、工作圖與群聊

流水線與 SOP：Pipeline

依固定階段交付產物，例如需求分析、設計、實作、驗收。MetaGPT 將角色與標準作業流程（SOP）結合，強調中間產物及階段驗證 [7]。

這種設計適合流程與責任已知的任務。上游錯誤仍會影響下游，因此每個階段需要輸入格式與驗收門檻。流水線也能由一般程式串接模型呼叫，不一定每個節點都是自主代理。

控制權交接：Handoff

代理把目前工作的控制權交給另一位專家，後者可直接繼續與使用者互動。這與主控「呼叫專家、等回覆、再自行回答」不同 [4]。

例如客服由問題分類轉交技術支援，再轉交帳務。交接時須決定傳遞完整歷史、摘要，或特定狀態欄位，以及誰仍有回覆與操作權限。

Handoff 是轉移控制的機制，不等於完整的去中心架構。 交接對象仍可受中央規則限制。

工作圖：DAG／State Graph

節點代表代理、工具或確定性程式，邊描述依賴、分支及匯合。LangGraph 用 State、Nodes、Edges 表達這類有狀態的工作流 [5]。

DAG 是有向無環圖；加入退回修改、重試或反思後，應稱含循環的工作圖或狀態圖。不能把所有代理流程都叫 DAG。

對平行節點，需要明確定義匯合條件與狀態合併方式，例如哪些分支完成才能進入審查、重複證據如何去重。多個代理同寫一個欄位，不能單靠提示詞處理衝突。

群聊與動態選角：Group Chat／Speaker Selection

代理在共享對話中輪流發言，由規則或選角器決定下一位。AutoGen 的 Selector Group Chat 可用模型選擇下一位參與者，並搭配終止條件 [6]。

群聊描述的是互動介面與發言調度；若選角器控制所有回合，控制權仍可能集中。共享歷史也會讓訊息量增加，應限制發言範圍、回合與終止條件。

互動策略：審查、辯論、投票與候選整合

策略	如何交換資訊	如何決定結果	需要避免的混淆
產生者／審查者	一位提出產物，另一位依準則檢查並回傳問題	測試、驗收規則或指定裁決者	審查者說通過，不等於客觀驗證完成
多代理辯論	各自提出答案，再讀取其他論點並修正	指定輪數後由聚合者或規則裁決	共識不等於正確
獨立候選與投票	初始解答彼此隔離，再比較候選	多數決、評分或可執行驗證	不能把同模型的多份輸出當成統計獨立
Mixture-of-Agents	上一層多份輸出成為下一層的參考	逐層綜合，形成最終輸出	不同於模型內部的 Mixture-of-Experts

原始多代理辯論研究讓不同模型實例先提出答案，再經多輪交換與修正 [8]。後續研究指出初始觀點多樣性與信心溝通會影響辯論效果，不能從「多討論幾輪」直接推論品質改善 [13]。

MoA 原始方法是分層整合：下一層代理使用上一層的輸出生成回應 [9]。這種「層」是答案聚合層，不一定是有管理權的主管層，也不代表每個代理都在操作外部工具。

產生／審查可以嵌入任何工作流；若只由同一代理自我反思，則未必構成多代理系統。

共享黑板與狀態：Blackboard

共享黑板把中間事實、假設、待辦與結果放在共同工作區。代理根據黑板內容貢獻資訊，調度機制再決定下一步；已有研究將這種架構用於 LLM 多代理系統 [10]。

它不等於所有代理讀取同一個長聊天紀錄，也不等於直接擁有可靠的長期記憶。實作時應分清：

資料來源與產物： 原始證據、模型推論、待驗證結論分開存放。
寫入協調： 任務所有者、資料版本與衝突處理。
可見範圍： 哪些代理讀得到哪些欄位，避免把所有內容廣播給所有人。
恢復條件： 中斷後哪些工作已完成、哪些仍在執行、哪些可以重試。

這些是本文的工程檢查項目，不是該論文宣稱已解決的全部能力。共享黑板可由中央主控調度，也能搭配其他控制拓樸。

如何選型與評估

以下是依上述研究整理的選型起點，不是效能排名：

需求	優先比較	驗證重點
平行處理可分割的子題	主控式、平行分支與匯合	子題是否重複、證據是否能追溯
多個團隊有各自責任與專業上下文	階層式、子工作圖	組間接口與摘要資訊是否遺失
使用者需接續與不同專家互動	Handoff	控制權、歷史與權限如何移交
階段依賴明確、需要重試與回復	流水線、狀態圖	每階段驗收、狀態合併與可重入性
想比較不同判斷或挑出錯誤	獨立候選、辯論、審查	是否比單代理及簡單投票更有效
多人逐步累積同一份問題狀態	共享黑板	資料歸屬、版本與寫入衝突