Loading...
Published on 2026-09-08
Codex CLI 抛弃了 compaction：长上下文管理的下一步，不是压缩是切换 你让 Codex 帮你 debug 一个奇怪的并发 bug，它跟你来回 10 轮。第 11 轮你想让它"再看一下第一次报错的 stack trace"，它说："对不起，之前的对话历史已被压缩，无法直接读取。" 这一刻你会意识到：compaction 的本质不是"节省 token"，而是"把对话截断"。它把所有过...
你让 Codex 帮你 debug 一个奇怪的并发 bug，它跟你来回 10 轮。第 11 轮你想让它"再看一下第一次报错的 stack trace"，它说："对不起，之前的对话历史已被压缩，无法直接读取。"
这一刻你会意识到：compaction 的本质不是"节省 token"，而是"把对话截断"。它把所有过去都变成了一段 summary，而 summary 是一种有损的载体——细节、上下文、那个 stack trace，都没了。
2026 年 9 月初，中文社区第一波捕捉到 Codex CLI 把记忆系统从"被动压缩（compaction）"换成了"主动预算（token budget）+ 主动切换上下文"。这件事被 Datawhale 公众号在 2026-09-04 14:12 的一篇解读推到中文读者面前，文章依据"PR 和代码"得出"长上下文管理从'压缩'变成'记忆'"的设计哲学结论1。表面上看，这是一个工程改动；往深看，是长上下文管理这条赛道上"设计哲学"的一次转向。
本文要做的事情很简单：用这次改动当坐标，重新看一遍"长上下文管理到底有哪些路可走"，然后回答两个问题——Codex 为什么放弃 compaction？做自己的 Agent 时这套思路能不能复用？
需要先交代一句：本文主要依据 Datawhale 公众号 9 月 4 日的解读1与一篇中文 AI 工程综述2，没有拿到 OpenAI Codex 仓库的官方 PR 编号或 commit hash。文中涉及的具体工具名（new_context、history、notes、<token_budget>）均来自上述二手转述。
先承认一件事：compaction 不是"坏掉的设计"。它是过去几年所有主流 Coding Agent 的默认兜底——包括 Claude Code 在内。Anthropic 的工程实践是"在摘要基础上额外保留最近访问的 5 个文件"，Anthropic 自己把这种轻量级摘要视为最轻量的 Compaction 策略3。
但 compaction 的设计哲学有一个根本性的取舍：它把"对话"当成一段可以压缩的文本流。压缩意味着丢细节，丢细节意味着模型在下一次推理时拿到的，是一段经过摘要的过去，而不是真正的过去。
这带来三个具体的麻烦4：
这三个问题不是"实现得不够好"，而是压缩这件事本身的代价。无论 LLM 摘要能力多强，丢掉的细节就是丢掉了。这是一道工程数学题，不是工程能力题。
Codex 的新思路可以一句话讲清楚：换一个窗口，但保留记忆1。
它不再压缩历史，而是让模型知道"还剩多少额度"，在合适的时候主动切换到一个新的 context window。切换不是"失忆"——历史记录完整地保存在 history 和 notes 里，随时可以查。
具体怎么实现，被公众号作者拆成了三层5：
<token_budget> 标签，模型在每次请求时都能看到当前 context window 的剩余 token 数。这是"主动管理"的前提。new_context 工具主动请求切换到新的 context window。新窗口被作为 no-summary compaction checkpoint 处理——不压缩历史，直接开新窗口。history 工具可以列出之前的 windows 和 items、读取 items 内容、搜索关键词。notes 工具可以做持久笔记的列出、读取、搜索、追加和写入。三层环环相扣：感知层让模型知道"什么时候该切了"，管理层让模型"能切"，记忆层让模型"切了之后还能找到之前的东西"。
如果你熟悉 RAG 系统，会马上意识到这其实是一回事——更大的 context window 不应该被当作良好 context 管理的替代品，更大的窗口只能暂时掩盖检索与打包的低效6。Codex 没有去"追求无限窗口"，而是把"还剩多少"显式化，让模型自己主动管理。这跟 RAG 工程里"先用粗粒度索引挑候选、再用细粒度内容填上下文"的思路在精神上相通：不把鸡蛋放一个篮子里，先用低成本的检索缩小范围，再把真正相关的内容送进 prompt。
要把这次改动的位置看清楚，得把"长上下文管理"这条赛道先画出来。
业界现有的主流策略，按递进关系可以排成三种2：
这三种是递进关系，不是替代关系。综述把后两种放在更"工程化"的端点上2。
Codex 这次的改动，巧妙之处在于：它把这三种策略做了一次重新组合，而不是发明第四种。
notes 工具做强，等于把"Structured Note-Taking"作为一等公民。换句话说：Codex 没有创造新方法，它只是把行业已有的三件套按"主动 > 被动、完整 > 摘要"的原则重新摆了一次位置。这个重新摆位，才是这次改动的真正价值。
把 compaction 当兜底，本质上是把模型当成"工具"——它只负责当前的请求，过去的事交给我（系统）来处理。
但人不是这样工作的。你 debug 一个 bug 的时候，会翻 commit history、看 git blame、回 IDE 跳到 3 个文件之前改的那一行。人会主动翻历史，不会把过去压缩成一段总结。
Datawhale 公众号的解读作者在文末点出了这件事的设计哲学意义7：
从"被动"到"主动"是重要转变。以前模型是"被动执行"，等系统触发压缩。现在模型"主动知道还剩多少 token，并在合适的时候切换"。这是从"工具"到"伙伴"的角色转变。
这话听着像鸡汤，但落到工程上是有具体含义的：compaction 把"管理记忆"的责任放在系统侧，token budget 把这个责任交给模型自己。责任在哪，能力就在哪长出来。
我自己的看法是，这件事的工程意义被低估了。过去几年 Coding Agent 的体验一直在涨，但涨得快的是模型能力（推理、写代码、跑测试），涨得慢的是"长任务的可控性"。一个 debug 跑到第 50 轮的会话，模型还在不在"记得第 1 轮的报错"——这件事直接决定了 Agent 是真的能跑完一整个开发任务，还是只能做"几个来回就完事"的小修小补。Codex 把"记得多少"从系统黑盒拉到了模型可感知的预算里，这是基础设施级别的动作。
如果你是做 Agent 的人，Codex 这套改动至少有三点可以直接借鉴：
1. 把"剩余额度"显式化。不要让模型对 context window 的剩余空间一无所知。<token_budget> 这个标签的工程意义大于它的字面意义——它把一个原本属于系统黑盒的状态变成了模型可推理的状态。一旦模型知道还剩多少，它就能"提前规划"，这是所有"主动管理"的前提。
2. 让"切换窗口"成为一等操作。不要等窗口满了才被动触发。给模型一个 new_context（或类似名字）工具，让它能主动开新窗口并把当前状态落到 notes / history。注意，新窗口不要顺手做 compaction——一旦 compaction 进了切换路径，模型就会把"切换"当成"压一下再继续"，主动管理就退化成被动管理。
3. 把"持久笔记"做成结构化工具。notes 的关键不是"能写"，而是"能查"。list / read / search / append / write 这五个动词要齐全。模型会主动用 notes 来挂"任务状态 / 已知约束 / 用户偏好"这类不会随窗口切换而消失的信息。
需要提醒的是：这套思路不是"compaction 已死"。Compaction 在某些场景仍然是合理的兜底——比如长 session 的尾巴、模型主动决定"这一段对话不再需要展开了"的时候。Codex 的改动不是消灭 compaction，而是把 compaction 从主路径挪到了边角：主路径是主动切换 + 完整记忆，compaction 只在必要的时候由模型主动触发，而不是由系统定时触发。
长上下文管理这条赛道，过去几年大家默认走 compaction，因为它"够用"。Codex 这次的改动，等于把"够用"的标准提高了——它不是把 compaction 改得更好，而是承认了一件事：压缩是有损的，主动切换 + 完整记忆才是无损的替代。
对做 Agent 的人来说，最值得参考的不是某个具体工具名，而是这套视角的转换：把"管理记忆"的责任从系统侧交还给模型侧。一旦这个责任交出去，模型的角色就从"工具"开始往"伙伴"挪。这是基础设施级别的设计哲学转向，不是某个 PR 的小修小补。
Datawhale《Codex悄悄大改了记忆系统！》，2026-09-04 14:12。https://mp.weixin.qq.com/s?__biz=MzIyNjM2MzQyNg==&mid=2247726158&idx=1&sn=9e31142f87f62815808d9ad4bb85d469 ↩ ↩2 ↩3
《AI工程范式的跃迁，一文讲透Context Engineering》，本地素材库收录，文中"滑动窗口 / Context Compaction / Structured Note-Taking"三种策略的递进关系描述。https://mp.weixin.qq.com/s?__biz=MzA5MTk0NTAzMQ==&mid=2651376010&idx=1&sn=c1d4f9f5f7b0e7b4d4d8c6c5e3a8e9f0 ↩ ↩2 ↩3
《AI工程范式的跃迁，一文讲透Context Engineering》，Claude Code 在 compaction 时保留"最近访问的 5 个文件"，以及"工具调用完成后把原始结果折叠为摘要"作为最轻量 compaction 策略的描述。https://mp.weixin.qq.com/s?__biz=MzA5MTk0NTAzMQ==&mid=2651376010&idx=1&sn=c1d4f9f5f7b0e7b4d4d8c6c5e3a8e9f0 ↩
Datawhale《Codex悄悄大改了记忆系统！》2026-09-04，第一节"先看问题：Compaction 有什么局限？"中关于有损、被动、失忆的三段描述。https://mp.weixin.qq.com/s?__biz=MzIyNjM2MzQyNg==&mid=2247726158&idx=1&sn=9e31142f87f62815808d9ad4bb85d469 ↩
Datawhale《Codex悄悄大改了记忆系统！》2026-09-04，第三节"怎么设计的：Token Budget 的三层架构"，感知层 / 管理层 / 记忆层定义。https://mp.weixin.qq.com/s?__biz=MzIyNjM2MzQyNg==&mid=2247726158&idx=1&sn=9e31142f87f62815808d9ad4bb85d469
freeCodeCamp《How to Handle Small Context Window Limits in RAG Systems》，2026-06-18，文中"larger context window 不应该被当作良好 context management 的替代品"原文。https://www.freecodecamp.org/news/how-to-handle-small-context-window-limits-in-rag-systems/ ↩
Datawhale《Codex悄悄大改了记忆系统！》2026-09-04，第四节"设计哲学：从'压缩'到'记忆'"中关于"从被动到主动、从工具到伙伴"的描述。https://mp.weixin.qq.com/s?__biz=MzIyNjM2MzQyNg==&mid=2247726158&idx=1&sn=9e31142f87f62815808d9ad4bb85d469 ↩