跳转至

使用Claude Code：session管理与1M上下文

Ch09.024 使用Claude Code：session管理与1M上下文

📊 Level ⭐⭐ | 15.9KB | entities/使用claude-codesession管理与1m上下文.md

使用Claude Codesession管理与1M上下文

使用Claude Code：session管理与1M上下文

本文来自 Anthropic Claude Code 团队成员，宣布 /usage 工具更新，并基于客户反馈详细指导如何管理 100 万 token 上下文窗口，以减少上下文腐化（context rot）对模型性能的影响。 文章解释了关键技巧：使用 /rewind 回溯修正错误、/compact 主动总结会话、启动子代理处理独立子任务，以及在新任务开始时新建会话，避免不必要文件重读。 这些策略帮助用户在长会话中保持模型高效，作者建议在每个回复后评估分支选项（如继续、压缩或清空），以提升复杂编程任务的可靠性和成本效益。

作者 Thariq（@trq212）是 Anthropic Claude Code 团队成员，曾参与 YC W20 项目，并有 MIT Media Lab 背景。他专注于 AI agent 与上下文管理，致力于打造"通往仁爱机器"的工具，帮助开发者高效利用长上下文窗口。 今天，我们针对 /usage 命令发布了新更新，旨在帮助你更好地了解在使用 Claude Code 时的额度消耗情况。这次更新源于我们与客户的大量交流。 在这些交流中，我们反复发现，用户在管理会话（Session）的方式上存在巨大差异，尤其是在 Claude Code 最近更新支持 ** 100 万（1M）上下文 ** 之后。 你是倾向于在终端里只保持一两个长期开启的会话？还是每发一条指令都开启新会话？你什么时候会用到 compact （压缩）、 rewind （回退）或 subagents （子智能体）？是什么导致了"糟糕的压缩"？ 这里隐藏着惊人的细节，它们会直接塑造你的 Claude Code 使用体验，而核心几乎都指向一点： ** 管理你的上下文窗口 ** 。

上下文、压缩与"上下文腐化"入门

上下文窗口（Context Window）是模型在生成下一个响应时能一次性"看到"的所有内容。它包括你的系统提示词（System Prompt）、此前的对话、每一次工具调用及其输出，以及读取过的每一个文件。Claude Code 拥有高达 ** 100 万 token ** 的上下文窗口。 遗憾的是，使用上下文是有隐含成本的，这通常被称为 ** 上下文腐化（Context Rot） ** 。这种现象是指：随着上下文的增长，模型性能会下降。因为注意力被分散到了过多的 token 上，陈旧且无关的内容开始干扰当前任务的完成。 上下文窗口是一个"硬限制"。当你接近窗口上限时，你需要将当前任务总结成一段较短的描述，并在新的上下文窗口中继续工作，我们称之为 ** 压缩（Compaction） ** 。你也可以手动触发压缩。

每一轮对话都是一个分叉点

假设你刚刚让 Claude 完成了一项任务，现在你的上下文中已经包含了一些信息（工具调用、输出、你的指令）。此时，对于下一步操作，你有以下几种选择：

  • ** 继续（Continue） ** —— 在同一个会话中发送下一条消息。
  • ** 回退（/rewind 或双击 Esc） ** —— 跳回到之前的某条消息，并从那里重新开始。
  • ** 清除（/clear） ** —— 开启一个全新会话，通常带上你从上个会话中提炼的简报（Brief）。
  • ** 压缩（Compact） ** —— 让模型总结目前的会话，并在总结的基础上继续。
  • ** 子智能体（Subagents） ** —— 将下一块工作委托给一个拥有"干净上下文"的代理，只将其最终结果取回。 虽然"继续"是最自然的反应，但其他四个选项才是管理上下文的关键工具。

何时开启新会话？

你是该维持一个长会话，还是开个新的？我们的经验法则是： ** 当你开始一项新任务时，就应该开启一个新会话。 ** 1M 的上下文窗口意味着你现在可以更可靠地处理长任务，例如让它从零开始构建一个全栈应用。 有时你处理的任务相互关联，部分上下文仍有必要，但不需要全部。例如，为你刚刚实现的功能编写文档。虽然你可以开新会话，但 Claude 必须重新读取那些文件，这会更慢且更贵。

用"回退"代替"修正"

如果让我选一个最能体现良好上下文管理习惯的做法，那就是 ** rewind（回退） ** 。 在 Claude Code 中，双击 ** Esc ** （或运行 /rewind ）可以让你跳回之前的任何一条消息并重新下达指令。该点之后的所有消息都会从上下文中移除。 ** 回退通常是比修正更好的方法。 ** 举个例子：Claude 读取了五个文件，尝试了一种方法，结果行不通。你的本能可能是输入"那没用，试试方法 X"。但更好的做法是 ** 回退 ** 到读取文件之后的那一刻，然后结合你刚学到的教训重新发指令："别用方法 A，foo 模块没暴露那个接口——直接用 B 方案。" 你还可以使用"从此处总结"（summarize from here）让 Claude 总结它的经验教训，生成一条"交接消息"。这就像是"未来的 Claude"给"过去的 Claude"留的小便条，告诉它哪里踩坑了。

压缩 vs. 开启新会话

当会话变得冗长时，你有两种减重方式： /compact 或 /clear （重新开始）。它们看起来很像，但逻辑完全不同。 ** Compact（压缩） ** ：要求模型总结目前的对话，然后用摘要替换历史记录。这是 ** 有损的 ** ，你在信任 Claude 去决定哪些信息重要。不过优点是你不需要自己写任何东西，而且 Claude 可能会更全面地保留重要的学习成果或文件引用。你也可以通过指令引导它（例如： /compact 重点关注 auth 重构，丢掉测试调试的部分 ）。 ** Clear（清除） ** ：你亲自动手写下重点（"我们正在重构 auth 中间件，限制条件是 X，相关文件是 A 和 B，已排除方案 Y"），然后干干净净地开始。这更费力，但得到的上下文完全由你掌控。

为什么会产生"糟糕的压缩"？

如果你经常运行长会话，可能会发现有时压缩后的效果很差。我们发现，当 ** 模型无法预测你工作方向 ** 时，通常会发生糟糕的压缩。 例如：在漫长的调试后触发了"自动压缩（autocompact）"，总结了整个排查过程。接着你的下一条消息是："现在修复我们在 bar.ts 中看到的另一个警告。" 但因为之前的会话重点在调试上，那个"另一个警告"可能在摘要中被当做无关信息丢掉了。 这种情况非常棘手，因为受 ** 上下文腐化 ** 的影响，模型在进行压缩处理时，往往处于它能力最弱的时刻。有了 1M 上下文，你有更充裕的时间根据接下来的计划，主动运行带描述的 /compact 。

深度分析

上下文窗口作为稀缺资源

Claude Code 的 1M token 上下文窗口在表面上是一个"充裕"的上限，但文章揭示了一个反直觉的现实：上下文越多，模型性能反而越差。 这种现象被称为"上下文腐化"（Context Rot），其根本机制是注意力分散——当模型需要处理的信息量超过其最佳处理阈值时，有价值的信号被噪声淹没。 值得注意的是，文章并未将上下文腐化描述为一种可以通过工程手段完全消除的缺陷，而是将其定位为一个"隐含成本"——这是对 LLM 在长上下文场景下固有局限性的诚实承认。 1M 上限的存在本身就是一种硬约束，当接近该限制时，用户不得不执行压缩操作，这意味着上下文腐化不是一个是否发生的问题，而是一个何时发生的问题。

"分叉点"框架：每个回复都是决策点

文章提出了一个核心框架：每一轮对话结束都是一个分叉点（bifurcation point），用户面临五个选择：继续、回退、清除、压缩、子智能体。 这个框架的价值在于它将上下文管理从被动的、反应式的行为（等到上下文满了才压缩）转变为主动的、预判式的行为（在每个决策点评估最优路径）。 这种"决策点"思维与传统的"对话流"思维形成了鲜明对比。大多数用户习惯于线性对话模式——发送消息、获得回复、继续对话——而文章暗示这种模式在长上下文场景下是低效甚至危险的，因为它放弃了在每个节点进行上下文优化的机会。

回退优于修正：一种认知模式的转变

文章最违反直觉的建议是：回退（rewind）通常比修正（correct）更好。 传统的修正方式是告诉模型"那样不对，试试 X"，这会往上下文里追加新的错误路径。而回退则是"撤销"错误决策，让模型从正确的节点重新出发。 这背后的洞察是：上下文中的错误路径会持续影响模型的后续推理，即使模型"知道"前面错了，错误的信息仍然占据上下文窗口的空间并干扰注意力机制。 "修正"本质上是追加，而"回退"是真正的撤销。这是一个关于上下文管理认知模式的根本性转变。

压缩的有损性与信任问题

文章指出了 Compact 操作的核心矛盾：压缩是有损的，用户必须信任 Claude 来决定哪些信息重要。 这与编程中"手动管理内存 vs 垃圾回收"的取舍类似——自动压缩提供了便利性，但牺牲了确定性。 糟糕的压缩发生在模型无法预测用户工作方向时。 这一洞察揭示了压缩失败的根本原因：上下文腐化与压缩质量之间存在正反馈循环——上下文越腐化，模型压缩能力越弱；压缩质量越差，上下文越腐化。 1M 上下文只是延缓了这一问题的发生，而没有解决其根本机制。

子智能体：上下文隔离的架构模式

子智能体（Subagents）代表了一种根本不同的上下文管理思路：不是优化当前上下文，而是通过派生独立上下文来规避问题。 当子智能体被派生时，它获得一个"干净的"上下文窗口，完成工作后只将最终结果返回父节点。 这一设计思路与 Agent Harness Context Management Working Set 中描述的 working set 模式有相通之处——两者都试图在有限上下文空间内维持高质量的信号密度。但子智能体的方案更彻底：它通过进程级隔离来完全避免上下文污染，而不是在单一上下文中进行管理。

上下文管理的工程化视角

综合全文，Thariq 的建议指向一个共同主题：上下文管理需要系统化、工程化的方法，而不是依赖直觉或事后补救。这与 Context Window Management 中描述的"上下文工程"（Context Engineering）范式高度一致——将上下文视为需要主动管理的资源，而非被动累积的副作用。 1M 上下文的到来并没有消除管理的重要性，反而因为更大的绝对空间而更需要主动维护。

实践启示

即刻可用的操作建议

  1. 在每个回复后强制评估决策点。当你准备发送下一条消息时，暂停并明确回答：我应该继续、回退、清除、压缩还是派生子智能体？这个习惯比任何工具层面的优化都更重要。
  2. 优先使用回退而非修正。当 Claude 的方法行不通时，用 /rewind 回退到正确的节点重新开始，而不是追加"不要用 A 方法，用 B"这样的修正指令。
  3. 主动压缩而非被动压缩。不要等到 auto-compact 触发才行动。在你知道即将转换任务方向时，手动运行带描述的 /compact：明确告诉 Claude 接下来要做什么，让它据此决定保留哪些信息。
  4. 新任务开新会话。当你开始一项新任务（而非同一任务的延续）时，主动用 /clear 开始新会话，并在 brief 中提炼上一会话的相关结论。
  5. 用"交接消息"沉淀经验。使用"summarize from here"功能生成交接消息，让未来的自己（或未来的 Claude）知道之前的踩坑记录。

子智能体的触发条件

文章给出了判断是否应该派生子智能体的心理测试标准："我以后还需要这些工具的原始输出吗？还是只需要结论？" 如果只需要结论，优先考虑子智能体。这一原则可以进一步具体化为：

  • 复杂调试过程中的验证步骤（只需要通过/失败结论）
  • 代码库调研任务（只需要总结报告）
  • 文档生成（只需要最终文档，不需要中间草稿）

与现有工程实践的整合

对于已经在使用 或 描述的系统进行上下文管理的团队，这篇文章提供了一个补充视角：它更侧重于会话级别的即时决策，而非整体架构层面的设计。在实际工程中，两者需要结合使用——在架构层面确保上下文质量，在会话层面确保决策及时。 对于使用 Claude Code 进行日常开发的个人开发者，这篇文章的操作建议可以在下一次开发会话中立即实践，而不需要任何工具或流程的改变。

相关实体

→ 原文存档