Codex用久了就得不断压缩上下文，压着压着还可能「失忆」的情况，或许在准备换一种做法。
从Codex代码库的新变化看，Codex新增了一款 _context 工具，让Agent不必反复压缩上下文，而是先了解自己还剩多少上下文空间。再结合新增的工作注释和历史查询能力，Codex CLI看起来正在酝酿一套新的长任务记忆机制：当上下文窗口快满时，不再一遍遍压缩旧对话，而是切换到一个新窗口；切换前留下工作注释，切换后按需查询此前的完整对话记录。
换句话说，Codex可能正在给自己加上一套「外部记忆」。窗口不够用时，它带着交接材料换到新窗口继续工作；此前的聊天记录则继续完整保留，若遗漏了某个细节，还可以回到历史记录中查找。
文中提到，推特上的网友对这一变化反应强烈，因为不少人都遇到过AI在长任务中前后脱节、反复犯错，却又很难及时纠正的情况。
反复压缩上下文，为什么会让Agent越干越糊涂
Codex此前采用的 compaction，也就是上下文压缩，本身有一个问题：压缩很难真正做到无损。
文中用一个类比解释这个问题：就像读一本福尔摩斯小说，每看完 50 页就把剧情总结成 1 页，再把前面的原文丢掉。第一次总结时，主要人物、案件进展和关键线索可能都还在；但如果连续总结几次，某个当时看起来不重要的细节，就可能彻底消失。
对 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不再执着于维持一段看似连续的超长对话，而是结束当前阶段，在一个新的干净窗口里继续工作。
这看上去像主动失忆，但文中认为，它更像工程团队里的换班。一个持续数月的项目，不可能全装在一名工程师脑子里。换人接手时，更重要的是一份清楚的交接文档：当前目标是什么、已经完成了什么、试过哪些方法、哪些方案失败了、下一步该做什么。工作注释承担的就是这个角色。
第二部分是查询历史记录。交接文档不可能覆盖全部细节，但此前的完整对话仍作为档案保留。新窗口中的 Agent 如果有疑问，可以自己搜索旧记录，找回当时的用户原话、报错信息或方案讨论，而不是只依赖一份有损摘要。
两者结合后，Codex CLI 的记忆结构就从「一份反复改写的总结」，变成了「当前工作台 + 交接笔记 + 可搜索档案」。
这两种模式的差别也很明显。摘要模式要求系统在压缩发生的那一刻判断，未来究竟哪些信息会有用；历史检索模式则允许系统等到问题真的出现后，再回头判断过去哪些内容和当前任务有关。
这样一来，即便交接笔记漏掉了一个细节，只要原始记录还在，就仍有机会补回来。
如果这套机制运作理想，最直接的变化就是，用户不必再反复告诉 AI：「这件事刚才已经讲过了。」文中还提到，它也可能减少一些更隐蔽的浪费，包括时间、token 消耗，甚至对原本正确代码造成二次破坏。
但这套机制也不是万能解法。注释可能写错，也可能漏掉真正重要的约束；系统在需要检索历史时，也可能根本没有意识到自己应该检索。因此，关键不只在于有没有这些机制，还在于 Codex CLI 能否在正确的时间使用它们。
_context工具的作用：让模型知道自己还剩多少空间
在这套记忆机制里，一个容易被忽略但可能很关键的变化，就是新增的 _context 工具。
它的作用，是让 Codex 了解自己的上下文使用情况，比如窗口还剩多少空间。
如果过去的 Codex 不知道自己的「笔记本」快写满了，它就会一直工作，直到系统在后台触发压缩；加入 _context 之后，模型就有机会提前感知上下文容量状态，再决定接下来怎么做。
如果 _context 判断空间还充足，模型可以继续探索。反过来，一旦窗口将要触顶，_context 就会及时「踩刹车」，让模型收束思路、沉淀当前结论、把关键信息写成注释，并给下一轮对话准备好交接材料。
文中把它比作驾驶舱里的「剩余油量表」。油量表本身不会让车跑得更远，但没有它，驾驶员很难判断什么时候该继续赶路，什么时候该去找加油站。
从这个角度看，_context 不只是一个小功能，它还在补上一种基础的「上下文自知」能力，让 Agent 不只是完成任务，还能管理完成任务所依赖的认知资源。
这种思路并非Codex首创
文中同时提到，这条路线并不是 Codex 首创。
Nico 表示：「AmpCode 早就试过了，且用户反馈也相当不错！」
开发者社区此前也摸索出不少手动方案。有人会让 Agent 在任务过程中持续更新 plan.md 或进度文件；有人会在窗口快满时，先让模型生成一段「交接提示词」，再清空对话，把提示词贴到新会话中；还有人会专门保存每次切换窗口时的工作记录。
这些工作流背后承认的是同一件事：与其假装 Agent 拥有一段无限连续的记忆，不如把任务拆成多个阶段，并为每次切换设置明确的交接点。
Codex CLI 可能不同的地方在于，它不需要用户自己判断上下文是否已满，而是能自己读取剩余的上下文容量，自己决定何时整理笔记，以及切换到新窗口前还需要补充什么信息。
比拼百万上下文之外，Agent也许更需要管理记忆
过去两年，大模型厂商一直在上下文窗口上展开激烈竞争。从几十万 token 到百万级，围绕「谁的脑容量更大」「谁能一次装下更多内容」的比较一直没有停过，「一口气能记住多少内容」也逐渐成了衡量模型能力的重要卖点。
而这次Codex暴露出的方向，给出了另一种思路：Agent 不一定要把所有信息一直放在脑子里，也可以学会自己记笔记，并在快写满时换一本到新的「笔记本」继续写。
如果这套机制最终落地，文中认为，Codex改变的可能不只是模型记忆的底层路径，还有一种对 AI 记忆的理解：可靠的 AI 记忆，不是永远不忘，而是即使忘了，也知道该去哪里找回来。
对正在构建 Agent 的团队和开发者来说，这可能是一个重新审视自身架构的信号。
本文来自微信公众号「量子位」，作者为「关注前沿科技」；MarsBit进行了转载。