很多团队谈多 agent 协作时，最先想到的是“一个 agent 规划，另一个 agent 执行”。真正到了工程现场，问题往往不在分工，而在移交。前一个执行者到底要交什么？是完整聊天记录，还是摘要？权限要不要一起转？外部副作用的责任算谁的？
如果这些问题没有被写成 contract，多 agent 协作和人工接管最后都会退化成“把一坨上下文丢给下一个执行者”。这不叫 handoff，只叫复制粘贴。
建议先结合 多 Agent 协作架构设计、AI agent Prompt Contract 设计、AI agent Artifact 设计 和 AI agent 人工审批控制台设计 一起看。
先给结论：handoff 最少要移交 4 类东西
| 类别 | 为什么必须移交 |
|---|---|
| 目标与当前状态 | 下一个执行者要知道任务停在哪里 |
| 可复用上下文 | 避免重新读全部历史 |
| 权限与可执行动作 | 避免接手后越权或失能 |
| 未完成风险与副作用 | 避免重复写入或误继续 |
如果缺任意一类，handoff 之后的执行者都只能靠猜。
一、Handoff 不是历史 transcript，而是一份可执行 envelope
更稳的做法是把 handoff 写成结构化 envelope：
{
"runId": "run_123",
"handoffFrom": "planner_agent",
"handoffTo": "review_agent",
"currentState": "waiting_review",
"goal": "validate external send draft",
"artifactRefs": ["draft_004", "evidence_011"],
"allowedActions": ["approve", "reject", "edit_and_resume"],
"openRisks": ["external_send_high_impact"]
}
这份 envelope 的意义是让下一个执行者立刻知道：现在是什么任务、能做什么、不能做什么。
如果要让 handoff 真正跨系统稳定工作，这份 packet 最好还带上版本和接手语义：
{
"handoffVersion": "v3",
"authoritySnapshot": "policy_bundle_12",
"resumePolicy": "resume_from_checkpoint_only",
"ackRequiredBefore": "2026-05-10T10:05:00Z"
}
这样接手方看到的就不只是内容摘要，而是一份带权限快照、恢复边界和接手时限的正式合同。
二、上下文转移要先裁剪，不要把整段历史全量塞过去
真实系统里，handoff 最大的问题之一就是上下文臃肿。更健康的转移通常会把上下文拆成三类：
- 必须带：目标、当前状态、关键 artifact、开放风险
- 可选带：相关历史摘要、最近几步决策理由
- 不应该带：无关对话、过期草稿、冗余 trace
这不仅是节省 token，更是在控制下一个执行者的注意力。
三、authority transfer 必须显式，不要默认“接手者全都能做”
handoff 之后最危险的情况，是新执行者看到了信息，却不知道自己是否真的有权继续某些动作。更稳的设计是把 authority 也写进 contract：
| 权限类型 | 示例 |
|---|---|
| 只读权限 | 查看 artifact、查看 evidence |
| 决策权限 | approve / reject |
| 执行权限 | 允许触发写入或外发 |
| 复用权限 | 允许修改已有 draft |
如果 authority 不显式存在，多 agent 协作很容易在边界处越权。
除此之外，handoff 最好还要求接手方显式 ack，而不是默认“收到了就算接手”。一个最小接手检查表通常包括：
| 检查项 | 为什么重要 |
|---|---|
| context complete | 防止关键 artifact 没带上 |
| authority still valid | 防止权限快照已过期 |
| side effects frozen | 防止旧执行链还在继续写入 |
| resume policy understood | 防止接手后从错误位置恢复 |
这一步看起来多了一层确认，但它能显著减少“handoff 已经发出，实际上没人真正接住”的空转。
四、人工 handoff 和 agent handoff 的差异要提前定义
看起来都是“移交任务”，但两者需求不同：
- agent -> agent 更强调结构化上下文与 machine-readable contract
- agent -> human 更强调证据摘要、风险解释和可选动作
- human -> agent 更强调修改结果和恢复点
所以 handoff contract 可以共用底层字段，但呈现形式通常不能完全一样。
五、handoff 后的责任边界也要记账
一旦接手者做了继续执行、修改或批准动作，系统应该能回答：
- 这是哪次 handoff 之后发生的
- 当前结果属于哪位执行者的责任范围
- 中间是否发生过人工覆盖或权限升级
这也是为什么 AI agent Run Ledger 审计模型 里最好保留 handoff 事实，而不只是最终结果。
六、上线后要看 handoff 质量，而不是只看 handoff 次数
建议至少记录：
| 指标 | 用途 |
|---|---|
| handoff completion rate | 看移交后能否顺利继续 |
| post-handoff clarification ratio | 看接手者是否还要频繁追问 |
| handoff accept latency | 看 packet 发出后多久被真正接手 |
| handoff packet size vs acceptance | 看上下文裁剪是否合理 |
| resume packet completeness rate | 看 handoff 信息是否经常缺字段 |
| authority mismatch incidents | 看权限边界是否清楚 |
如果 handoff 次数很多，但 clarification ratio 也很高，说明系统只是在频繁移交，不是在有效协作。
七、失败案例：Planner 把整段历史丢给 Reviewer，人工仍然看不懂该审什么
某个采购审批 agent 把 40 多轮历史记录原样交给 review agent，再由 review agent 把相同文本显示给人工。结果人工审批者仍然要花很长时间判断“到底要我做什么”。
修复后，团队把 handoff 改成“目标 + 当前状态 + 关键 evidence + 可选动作 + 风险摘要”的 packet，人工审批时间明显缩短，误操作也下降。
八、Handoff Contract Checklist
- handoff 是否被定义为结构化 envelope，而不是转发聊天记录
- 是否区分必须带、可选带和不该带的上下文
- authority transfer 是否显式记录可执行动作
- handoffVersion、authoritySnapshot 和 resumePolicy 是否进入 packet
- 是否区分 agent -> agent、agent -> human、human -> agent 三类 handoff
- 是否要求接手方显式 ack，而不是默认接手成功
- handoff 事实是否进入 ledger 和 trace
- 是否监控 clarification ratio 和 authority mismatch
- 接手者是否能从 contract 直接开始下一步，而不是重新猜任务
结语
AI agent 的 handoff 不该是“把上下文往后传”，而是把目标、状态、权限、风险和可复用产物一起封装成可执行 contract。只有这样，多 agent 协作和人工接管才不会把系统复杂度转嫁给下一个执行者。
延伸阅读：
