会话生命周期:compact、clear 与恢复
全面详解会话生命周期中compact、clear、resume与检查点的使用时机，以及基于文件化状态运行长任务的最佳实践方法
缓存篇讲了“别破坏前缀”,上下文窗口篇讲了“窗口只增不减”。本篇讲日常操作层面,什么时候该压缩、该重开、该回滚、该续跑。
核心命令速查
| 命令 | 作用 | 对上下文的影响 |
|---|---|---|
/context |
查看窗口占用明细 | 无(诊断工具) |
/compact |
把历史压缩成摘要 | 大幅缩小,细节丢失 |
/clear |
清空对话,重新开始 | 归零(系统提示、CLAUDE.md 仍在) |
/resume |
列出历史会话,挑一个继续 | 恢复所选会话的完整历史 |
claude -c / --continue |
直接续上最近一个会话 | 同上 |
Esc Esc / /rewind |
回滚到之前的检查点 | 对话和/或代码回到当时状态 |
/cost |
查看本会话花费(API 计费时) | 无 |
Compact
窗口接近上限时,Claude Code 会自动 compact,腾出空间继续。这是保底机制,但把压缩时机交给自动触发有两个问题任务中间(正是上下文最值钱的时候),而且你无法控制保留什么。
更好的做法是主动压缩,选好时机:
- 在阶段边界压缩、测试通过、刚提交——此刻旧历史的细节价值最低,是压缩的黄金时间;
- 带指令压缩:
/compact 保留所有文件修改记录和未解决的报错—— 告诉它摘要里什么必须留下; - 压缩前把状态写进文件 Agent 先把进展、待办、关键决定写到一个 markdown(如
PROGRESS.md),文件不怕压缩——摘要丢了细节,随时能从文件读回来。这是长任务最重要的习惯。
Clear
经验法则:换任务就 /clear,别舍不得。
上一个任务的历史对新任务不但没帮助,还是三重负担、增加每轮成本、且残留的旧上下文会干扰模型对新任务的判断(它可能“惯性”沿用上个任务的假设)。/clear 之后系统提示、CLAUDE.md、MCP 都还在,只是对话归零——相当于换了一张干净的桌子,而不是搬了办公室。
什么时候不该 clear(修复刚才实现里的 bug)、需要引用前面结论的追问。
Resume 与续跑
会话历史保存在本地,随时可以捞回来:
claude --continue,适合“昨天干到一半今天接着来”;claude --resume(或会话内/resume)。
但要清醒:恢复的会话把整个历史重新载入窗口,而且缓存早已过期(TTL 只有 5 分钟到 1 小时),第一轮是全额重建。所以跨天的长任务,靠 resume 不如靠文件化的状态:
推荐的长任务模式:
1. 让 Agent 维护一个 TODO.md / PROGRESS.md,每完成一步就更新;
2. 阶段完成 → 提交 git → /clear;
3. 新会话开场:"读 PROGRESS.md,继续下一项"。
── 每个会话都从小而干净的上下文开始,状态却一点不丢。这个模式同时解决了窗口膨胀、缓存重建、compact 丢细节三个问题,是本站最推荐的工作方式。
检查点与回滚
Claude Code 会在每次修改前自动记录检查点(checkpoint)。按 Esc Esc(或 /rewind)可以回滚,且对话和代码可以分开回:
- 只回代码 A 改坏了,代码回到改动前,但对话里保留“方案 A 为什么失败”的记忆——让 Agent 带着教训试方案 B(非常好用);
- 只回对话,但对话被带偏了,回到之前的提问重新说;
- 都回。
注意检查点不替代 git Bash 命令产生的副作用(比如脚本删的文件),跨会话的持久保障仍然是“小步提交”。