使用 Claude Code：会话管理和 100 万上下文

你如何在 Claude Code 中管理会话、上下文和压缩，比你想象中更影响最终效果。这里是一份实用指南，帮你在每一步做出合适选择。

我们发布了 /usage，这是一个新的 slash command，用来帮助你了解自己在 Claude Code 中的用量。这个功能来自我们和许多客户交流后的反馈。

在这些交流中，一个反复出现的问题是：用户管理会话的方式差异很大，尤其是在 Claude Code 新增 100 万上下文之后。

你是只在终端里长期保留一个会话或两个会话？还是每次输入 提示词 都开启一个新会话？你什么时候会用 compact、rewind 或 子Agent？什么会导致一次糟糕的 compact 或糟糕的会话？

这里的细节比想象中多，而且真的会影响你使用 Claude Code 的体验；其中几乎所有问题都来自对 上下文窗口 的管理。

快速理解 context、compaction 和 context rot

上下文窗口 指的是模型在生成下一次回复时一次性能“看到”的全部内容。它包括 system 提示词、到目前为止的对话、每一次 tool call 及其输出，以及所有被读取过的文件。Claude Code 的 上下文窗口 是 100 万 tokens。

遗憾的是，使用更多 context 会轻微影响性能，这通常被称为 context rot。context rot 指的是：随着 context 变长，模型性能会下降，因为注意力被分散到更多 tokens 上，较早的、无关的内容也开始干扰当前任务。

上下文窗口 有硬性上限，所以当你接近 上下文窗口 末尾时，你正在处理的任务会被自动总结成一段更短的描述，然后模型会在新的 上下文窗口 中继续工作。我们把这个过程叫做 compaction。你也可以手动触发 compaction。

每一轮都是一个分支点

假设你刚让 Claude 做了一件事，并且它已经完成了。现在 context 里有了一些信息（tool calls、tool outputs、你的指令），接下来你其实有很多选择：

• Continue：在同一个会话里继续发送下一条消息

• /rewind（esc esc）：跳回之前的某条消息，并从那里重新尝试

• /clear：开始一个新会话，通常会带上一份你从刚才经验中提炼出的简短说明

• Compact：总结到目前为止的会话，然后基于这份总结继续

• 子Agent：把下一段工作委派给一个拥有干净 context 的 Agent，只把它的结果带回主会话

最自然的做法通常是直接继续，但另外四个选项存在的目的，都是帮你管理 context。

什么时候开启新会话

什么时候该保留一个长期运行的会话，什么时候该开启新会话？我们的通用经验是：开始一个新任务时，也应该开始一个新会话。

虽然 100 万 上下文窗口 让你现在可以更可靠地完成更长的任务，比如从零构建一个 full-stack app，但 context rot 仍然可能发生。

有时你会做一些相关任务，其中一部分 context 仍然有用，但并不总是如此。比如，为你刚实现的功能写文档。虽然你可以开启新会话，但 Claude 就必须重新读取你刚实现过的文件，这会更慢，也更贵。

用 rewinding 代替直接纠正

在 Claude Code 中，双击 Esc（或运行 /rewind）可以让你跳回任意一条之前的消息，并从那里重新输入 提示词。该时间点之后的消息会从 context 中删除。

Rewind 通常是更好的纠正方式。比如，Claude 读取了五个文件，尝试了一种方案，但没有成功。你的直觉可能是输入“那样不行，改试 X”。但更好的做法可能是 rewind 到刚读完文件之后，再带着你刚学到的信息重新 提示词：“不要用方案 A，foo module 没有暴露那个接口，直接走 B。”

你也可以使用“summarize from here”或 /rewind slash command，让 Claude 总结它学到的东西并创建一条交接消息，有点像未来的 Claude 写给上一轮 Claude 的留言：我试过某个方案，但它行不通。

Compacting 与开启全新会话的区别

当一个会话变长后，你有两种方式丢掉多余的 context：/compact 或 /clear（然后重新开始）。它们感觉相似，但行为非常不同。

Compact 会让模型总结到目前为止的对话，然后用这份总结替换原有历史。它会有信息损失，但你不需要自己写任何内容，而且 Claude 可能会更完整地包含重要发现或文件。你也可以通过传入指令来引导它（/compact focus on the auth refactor, drop the test debugging）。

使用 /clear 时，你需要自己写下重要内容（“我们正在重构 auth middleware，约束是 X，相关文件是 A 和 B，我们已经排除了方案 Y”），然后干净地重新开始。这更费事，但最终进入 context 的内容，是由你决定哪些才相关。

什么会导致糟糕的 autocompact？

如果你经常运行很长的会话，可能会注意到有些时候 compact 的效果特别差。我们经常发现，当模型无法预测你的工作接下来要往哪个方向走时，就容易出现糟糕的 compact。

在上面的例子中，autocompact 在一段很长的调试会话之后触发，模型总结了这次排查，而你的下一条消息是：“现在修一下我们在 bar.ts 里看到的另一个 warning。”

但因为整个会话都聚焦在调试上，那个“另一个 warning”可能已经从总结中被丢掉了。

这尤其棘手，因为受 context rot 影响，模型在 compact 时往往正处于最不聪明的状态。有了 100 万 context，你有更多时间主动使用 /compact，并说明你接下来想做什么。

子Agent 和全新的 上下文窗口s

当你提前知道某一段工作会产生大量中间输出，而且之后不再需要这些输出时，子Agent 往往很好用。

当 Claude 通过 Agent tool 启动 子Agent 时，这个 子Agent 会获得自己的全新 上下文窗口。它可以完成所需的全部工作，然后把结果综合起来，只把最终报告带回父会话。

我们在 Anthropic 使用的判断方式是：我之后还需要这些 tool output，还是只需要结论？

虽然 Claude Code 会自动调用 子Agent，但你可能也会想明确告诉它这样做。例如，你可以告诉它：

• “启动一个 子Agent，根据下面这个 spec file 验证这项工作的结果”

• “派出一个 子Agent 阅读另一个 代码库，总结它是如何实现 auth flow 的，然后你自己用同样方式实现”

• “派出一个 子Agent，根据我的 git changes 为这个功能写文档”

整合起来看

为了帮助你选择该使用哪种 context 管理功能，我们整理了这张实用表格，说明常见场景、应该使用什么工具，以及原因。

期待看到你构建出的成果。

今天就开始使用 Claude Code。

关于作者：Thariq Shihipar 是 Anthropic 的技术团队成员，负责 Claude Code。