跳到主要内容

compaction 与上下文压缩

三种压缩策略的选型逻辑、触发时机，以及 context anxiety 副作用的成因与对策

核心要点：

  • compaction = 压缩历史后续跑同一 agent
  • 三策略：compaction / context-reset / 全新窗口
  • 预压缩把紧急压缩挪到后台，延迟无感
  • compaction 有损，丢细粒度数字
  • context anxiety：模型临近上限会过早收尾

compaction 是 06-记忆操作生命周期 中 compress 原语 在长任务里的具体工程形态。本文讲它的策略选择、触发机制和副作用。

compaction、context-reset、全新窗口有什么区别？​

核心问题：上下文快满了，把历史"压一下"和"开新会话"是一回事吗？

三者机制不同，只有 compaction 是原地压缩续跑[1]。混淆它们会选错策略。

策略机制信息损失agent 状态
compaction历史被模型压成摘要，同一 agent 以摘要为起点续跑有损，丢细节知道自己被压缩
context-reset终止当前会话，用结构化 handoff 文档启动新 agent取决于文档设计干净起点
全新窗口完全空白会话，不传任何历史全部丢失从零开始

@tbl-agent-memory-compaction-strategies 上下文满时三种处理策略对比：compaction、context-reset、全新窗口的机制、信息损失与 agent 状态

关键区分：compaction 和 context-reset 都能让工作继续，但前者是"压缩后续跑同一个 agent"，后者是"关掉旧 agent、用文档启动新 agent"(handoff 机制详见 04-文件型外置记忆)。全新窗口只适合无需历史的独立子任务。

compaction 怎么触发，丢什么留什么？​

核心问题：压缩在什么时候发生，哪些信息能活下来？

默认在输入超过约 150K token 时触发（最低可设 50K），摘要保留高层决策、丢弃细粒度数字[2]。压缩后旧消息被替换为一个 <summary> 内容块，对 agent 透明——它能看到摘要，知道自己经历了压缩。

Anthropic cookbook 的实测对照很直接：

  • 存活：高层事实——中位数、关键标识符、百分比。
  • 丢失：附录表格的具体数值、效应量、细粒度统计。

陷阱：一个跑数据分析的 agent，压缩后还记得"中位数是 42、用了 A 方案"，但忘了附录里每一行的精确数值。如果后续步骤要引用那些精确数，就会出错——所以要把不能丢的精确数据落到文件，而非指望摘要保留。

摘要者就是模型自身，接收完整历史生成结构化摘要，遵循"先最大化召回，再迭代提升精确度"的原则。可传自定义 instructions 保留领域关键信息（如代码变量名、决策链）。这个有损特性正是文件型记忆存在的理由：关键状态写进文件，压缩后能从磁盘重新注入，不随摘要消失。

预压缩怎么把紧急压缩成本降下来？​

核心问题：等上下文满了再压缩会卡住任务，能不能提前压？

后台异步预压缩把紧急压缩挪到后台，延迟降到用户无感[2]。这是"超前压缩"思路：不在任务关键时刻临时压。

  • 每轮用户交互结束后，后台线程异步压缩历史。
  • 对历史上下文用 cache_control 加速压缩。
  • 主对话触达 token 上限时，最新的后台摘要立即顶替历史，无可感知延迟。

工程上还可以用更廉价的模型（如 Haiku）执行压缩，进一步降本。这条经验可借鉴：把昂贵的同步操作改成廉价的后台预计算，是 agent 工程里反复出现的模式。

什么是 context anxiety，怎么缓解？​

核心问题：为什么 agent 接近上下文上限时会"草草收尾"?

context anxiety 指模型临近它认为的上下文上限时过早结束任务[1]。这是 compaction 留下的行为副作用：压缩后模型仍感知到"之前发生了很多"，带着这种"已经跑很久"的感觉而提前收工。

Anthropic 的观察很具体：Claude Sonnet 4.5 的 context anxiety 强到"单靠 compaction 不足以支撑长任务"，即便压缩续跑仍会过早收尾；对这类模型，context-reset 配 handoff 文档效果更好，因为干净起点消除了焦虑来源。Anthropic 后续更强的模型大幅改善这一行为，可单用 compaction 承载长任务。

这条经验的可借鉴点：记忆策略要随模型能力调整——同一套 harness，在弱模型上需要 context-reset 兜底，在强模型上可以简化为纯 compaction。

Claude Code 的渐进压缩流水线长什么样？​

核心问题：生产系统是一次性压缩，还是分级处理？

Claude Code 按成本从低到高分五层惰性降级，而非一刀切[3]。每次模型调用前依次尝试，能用便宜手段就不用贵的。

  1. Budget Reduction — 裁剪最低优先级上下文。
  2. Snip — 去除样板和重复模式。
  3. Microcompact — 对冗长段落内联压缩。
  4. Context Collapse — 读时投影，非破坏性。
  5. Auto-Compact — 完整模型摘要，最后手段。

前几层保留细节，后几层以保真度换 token。这种分级让大多数压缩在廉价层完成，只有真正逼近上限时才动用昂贵的完整摘要。

Takeaway​

知识点核心结论
三策略区分compaction（原地续跑） ≠ context-reset（新 agent + 文档） ≠ 全新窗口
触发与损失默认 ~150K token 触发；留高层决策，丢细粒度数字
预压缩后台异步 + cache_control，延迟无感，成本摊到后台
context anxiety模型临近上限过早收尾；弱模型需 context-reset，强模型可纯 compaction
渐进压缩五层惰性降级，廉价层优先，完整摘要是最后手段

参考资料​

  1. Anthropic. Harness design for long-running application development. 2025. https://www.anthropic.com/engineering/harness-design-long-running-apps
  2. Anthropic Claude Cookbook. Context engineering: memory, compaction, and tool clearing. 2026. https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
  3. Liu et al. Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems. arXiv:2604.14228, 2026. https://arxiv.org/abs/2604.14228

延伸阅读​