Agent交接模式：AI代理之間的任務路由
Agent交接模式是指一個AI代理將任務、累積的上下文和執行權限移轉給另一個代理的協定。它決定了哪些資料跨越邊界、什麼被捨棄以及憑證是否隨任務傳遞。大多數交接失敗不是路由失敗，而是上下文遺失或憑證洩漏的失敗——這些問題只有當下游代理靜默失敗或被攻破的代理竊取敏感載荷資料時才會顯現。
Agent交接模式是一種軟體設計模式，規定自主AI代理如何將任務委託給對等或專家代理，明確上下文傳輸的資料契約、任務交付的路由機制以及防止代理間憑證或上下文洩漏的隔離保證。
四種經典交接模式
推送交接：呼叫方直接喚醒被呼叫方
在推送交接中，呼叫代理建構包含任務上下文的載荷並直接通知接收代理——通常透過函式呼叫、傳送訊息或呼叫喚醒被呼叫方的API。呼叫方精確控制被呼叫方接收哪些資料、何時接收以及哪個代理處理任務。
推送交接是OpenAI Agents SDK的handoff()原語（GitHub 27,133星，MIT授權）使用的模式。呼叫方可以選擇傳入一個input_filter函式，在傳輸前刪除或轉換上下文欄位。沒有input_filter時，包含所有敏感內容的完整上下文視窗都會傳給被呼叫方。
優勢：低延遲，對任務路由的直接控制，在可觀測性工具中易於追蹤。
風險：呼叫方必須明確刪除憑證和敏感上下文；呼叫方與被呼叫方的緊密耦合意味著新增或刪除專家代理時路由邏輯必須更改。
拉取分發：被呼叫方從共享佇列中取得
在拉取分發中，呼叫代理將任務寫入共享佇列或收件匣，不直接通知任何特定代理。被呼叫代理監控佇列並取得與其能力相符的任務。這實現了跨工作池的負載平衡，並將呼叫方從了解哪個特定代理將處理工作中解耦。
拉取分發減少了憑證暴露：佇列訊息只包含任務描述和輸出鍵指標，而不是呼叫方的完整上下文。
優勢：水平擴充，鬆耦合，相同工作者之間的自然負載平衡。
風險：負載下佇列深度可能無限增長；任務順序保證取決於佇列語義；可觀測性需要跨多次佇列讀取關聯任務ID。
黑板路由：基於指標的上下文隔離
在黑板指標交接中，呼叫方將輸出寫入共享持久儲存上的命名鍵（例如output/researcher/task_abc123），並僅向被呼叫方傳送鍵名。被呼叫方讀取鍵並精確擷取所需的欄位。原始憑證、中間草稿內容和呼叫方的完整上下文永遠不會出現在交接訊息中。
OpenLegion的hand_off()函式原生實現了此模式：它將輸出資料寫入黑板上的output/{agent_id}/{handoff_id}，在接收方的收件匣中建立帶有該鍵指標的任務項目，並喚醒接收方。儲存在Vault中的憑證由Mesh在執行時注入。
優勢：最高憑證隔離，被呼叫方只讀取所需內容，透過鍵版本歷史的完整稽核追蹤。
風險：與直接推送相比增加了讀取操作；需要具有適當存取控制的可靠共享儲存。
串流交接：增量上下文傳輸
在串流交接中，上下文在呼叫代理產生時逐令牌或逐區塊傳輸，而不是等待完整輸出。這最小化了即時管道中的端對端延遲。
串流交接具有最高的憑證暴露風險：串流可能包含在呼叫方有機會篩選之前在推理途中產生的敏感內容。
優勢：最低端對端延遲，實現即時多代理協作。
風險：最難保護，最複雜的觀測，需要被呼叫方優雅處理部分上下文。
OpenLegion的觀點：為什麼上下文遺失和憑證洩漏是真正的交接錯誤
大多數多代理交接失敗屬於兩類：上下文遺失錯誤和憑證洩漏錯誤。兩者都可以透過設計來預防。
上下文遺失數字：LLM上下文壓縮評估一致發現，交接邊界的簡單截斷相比結構化摘要會降低多跳推理任務的任務完成率。解決方案不是更大的上下文視窗，而是具有已完成工作、剩餘工作和關鍵發現明確欄位的結構化交接載荷。
憑證洩漏：OWASP LLM06:2025（敏感資訊洩露）明確將透過代理間訊息傳遞的憑證洩漏列為十大LLM漏洞。
上下文遺失問題：邊界處遺失了什麼
上下文遺失的根本原因是呼叫代理知道的內容與交接載荷傳達的內容之間的不一致。結構化交接載荷可防止這種情況：呼叫方明確填寫欄位：任務目標、目前已完成的工作、未完成的子任務、關鍵發現和輸出鍵指標。
透過交接載荷的憑證竊取（OWASP LLM06:2025）
Google ADK的transfer_to_agent()將包含對話歷程的完整Session物件傳給接收代理，預設情況下建立最多32K令牌的上下文傳輸。使用任一框架的團隊需要根據AI代理安全性：憑證隔離和提示注入防禦稽核其交接實現。
作為安全預設值的黑板指標模式
黑板指標模式在協定層級消除憑證暴露，而不是依賴應用層篩選。儲存在OpenLegion Vault中的憑證永遠不會注入代理上下文。
主要框架如何實現交接
OpenAI Agents SDK：帶input_filter的handoff()（27,133星）
openai/openai-agents-python（GitHub 27,133星，MIT授權）將handoff()實現為推送模式。input_filter參數在v0.0.5（2025年3月）新增，需要明確選擇啟用。
from agents import Agent, handoff, RunContextWrapper
def strip_credentials(ctx: RunContextWrapper, input_data: ResearchInput) -> ResearchInput:
return ResearchInput(task=input_data.task, context=input_data.context)
researcher = Agent(
name="researcher",
handoffs=[handoff(writer_agent, input_filter=strip_credentials)]
)
Google ADK：transfer_to_agent()和Session物件傳輸（20,100星）
google/adk-python（GitHub 20,100星，Apache-2.0）透過transfer_to_agent()實現交接，傳遞包含對話歷程的完整Session物件。接收代理接收所有內容，必須明確捨棄不相關的歷程。
LangGraph：帶共享型別狀態的Command(goto=)
LangGraph（langchain-ai/langgraph，Apache-2.0）透過Command(goto='節點名')實現代理路由，可選狀態更新。狀態是跨圖中所有節點共享的型別字典。LangGraph的共享狀態模型不提供節點間的憑證隔離。
from langgraph.types import Command
def researcher_node(state: AgentState) -> Command:
result = researcher.invoke(state)
return Command(
goto="writer",
update={"research_output": result, "completed_steps": state["completed_steps"] + ["research"]}
)
OpenLegion：帶黑板指標和收件匣投遞的hand_off()
OpenLegion的hand_off()函式原生實現黑板指標交接。
hand_off(
to="writer",
summary="研究完成：langchain-alternative，2847字的原始資料",
data='{"topic": "langchain-alternative", "sources_key": "research/langchain-alt-sources", "word_count_target": 3000}'
)
交接資料契約
應包含的內容：任務摘要、輸出鍵、相關歷程
設計良好的交接載荷是結構化規格，而非謄本轉儲。包含：
- 任務摘要（200字以內）：被呼叫方需要完成的內容
- 輸出鍵指標：呼叫方輸出儲存的黑板鍵
- 已完成工作摘要：已經完成的內容，作為事實而非對話陳述
- 未完成的子任務：被呼叫方負責的具體項目
- 結構化參數：被呼叫方任務所需的任何型別輸入
應排除的內容：原始憑證、完整上下文視窗、中間草稿
從交接載荷中排除：
- API金鑰、令牌和憑證：應由Mesh在執行時注入
- 完整對話記錄：截斷為相關摘要
- 中間推理草稿：呼叫方的思維鏈對被呼叫方沒有用處
- 被呼叫方角色不需要的資料：對上下文也應用最小權限原則
交接路由機制
靜態路由：硬式編碼的代理ID
靜態路由將特定類型的每次交接傳送給特定的命名代理。實現簡單，易於追蹤。當目標代理不可用、過載或被替換時會中斷。
動態路由：LLM選擇的專家
動態路由使用LLM呼叫根據任務特徵選擇適當的專家代理。提供彈性，但增加延遲並在LLM錯誤分類任務時引入路由錯誤的可能性。
條件路由：基於規則的升級
條件路由應用確定性規則來選擇目標代理。比基於LLM的路由更可預測，但需要為每個路由條件明確定義規則。
回退和逾時處理
每次交接應定義被呼叫方在逾時視窗內未回應時的處理方式。選項：
- 用同一被呼叫方重試：當失敗可能是暫時性的時適合
- 重新路由到備選代理：當主被呼叫方持續不可用時適合
- 升級到營運者：當任務需要人工判斷時適合
- 將失敗寫入黑板並繼續：當下游任務是選擇性的時適合
交接模式安全性和可靠性比較
| 維度 | 推送交接 | 拉取分發 | 黑板路由 | 串流交接 |
|---|---|---|---|---|
| 路由機制 | 直接喚醒被呼叫方 | 共享佇列/收件匣取得 | 鍵寫入+被呼叫方監視 | 增量令牌串流 |
| 上下文隔離 | 呼叫方控制載荷；需要input_filter | 僅佇列訊息 | 最高：被呼叫方只讀取命名鍵 | 最低：完整上下文跨越邊界 |
| 憑證暴露風險 | 中等：取決於input_filter選擇 | 低：佇列僅持有任務指標 | 極低：憑證從不在載荷中 | 高：串流可能包含敏感上下文 |
| 可觀測性 | 每次交接單個追蹤事件 | 佇列深度+取得事件 | 鍵版本歷程+收件匣事件 | 需要令牌級追蹤 |
| 延遲 | 最低 | 低（佇列讀取開銷） | 低（黑板讀取開銷） | 最低端對端（串流） |
| 最適合 | 緊密耦合的專家委託 | 負載平衡的工作池 | 非同步解耦管道 | 即時協作 |
常見問題
什麼是Agent交接模式？
Agent交接模式是將任務從一個AI代理移轉到另一個代理的協定，指定哪些上下文資料跨越邊界、如何通知接收代理以及防止憑證或記憶體洩漏的隔離保證。四種經典模式是推送交接、拉取分發、黑板指標路由和串流交接，各有不同的安全性、延遲和可觀測性取捨。
OpenAI Agents SDK如何實現交接？
OpenAI Agents SDK（GitHub 27,133星，MIT）將handoff()實現為推送模式。呼叫代理使用目標代理和選擇性的input_filter函式呼叫handoff()，該函式在傳輸前從上下文中刪除欄位。input_filter參數在v0.0.5（2025年3月）新增，需要明確選擇啟用；沒有它，完整的上下文視窗將傳給被呼叫方。
Google ADK如何實現Agent交接？
Google ADK（GitHub 20,100星，Apache-2.0）使用transfer_to_agent()，將包含對話歷程的完整Session物件傳給接收代理。預設情況下建立最多32K令牌的上下文傳輸。接收代理接收完整歷程，必須明確捨棄不相關的先前上下文。
什麼是黑板指標交接模式，為什麼它更安全？
在黑板指標交接中，呼叫方將輸出寫入共享儲存上的命名鍵（如output/agent-id/task-id），然後只向被呼叫方傳送鍵指標，而非資料本身。被呼叫方只讀取所需的欄位。憑證永遠不會出現在交接訊息中，消除了OWASP LLM06:2025（敏感資訊洩露）的竊取向量。OpenLegion的hand_off()原生實現了此模式。
Agent交接中存在哪些安全風險？
主要風險是憑證竊取：在交接期間傳遞的上下文物件中包含環境變數、承載令牌或API金鑰的框架會將它們暴露給可能已被攻破的接收代理。OWASP LLM06:2025將此列為十大LLM漏洞。次要風險是上下文污染。
如何處理交接失敗和逾時？
健全的交接管道定義逾時和回退路徑：用同一被呼叫方重試、重新路由到備選專家、升級到人工營運者或將失敗記錄寫入黑板。呼叫代理應追蹤交接ID並監控任務完成事件。
交接載荷應包含哪些資料？
包含：簡潔的任務摘要（200字以內）、共享儲存上輸出資料鍵的指標、已完成工作的事實、未完成的子任務以及被呼叫方角色所需的結構化參數。排除：原始API憑證、完整對話記錄、中間推理草稿以及被呼叫方角色不需要的任何資料。
OpenLegion中的安全Agent交接
交接邊界是大多數多代理可靠性問題的起源。上下文遺失會降低下游任務品質，載荷中的憑證洩漏會建立隨管道長度增長的竊取風險。
OpenLegion的黑板指標交接在協定層級解決了這兩個問題。hand_off()將輸出寫入命名鍵，只向接收方的收件匣投遞指標，並依靠Vault代理憑證注入。接收方從黑板讀取恰好所需的內容，不多不少。
對於擷取交接協定遺漏的失敗的監控層，請參閱代理可觀測性：跨管道階段追蹤交接。對於確定選擇哪種交接模式的框架層，請參閱比較生產部署的AI代理框架。