我对这个变化其实挺期待的。但先说明一下目前我能查到的 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 上下文了。这可能才是“外部记忆”真正有意思的地方。
怎么看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 上下文了。这可能才是“外部记忆”真正有意思的地方。