Datawhale干货
更新：Codex CLI
Codex CLI 最近悄悄改了个大东西，它的记忆系统：放弃了 compaction（压缩）机制，转向 token budget（token 预算）+ 硬性上下文切换。简单说，模型不再被动等 token 用完被压缩，而是主动知道还剩多少额度，自己决定什么时候切换上下文。
我感觉 Codex 这次的改动在设计思路上有转变。这篇文章快速讲清楚三件事：它解决了什么问题、怎么设计的、有什么值得借鉴的视角。
一、先看问题：Compaction 有什么局限？
Compaction 的工作方式很简单：等 token 快用完时，把对话历史压缩成一段 summary，然后带着 summary 继续。这个方案用了挺久，但问题也很明显。
压缩是有损的。Summary 本质上是"概括"，概括就意味着丢细节。一段 10 轮的调试对话被压缩成三句话，中间的关键上下文就没了。
模型是被动的。模型不知道当前 context window 还剩多少 token，只能等到系统触发压缩。它无法提前规划，也无法在合适的时机主动整理上下文。
切换后是失忆的。压缩后的对话历史变成了一段 summary，模型无法回溯之前的完整记录。想看细节？已经被压缩掉了。
所以问题的核心是压缩本身就有损，换一个窗口但保留记忆才是更好的思路。
二、解决方案：Token Budget 的核心思路
Codex 的思路是：换一个窗口，但保留记忆。
不再压缩历史，而是让模型知道剩余额度，在合适的时候切换到新的 context window。切换不是"失忆"，因为历史记录完整保存在 history 和 notes 里，随时可以查。
这个方案带来三个转变：
从被动到主动。模型通过 <token_budget> 标签知道当前还剩多少 token，可以提前规划，在合适的时候主动切换。
从失忆到记忆。History 工具可以列出之前的对话窗口和条目，读取具体内容，搜索关键词。Notes 工具可以写入持久笔记，把工作状态保存下来。
从手动到自动。模型可以通过 metadata 自动启用 token budgeting，不需要用户手动配置。
核心就一句话：用预算管理替代压缩。
三、怎么设计的：Token Budget 的三层架构
Token Budget 的架构可以分成三层，每层解决一个问题。
感知层：知道还剩多少。通过 <token_budget> 标签，模型在每次请求时都能看到当前 context window 的剩余 token 数。这是主动管理的前提。
管理层：主动切换窗口。模型可以通过 new_context 工具主动请求切换到新的 context window。新窗口作为 no-summary compaction checkpoint，不压缩历史，直接开新窗口。
记忆层：保留和查询历史。History 工具可以列出 windows 和 items、读取 items、搜索对话内容。Notes 工具可以列出、读取、搜索、追加、写入持久笔记。
三层环环相扣：感知层让模型知道"什么时候该切了"，管理层让模型"能切"，记忆层让模型"切了之后还能找到之前的东西"。
四、设计哲学：从"压缩"到"记忆"
这个改动最值得琢磨的是它背后的设计哲学。
长上下文管理的本质是"记忆"。压缩是有损的，无论算法多好，丢掉的细节就是丢掉了。Token Budget 的思路是"换一个窗口，但保留记忆"，这更符合人类处理长任务的方式。我们会翻回之前的记录，而不是把之前的内容概括一下就扔掉。
从"被动"到"主动"是重要转变。以前模型是"被动执行"，等系统触发压缩。现在模型"主动知道还剩多少 token，并在合适的时候切换"。这是从"工具"到"伙伴"的角色转变。
从"工具"到"伙伴"的设计哲学。Compaction 把模型当成"工具"，用完就压缩。Token Budget 把模型当成"伙伴"，给它记忆，让它主动管理。这种设计哲学上的转变，比具体的技术实现更有价值。
写在最后
看完这些 PR 和代码，我感觉 Codex 这次改动在设计思路上有转变。长上下文管理从"压缩"变成"记忆"，这个视角转换挺有意思。
对做 Agent 的人来说，最值得参考的是"主动管理"这个思路。模型不再被动等待上下文被压缩，而是主动知道还剩多少 token，并在合适的时候切换。配合 history 和 notes 的记忆机制，让长任务的处理更接近人类的工作方式。
如果想深入学这个设计，建议重点看三层架构的配合。感知层让模型知道"什么时候该切"，管理层让模型"能切"，记忆层让模型"切了还能找到之前的东西"。这个设计思路不只适用于 Codex，做自己的 Agent 系统时也值得借鉴。
一起“点赞”三连↓