Agent 需要的不是越来越长的上下文，而是可恢复的状态

把 AI 用在持续几天、几周的项目里以后，我更在意一个问题：新会话打开时，它能不能知道现在真正处于什么状态？把整段历史重新塞进上下文，确实能带回很多文字，但也会带回旧假设、已经失效的决定，以及当时还没验证的解释。

我现在倾向于把“记得所有过程”换成“能恢复当前工作”。这篇讨论的是项目状态怎么帮助下一次判断，不是上下文长度的性能比较。我没有做过长历史和精简状态的严格对照，也不会据此断言短上下文一定更好。

历史完整，仍然可能恢复错位置

服务器维护里有一个很直观的例子：某次记录显示主机还没有正式应用，后续则已经部署了第一个服务。两份记录都真实。新会话如果只读到旧段落，可能继续把生产服务当成未来计划；若把新记录里的健康状态当成永久事实，也可能忽略之后的变化。

DNS 的经历更明显：先有成功解析，后来权威记录缺失，再后来恢复。不能把三次观察平均成一个模糊结论。需要知道哪条记录对应哪个时间，哪项判断被后续观察推翻，而涉及此刻的行动是否还要重新查询。

这让我意识到，恢复工作需要的是信息之间的关系。过去知道什么、现在相信什么、凭什么改变、下一步哪个未知最影响决定，不能只靠它们在聊天里的出现顺序来表达。

Mission 保存想达到的结果和边界；Belief 保存当前判断及信心；Unknown 保存会影响选择的未解问题；Evidence 连接实际观察；Decision 保存已经选择的做法和理由；Next Best Action 说明目前最值得做的一步。它们共同回答“为什么现在该做这件事”。

例如“两个域名能正常访问”是一项有时间范围的观察，不应只记成永远有效的结论。若新的权威查询与它冲突，就要调整当前信念。原来的记录不必删除，因为它能解释这次判断为什么发生变化。

Unknown 也不等于待办清单。“需要换一句摘要”是明确工作；“独立备份放在哪里才能覆盖双端丢失”则涉及恢复策略。把两者混在一起，容易让一堆小任务遮住真正影响风险的未知。

codex-auto 当前的恢复原则，是先看仓库实际行为，再看仍适用的证据，然后才看保存状态和旧对话。状态负责帮助定位，不负责宣布真相。若文件或运行结果与状态不同，应当修正记忆，而不是让现实服从记忆。

这意味着恢复并不只是一句“读取状态后继续”。还要检查 Git、相关文件以及当前要行动的运行边界。一次旧测试通过，只证明当时的版本；工作树已经变化时，不能把旧提交的绿色结果贴到新内容上。

我也不希望把失败压成一个永久阻挡。曾经缺少的外部配置可能已经补齐；曾经有效的授权可能已经结束。恢复时要检查具体条件，不能因为历史里出现过一次“可以执行”，就认定同类动作从此都可以自动执行。

如果每次执行都复制一份长总结，记忆迟早会变成另一个庞大的聊天记录。普通命令输出、临时思路和很容易从代码重建的事实，不一定值得长期保存。反而是失败假设、已排除的解释、重要决定及重审条件，更可能避免未来重走同一条路。

“当前重点”我尽量只保留一个。它不是拒绝多个工作项，而是让新会话先看到最影响目标的缺口。下一步也应该带理由，否则一旦环境变化，Agent 只看见一个动作，无法判断还应不应该照做。

这有维护成本。状态越多，越可能过期；记录越详细，越容易出现重复权威。因此证据留在相应记录里，活动状态保持短。发现矛盾时修订相关判断，保留有解释价值的历史，而非无限追加。

项目状态能帮助重新理解工作，但不保存密钥，不恢复正在执行的请求，也不保证外部服务仍处于原状态。Git 能恢复配置，不意味着数据和凭据都可恢复。Agent 能找到下一步，也没有因此获得新的预算或权限。

我还不知道这套方式在很长项目、多次人员交接或并行修改里会出现哪些维护问题。现有使用说明它能提供恢复入口，没有证明它比所有记忆机制更好，更没有测出节省了多少 token 或多少人的时间。

我的当前判断是：与其追求让 Agent 永远不忘，不如让它在忘了以后仍能回到可以判断的位置。Mission 驱动决定谁负责继续推进；可恢复状态则帮助下一次推进不继承错误的现在。二者有关，但少了对现实的重新核对，保存再完整的状态也可能只是更稳定地延续一个旧错误。