别再把聊天记录交给下一个 Agent：`handoff` 才是长任务的“工作记忆”

当你开始把 AI 当成能持续推进工作的同事，迟早会遇到一个很不浪漫的问题：任务还没结束，线程已经很长了。

代码读了十几个文件，跑过几轮测试，排除了两条错误路径，某个 PR 也改到一半。此时无论是换一个 agent、隔天再做，还是把工作交回给人，真正麻烦的都不是“没有聊天记录”，而是没人知道哪几条信息还在影响下一步决策。

这也是为什么我会把 handoff 放进 AI 工作流的前十：它解决的不是总结，而是接力。

这里说的 handoff，来自 Matt Pocock 的公开 skills 仓库。它的定义非常克制：把当前对话压缩成一份文档，让另一个 agent 可以继续工作。重点不在于把历史保存得多完整，而在于让新接手者少花时间重建上下文，直接进入可验证的下一步。原始 SKILL.md（真实链接：https://github.com/mattpocock/skills/blob/main/skills/productivity/handoff/SKILL.md）

先划清一个容易混淆的边界：原始 skill 没有规定一套固定的交接目录或九宫格模板。它只定义交接的基本约束；后面的“六个问题”、检查清单和可复制提示词，则是在这些约束上整理出的推荐实践，目的是让真实项目里的交接更容易执行、验证和审阅。

先划清边界：handoff 不是“自动续聊”

AI 工具里叫 handoff 的东西并不都是一回事，混在一起理解，反而容易选错工具。

OpenAI 在 Agent 构建指南中也把 handoff 用于把控制权交给专业 agent，例如从分诊 agent 转给订单管理 agent；这是“运行时路由”。OpenAI 指南（真实链接：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf）
而我们今天说的，是另一件事：当任务还在半路上，如何给下一轮工作交一份“人和 agent 都能读懂”的接班单。

Claude Code 的官方文档把这种需求讲得更直白：新 session 默认是新的上下文窗口；当上下文变长，系统会压缩历史，而早期细节可能丢失。会话与上下文说明（真实链接：https://code.claude.com/docs/en/how-claude-code-works）
所以，handoff 不是和压缩对立，而是给压缩加上人为选择：哪些内容必须留下，不交给模型临场猜。

handoff 的真正价值：把“聊天历史”变成“决策载荷”

聊天记录适合回放过程，不适合启动下一步。它混着试错、重复提问、长日志、被放弃的猜测和已经过期的计划。接手者若从头爬记录，最容易出现两种浪费：要么重新做一遍已排除的排查，要么继承了一条没有证据的旧结论。

一份好的 handoff 做的是反向操作：删掉不再影响行动的过程，把仍会约束行动的信息变成一个短文档，并把细节留在原工件中。

它至少要回答六个问题：

1. 目标是什么，什么算完成？
2. 哪些事实已经确认，证据在哪里？
3. 已经做了哪些改动、运行了哪些验证？
4. 哪些问题还没解，卡在哪里？
5. 哪些风险、权限和边界不能丢？
6. 新 agent 的第一步是什么，最适合调用什么 skill？

这正好对应公开 handoff skill 的几个硬要求：单独写交接文档，并保存到操作系统的临时目录而不是项目工作区；加入 Suggested Skills；已有 specs、计划、ADR、Issue、commit、diff 不要复制，直接引用路径或 URL；并且脱敏 API key、密码和个人信息。skill 原文（真实链接：https://github.com/mattpocock/skills/blob/main/skills/productivity/handoff/SKILL.md）

把这些要求放在一起看，其实只是在做一件事：降低接手成本，同时避免把敏感内容和过期叙事再复制一遍。

它还有一个容易被忽略的元数据：disable-model-invocation: true。这表示它通常不应被模型在普通执行过程中自动触发，而更像一个由用户明确发起的“正式交班动作”。这很合理：什么时候暂停、交给谁、下一轮聚焦什么，往往仍然需要人来决定。

到底怎么用？先记这一件事

如果你的工具已经安装并支持调用这个 skill，最短用法不是复制后面的长提示词，而是直接明确调用 handoff，并告诉它下一轮的工作重点：

/handoff 下一轮继续验证支付 webhook 的幂等逻辑；不要改线上配置。

当前 agent 会依据原始 skill 写出交接文档、保存到系统临时目录，并把文件路径交给你。你把这个文件路径或文档内容交给下一位 agent 即可。

**后面的长提示词不替代官方 handoff skill。**它是一个备用方案：当你的 AI 工具没有安装该 skill、没有 slash command，或者你想手动规定交接格式时，才把它发给“当前正在工作的 agent”，请它按同样的目标产出一份 handoff。它不是发给下一位 agent 的提示词。

为什么现在更需要它：上下文窗口变大，不等于上下文不会变质

很多人会说：模型的上下文已经越来越大，为什么还要专门交接？

因为问题并不只是装不装得下，更是“什么信息还应该占据注意力”。长任务里的工具输出、调试分支和临时想法会持续堆积；即便能够自动压缩，压缩也是有损的，而且模型未必知道你下一步真正准备做什么。

Anthropic 的实践建议很有参考价值：同一任务但上下文仍有价值时，可以继续；会话被过期探索塞满时，可以带重点执行 /compact；真正开始一个新任务，则清空上下文并由人明确决定哪些信息带过去。会话管理实战（真实链接：https://claude.com/blog/using-claude-code-session-management-and-1m-context）

这给 handoff 一个很好的定位：它最适合“任务没有换，但执行者或会话要换”的时刻。

X 上围绕长运行 agent 的讨论也反复提到同一个关键词：context fidelity。通俗说，就是交接后还能不能保住那些真正决定结果的约束、证据与优先级，而不是只保留一个听起来合理的故事。相关讨论（真实链接：https://x.com/systematicls/status/2038241033755168959）

一个贯穿案例：排查做到一半，怎么交给明天的 Agent？

假设今天正在排查“支付成功后订单状态没有更新”。你已经完成了这些工作：

• 用 scripts/repro-payment.ts 稳定复现；
• 确认 webhook 已收到，但消费者没有写入订单；
• 排除了数据库连接和签名校验；
• 怀疑 src/payments/consumer.ts 的幂等判断；
• 还没修，因为需要确认重放事件是否会重复发货。

差的交接是：“支付 bug 已经查到 consumer，明天继续。”

好的交接则会写成：“目标是修复 webhook 成功但订单未更新；复现命令是……；目前 event_id 已入库而订单仍为 pending；证据在日志链接和测试输出；不要修改发货逻辑；下一步先阅读 consumer.ts 第 86–124 行，验证幂等键是否错误地短路了状态更新；建议先用 debugging，修复后再用 test。”

两者的区别不是文字长短，而是后者能让接手者做第一条动作，并且知道如何判断它对不对。

原始规范之外：一份够用的 handoff，我建议再写什么？

下面不是原始 skill 强制的目录，而是我建议的一套增强结构。它把原始规范中的“能接手、能引用、能脱敏”具体化，适用于代码、研究、内容、运营和多 agent 协作。交接件可以控制在“10 分钟可读完”的量级，但结构不要省。

有一个特别实用的判断标准：如果下一位 agent 读完后还要问“从哪个文件、链接或命令开始”，那它不是 handoff，只是摘要。

没有安装 skill 时：用这条提示词手动生成 handoff

这条是推荐提示词，不是仓库原文。把它发送给当前正在工作的 agent，而不是下一位 agent；它的作用是在没有 handoff skill 时，手动生成一份同类的交接文档。若你已安装并能调用官方 skill，优先使用上一节的 /handoff <下一轮重点>，无需复制这段。

把当前任务整理成一份面向下一位 agent 的 handoff。
目标：让对方在 10 分钟内完成上下文接收，并开始第一条可验证的行动。

请按以下顺序输出：
1. 目标与完成标准
2. 当前状态（2–4 句）
3. 已确认事实与对应证据
4. 已完成的改动/验证
5. 未完成事项、阻塞与待验证假设
6. 边界、权限、风险与脱敏提醒
7. 工件入口：引用现有 issue、PR、diff、review、测试结果、日志和代码路径；不要重复抄写
8. Suggested Skills：列出下一位 agent 应调用的 skill、原因与预期产物
9. First Action：只写一条最高优先级、可立即执行的下一步

不要复制 API Key、密码、Cookie、个人信息或完整敏感日志。
如果某条结论没有证据，请标注为“待验证”，不要伪装成事实。

如果你的工具支持传参数，可以补一句下一轮的焦点，例如“下一轮只完成根因验证，不要直接改线上配置”。公开 skill 也明确要求：若用户带了参数，应把它视为下一 session 的重点来定制交接内容。skill 原文（真实链接：https://github.com/mattpocock/skills/blob/main/skills/productivity/handoff/SKILL.md）

最适合放在哪些环节？

不是每轮对话都需要 handoff。它在下面四个节点最值钱：

1. PR 还没 ready。 已经有 Issue、diff、review 和测试线索，但还差一次验证或决策。
2. 排查完成一半。 已建立复现、排除了假设、定位到可疑模块，但还没得到可安全合并的修复。
3. 从 agent 交回人，或从人再交给 agent。 人需要看结论、风险和确认点，而不是工具调用回放。
4. 跨天或跨工作区。 工作本身没变，但你不希望明天先花 20 分钟“恢复记忆”。

反过来说，若任务已经完成，只需要最终交付说明；若任务完全无关，应该开新上下文，而不是勉强续接。handoff 的边界越清楚，文档越短、越可信。

它不是文书工作，而是一个小型控制面

handoff 最容易被误解为“顺手写个总结”。但一份成熟的 handoff，其实在给下一轮工作建立控制面：目标决定方向，证据决定可信度，边界决定权限，工件链接决定可追溯性，第一步决定能否启动。

这也解释了为什么它对多 agent 和跨天协作尤其重要。单轮表现再亮眼，接力时丢了约束、重做了排查、越过了权限，整体效率仍然很差。反过来，一份好交接能把“重建上下文”的二十分钟，压缩成“验证第一步”的两分钟。

真正可持续的 AI 工作流，不是让 agent 记住一切，而是每次行动都留下下一位执行者能接住的边界、来源和入口。handoff 不是让聊天更漂亮；它是在为长期任务建立工作记忆。

如果你要自己检查交接质量，再看这张清单

这不是每天要完成的一串任务，也不是原始 skill 的官方要求。它是一张“验收表”：拿到一份 handoff 后，如果想判断它是否真的能交给下一位 agent，再逐项扫一遍。

不需要背完。只要用一个问题判断即可：“把这份文档交给一个不了解前情的 agent，它能否在不翻聊天记录的情况下，知道从哪里开始、什么不能做、如何验证？” 如果答案是否定的，再回来看下面缺了哪项。

参考资料

• Matt Pocock Skills：handoff / SKILL.md（真实链接：https://github.com/mattpocock/skills/blob/main/skills/productivity/handoff/SKILL.md）
• GitHub：mattpocock/skills · Productivity README（真实链接：https://github.com/mattpocock/skills/blob/main/skills/productivity/README.md）
• OpenAI：A practical guide to building agents（真实链接：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf）
• Anthropic：How Claude Code works（真实链接：https://code.claude.com/docs/en/how-claude-code-works）
• Anthropic：Explore the context window（真实链接：https://code.claude.com/docs/en/context-window）
• Anthropic：Using Claude Code: session management and 1M context（真实链接：https://claude.com/blog/using-claude-code-session-management-and-1m-context）
• X：关于长运行 Agent 与 context fidelity 的讨论（真实链接：https://x.com/systematicls/status/2038241033755168959）