这篇长帖系统讲清了 Claude Code 在 1M 上下文窗口下的会话管理：什么时候开新会话、什么时候 rewind、什么时候 compact，以及 subagents 如何帮你隔离上下文噪音。
最近我和很多 Claude Code 用户交流时，一个主题反复出现：1M token 的上下文窗口是一把双刃剑。
它让 Claude Code 可以更长时间地自主工作，也能更稳地处理长任务；与此同时，只要你在会话管理上稍微不够主动，它也会更容易把你带进上下文污染里。
所以，会话管理的重要性比以前更高了，而且很多人都在问同一类问题：一个终端里该常驻一个 session，还是两个？每次提问都应该全新开始吗？什么时候适合用 compact、rewind 或 subagents？一次糟糕的 compact 往往是怎么发生的？
这里面有很多细节，而这些细节会显著影响你使用 Claude Code 的体验。几乎所有问题，最后都指向同一个核心：你如何管理自己的上下文窗口。
先快速讲清楚：什么是上下文、压缩和“上下文腐化”
上下文窗口，指的是模型在生成下一次回复时能够同时“看见”的全部内容。它包括 system prompt、到目前为止的对话、每一次工具调用和输出，以及所有被读取过的文件。Claude Code 的上下文窗口是 100 万 token。
上下文的使用会附带一层隐性成本，这通常被称为 context rot，也就是“上下文腐化”。它描述的是这样一种现象：随着上下文越来越长，模型的注意力会被摊薄到更多 token 上，较早出现、已经失去相关性的内容，也会开始干扰当前任务，于是模型表现逐步下降。对于 1M 上下文模型，我们通常会在大约 30 万到 40 万 token 左右观察到某种程度的 context rot，不过这件事很依赖任务类型，所以它更像经验区间，不是硬性阈值。
上下文窗口有明确上限。接近上限时，你需要把正在处理的任务总结成一份更短的描述，然后在一个新的上下文窗口里继续推进，这个过程就叫 compaction。你也可以主动提前触发 compaction。
每一轮结束，都是一次分叉点
当你刚让 Claude 做完一件事，当前上下文里已经留下了一些信息：工具调用、工具输出、你的指令，以及它刚完成的工作。此时你接下来怎么走，其实有不少选择：
- Continue：在同一个 session 里继续发下一条消息
- /rewind（esc esc）：跳回之前某条消息，从那里重新提示
- /clear：开启一个新会话，通常带上一份你从当前工作里提炼出来的 brief
- Compact：把当前会话压缩成摘要，再继续往下做
- Subagents：把下一段工作委派给一个拥有独立干净上下文的 agent，只把最终结果带回主会话
直接继续通常最符合直觉，另外四种选择的存在，价值就在于帮你主动控制上下文质量。
什么时候该开新会话
新的 1M 上下文窗口，让更长任务变得更可靠了。比如，你现在可以更稳地让 Claude Code 从零做出一个全栈应用。可这件事带来的结论，并不是“只要上下文还没满，就一直沿用原会话”。
一个很实用的经验法则是：只要你开始的是一个新任务，也应该同步开启一个新会话。
真正有判断空间的地方，在于“相关但不完全相同”的任务。也就是部分旧上下文依然有价值，但并非全部都还重要。
比如，你刚实现完一个功能，接着去写它的文档。你当然可以开新会话，但那样 Claude 就得重新读取刚才写过的那些文件，速度更慢，成本也更高。文档撰写通常又不是那种对模型智力状态极度敏感的任务，所以为了省掉重复读文件的成本，保留一部分额外上下文，往往是划算的。
遇到修正需求时，rewind 往往更优
如果我只能挑一个最能体现“上下文管理成熟度”的习惯，我会选 rewind。
在 Claude Code 里，连按两次 Esc，或者直接运行 /rewind，都可以让你回到之前任意一条消息，再从那里重新发 prompt。那个时间点之后的消息会一起从上下文中移除。
rewind 往往比“继续纠正”更有效。比如，Claude 读了五个文件，尝试了一条路径，结果没走通。很多人的第一反应是接着输入：“这条路不行，换 X。”更高质量的做法，通常是 rewind 到刚读完文件的位置，再把新学到的信息塞回 prompt 里，比如：“别再走方案 A，foo 模块没有暴露那个接口，直接去做 B。”
你也可以用 “summarize from here”，让 Claude 把已经获得的经验总结成一条 handoff message。它很像来自“未来版本 Claude”的留言：我已经替你踩过坑了，接下来你直接沿着这条更优路径走。
compact 和 fresh session 的区别
会话一旦拉长，你就有两种常见方式给上下文减负：/compact，或者 /clear 再重新开始。两者看起来接近，实际行为差异很大。
compact 会让模型总结到目前为止的对话，再用这份摘要替换原本的历史。这个过程天然带有信息损耗，因为你把“什么重要”交给了 Claude 来判断。它的优势在于省事，你不需要手写总结，而且 Claude 有时会比你更完整地保留关键经验和相关文件。你还可以给它加方向，例如：/compact focus on the auth refactor, drop the test debugging。
/clear 的方式则是由你亲自写下关键上下文，比如：“我们正在重构 auth middleware，约束条件是 X，核心文件是 A 和 B，方案 Y 已经排除。”然后从一张真正干净的纸开始。它更费力，但新上下文里留下的内容，完全由你决定。
什么情况下会出现糟糕的 compact
如果你经常跑很长的 session，大概率已经见过某些 compact 效果特别差的时刻。我们通常观察到，bad compact 往往出现在模型很难预测你接下来工作方向的时候。
例如，autocompact 在一次漫长的调试会话后自动触发，摘要主要围绕调试过程生成；紧接着你的下一条消息却是：“现在去修 bar.ts 里刚才看到的另一个 warning。”
由于整个 session 的主轴一直是调试，那个次要 warning 很可能已经被摘要丢掉了。
这个问题更棘手的一点在于：context rot 会让模型在 compact 发生时，恰好处在自己智力状态相对更差的区间。1M 上下文窗口给了你更充裕的主动空间，所以更好的做法通常是：在你还清楚知道自己接下来要做什么的时候，尽早手动 /compact，并明确告诉它要保留什么。
subagents 本质上也是上下文管理工具
subagents 本身就是一种上下文管理手段。它特别适合这样一种场景：你提前知道，接下来这段工作会产生大量中间输出，而这些中间输出之后大概率用不上。
当 Claude 通过 Agent tool 拉起一个 subagent 时，这个子代理会拿到自己独立、全新的上下文窗口。它可以在里面做足够多的工作，最后再把结果压缩成一份总结，只把最终报告返回给父会话。
这里有一个很好用的判断标准：我未来还需要这些工具输出本身吗，还是只需要它们的结论？
Claude Code 会自动调用 subagents，但很多时候你也可以更明确地要求它这样做。比如：
- “起一个 subagent，基于下面这份 spec 文件验证这次工作的结果。”
- “起一个 subagent，去读另一个代码库，总结它的 auth flow 是怎么做的，然后按同样方式在当前项目里实现。”
- “起一个 subagent，根据我当前的 git changes 去写这项功能的文档。”
收束
当 Claude 完成一轮回复，而你正准备发下一条消息时，你其实站在一个明确的决策点上。未来，Claude 大概率会替你处理掉更多这类判断；眼下，主动管理这些分叉点，依然是你引导 Claude 产出质量的关键方式之一。
