多代理工作流怎麼編排？Manager、Handoff、共享狀態與衝突控制

多代理工作流怎麼編排？Manager、Handoff、共享狀態與衝突控制

先講結論：多代理工作流只有在角色、權限或上下文明顯分離時才值得使用。本文聚焦Manager、Handoff、Router、共享狀態、並行衝突、工具權限與整合驗收，說明如何讓多個Agent協作而不互相覆蓋。

多代理工作流怎麼編排？Manager、Handoff、共享狀態與衝突控制在講什麼？ 多代理工作流只有在角色、權限或上下文明顯分離時才值得使用。本文聚焦Manager、Handoff、Router、共享狀態、並行衝突、工具權限與整合驗收，說明如何讓多個Agent協作而不互相覆蓋。

先記住哪個結論？ 核心是把「多代理工作流怎麼編排？Manager、Handoff、共享狀態與衝突控制」放回完整脈絡，區分已知資訊、背景與可延伸的判斷。

文中整理了哪些重點？ 文章依序整理：多代理工作流只有在角色、權限或上下文明顯分離時才值得使用。本文聚焦Manager、Handoff、Router、共享狀態、並行衝突、工具權限與整合驗收，說明如何讓多個Agent協作而不互相覆蓋。，並補充相關背景、影響與讀者可查證的線索。

讀者最容易忽略什麼？ 不要只看標題；請同時確認時間、人物、作品或事件名稱，以及資訊的原始來源。

這個主題和台灣讀者有何關係？ 對台灣讀者而言，清楚的中文脈絡、關鍵字與可延伸閱讀入口，能讓後續查證更有效率。

哪些資訊需要再核對？ 涉及日期、名單、票價、健康、政策、交通或產品規格時，仍應以文章列出的一手來源與最新公告為準。

如果只看一段，建議看哪裡？ 可先讀這個答案區與文章開頭，再依需求回到正文的背景、分析與常見問題。

這篇內容適合誰？ 適合想快速掌握「多代理工作流怎麼編排 Manager Handoff 共享狀態與衝突控制」並需要延伸閱讀入口的讀者。

一句話總結？ 一句話：多代理工作流只有在角色、權限或上下文明顯分離時才值得使用。本文聚焦Manager、Handoff、Router、共享狀態、並行衝突、工具權限與整合驗收，說明如何讓多個Agent協作而不互相覆蓋。

多代理工作流的重點，是讓不同角色在清楚邊界內分工、交接與驗收。Manager負責拆解與整合，Worker負責有限子任務；Handoff把整個任務轉交給更合適的角色；共享狀態則保存每個Agent都需要的任務事實與產物。

多代理不會自動提高效率。若角色共用同一套資料、權限與目標，單一Agent配合Skills通常更簡單。只有當上下文、工具、責任或信任範圍需要分離時，增加Agent才有實際價值。

• Manager-Worker適合中央角色拆解任務，再收回子結果統一驗收。
• Handoff適合請求需要由另一個專家完整接手，不再返回原角色。
• 共享狀態只保存任務必要資訊，不應把所有對話與私人記憶開放給全部Agent。
• 並行任務必須處理檔案、資料列、工具與決策的寫入衝突。
• 每個Agent都要有輸入、輸出、工具、預算、停止條件與責任人。

多代理工作流的編排與衝突控制

多代理工作流怎麼編排，核心在 Manager、Handoff、共享狀態與衝突控制，而不是把多個模型同時開著。文章將任務拆解、代理權責、交接格式、共享記憶與合併驗證具體化。

多代理如何不互相覆蓋

• Manager：分配工作包、設定驗收條件與決定何時合併。
• Handoff：交接必須包含背景、已做變更、證據、風險與下一步。
• 共享狀態：用版本、鎖、事件紀錄與明確權限避免兩個代理修改同一資源。
• 衝突端：合併前測試、人工確認與回滾策略比代理數量更重要。

本文以「多代理工作流的編排與衝突控制」為主線，補回人物、作品、制度、技術、場景與它們之間的關係，讓讀者能從具名實體一路追到實際流程與文化語境。

什麼時候需要多代理？

情況	建議
任務共享相同資料、權限與工具	先用單一Agent
不同角色需要互斥權限	拆分專用Agent
子任務彼此獨立，可以同時處理	Manager-Worker或Parallel Workers
請求類型不同，需要專家完整接手	Router加Handoff
提示規則過多且互相衝突	依責任邊界拆分Agent
只是希望得到更多答案	不要增加Agent，先改善評估與工具

完整的單一Agent工作流設計，可先閱讀AI Agent工作流怎麼設計？從任務契約到驗證的七層架構。多代理應是單一流程出現明確瓶頸後的架構選擇。

四種常見編排模式

1. Manager-Worker

Manager負責理解總目標、拆分子任務、分配Worker、檢查輸出與整合最終結果。Worker只看到完成自己任務所需的Context與工具，不直接修改總體規格。

這種模式適合研究、程式開發、內容製作與大量資料分析。Manager不能只做轉發，還需要解決重複、矛盾、缺漏與優先順序。

2. Router加專用Agent

Router先判斷請求類型，再把任務交給具備對應工具與規則的Agent。例如客服問題可分成帳務、技術、退貨與安全事件。Router的輸出應是明確類別與信心，而非直接產生最終答案。

3. Handoff

Handoff代表任務責任轉移。原Agent將目標、已確認事實、未解問題、來源與限制整理成交接包，由新Agent完整接手。適合權限、語言或專業領域需要切換的情境。

4. Evaluator-Optimizer

Generator產生方案，Evaluator依固定Rubric檢查，Optimizer根據具體問題修正。這種模式適合有清楚品質標準的內容、程式碼、資料抽取與規格文件，但必須限制最大修正輪次。

共享狀態應保存什麼？

• 任務ID、總目標、範圍與完成條件。
• 子任務清單、依賴、負責Agent與目前狀態。
• 已確認事實、來源、版本與不確定項目。
• 產物位置、格式、雜湊或版本ID。
• 人工決定、拒絕原因與適用範圍。
• 預算、截止時間、最大步數與停止訊號。

共享狀態不應包含所有Agent的完整對話、私人偏好、Secrets與無關工具結果。資訊越多不代表協作越好；過量Context會增加成本，也讓不同角色受到不必要資訊干擾。

每個子任務都需要Task Contract

task_id: research-03
goal: 核實產品價格與正式發布日期
inputs:
  - 官方產品頁
  - 發布公告
allowed_tools:
  - web_read
  - source_extract
output:
  format: json
  fields: [claim, source, date, confidence]
forbidden:
  - update_cms
  - infer_missing_price
stop_when:
  - two_primary_sources_agree
  - source_conflict_requires_human

Task Contract讓Worker知道自己不負責什麼，也讓Manager可以用固定格式比較子結果。缺少輸出Schema與停止條件時，Worker容易擴張任務、重複搜尋或交回無法整合的長篇文字。

如何處理並行衝突？

衝突類型	控制方式
多個Agent修改同一檔案	獨立Branch、Patch或檔案鎖
同一資料列被重複寫入	冪等鍵、交易與唯一約束
不同Agent提出矛盾結論	保留來源，由Evaluator或人裁決
工具資源互相搶占	Queue、Rate Limit與Concurrency Limit
任務依賴順序錯誤	DAG、狀態門檻與前置驗證
重複處理相同子任務	Task ID、Claim Check與租約機制

多代理系統的錯誤常發生在整合層，而非單一Agent。每個Worker都可能產出合理結果，但若同時覆蓋檔案、使用不同資料版本或各自修改共同規格，最終成果仍會失敗。

工具權限如何分配？

• 研究Agent：唯讀搜尋與資料抽取，不具CMS寫入權。
• 內容Agent：讀取研究Artifact並建立草稿。
• 驗證Agent：讀取需求、來源與草稿，只輸出問題清單。
• 發布Agent：只接受已確認內容，具有有限且可撤銷的寫入權。
• Manager：負責狀態與路由，不一定需要所有高風險工具。

工具權限應依角色與任務動態授予。讓所有Agent共用同一組Token與檔案權限，只是換了角色名稱，沒有建立真正隔離。

多代理的成本與停止條件

每增加一個Agent，都會增加模型呼叫、Context複製、工具競爭、整合與觀測成本。系統應限制子任務數量、平行度、每個Agent最大步數、總Token、工具費用與修正輪次。

• Manager無法產生新的必要子任務。
• 所有必需子任務已通過驗收。
• 來源衝突需要人工決定。
• 達到總成本、時間或失敗次數上限。
• 下一步需要更高權限或不可逆操作。

內容製作的多代理範例

1. Manager定義文章問題、讀者、範圍與完成標準。
2. 站內Agent找出相同搜尋意圖與可更新舊文。
3. 研究Agent核實人物、日期、產品與官方資料。
4. 寫作Agent依已確認Artifact完成正文。
5. 驗證Agent檢查來源、重複意圖、內鏈與格式。
6. Manager整合問題並產生最終版本。
7. 人工確認目標Post ID與修改內容。
8. 發布Agent執行一次更新並重新讀取驗證。

跨研究、程式、文件與設計的交接格式，可延伸閱讀跨域AI協作怎麼交接？Artifact、決策紀錄與驗收表。

常見問題

多代理一定比單一Agent快嗎？

不一定。只有可獨立拆分的任務才能真正平行。若子任務彼此依賴或需要頻繁共享Context，多代理可能因交接與整合而更慢。

Manager需要最強模型嗎？

Manager需要穩定拆解、路由與整合，通常比單純Worker更重視推理與長上下文。但是否使用最高成本模型，仍應由任務複雜度與Eval結果決定。

Agent之間應共享完整記憶嗎？

不應。只共享完成任務所需的狀態、來源與Artifact。私人偏好、Secrets與無關歷史應依角色隔離。

資料來源與延伸閱讀

• Anthropic：Multi-agent research system
• OpenAI Agents SDK：Agents與Handoffs
• LangGraph：State、Persistence與Human-in-the-loop
• 多Agent團隊怎麼協作？Manager、Handoff與Subagent
• 長任務AI Agent怎麼設計？上下文與驗收架構

多代理編排的成熟度，取決於角色邊界、共享狀態、衝突控制與最終責任是否清楚。Agent數量只是系統規模，不是品質指標。

YOLO_DEPTH_IMAGE_37410_20260818

多代理工作流的第一個設計問題，不是「要建立幾個 Agent」，而是「哪些責任真的需要分開」。如果所有角色都讀同一份資料、使用相同工具、擁有相同權限，拆成多個 Agent 只會增加 Context 複製、模型呼叫、交接失敗和整合成本。相反地，當研究、寫作、執行、驗證或高風險發布需要不同的資料範圍、工具權限和責任人時，多代理才有機會把邊界變成可測試的系統控制。

先判斷瓶頸，再選編排模式

Manager-Worker 適合一個中央角色拆解任務、分配獨立子任務，再收回結果統一驗收；Router 適合先分類請求，再把整個流程交給專用 Agent；Handoff 適合責任完整轉移，不要求原 Agent 持續管理；Evaluator-Optimizer 則適合品質規則明確、可以限制修正輪次的內容或程式工作。四種模式可以組合，但每增加一層，都要說明它解決哪一個可觀察問題。

模式	適用條件	主要風險	驗收重點
Manager-Worker	子任務可拆分，最後需要中央整合	Manager 重複分派或整合錯誤	任務依賴、輸出 Schema、完整性檢查
Router	請求類型差異大，專家工具不同	分類錯誤、信心不足仍繼續	路由準確率、fallback、人工轉接
Handoff	專業、權限或語言需要完整接手	上下文遺失、責任不清	交接包、接手確認、原角色停止
Evaluator-Optimizer	有固定 Rubric，可反覆改善輸出	無限自我修正、成本失控	最大輪次、品質門檻、停止原因

一個實用的決策規則是：若只需要更多資料，先增加工具或檢索；若只需要更好的答案，先改善 Prompt、Schema 和 Evaluator；只有當責任、權限、上下文或信任邊界必須分離時，才增加 Agent。這能避免把「多一個角色」誤當成「多一份智慧」。

Manager 的責任不是轉發，而是維持任務契約

Manager 要保存總目標、範圍、完成條件、子任務依賴、預算、截止時間和停止規則。它可以拆解和路由，但不應任意擴張任務，也不應把 Worker 的猜測直接升格為已確認事實。每一個子任務都要有輸入、允許工具、輸出格式、禁止事項、成功條件和最大步數；沒有這些欄位，Manager 很難知道何時算完成，Worker 也會把研究、決策和寫入混在一起。

task_id: research-03
goal: 核實產品價格與正式發布日期
inputs: [official_product_page, release_notice]
allowed_tools: [web_read, source_extract]
output: {format: json, fields: [claim, source, date, confidence]}
forbidden: [update_cms, infer_missing_price]
stop_when: [two_primary_sources_agree, source_conflict_requires_human]

Manager 收回結果時，要先做格式與範圍檢查，再做內容整合。缺少來源、超出欄位、使用禁止工具或未達停止條件的結果，應退回修正或標記為 incomplete，不應用一段看似流暢的摘要掩蓋缺口。整合後還要保留每個結論對應的 Worker、來源版本和時間，讓後續驗證可以追溯。

Handoff 是責任轉移，不是把整段對話丟給下一個 Agent

一個好的交接包只包含接手所需的最小資訊：任務目標、已確認事實、未解問題、來源、已完成 Artifact、限制、風險、下一步和停止條件。私人記憶、無關對話、Secrets、未驗證推論和原角色的內部草稿，不應因為方便而全部共享。交接前要由原角色整理和簽名，接手後要由新角色確認自己理解的範圍，兩端都要留下時間與版本。

交接欄位	應回答的問題
目標	接手後要完成哪一個可驗證結果？
已確認事實	哪些資料已由來源或測試支持？
未知與衝突	哪些地方不能猜，必須查詢或交人判斷？
Artifact	檔案、版本、Hash、位置與格式是什麼？
限制	不能使用哪些工具、資料、身份或寫入端點？
停止條件	什麼情況必須停下、回報或轉人工？

Handoff 之後，原 Agent 是否停止要明確定義。若兩個角色都以為自己仍然擁有任務，就會出現重複回覆、同時寫檔或互相覆蓋決策。可以把任務狀態設為 handed_off，只有新 Agent 確認接手後才能轉為 active；若接手逾時，回到 Manager 或人工，而不是由原 Agent 靜默繼續。

共享狀態要像資料合約，不是共享聊天室

共享狀態最少應包含任務 ID、總目標、子任務狀態、依賴、已確認事實、來源與版本、Artifact 位置、人工決定、預算、截止時間和停止訊號。Session 對話、Long-term Memory、Business Context 和 Audit Log 要分開管理，因為它們的讀取權限、保存期限、修改方式和刪除責任不同。讓所有 Agent 讀到完整歷史，通常只會增加成本與越權風險。

狀態更新應採 append-only 事件或版本化快照，避免一個 Worker 直接把另一個 Worker 的結論改掉。每個欄位要標記 owner、source、observed_at、confidence 和 version；若兩個來源衝突，保留兩者並建立 conflict 狀態，交由 Evaluator 或人工裁決。未解衝突不能被自動摘要成單一肯定句。

並行工作需要租約、版本與冪等

並行能縮短等待時間，但也會把衝突放大。多個 Agent 同時修改同一檔案、資料列、內容草稿或共享規格時，要有明確的 ownership、lease、版本檢查和合併策略。最小控制包括 Task ID、Claim Check、樂觀鎖、唯一鍵、冪等請求和明確的 conflict queue。不要用「最後寫入者獲勝」處理重要內容，因為它會靜默遺失較早但可能更正確的結果。

衝突	可用控制	不能依賴
同一檔案	獨立分支、Patch、鎖、三方合併	共享工作目錄與最後寫入者獲勝
同一資料列	唯一約束、交易、冪等鍵、CAS	重試時重新 POST
矛盾結論	來源並列、Evaluator、人工裁決	用語言流暢度決定真偽
工具資源	Queue、Rate Limit、Concurrency Limit	每個 Agent 自行無限重試
依賴順序	DAG、前置門檻、狀態轉移	靠 Prompt 提醒順序

若一個子任務被租約鎖定，其他 Agent 應看到 owner、開始時間、到期時間和目前狀態。租約過期後也不能直接搶寫；要先確認原執行者是否仍在執行、是否留下部分副作用，再由 Manager 或人工決定接管。這個流程看似保守，卻能避免兩個 Agent 同時修復同一個錯誤。

把工具權限綁在角色與任務上

研究 Agent 可以讀取官方來源，卻不需要 CMS 寫入權；內容 Agent 可以建立草稿，卻不應直接發布；驗證 Agent 可以讀取需求、來源和草稿，卻最好只輸出問題清單；發布 Agent 只有在內容、身份和核准條件全部成立時，才獲得一次性、可撤銷的有限寫入權。Manager 負責狀態和路由，也不必因此擁有所有高風險工具。

權限還要跟著 Handoff 改變。當任務從研究交給發布，發布角色只接收已確認 Artifact 和允許的 Post ID，不應自動繼承研究角色的所有網路、檔案和記憶權限。短效 Token、工具級 Scope、環境隔離、可撤銷 Session 和完整委派鏈，才是多代理安全的基礎；把同一組管理員 Token 放給所有角色，只是把單一風險複製更多次。

Evaluator-Optimizer 要有固定 Rubric 和最大輪次

Generator 產生文章、程式或資料結果，Evaluator 依固定 Rubric 檢查，Optimizer 只修正被明確指出的問題。Rubric 應包含正確性、來源、格式、完整性、權限、成本和停止條件，而不是一句「請再好一點」。每一輪要記錄輸入版本、問題清單、修正內容、評分與剩餘風險，並設定最大輪次和總預算。

如果 Evaluator 和 Generator 使用同一套錯誤假設，反覆迭代只會把偏差磨得更漂亮。高影響內容應加入獨立來源、反例、負向測試或人工抽查；程式碼則要有測試、靜態檢查和執行結果；資料抽取要保留原文與欄位級證據。Evaluator 的分數只能是決策輸入，不能取代真實 read-back。

多代理的停止條件與成本上限

每增加一個 Agent，就增加模型呼叫、Context 轉換、工具競爭、觀測和整合成本。系統應限制子任務數量、最大平行度、每個角色的步數、總 Token、工具費用、Retry 次數和 Evaluator 輪次。若 Manager 無法產生必要的新子任務、所有必需結果已驗收、來源衝突需要人工、達到時間或成本上限，系統就應停止，而不是為了「完成」繼續製造更多摘要。

停止狀態要能區分 succeeded、blocked、incomplete、conflict、timeout 和 handed_off。每一種狀態都要有下一步：成功可交付，blocked 要回報原因，incomplete 要列缺項，conflict 要交裁決，timeout 要查詢狀態，handed_off 要等接手確認。只回傳一段「任務完成」的文字，會讓上層無法判斷是否真的達到業務驗收。

內容製作的多代理驗收範例

1. Manager 定義文章問題、讀者、範圍、來源門檻與交付格式。
2. 站內 Agent 找出相同搜尋意圖、既有文章與可能的內鏈關係。
3. Research Agent 只讀取官方資料，回傳 claim、source、date、confidence。
4. Writing Agent 只使用已確認 Artifact，產生正文、圖片說明與來源區塊。
5. Verification Agent 檢查來源、深度、重複意圖、內鏈、格式與禁止內容。
6. Manager 整合問題，但不得自行補造缺失事實。
7. 人工確認目標 Post ID、內容 Hash、狀態與不可變欄位。
8. Publisher 以最小權限寫入，再由 authenticated、public 與 crawler read-back 驗收。

這個流程把「研究正確」與「發布安全」分開。Research Agent 可以提出證據，不能直接改 CMS；Publisher 可以執行受控寫入，不能自行改變文章目標或發布狀態。當任何一段交接缺少來源、身份、版本或核准，整個流程應停在該段，而不是用下游 Agent 的自信語氣掩蓋缺口。

官方文件能確認什麼，不能替你的系統背書

本文以Anthropic 多代理研究系統工程文章核對多代理研究、路由與平行工作概念；以OpenAI Agents SDK 官方 Agents 文件核對 Agent、工具與 Handoff 的介面概念；以LangGraph 官方概覽核對有狀態圖、持久化與人機協作的設計方向。這些來源能說明框架能力與公開模式，不能直接證明你的資料隔離、權限、成本、正確率、發布安全或 ROI；實際結果仍要靠自己的測試集、Trace、Policy 和 live read-back。

原創圖片是 YOLO LAB 的概念化多代理架構示意，不是 Anthropic、OpenAI、LangChain 或任何供應商的官方產品介面、基準圖表、安全保證或部署拓撲。多代理適合用來分離責任與信任邊界，不是用來增加答案數量；真正成熟的系統，會讓每個 Agent 知道自己可以做什麼、不能做什麼、何時停止，以及如何把證據交給下一個角色。

最後可以用一個問題檢查架構是否過度複雜：如果把所有 Worker 合併成一個 Agent，哪一個可驗證的安全、權限、上下文或平行性能力會消失？若沒有清楚答案，先維持單一 Agent；若答案是資料隔離、專業接手、並行縮短等待或獨立驗證，再為那個具體能力設計最小的多代理邊界。

部署後還要持續觀察每次路由、交接、重試、衝突與人工接手的比例。若多代理讓錯誤更難定位、等待時間增加或成本超過單一 Agent，應回到原始瓶頸重新簡化，而不是把更多監控和更多角色疊上去。可量測、可回退、可說明，才是值得保留的協作複雜度。

每次改動都要保存版本與回歸結果，讓團隊知道是架構真的改善，還是只是偶然成功。

增量觀察｜Manager的工作不是替所有agent做決定

多代理工作流的Manager更像編排器：拆分任務、分配權限、保存狀態、處理失敗與決定何時交回人類。若Manager把所有上下文重複傳給每個agent，系統會變慢且更難追蹤；若沒有明確的Handoff契約，agent之間就會互相覆寫、重複工作或把錯誤假設傳下去。

• Handoff：定義輸入、輸出、完成條件、失敗格式與責任邊界。
• 共享狀態：保存版本、假設、工具結果與待決策事項，而不是只依賴對話記憶。
• 衝突：使用鎖、佇列、版本檢查或合併策略，避免平行寫入互相覆蓋。
• 人工確認：高風險寫入、外部訊息與不可逆動作設置停點。

可維護的動態工作流不是agent越多越聰明，而是每個角色知道何時開始、何時交接、何時停止，以及誰對最後結果負責。