最近我和一些 Claude Code 用户交流时，一个话题总会反复出现：100 万 token 的上下文窗口，是一把双刃剑。
它让 Claude Code 能更长时间地自主工作，也能更稳定地处理任务；但如果你不刻意管理会话，它也会让上下文污染更容易发生。
会话管理比以前重要得多，而关于它的问题似乎也特别多。你应该在终端里一直开着一个会话，还是开两个？每次发 prompt 都重新开始吗？什么时候该用 compact、rewind，或者 subagent？一次糟糕的 compact 又是怎么发生的？
这里面有不少细节，真的会明显影响你使用 Claude Code 的体验，而几乎所有细节都和你如何管理上下文窗口有关。
上下文、压缩与上下文腐化速览
上下文窗口，就是模型在生成下一条回复时一次性能“看到”的全部内容。它包括系统提示词、到目前为止的对话、每一次工具调用及其输出，以及所有被读取过的文件。Claude Code 的上下文窗口是 100 万 token。
不幸的是，使用上下文本身是有代价的，这通常被称为 context rot，也就是“上下文腐化”。它指的是：随着上下文变长，模型表现会下降，因为注意力被分散到更多 token 上，而更早、也更无关的内容会开始干扰当前任务。对我们这个 100 万上下文模型来说，通常在大约 30 万到 40 万 token 左右，就会出现一定程度的上下文腐化；但它和具体任务高度相关，并不是一条硬规则。
上下文窗口有明确上限，所以当你快走到窗口尽头时，就需要把正在做的任务总结成更短的描述，再在一个新的上下文窗口里继续。我们把这件事叫作 compaction，也就是压缩。你也可以主动触发压缩。
每一轮，都是一个分叉点
假设你刚让 Claude 做完一件事，现在你的上下文里已经积累了一些信息（工具调用、工具输出、你的指令），这时你下一步其实有很多选择：
- Continue：在同一个会话里继续发下一条消息
- /rewind（按两下 Esc）：跳回之前某条消息，从那里重新开始
- /clear：开启一个新会话，通常配合一份你根据刚刚所得整理出的简短说明
- Compact：把目前会话压缩成摘要，再基于这个摘要继续
- Subagents：把下一块工作委托给一个拥有独立干净上下文的 agent，只把结果带回来
最自然的选择当然是直接继续，但另外四种选项存在，本质上都是为了帮你管理上下文。
什么时候该开一个新会话
新的 100 万上下文窗口，意味着你现在能更可靠地完成更长的任务，比如从零搭一个全栈应用。但模型没把上下文用光，并不代表你就不该开新会话。
我们一个很通用的经验法则是：当你开始一个新任务时，也应该开启一个新会话。
灰色地带在于，有些相关任务会保留一部分仍然有用的上下文，但不是全部都需要。
比如你刚实现完一个功能，接着去写它的文档。你当然可以开新会话，但那样 Claude 就得重新读取你刚刚改过的那些文件，会更慢，也更贵。因为写文档未必是那种对“智能状态”特别敏感的任务，所以为了避免重新读相关文件，多保留一点上下文，可能反而更划算。
与其纠正，不如回退
如果要我选一个最能体现上下文管理是否到位的习惯，那就是 rewind。
在 Claude Code 里，连按两下 Esc（或者执行 /rewind）可以让你跳回任意一条先前的消息，然后从那里重新下提示。那之后的消息都会从上下文里被丢掉。
在很多需要纠错的场景里，rewind 往往是更好的做法。比如，Claude 读了五个文件，尝试了一种方案，但没成功。你的第一反应也许是输入：“这个不行，改用 X 试试。”但更好的动作，通常是回退到刚读完文件之后，再把你学到的信息写进新的 prompt 里重新来一次。比如：“别用方案 A，foo 模块并没有暴露那个接口——直接走 B。”
你也可以用 “summarize from here”，让 Claude 把它在某个时间点之后的探索总结出来，生成一条交接消息。它有点像是：来自未来的 Claude，给过去那个自己留的一张便条，告诉它刚才试过什么、为什么不行。
Compact 和全新会话的区别
当一个会话变得很长时，你有两种方式减重：/compact，或者 /clear（然后重新开始）。它们看起来相似，但行为方式差别很大。
Compact 会让模型把当前对话总结一遍，然后用这个总结替换掉原来的历史记录。这是有损的：你是在相信 Claude 自己判断“什么是重要的”。但你不用亲手写总结，而且 Claude 可能会更完整地保留关键发现或相关文件。你也可以通过指令去引导它，比如 /compact focus on the auth refactor, drop the test debugging。
而 /clear 则是你自己写下什么重要——“我们正在重构认证中间件，约束是 X，关键文件是 A 和 B，我们已经排除了方案 Y”——然后在一个完全干净的上下文里重新开始。它更费事，但最后留下来的上下文，是由你亲自决定的。
什么会导致一次糟糕的 compact？
如果你跑过很多长会话，可能已经发现：有些时候 compact 的结果会特别糟。我们经常观察到，这往往发生在模型无法预测你的工作接下来要往哪走的时候。
比如自动 compact 在一次很长的调试会话后触发，把整个调查过程都总结了一遍；而你下一条消息却是：“现在去修我们刚才在 bar.ts 里看到的另一个 warning。”
但因为刚才整个会话的重心都在调试主问题上，那个“另一个 warning”就很可能在摘要里被丢掉了。
这件事尤其棘手，因为受上下文腐化影响，模型在执行 compact 时，往往正处在它最不聪明的阶段之一。有了 100 万上下文后，你有更多空间去更早地主动 /compact，并顺手说明你接下来打算做什么。
Subagent 与全新的上下文窗口
Subagent 也是一种上下文管理方式，适合那种你提前就知道会产出大量中间输出、而这些输出以后大概率不会再看的工作块。
当 Claude 通过 Agent 工具启动一个 subagent 时，这个 subagent 会获得一个全新的上下文窗口。它可以在里面完成所需的全部工作，最后把结果整理成总结，只把最终报告返回给父 agent。
我们常用的判断标准是：我之后还会再需要这些工具输出吗，还是我只需要结论？
虽然 Claude Code 会自动调用 subagent，但你有时也可以明确要求它这么做。比如你可以告诉它：
- “启动一个 subagent，根据下面这份 spec 文件验证这项工作的结果。”
- “分出去一个 subagent，读一下另一个代码库，总结它是怎么实现 auth flow 的，然后按同样方式在这里实现。”
- “分出去一个 subagent，根据我的 git 改动来写这个功能的文档。”
总结
总之，当 Claude 完成一轮回复、而你准备发下一条消息时，你其实正站在一个决策点上。
我们预计，随着时间推移，Claude 会越来越多地帮你处理这些事；但在现在，这依然是你可以主动引导 Claude 输出质量的一种方式。
