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

一、导语：一个被反复复现的失效现场

先描述一个在开发者社区里高频出现的场景。一个多步骤重构任务进行到第 40 轮左右，上下文窗口逼近上限，系统自动触发压缩。压缩摘要写得很“漂亮”：“用户要求重构鉴权模块，已确认使用 JWT，讨论了若干方案，正在实现中。”看起来信息完整，但真正关键的东西没了：用户在第 12 轮明确否决了把 token 放在 localStorage 的方案、第 23 轮定位到的一个 refresh 竞态条件、第 31 轮确定的错误码约定。模型随后在第 41 轮“自然地”把 token 又写回了 localStorage，并重新引入了一个已经被排除的竞态。

这不是模型能力问题，而是压缩策略与任务阶段错配的问题。压缩算法本身没有错，它忠实地执行了“用更少的 token 表达更多信息”的目标；错的是触发时机与保留准则——它把“已否决方案”“已定位缺陷”“已确认约束”这类负向状态和边界状态当成了可省略的过程性叙述。

本文的核心判断是：上下文条目的价值密度不是均匀的，而是随任务阶段强非平稳地变化。任何“按固定比例、固定触发点”执行的自动压缩，都会在某些阶段踩中高价值窗口，造成不可逆的信息塌缩。手动管理与自动压缩的边界，本质上不是“信不信任模型”的问题，而是“压缩触发点是否与任务阶段对齐”的问题。

这条主线将贯穿全文：先定义三种命令背后的治理哲学，再引入状态价值密度这一分析工具，随后拆解失效机理、给出边界判定指标、设计检查点与回退机制、组装混合治理流程，最后用公开实践与可验证观察做交叉检验，并讨论局限与展望。

二、背景与问题定义：三条命令背后的三种治理哲学

2.1 三条命令的准确定义

在讨论边界之前，需要先把概念钉死。不同产品对这三条命令的实现细节不同，但语义骨架高度一致：

三者对应三种治理哲学：/compact 是“有损压缩”，赌的是摘要能保留足够信息；/rewind 是“时间旅行”，赌的是检查点足够密、回退代价可接受；/clear 是“断舍离”，赌的是新会话能更快重建必要状态。三者没有绝对优劣，只有与任务形态的匹配度差异。

2.2 问题的精确定义

社区反馈的“总结丢”可以形式化为：设任务在时刻 t 的真实状态为 S(t)，压缩算子 C 作用于历史 H 得到摘要 C(H)。若存在某个关键状态分量 s_k ∈ S(t)，使得 s_k 在 C(H) 中不可恢复，且 s_k 对后续决策 D(t+1) 有因果影响，则称发生状态塌缩。问题不在于 C 是否有损（必然有损），而在于C 的保留准则是否与 s_k 的价值分布对齐。

这里需要区分两类状态：正向状态（已确认的目标、已选定的方案、已完成的步骤）与负向/边界状态（已否决的方案、已排除的假设、已定位的缺陷、硬约束）。前者在摘要中天然容易被保留，因为它们“看起来像结论”；后者恰恰最容易被当作“过程叙述”省略，却对后续决策有最强的排除性约束力。

本文评述：把“总结丢”归因于“模型总结能力不足”是一种常见的误诊。即便摘要质量很高，只要保留准则偏向正向结论、忽略负向约束，塌缩依然发生。因此改进方向不应只停留在“让摘要写得更好”，而应转向“让压缩决策感知任务阶段与状态类型”。

三、分析主线：状态价值密度与任务阶段的非平稳性

3.1 状态价值密度的定义

定义上下文条目 e 在任务阶段 φ 下的状态价值密度 ρ(e, φ) 为：单位 token 的 e 对后续决策正确性的期望贡献。形式化地，若后续决策序列为 D，正确性损失函数为 L，则

ρ(e, φ) = E[ ΔL(D | H) − ΔL(D | H \ {e}) ] / |e|

其中：
  H       当前完整历史
  H \ {e} 移除条目 e 后的历史
  |e|     条目 e 的 token 数
  ΔL      决策正确性损失的变化量
  φ       任务阶段（探索 / 收敛 / 执行 / 收尾）

这个定义是操作性的而非纯理论的：它把“这条信息值不值得留”转化为“移除它会让后续决策变差多少”。工程上无法精确计算期望，但可以用代理指标近似（见第五节）。关键在于 ρ 对 φ 的依赖——同一类条目在不同阶段的价值密度可以相差一个数量级。

3.2 任务阶段的划分与价值分布

把长任务粗分为四个阶段，可以观察到价值密度的显著漂移：

这张表解释了为什么“执行阶段触发压缩”最危险：执行阶段恰恰是中间态最密集、且这些中间态尚未外化为文件或提交的阶段。一旦此时压缩，尚未落盘的调试结论就只存在于对话历史中，而对话历史正被摘要。

笔者认为：自动压缩最合理的触发条件不是“token 用量达到阈值”，而是“token 用量达到阈值 且 当前处于低价值阶段”。前者是资源信号，后者是任务信号，二者缺一不可。只按资源信号触发，等于在高速公路上按油量决定是否急刹，而不看路况。

3.3 非平稳性的来源

价值密度的非平稳性有三个来源。其一是信息外化程度：已写入文件、已提交、已记录到外部笔记的状态，其对话内价值骤降；反之未外化的状态价值极高。其二是决策依赖深度：某些条目（如“用户否决了方案 A”）会被后续多轮反复引用，形成长尾依赖；另一些条目只影响紧邻的一两轮。其三是不可恢复性：可从代码库、日志、文档重建的信息，压缩损失可接受；只存在于对话中的推理链，压缩即永久丢失。

这三个来源共同决定了：压缩的安全性 = f(外化程度, 依赖深度, 不可恢复性)。一个成熟的上下文治理方案，应当显式地估计这三个维度，而不是把判断权完全交给一个黑箱摘要器。

四、压缩失效的机理拆解：信息在何处被“总结丢”

4.1 摘要器的目标函数错位

主流压缩实现通常要求模型“总结对话要点，保留关键信息，去除冗余”。这个指令隐含了一个目标函数：最大化摘要的“可读性”与“主题覆盖度”。但任务连续性真正需要的是最大化后续决策的正确性。两个目标并不一致：一段读起来连贯、主题完整的摘要，完全可能丢失了“为什么不用方案 B”这种不连贯但决定性的信息。

这与信息检索中的经典张力同构：摘要偏向“主题相关性”，而任务连续性需要“决策相关性”。本文评述：把摘要目标从“写得好”改为“决策不塌缩”，需要在提示中显式要求保留负向状态与约束，并给出结构化模板（见 4.3），仅靠“保留关键信息”这类模糊指令不足以改变模型的行为倾向。

4.2 三类高频塌缩模式

从公开的社区讨论与工程实践中，可以归纳出三类反复出现的塌缩模式：

（1）否决项蒸发。“不要用 X”“已经试过 Y 不行”这类否定性陈述，在摘要中常被压缩为“讨论了若干方案”，否定语义丢失。后果是模型重新提出已被否决的方案，浪费轮次甚至引入已排除的风险。

（2）数值与标识符漂移。端口号、错误码、函数签名、配置项名称等精确信息，在自然语言摘要中容易被模糊化或改写。这类信息一旦漂移，后续代码与配置就会不一致，且难以通过语义相似度发现。

（3）因果链断裂。“因为 A 所以排除 B，进而选择 C”被压成“选择了 C”。结论保留、理由丢失，导致后续遇到反例时无法判断该坚持还是该修正，模型倾向于盲目坚持。

本文评述：三类塌缩有一个共同结构——被丢的都是“约束性信息”，保留的都是“描述性信息”。约束性信息的特点是短、硬、可判定，恰恰最适合用结构化格式而非自然语言摘要来保留。这为工程改进指明了方向：把约束从叙述中剥离出来，单独维护。

4.3 结构化压缩模板

与其让模型自由发挥写摘要，不如给出固定骨架，强制其填充约束性字段。下面是一个可直接用于 /compact 的自定义模板示例：

请将以下会话压缩为结构化状态，严格按字段输出，
缺失字段写“无”，不得省略字段：

[目标]        当前任务的最终目标（一句话）
[已完成]      已确认完成的步骤（列表）
[已否决]      明确排除的方案及理由（列表，含原话要点）
[硬约束]      不可违反的约束（版本、接口、合规、用户明示要求）
[关键数值]    端口/错误码/签名/配置项等精确信息（原样保留）
[未决问题]    尚待确认的开放问题（列表）
[下一步]      紧接着要做的动作
[可丢弃]      可安全省略的过程性叙述（列表）

要求：已否决、硬约束、关键数值三类字段必须逐条保留，
不得合并、不得改写、不得概括为“若干”。

这个模板的价值不在于“更详细”，而在于把易塌缩的信息类型变成必填字段。字段的存在本身就是一种注意力锚点，能显著降低模型省略负向状态的倾向。工程上还可以进一步把 [已否决]、[硬约束]、[关键数值] 三类字段单独持久化到外部文件，使其完全不受压缩影响。

五、边界判定：可操作的指标、阈值与决策表

5.1 三个可观测代理指标

精确的 ρ 不可计算，但可以用三个廉价代理指标近似：

指标一：外化率 E。当前会话中“已写入文件/已提交/已记录到外部”的状态占比。E 越高，压缩越安全。工程上可用工具调用记录粗略估计：写文件、执行命令、提交等动作的次数与总轮次之比。

指标二：约束密度 K。最近 N 轮中否定性、约束性陈述（含“不要”“必须”“已排除”“固定为”等标记）的条数。K 高说明正处于约束密集期，压缩风险高。

指标三：未决度 U。当前开放问题的数量与紧迫度。U 高说明任务处于未收敛状态，此时压缩容易丢失问题上下文。

5.2 决策表

把三个指标组合成一张决策表，可以在触发压缩前做一次快速判断：

这张表不是精确科学，而是一个强制人工介入的检查清单。它的作用是在自动压缩触发的那一刻，把“资源信号”与“任务信号”同时摆到台面上，避免单信号决策。

笔者认为：指标的价值不在于精确，而在于把隐性的判断显性化。即便 E、K、U 都是粗估，只要团队在压缩前例行过一遍这张表，塌缩事故率就会显著下降。这与航空业检查单的逻辑一致：检查单不提高飞行员能力，但能防止在高压下漏掉关键项。

六、检查点与回退：/rewind 的工程化用法

6.1 检查点的粒度设计

/rewind 的有效性完全取决于检查点粒度。粒度过粗，回退代价大，等于重做大量工作；粒度过细，检查点本身占用资源且管理复杂。合理的粒度应与决策节点对齐：每当做出一个不可轻易撤销的决定（选定方案、修改接口、变更数据模型），就打一个检查点。

工程上可以用一个轻量约定实现：在关键决策后，让模型输出一行标记（如 [CKPT] 决策：采用 refresh token 轮换，理由：…），并同步写入外部日志。这样即使对话被压缩，检查点索引仍在外部，/rewind 的目标点可被精确定位。

6.2 回退与副作用的解耦

/rewind 的一个常被忽视的陷阱是对话回退不等于副作用回退。回退到第 30 轮，但第 31 至 40 轮已经写入了文件、执行了命令、提交了代码，这些副作用不会自动撤销。因此回退前必须做副作用盘点：哪些变更已落盘、哪些可安全保留、哪些需要手动还原。

一个实用的做法是把“对话状态”与“工作区状态”分开管理：对话回退只影响推理上下文，工作区变更通过版本控制（git stash / 分支）独立管理。回退时先 stash 工作区，再 rewind 对话，然后按需恢复。这样两个状态维度互不纠缠，回退的确定性大幅提高。

本文评述：把 /rewind 当作“撤销键”是危险的，它更像“时间机器 + 手动对账”。真正可靠的方案是让副作用本身可重放：所有对工作区的修改都通过可追溯的工具调用完成，并记录在案，回退后可按记录重建或丢弃。这要求工具层具备幂等性与可审计性，是比命令本身更底层的工程约束。

七、混合治理流程：一套可复用的操作路径

7.1 分层上下文模型

把上下文分为四层，不同层用不同策略管理，是本文建议的核心工程结构：

这个分层的关键在于：把最易塌缩的 L0 移出对话历史，使其不受任何压缩算子影响。对话内只需保留一个指向 L0 文件的引用（如“约束见 constraints.md”），模型每轮按需读取。这样即使对话被彻底压缩甚至 /clear，核心状态依然完好。

7.2 操作步骤

把上述模型落成日常流程，可以按以下步骤执行：

步骤 1：会话初始化时建立 L0 文件。在任务开始时创建 constraints.md，写入目标、已知硬约束、用户明示要求。此后每轮对话开头注入该文件内容（或摘要引用）。

步骤 2：决策即外化。每当出现否决、定位缺陷、确定接口，立即追加到 L0 或 L1 文件，并在对话中留一行标记。不要依赖“稍后总结”。

步骤 3：压缩前过决策表。自动压缩触发时，先按 5.2 的决策表评估 E、K、U，高风险则推迟压缩或改用手动结构化压缩（4.3 模板）。

步骤 4：检查点对齐决策节点。重大决策后打检查点并记入 L1，回退时先 stash 工作区再 rewind，回退后按 L1 对账副作用。

步骤 5：收尾阶段再 /clear。任务交付、L0/L1 已归档后，/clear 是安全且推荐的，此时过程叙述已无保留价值。

7.3 一段可复用的提示片段

【上下文治理约定】
1. 每轮开始前，先读取 constraints.md 与 decisions.md，
   将其视为最高优先级约束，不得违反。
2. 出现以下情况时，立即追加写入对应文件并在回复中标记：
   - 用户否决某方案        → constraints.md [已否决]
   - 确定接口/错误码/配置  → constraints.md [关键数值]
   - 做出不可轻易撤销决策  → decisions.md [CKPT]
3. 收到压缩指令时，先输出结构化状态（见模板），
   确认 [已否决][硬约束][关键数值] 三类字段完整后再压缩。
4. 若发现当前推理与 constraints.md 冲突，停止并指出冲突，
   不得自行忽略约束继续推进。

这段约定的作用是把“记住约束”从模型的隐式能力变成显式流程。它不保证万无一失，但把塌缩从“随机发生”变成“可检测、可对账”的工程问题。

八、关键数据与案例：从公开实践到可验证观察

8.1 长上下文与“中间遗忘”的公开研究

关于长上下文模型的信息利用，已有若干公开研究提供了可引用的观察。Liu 等人 2023 年发布的 “Lost in the Middle” 研究指出，语言模型对长上下文中间位置信息的利用显著弱于开头与结尾，呈 U 形曲线（Liu et al., 2023, arXiv:2307.03172）。这一发现对压缩策略有直接含义：即便信息未被摘要掉，位于长上下文中部的条目也可能被模型低效利用，因此“保留”与“有效利用”是两回事。

另一条相关线索是检索增强与上下文重排的研究：把高价值信息放在上下文首尾、或通过检索动态注入，能显著改善利用效率（如 Shi et al., 2023, arXiv:2304.09542 关于重排的研究）。本文评述：这些研究共同支持一个工程结论——上下文治理不应只做“减法”（压缩），还应做“重排”（把 L0 约束放在显眼位置）。压缩与重排是互补的两把工具，只做压缩等于把重要文件塞进抽屉最深处。

8.2 智能体记忆与状态管理的公开工作

在智能体记忆方向，Park 等人 2023 年的生成式智能体工作（arXiv:2304.03442）展示了“记忆流 + 检索 + 反思”的结构：原始记忆保留、按相关性检索、定期反思生成高层摘要。这种结构的关键启示是原始记录与摘要并存，摘要用于快速定位，原始记录用于精确回溯。相比之下，一次性有损压缩缺少“原始记录”这一层，塌缩后无法回溯。

Packer 等人 2023 年的 MemGPT 工作（arXiv:2310.08560）则把上下文管理类比为操作系统虚拟内存：主上下文有限，外部存储无限，通过分页与换入换出管理。这一类比与本文的分层模型高度契合——L0/L1 相当于“换出到磁盘的关键页”，对话上下文相当于“物理内存”。笔者认为：MemGPT 的贡献不在于具体实现，而在于确立了“上下文是可治理的资源而非一次性缓冲区”的观念，这正是本文主线的理论支点之一。

8.3 一个可复现的观察设计（模拟数据说明）

为验证“阶段错配导致塌缩”的假设，可以设计一个可复现的小规模观察。需要说明：以下为模拟数据与设计示例，用于说明方法，不代表任何真实产品指标。

设计：构造 30 个多步骤编码任务，每个任务包含 3 条“否决项”与 2 条“关键数值”。分别在探索期、收敛期、执行期触发压缩，压缩后继续执行 10 轮，统计“否决项被重新提出”与“关键数值漂移”的次数。模拟结果（整合数据，非真实实验）显示：执行期触发压缩的塌缩率最高，收敛期次之，探索期相对最低；采用 4.3 结构化模板后，三类塌缩均有下降，其中否决项蒸发下降最明显。

本文评述：上述设计刻意保持小规模与可复现，目的是提供方法而非结论。真实工程中，团队应基于自己的任务分布做类似观察，把“塌缩率”作为上下文治理的持续指标，而不是照搬任何外部数字。任何声称“某压缩方案将塌缩率降低 X%”的说法，都必须交代任务分布与评估口径，否则不可比。

九、对比与局限：三种策略的适用边界

9.1 三种策略的对照

9.2 局限与反例

本文方案并非普适。首先，分层治理引入了额外开销：维护 L0/L1 文件、每轮注入、压缩前评估，都会消耗时间与 token。对于短任务（10 轮以内），这些开销可能超过收益，此时直接依赖模型原生上下文即可。其次，结构化模板依赖模型遵守指令，能力较弱的模型可能仍然省略字段，需要配合外部校验（如压缩后自动检查字段完整性）。

第三，存在反例：某些任务的价值恰恰在过程叙述中——例如需要复盘“为什么走了弯路”的调试任务，过程本身就是交付物。此时压缩过程叙述会破坏任务目标，应把过程也纳入 L1 保留。这说明分层不是固定的，而应随任务目标调整，任何“一刀切”的分层都会在特定任务上失效。

笔者认为：讨论上下文治理时，最容易犯的错误是追求“通用最优解”。实际上，治理策略的优劣高度依赖任务分布与失败代价。对失败代价极高的任务（生产环境变更、合规审查），应偏向保守（多外化、少压缩）；对失败代价低、迭代快的任务，可以更激进地压缩以换取速度。边界不是一条线，而是一个随代价变化的区间。

十、结论与展望：从“压缩上下文”到“治理状态”

10.1 结论

回到最初的问题：手动管理与自动压缩的边界该怎么划？本文的答案是——边界不在“手动还是自动”，而在“压缩触发点是否与任务阶段对齐、高价值状态是否已外化”。具体而言：

第一，把 L0（目标、否决项、硬约束、关键数值）移出对话历史，单独持久化，使其不受任何压缩影响。这是投入产出比最高的一步。

第二，压缩触发同时看资源信号与任务信号，用 E/K/U 决策表强制人工介入，避免单信号决策。

第三，压缩使用结构化模板，把易塌缩字段设为必填，并在压缩后做字段完整性校验。

第四，检查点对齐决策节点，回退前先对账副作用，把对话状态与工作区状态分开管理。

10.2 展望

向前看，上下文治理正在从“会话级技巧”演化为“系统级能力”。三个方向值得关注：其一，压缩决策的自动化与可解释化——未来的压缩器可能内置阶段识别与价值估计，在触发前给出“为何此时压缩安全/不安全”的解释，而非黑箱执行。其二，状态的外生化与标准化——类似 constraints.md 的结构化状态文件可能成为工具链标配，甚至由 IDE 或版本控制系统原生支持。其三，评估体系的建立——需要一套公开、可复现的基准来衡量“压缩后任务连续性”，否则所有改进都无法比较。