Claude Code 会话压缩（二）：Auto-Compact 的 SM-Compact（Session Memory）

Claude Code 会话压缩（二）：Auto-Compact 的 SM-Compact（Session Memory）​

源码基线：Claude Code 2.1.88​
文档重点：讲清 Session Memory 如何提取、保存，以及 Auto-Compact 如何消费它​
写作口径：以原理和例子为主；凡涉及固定 Prompt 或模板，完整保留原文​

系列导航：

•
四种会话压缩手段的主流程​

•
Microcompact：先清理旧工具结果​

•
传统 Compact：压缩时让 LLM 现场生成摘要​

•
Reactive Compact：真实溢出后的恢复​

1. 最重要的结论：Session Memory 是两阶段系统

SM-Compact 最常见的误解是“它完全不用 LLM”。准确说法是：

代码块

阶段一：会话正常进行时​
后台 Agent 周期性整理对话，并更新磁盘上的 summary.md​
这个阶段会调用 LLM​
​
阶段二：达到 Auto-Compact 阈值时​
读取已经准备好的 summary.md，作为压缩摘要​
这个阶段不再新增一次摘要 LLM 调用​

传统 Compact 把摘要成本集中在窗口将满的那一刻；Session Memory 则把这项工作分摊到会话进行过程中。​

两个阶段可以相隔很多轮对话。压缩发生时速度快，是因为摘要已经在更早的时候维护好了，而不是因为摘要工作消失了。​

2. 从提取到消费的完整流程

画板

这条主线包含五个关键动作：

1.
判断是否值得更新 Memory，避免每一轮都调用后台 Agent。​

2.
读取已有 Memory，让更新是增量整理，而不是每次从空白开始。​

3.
由后台 Agent 使用 Edit 落盘，主线程不把模型返回文本直接当文件内容。​

4.
记录 Memory 的覆盖边界，压缩时区分“已被 Memory 概括的历史”和“尚未概括的近期消息”。​

5.
SM-Compact 同时保留 Memory 与 recent tail，既获得长期摘要，也保留当前工作现场。​

3. Session Memory 什么时候更新

3.1 更新发生在主线程的输出之后

Session Memory 通过 post-sampling 阶段观察主会话：主模型完成一轮输出后，系统检查是否需要提取。它只服务于常规主线程，不让短生命周期的 subagent 各自改写主会话 Memory。​

自动更新相对主对话在后台执行，不要求用户等待它完成后才能继续操作；多个自动更新任务会串行执行，避免它们同时编辑同一个文件。​

这个能力还依赖 Session Memory、Auto-Compact 和当前运行环境的相关开关。总文档只需要理解：即使代码具备该能力，也不表示所有环境默认都会启用。​

3.2 默认更新门槛

当前默认配置可以概括为：

真正的触发逻辑是：5K 上下文增长始终必须满足，然后再满足下面任一条件：​

•
自上次更新以来累计至少 3 次工具调用；​

•
最近一轮 assistant 没有工具调用，说明到达一个自然对话断点。​

首次提取还要先跨过约 10K 的初始化门槛。这些数字可以由远端配置调整，因此更适合作为当前默认心智模型，而不是永久产品承诺。​

3.3 一个阈值例子

假设会话按下面的节奏增长：

Claude Code 会话压缩（二）：Auto-Compact 的 SM-Compact（Session Memory）​