Codex CLI 抛弃了 compaction：长上下文管理的下一步，不是压缩是切换

Codex CLI 抛弃了 compaction：长上下文管理的下一步，不是压缩是切换

你让 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 和代码"得出"长上下文管理从'压缩'变成'记忆'"的设计哲学结论¹。表面上看，这是一个工程改动；往深看，是长上下文管理这条赛道上"设计哲学"的一次转向。

本文要做的事情很简单：用这次改动当坐标，重新看一遍"长上下文管理到底有哪些路可走"，然后回答两个问题——Codex 为什么放弃 compaction？做自己的 Agent 时这套思路能不能复用？

需要先交代一句：本文主要依据 Datawhale 公众号 9 月 4 日的解读¹与一篇中文 AI 工程综述²，没有拿到 OpenAI Codex 仓库的官方 PR 编号或 commit hash。文中涉及的具体工具名（new_context、history、notes、<token_budget>）均来自上述二手转述。

一、compaction 不是坏设计，但它注定丢东西

先承认一件事：compaction 不是"坏掉的设计"。它是过去几年所有主流 Coding Agent 的默认兜底——包括 Claude Code 在内。Anthropic 的工程实践是"在摘要基础上额外保留最近访问的 5 个文件"，Anthropic 自己把这种轻量级摘要视为最轻量的 Compaction 策略³。

但 compaction 的设计哲学有一个根本性的取舍：它把"对话"当成一段可以压缩的文本流。压缩意味着丢细节，丢细节意味着模型在下一次推理时拿到的，是一段经过摘要的过去，而不是真正的过去。

这带来三个具体的麻烦⁴：

1. 有损。一段 10 轮的调试对话被压缩成三句话，中间那个变量名、那个报错信息、那个 stack trace，就消失了。
2. 被动。模型不知道当前 context window 还剩多少 token，它只能等系统触发压缩。它无法提前规划，也无法在合适的时机主动整理上下文。
3. 回溯困难。压缩后的历史变成了一段 summary，想回看细节的代价变高。

这三个问题不是"实现得不够好"，而是压缩这件事本身的代价。无论 LLM 摘要能力多强，丢掉的细节就是丢掉了。这是一道工程数学题，不是工程能力题。

二、Codex 的替代方案：换一个窗口，但保留记忆