概述
这篇文章是 Anthropic 官方发布的 Claude Code 实用指南，针对新推出的 100 万 token 上下文窗口，重点讲解如何高效管理会话，避免上下文衰退（context rot），从而获得更稳定、更高质量的输出。 核心内容要点：
- 每次回复后的 5 种选择（决策点）：Continue、/rewind（双击 Esc）、/clear、Compact（/compact）、Subagents；
- 最佳实践建议：新任务 = 新会话、优先使用 Rewind 而非直接修正、Compact vs. Clear、提前规划 Compact、Subagents 的适用场景；
文章结合实际案例和用户常见痛点，实用性很强，适合所有重度使用 Claude Code 的开发者快速上手高级会话管理技巧。但我更想和大家分享的原因是：Agent如何管理session，如果能够管理好context，你会节约很多token，帮助自己省钱；另一个方面，我们自己在做agent时，应该如何设计这套系统。 文章原文，翻译如下：
今天我们推出了 /usage 的新更新，帮助你更好地理解 Claude Code 的使用情况。这项更新基于我们与众多客户的对话反馈。
在这些对话中反复出现的一个问题是：大家管理会话的方式差异很大，尤其是我们刚刚将 Claude Code 的上下文窗口升级到 100 万 token 之后。你是只开一个会话，还是同时开两三个会话常驻终端？你是每次提示都新建会话吗？什么时候用 compact、rewind 或 subagents？什么情况下 compact 会变差？
这里面有很多细节会显著影响你使用 Claude Code 的体验，而几乎所有细节都来自如何管理上下文窗口。
上下文、压缩与上下文衰退快速入门
上下文窗口是指模型在生成下一个回复时能“看到”的全部内容，包括系统提示、当前对话历史、每次工具调用及其输出，以及所有已读取的文件。Claude Code 的上下文窗口为 100 万 token。
遗憾的是，使用上下文是有轻微代价的，这通常被称为上下文衰退（context rot）。上下文衰退是指：随着上下文增长，模型性能会逐渐下降，因为注意力被分散到更多 token 上，而旧的、无关的内容会干扰当前任务。
上下文窗口是硬性上限。当你快接近窗口上限时，就需要把当前任务总结成更简短的描述，然后在新上下文窗口中继续工作——我们称之为 compact（压缩）。你也可以手动触发压缩。
每次回复都是一个分支点
当你让 Claude 完成一项任务后，上下文里已经积累了工具调用、工具输出和你的指令。这时你有多种选择：
- Continue：在当前会话中继续发送消息（最自然的方式）
- /rewind（双击 Esc）：跳回之前的某条消息，从那里重新开始，后面的消息会被从上下文丢弃
- /clear：新建会话，通常带上你从刚才学到的精炼摘要
- Compact：总结当前会话，然后在总结基础上继续
- Subagents：把下一块工作委托给一个拥有干净上下文的子代理，只把最终结果拉回来
虽然最自然的做法是继续，但另外四种选项正是为了帮助你管理上下文而设计的。
什么时候新建会话？
何时保持长会话，何时新建？我们的经验法则是：开始一项新任务时，就新建一个会话。
100 万上下文窗口确实让你能更可靠地完成更长的任务，例如从零构建一个全栈应用。
有时你会处理相关任务，其中部分上下文仍有必要保留。例如，你刚实现了一个功能，现在要写它的文档。这时如果新建会话，Claude 就需要重新读取你刚实现的文件，这会更慢也更贵。
用 Rewind 而不是直接修正
如果要说哪一个习惯最能体现优秀的上下文管理，那就是 rewind。
在 Claude Code 中，双击 Esc（或输入 /rewind）可以跳回任意之前的消息，从那里重新提示。之后的消息会从上下文中被丢弃。
Rewind 往往是修正错误更好的做法。例如：Claude 读取了五个文件，尝试了一种方案，结果失败了。你的第一反应可能是输入“那没用，试 X 方案吧”，但更好的做法是 rewind 到刚读取完文件的位置，然后用你学到的信息重新提示：“不要用方案 A，foo 模块没有暴露那个接口——直接用方案 B。”
你也可以用“summarize from here”让 Claude 总结它的学习成果，生成一条交接消息，就像未来的 Claude 给过去的自己留的留言：“我试过了，不行。”
压缩 vs. 新建会话
当会话变长后，你有两种减重方式：/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 在一次漫长的调试会话后触发，它总结了整个调查过程，而你下一条消息是“现在去修复我们在 bar.ts 里看到的另一个警告”。因为之前整个会话都在调试，那个警告可能就被总结丢掉了。
这特别棘手，因为由于上下文衰退，模型在执行 compact 时正处于它最不聪明的时候。有了 100 万上下文，你就有更多时间提前 /compact，并附上你接下来想做什么的描述。
子代理与全新上下文窗口
子代理（Subagents）是另一种上下文管理方式，特别适合你事先知道某块工作会产生大量中间输出、之后不再需要的情况。
当 Claude 通过 Agent 工具生成子代理时，子代理会获得一个全新的干净上下文窗口。它可以尽情工作，然后只把最终报告合成后返回给父会话。
我们的心智测试是：我之后还需要这个工具的原始输出吗？还是只需要结论？
虽然 Claude Code 会自动调用子代理，但你也可以明确指示它这么做。例如：
- “启动一个子代理，按照这个 spec 文件验证这项工作的结果”
- “分出一个子代理，去读另一个代码库，总结它是怎么实现 auth flow 的，然后你用同样的方式自己实现”
- “分出一个子代理，根据我的 git 变更写这个功能的文档”
总结
总之，当 Claude 完成一次回复，你准备发送新消息时，你其实站在一个决策点上。
长期来看，我们希望 Claude 能自动帮你处理这些，但目前这是你引导 Claude 输出质量的重要方式之一。
AI 速览
