我最近用 Codex 跑了大量长任务，发现一个很烦的问题：达不到我的预期
任务刚开始时，它完全理解我的意思。跑到后面触发上下文压缩，结果就开始慢慢跑偏。代码可能通过测试，但最后交付的东西已经不是我最初要的东西了。
后来我看到 Codex 已经在尝试 new_context、notes 和 history：上下文不够时切窗口，用 notes 交接，必要时回查旧历史。
摘要、notes 和 history，各自做什么
compaction 和硬切窗口经常被看作两条互斥路线。放进实际链路里，它们承担的工作和读取成本并不相同。
放回同一条运行链路里，它们更像不同成本的读取层级。
摘要适合快速恢复全局，notes 适合保存明确的交接状态，原始 history 适合核对关键细节。只有摘要，遗漏的信息很难找回；只有原始记录，新窗口又可能花很多次检索才能拼出任务全貌。
Codex 当前实验采用了“短交接 + 原始历史”的组合，compaction 也仍然留在官方产品里。以后哪条路会成为主线，最终还得看真实任务数据；眼下仅凭一条帖子和几组 PR 还看不出来。
Teknium 提到 Hermes 也在加入 compaction recall。两个项目的具体实现不同，却都给压缩或交接后的内容留了回查原始记录的入口。
目前怎么开启
Codex CLI 0.153.0 的公开配置是：
在 ~/.codex/config.toml 中加入两行：
[features.context_management]experimental_mode = true
它默认关闭，并受前面提到的账号、后端和线程类型限制。开发阶段曾出现 [features] token_budget = true 和更早的细分开关，当前公开配置已经换成了上面的入口
但我觉得这还没有完全解决“最后交付跑偏”的问题。
真正不能丢的，不只是之前聊过什么，而是：
- 原始目标是什么；
- 哪些事情明确不做；
- 哪些验收条件还没完成；
- 哪些结论有测试、日志或文件证据；
- 下一步唯一应该做什么。
我的思路是再加一层不会被摘要改写的任务状态：
任务契约：目标、边界、验收标准
当前快照：做到哪一步、卡在哪里
执行账本：每一步实际发生了什么
证据：测试结果、Git diff、日志和外部系统状态
每次切换上下文后，Agent 先对照这几项，再继续工作。没有证据，就不能把“测试通过”当成事实；没有完成验收，就不能宣布任务完成。
压缩可以丢掉聊天细节，但不能丢掉目标、边界、证据和未解决的问题。
大家用 Codex、Claude Code 或其他 Coding Agent 时，有没有遇到过这种“过程看起来没问题，最后结果却跑偏”的情况？
