让Codex任务不断档的方法，未完成的任务写handoff，接手任务前先读handoff

很多人以为Agent 任务中断损失的只是几分钟。不是。真正丢掉的是已经建立起来的上下文查过哪些文件、排除了哪些可能、为什么选了这个方案、哪一条路已经试过且确定走不通。一个没有交接记录的未完成任务表面上只是“暂停”。对下一个接手的 Agent 来说它其实是一个信息不完整的新任务。于是新的 Agent 重新浏览目录重新读代码重新运行命令重新踩一次已经踩过的坑。看起来很勤奋实际上只是在重复消耗。所以先把一个概念弄清楚。Handoff 不是工作日报。Handoff 是让下一位执行者恢复工作状态的说明书。日报强调“我做了什么”。Handoff 强调“你现在该怎么接着做并且为什么”。这两者差别很大。为什么要写 Handoff你可以把一个复杂任务想成修一辆拆开的车。发动机罩已经打开零件摆在地上某个螺丝刚刚确认不匹配替代零件已经订好了但还没送到。这时换一个人来修如果没有说明他会做什么他大概率先把已经拆过的部分重新检查一遍。Agent 也是一样。它并不天然拥有上一个 Agent 的工作记忆。即使代码和文件还在决策过程、失败尝试和当前意图也未必在。而这些东西往往比最终改动更值钱。例如“已经把超时问题定位到第三方接口但不要盲目增加重试次数因为接口会对重复请求扣费”这句话的价值远高于一句“正在修超时”。前者能让接手者立刻避开错误方向后者几乎等于没有信息。写 Handoff 的本质是把原本只存在于执行者脑中的临时信息变成团队可以复用的外部信息。把记忆写下来任务才不依赖某一个 Agent。它到底用在什么场景凡是任务会中断、会切换执行者、或未来可能重启的地方都该写。最常见的场景是任务还没完成但时间、上下文窗口或可用资源已经不够。此时最差的做法是匆忙留一句“后续继续”。“继续”不是下一步。下一步应该像这样先运行哪条命令查看哪个文件预期看到什么结果若结果 A 出现进入哪条路径若结果 B 出现停止并检查什么。第二类场景是多人或多 Agent 接力。有人负责定位问题有人负责实现有人负责测试。没有 Handoff交接就会变成口头猜谜。第三类场景是等待外部条件。比如等待用户提供密钥、等待审批、等待接口恢复、等待产品确认方案。任务并没有消失只是暂时不能推进。第四类场景是你自己稍后回来继续做。不要高估未来自己的记忆。你过几个小时再看同一堆文件也很可能忘了当时为什么没选那个“看起来更简单”的方案。你看Handoff 并不是大型项目才配拥有的仪式。只要一次重复排查的成本高于写几分钟文档的成本就应该写。写了以后得到的到底是什么最直接的收益是减少重复劳动。接手者不必从目录结构和提交记录里考古。他可以从已知事实出发继续验证尚未验证的部分。更重要的收益是降低决策质量的波动。没有 Handoff 时接手者常常会把“尚未完成”误解为“尚未开始”把“已经被否定的方案”再做一遍。结果是进度看似在动实际在原地打转。还有一个经常被忽略的收益它会迫使当前执行者把思路说清楚。你一旦试着写下“卡在哪里”就会发现有些所谓的阻塞实际上只是下一步没有被拆到足够小。你一旦试着写下“哪些坑不要再踩”就会发现自己刚才的尝试是否真的得出了结论。所以Handoff 同时服务两个人未来的接手者和现在正在思考的你。清晰的交接会让中断变成暂停模糊的交接会让暂停变成重启。一个真正能用的 Handoff 指令模板你不需要让 Agent 写一篇漂亮的总结。你需要让它留下下一位执行者能用的操作说明。把下面这段指令直接交给未完成任务的 Agent当前任务尚未完成。请在停止、等待或交接任务前在项目根目录下创建或更新 HANDOFF.md确保下一位 Agent 可以不重复排查、直接继续工作。文档必须基于最新工作状态准确、简洁、可操作并且必须包含以下五部分1. 现在正在做什么 说明当前所在步骤、正在修改或检查的文件、当前进展以及为什么在做这件事。2. 已经完成了什么 列出已完成的改动、产出和验证结果写明相关文件路径、关键实现和已执行命令。3. 卡在了哪里 说明当前阻塞点、报错或不确定事项记录已尝试的方法、得到的结果以及继续推进所需的条件。4. 下一步做什么 按优先级给出可直接执行的具体步骤。不要写“继续完成任务”应写明目标文件、操作方式或命令以及预期结果。5. 哪些坑不要再踩了 记录已经验证无效、容易造成问题或容易误判的做法说明原因并给出推荐替代方案避免后续 Agent 重复踩坑。要求 - 具体引用文件路径、命令、报错和关键上下文。 - 不要猜测不要复制过期信息。 - 保留关键设计决策、约束和风险。这个模板的重点不在于文件名必须叫HANDOFF.md。重点在于它强迫 Agent 回答五个问题现在在哪儿、已经走过哪儿、为什么走不动、接下来往哪儿走、哪些路已经证实不该再走。只要这五件事清楚换谁接手都不会从零开始。接手任务前先读 Handoff还有半件事同样重要。既然前一个 Agent 已经把上下文写进了 Handoff后一个 Agent 的第一步就不该是立刻改代码而应该是先读它。这不是形式主义。你先读 Handoff才能知道哪些结论已经验证哪些改动还没完成哪些风险不能碰。然后再用当前工作区和运行结果去核验其中最关键的事实。顺序应该很简单先读 Handoff了解现状然后向我汇报你了解的现在情况。读文档是为了获得方向向我汇报是为了确保它理解的是正确的等确定没有问题动手是最后一步。很多返工并不是能力不够而是顺序错了。一上来就动手等于主动丢弃已经存在的信息。最后说一句所谓任务不断档不是让 Agent 永远不停止。停止是正常的。上下文有限、任务会切换、外部条件会变化这些都正常。真正不正常的是每一次停止都让下一个执行者重新理解一遍世界。把 Handoff 写好把“先读 Handoff”变成接手任务的默认动作。你得到的不是一份文档而是一套可以不断衔接、不断积累的工作机制。说白了就是别让已经付出的思考在一次交接之后归零。《教程全集知识库》首发阿一AI站