文章摘要
Codex CLI放弃易丢失关键细节、易引发长任务返工的传统上下文压缩机制，推出全新上下文管理方案：新增Token余量感知机制，通过new_context工具主动切换全新上下文窗口，搭配记录核心状态的笔记功能与可回溯原始内容的全历史检索功能，相关更新已并入正式版v0.150.0。

近期，一名开发者在社交平台分享了Codex CLI的更新计划：这款工具将放弃传统的上下文压缩模式，转而采用全新的上下文硬切换机制，搭配内置笔记与全历史检索功能，彻底改变长任务运行逻辑。

这条动态很快获得了大量关注，随后开发者公布了两项关键的代码更新：一项是用于创建全新上下文窗口的new_context工具，另一项则是将历史记录与笔记功能整合进Codex的改进。

简单来说，Codex将拥有自主管理工作记忆的能力：当上下文窗口即将耗尽时，它会先梳理清楚当前的工作进度与核心状态，再切换到全新的干净窗口继续任务。此前的对话内容不会继续占用当前窗口空间，当需要核对细节时，Codex可以随时回溯完整的历史记录。

这一改动直击了编码代理工具长期存在的一个痛点：在长时间运行的任务中，传统的上下文压缩机制会将过往对话和工具结果压缩为简短的状态摘要，虽然能节省Token占用，但很容易丢失关键细节。比如用户已经明确告知某个依赖不能升级，并且已经排除了三条可行的方案，但运行数小时后，经过一次上下文压缩，模型可能还记得“不能升级”这个结论，却忘记了无法升级的具体原因，当环境出现细微变化时，之前已经否决的方案可能会被重新尝试，导致任务返工。Codex这次的更新，正是要替换这种仅依靠压缩摘要接力的工作模式。

第一步：让模型感知上下文余量

传统的compaction机制会将过往对话和工具结果压缩为更短的状态，以此腾出空间继续工作，相关厂商将其称为loss-aware compression：在尽量保留有用信息的前提下大幅减少Token占用。但这类机制的问题在于，系统需要提前预判哪些细节在后续任务中会被用到，而一句用户的约束条件、一次失败的终端输出、某个被放弃方案的原因，在当时看起来只是无关紧要的边角料，几小时后却可能直接决定整个任务是否需要返工。

新方案的第一步是引入token_budget机制，这套机制会向模型实时反馈当前上下文窗口的序号与剩余Token数量。同时Codex新增了一个仅可供模型调用的get_context_remaining工具，让模型在运行过程中可以主动查询剩余的上下文空间，相当于给模型装上了一个“油量仪表盘”。当剩余空间充足时，模型可以继续查询代码、运行测试；当接近窗口边界时，模型可以主动收束当前阶段的工作，将后续需要用到的关键信息写入交接记录。相比以往等到窗口被撑满才被动压缩，新机制让模型可以自主选择更合适的时机完成上下文切换。

第二步：自动切换上下文窗口

负责切换上下文窗口的核心工具是new_context。当模型判断当前窗口不再适合继续工作时，可以主动请求创建一个全新的上下文窗口。这项更新有一个容易被忽略的细节：新创建的窗口只会加载初始上下文，不会带入上一个窗口的对话内容，也不会自动生成压缩摘要。单独来看，这项功能相当于让模型主动“清空大脑”，而后续加入的notes与history工具，则让模型可以在清空窗口后依然接续之前的工作。

第三步：笔记与历史的分工机制

notes工具用于保存跨窗口可用的工作状态，模型可以对笔记进行列出、读取、搜索、追加或重写操作。history工具则用于保存完整的原始运行记录，支持按窗口查看条目，也可以搜索过往的对话与工具返回结果。

两者的分工非常贴合工程师的日常工作习惯：笔记中记录当前的工作进度、已经尝试过的方案、下一步的计划；当需要追溯细节时，再从历史记录中查找当时的原始对话与终端输出。代码还为自动换窗预留了额外的Token空间，当接近窗口边界时，模型会获得最后一次整理机会，先将关键状态写入笔记。新窗口启动后，会先加载一段最多4000字节的上下文提示，如果信息不足，再通过搜索完整历史记录获取细节。

比如在一次跨40个文件的重构任务中，笔记可以记录已经完成23个文件的修改、测试卡在哪个模块、哪些方案已经被否决；而history则会保留具体的报错信息、用户的约束条件以及失败调用的完整输入输出内容。通过这种设计，当前窗口只会展示当前正在处理的内容，笔记负责衔接前后任务，历史记录作为兜底保障，模型不再需要将数小时的工作全部押在一份越来越精简的压缩摘要上。

落地进展与未来展望

这套更新方案并非纸面设想，相关的代码改动已经逐步合并到Codex的正式版本中。new_context工具的PR在6月完成合并，history与notes工具的PR则在8月合并，相关改动已经出现在Codex CLI 0.150.0的更新日志中。后续的另一项更新还允许通过模型配置，在新线程启动时默认启用这套全新的上下文管理机制。

对于长任务而言，这项更新的核心价值其实非常朴素：无论上下文窗口有多大，总会有被填满的时刻。长任务能否持续推进，最终取决于模型能否在切换窗口前做好工作交接，以及能否在需要时回溯历史记录。如果这套机制能够顺利开放，Codex在完成一次上下文切换后，将能像重新回到工位的工程师一样：翻开笔记找到昨日的工作现场，继续推进后续的任务。

参考链接

以上内容不代表本平台立场，仅供读者参考