Multi-agent 系統在 2025 到 2026 年之間收斂出一個相當一致的架構：orchestrator 加上隔離 context 的 subagent，subagent 回傳摘要。這個收斂本身就是一份關於交接的實證——業界試過 peer-to-peer 廣播、試過共享完整對話歷史、試過讓所有 agent 看到所有東西，然後回到了「刻意限制資訊流」這個選擇。
兩家主要供應商的動向可以佐證這個方向。Anthropic 2026 年的架構走向是 brain／hands 的解耦與角色範圍明確的 subagent（4 月的 Managed Agents 與用於全端開發的三 agent harness），而不是更寬的平行 fan-out；工程實作上採用 context reset 搭配結構化的交接產物，讓下一個 agent 從一個明確定義的狀態繼續。OpenAI 則在 2026 年 4 月 15 日的 Agents SDK 更新裡，把 nested handoff history 改成預設關閉、需要明確開啟——直接針對 cross-agent context bleed。
這兩件事指向同一個判斷：交接的價值來自它是一個過濾器，不是一根水管。
四種特有的失敗模式
Context bleed。 下游 agent 拿到上游的完整對話歷史，包含試錯過程、被放棄的路徑、無關的探索。結果不是「資訊更充分」而是注意力被稀釋，關鍵指令埋在中段失效。OpenAI 把 nested handoff history 改為 opt-in，正是承認預設傳遞全部歷史是錯的預設值。
錯誤放大。 上游 agent 產出的一個推測（「這個欄位應該是 UTC」），在交接後被下游當成已驗證的事實使用，再交接一次就成了系統的既定前提。人類交接也有這個問題，但人會在語氣裡保留不確定性（「我猜是 UTC，你確認一下」），而摘要式的交接會把不確定性磨平——摘要的本質就是丟掉修飾語。這是 agent 交接最需要對抗的一種損耗。
責任漂移。 一條長鏈的 agent 各自完成了自己那段，沒有任何一個 agent 擁有最終結果。這是 責任轉移 在 AI 場景的重現，而且更嚴重——因為 agent 完全沒有「我覺得這整件事不太對」的動機。實務上的對策是讓 orchestrator 保留驗收責任，而不是把驗收也委派下去。
驗收標準在鏈上稀釋。 原始任務有明確的驗收標準，經過兩層委派後變成一句模糊的「實作這個功能」。每一層委派都必須重新攜帶驗收標準，這不是重複，這是防止損耗複利的必要動作。
Handoff payload 該裝什麼
從上面的失敗模式可以直接推導出一份交接負載的結構。它跟人類的交接文件同構，只是欄位更硬：
任務 — 一句話說清楚要達成什麼，可測試。已驗證的事實 — 我確認過的、下游可以直接依賴的東西（附驗證方式）。未驗證的假設 — 我推測但沒確認的，明確標記；這一欄的存在就是對抗錯誤放大。驗收標準 — 怎樣算完成。邊界 — 不要做什麼、不要碰哪些檔案。低信心清單 — 我覺得最可能出錯的地方。
明確不該裝的東西：完整對話歷史、探索過程的細節、已經被否決的嘗試（除非是為了避免下游重蹈，那就寫成一行「不要試 X，因為 Y」）。
這份結構跟 通用 handoff doc 範本 幾乎一樣，這不是巧合——這也是本專欄的核心論點之一：AI 的交接問題沒有一個是新的，它只是把舊問題的迭代週期從幾週壓縮到幾秒。
一個實作層面的常見誤解
「讓下游 agent 看到更多上下文，它就能做得更好」在直覺上成立，在實測上通常不成立。Anthropic 描述的 sub-agent 模式刻意讓子 agent 在乾淨的 context 裡工作，只回傳一份約一到兩千 token 的濃縮摘要給主 agent。這個瓶頸是設計出來的，不是妥協出來的：資訊瓶頸強迫每一層做出「什麼真的重要」的判斷，而這個判斷正是交接的核心工作。
換個說法：沒有損耗的交接不存在，能設計的只有損耗掉什麼。 傳遞全部歷史不是「無損」，它只是把選擇權推給下游的注意力機制去隨機決定。
Agent 交回給人：升級交接
任何 agent 系統都需要一條把控制權交回人的路徑，而這條路徑的品質決定了整個系統能不能被信任。觸發條件應該是明確的規則而不是模型的自由判斷：信心低於某個門檻、遇到不可逆的操作（刪除資料、發送對外訊息、金流）、觸及政策邊界、或連續嘗試失敗達到次數上限。
交回時要附的內容跟其他交接一致，但有一項特別重要：我卡在哪，以及我試過什麼。一個只說「我無法完成這個任務」的升級，把全部的重新發現成本丟給人；一個說「我試了 A 和 B，A 失敗是因為權限、B 失敗是因為 API 回傳格式跟文件不符，我建議 C」的升級，人接手後可以在幾分鐘內處理完。
這裡有一個容易被忽略的設計問題：升級的接收端必須有人。一個升級到無人監看的頻道的 agent，等於 交接即甩鍋 的自動化版本。
何時不該用 multi-agent
交接有成本，所以增加交接次數需要理由。精實的立場是減少交接次數優於改善交接品質，這個立場在 agent 系統裡依然成立：能在單一 context 內完成的任務，拆成三個 agent 只會增加三次損耗機會。值得拆的情況是清楚的——任務需要的探索量會撐爆 context（拆出去做，只回摘要）、需要真正獨立的視角（例如對抗式審查，共享 context 會污染獨立性）、或需要平行處理彼此無關的工作。
為了「架構看起來比較模組化」而拆 agent，是把工程美學的成本轉嫁給交接損耗。
延伸
- 人與 AI 之間的交接、記憶分層與載體 → 人↔AI 的上下文交接
- handoff payload 的可抄用格式 → 交接產物模板
- 這些架構主張的證據強度 → 客觀檢視：主張 vs 可佐證
- AI 輔助工程的整體紀律 → Engineering AI Coding Methodology
- 回到全景 → Handoff 專欄首頁