Codex重构长任务记忆:用Token预算与上下文切换替代压缩

Codex用Token预算、主动换窗和可检索记忆重构长任务上下文管理。

冷月清谈:

文章介绍了Codex CLI在长上下文管理上的设计变化:不再等上下文接近上限后,将历史对话压缩成可能丢失细节的摘要,而是向模型公开剩余Token预算,让模型主动选择切换上下文。新机制由三层组成:感知层通过token_budget告知剩余额度;管理层通过new_context开启无摘要的新窗口;记忆层借助History与Notes保存、检索历史对话和任务状态。这套方案将长任务管理从被动压缩转向主动规划,并让模型在切换窗口后仍可按需查找原始记录。文章认为,该思路对代码智能体和其他Agent系统具有借鉴价值,但实际效果仍取决于切换策略、检索质量、存储成本与模型调用工具的可靠性。

怜星夜思:

1、让模型自己决定什么时候切换上下文,真的会比系统设定固定阈值更可靠吗?
2、保留完整History和Notes虽然减少了信息损失,会不会带来更高的检索成本、延迟和隐私风险?
3、如果自己搭建一个Agent,Token预算、History和Notes中哪一部分最值得优先实现?
4、这种“换窗口再检索历史”的方式,能算真正的长期记忆吗?

原文标题:Codex悄悄大改了记忆系统!

原文作者:数据派THU

原文内容

图片
本文约2000字,建议阅读5分钟
模型不再被动等 token 用完被压缩,而是主动知道还剩多少额度,自己决定什么时候切换上下文。


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 系统时也值得借鉴。

编辑:文婧



关于我们

数据派THU作为数据科学类公众号,背靠清华大学大数据研究中心,分享前沿数据科学与大数据技术创新研究动态、持续传播数据科学知识,努力建设数据人才聚集平台、打造中国大数据最强集团军。




新浪微博:@数据派THU

微信视频号:数据派THU

今日头条:数据派THU



关于「是否算长期记忆」:从认知架构角度看,它更接近外部记忆,而不是模型参数中的内化记忆。模型并未永久学会历史内容,只是在需要时通过工具重新读取。

1 个赞

回答History和Notes的代价:实际不一定每次都读取全部记录,可以先搜关键词或按任务阶段过滤,再加载少量条目。真正影响延迟的往往不是存了多少,而是检索是否精准。

3 个赞

关于什么时候换窗:全交给模型有点像让一个聊上头的人自己决定几点睡,理论上会看时间,实际可能说“再来一轮”。系统兜底还是得有。