怎么看OpenAI 的 Codex 将取消上下文压缩，换成「硬切窗口 」和「外部记忆」？

我对这个变化其实挺期待的。

但先说明一下，目前我能查到的 Codex 官方公开代码里，自动 context compaction 还存在，官方之前也专门介绍过这套机制：上下文快满以后，把前面的历史压缩，再拿压缩后的内容继续跑。与此同时，Codex 的 Memories 已经做得越来越完整，包括 memory_summary.md、MEMORY.md、历史任务摘要这些东西。

所以网上说的“取消上下文压缩，改成硬切窗口+外部记忆”，我目前更愿意理解成 Codex 正在往这个方向演进，而不是今天更新 Codex，压缩机制就已经没了。

但这个思路，我觉得是对的。

我之前一直觉得 AI 编程里面“上下文压缩”这个设计有点像没办法的办法。

比如你让 Codex 连续干几个小时：

先看项目结构，改登录模块，跑测试，发现数据库有问题，然后又去改 migration，中间你告诉它“这个接口千万别动，因为线上还有旧客户端在调用”。

干着干着上下文满了。

Codex 开始 compact。

压完之后表面上它还记得这个任务在干什么，但是那种感觉很微妙。项目的大方向一般还在，很多小细节开始丢。

尤其是这种：

“为什么当时没有采用方案 A？”

“这个文件之前已经试过修改，但是会导致测试挂掉。”

“这里看起来像 bug，其实为了兼容旧版本故意这么写。”

这些东西特别容易在压缩的时候变成一句很模糊的话。

然后过几十分钟，你会发现 Codex 又兴冲冲地把之前失败过的方案重新试了一遍。

这种情况我遇到的时候是真的挺烦。

你跟一个程序员合作，他忘了一两个细节还能问你。AI 更麻烦的地方是，它忘了以后很多时候自己并不知道自己忘了。

它会非常自信地继续干。

这也是我觉得“硬切窗口”反而可能比压缩舒服的地方。

假设上下文只能保留最近 200K、300K token，那就老老实实只保留最近这些。

前面的东西掉出去就掉出去。

但是，把真正值得长期保留的东西单独放进 Memory。

比如：

这个项目用什么技术栈。

哪些目录不要碰。

之前踩过什么坑。

用户长期的编码习惯。

某个架构为什么这么设计。

哪些方案已经试过并失败。

下一次需要的时候，再从外部记忆里找回来。

这种方式其实更像人干活。

我现在脑子里不会一直装着三个月以前某个项目的全部聊天记录。我只会记住“大概发生过什么”，需要细节的时候去翻 Git、文档、issue、笔记。

Codex 现在的 Memories 其实已经有这个味道了。它会维护一个比较精简的 memory_summary.md，更详细的信息放在 MEMORY.md，再往下还有每次任务的 rollout summary。官方代码里的描述甚至明确要求 memory summary 保持高信息密度，详细内容需要的时候再往下找。

这和把几十万 token 的历史对话硬塞进模型，我觉得已经是两种思路了。

一个是：

“我把以前发生过的事情全部带着。”

另一个是：

“我知道以前发生过事情，而且知道去哪里找。”

对于 Coding Agent，我反而更看好第二种。

因为还有一个很多人容易忽略的问题：上下文不是越长越好。

现在大家看到 1M context，很容易产生一种感觉——那我直接给 Codex 100 万 token 不就完事了吗？

Codex 社区里确实有人这么干，把 GPT-5.6 Sol 的 context 配到 1M，然后把自动压缩阈值开到 900K。

爽不爽？

当然爽。

一个大项目能塞进去很多东西。

但代价也挺明显。

Agent 每调用一次模型，都可能带着一个越来越肥的上下文。尤其 Codex 这种疯狂调用工具、读文件、跑测试的工作方式，一个任务几十次甚至上百次 sampling 很正常。

有人分析 Codex 长线程时就发现，平均 prompt 从十几万 token 涨到二十多万 token 后，即使模型调用次数更少，总 input token 都可能明显增加。

所以我现在越来越觉得，以后 Coding Agent 拼的可能不是“谁能塞 200 万 token”。

而是谁更会管理上下文。

最近正在做什么，放工作窗口。

长期规则，放 Memory。

项目事实，需要的时候检索。

历史操作，留日志。

真正相关的东西再拿回来。

这个架构听起来没“百万上下文”那么性感，但长期跑 Agent，大概率更实用。

不过我也不觉得“外部记忆”一定就比压缩好。

这里面最大的坑其实是：你怎么保证它想起来的是对的东西？

比如我半个月前告诉 Codex：

数据库现在是 MySQL。

后来项目迁移 PostgreSQL 了。

Memory 里面如果还留着“MySQL”，结果下一次 Codex 搜记忆的时候刚好把旧信息翻出来，那就很热闹了。

还有更麻烦的：

Codex 做某个 bug 时得出了一个错误结论，然后这个错误结论被写进 Memory。

以前上下文满了，这个错误信息最终可能自然消失。

现在变成“长期记忆”以后，它可能隔三天又被翻出来继续坑你。

而且这已经不完全是理论问题了。Codex 现在的 Memories 还是比较新的系统，GitHub 上已经有人反馈 memory 生成时遇到超长 transcript 导致 context window 报错，也有人反馈部分历史任务没有成功进入长期记忆。

所以这个方向最后好不好用，我觉得不取决于“硬切”两个字。

主要看 Memory 能不能做到三件事：

该记的真的记住。

过时的能更新。

需要的时候能准确找回来。

这三件事如果做好，我甚至愿意接受更小一点的实时上下文窗口。

因为写大型项目最烦的从来不是 Codex 忘了三小时前终端里打印了哪 200 行日志。

那种东西重新跑一次就行。

最烦的是它忘了：

“我们为什么这么改。”

“之前哪些路已经走不通了。”

“这个项目有哪些不能碰的约束。”

如果外部记忆能把这些东西保存得比较靠谱，我觉得比单纯把 context 从 300K 堆到 1M，价值可能还大。

当然还有一个我比较现实的猜测。

OpenAI 推这种架构，多半也有成本考虑。

一直维持巨大的 active context 太贵了。Codex 又不是普通聊天，它会连续调用模型、工具、shell、文件搜索，一轮任务下来重复读取的 token 很夸张。

把工作窗口控制住，把历史信息放进便宜得多的检索和 Memory，需要的时候再拿出来，对 OpenAI 成本肯定舒服很多。

这点我倒不觉得有什么问题。

只要最终效果更好，我其实不太在乎 OpenAI 顺便省了多少 GPU。

我现在比较担心的是另一种情况：

为了省 context，把窗口切得很狠，但 Memory 又还没成熟。

那使用体验可能会变成——

以前 Codex 是干久了以后“慢慢失忆”。

以后变成突然失忆，然后翻笔记还翻错了。

那就有点灾难了。

所以我目前对这个变化大概是六七分期待，三四分观望。

方向我是认可的。

Coding Agent 真想连续工作几小时、几天，甚至以后自己维护一个项目，靠无限扩上下文肯定走不远。把“眼前正在想的东西”和“以前知道的东西”分开，应该迟早都会走这条路。

只是 Codex 的 Memory 现在还得继续打磨。

如果有一天我开一个三个月没碰的项目，跟 Codex 说一句：

“接着上次那个支付问题继续。”

它自己能找到当时改了什么、为什么这么改、哪些方案已经排除，然后直接开始工作。

到那个时候，我可能根本不会关心它到底是 200K、500K 还是 1M 上下文了。

这可能才是“外部记忆”真正有意思的地方。