让长程 Agent 接续任务：文件化上下文的设计记录

长程任务里让我在意的一件事，是工作做到一半以后还能不能接得上。

前面确认了哪些约束，哪个方案已经失败，最近一次检查发现了什么，这些信息散在对话里时，重新进入任务并不轻松。即使保留了很多历史记录，也仍然需要找出与当前步骤有关的部分。

Planning-with-Files 给我的启发，是把任务状态写到文件里。这篇先整理这种做法的设计，以及我希望怎样验证它。它不提供完成率或 Token 节省数据，也不把文件存在本身当成恢复可靠的证明。

先保存继续工作需要知道的事

我会把任务信息分开记录，让每份文件回答一个相对明确的问题。

这些文件名只是这篇记录采用的约定，不是工具必须遵守的接口。小任务也不必拆成四份。如果记录的维护成本已经超过任务本身，就该减少它们。

我更关心记录是否足以支持下一步。例如，“构建有问题”几乎没有帮助；记录检查命令、失败位置和日志所在文件，才能让下一次调查从已有证据出发。

进展记录需要区分尝试和验证

“已经改了代码”和“已经通过检查”是两件事。若进度文件把它们合成一句“完成”，恢复任务时就容易跳过必要的验证。

下面是一个用于说明记录格式的假设示例，不是某次实际运行日志：

目标：修改文章列表的排序规则。
已做：调整排序逻辑，尚未验证构建结果。
下一步：运行构建，检查同日期文章的顺序是否稳定。
约束：不得把草稿加入公开列表。
完成依据：构建结果和排序检查记录。

这样的记录仍然可能过时。下一次接续时，应当同时看实际文件与差异，确认进度描述和工作区一致。若二者冲突，需要先查清原因，再修订记录。

保存完整信息，按需读取

文件多起来以后，新的问题是每一步究竟该读哪些。

修复一个构建错误，通常先需要任务约束、最近一次错误与相关代码。重新规划时，才可能需要回顾更多发现。把所有文件反复读入上下文，既费力，也没有利用分类存储的意义。

因此，我会在短记录里留下指向详细材料的路径。这个路径还应说明材料用于什么判断。只有一个孤立文件名，接手者仍然不知道为什么要读它。

自动选择材料的 Hook 是可以继续探索的一层。但在接入自动化之前，应当先验证人工按这套记录接续是否顺畅。否则 Hook 只是更快地加载一份不清楚的任务状态。

恢复后不一定马上继续执行

我设想的接续顺序是：读取目标和进展，核对工作区，找到相关证据，再决定下一步。

如果记录说某个文件已经修改，而工作区里没有对应变化，就不该直接照着计划往下走。可能是修改没有保存，也可能是记录属于另一个版本。如果证据缺失，记录里应该保留这个缺口，而不是补出一个看似完整的结论。

还有一些信息不适合写进长期记录：已经失效的猜测、没有用途的大段日志、未经确认的完成声明。保留指针与必要上下文就够了；记录本身也需要清理。

下一次怎样验证

我希望用一个范围可控的任务检查这套方法。先记录初始版本、工具环境与验收条件，在任务中途暂停，再从保存的文件接续。

重点观察：

• 是否能准确找回下一步，而不重复已经完成的调查。
• 是否会遗漏原有约束，尤其是已经否决的方案。
• 进展文件与实际工作区是否一致。
• 最后是否有可检查的完成依据。

若要比较效果，还需要在相近条件下对照仅保留对话与使用文件记录的情况，并说明任务差异及重复次数。一次顺利接续不足以说明这种方法普遍有效。

对我来说，文件化上下文值得探索的地方，是它让“任务现在是什么状态”变得可读、可检查。至于它能在多大程度上改善长程执行，还需要用具体的接续记录来回答。