# 使用 Claude Code：会话管理与百万级上下文窗口的策略

- 来源：Thariq (@trq212)
- 发布时间：2026-04-16 06:47
- AIHOT 分数：72
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmo0p96zy026ksli2n2u47nfc
- 原文链接：https://x.com/trq212/status/2044548257058328723

## 精选理由

Claude Code 1M 上下文听着爽，但 context rot 在 300k 就开始咬你了。这篇把 rewind、compact、subagent 三个操作的使用时机讲得极清楚，是目前最实用的 Claude Code 上下文管理指南，重度用户必读。

## AI 摘要

Claude Code 的百万级上下文窗口在支持长任务的同时，也带来了“上下文腐化”的风险，即模型性能可能在处理约30-40万token后开始下降。因此，有效的会话管理至关重要。关键策略包括：开启新任务时建议新建会话；对于关联任务可酌情保留上下文以提升效率；善用 `/rewind` 回退功能而非直接纠正错误，是维护上下文清洁的核心习惯。用户在每个对话轮次后，应根据情况选择继续、回退、新建会话、压缩或使用子代理。

## 正文

http://x.com/i/article/2044537014620721153

# 使用 Claude Code：会话管理与 1M 上下文

在我近期与 Claude Code 用户的交流中，有一个主题反复出现：100 万模型 token 的上下文窗口是一把双刃剑。

它让 Claude Code 能够更长时间地自主运行，更可靠地处理任务，但如果你不刻意管理好自己的会话，它也为上下文污染敞开了大门。

会话管理比以往任何时候都更重要，而且似乎有很多人对此有疑问。你是在一个终端里保持一个会话打开，还是两个？每次提示词都从头开始？什么时候应该使用压缩、回退或子智能体？什么导致了糟糕的压缩？

这里涉及的细节数量惊人，它们能真正塑造你使用 Claude Code 的体验，而几乎所有这些都来自于你如何管理上下文窗口。

## 关于上下文、压缩与上下文衰减的快速入门

上下文窗口是模型在生成下一次响应时能“看到”的全部内容。它包括你的系统提示词、到目前为止的对话、每一次工具调用及其输出，以及每一个被读取过的文件。Claude Code 的上下文窗口有 100 万模型 token。

不幸的是，使用上下文会带来一点代价，这通常被称为上下文衰减。上下文衰减是指：随着上下文增长，模型性能会下降，因为注意力被分散到更多模型 token 上，而较旧的、不相关的内容开始干扰当前任务。对于我们的 100 万模型上下文模型，我们在大约 30 万到 40 万模型 token 左右观察到一定程度的上下文衰减，但这在很大程度上取决于任务——并非绝对规则。

上下文窗口是一个硬性截断，因此当你接近上下文窗口的末尾时，你需要将你一直在处理的任务总结成更简短的描述，然后在一个新的上下文窗口中继续工作，我们称之为压缩。你也可以自己触发压缩。

# 每一次交互都是一个分支点

假设你刚刚让 Claude 做某件事并已完成，现在你的上下文中已经有了一些信息（工具调用、工具输出、你的指令），而下一步你有数量惊人的选择：

- 继续——在同一会话中发送另一条消息

- /rewind (esc esc)——跳回到之前的某条消息，并从那一点重新开始

- /clear——开始一个新会话，通常以你从刚才所学中提炼出来的简报为起点

- 压缩——总结到目前为止的会话，并在此总结之上继续推进

- 子代理——将下一部分工作委派给一个拥有自己清洁上下文的代理，只将其结果拉回。

虽然最自然的方式是继续，但其他四个选项的存在是为了帮助你管理上下文。

## 何时开始新会话

新的1M上下文窗口意味着你现在可以更可靠地执行更长的任务，例如让它从头构建一个全栈应用。但仅仅因为你的模型没有耗尽上下文，并不意味着你不应该开始一个新会话。

我们的一般经验法则是：当你开始一个新任务时，你也应该开始一个新会话。

一个灰色地带是，你可能想做相关的任务，其中部分上下文仍然是必要的，但不是全部。

例如，为你刚实现的功能编写文档。虽然你可以开始一个新会话，但Claude将不得不重新阅读你刚实现的文件，这会更慢且更昂贵。由于文档可能不是一个高度智能敏感的任务，额外的上下文可能值得获得不必重新阅读相关文件的效率提升。

## 回退而非纠正

如果我必须选一个标志良好上下文管理的习惯，那就是回退。

在Claude Code中，双击Esc（或运行 /rewind）可以让你跳回到之前的任何消息，并从那里重新提示。该点之后的消息会从上下文中丢弃。

回退通常是更好的纠正方法。例如，Claude读取了五个文件，尝试了一种方法，但没有成功。你的本能可能是输入“那行不通，试试X”，但更好的做法是回退到刚读完文件之后，并用你学到的东西重新提示。“不要使用方法A，foo模块没有暴露那个——直接去B。”

你也可以使用“从这里总结”来让Claude总结它的所学并创建一个交接消息，有点像未来的Claude自己给之前的Claude迭代发送消息，说尝试了某事但没有成功。

## 压缩 vs. 全新会话

当会话变长时，你有两种方法来减轻负担：/compact 或 /clear（然后重新开始）。它们感觉相似，但行为截然不同。

Compact 要求模型对到目前为止的对话进行总结，然后用该总结替换历史记录。这是一种有损压缩，你需要信任 Claude 来决定哪些内容重要，但你无需自己动手写任何东西，而且 Claude 在包含重要的经验或文件方面可能更彻底。你也可以通过传递指令来引导它（例如 `/compact focus on the auth refactor, drop the test debugging`）。

使用 /clear 时，你可以写下重要的内容（例如“我们正在重构身份验证中间件，约束条件是 X，关键文件是 A 和 B，我们已经排除了方案 Y”），然后开始全新的对话。这需要更多工作，但最终得到的上下文是由你自己决定的相关内容。

## 什么导致糟糕的 Compact？

如果你运行过很多长时间运行的会话，你可能注意到有时候压缩效果特别差。在这种情况下，我们经常发现，当模型无法预测你的工作方向时，糟糕的压缩就会发生。

例如，自动压缩在长时间调试会话后触发，总结了调查过程，而你下一条消息是“现在修复我们之前在 bar.ts 中看到的那个警告。”

但由于会话专注于调试，那个警告可能已从总结中被丢弃。

这尤其困难，因为由于上下文腐烂，模型在压缩时处于其最不智能的状态。借助一百万上下文窗口，你有更多时间主动使用 /compact，并附上你想要做什么的描述。

## 子智能体与全新上下文窗口

子智能体是上下文管理的一种形式，适用于当你事先知道某块工作会产生大量你之后不再需要的中间输出时。

当 Claude 通过 Agent 工具生成一个子智能体时，该子智能体会获得自己全新的上下文窗口。它可以执行所需的所有工作，然后综合其结果，使得只有最终报告返回给父智能体。

我们使用的心理测试是：我之后还需要这个工具的输出吗，还是只需要结论？

虽然 Claude Code 会自动调用子智能体，但你可能会想明确告诉它这样做。例如，你可能会想告诉它：

- “启动一个子智能体，根据以下规范文件验证这项工作结果” - “分出一个子智能体，阅读另一个代码库并总结它是如何实现身份验证流程的，然后你自己以相同方式实现” - “分出一个子智能体，根据我的 git 变更为此功能编写文档”

# 总结

总之，当 Claude 结束一轮对话、你准备发送新消息时，你需要做出一个决策。

我们预计随着时间的推移，Claude 会自行帮你处理这一点，但目前，这是你可以引导 Claude 输出的方式之一。