随着 AI 编程助手进入 Agent 时代，许多专业术语正逐渐为更广泛的开发者群体所熟悉。除了之前讨论过的“Token”，另一个关键概念便是“上下文”以及去年颇受关注的“上下文工程”。
简单来说，上下文窗口指的是大模型在生成下一次回复时，一次性所能看到的所有输入内容的集合。在日常使用 Claude Code 时，理解并管理上下文至关重要。一个典型的 Claude Code 上下文通常包含：系统提示、CLAUDE.md 文件、当前对话历史、每次工具调用及其输出，以及所有已读取的文件内容。
你可以通过输入 /context 命令来查看当前会话的上下文使用详情。
在 Claude Opus 4.6 版本之前，模型的上下文窗口仅有 200K。为了在有限空间内保持 Claude Code 的最佳性能，我曾尝试过多种节省上下文的方案，例如关闭自动压缩以节省约 40K 空间、停用或删除不常用的 MCP 工具、保持 CLAUDE.md 文档尽可能简洁等。
而自 Claude Opus 4.6 起，上下文窗口大幅升级至 100 万 Token，资源瞬间变得充裕。上周，Anthropic 发布了一篇官方博客，专门探讨了 Claude Code 中会话与 100 万上下文的管理方法，这让我对上下文管理有了更深的认识，因此觉得有必要进行解读和分享。
原文地址：https://claude.com/blog/using-claude-code-session-management-and-1m-context
这篇博客的独特之处在于，它将 Claude Code 中本已存在的五种操作放在一起对比：何时继续、何时回退、何时开启新会话、何时压缩、何时使用子代理。每种操作都有其用武之地，但用错了场景代价可能不小。
理解“上下文衰减”
博客开篇引入了一个重要概念：Context rot，可译为“上下文衰减”或“上下文腐烂”。
它指的是随着上下文长度增加，模型的表现会缓慢下降。模型的注意力被更多的 Token 分散，早期那些已不相关的内容开始干扰对当前任务的判断。
在 200K 上下文时代，这个现象还不算特别突出，一个半天内的会话通常能撑过去。而 1M 上下文上线后，反而更容易触发衰减，因为你能塞进去的内容变多了，Claude 判断哪些信息重要、哪些不重要的压力也随之增大。
官方补充了一个关键点：自动压缩动作恰好是在模型注意力已经开始涣散时触发的。也就是说，当 autocompact 自动执行时，可能正是 Claude “最不聪明”的时候。
因此，会话的上下文管理，本质上是在帮助模型将注意力维持在高水平。官方给出的五种管理方案，每一种都对应着不同的目标和场景。
1. 继续：最省心的默认操作
最自然的动作就是继续。
手头任务刚完成一轮，上下文里还保留着有用的文件读取记录和工具输出，此时直接追问下一步是最省事的。
官方的原则很清晰：如果上下文里的内容仍然对后续任务有帮助，就别动它。换成压缩或清空操作，都需要付出重新构建上下文的代价。
判断是否该继续，只需问自己一个问题：下一步需要用到的信息，当前上下文里还在吗？ 如果在，就继续。
2. 回退：比简单说“再试一次”有效得多
这一节是整篇博客中最值得反复品读的部分。
在 Claude Code 中，快速按两下 Esc 键，或输入 /rewind 命令，可以回退到之前的任意一条消息，此后的所有记录都将被丢弃。这个功能其实很早就有了，我印象中是先有双击 Esc 的功能，后来才绑定到 /rewind 命令上。
官方举了一个典型例子：Claude 读取了 5 个文件，尝试了一个方向（A），但失败了。你的第一反应可能是追一句“这个方法不对，换 B 试试”。然而，更好的做法是使用 rewind 回退到读完文件的那一刻，然后带着你获得的新认知重新给出指令，例如：“不要用方案 A，因为 foo 模块并未暴露这个接口，直接尝试方案 B。”
这个区别看似细微，实际效果天差地别。追加一条纠正消息，上下文中会留下“失败的尝试”以及“纠正”两层信息，Claude 需要从中推断你真正的意图。而 rewind 之后，那段失败的尝试直接消失了，Claude 看到的是一份干净的、融入了你最新理解的指令。
一句话总结：rewind 是在帮 Claude 擦除错误的记忆。
官方还提到一个进阶用法：配合“summarize from here”功能或另一个 /rewind 命令，先让 Claude 将踩坑学到的东西总结成一段交接说明，再回退并带上这段说明重新开始。这相当于让它给“未来的自己”留一张便条。
这个操作的价值我一直低估了。双击 Esc 这个动作太不起眼，以至于很多人甚至没意识到它的存在。
3. /clear：手动编写任务简报，开启全新会话
官方给了一条朴素的原则：开始一个全新的任务时，就开启一个新的会话。
这条规则听起来简单，但执行时容易被惰性拖累。比如，在同一个终端里，改完后端代码接着写文档，顺手就让 Claude 继续跑下去了。问题在于，写文档这个任务很可能用不上后端接口的那些实现细节。带着旧的上下文继续，除了消耗更多 Token，并无实际益处。
/clear 的定位是：由你亲自将重要的信息提炼并写入提示词。 例如：“我们正在重构认证中间件，约束条件是 X，相关文件是 A 和 B，已经排除了 Y 方案。” 这段话将成为新会话的起点。
这比使用 compact 更费事，因为需要你自己动笔。但换来的是一份由你亲自筛选过的、干净的上下文。
我个人的习惯是：新任务一定用 /clear，除非非常明确地知道旧上下文中的文件读取对新任务依然有用（例如刚实现完功能紧接着写对应的单元测试），这种情况就直接“继续”。
4. /compact：省事但有损，最好手动触发
/compact 的原理是，将之前的对话历史交给模型自行总结，然后用总结文本来替换原始的历史记录。
这个操作是有损的，但好处是你无需亲自动笔。你还可以通过提示词来引导它，例如输入 /compact focus on the auth refactor, drop the test debugging，告诉它应该关注什么、舍弃什么。
官方解释了为什么自动压缩有时会“翻车”。核心原因在于：模型执行压缩时，它并不知道你下一步要做什么。
博客举了一个具体场景：一段漫长的调试会话之后，自动压缩被触发，总结出一份关于项目调试过程的要点。而你下一句输入的是：“现在去修复 bar.ts 里的另一个警告。” 但那个警告只是你之前随口提过，在调试会话中并未深入讨论，很可能在压缩时就被当作无关信息丢弃了。
再加上前面提到的“上下文衰减”问题——自动压缩触发的时间点，恰好是 Claude 注意力可能已经开始涣散的时候。这就相当于让一个已经分心的人去决定什么重要、什么不重要，结果可想而知。
我在 200K 上下文时代曾写过一篇文章，专门讲解为何要关闭自动压缩（在 /config 中将 Auto-compact 设为 false）。具体可以参考相关教程。
关闭自动压缩后，就需要自己判断何时手动执行 /compact。1M 上下文的好处在于，你有更多的时间在问题出现之前主动进行压缩，而且主动压缩时可以附加提示，引导 Claude 保留哪些关键信息。
5. Subagents：仅当只需最终结论时启用
关于子代理的用法我之前写过专门教程，这里重点讲博客中最核心的心法。
官方的判断标准只有一句话：你后续还会用到这个探索过程中的中间输出吗？还是只需要它的最终结论？
如果只需要结论，就开启子代理。如果还需要用到中间产出，就不要开。
举个例子：让 Claude 在一个庞大的代码库中搜索关键字并进行归纳，这个过程会产生海量的中间文件读取记录。这些记录对你没有直接用处，你只要最后那份归纳报告。这种场景，子代理就是完美匹配：它会在自己全新的上下文窗口中完成所有工作，只把最终的结论带回到主会话中。
官方提供了几个可以直接套用的提示词示例：
- Spin up a subagent to verify the result of this work based on the following spec file
- Spin off a subagent to read through this other codebase and summarize how it implemented the auth flow, then implement it yourself in the same way
- Spin off a subagent to write the docs on this feature based on my git changes
需要特别注意的是，在 Opus 4.7 升级后，模型对自动开启子代理比 4.6 版本克制了许多，之前很多会自动开启的场景现在不会了。因此，在 4.7 版本下，如果你明确知道某个任务适合用于代理，最好在提示词中明确写出来，不要指望它自动判断。
总结与决策指南
博客最后提供了一张清晰的决策对照表，我已将其翻译为中文。当你面临选择困难时，参照这张表来决策即可。
这张表是整篇博客最值得强化记忆的部分。在中文技术社区，很少见到将这五种操作放在一起讲清楚的材料，因此深入学习还得参考这类优质的官方文档。
顺带一提，博客开头还提到了一个新上线的斜杠命令 /usage，用于查看 Claude Code 的使用情况统计，辅助你进行会话管理的决策。
使用一段时间后的感受是，Claude Code 的这些功能其实一直都在，只是很少有人将它们系统地梳理清楚。100 万上下文给了我们更大的操作空间，也让每一次关于会话管理的决策变得更有价值。
这也提醒我们，在深度学习和 AI 工具飞速发展的今天，认真研读核心的一手技术资料，对于提升开发效率至关重要。如果你对这类 AI 编程实战技巧感兴趣，欢迎在云栈社区与更多开发者交流心得。
发表于 2 小时前
|
查看: 4|
回复: 0
