每一轮都是分支点
要点速览
- 上下文腐化 (Context Rot)：随着上下文增长，模型注意力被稀释，旧的无关内容会干扰当前任务
- 每一轮对话都是分支点：继续、回退 (rewind)、清空 (/clear)、压缩 (compact)、子代理 (subagent) 五种选择
- Rewind 优于纠正：回退到出错前重新提示，而不是在已膨胀的上下文中追加更正
- 主动压缩优于自动压缩：在模型还"聪明"时手动 /compact 并附带方向描述，避免自动压缩丢失关键信息
- 子代理是上下文管理手段：把产生大量中间输出的工作委派给子代理，只回收结论
原文链接 English Original by Thariq (@trq212)
今天我们为 /usage 推出了一项新更新，帮助你了解自己在 Claude Code 中的使用情况。这个更新源于与客户的大量对话。
这些对话中反复出现的问题是：会话管理方式因人而异，尤其是在 Claude Code 升级到百万上下文之后。
你是只用一两个终端窗口保持长会话？还是每次提示都开新会话？什么时候用 compact、rewind 或子代理？什么会导致糟糕的压缩？
这里有大量细节会真正影响你使用 Claude Code 的体验，而几乎所有问题都归结于上下文窗口的管理。
上下文、压缩与上下文腐化入门
上下文窗口是模型在生成下一个回复时能"看到"的全部内容。它包括系统提示词、对话历史、每次工具调用及其输出，以及所有被读取的文件。Claude Code 的上下文窗口为一百万 token。
遗憾的是，使用上下文有一个微妙的代价，通常被称为上下文腐化 (Context Rot)。上下文腐化指的是：随着上下文增长，模型性能会下降，因为注意力被分散到更多 token 上，旧的无关内容开始干扰当前任务。
上下文窗口有硬性上限，所以当你接近窗口末尾时，需要将当前工作总结为更简短的描述，然后在新的上下文窗口中继续工作——这就是压缩 (Compaction)。你也可以手动触发压缩。
每一轮都是分支点
假设你刚让 Claude 完成了一项任务，此时上下文中已经有了一些信息（工具调用、工具输出、你的指令），你有出人意料多的选择：
- 继续 — 在同一会话中发送下一条消息
- /rewind (双击 Esc) — 回退到之前的某条消息，从那里重新尝试
- /clear — 开启新会话，通常附带你从刚才学到的内容提炼出的简述
- Compact — 总结当前会话，然后在摘要之上继续
- 子代理 (Subagents) — 将下一块工作委派给拥有独立干净上下文的代理，只把结果拉回来
虽然最自然的做法是直接继续，但另外四个选项的存在正是为了帮助管理上下文。
何时开启新会话
什么时候保持长会话，什么时候开新会话？我们的经验法则是：当你开始新任务时，也应该开启新会话。
百万上下文窗口确实意味着你现在可以更可靠地完成更长的任务，比如从零开始构建一个全栈应用。
有时你可能做的是相关任务，其中部分上下文仍然有用但不是全部。例如，为刚实现的功能编写文档。虽然可以开新会话，但 Claude 得重新读取你刚实现的文件，这会更慢也更贵。
回退优于纠正
如果让我选一个代表良好上下文管理的习惯，那就是 rewind。
在 Claude Code 中，双击 Esc（或运行 /rewind）可以回退到之前任意一条消息，从那里重新提示。该时间点之后的消息会从上下文中移除。
回退通常是比纠正更好的方式。例如：Claude 读了五个文件，尝试了一种方案但失败了。你的直觉可能是输入"那个不行，试试 X"，但更好的做法是回退到文件读取之后，带着你学到的东西重新提示："不要用方案 A，foo 模块没暴露那个接口——直接走方案 B。"
你还可以用"从这里开始总结"让 Claude 总结它的发现并创建一条交接消息——就像未来的 Claude 给过去的自己留的备忘："我试了这个，没用。"
压缩 vs. 全新会话
当会话变长后，你有两种减负方式：/compact 或 /clear（重新开始）。它们感觉相似，但行为截然不同。
Compact 让模型总结当前对话，然后用摘要替换历史记录。这是有损的——你信任 Claude 来判断什么重要，但你不需要自己写任何东西，而且 Claude 在包含重要发现和文件方面可能更全面。你也可以通过附加指令来引导它（/compact 聚焦 auth 重构，丢掉测试调试部分）。
用 /clear 时，你自己写下重要的内容（"我们在重构 auth 中间件，约束是 X，相关文件是 A 和 B，我们已排除方案 Y"）然后干净地重新开始。这需要更多工作，但产生的上下文是你决定的相关内容。
什么导致糟糕的压缩？
如果你经常跑长会话，可能注意过有时压缩效果特别差。我们发现，当模型无法预测你工作的下一步方向时，糟糕的压缩就容易发生。
例如：自动压缩在一段漫长的调试会话后触发，总结了整个调查过程，而你的下一条消息是"现在修一下我们在 bar.ts 里看到的那个警告"。
但因为会话焦点是调试，那个警告可能已经从摘要中被丢弃了。
这尤其棘手，因为受上下文腐化影响，模型在压缩时正处于最不聪明的状态。有了百万上下文，你有更多时间主动 /compact 并附带你要做什么的描述。
子代理与全新上下文窗口
子代理是一种上下文管理形式，适用于你预先知道某块工作会产生大量你不再需要的中间输出。
当 Claude 通过 Agent 工具生成子代理时，该子代理获得自己的全新上下文窗口。它可以做任意多的工作，然后综合结果，只将最终报告返回给父级。
我们使用的心理测试：我还需要这些工具输出，还是只需要结论？
虽然 Claude Code 会自动调用子代理，但你可能想显式地要求它这样做。例如：
- "启动一个子代理，根据这个规格文件验证这项工作的结果"
- "启动一个子代理，阅读另一个代码库并总结它是如何实现 auth 流程的，然后你用同样的方式实现"
- "启动一个子代理，根据我的 git 变更为这个功能写文档"
总结
总而言之，当 Claude 结束一轮对话、你即将发送新消息时，你面临一个决策点。
随着时间推移，我们期望 Claude 能帮你自行处理这些决策，但目前这是你引导 Claude 输出的重要方式之一。
Related Documents
- English Original
- AI 技术博客索引