理解 Manager 的子任務調用與 Handoff 的執行接管，區分上下文、任務狀態和控制權，分析多 Agent 的拆分條件與協作成本。
研究系統讓 Lead 委派搜索，再收回材料形成報告；並行編程讓多個 Agent 通過任務認領、Git 和測試共同推進項目。這兩種系統都包含多個 Agent，但任務在它們之間流動的方式並不一樣。
理解多 Agent 編排，需要看清三件事：誰決定下一步，工作結果返回給誰，誰繼續與用户交互。 Agent 的數量和角色名稱只能描述有哪些參與者，不能解釋這些參與者怎樣協作。
這一篇結合 OpenAI《A practical guide to building agents》的編排部分，整理兩種基本關係：Manager 把專家作為工具調用，Handoff 把後續執行交給另一位 Agent。 先理解控制流，再看信息怎樣跨邊界傳遞，以及什麼時候值得拆分 Agent。
一、Agent 之間怎樣分配執行控制權h2
先看子任務結果是否返回，再看當前執行者是否切換，這是兩種編排關係的核心邊界。
1. Manager：委派子任務，再接回結果h3
Manager Pattern 由一箇中心 Agent 負責整體請求，把有邊界的工作交給專家，再依據返回結果決定下一步。專家可以在自己的執行過程中連續調用工具；對外層而言，它仍然是一次有輸入、有結果的子任務調用。
以一個假設的售後請求為例：“包裹一直沒到，幫我看看能不能退款。”售後 Manager 可以分別委派：
- 物流專家： 查詢運輸事件，判斷是否存在異常，以及哪些情況尚未確認。
- 規則專家： 核對訂單適用的退款規則，説明申請條件和必要確認。
- Manager： 綜合事實和規則，向用户解釋可選方案，組織後續操作。
這是一種 agents as tools 的關係。物流專家不需要接管整段售後對話，只需把自己的查詢結果交回來。
例如，物流專家返回“運輸停留在轉運中心，尚未確認丟件”，規則專家返回“已達到申請條件，需要用户確認”。Manager 需要據此詢問用户是否申請退款，而不能直接回復“退款已完成”。專家的判斷、用户的確認和真實業務操作，是不同的任務狀態。
因此，委派不能只有一句“幫我處理售後”。一個有用的委派約定至少要明確：
| 約定 | 物流查詢示例 |
|---|---|
| 目標 | 核查訂單的運輸狀態，而不是處理整段售後 |
| 輸入 | 訂單標識、用户描述、已經核實的信息 |
| 範圍 | 可以查詢物流，不自行提交退款 |
| 返回內容 | 運輸事實、查詢依據、未確認信息 |
| 結束條件 | 已取得足夠證據，或明確説明信息缺口 |
Manager 保留的是外層流程與綜合答覆的責任。這不意味着它在等待專家時一直進行模型推理，也不意味着專家必須只調用一次工具。外層調用和專家內部的 Agent Loop 是兩層執行過程。
2. Handoff：轉交當前分支的後續處理h3
Handoff 不只是讓另一位 Agent 幫忙查一件事，而是切換當前執行者，由接收方繼續處理這個分支。
仍然是售後請求。如果入口 Agent 只負責識別問題類型，確認屬於訂單售後以後，就可以把處理交給訂單 Agent。之後由訂單 Agent 查詢情況、向用户追問並給出答覆，不必讓入口 Agent 轉述每一次交流。
兩種關係可以壓成：
Manager： 委派子任務 → 收回結果 → 自己繼續。
Handoff： 轉交當前分支 → 接收方繼續。
Handoff 是一次單向的執行轉移，不隱含“專家做完自動返回入口”。如果需要交回，應明確安排另一條交接關係。否則，原 Agent 不會像普通函數調用的調用者一樣，自然接回一個返回值。
有時 Handoff 也通過模型可調用的工具接口暴露，例如 transfer_to_order_agent。接口形式相似，不代表執行語義相同：普通專家工具完成後返回結果，Handoff 則讓運行程序切換當前 Agent。
交接也不等於任務完成。訂單 Agent 仍然需要核實狀態、確認用户意圖，並處理執行失敗。它接到的是後續處理責任，不是一張“已經成功”的憑證。
二、協作中的信息與責任怎樣銜接h2
確定誰繼續以後，還要説明接收者拿到什麼信息，以及多條調用和交接怎樣組合。
3. Context 與 State：傳遞背景、證據與執行進度h3
控制權解決“誰繼續”，信息傳遞解決“接收者憑什麼繼續”。切換了 Agent，卻沒有交代前面發生過什麼，後續判斷就可能重複、遺漏，甚至把建議當成已經執行的操作。
一次售後交接可以按下面幾類信息檢查：
| 信息 | 需要保留的內容 |
|---|---|
| 用户目標與限制 | 希望調查延誤；未確認是否申請退款 |
| 已核實事實 | 訂單標識、運輸事件、查詢時間與來源 |
| 已執行動作 | 已查詢物流；尚未提交退款申請 |
| 待辦與缺口 | 缺少承運商調查結果，需要向用户確認下一步 |
| 必要的業務狀態 | 身份校驗結果、已有申請標識等 |
其中，事實、推斷和動作記錄要分開。“符合申請條件”是一項判斷，“申請已提交”是一項動作結果，二者不能被壓成模糊的“退款處理中”。
這些信息也不一定通過同一種通道傳遞：
- 會話歷史保留此前的交流和工具觀察。
- 交接參數説明交接原因和必要標識。
- 應用狀態保存業務事實和執行進度。
一個交接對象裏有訂單號，並不表示接收方已經獲得完整歷史；業務狀態存在數據庫中，也不表示模型已經看見它。實現時需要檢查實際進入模型輸入的內容，以及接收者能夠通過哪些工具取得剩餘信息。
Manager 委派專家同樣有這條邊界。專家不應依賴未提供的背景，Manager 也不應假設返回的幾句話包含專家全部查詢過程。獨立 Context 減少干擾，但必須通過明確的輸入和輸出重新建立聯繫。
另外，交接信息不能代替權限檢查。知道訂單號、收到“用户想退款”的摘要，都不自動授予操作權限；真正執行時仍需遵守業務系統的校驗和批准規則。
4. Pattern Composition：比較與組合調用、交接關係h3
兩種模式的選擇，可以從具體的責任關係判斷，而不是先畫一個看起來復雜的多 Agent 架構。
| 維度 | Manager | Handoff |
|---|---|---|
| 交出的工作 | 有邊界的子任務 | 當前分支的後續處理 |
| 工作結束後 | 結果返回調用者 | 接收方繼續執行或答覆 |
| 用户交互 | 通常由 Manager 統一組織 | 接收方可以直接推進 |
| 適合的關係 | 多份結果需要綜合、比較或協調 | 專業角色能夠獨立處理當前分支 |
| 主要協調問題 | 委派是否清楚，彙總是否遺漏 | 交接是否正確，狀態是否完整 |
例如，物流、退款規則和補償方案需要綜合權衡時，Manager 有明確價值；如果訂單專家已經能夠獨立完成售後分支，入口 Agent 再轉述所有追問，就只增加了中間傳遞。
兩種模式也可以組合：
入口 Agent Handoff 給訂單 Agent；
訂單 Agent再以 Manager 的方式調用物流專家；
物流結果返回訂單 Agent，由它繼續回應用户。
這裏有兩種不同的連接：入口轉交處理，訂單 Agent 委派查詢。只要每條連接的返回關係清楚，系統不必全局只使用一種模式。
反過來，共享 Git 的並行開發並不能因為沒有中心 Orchestrator，就歸類為 Handoff。多個 Agent 可以通過共同產物和任務狀態協調，卻沒有發生“把當前對話的執行權交給另一位 Agent”的操作。共享狀態和執行交接是不同的協作機制。
三、什麼時候值得拆分多個 Agenth2
拆分需要解決具體的職責衝突，也要承擔新的信息傳遞和協調工作。
5. Single-Agent 與 Multi-Agent：拆分條件與協調成本h3
多 Agent 不一定比單 Agent 更有效。一個 Agent 連續查詢訂單、檢查物流和讀取規則，仍然可以完整完成售後任務；步驟多、工具多，都不是必須拆分的理由。
OpenAI 指南建議先儘量發揮單 Agent 的能力，再考慮拆分。這裏值得分析的是複雜性造成了什麼穩定的失敗，而不是工具數量是否超過某個閾值。
例如：
- 模型反覆混用不同業務規則，可能需要按領域劃分職責。
- 相似工具經常被誤選，應先檢查命名、描述和參數，而不是立刻增加 Agent。
- 不同專業結論需要綜合，可能適合中心 Manager。
- 某個分支需要持續追問和專門處理，可能適合 Handoff。
拆分的收益來自更聚焦的職責、工具集合和 Context；代價則來自新的通信邊界。輸入可能遺漏，結果可能失真，交接可能選錯，還會增加調用與等待。
因此，評價協作設計不能只看“每位專家都回答得不錯”。還要檢查整個請求是否正確完成：用户是否重複提供信息，動作是否被重複執行，失敗是否有人接住，最終答覆是否對應真實業務結果。
我理解的編排設計，不是給每項能力安排一個角色，而是把工作邊界、信息邊界和後續責任一起劃清楚。只有這些關係比拆分前更清晰，多 Agent 才真正改善了系統。
幾個關鍵問題，串起控制權、上下文與職責劃分h2
Manager 和 Handoff 都會調用另一位 Agent，決定性區別是什麼？
看工作結束後誰繼續。Manager 收回子任務結果，自己推進外層流程；Handoff 切換當前執行者，由接收方處理後續分支。
專家內部可以有自己的 Agent Loop 嗎？
可以。專家作為工具被調用，並不意味着它只有一次模型推理。它可以反覆使用工具完成子任務，再把約定的結果返回 Manager。
Handoff 會自動回到原 Agent 嗎？
不會隱式返回。需要交回時，應明確安排另一條交接；需要接收方繼續下一輪對話時，應用也要保存並恢復相應執行者與會話狀態。
有交接摘要，為什麼還需要區分任務狀態？
摘要可能混淆事實、判斷和已執行動作。接收方必須知道哪些操作真的發生過、哪些仍待確認，才能避免重複執行或錯誤宣佈完成。
工具很多時，是否應該直接拆成多個 Agent？
不一定。先檢查工具定義與指令是否清晰。如果改進接口已經解決誤用，拆分只會增加協調開銷；穩定的職責衝突才是更有意義的拆分信號。
Manager 是否一定串行，Handoff 是否一定並行？
都不是。Manager 可以調度獨立專家並行工作，也可以按依賴串行調用；Handoff 描述執行者的切換，不描述並行度。調度與控制權是兩個維度。
多 Agent 協作可以只靠共享倉庫嗎？
可以形成這樣的協作機制，但仍需任務認領、版本同步和驗證規則。共享倉庫不是自動的任務調度器，也不等於 Handoff。