Codex 用着用着就要压缩上下文、压着压着可能还"失忆"的痛苦，就要结束了！
Codex 在其代码库中上新了一款 _context 工具，它可以让 Agent 放弃反复压缩上下文，转向了解自己还剩多少上下文空间。
结合新增的工作注释和历史查询能力来看，Codex CLI 可能正在酝酿一套新的长任务记忆机制，即：
当上下文窗口快满时，Codex 不再需要反复压缩旧对话，而是直接切换到一个新窗口；
切换前 Codex 会细心留下工作注释，切换后则可以根据需要查询此前的完整对话记录。
换句话说，Codex 可能正在准备给自己加上一套"外部记忆"。
当窗口不够用时，它就会带着交接材料换到一个新窗口继续工作。
而此前的聊天记录仍然会作为档案完整保留，如果 Codex 忘记了某个细节，它就可以随时回到历史记录中查旧账。
推上网友集体泪奔了——这种被 AI 气得半死、打又打不到，对方还一脸无辜的憋屈日子终于要结束了！
Agent 工作越久，记忆反而可能越模糊
Codex 之前采用的compaction（也就是上下文压缩）的办法有一个 bug，即压缩很难真正做到无损。
就好比你读一本福尔摩斯小说，每看完 50 页就把剧情总结成一页，然后扔掉前面的原文。
第一次总结时，主要人物、案件进展和关键线索可能都还在；但连续总结几次之后，某个当时看起来无关紧要的细节，就可能彻底消失。
对于 Coding Agent 来说，这个被漏掉的细节，可能就是一条特殊的用户要求、一段终端报错、某个函数不能修改的原因，也可能是团队已经否决方案 B 的理由。
"方案 B 被否决"或许进入了摘要，但"为什么被否决"没有留下。
于是当几个小时以后环境发生了变化，Agent 再次看到方案 B，很可能就又会从头尝试一遍。
AI 生成
这种遗忘并非纯粹的理论问题，在 Codex 公开的代码库中，此前已有用户报告压缩后任务背景变得模糊、历史工作被遗漏等情况。
一位网友 Nico 发现，与 GPT5.5 和 5.4 相比，5.6 版本的数据经过压缩后出现了保真度下降。
他原本只是让 ChatGPT 在 Codex CLI 代码库中寻找一种让大模型了解自身上下文状态的方法，结果顺着代码一路追查，意外掉进了一个"兔子洞"，最终发现 Codex 正在准备新的上下文管理方式。
这可真是"踏破铁鞋无觅处，得来全不费工夫"啊。
不过截至发稿，OpenAI 官方文档依然将 compaction 列为长任务的上下文管理机制。（GPT ‑ 5.6 目前也在支持和使用 compaction。）
因此，我觉得更大的可能性是Codex CLI "正在准备转向"或者"正在测试"，而不是这项功能已经全面上线。
不过，从现有线索来看，Codex CLI 这次改变确实并不只是在单纯地优化压缩质量，而是在准备给自己换一种记忆思路。
不再反复压缩，Codex 开始学着"交接班"
新方案概括为三个部分：硬切上下文窗口、工作注释，以及历史记录查询。
首先是硬切窗口。
当前上下文接近上限时，Codex CLI 将不再执着于维持一段看似连续的超长对话，而是明确结束当前阶段，并在一个干净的新窗口里继续工作。
这听起来像是主动失忆，但这实际上更像工程团队里的换班。
一名工程师不可能把一个持续数月的项目全部装在脑子里，换人接手时，他需要的是一份清楚的交接文档，比如：
当前目标是什么、已经完成什么、试过哪些方法、哪些方案失败了、接下来应该做什么。
而这，就是工作注释的作用。
AI 生成
其次是查询历史记录。
一份交接文档不可能覆盖所有细节，但此前的完整对话仍然作为档案保留。
新窗口里的 Agent 如果遇到疑问，可以自行搜索旧记录，找回当时的用户原话、报错信息或者方案讨论，而不是完全依赖一份有损摘要。
两者结合起来，Codex CLI 的记忆就从"一份反复改写的总结"，变成了"当前工作台＋交接笔记＋可搜索档案"。
摘要模式要求系统在压缩发生的那一刻判断"未来究竟需要哪些信息"；
而历史检索模式则允许系统等到问题真正出现后，再判断过去的哪些内容与此刻有关。
这样一来，当发现交接笔记漏掉了一个细节时，只要原始记录还在，它就有机会重新找回来。
如果这套机制工作理想，最直接的变化就是你不必再反复对 AI 说："这件事刚才已经讲过了。"
而且它还可能减少一些更加隐蔽的浪费，比如浪费时间，消耗 token，甚至对已经正确的代码造成二次破坏等。
但它也不是万能解法，比如它的注释有可能写错、有可能漏掉真正重要的约束、或者在需要检索历史时根本没意识到自己需要检索。
因此，评价这套机制的关键也应该是" Codex CLI 能否在正确时间使用它们"。
新增的 _context 工具，让 Codex 能知道自己"脑容量"还剩多少
在 Codex CLI 这套记忆机制中，一个很容易被忽略、但可能相当关键的变化，是新增的 _context 工具。
它的作用是让 Codex 了解自己的上下文使用情况，例如：窗口还剩多少空间。
如果说过去 Codex 不知道自己的"笔记本"快写满了，会一直工作到系统在后台触发压缩；
那么加入 _context 后，模型就有机会提前感知上下文容量状态，并据此调整行动。
如果 _context 判断空间还多，模型就可以继续探索；
反之，一旦窗口即将触顶，_context 便会及时"踩刹车"，让模型收束思路、沉淀当前结论，将关键信息落笔为注释，并为下一轮对话备好交接材料。
这相当于给 Codex 的驾驶舱增加了一块"剩余油量表"。
油量表本身不会让汽车跑得更远，但没有它，驾驶员很难决定什么时候应该继续赶路、什么时候应该寻找加油站。
So，从这个角度看，_context 不止一个贴心的小功能，它还在给 Agent 补上一种基础的"上下文自知"能力，以便让它不仅可以完成任务，还可以管理完成任务所依赖的认知资源。
AI 生成并非 Codex 首创
不过呢，这种思路并非 Codex 首创。
Nico 表示：" AmpCode 早就试过了，且用户反馈也相当不错！"
开发者社区也早已摸索出不少手动方案。
比如有人会让 Agent 在任务中持续更新 plan.md 或进度文件；有人会在窗口快满时，让模型生成一段"交接提示词"，随后清空对话，将提示词粘贴到新会话；还有人会专门保存每次切换窗口时的工作记录。
这些工作流共同承认了一件事，即： >与其假装 Agent 拥有一段无限连续的记忆，不如把任务拆成多个阶段，为每次切换建立明确的交接点。
Codex CLI 的不同之处可能就在于，它不需要我们自己判断上下文满没满，它能自行读取剩余的上下文容量、自行决定何时整理笔记以及切换到新窗口需要补充什么信息。
AI 生成比起百万上下文，Agent 更需要学会管理记忆
过去两年，全球大模型厂商们在上下文窗口上展开了一场激烈非常的"军备竞赛"。
从几十万 token 一路狂飙至百万级，人人都在比"谁的脑容量大"、"谁堆砌的 token 数量多"；
"一口气能记住多少内容"俨然成为了衡量一款模型能力的核心卖点。
但 Codex 这次暴露出的方向，给大家伙提供了另一种思路，即： >Agent 不一定需要把所有信息一直放在脑子里，你也可以教会它自己记笔记，并教它在快要写满的时候拿出一本新的笔记本继续写。
如果这套机制最终落地，Codex 重塑的可能就不只是一次模型记忆的底层路径，还有一种新认知，即：
可靠的 AI 记忆不是永远不忘，而是即使忘了，也知道应该去哪里找回来。
对于正在构建 Agent 的团队及开发者而言，这或许是一个值得重新审视自身架构的重要信号。
参考链接：
[ 1 ] https://x.com/nicoritschel/status/2093775003888361576?s=20
[ 2 ] https://x.com/AmpCode
[ 3 ] https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.5
[ 4 ] https://github.com/openai/codex/pull/27488
[ 5 ] https://github.com/openai/codex/discussions/15432
[ 6 ] https://github.com/openai/codex/issues/36721
[ 7 ] https://github.com/openai/codex/issues/17354
[ 8 ] https://ampcode.com/guides/context-management
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
� � 点亮星标 � �
科技前沿进展每日见
正中优配提示：文章来自网络，不代表本站观点。
