Handoff 常被翻译成“交接”或“移交”。在多 Agent 系统里，它指当前 Agent 完成自己负责的阶段后，把任务交给更适合处理下一步的 Agent，并把继续工作所需的信息一并带过去。接手者成为新的任务负责人，前一个 Agent 不再同时推进同一份任务。
因此，一次真正完整的 Handoff 至少包含三件事：任务移交、必要上下文移交、控制权移交。只调用另一个 Agent、只复制对话、或只在聊天记录里写一句“请继续处理”，都不能自动保证这三件事发生。
不过，Handoff 不是每段 AI 对话都必须有的机制。用户问一个简单问题、一个 Agent 调用一个工具就能完成时，直接回答或工具调用通常更简单。只有任务跨越不同专业职责、权限边界或处理阶段，且确实需要换负责人时，Handoff 才有价值。
为什么多 Agent 对话会需要 Handoff
一个 Agent 包办所有事情，边界会变得模糊
拿景区退款举例。游客说：“票买了但没用，想退款。”系统要识别诉求、查询订单、确认支付与核销状态、检查风险、计算退款金额，最后可能还要申请审批并执行退款。
如果一个 Agent 做完所有步骤，它不仅要理解用户，还要知道订单、风控、票务、退款和审批规则，并持有相应工具。工具越来越多，模型每次都要判断该调用哪个；提示词和上下文也越来越重。更麻烦的是，查询订单、判断风险和执行退款的权限不同，放在一个 Agent 上容易让职责和安全边界缠在一起。
交给一个总控 Agent，也有成本
另一种做法是让 Supervisor 每次决定下一步：客服处理后回报 Supervisor，再由它派给订单 Agent；订单查完再回报，Supervisor 再决定是否交给风控。这样集中调度，流程更容易观察和控制，但每一步路由都压在总控上。业务越多、分支越多，总控越容易成为又重又难维护的决策中心。
Handoff 可以让熟悉当前业务阶段的 Agent 直接把任务交给下一位专业 Agent。例如客服判断出这是退款并收齐订单号后，直接交订单 Agent；订单核验完成，再交风控 Agent。这样少一层重复路由，也保留了按结果选择下一步的空间。
Handoff 是责任转移，不等于“多找一个模型帮忙”
多 Agent 对话里最容易混淆的是“调用”与“交接”。工具调用通常是当前 Agent 发出一个请求，拿回结果后仍由它继续负责。Handoff 则把任务当前负责人换成另一个 Agent。两者的状态变化不同。
| 动作 | 发起后谁仍负责任务 | 典型例子 |
|---|---|---|
| 工具调用 | 当前 Agent | 客服 Agent 查询订单接口，拿回订单状态后继续判断 |
| Handoff | 目标 Agent | 客服 Agent 完成信息收集，把退款任务交给订单 Agent |
| 并行委派 | 通常仍由协调者负责汇总 | 多个 Agent 同时调查客流、天气和支付数据 |
Handoff 也不天然代表去中心化。如果每次目标 Agent 都由 Supervisor 决定，整个系统仍是中心调度，只是交接消息采用了 Handoff 的形式。视频重点讨论的是 Agent 之间可以直接交接的 peer-to-peer 路径。
用退款流程看任务如何流动
先把用户请求转成一项可追踪的业务任务，而不只是留在聊天记录里。系统可以创建 task_id，记录这是一个退款申请；session_id 只说明它来自哪次对话。一段对话里可能有多个订单、多个请求，任务 ID 和会话 ID 分开后，才知道审计或恢复时要追踪哪一件事。
客服 Agent 负责识别退款意图、记录游客诉求、收集订单号。没有订单号时先向用户追问，满足最低交接条件后才交给订单 Agent。订单 Agent 查询权威订单系统，核实订单归属、支付状态、核销状态和重复退款情况。通过基础校验后，把查到的事实和证据交给风控 Agent。
风控 Agent 检查退款频率、账号标签、设备异常或重复申请。风险较低时交给退款 Agent；命中规则时转人工审批。退款 Agent 根据票种和规则计算金额、手续费和退款方式，但最终执行仍要通过后端的权限和业务校验。处理完成后，系统通知用户；如果进入审批，就由人工完成决策，再把任务交回系统。
这不是一条必须写死的 A 到 B 到 C 流程。大方向可以明确，具体路线根据订单状态、风控结果和审批条件分支。每次交接都应由当前 Agent 完成职责后触发，而不是因为“还有另一个 Agent”就随意转交。
一份交接包应包含什么
交接包的目标是让接手者知道：这是哪项任务、为什么交给我、我应该做什么、哪些信息已经确认、哪些内容仍不确定。字段可以按业务需要调整，以下是一种参考结构：
{
"task_id": "refund-20260831-001",
"session_id": "session-abc123",
"handoff_id": "handoff-002",
"trace_id": "trace-xyz789",
"schema_version": "1.0",
"from_agent": "customer_service",
"to_agent": "order_verification",
"current_owner": "order_verification",
"handoff_reason": "已确认退款诉求，需要核验订单状态",
"objective": "核实订单是否属于该用户、是否支付、是否核销",
"business_context": {
"intent": "refund_request",
"order_id": "A20260831",
"user_request": "订单已支付但尚未消费，希望退款"
},
"known_facts": [],
"evidence_refs": ["order-service-query-789"],
"risk_flags": [],
"open_questions": ["订单当前状态是否满足退款审核条件"],
"constraints": ["只查询，不执行退款"],
"deadline": "2026-10-08T16:30:00+08:00"
}
这里的字段不是通用标准，关键是定义稳定的“上下文契约”。例如：
- 任务身份与路由：
task_id、session_id、handoff_id、from_agent、to_agent、当前负责人和交接原因。 - 处理目标：这次要回答的问题、允许执行的动作，以及不能做的事。订单 Agent 可能只需核验，不能退款。
- 业务上下文：用户意图、订单号和简要诉求，不需要把几十轮聊天全部复制过去。
- 事实与证据：把“用户声称已付款”和“订单系统返回已付款”分开记录；尽量带来源或查询结果引用。
- 风险与未决问题：有哪些风险标记，哪项信息仍待核实，下一位 Agent 应先解决什么。
- 追踪和时限：
trace_id、交接包版本、截止时间和幂等标识，帮助串起链路并处理超时或重复请求。
信息应“最小但充分”。上下文太少，接手者会重复问用户或漏掉限制；上下文太多，关键事实会被淹没，还会增加成本和数据暴露面。原始业务数据很大时，交接包传引用，下游按权限读取即可。
不要在交接包里传密码、数据库凭证或服务令牌。Agent 有什么权限，应由系统自己的授权配置决定。上游 Agent 有权限，不代表下游也应获得同样权限。
交接前要有门槛，交接后要确认结果
视频把交接前的检查称为 handoff guard。它可以检查几件事：当前 Agent 是否完成职责；目标 Agent 是否确实需要介入；关键字段是否齐全；路由是否符合业务规则；任务是否已取消、已完成或已经转给别人。
例如客服还没有拿到订单号，guard 应阻止任务进入订单核验。退款金额超过某个阈值时，规则应要求进入审批，而不能让模型自由选择自动退款。通用问题可以由模型根据 Agent 能力描述选择目标；退款、支付和审批等高风险路径则应由明确规则约束。两种办法可以组合使用。
交接发出后，还需要明确接收状态。目标 Agent 是否成功接收？任务负责人是否已经切换？交接消息是否重复？如果调用超时，系统要能判断“对方没收到”还是“对方处理了但回执丢了”。这也是 handoff_id 和幂等处理有用的原因。
进一步的工程建议是把“写入交接事件、切换任务负责人、投递交接消息”设计成可恢复的操作。否则可能出现负责人已切换、消息却没发出去，或消息发出、旧负责人仍能写入的半完成状态。可以通过事务性事件或 Outbox 一类机制协调状态更新和消息投递；采用哪种方式取决于系统架构，但要能恢复和去重。
所有权、状态机和并发控制
一个任务在同一时刻应只有一个 Agent 负责推进状态。系统可在任务记录里保存 current_owner 和 owner_version。比如订单 Agent 持有版本 7，交接给风控时负责人更新为风控、版本变为 8。订单 Agent 若拿着版本 7 的旧请求回来更新任务，系统就拒绝过期写入。
这可以用乐观锁、状态版本或其他并发控制实现。它解决的是“谁有权写当前状态”，不代表其他 Agent 完全不能读取所需信息。
复杂任务还适合用明确状态表达生命周期，例如：
created → assigned → active → handed_off → active
↘ awaiting_human → active
↘ completed
↘ failed / cancelled
状态名称可以因系统而异，但要规定谁能触发每种转换。completed 任务不能被旧 Agent 重新打开；cancelled 任务不能继续执行退款；等待人工审批时，自动 Agent 不应偷偷越过审批继续操作。
防止踢皮球、无限重试和重复副作用
如果客服把任务交给订单 Agent，订单 Agent 又把它退回客服，补完后再交回来，系统可能一直循环。可以设置最大交接次数 max_hops，但具体上限要按流程长度决定。还要记录交接路径；重复的 Agent 序列或重复退回同一原因时，触发环路保护，转异常队列或人工处理。
每个阶段应有截止时间或 SLA。订单服务超时，可以有限次重试；服务持续不可用时，告知用户状态暂时无法确认，再转人工或异常队列。重试要有上限、退避策略和可观察的失败原因，不能让任务无期限挂起。
退款、支付、库存扣减都可能产生不可逆或重复的副作用。系统应为业务动作设置幂等键，后端在执行前重新检查订单最新状态和权限。Agent 的重试不能变成两次退款。对于状态不确定的请求，应先查执行结果，再决定是否重试，不能仅凭“没收到响应”就再发一次。
如果超时或无法路由时交给 Supervisor 兜底，这不代表正常流程也必须改成 Supervisor 模式。Supervisor 可以只处理异常出口；人工审批也可以是正式链路节点。
安全边界不能随着任务一起漂移
Handoff 转移的是任务控制权和必要上下文，不是上游 Agent 的全部能力。客服 Agent 可以收集诉求，订单 Agent 可以查询订单，退款 Agent 才可能调用退款执行能力。高风险操作还需审批或额外授权。
业务数据应以权威系统为准。上游传来的结论如果会影响退款，接手 Agent 应按需重新查验，或验证附带的证据引用。对外部网页、用户输入、工具返回内容也要保留来源边界：这些内容可以提供事实，但不应自动获得修改系统规则、越权调用工具或改变任务权限的资格。
还要控制传递的数据范围。任务只需要订单状态，就不应把不相关的个人资料带到下游。多租户场景中，查询和交接都必须沿用当前租户与用户的授权范围，避免“换了 Agent 就丢了访问控制”。
用户看到的应该是一件连续的事
内部发生多次 Handoff，不代表用户需要面对多个机器人轮番自我介绍。系统最好指定一个对话出口，由它负责把内部结果转成一致的用户回复。处理中可以简短说明正在核验或等待审批；任务切换时保存用户已提供的信息，避免反复索要订单号和退款理由。
遇到耗时任务，还要处理用户中途补充信息、撤销申请或开启新请求的情况。新信息要关联到正确的 task_id：它可能更新当前任务，也可能创建新任务。用户取消后，待执行的 Agent 和工具调用都应检查取消状态，特别是尚未发生的退款操作。
因此，“Agent 对话要有 Handoff”并不是普遍要求。真正需要的是让多阶段任务在内部交接时，对用户仍保持连贯、可解释、可中断。简单对话不必为了架构整齐而拆 Agent。
记录什么，才能知道 Handoff 有没有用
每次交接至少记录任务 ID、发起方、接收方、交接原因、时间、交接结果、处理耗时和 Trace ID。需要审计时，可保存交接包快照或哈希，并记录哪个版本的规则做了路由决定。日志里不要因为方便而保留不必要的敏感数据。
除单次日志外，还可以观察几项系统指标：交接成功率、每个 Agent 的超时率、平均交接次数、重复退回率、环路触发率、人工接管比例、重试后重复执行拦截数，以及用户被重复追问的比例。若任务经常在两个 Agent 间往返，问题可能是职责边界不清或交接字段不足；若人工接管很多，也要判断是规则过严、信息不足，还是某个 Agent 的能力不够。
什么时候选 Handoff，什么时候换方法
适合 Handoff 的任务通常有明确分工，阶段之间存在先后依赖，但下一步仍可能根据结果分叉。客服、订单、风控、退款这样的业务链就是典型例子。售后转技术支持、工单分级和审批流程也可能适用。
如果流程完全固定，每一步都不需要 Agent 决定下一站，普通工作流可能更简单。如果问题需要多个 Agent 同时探索、相互共享中间发现，例如分析收入下滑的原因，Blackboard 更合适。如果系统必须由中心统一掌握每次路由，Supervisor 更合适。它们不是等级关系，按任务结构选择即可，也可以组合。
一个实用的起步方法是先画出任务状态和职责边界，再列清每个 Handoff 的触发条件、交接字段、权限范围和失败出口。先把正常路径做成少数几次可解释的交接，记录真实运行情况；确认职责划分稳定后，再增加模型动态选路。不要一开始就让每个 Agent 可以自由地交给任何其他 Agent。
上线前的检查问题
- 当前任务由谁负责？交接完成后旧负责人还能否写状态？
- 每次交接的业务目的和完成条件是否明确？
- 目标 Agent 拿到的信息够不够用？哪些事实要重新向权威系统核实？
- 交接是否带了不必要的个人数据、凭证或权限？
- 同一任务重复提交、消息超时、回执丢失时，系统如何去重和恢复？
- 是否有最大交接次数、路径检测、阶段超时、重试上限和人工出口？
- 退款等副作用操作是否由后端最终校验并支持幂等？
- 用户中途补充或取消时，任务如何更新？
- 发生错误后，能否根据事件记录还原谁在什么依据下做了什么？
- 如果流程根本不需要动态分工，是否可以用更简单的工作流或单 Agent？
最后把它说清楚
Handoff 解决的是多阶段业务里的责任交接：当前 Agent 做完自己这一段后，把可追踪的任务和必要信息交给下一位负责人。它能让专业分工更清楚，也能减少总控节点的重复路由；代价是状态、上下文、权限、重试和异常恢复都需要认真设计。
所以判断一个 Handoff 系统是否成熟，不看 Agent 之间能不能互相调用，而看任务能否明确交接、唯一推进、失败后恢复，并且在每个关键步骤上都能说明“谁做了什么、依据是什么、下一步由谁负责”。
- 作者：赵聪（ZhaoCong），产品经理与独立开发者。