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代理框架。