CodeX记忆系统大更新

Codex用着用着就要压缩上下文、压着压着可能还“失忆”的痛苦，就要结束了！

Codex在其代码库中上新了一款_context工具，它可以让Agent放弃反复压缩上下文，转向了解自己还剩多少上下文空间。

结合新增的工作注释和历史查询能力来看，Codex CLI可能正在酝酿一套新的长任务记忆机制，即：

当上下文窗口快满时，Codex不再需要反复压缩旧对话，而是直接切换到一个新窗口；切换前Codex会细心留下工作注释，切换后则可以根据需要查询此前的完整对话记录。

换句话说，Codex可能正在准备给自己加上一套“外部记忆”。

当窗口不够用时，它就会带着交接材料换到一个新窗口继续工作。

而此前的聊天记录仍然会作为档案完整保留，如果Codex忘记了某个细节，它就可以随时回到历史记录中查旧账。

推上网友集体泪奔了——这种被AI气得半死、打又打不到，对方还一脸无辜的憋屈日子终于要结束了！

Agent工作越久，记忆反而可能越模糊

Codex之前采用的compaction（也就是上下文压缩）的办法有一个bug，即压缩很难真正做到无损。

就好比你读一本福尔摩斯小说，每看完50页就把剧情总结成一页，然后扔掉前面的原文。

第一次总结时，主要人物、案件进展和关键线索可能都还在；但连续总结几次之后，某个当时看起来无关紧要的细节，就可能彻底消失。

对于Coding Agent来说，这个被漏掉的细节，可能就是一条特殊的用户要求、一段终端报错、某个函数不能修改的原因，也可能是团队已经否决方案B的理由。

“方案B被否决”或许进入了摘要，但“为什么被否决”没有留下。

于是当几个小时以后环境发生了变化，Agent再次看到方案B，很可能就又会从头尝试一遍。

△

这种遗忘并非纯粹的理论问题，在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将不再执着于维持一段看似连续的超长对话，而是明确结束当前阶段，并在一个干净的新窗口里继续工作。

这听起来像是主动失忆，但这实际上更像工程团队里的换班。

一名工程师不可能把一个持续数月的项目全部装在脑子里，换人接手时，他需要的是一份清楚的交接文档，比如：

当前目标是什么、已经完成什么、试过哪些方法、哪些方案失败了、接下来应该做什么。

而这，就是工作注释的作用。

△

其次是查询历史记录。

一份交接文档不可能覆盖所有细节，但此前的完整对话仍然作为档案保留。

新窗口里的Agent如果遇到疑问，可以自行搜索旧记录，找回当时的用户原话、报错信息或者方案讨论，而不是完全依赖一份有损摘要。

两者结合起来，Codex CLI的记忆就从“一份反复改写的总结”，变成了“当前工作台＋交接笔记＋可搜索档案”。

摘要模式要求系统在压缩发生的那一刻判断“未来究竟需要哪些信息”；

而历史检索模式则允许系统等到问题真正出现后，再判断过去的哪些内容与此刻有关。

这样一来，当发现交接笔记漏掉了一个细节时，只要原始记录还在，它就有机会重新找回来。

如果这套机制工作理想，最直接的变化就是你不必再反复对AI说：“这件事刚才已经讲过了。”

而且它还可能减少一些更加隐蔽的浪费，比如浪费时间，消耗token，甚至对已经正确的代码造成二次破坏等。

但它也不是万能解法，比如它的注释有可能写错、有可能漏掉真正重要的约束、或者在需要检索历史时根本没意识到自己需要检索。

因此，评价这套机制的关键也应该是“Codex CLI能否在正确时间使用它们”。

新增的_context工具，让Codex能知道自己“脑容量”还剩多少

在Codex CLI这套记忆机制中，一个很容易被忽略、但可能相当关键的变化，是新增的_context工具。

它的作用是让Codex了解自己的上下文使用情况，例如：窗口还剩多少空间。

如果说过去Codex不知道自己的“笔记本”快写满了，会一直工作到系统在后台触发压缩；

那么加入 _context后，模型就有机会提前感知上下文容量状态，并据此调整行动。

如果_context判断空间还多，模型就可以继续探索；

反之，一旦窗口即将触顶，_context 便会及时“踩刹车”，让模型收束思路、沉淀当前结论，将关键信息落笔为注释，并为下一轮对话备好交接材料。

这相当于给Codex的驾驶舱增加了一块“剩余油量表”。

油量表本身不会让汽车跑得更远，但没有它，驾驶员很难决定什么时候应该继续赶路、什么时候应该寻找加油站。

So，从这个角度看，_context 不止一个贴心的小功能，它还在给Agent补上一种基础的“上下文自知”能力，以便让它不仅可以完成任务，还可以管理完成任务所依赖的认知资源。

△

并非Codex首创

不过呢，这种思路并非Codex首创。

Nico表示：“AmpCode早就试过了，且用户反馈也相当不错！”

开发者社区也早已摸索出不少手动方案。

比如有人会让Agent在任务中持续更新 plan.md或进度文件；有人会在窗口快满时，让模型生成一段“交接提示词”，随后清空对话，将提示词粘贴到新会话；还有人会专门保存每次切换窗口时的工作记录。

这些工作流共同承认了一件事，即： >与其假装Agent拥有一段无限连续的记忆，不如把任务拆成多个阶段，为每次切换建立明确的交接点。

Codex CLI的不同之处可能就在于，它不需要我们自己判断上下文满没满，它能自行读取剩余的上下文容量、自行决定何时整理笔记以及切换到新窗口需要补充什么信息。

△

比起百万上下文，Agent更需要学会管理记忆

过去两年，全球大模型厂商们在上下文窗口上展开了一场激烈非常的“军备竞赛”。

从几十万token一路狂飙至百万级，人人都在比“谁的脑容量大”、“谁堆砌的token数量多”；

“一口气能记住多少内容”俨然成为了衡量一款模型能力的核心卖点。

但Codex这次暴露出的方向，给大家伙提供了另一种思路，即： >Agent不一定需要把所有信息一直放在脑子里，你也可以教会它自己记笔记，并教它在快要写满的时候拿出一本新的笔记本继续写。

如果这套机制最终落地，Codex重塑的可能就不只是一次模型记忆的底层路径，还有一种新认知，即：

可靠的AI记忆不是永远不忘，而是即使忘了，也知道应该去哪里找回来。

对于正在构建Agent的团队及开发者而言，这或许是一个值得重新审视自身架构的重要信号。

本文来自微信公众号“量子位”，作者：关注前沿科技，36氪经授权发布。