谈Codex-Max模型的自动Context压缩

本文主要分析GPT‑5.1-Codex-Max模型的自动context压缩功能。

它的发布文网址是

https://openai.com/index/gpt-5-1-codex-max/

其中提到自动压缩功能的段落有：

GPT‑5.1-Codex-Max is built for long-running, detailed work. It’s our first model natively trained to operate across multiple context windows through a process called compaction, coherently working over millions of tokens in a single task. This unlocks project-scale refactors, deep debugging sessions, and multi-hour agent loops. GPT‑5.1-Codex-Max

专为长时间、细致的工作而打造。它是我们首个通过称为压缩（compaction）的过程，原生训练以跨多个上下文窗口运行的模型，能够在单个任务中连贯地处理数百万个 token。这将解锁项目级重构、深入的调试会话以及持续数小时的代理循环。

—

Compaction enables GPT‑5.1-Codex-Max to complete tasks that would have previously failed due to context-window limits, such as complex refactors and long-running agent loops by pruning its history while preserving the most important context over long horizons. In Codex applications, GPT‑5.1-Codex-Max automatically compacts its session when it approaches its context window limit, giving it a fresh context window. It repeats this process until the task is completed.

压缩功能使 GPT‑5.1-Codex-Max 能够完成此前会因上下文窗口限制而失败的任务，例如通过在长时间跨度内修剪历史同时保留最重大的上下文，从而进行复杂的重构和长时间运行的智能体循环。在 Codex 应用中，GPT‑5.1-Codex-Max 会在接近其上下文窗口限制时自动压缩会话，为其提供一个全新的上下文窗口。它会重复这一过程，直到任务完成。

很明显，OpenAI不会介绍任何关于它的具体实现方式。而本文从这里开始。

对于 GPT‑5.1-Codex-Max 模型自动压缩能力实现方式的推测

在Codex-Max之前，Claude Code也有“自动”Context压缩功能：

Claude Code自带一个按Context消耗长度自动触发的整个Context历史压缩功能。但效果颇为鸡肋。它是直接让LLM对于整个对话历史进行总结，并重新载入对话中讨论的一些文件的内容。从实践中，它并不能支持长时间的自动运行，触发Context压缩之后，效果会明显下降，甚至有时候无法继续执行任务。

此外，目前Codex-Max模型只能在OpenAI自己的Codex中使用，连与OpenAI紧密合作的Cursor上的也都尚未上线该模型。

在我看来，Codex-Max模型的自动压缩Context能力明显不会是Claude Code那样的方式，一是这种方式并不值得特别强调，第二是这种方式大致率也无法实现长时间、跨越多轮压缩过程的稳定的任务执行。

不知道读者会如何推测该功能的实现，但在我的认知中，有一个明显最简单的实现思路，就是：把Context压缩也作为一个tool，并使用Agent RFT性的方案来直接训练模型熟悉该工具。

当然这可能出乎许多读者的预料，tool调用并非只能单纯地在Context中继续增加内容。实际上，我们可以编写一些修改当前Session历史Context的tool，唯一的问题只是LLM是否能够用好这种工具，而Agent RFT基本解决了这点。

下面是一个简洁的设计，虽然未必是唯一可以实现的方案，但我觉得它足够简洁和有效了。

修改Chat History中每个message的格式，在message中增加message index，还要加入已经消耗的context token数量，或者剩余可用的context token数量。
增加一个compress history tool，参数是：要修改的history中的message 范围（用index表明），以及修改后的结果（以新的message方式表达）
（可选）增加一种新的message role，用来表达中间被压缩的历史。

然后指示LLM（例如通过prompt）当剩余context token可能不足时，调用compress history tool，将history中的部分消息进行压缩。

在具体的训练中，还有不同的调教方向可选：

尽量惰性的压缩，尽可能多保留 context。
平衡，每次触发需要压缩时，把历史history中的次要信息都压缩掉，减少触发压缩过程的频率，提升KV Cache的复用性。
激进。每次完成一个任务环节时，都把中间无需保留到后续的信息压缩掉，保持平均context最短。

谈Agent Memory的自动管理

有人可能会觉得上述Context自动压缩就已经算得上是一种简单的（模型层）自动Memory方案了。

但它的限制依旧许多，实际上这种方式可以直接推广到实现一种更通用的、可自动管理的外部 Memory 能力。这也是我在之前文章里提到的那个猜测：模型层可能用不了多久就会在这方面有明显进展。

下面也给出一个具体的实现设计，该方案包含一组tool函数，我称之为【Memory tool套件】

Memory是在一个外部虚拟文件系统中的，包含的对象有：目录、文本文件、文件的快捷方式/软连接、向量索引数据库文件、全文检索数据库文件等。
【TextFileWrite】向指定路径的文本文件的某个部分插入或替换文本（以行为操作单元）
【TextFileRead】读取指定路径文本文件的某个范围（以行为操作单元）
【ListPath】获取某个路径下的文件和目录列表
（可选的其他文件系统操作工具，例如移动、批量删除等）
【PathDescUpdate】更新某个文件或目录的描述信息（相当于文件系统的元信息，或者是以特殊文件的形式保存在文件系统中）
【PathDescRead】读取某个路径下的文件或目录的描述信息。
【EmbeddingUpdate】向指定路径的VectorDB中，插入数据、更新数据或删除数据。数据中可以包含文件引用，例如引用到某个路径下的文件的某一个部分。
【EmbeddingRecall】从指定路径的VectorDB中，使用指定query进行类似度检索召回
【FullTextUpdate】向指定路径的全文检索引擎数据库中，插入数据、更新数据或删除数据，数据也可以是某个路径下文件的一个引用。
【FullTextSearch】从指定路径的全文检索引擎数据库中，使用指定query进行全文检索查询或模糊查询或Regex查询
【BruteforceSearch】在没有索引支持的情况下，暴力地对存储中的所有文件进行进行枚举，并做文本/regex 匹配检索。

并且还要引导LLM：

将整个Memory存储的结构设计保存在存储中的固定位置，例如根路径 / 的描述信息，或者是根路径下的Readme.md文件等。
利用路径的描述信息进行分层的信息summary，加速检索召回过程。
当涉及到大型外部Memory的结构调整时，还可能需要引导LLM以新的规格创建一个新的外部存储，然后逐步做数据迁移，以提升成功率，并降低任务失败时旧memory结构被破坏的风险。

Claude之前就已经推出了一个超级简化（或者说残缺的memory tool套件），这里从略。