AI 的长期记忆，不应该是一段越积越长的聊天记录。我的做法是：每次会话结束前，不让 Agent 只留一句“工作总结”，而是把任务压缩成一个 checkpoint 写回 Issue。下一轮先读这个恢复点，再决定是否需要翻旧对话。
这个习惯来自一次筛选器修复。用户报告的动作很具体：在可搜索的下拉框输入关键词，选中某个 setid 后，关键词被清空。
第一轮 AI 找到了一个真实缺陷：不同列的筛选条件会互相冲掉。改动合理，对应测试也能解释这处缺陷，但它没有解决用户报告的动作。如果交接只写“筛选问题已修复”，下一轮就会从已有补丁和绿色测试继续推理，把正确的局部结果误当成任务已经完成。
这不只是措辞差异。两种交接方式会让下一轮从完全不同的位置启动：
| 工作总结式交接 | Checkpoint 式交接 |
|---|---|
| 筛选问题已修复 | 跨列冲突已修复；关键词清空未验证 |
| 测试已通过 | 当前测试仅覆盖跨列冲突 |
| 继续排查 | 重放输入关键词、选择 setid、观察输入框 |
我后来把接力点改成了另一种写法：当前结论明确标注“跨列冲突已修复，关键词清空仍未验证”；已验证证据只列对应测试；未决问题保留用户的原始动作；下一步要求重新执行“输入关键词—选择 setid—观察输入框”。新会话不需要复述上一轮的全部推理，先重放这个动作即可。排查随后回到公共下拉组件，最终确认与 reserveKeyword 的默认行为有关，改动也从页面补丁收敛到了组件工厂。
长期记忆保存的是恢复点
这次经历改变了我对“记忆”的理解。项目知识库回答“系统通常如何工作”，聊天记录保存“当时如何讨论”，checkpoint 则回答“任务停在哪里，下一步凭什么继续”。三者不能互相替代。
对接力最有用的，不是完整保存几万字对话，而是保留最小可恢复状态：已经确认了什么，依据是什么；哪些判断还没有成立；下一步执行哪个动作；最终交付应从哪里追溯。即使上下文全部清零，新的 Agent 也能从同一现场继续，而不是重新猜测上一轮的意图。
交接模板必须暴露认知缺口
交接记录必须允许明确写下“未知”和“暂无”：
Checkpoint｜时间 / 会话<br> 当前结论： 已确认的判断，以及明确尚未成立的判断<br> 已验证证据： 可重复的测试、截图、日志或操作结果<br> 未决问题： 仍无法解释的现象与缺少的证据<br> 下一步： 一个具体动作、作用对象和预期观察结果<br> 交付来源： commit、PR、既有发布记录；尚未交付则写“暂无”
真正关键的是字段之间不能互相冒充。“代码已修改”不能放进已验证证据，“测试通过”必须写清验证了哪个现象，“下一步继续排查”也不够，因为新会话仍要重新决定从哪里开始。
我只在三个节点更新 checkpoint：会话即将结束、关键判断发生变化、任务准备交付。写得太频繁会变成流水账，写得太晚又会丢失现场。打开一个没有旧聊天的新会话，只给它 Issue；如果它能说清当前边界，并执行正确的下一步，这份长期记忆才算有效。
