Codex 真的不再压缩上下文了吗？从 Compaction 到硬切窗口

最近有一个说法很火：

Codex 要取消上下文压缩，改成硬切 context window，再通过外部记忆继续工作。

更准确的说法是：

Codex 正在尝试一条新的上下文管理路径：在特定 TokenBudget 条件下，不再只依赖摘要压缩，而是开启新的 context window，再通过 notes 和 history 恢复任务状态。

这和"所有 Codex 都已经不再压缩上下文"不是一回事。

Context window 是什么？

大语言模型每次工作，都需要把相关信息放进输入里。

这些信息可能包括：

复制代码

用户消息
模型回答
工具调用
终端输出
代码内容
测试结果
图片和文件信息
系统指令

这些内容共同组成了模型当前能看到的上下文。

可以把 context window 想象成一张白纸。

模型回答问题时，只能根据这张纸上的内容进行思考。纸张大小是有限的，写得越多，剩余空间就越少。

长时间运行的编程任务尤其容易把这张纸写满：

markdown 复制代码

用户提需求
    ↓
读取项目
    ↓
修改代码
    ↓
运行测试
    ↓
修复问题
    ↓
继续读取文件
    ↓
再次运行测试

每调用一次工具，都会增加新的上下文。

最后就会出现一个问题：

复制代码

这张纸快写满了，接下来怎么办？

传统方案：压缩上下文

以前比较常见的做法是 compaction，也就是上下文压缩。

流程大概是：

markdown 复制代码

旧上下文
    ↓
总结成一段更短的内容
    ↓
用这段内容替换大量旧消息
    ↓
继续工作

举个简单的例子。

原始对话可能是：

bash 复制代码

用户：给项目增加日志功能。

Codex：已经增加，默认级别是 INFO。

用户：把默认级别改成 DEBUG。

Codex：已经修改。

用户：再增加一个 Prometheus 指标接口。

Codex：/metrics 接口已经完成。

压缩之后，可能变成：

bash 复制代码

项目增加了日志功能，默认级别为 DEBUG，并增加了 /metrics 接口。

对于这种对话，压缩效果很好。

那些"已经修改""再调整一下"的中间过程并不重要，最终结论保留下来就够了。

所以，压缩并不是一个糟糕的方案。

它解决了一个很现实的问题：

复制代码

模型的上下文有限，但任务不能因为写满就停止。

压缩的问题：摘要不是原文

压缩最大的风险是，摘要一定会做取舍。

模型需要判断：

复制代码

什么重要？
什么可以删除？
什么以后还会用到？
什么只是临时过程？

普通聊天里，这种取舍通常没什么问题。

但编程任务里，很多细节可能非常关键：

复制代码

只能修改前端，不能修改后端
接口必须保持兼容
某个方案之前已经失败
某个文件明确不能修改
测试失败，但当前决定暂时不处理
用户明确否定过某种实现方式

这些内容在摘要里很容易变成一句：

复制代码

相关功能已经完成。

看起来很完整，实际上最重要的限制可能已经丢了。

于是新窗口里的模型可能会出现这种情况：

复制代码

用户：我不是说过不能改后端吗？

Codex：抱歉，我没有保留这个限制。

这并不是模型故意忘记，而是这个限制可能没有进入压缩后的上下文。

更麻烦的是摘要的摘要

如果任务足够长，压缩可能发生很多次。

第一次：

css 复制代码

原始对话 -> 摘要 A

第二次：

css 复制代码

摘要 A + 新对话 -> 摘要 B

第三次：

css 复制代码

摘要 B + 新对话 -> 摘要 C

这就像一张照片被反复复印。

第一代复印件可能还清楚，复印很多代之后，细节就越来越模糊。

因此，压缩真正需要解决的不是：

复制代码

能不能把文字变短？

而是：

复制代码

变短以后，关键事实还在不在？

新方案：硬切 context window

Codex 正在尝试的另一种方案，是直接开启一个新的 context window。

流程变成：

javascript 复制代码

旧窗口快满
    ↓
保存当前工作状态
    ↓
创建新的 context window
    ↓
恢复当前任务状态
    ↓
需要细节时查询历史
    ↓
继续工作

这个过程可以类比成程序员使用白板。

旧白板写满以后，不是把整块白板压缩成一句话，而是：

markdown 复制代码

先把白板拍照存档
    ↓
记录当前做到哪里
    ↓
擦掉白板
    ↓
换一块新的白板
    ↓
继续工作

新白板上只写当前最需要的信息。

如果之后想确认某个细节，再去查看旧白板的照片。

这就是所谓的"硬切窗口"。

硬切不是重新开一个聊天

这里最容易误解的一点是：

javascript 复制代码

新的 context window
不等于
新的聊天会话

硬切主要清理的是模型当前能直接看到的上下文。

任务本身、对话历史和外部状态仍然可以继续存在。

所以它更像：

复制代码

同一个任务，换了一张工作纸

而不是：

复制代码

关闭旧聊天，重新开始一个完全无关的任务

对于用户来说，理想效果应该是：

复制代码

任务还在继续
模型只是换了一张新的工作纸

notes 是什么？

新窗口最重要的问题是：

复制代码

换了新窗口以后，模型怎么知道自己之前做到哪里了？

这就需要 notes。

notes 可以理解成一份任务交接文档，里面记录：

复制代码

当前目标
已经完成的内容
已经做出的决定
不能违反的限制
尝试过但失败的方案
测试结果
关键文件
下一步计划

例如：

bash 复制代码

目标：修复 OAuth 登录超时。

决定：不修改 token refresh API，只调整客户端重试逻辑。

进度：auth/session.rs 已完成修改。

问题：login_test 还有两个失败。

限制：不能修改后端接口。

下一步：继续检查 reconnect 流程。

有了这样的记录，新窗口就不必重新阅读几万条消息，也能快速恢复当前工作状态。

不过 notes 并不是模型完整思维过程的保存区。

它保存的是：

复制代码

任务状态
技术决策
约束条件
下一步计划

而不是模型所有内部推理。

history 是什么？

notes 负责记录当前状态，但有时候一份笔记还不够。

比如模型突然想确认：

复制代码

用户当时到底说了什么？
某个测试为什么失败？
之前尝试过哪种方案？
某个工具返回的原始结果是什么？

这时候就需要 history。

history 更像一个完整的历史档案库。

它可能包含：

javascript 复制代码

过去的用户消息
模型回答
工具调用
终端输出
测试结果
旧 context window 中的具体事件

需要注意，history 不是模型主动保存完整历史的地方。

完整历史通常已经由系统保存，history 更像是模型查询历史的入口。

因此两者的职责不同：

bash 复制代码

notes：保存当前工作状态

history：查询过去发生过的事实

这两个东西配合起来，就像：

bash 复制代码

notes 是项目交接文档
history 是完整项目档案

新窗口先看交接文档，只有在遇到疑问时，才去翻完整档案。

"替换"到底替换了什么？

很多人说：

Codex 把旧上下文替换成了新上下文。

这句话基本没错，但还可以说得更准确。

真正被替换的，主要是：

复制代码

当前交给模型的输入内容

传统压缩的替换方式是：

markdown 复制代码

旧消息
    ↓
生成摘要
    ↓
用摘要替换旧消息
    ↓
模型继续工作

新的硬切方式是：

javascript 复制代码

旧 context window
    ↓
保存任务状态
    ↓
创建新 context window
    ↓
新窗口读取 notes
    ↓
需要时查询 history

所以，新方案并不是把旧历史直接删除。

它只是让旧历史不再全部出现在模型眼前。

可以把它理解成办公桌：

复制代码

当前正在处理的文件放在桌面上
以前处理过的文件放进档案柜

桌面上的文件变少了，但档案柜里的资料还在。

这和"把所有文件粉碎掉"完全不是一回事。

Codex 到底有没有变化？

目前比较稳妥的结论是：

bash 复制代码

Codex 的公开代码中，确实出现了新的 context window、TokenBudget、notes 和 history 方向。

但不能据此断言所有用户的 Codex 都已经取消了原来的 compaction。

也就是说，比较准确的描述应该是：

Codex 正在尝试从"摘要压缩上下文"发展为"切换工作窗口，并通过外部状态和历史记录恢复任务"的模式。

而不是：

Codex 已经彻底取消上下文压缩。

两者的差别很重要。

因为公开代码中的功能，可能还受到以下因素影响：

复制代码

客户端版本
模型版本
功能开关
账号类型
认证方式
发布节奏

即使代码已经合并，也不代表每个用户马上就能看到相同的行为。

压缩是不是就没用了？

当然不是。

压缩对于重复内容依然非常有价值。

例如：

复制代码

用户：改成蓝色。
Codex：已经改成蓝色。
用户：再亮一点。
Codex：已经调亮。
用户：稍微暗一点。
Codex：已经调整。

这段内容压缩成：

复制代码

最终颜色已调整为合适的蓝色。

通常不会产生问题。

但以下内容最好不要只依赖摘要：

复制代码

精确文件路径
用户的硬性限制
失败过的尝试
测试输出
兼容性要求
明确不能修改的内容
关键工具结果

更理想的设计不是简单地选择"压缩"或"不压缩"，而是让不同的信息各司其职：

bash 复制代码

重复过程可以压缩

当前任务状态写入 notes

完整事实保留在 history

需要细节时再查询原始记录

这种设计有什么好处？

对于短对话，用户可能几乎感觉不到差异。

但对于持续几个小时甚至几天的长任务，这种方式可能更稳定。

以前长任务容易遇到：

复制代码

上下文越来越长
模型遗漏早期要求
摘要丢失关键细节
重复尝试已经失败的方案
后续修改偏离最初目标

新的思路则是：

复制代码

定期换一个干净窗口
保存清晰的任务状态
需要细节时查询完整历史
避免摘要不断叠加损失

它更像是把模型的工作记忆和长期记忆分开。

工作记忆负责：

复制代码

我现在要做什么？
我做到哪一步了？
下一步是什么？

长期记忆负责：

复制代码

之前究竟发生了什么？
用户原话是什么？
某个方案为什么失败？

这比把所有信息都塞进一段摘要里更清晰。

这种设计还有哪些问题？

新方案也不是万能的。

它可能遇到以下问题：

bash 复制代码

notes 没有及时记录
任务状态记录得不完整
模型不知道自己遗漏了什么
history 搜索关键词不准确
查出来的内容太多，再次塞满窗口
错误的 notes 被一直沿用

尤其是"你不知道自己不知道什么"这个问题，很难解决。

如果模型已经忘了某个重要事实，它可能连搜索这个事实的关键词都想不起来。

所以，一份高质量的 notes 非常重要。

"任务进行中"这种记录几乎没有帮助。

更有价值的是：

复制代码

目标是什么
当前进度是什么
做过哪些决定
哪些方案失败了
哪些限制不能违反
下一步是什么

最后总结

Codex 的变化可以这样理解：

旧方式：

markdown 复制代码

上下文快满
    ↓
把旧内容总结成摘要
    ↓
用摘要替换旧消息
    ↓
继续工作

新方向：

bash 复制代码

上下文快满
    ↓
保存当前工作状态
    ↓
创建新的 context window
    ↓
通过 notes 恢复工作集
    ↓
通过 history 查询历史细节
    ↓
继续工作

一句话概括：

以前是把记忆压缩成摘要后继续背，新方案是换一张干净的工作纸，旁边放一本完整档案，需要什么再查什么。

但需要把结论说严谨：

Codex 的公开实现正在尝试这种新的上下文管理方式，但这不等于所有 Codex 用户都已经默认从 compaction 切换到了硬切窗口。

真正值得关注的，不是"压缩功能消失了没有"，而是 AI Agent 的记忆正在从单一的上下文，逐渐变成三层结构：

复制代码

当前上下文：眼前正在处理的事情

工作笔记：当前任务的状态和下一步

历史档案：过去完整发生过的事情

当这三层职责分开之后，模型就不必把所有记忆都背在身上。

它只需要记住眼前要做什么，并且知道去哪里找回那些暂时用不到、但以后可能很重要的内容。