摘要：1M 上下文是把双刃剑，关键在于主动管理会话：何时 rewind、何时 compact、何时起新窗口、何时派子 Agent。
本文翻译自 Using Claude Code: Session Management & 1M Context
作者：@trq212
发布时间：2026-04-15
翻译：searchpcc
授权：未获明确授权，仅作学习交流，如有异议请联系删除
在我最近和 Claude Code 用户的交流中，一个主题反复出现：1M token 上下文窗口是一把双刃剑。
它让 Claude Code 能更长时间自主运行、更可靠地完成任务；但如果你不主动管理会话，它也会打开「上下文污染」的大门。
会话管理比以往任何时候都更重要，而大家似乎有一堆疑问：在终端里只开一个会话，还是两个？每条 prompt 都开新会话？什么时候该用 compact、rewind 或子 Agent？什么情况下 compact 会变糟？
这里有相当多的细节，会实打实地影响你使用 Claude Code 的体验——而几乎所有细节都来自如何管理你的上下文窗口。
上下文、Compaction 与 Context Rot 速成
上下文窗口就是模型在生成下一条回复时能够「看到」的一切。它包括你的 system prompt、迄今为止的对话、每一次工具调用及其输出、以及每一个被读取过的文件。Claude Code 的上下文窗口是 100 万 token。
不幸的是，使用上下文是有代价的，这通常被称为 context rot（上下文腐化）。Context rot 是指随着上下文增长，模型性能会下降——因为注意力被分散到更多 token 上，而更早的、与当前任务无关的内容开始干扰模型。对我们的 1M 上下文模型来说，我们观察到 context rot 大约在 300k–400k token 附近开始显现，但这高度依赖具体任务，并不是硬性规律。
上下文窗口是一个硬边界。所以当你接近上下文窗口末尾时，你需要把之前做过的工作压缩成一份较短的描述，在一个新的上下文窗口里继续工作——我们把这个过程叫做 compaction。你也可以自己触发它。
每一轮都是一个分支点
假设你刚让 Claude 做完一件事，此时你的上下文里已经累积了一些信息（工具调用、工具输出、你的指令），接下来你有出乎意料多的选项：
- Continue —— 在同一个会话里继续发下一条消息
- /rewind（esc esc）—— 回到之前某条消息，从那里重试
- /clear —— 开一个新会话，通常会带上你刚总结出来的简要 brief
- Compact —— 把目前的会话总结一下，然后在这份摘要上继续
- Subagents —— 把下一块工作派给一个拥有独立干净上下文的 Agent，只把它的结果拉回来
最自然的选择当然是直接 continue，而其他四个选项存在的意义，就是帮你管理上下文。
什么时候开新会话
新的 1M 上下文窗口意味着你现在可以更可靠地完成更长的任务，比如让它从零开始做一个全栈应用。但模型还没用完上下文，不代表你就不该开新会话。
我们的一般经验法则是：开始一个新任务时，也开一个新会话。
灰色地带是，当你要做一些相关任务，其中一部分上下文仍然有用、但不是全部。
比如，给你刚实现的功能写文档。你可以开一个新会话，但那样 Claude 就要重新读一遍你刚实现的那些文件，既慢又贵。既然写文档并不是一个对智能水平极度敏感的任务，那么「多带一点上下文」换来的「不用重新读文件」的效率收益，多半是值得的。
用 Rewind 代替纠正
如果要我挑一个最能体现「上下文管理得好」的习惯，那就是 rewind。
在 Claude Code 里，双击 Esc（或运行 /rewind）可以让你跳回任意一条之前的消息，从那里重新 prompt。那之后的消息会从上下文里移除。
Rewind 往往是比「纠正」更好的做法。举个例子：Claude 读了五个文件，尝试了一种方案，没有成功。你的直觉可能是打「那个不行，换成 X 试试」——但更好的做法是 rewind 到刚读完文件那一步，用你新学到的东西重新 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 时，你自己写下什么重要（「我们正在重构 auth middleware，约束是 X，相关的文件是 A 和 B，我们已经排除了方案 Y」），然后从零开始。这更费事，但得到的上下文是你亲自决定相关的那些。
什么会导致一次糟糕的 Compact？
如果你跑过大量长会话，你可能注意到有时 compact 效果特别差。我们发现，糟糕的 compact 常常发生在模型无法预测你接下来要往哪走的时候。
比如，一次漫长的调试会话之后 autocompact 触发了，把整个调查过程总结了一下，而你的下一条消息是：「现在修一下我们之前在 bar.ts 里看到的那个 warning。」
但因为会话本身聚焦在调试，那个 warning 很可能在摘要里被丢掉了。
这件事特别棘手，因为受 context rot 影响，模型在触发 compact 那一刻恰好处在「最不聪明」的状态。有了 100 万上下文，你有更多时间主动 /compact，并带上你想做什么的描述。
Subagent 与全新的上下文窗口
Subagent 也是一种上下文管理方式，适合你事先就知道某一块工作会产生大量以后用不上的中间输出的场景。
当 Claude 通过 Agent 工具派生一个 subagent 时，这个 subagent 会得到一个全新的独立上下文窗口。它可以做任意多的工作，然后把结果综合起来，只把最终报告传回给父会话。
我们常用的判断方法是：我之后还会用到这些工具输出吗？还是只要结论就够了？
尽管 Claude Code 会自动调用 subagent，但你也可能想显式告诉它去这么做。比如你可以说：
- 「派一个 subagent，根据下面这份 spec 文件验证这段工作的结果」
- 「派一个 subagent 把另一个代码库读一遍，总结它是怎么实现 auth 流程的，然后你自己用同样的方式实现一遍」
- 「派一个 subagent，根据我的 git 改动，给这个功能写文档」
总结
总结一下：当 Claude 完成一轮、你正准备发下一条消息时，你面前就是一个决策点。
长远来看，我们期望 Claude 自己就能帮你处理好这件事；但现在，这是你引导 Claude 产出的一种方式。
