基础篇

F27｜压缩不是魔法：摘要、原文和执行状态怎样配合

基础篇约 2.5 千字1 组分步图解

从具体对象与小例子开始，理解计算过程与适用条件。

本节会用到

F16 · KV Cache从零解释 F24 · 状态、事件与检查点 F26 · 上下文组装

本章目录

动态图解 · F27

压缩要保留行动所依赖的事实

把一百轮历史压成几句话，最容易丢什么？

像交班给另一位同事：对方最需要目标、禁止事项、已经做完的事、还没核实的事，以及到哪里看原证据。原始日志可以外置，但决定下一步动作的区别不能抹平。摘要也不是执行数据库，不应凭它判定不可重复动作是否已完成。

截断直接删掉一部分上下文。

摘要压缩用新文本概括旧信息，可能引入改写错误。

快照明确字段的当前状态记录。

证据引用重新获取原文的定位信息。

输入与适用条件：构造的exclude修复场景；有意保留“集成测试尚未运行”这一否定状态。错误摘要只作为反例，禁止当作推荐模板。

1 / 5 · 原历史有很多噪声

停留时间

步骤第1步，共5步

窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。

工具输出、失败尝试和重复讨论可以很长。压缩的目标是减少历史占用，不是美化成“进度不错”。

可恢复快照

默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。

为什么需要

有限窗口无法一直保留全部原始对话，但任务需要连续推进。

怎样实现

保留必要状态与引用，压缩后核对，再从原始来源恢复细节。

可能的代价与误解

摘要重写可能把猜测变结论，多轮摘要还可能累计偏移。

如何判断是否做对

比较压缩前后允许的下一步动作是否一致，而不只是文本相似度。

先区分四种动作

截断直接删除部分历史；摘要压缩compaction尝试用更短表示保留后续需要的信息；外部存储offloading把内容放到文件或数据库；计算缓存复用相同条件下的计算。这四件事可能配合，但不等价。

摘要是有损的：一句“测试已通过”可能丢掉哪些测试、对哪个版本、是否还有未测边界。把所有关键细节都保留，压缩比例就可能较低，这是信息取舍而不是命名问题。

一个不能再被缩短成“任务快完成”的状态

压缩前有大量记录，真正需要保留的是：

目标：修复目录排除规则；不改公共函数签名。
事实：vendor/a.py未被排除；原始证据在测试日志log-7。
已确认原因：前缀比较忽略目录分隔边界。
已执行：修改调用c12已发出，但响应超时，结果unknown。
验证：只对修改前版本v3运行过测试。
下一步：核验文件版本，再决定是否重试和运行新测试。

若压成“已修复，待提交”，会把未知变成功，还把旧测试变成新验证。好的文笔无法抵消状态错误。

一次压缩应该怎样进行

先在合适边界获得一致的历史与状态视图；识别目标、约束、事实、假设、未决动作、证据引用；生成候选摘要；核对关键项；再切换为新上下文。

若工具仍在执行，而摘要和状态分别读到不同时间点，可能出现“摘要说待执行、实际上已经成功”。是否需要锁、版本检查或等待，取决于任务并发程度，不是所有场景都必须上复杂事务。

原文如何重新找回

摘要应给出足够定位原始证据的引用，例如任务ID、工具调用ID、日志位置、仓库提交与路径。之后遇到细节问题，可重新读取原文，而不是让模型猜摘要没写的部分。

引用仍需检查有效性：文件路径可能被覆盖；工具记录可能过期；权限可能已改变。可找回与当前可合法使用也不同。

为什么不透明压缩块不能当普通摘要

有些服务返回模型或服务特定的压缩状态，不保证人能直接阅读，也不保证另一模型可以使用。它的内部编码未公开时，不应编造“里面保存了哪些神经元记忆”。

能观察和验证的是接口契约、后续任务表现、关键约束是否保留，以及已记录的恢复行为。不能因形式更神秘就假定无损。

怎样评估压缩有没有损失关键内容

不只看摘要与原文词语重合度，而要设计具体问题：目标还能否准确重述？禁止项是否仍在？证据版本能否找到？unknown动作是否仍被标记未知？能否接着完成任务而不重复破坏性操作？

把完整历史、截断、摘要加引用等方案在同一组任务上比较。恢复成功率、错误状态率、耗时和成本都是重要指标。不能只报压缩率。

记得一句话与得到可执行状态不同

自然语言摘要帮助模型理解；执行记录帮助宿主决定可否重试、提交和回滚。长任务往往需要两者，而不是让一段摘要承担所有事务语义。

读高级压缩章节时，带着“哪个状态可能被弄错、恢复依赖什么、失败会造成什么具体后果”追问，才能从摘要技巧进入系统工程。

运行示例 · F27

同样短的摘要，为什么一个安全一个危险

输入与条件。原事实：补丁已写；测试仅在r7通过；当前工作树r8；禁止部署；还缺r8回归测试。

步骤与对象	内部动作	中间结果 / 新状态
1错误摘要	“修复完成，测试通过，可交付”	遗漏测试版本与禁止部署，把待办改成完成。
2保真摘要	“补丁已写；r7测试通过；r8待回归；禁止部署”	保留动作、证据版本、待办和限制。
3外置证据	保存 `test_log@r7` 的可访问位置	摘要只当入口，不声称其中含完整日志。
4恢复后动作	先对r8运行相关测试	不能沿用r7的通过状态。
5验证摘要	逐项询问当前版本、禁做动作和未完成项	不是只看与原文的词汇相似度。

把过程连起来。摘要必须保存“谁在什么版本做过什么、还有什么没做”。“没有完成”中的否定词也是状态的一部分。

边界与反例。没有用真实LLM生成摘要，两个候选是人为构造的正反例；保真需在真实任务上另外评测。

依据与适用范围：[CONTEXT]。示例输入和场景由本书明确设定。

课后自检

自检 1

为什么“测试通过”这个摘要不够？

查看参考答案收起参考答案

缺少测试名称、运行范围、输入和代码版本。可能只是旧版本通过，不能证明当前补丁已验证。

自检 2

能否保证所有任意长历史都被一个极短摘要无损保存？