AI 工作實務
3 個 AI Agent 都完成任務，最終成果卻接不起來？Agent Handoff 要解決的是責任交接
多個 AI Agent 各自完成工作，成果為何仍接不起來？區分 handoff 與管理者模式，提供交接紀錄、版本、驗收、批准與重試控制的設計方法。
業務 Agent 產生了客戶需求摘要，報價 Agent 算出一份價格，法務 Agent 回覆合約條款「沒有明顯問題」，主管卻不知道哪份資料是最新版，也無法確認報價是否採用同一套折扣規則。多 Agent 並不天然等於自動協作。Agent Handoff（代理交接）真正要定義的是：工作何時轉交、接手者收到什麼、誰有決策權，以及失敗後由誰處理。
專題編輯：Derek Chou｜AI 技術與架構編輯
一、Agent Handoff 與「讓 AI 幫另一個 AI 做事」有什麼不同？
在多代理系統中，常見的兩種協作模式是：由一個管理者 Agent 保有流程控制權，呼叫專家 Agent 作為工具；或由當前 Agent 將工作控制權交給另一個專家 Agent。OpenAI 的 Agents SDK 文件對 handoff 的定義偏向後者：專家接管指定分支的對話；manager-style orchestration 則讓管理者繼續掌握流程。這是具體框架中的設計方式，不代表所有產品對「交接」的實作都完全相同。來源一、來源二
從企業流程看，真正重要的不是 Agent 有幾個，而是控制權、任務狀態、資料與批准權是否同步移轉。例如客服 Agent 將客訴交給退貨處理 Agent，不表示後者就有權直接退款；如果退款需要主管核准，該限制必須由系統層驗證，不應只放在自然語言提示詞中。
二、為什麼三個 Agent 都說完成，工作還是失敗？
實務設計可先檢查五個失敗點。其一，沒有唯一任務 ID，三份成果無法對齊。其二，交接時只有文字摘要，缺少原始檔案版本與資料契約。其三，接手者不知道前一階段是否真正驗收。其四，執行失敗後重試，造成同一筆報價或通知重複建立。其五，工作完成了卻沒有決策責任人，系統誤把「草稿完成」當成「已批准執行」。
以虛構的 30 人 B2B 設備供應商為例，客戶寄來最新規格。第一個 Agent 摘錄需求，第二個 Agent 按料號算成本，第三個 Agent 草擬報價。若第二個 Agent 未取得完整數量或最新幣別，應退回補件，而不是繼續交接。若第三個 Agent 看不到報價計算版本，即使句子通順也應停止對外發送。
三、企業級交接至少要有八個欄位
一份可以實作的 Handoff Record 至少應說明：task_id（唯一任務）、from_agent（移交者）、to_agent（接手者）、input_refs（輸入及版本）、expected_output（輸出契約）、approval_status（核准狀態）、acceptance_evidence（驗收證據）、retry_key（避免重複執行的識別碼）。此外可以增加最後更新時間、資料機密等級、失敗處理方式及回滾方法。
以下是跨部門報價的教學示意 JSON，不是某個 Agents SDK 的原生函式參數：
{
"task_id": "QUOTE-2026-014",
"from_agent": "requirements_agent",
"to_agent": "pricing_agent",
"status": "READY_FOR_VALIDATION",
"input_refs": [
{"path": "requirements/v4.json", "version": "4"},
{"path": "pricing/rules-v2.json", "version": "2"}
],
"expected_output": "pricing/quote-draft.json",
"acceptance": [
"所有品項必須有可查核的料號與數量",
"幣別及稅別須明確標示",
"超出核准折扣範圍時不得自動報價"
],
"approval_status": "NOT_APPROVED",
"acceptance_evidence": null,
"retry_key": "QUOTE-2026-014-PRICING-v4"
}
這份示意仍需要真正的系統權限、資料檢查與持久化儲存。retry_key 也只有在後端實作冪等性檢查時才能阻止重複寫入；單純把欄位寫進 JSON 不會自動產生安全效果。
四、最小可行流程：交接不是直接往下一站丟
一個穩健的設計，可分成五個節點：建立任務、確認輸入、執行專責工作、驗收交接、必要時升級人工核准。對每個交接點都要設定「可以繼續」、「需要補件」與「必須停止」三種結果，並把理由寫進紀錄。
例如需求 Agent 先輸出已結構化的需求表；協調者檢查必填欄位；再由報價 Agent 計算草稿；驗收節點比對折扣授權、計價規則及金額；只有授權人確認後，系統才允許對外發送。整條工作流的成敗，不以各 Agent 的自然語言完成聲明判定，而以文件、欄位、權限與外部副作用核對。
多代理框架可提供 handoff、tool、guardrail 與 tracing 等協作機制，但企業仍要自行定義業務責任、回滾、外部系統權限及監控。OpenAI Agents SDK 官方文件對這些機制有明確介紹。來源三
五、設計重試：交接失敗最怕重複寫入
若報價 Agent 寫入資料庫成功，但回應在網路途中遺失，協調者可能誤判任務失敗並重跑。沒有冪等性設計時，兩次請求可能產生兩份報價或重複寄送通知。企業可以要求相同任務與步驟組合使用唯一操作鍵，並在後端記錄已完成的外部副作用；重跑時先查狀態，再決定是否繼續。這是工程設計原則，實際可靠性仍取決於資料庫交易、API 行為與錯誤處理。
另一項必備規則，是不要把「取得輸出」誤當「可以對外行動」。Agent 可以在沒有最終批准的情況下產生草稿，但發送採購單、核准退款、修改帳務、部署正式系統等動作，必須採取分離權限與適當人工簽核。
六、交接成熟度的驗收方法
企業可選 10 個工作情境，每個情境安排正常、缺漏、過期與重試四種測試。舉例：使用過期價格表時是否會拒絕交接；少了客戶識別碼時是否退回；重試同一任務是否重複產單；主管尚未簽核時是否能意外寄出報價。10 個情境與四種測試是本文的示範範圍，應依真實風險調整。
建議追蹤的管理指標包括：成功交接率、缺件退回率、同任務重複執行次數、人工接手平均時間、外部副作用的誤觸發數，以及有證據可回查的完成比例。這些比「一個流程使用幾個 Agent」更能衡量導入品質。
企業不該先問要安排多少個 AI Agent，而應先問每次交接究竟有誰負責、依據哪個版本，以及出錯時能否停得下來。
延伸閱讀與來源
案例與 JSON 為教學示例，未代表實際企業系統已部署或完成資安驗收。主圖為原創生成流程示意，非產品操作截圖。
可下載工作範本
下載代理交接紀錄（ZIP）。範本為教學示例，採用前請填入經核准的真實資料。
相關閱讀
本文由 TARAISG（TIANDIREN AI SOLUTION GROUP）使用 AI 模型產生正文、整理來源並設計實務工具。方法依據與限制列於文末；案例為明確標示的教學假設。未有具名紀錄時，不宣稱經人工或專家審核。
查看內容製作與更正說明
