使用 Claude Code：会话管理与 1M 上下文窗口

在我最近与 Claude Code 用户的交流中，一个主题反复出现：100 万 token 的上下文窗口是一把双刃剑。

它让 Claude Code 能够更长时间地自主运行，更可靠地处理任务，但如果你不刻意管理会话，它也为上下文污染打开了大门。

会话管理变得前所未有地重要，围绕这个话题也有大量疑问。是保持一个终端会话还是两个？每次 prompt 都重新开始？什么时候该用压缩、回溯或子 Agent？什么会导致糟糕的压缩？

这里有很多出人意料的细节，能真正影响你使用 Claude Code 的体验，而几乎所有这些都取决于你如何管理上下文窗口。

上下文窗口是模型在生成下一个回复时能同时"看到"的所有内容。它包括你的系统 prompt、到目前为止的对话、每一次工具调用及其输出、以及每一个被读取的文件。Claude Code 的上下文窗口为 100 万 token。

然而，使用上下文是有代价的，这通常被称为上下文衰减（context rot）。上下文衰减指的是随着上下文增长，模型性能会下降——因为注意力被分散到更多 token 上，而旧的、不相关的内容开始干扰当前任务。对于我们的 100 万 token 上下文模型，我们观察到大约在 30-40 万 token 左右会出现一定程度的上下文衰减，但这高度依赖于具体任务，并非固定规律。

上下文窗口是一个硬性截断点，所以当你接近上下文窗口的末尾时，你需要将当前任务总结成更小的描述，然后在一个新的上下文窗口中继续工作，我们称之为压缩（compaction）。你也可以手动触发压缩。

假设你刚刚让 Claude 完成了一件事，你的上下文中现在有了一些信息（工具调用、工具输出、你的指令），接下来你有一系列出人意料的选择：

继续（Continue）——在同一个会话中发送下一条消息

/rewind（连按两次 Esc）——跳回到之前的某条消息，从那里重新开始

/clear ——开始一个新会话，通常带着你从刚才学到的内容中提炼的简报

压缩（Compact）——将会话到目前为止的内容总结，然后在总结的基础上继续

子 Agent（Subagents）——将下一块工作委派给一个拥有独立干净上下文的 Agent，只把结果拉回来

虽然最自然的方式就是继续，但其他四个选项的存在都是为了帮助你管理上下文。

新的 100 万 token 上下文窗口意味着你现在可以更可靠地完成更长的任务，比如让它从零构建一个全栈应用。但仅仅因为模型还没有耗尽上下文，并不意味着你不应该开始新会话。

我们的经验法则是：当你开始一个新任务时，也应该开始一个新会话。

一个灰色地带是，你可能想做相关任务，其中部分上下文仍然是必要的，但并非全部。

比如，为你刚实现的功能编写文档。虽然你可以开一个新会话，但 Claude 需要重新读取你刚实现的文件，这会更慢、更昂贵。由于文档编写可能不是一个对智能高度敏感的任务，额外的上下文可能值得为了不重新读取相关文件而获得的效率提升。

如果要我选一个标志着良好上下文管理的习惯，那就是回溯。

在 Claude Code 中，连按两次 Esc（或运行 /rewind）可以让你跳回到任意一条之前的消息，从那里重新 prompt。该时间点之后的消息会从上下文中移除。

回溯通常是更好的纠错方式。比如，Claude 读取了五个文件，尝试了一种方案，但行不通。你的本能可能是输入"那个不行，试试 X 吧"，但更好的做法是回溯到文件读取完成之后，用你学到的东西重新 prompt："不要用方案 A，foo 模块没有暴露那个接口——直接用 B。"

你也可以使用"summarize from here"让 Claude 总结它的发现并创建一条交接消息，就像来自未来的自己给之前的 Claude 版本留的一条消息。

一旦会话变长，你有两种方式来减轻上下文负担：/compact 或 /clear（然后重新开始）。它们感觉类似，但行为截然不同。

压缩（Compact）会让模型总结到目前为止的对话，然后用总结替换历史记录。这是有损的——你信任 Claude 来决定什么重要，但你不需要自己写任何东西，而且 Claude 可能会更全面地保留重要的发现和文件。你还可以通过传入指令来引导它（比如 /compact focus on the auth refactor, drop the test debugging）。

使用 /clear 时，你自己写下重要的内容（"我们在重构认证中间件，约束条件是 X，重要的文件是 A 和 B，我们已经排除了方案 Y"），然后从头开始。这需要更多工作，但生成的上下文完全是你认为相关的内容。

如果你经常运行长时间的会话，你可能注意到有些时候压缩效果特别差。我们发现，糟糕的压缩通常发生在模型无法预测你的工作方向时。

比如，自动压缩在一次漫长的调试会话后触发，总结了调查过程，然后你的下一条消息是"现在修复我们在日志里看到的另一个警告"。

但由于会话聚焦在调试上，那个其他警告可能已经从总结中被丢弃了。

这尤其困难，因为由于上下文衰减，模型在压缩时正处于它最不聪明的时刻。有了 100 万的上下文窗口，你有更多时间主动执行 /compact，并描述你接下来想做什么。

子 Agent 是一种上下文管理方式，适用于你预先知道某块工作会产生大量你不再需要的中间输出的场景。

当 Claude 通过 Agent 工具生成子 Agent 时，该子 Agent 会获得自己全新的上下文窗口。它可以根据需要做尽可能多的工作，然后综合其结果，只有最终报告会返回给父 Agent。

我们使用的思维测试：我会再次需要这个工具输出吗，还是只需要结论？

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

"启动一个子 Agent，根据以下规格文件验证这项工作的结果"

"派一个子 Agent 通读另一个代码库，总结它是如何实现认证流程的，然后你用同样的方式来实现"

"派一个子 Agent 根据我的 git 变更为这个功能编写文档"

总结来说，当 Claude 结束了一个回合，你准备发送新消息时，你面临一个决策点。

随着时间的推移，我们期望 Claude 能帮你自动处理这些，但目前这是你可以引导 Claude 输出的方式之一。