AI CLI 的上下文压缩，正在成为全行业的质量洼地

如果你长期开着 Claude Code 或 Codex 干活，最近可能遇到过一种情况：会话开到一半，模型突然"失忆"了——之前商量的方案、做过的决定、读过的文件，它都不记得了。检查日志，只看到一行"Compacted while idle"。这不是你的配置问题。近几个月，多款主流 AI CLI 工具先后暴露出上下文压缩（compaction）问题，它正在成为这个行业共同的质量洼地。

Claude Code：空闲时静默压缩，无法关闭

有开发者在 Claude Code 仓库提交了 issue #98747，标题直指要害：2.1.286 版本起，空闲会话会在提示词缓存过期前被自动压缩，没有开关，没有预告，日志里还记成"manual"——也就是把一次系统自动执行的操作，标注成了用户手动触发。

报告者描述了自己的工作形态：大约 20 个 Claude Code 会话并行开在长期项目上，每个会话累积几小时的工作上下文——给过的精确指令、决策及其理由、商定的方法。空闲压缩一来，这些 grounding 被整体丢弃。这位用户建议压缩应保持用户触发，或者至少 opt-in、提前告知，除非真的撞上上下文上限的紧急情况。从他不得不从磁盘转录手工重建上下文来看，这类静默压缩对长期会话用户的代价是实打实的。

报告者还发现两个附带问题：这些空闲压缩在转录里被记成 compactMetadata.trigger 为 manual——用户从未运行 /compact，自动操作和手动操作在日志里无法区分；PreCompact 钩子是否对空闲压缩生效也没有文档确认。压缩的时机、过程和可观测性，用户既看不见也管不了。

Codex：图片载荷无限保留，压缩变成死循环

OpenAI Codex 的问题形态不同。issue #33493 报告：一个长期运行、图片密集的 Codex Desktop 线程会进入"反复自动压缩"的循环——一次压缩完成后，剩下的历史只是略微低于自动压缩阈值，很快又触发下一轮。根因是本地压缩 v2 保留了无边界的 input_image 载荷：文字被压缩了，图片原样留着，上下文根本压不下去。

对截图驱动的工作流（前端还原、UI 调试、设计走查）来说，这意味着会话越用越卡，压缩日志刷屏，而实际可用上下文没有增加。

为什么压缩这么难做好

这两家的案例指向同一个工程矛盾：压缩本质是"有损摘要"，而哪些信息是"关键"取决于任务，不取决于算法。模型不知道你半小时后还要引用那份配置文件，摘要器自然可能把它压掉。厂商在"自动压缩保护上下文上限"和"用户可控保留工作记忆"之间摇摆，每个版本都在移动默认值——Claude Code 2.1.286 把默认值移向自动压缩，社区随即提出 issue 反馈。报告者的原话说得很清楚：对这种工作方式，这笔交易是反的——上下文才是有价值的部分，缓存重读的成本是他乐意付出以保住上下文的。

开发者现在能做什么

在厂商解决之前，有实际经验可循：

把长任务的 grounding 外置。 不要依赖会话记忆承载关键决策。项目级 CLAUDE.md、AGENTS.md 或工作区内的决策日志，比会话上下文可靠——压缩动不了磁盘文件。会话开始时让模型重读这些文件，比赌它"还记得"更稳。

对图片密集任务主动清理。 用 Codex Desktop 跑截图工作流时，定期开新线程，而不是让一个线程积累几十张图。#33493 的触发条件就是图片载荷堆积。

升级前查一次压缩行为变更。 这轮问题的共同教训是：压缩默认值属于"静默变更"——不写在显眼功能列表里，却在最关键的时刻改变行为。Claude Code 2.1.286 的自动压缩就是版本升级后突袭的。重度用户升级前扫一眼 release note 里的 compaction 相关条目，是低成本保险。

留一条可核对的产物链。 不少被压缩影响过的开发者会养成一个习惯：让模型把每步结论写进文件。文件在，上下文丢了也能恢复。这不只是为了防压缩，也是所有长任务协作的基本功——“接口有回复"和"任务完成"之间，隔着一个可核对的产物。

压缩问题不会很快消失。只要上下文窗口还是稀缺资源、摘要还是有损操作，这个洼地就会存在。但对单个开发者来说，损失是可控的：关键记忆放磁盘，长会话勤分段，升级前看变更。工具在进步，但你的工作记忆不该押在工具的进步上。