Handoff 交接模式：控制权的单向移交
一句话结论：Handoff（交接）是多智能体协作里最简单的编排原语——一个智能体把对话控制权单向移交给更合适的专家智能体，之后由专家全权接管，原智能体不必留在场。OpenAI 开发者文档把它定位为”专家应当拥有下一段对话”时的首选模式。
Handoff vs Agent-as-Tool：一张表分清
| 维度 | Handoff | Agent as Tool |
|---|---|---|
| 控制权 | 完全移交，专家接管对话 | 留在管理者手中 |
| 典型场景 | 客服分流、话务转接 | 摘要、分类等有界子任务 |
| 最终答复归属 | 当前接手的专家 | 中心管理者 |
| 可追溯性 | 分支清晰但全局视野弱 | 单一主线，易审计 |
判断口诀：下一个回答该由谁负责？专家负责就 handoff，管理者负责就当工具调。
用 OpenAI Agents SDK 实现三智能体分流
经典客服场景：分流员接下用户第一句话，判断意图后把控制权移交给账单、退款或订单专家。
from agents import Agent, Runner
billing = Agent(name="Billing agent")
refund = Agent(name="Refund agent")
triage = Agent(
name="Triage agent",
handoffs=[billing, refund],
)
result = Runner.run_sync(triage, "我上周的订单怎么还没退钱")模型看到 handoffs 列表后，会把每个目标智能体当成一个可调用的特殊工具；一旦调用，执行立即切到新智能体并带上最新对话状态。需要回退时，可给专家配一条指回分流员的 handoff 。
三条实践红线
- 路由面要窄：每个专家的职责边界写窄一点，handoffDescription 保持具体简短，模型才选得准。
- 别过早拆分：官方建议能用一个智能体解决就别拆——拆分带来更多提示词、更碎的轨迹和更多审批面。
- 交接即边界：移交后原智能体的上下文不再参与决策，涉密信息要在移交前过滤。
Handoff 与 ReAct 是互补关系：单专家内部用 ReAct 边想边做，跨专家切换用 handoff 。别拿 handoff 去做本该在一个智能体里完成的推理循环。
Handoff 适合”接力”，需要中心化调度时应上管理器架构，对比见站内多智能体编排：Lead + Subagent 架构；单智能体的行动循环参考Agent 设计模式 ReAct 实战；还在纠结要不要上多智能体，先做智能体还是工作流的四问自测。
handoff 之后还能把控制权交回来吗
可以，给专家智能体也配置一条指回原智能体的 handoff 即可；但不建议频繁来回，循环交接会让轨迹难排查。
交接时对话历史会丢吗
不会，最新对话状态随移交一起传递；SDK 还支持传递结构化元数据或过滤后的历史，具体看所用语言的 API 。
怎么决定第一个接手的智能体
由路由智能体（triage）基于意图分类决定，这也是最常见的入口设计：一个窄职责的分流员加一组专家。
评论 (0)