AI Harness如何断点续跑？

任务做到一半断了，下次从哪里继续？关键不在于让模型记住所有聊天，而在于让下一次运行知道：目标是什么、哪些事确实做完、还有哪些状态需要核实。AI Harness把这些信息与工具、文件和执行流程连接起来，为续跑提供依据，但不会自动消除所有故障。

01 记忆分层

第一层是当前上下文，相当于工作台：放眼前任务、约束和必要材料。它的容量有限，也可能随会话结束而不可用，因此不适合充当唯一的任务账本。

第二层是持久状态，相当于交接单：把目标、已完成项、待办和阻塞写入可再次读取的文件或数据库。第三层是外部证据，例如实际文件、测试结果和平台回执，用来核对交接单是否可信。聊天里一句“已经完成”只是线索，不能代替产物与验证。

恢复时不必把历史对话全部塞回模型，而应按当前步骤取回必要信息。持久记录负责指路，外部证据负责核验，当前上下文负责支持眼前判断；三者分开，才能减少旧信息和无关内容的干扰。

02 保存检查点

检查点是一个可以核对的进度截面，不是随手记下的愿望。完成一个小步骤后，先检查结果，再记录任务ID、已完成项、产物位置、验证结果和下一步；随后再推进下一段。

例如修改代码后，应保存改动并记录实际运行过的测试，而不是把“准备测试”写成“测试通过”。检查点还应指向对应版本，避免记录说的是旧文件，恢复时读到的却是新文件。每次只推进可验证的小步，出了问题才容易定位回退范围。

写日志本身不能保证原子性或零丢失：产物可能已写入，记录却没来得及更新。反过来，记录也可能存在，但产物缺失或验证已经失效，所以要找最近有效的检查点，而非只看时间最新的一条。

03 恢复先核验

恢复顺序是读取记录、检查实际环境，再确认上次动作是否生效。确认已完成就跳过；确认未完成且可安全重试，就设定次数或时间上限；状态不明，尤其涉及发布、付款等外部影响时，应暂停并请人确认。

以公众号草稿为例，创建请求网络超时，不等于创建失败。应先查草稿箱或平台回执，确认是否已有对应草稿，避免重复创建；草稿保存成功，也不代表已经正式群发。

不同任务要找不同证据：编程看测试与提交，资料研究看来源与摘录，内容制作看图文与草稿回执。落地清单可以很短：拆小步、存状态、留证据、先核验、限重试。试着给你手头的一项任务写张交接单：换一个会话接手，它能知道下一步做什么吗？
Harness

#AI Harness #上下文管理 #检查点恢复 #AI工程 #AI