Created time
Apr 19, 2026 12:59 PM
category
library
date
Apr 16, 2026
status
Published
icon
password
slug
for-claude-code-session-management
type
post
likes
views
summary
如何有效管理ClaudeCode中的会话和上下文，以应对上下文衰减的问题？
tags
Claude
Agent
工程实践
原文链接：https://claude.com/blog/using-claude-code-session-management-and-1m-context 发表日期：2026年4月15日
以下是这篇文章的核心 takeaway：
1. 上下文窗口大，但"上下文衰减"仍然存在
100 万 token 不等于无限。上下文越长，模型注意力越分散，旧内容干扰当前任务，性能会逐渐下滑——这是结构性问题，不能靠"窗口够大"来回避。
2. 新任务 = 新会话，这是最简单的经验法则
任务切换时果断
/clear，而不是无限续杯。除非前一个任务的上下文对新任务仍有实质价值，否则干净的上下文总是更好的起点。3. 走错了就回退，而不是在错误上打补丁
/rewind（双击 Esc）比追加"那不行，试试 X"更有效。回退能保留有价值的文件读取，同时彻底清除失败的尝试，让你从正确的节点重新提示。4.
/compact 与 /clear 的本质区别：谁来写摘要/compact：Claude 来总结，省力但有损，你无法完全控制保留哪些信息
/clear：你来写关键点，费力但精准，上下文完全掌控在自己手里
5. 主动压缩，而不是等到被动触发
自动压缩发生时，模型往往处于衰减最严重的状态——恰恰是最不适合做好总结的时刻。100 万窗口的意义在于：你有足够时间提前
/compact，附上接下来的任务描述，效果远好于被迫触发。6. 压缩效果差的根本原因：方向不可预测
模型不知道你接下来要做什么，就会按当前任务的重心来总结，导致下一步需要的信息被丢弃。用
/compact <hint> 明确告诉它关注点，是关键。7. 子代理的核心判断标准：我需要过程，还是只需要结论？
当某项工作会产生大量中间输出、但你只关心最终结果时，启动子代理是最优解。它拥有独立的干净上下文，噪音不会污染主会话。
8. 五种上下文管理工具，各有适用场景
没有"万能选项"——继续、回退、
/clear、/compact、子代理，每一个都有它最合适的触发时机，理解场景比记住工具更重要。正文：
我们上线了新的斜杠命令
/usage，帮助你随时了解自己在 Claude Code 中的资源消耗情况。这个功能的诞生，源于我们与大量用户的深入交流。我们发现，不同用户在管理会话这件事上差异极大——尤其是在我们将 Claude Code 的上下文窗口升级至 100 万 token 之后，这一现象更加突出。
你是习惯只开一个会话，还是同时在终端维持两个？每次新提示都重开会话？什么时候该用压缩（compact）、回退（rewind）或子代理（subagents）？又是什么让压缩效果变差、会话质量下降？
这些细节，直接决定了你的 Claude Code 体验好不好——而几乎所有这些，归根结底都是如何管理上下文窗口的问题。
上下文、压缩与"上下文衰减"是怎么回事？
上下文窗口，是指模型在生成回复时能"看到"的全部内容——包括系统提示词、当前对话记录、所有工具调用及其输出，以及已读取的文件内容。Claude Code 的上下文窗口为 100 万 token。
但上下文的积累会带来一个副作用，通常被称为"上下文衰减（context rot）"：随着上下文不断增长，注意力被分散到越来越多的 token 上，旧的、不相关的内容开始干扰当前任务，模型性能因此逐渐下滑。
当上下文接近窗口上限时，系统会自动将当前进行中的工作压缩为一段简短摘要，并在新的上下文窗口中继续工作——这个过程就叫做"压缩（compaction）"。你也可以随时手动触发压缩。
每个转折点，都是一个分支
假设 Claude 刚完成了一项任务，此时上下文里已经积累了一些信息（工具调用、输出结果、你的指令）。接下来，你有以下几种选择：
- 继续（Continue） — 在当前会话中直接发送下一条消息。
/rewind（Esc Esc） — 回跳到之前的某条消息，从那里重新出发。
/clear— 开启全新会话，通常带上你从刚才学到的关键要点。
- 压缩（Compact） — 总结当前会话，并在摘要基础上继续推进。
- 子代理（Subagents） — 将下一阶段的工作交给一个拥有独立、干净上下文的代理，只取回它的最终结果。
直接继续当然是最自然的选择，但另外四种方式都是为了帮你更主动地管理上下文。
什么时候该开启新会话？
经验法则：开始一项新任务时，就开启新会话。
100 万的上下文窗口让你可以更稳定地完成长任务（比如从零构建一个全栈应用），但上下文衰减依然存在。
有时任务之间存在关联，部分上下文还有参考价值——比如为你刚实现的功能编写文档。这种情况下你可以开新会话，但 Claude 需要重新读取刚才的文件，既慢又多花成本。如果上下文仍然有用，继续当前会话往往更高效。
优先用"回退"，而不是"修正"
在 Claude Code 中，连按两次 Esc（或运行
/rewind）可以跳回到任意历史消息，并从那里重新提示。该节点之后的消息会从上下文中彻底移除。回退，通常比"补救式修正"更有效。
举个例子：Claude 读取了五个文件，尝试了某种方法但失败了。你的本能反应可能是输入"那行不通，试试 X"。但更好的做法是——回退到文件读取之后，根据你已有的判断重新提示："不要用 A 方法，foo 模块不支持它，直接用 B。"
你也可以让 Claude 先总结本次尝试的收获，生成一条"交接备忘录"，留给下一轮的 Claude 参考——避免重蹈覆辙。
压缩 vs 新会话，该怎么选？
当会话越来越长、需要清理冗余上下文时，你有两条路：
/compact 或 /clear（开新会话）。它们看似相似，实则截然不同。压缩（
/compact）： 让模型自动总结当前对话，用摘要替换历史记录。这个过程是有损的，但你无需自己动手，Claude 在提炼关键学习点和重要文件方面通常比较全面。你也可以通过附加指令来引导压缩的方向，例如：/compact focus on the auth refactor, drop the test debugging。
开新会话（
/clear）： 由你来提炼并写下关键信息——"我们正在重构认证中间件，约束条件是 X，核心文件是 A 和 B，已排除 Y 方案"——然后带着这份摘要重新开始。这需要你多花一点工夫，但最终的上下文完全掌握在你手中。什么会导致自动压缩效果变差？
如果你经常进行长会话，有时会发现压缩的结果不尽如人意。我们发现，当模型难以预判你下一步工作的方向时，压缩质量往往会下降。
典型场景：一次漫长的调试会话结束后触发了自动压缩，摘要聚焦于整个调试过程。而你的下一条消息却是"现在修一下我们在 bar.ts 里看到的另一个警告"——这个警告在调试过程中属于边角信息，极有可能在压缩摘要中被丢弃。
更棘手的是，在接近上下文上限时，模型本身往往处于"上下文衰减最严重"的状态——也就是说，它在最需要做好总结的时刻，反而能力最受限。
好消息是，100 万的上下文窗口给了你更多提前干预的机会——在问题变严重之前，主动使用
/compact 并附上你接下来的操作描述。子代理：一个全新的上下文窗口
当你预判某项工作会产生大量中间过程输出、但最终只需要结论时，子代理（Subagents）是最合适的工具。
Claude 通过 Agent 工具生成子代理时，该子代理拥有独立的、全新的上下文窗口。它可以独立完成所有必要工作，最后只将最终报告返回给父级——中间过程的工具输出噪音，全部留在子代理自己的上下文里。
我们在 Anthropic 内部常用的判断标准是：我还需要这些工具输出本身，还是只需要它们得出的结论？
虽然 Claude Code 会自动调用子代理，但你也可以显式要求它这样做，例如：
- "启动一个子代理，根据以下规范文件验证此次工作的结果"
- "启动一个子代理，通读这个代码库并总结其认证流程的实现方式，然后用同样的方式来实现它"
- "启动一个子代理，根据我的 git 更改为此功能编写文档"
一张表，搞清楚该用哪个
情况 | 建议使用 | 原因 |
同一任务，上下文仍然有价值 | 继续（Continue） | 窗口中的信息仍有用；重建上下文既慢又费成本。 |
Claude 走偏了方向 | 回退（Rewind） | 保留有效的文件读取，丢弃失败的尝试，根据所学重新提示。 |
任务进行中，但会话里堆满了陈旧的调试/探索记录 | /compact <hint> | 低成本；由 Claude 决定保留什么。必要时通过附加指令引导方向。 |
开始一项全新的任务 | /clear | 零衰减；完全由你决定带入什么上下文。 |
下一步会产生大量中间输出，但只需最终结论（代码库搜索、结果验证、文档编写等） | 子代理（Subagent） | 中间过程的工具噪音留在子代理上下文中；父级只获取最终结果。 |
我们期待看到你用这些工具创造出的成果。
立即开始使用 Claude Code。
关于作者： Thariq Shihipar 是 Anthropic 的技术人员，致力于 Claude Code 的开发。