管理 Claude Code 的上下文窗口：别让会话塞满、token 白烧

你刚启动一段 Claude Code 会话时，它很敏锐。两个小时后，它变慢了，开始重新读已经看过的文件，忘掉你一开始设下的约束，使用量也涨得比实际进展更快。不是模型突然变差了，而是上下文窗口里堆满了它已经用不上的东西：旧文件片段、放弃掉的方案、早就处理完的工具输出。

保持上下文轻量，决定了一段长会话是继续又快又省，还是变成一团又慢又贵的负担。核心其实是五个习惯。下面按真实影响从高到低排。

30 秒版

1. subagent 是最大的杠杆。 搜索和跨文件调查交出去，让文件片段留在它们的上下文里，主线程只拿答案。这一条本身就会改变长会话的形态。
2. 无关任务之间用 /clear。 这是最常被低估的命令。重新开始没有成本，而且能把历史负担清零。
3. 单个任务变长时用 /compact。 它会总结已完成内容，保留线程连续性，同时释放空间。接近上限时自动压缩也会触发，但主动在合适节点压缩更好。
4. 限制读取范围。 “读完整个仓库”就是上下文窗口被填满的起点。直接点名文件。
5. 清掉固定税。 臃肿的 CLAUDE.md 和一排常开的 MCP 服务器，会在你还没输入任何内容之前，就在每一轮消耗 token。

为什么上下文会被填满，以及为什么没填满前就已经有代价

当前 Claude 模型的上下文窗口很大，Opus 4.8 大约有 1M token。直觉上，你可能觉得永远用不完。但实际使用里，有两件事会让这个判断失效：

• 窗口没满之前，质量就会下降。 上下文里塞满过期、无关材料时，模型响应会更慢，更容易丢掉主线，每一轮也更贵，因为窗口里的每个 token 都会在每一轮重新处理。一个装着垃圾、占用 60% 的窗口，比一个信号密度高、只占 20% 的窗口更糟。
• 它会安静地累积。 每次读文件、每次跑测试、每次 grep 出一大段、每个放弃掉的方案，都会留在上下文里，除非你清空或压缩。一段两小时的会话，可能带着四十个你只用过一次、之后再也不需要的文件读取结果。

所以，“上下文用完”只是最显眼的故障。真正的成本更早就出现了：会话悄悄变钝、变贵。

1. subagent：杠杆最高的修法

这一条会直接改变 token 账本，所以排在第一。

如果你让主会话去“找一下代码库里哪里处理重试”，它可能会读十个文件，把内容全倒进主上下文，然后基于这些内容推理。更麻烦的是，这十段文件内容会一直留在后续会话里。把同一个问题交给 subagent（Task/Agent 工具，或者你环境里的斜杠式 agent），它会在自己的上下文里完成读取，最后只返回结论：“重试逻辑在 client.ts:88 和 queue.ts:140；模式是这样。”四十次文件读取，回到主线程时变成一段摘要。

规则很简单：凡是需要读很多东西、最后只产出少量结论的步骤，都该交出去。 搜索、审计、“X 在哪里”、总结某个模块如何工作、跨文件调查，都适合交给 subagent。主线程应该是决策记录，而不是所有读过内容的堆放场。多 agent 配置可以继续看管理一支长驻 agent 编队。

2. 无关任务之间用 /clear

这是最便宜的收益，也是最容易因为“顺手继续做”而被跳过的动作。你修完一个 bug，准备转去做一个无关功能时，那个 bug 的上下文没有必要跟着你走。 /clear 会重新开始；模型会为新任务读取它真正需要的东西，不会继续背着旧任务的负担。

反模式是全天不关的单段会话：早上 9 点从一个拼写修复开始，到下午 4 点已经装着你中间碰过的所有互不相关内容。这样的会话，每一轮都要为整段历史付税。把 /clear 当成任务之间的标点。

3. 单个任务变长时用 /compact

有些时候不能清空，因为你还在同一个任务里，需要保留历史。这就是 /compact 的用途：它把正在进行的对话替换成一份摘要，保留决策和当前状态，丢掉产生这些决策的原始材料。你仍然能接着做，但占用空间小得多。

Claude Code 接近窗口上限时也会自动压缩：系统会替你总结对话，让工作继续，不会硬停。这个安全网是真实存在的，但在自然停顿处主动压缩，通常比被迫在思路中间触发自动压缩得到的摘要更干净。不要只依赖自动触发。

4. 限制 Claude 读取的范围

很多上下文膨胀，其实是提示词本身引起的。“先读代码库，然后……”会邀请模型拉进远超任务所需的材料。两个习惯很有用：

• 点名文件或目录。 “看一下 auth/，然后告诉我……”比“看一下这个项目”更好。
• 用忽略规则挡掉噪声。 构建产物、锁文件、随仓库带入的第三方依赖、生成代码，都不该让 agent 随手读到。避免大范围搜索把它们吸进来。让磁盘足迹保持干净的同一套卫生习惯，也会让上下文保持干净。

5. 清掉固定税：CLAUDE.md 和 MCP

这两个东西会在你每一轮对话里消耗 token，而且是在你开口之前就开始消耗；也正因为如此，它们是最容易被忽视的省钱项。

• CLAUDE.md 会被预加载到每段会话里。 你写进去的每一行，都会在整段会话的每一轮里收费。一份 400 行、名义上是“最佳实践”、实际大多是噪声的文件，就是逐轮固定税。保持短小，只留下真正承重的规则。具体做法可以看CLAUDE.md 中 5 个偷烧 token 的坏习惯。
• 每个常开的 MCP 服务器都会把工具定义放进上下文。 连上十几个 MCP 服务器后，不管你用不用，它们的工具定义都会待在窗口里。新版 Claude Code 通过可搜索、延迟加载的工具缓解了一部分问题，工具定义可以按需加载；但原则不变：不用的 MCP 服务器就断开。 工具面越瘦，上下文越轻。

快速决策表

主线只有一句：上下文窗口是工作记忆，不是仓库。 当前步骤需要什么，就放什么；其余内容尽快移出去。这样长会话才能像新会话一样敏锐，而且 token 成本低得多。

什么变化会让这篇文章需要重写

更大的上下文窗口不会让这些习惯过时。只要窗口里有垃圾，每 token 质量就会下降，轻量上下文仍然值得维护。真正会改变细节的是：更聪明的自动上下文裁剪，能保留信号、丢掉文件片段，而不需要手动 /compact；默认按工具隔离上下文；或者 MCP 工具定义在实际调用前完全不进入上下文。2026 年的趋势正在往这个方向走。在那之前，上面这五个习惯就是日常功课。

配套阅读

• CLAUDE.md 中 5 个偷烧 token 的坏习惯 —— 你打字之前就已经在付的逐轮固定税
• Claude Code 默认会过度工程化 —— 生成的代码越少，消耗的上下文越少
• 管理一支长驻 AI agent 编队 —— 多个 agent 之间的上下文隔离
• Claude Code 用量限制怎么算 —— 你正在管理的 token 消耗如何对应到套餐上限
• AI 编程 agent 到底往你磁盘里写了什么 —— 让读取保持干净的忽略规则卫生

来源

1. Claude Code documentation — managing context, /compact and /clear
2. Anthropic — Claude Code best practices
3. r/ClaudeWorkflows — tiered context management and token-reduction workflows (June 2026)
4. Hacker News — “How much $ you spend for AI to code?” (June 18, 2026)

常见问题

为什么 Claude Code 会耗尽上下文？ 每次读文件、每段命令输出、每一轮对话都会累积进窗口。窗口很大，Opus 4.8 大约有 1M token，但质量和成本在真正填满前就会下降。一个满是过期文件片段的会话，会慢、会贵，也会健忘。问题很少是代码库太大，更多是会话带着它已经不需要的东西。

/clear 和 /compact 有什么区别？ /clear 会清空对话，从头开始，适合无关任务之间使用。/compact 会总结对话并保留摘要，释放空间的同时保住连续性，适合同一个任务做到一半、对话已经变长时使用。新任务用 /clear；同一任务变长了，用 /compact。

subagent 能降低 token 使用量吗？ 能。对需要大量探索的工作来说，它是最大的杠杆。把搜索或调查交出去，文件片段会留在 subagent 自己的上下文里；回到主线程的只有结论。四十次文件读取，最后只回来一段摘要。

长会话里怎样降低 token 账单？ 按影响大小排序：把探索交给 subagent；无关任务之间用 /clear；单个任务变长时用 /compact；限制读取范围；清掉固定税。一份臃肿的 CLAUDE.md 和常开不用的 MCP 服务器，都会在每一轮里消耗 token。