Claude Code：官方推荐/compact主动压缩上下文、/rewind回退、/clear重开，但社区反馈自动压缩经常在任务做到一半时把关键中间状态“总结丢”，手动管理上下文和信任自动压缩之间的边界到底该怎么划？

一、问题的真实形态：不是“丢信息”，而是“丢状态”

社区里关于 Claude Code 自动压缩的抱怨，措辞高度一致：“任务做到一半，它把我前面确认过的关键细节总结没了。”如果只把这理解为“摘要模型能力不足”，就会导向一个错误的解法——换更强的摘要模型。但实际观察到的失败模式更具体：模型并没有忘记“我们在做一个登录重构”，它忘记的是“用户已经明确否决了 JWT 方案、数据库字段名已定为 session_token_v2、迁移脚本必须幂等”。

这三类信息有一个共同点：它们是被外部世界（用户、代码库、数据库）确认过的事实，而不是模型推理过程中的中间想法。摘要模型在压缩时，倾向于保留“叙事连贯性”——谁在做什么、目标是什么——而牺牲“约束清单”。这在人类写会议纪要时是合理的取舍，在 Agent 执行任务时却是致命的，因为约束清单恰恰是后续每一步动作的合法性依据。

本文评述：把“上下文压缩”类比为“无损/有损压缩”是误导性的。信息论意义上的有损压缩有明确的率失真函数，可以量化“在给定失真下最小码率”；而 LLM 摘要的“失真”没有统一度量，摘要模型并不知道下游任务需要哪些比特。因此工程上不能指望“更好的压缩算法”，只能改变被压缩对象的构成——先把不可丢的状态搬出上下文，剩下的才允许被自由压缩。

这条判断构成了全文的分析主线。后文所有机制拆解、方案设计与度量指标，都服务于同一个目标：让压缩只作用于“叙述”，让“状态”活在压缩之外。

二、背景：上下文窗口作为稀缺资源与三条官方路径

2.1 上下文窗口的稀缺性从何而来

Transformer 的自注意力计算复杂度随序列长度呈二次增长，这是架构层面的硬约束；即便工程上通过 FlashAttention 系列工作把显存占用从 O(n²) 降到接近线性，推理延迟与成本仍随上下文长度上升。Anthropic 在 2023 年提出的“Lost in the Middle”现象（Liu et al., 2023）进一步指出：当关键信息位于长上下文中部时，模型利用率显著下降。这两点共同说明——上下文不是“越长越好”的免费资源，而是有边际收益递减的昂贵资源。

Claude Code 作为终端内的编码 Agent，其上下文消耗速度远高于普通对话：一次文件读取可能注入数百行代码，一次测试运行可能带回完整堆栈，一次多文件搜索可能返回几十条匹配。一个中等规模的重构任务，几十轮工具调用就能把窗口推到高位。因此上下文管理不是“优化项”，而是“可用性前提”。

2.2 三条官方路径的定位

根据 Anthropic 官方文档与 Claude Code 的公开说明，三条命令的定位可以概括为：

三者并非同一维度的替代品：/compact 作用于“信息密度”，/rewind 作用于“时间轴”，/clear 作用于“会话边界”。把它们混为一谈，是很多误用的起点。

官方文档对 /compact 的说明可以在 Anthropic 的 Claude Code 文档中查阅（docs.anthropic.com/en/docs/claude-code），其中也提到了自动压缩（auto-compact）机制：当上下文接近上限时，系统会自动触发压缩。社区争议正集中在这个“自动”上。

三、机制拆解：三条命令到底做了什么

3.1 /compact：一次有损的、面向叙述的重写

压缩的本质是：把 n 轮消息序列 M = [m₁, m₂, …, mₙ] 映射为更短的序列 M' = [s, mₖ₊₁, …, mₙ]，其中 s 是对前 k 轮生成的摘要。关键点在于：摘要 s 由模型生成，其内容选择遵循的是“读起来像一份好总结”的目标，而不是“支撑后续动作”的目标。

这与检索增强生成（RAG）中的查询重写有本质区别。RAG 的重写目标是“召回相关文档”，有明确的检索信号可以优化；而对话摘要没有下游监督信号，摘要模型无法知道下一步会调用哪个工具、需要哪个字段名。Gao et al. (2023) 在 RAG 综述中系统梳理了查询重写与上下文压缩的多种策略，但同样指出：压缩质量高度依赖任务定义，通用摘要并不保证任务保真。

笔者认为：把 /compact 理解为“对话历史的 zip 压缩”是危险的。它更接近“让一个没参与过会议的人写会议纪要”——他会保留议题和结论，但很可能漏掉“张工说这个字段名不能再改”这类约束。任务越依赖细粒度约束，摘要的保真风险越高。

3.2 /rewind：检查点回滚，作用于时间轴而非信息密度

/rewind 的机制更接近版本控制中的“回到某个 commit”。它依赖系统在会话过程中建立的检查点（checkpoint），回退后不仅对话历史回到该点，代码状态也一并恢复。这一点在 Claude Code 的公开说明中有体现，也是它与纯对话回退的关键差异。

从工程角度看，/rewind 的价值在于它不丢信息，只丢时间。你放弃的是检查点之后的所有改动，但检查点之前的状态是完整保留的。这与 /compact 恰好相反：后者保留时间连续性，但牺牲信息完整性。

这个对称性非常重要，它意味着两条路径可以组合：当压缩已经发生且发现关键状态丢失时，/rewind 是唯一能真正“找回”的路径（前提是丢失的状态发生在某个检查点之前且该检查点未被覆盖）。而如果状态从未被写入任何检查点，/rewind 也救不了你。

3.3 /clear：会话边界重置

/clear 是最“暴力”也最容易被低估的路径。它的作用不是压缩，而是切断因果链。当上下文已经被错误假设污染——比如模型坚信某个 API 存在，而实际上不存在，并且这个错误假设在后续多轮中被反复引用——此时任何压缩都只会把错误假设“固化”进摘要。唯一干净的解法是重开。

但 /clear 的代价是全部上下文归零，包括那些本来还有用的约束。因此它适合的场景是“任务切换”或“上下文污染已不可局部修复”，而不是“上下文快满了”。把 /clear 当作省 token 的手段，是典型的误用。

四、失效分析：自动压缩为何常在任务中途“总结丢”

4.1 触发时机与任务阶段的不匹配

自动压缩的触发条件是“上下文接近上限”，这是一个资源信号，不是任务信号。而任务是否处于“可以安全压缩”的阶段，取决于任务本身的语义结构。一个重构任务通常包含：需求澄清 → 方案选型 → 接口约定 → 分文件实现 → 测试修复。其中“接口约定”阶段产生的约束（字段名、函数签名、错误码）是后续所有实现的依赖，而“分文件实现”阶段产生的叙述（读了哪些文件、改了哪几行）大部分是可再生的。

问题在于，资源信号可能在任意阶段触发。如果恰好在“接口约定”刚完成、实现尚未开始时触发压缩，摘要模型很可能把“字段名定为 session_token_v2”压缩成“确定了会话 token 方案”——信息量看似保留，可执行性却已丢失。

4.2 摘要目标与执行目标的错位

更根本的原因在 3.1 节已经点出：摘要模型的优化目标是“生成一段连贯、覆盖主要内容的总结”，而 Agent 执行的目标是“在下一步动作中不违反任何已确认约束”。这两个目标在多数情况下重合，但在关键约束上会分叉。

可以用一个简化的信息论视角来刻画：设任务继续所需的信息为 I_task，摘要保留的信息为 I_summary。压缩的风险不在于 |I_summary| 小，而在于 I_task \ I_summary 非空，且其中包含高权重的约束项。由于摘要模型无法观测 I_task 的定义，这个差集无法被它主动最小化。

本文评述：这解释了为什么“换更强的模型做摘要”收效有限。更强的模型能写出更好的总结，但它依然不知道你的下一步动作需要哪个字段名。除非把“下游需要什么”作为条件注入摘要过程——而这恰恰是工程侧可以做的事，也是第六节方案的理论依据。

4.3 一个可复现的失败模式

下面是一个典型的失败序列（基于公开社区讨论归纳，非特定用户数据）：

轮次 12: 用户确认 "错误码统一用 E_ 前缀，不要用 ERR_"
轮次 13-20: 模型读取 8 个文件，逐个修改错误处理
轮次 21: 上下文接近上限，自动压缩触发
轮次 22: 模型新增一个错误码，写成 ERR_TIMEOUT
          → 违反轮次 12 的约束，但约束已在摘要中丢失

注意失败点：模型并没有“忘记自己在做什么”，它忘记的是一条否定性约束。否定性约束（“不要用 X”）在摘要中天然容易被弱化，因为它们在叙述上不构成“进展”。这是摘要偏差的一个结构性来源，值得单独强调。

五、主线：状态与叙述的分离原则

5.1 定义：什么是“状态”，什么是“叙述”

为了把这条主线讲清楚，需要给出可操作的定义：

判据是“可验证性”：如果一条信息能通过运行命令、读取文件、查询数据库来独立确认，它就是状态；如果它只存在于对话历史中、且重新获取的成本可接受，它就是叙述。

5.2 为什么这条分离能解决问题

回到第 4 节的信息论刻画。如果状态已经被外置为工件（文件、schema、测试用例），那么即使摘要丢失了“字段名是 session_token_v2”，模型在下一步动作前仍会读取该工件，从而恢复约束。此时 I_task \ I_summary 中高权重的部分被外部存储兜底，压缩的“失真”不再致命。

换句话说，压缩的风险与上下文中“不可再生信息”的占比成正比。把不可再生信息搬出去，压缩就从“危险操作”降级为“常规维护”。

笔者认为：这条原则与软件工程中的“单一事实来源”（Single Source of Truth）同构。对话历史不应该成为任何约束的唯一载体——正如配置文件不应该成为唯一文档。Agent 上下文治理的成熟标志，是从“管理对话”转向“管理工件，对话只是工件的投影”。

5.3 与已有研究的呼应

这条思路在学术上并非孤立。MemGPT（Packer et al., 2023）提出把上下文窗口类比为操作系统的内存层级，用“主上下文 + 外部存储”的分层来突破窗口限制；其核心机制正是把不常用的信息换出到外部，需要时再换入。Generative Agents（Park et al., 2023）则用“记忆流 + 检索 + 反思”的结构管理长期行为一致性。这些工作共同支持一个判断：上下文管理的本质是存储层级设计，而不是摘要算法选择。

本文的差异在于把“状态/叙述”的区分显式化，并把它落到具体命令（/compact、/rewind、/clear）的操作决策上，而不是停留在架构层面。这也是后文方案设计的出发点。

六、工程方案：分层压缩 + 检查点 + 工件外置

6.1 三层结构

把上下文治理拆成三层，每层有独立的职责与失效模式：

这个结构的关键不在表格本身，而在于写入时机：L1 与 L2 的写入必须发生在“约束被确认的那一刻”，而不是等到压缩前再补。因为压缩前补写，你依赖的仍然是可能已经失真的上下文。

6.2 工件外置的具体做法

在仓库根目录维护一个轻量目录，例如 .agent/，包含：

• .agent/constraints.md：所有否定性与肯定性约束，逐条编号，带确认轮次。
• .agent/decisions.md：方案取舍与理由，只追加。
• .agent/checkpoints.md：记录每次 /rewind 可用检查点的语义标签（“接口约定完成”“迁移脚本通过”）。

这些文件由 Agent 在关键节点主动写入，也可由用户在确认约束后手动补一行。它们不参与 /compact，因为它们是文件，不是对话消息。Agent 在每次进入新阶段前读取它们，成本极低。

6.3 检查点策略

检查点的价值取决于粒度与语义标签。建议在以下节点显式建立检查点：

1. 需求澄清结束、方案选型开始前；
2. 接口约定完成、批量实现开始前；
3. 每完成一个可独立验证的子任务（测试通过）；
4. 任何一次大规模重构前。

第 2 条尤其关键：它是“约束已确定但尚未被大量叙述淹没”的黄金时刻。此时建立检查点，即使后续压缩丢失约束，/rewind 也能回到这个干净状态。

本文评述：检查点不是越多越好。过密的检查点会增加认知负担，且回退时的“选择成本”上升。经验上，一个中等任务 4-6 个语义检查点足够。这与版本控制中“有意义的 commit”原则一致——提交的价值在于语义边界，而非频率。

七、操作路径：从触发阈值到回滚决策的完整步骤

7.1 手动优先于自动的阈值设定

自动压缩的问题在于“你无法选择时机”。一个务实的做法是：在自动触发之前，主动在语义边界处执行 /compact。具体阈值可以这样设定（以相对窗口占比计，具体数值需按模型窗口调整）：

注：上述阈值为工程经验值，非官方推荐，需按实际模型窗口与任务类型调整。

7.2 回滚决策树

当发现关键状态丢失时，按以下顺序判断：

状态丢失？
├─ 丢失项在 L1/L2 工件中？
│   ├─ 是 → 读取工件恢复，无需回滚
│   └─ 否 → 继续
├─ 丢失项发生在某个检查点之前？
│   ├─ 是 → /rewind 到该检查点，重新推进
│   └─ 否 → 继续
├─ 上下文是否已被错误假设污染？
│   ├─ 是 → /clear，从工件重建上下文
│   └─ 否 → 手动补充约束，继续推进

这个决策树的核心思想是成本递增：先尝试最便宜的恢复（读工件），再尝试中等的（回退），最后才是最贵的（重开）。很多团队的问题在于跳过第一步，直接 /clear，导致大量可复用上下文被浪费。

7.3 一个可执行的日常节奏

把上述规则固化为节奏，比记住规则更有效：

1. 开工前：读取 .agent/constraints.md 与 .agent/decisions.md，把当前约束注入首轮提示。
2. 每个子任务完成时：追加决策记录，建立语义检查点。
3. 窗口过半时：在下一个语义边界主动 /compact，而不是等自动触发。
4. 发现约束被违反时：先查工件，再决定是否 /rewind。
5. 任务切换时：/clear，但先把工件补齐。

关于 Claude Code 的具体命令用法，官方文档是最可靠的来源；社区也有不少实操教程可供参考，例如 Anthropic 的工程博客（anthropic.com/engineering）以及 Claude Code 的 GitHub 仓库讨论区（github.com/anthropics/claude-code）。视频类教程可参考 YouTube 上关于 Claude Code 工作流的公开分享（YouTube 检索页），但需注意版本差异，以官方文档为准。

八、度量与验证：如何证明你的上下文治理有效

8.1 三个可观测指标

治理效果不能靠“感觉顺畅”来判断，需要可观测指标。以下三个指标成本低、信号强：

其中“约束违反率”是最直接的指标。建议在任务结束后做一次轻量复盘：把 diff 与 .agent/constraints.md 逐条比对，记录违反项。这个动作本身也会反向推动约束写得更好。

8.2 一个对照实验设计

如果想更严格地验证，可以设计小型对照实验（模拟数据示例，非真实实验）：

组 A：仅依赖自动压缩，不维护工件
组 B：维护 L1/L2 工件 + 语义检查点 + 手动 /compact
任务：同一组 10 个中等规模重构任务（可重复执行）
度量：约束违反率、任务完成轮次、回退次数
预期：B 组约束违反率显著低于 A 组，轮次差异不显著

说明：上述为实验设计示例，非实际运行数据。真实结论需以实际运行结果为准。

笔者认为：“轮次差异不显著”是这套方案能否被团队接受的关键。如果维护工件显著增加了轮次，工程上就不可持续。经验上，工件的写入成本很低（每阶段几行），而它带来的恢复收益远大于成本——但这需要用你自己的任务分布去验证，而不是照搬结论。

九、对比与局限：三条路径的适用边界

9.1 路径对比

9.2 方案的局限

必须诚实指出这套方案的边界：

• 工件维护有纪律成本。它依赖人或 Agent 在正确时机写入。如果团队没有形成习惯，工件会退化为“事后补写的文档”，失去兜底价值。
• 并非所有状态都可外置。有些约束是隐性的、难以形式化的（例如“这个模块的风格要保守一点”）。这类信息仍只能留在上下文里，压缩风险无法完全消除。
• 检查点依赖系统实现。/rewind 的可用性、粒度、是否包含代码状态，取决于 Claude Code 的具体版本与配置，不同版本可能有差异，需以官方文档为准。
• 指标采集需要额外工程。约束违反率的复核是人工的，规模化时需要自动化比对工具。

本文评述：承认局限比宣称“彻底解决”更有价值。这套方案的目标不是“让压缩无损”——那不可能——而是“让压缩的损失落在可恢复的范围内”。这是一个工程上可达成、可度量的目标，而不是一个理论上的完美解。

十、前沿预判与结论

10.1 三个可预期的演进方向

方向一：条件化摘要。如果摘要过程能接收“下游任务类型”作为条件，摘要模型就能优先保留与该任务相关的约束。这在技术上可行（把任务描述作为摘要提示的一部分），但需要产品层面暴露接口。目前 Claude Code 的 /compact 是否支持自定义压缩指令，需以官方文档为准；社区已有用户尝试在压缩前用提示引导保留要点，效果因任务而异。

方向二：结构化记忆。MemGPT 式的分层记忆正在从研究走向工程。未来的编码 Agent 很可能内置“约束存储”与“决策日志”，而不是依赖用户手工维护 .agent/ 目录。Cognition 等团队在 Agent 记忆方面的公开讨论也指向这个方向。

方向三：压缩可审计。当前压缩是黑箱：你不知道摘要丢了什么。如果系统能输出“压缩前后差异报告”（哪些实体、约束、数字被保留/丢弃），用户就能在压缩后快速校验。这在工程上不难，难的是产品取舍。

10.2 结论

回到最初的问题：手动管理上下文与信任自动压缩之间的边界该怎么划？本文给出的答案是——边界不划在“压缩 vs 不压缩”上，而划在“状态 vs 叙述”上。状态外置、检查点兜底、叙述交给压缩，三者各司其职。自动压缩不是敌人，它只是不该成为状态的唯一载体。

具体到操作：窗口过半时在语义边界主动 /compact；关键约束在确认时立即写入工件；每个可验证子任务完成时建检查点；发现状态丢失时按“读工件 → /rewind → /clear”的成本递增顺序处理。这套流程不追求零损失，只追求损失可恢复、可度量、可复盘。

最后需要强调：Claude Code 仍在快速迭代，命令行为、自动压缩策略、检查点机制都可能变化。本文的机制描述基于公开文档与社区讨论，具体行为请以你所用版本的官方文档为准。方法论层面的结论——状态与叙述分离——则不随版本变化，它是上下文工程的一个稳定原则。

主要参考文献