第十三章 claude的微压缩-精准上下文修剪

这一章深入分析了 Claude Code 如何在不调用大语言模型（LLM）生成摘要的情况下，通过轻量级的策略精准移除“过时”的上下文内容（如旧的工具执行结果），以释放宝贵的 Token 空间。

以下是该章节的核心内容总结：

1. 微压缩的核心哲学

与之前提到的全量“自动压缩”不同，微压缩遵循 “最便宜的 Token 是你从未发送的那个”。它不生成摘要，而是直接清除或删除旧的工具调用结果（如几小时前的搜索输出或日志），因为这些信息对于当前的推理任务往往已经过时。

2. 三种微压缩机制对比

源码中实现了三种互补的机制，它们在触发条件和执行方式上各有侧重：

• 基于时间的微压缩（Time-based Microcompact）：

  • 触发场景：当用户长时间离开（如超过 60 分钟）后恢复会话时触发。

  • 原理：既然服务端的提示词缓存（Prompt Cache）已经过期，系统会直接修改本地消息内容，将旧工具结果替换为占位文本，从而在重写缓存时减小体积。

• 缓存微压缩（Cached Microcompact）：

  • 触发场景：实时会话中，当可压缩工具数量超过阈值时触发。

  • 原理：利用 Anthropic API 的 cache_edits 特性，向服务端发送删除指令。它不修改本地消息，因此能保持缓存前缀的完整性，避免产生昂贵的缓存创建费用。

• API 上下文管理（API Context Management）：

  • 原理：一种声明式策略。客户端描述规则（如“超过 X tokens 时保留最近 Z 个”），由 API 服务端自动执行清理工作。它还支持清理大模型产生的思考过程（Thinking Blocks）。

3. 工具清除的优先级与分类

并非所有工具结果都会被一视同仁地清除。系统定义了不同的可压缩工具集：

• 高频清理类：输出量大但可丢弃的工具，如 Shell (Bash)、Grep、Glob、FileRead 和 WebSearch。

• 写入保护类：如 FileEdit 和 FileWrite，在 API 模式下会采取更激进的 exclude_tools 策略来管理。

4. 复杂的工程协调机制

微压缩并非孤立操作，它需要与系统的其他子系统紧密配合：

• 缓存中断检测协调：由于微压缩故意减少了缓存内容，系统通过 notifyCacheDeletion() 通知检测器，防止其将正常的微压缩误报为“缓存中断” Bug。

• 子代理（Sub-agent）隔离：为了防止全局状态污染，缓存微压缩仅对主线程执行，子代理被完全排除在外。

• 幂等性保证：在修改消息时，系统会检查占位文本，防止对已清除的内容重复统计节省的 Token 数。

5. 版本演化 (v2.1.91)

在较新版本中，微压缩系统引入了更多人性化和防御性特性：

• 冷压缩（Cold Compact）：一种非紧急的、可延迟到下一回合的压缩策略。

• 压缩确认 UI：在执行压缩前通过对话框通知用户，提升了操作透明度。

• 快速回填熔断器：如果压缩后上下文被迅速填满（如连续读大文件），系统会中断压缩循环，防止无意义的 API 开销。

6. 给开发者的设计模式启示

• 分层降级：从 API 声明式基线到精准手术般的缓存微压缩，再到缓存失效后的时间触发清理，形成了完备的退化路径。

• 单次消费语义：通过 consumePendingCacheEdits() 确保指令在 API 重试等场景下不会被重复消费。

• 不可变修改：在处理消息数组时使用展开运算符创建新数组，保护原始数据不被污染。

总结而言：本章展示了 Claude Code 如何通过时间感知、缓存感知和声明式策略的组合，在不牺牲模型“智力”的前提下，极致地榨取每一分上下文空间的价值。