Claude Code 在长会话里越用越慢，根因是每次请求都要把整段上下文重新发给 API。上下文越长，首字延迟越高，工具调用历史与已读文件又会把大量无关字节堆进前缀，结果是模型推理变慢、费用上升、回答开始丢三落四。要缓解必须从”减税（固定开销）”与”控量（增长部分）”两条线同时治理。
一、为什么长会话会越来越慢
Claude Code 在一次请求里要把以下五类字节全部回传给模型：系统提示、项目根目录的 CLAUDE.md、自动内存、已加载的 MCP 工具定义、对话历史与工具结果。前三类是”固定税”，每轮都付；后两类是”增长量”，会话越长越膨胀。
| 上下文桶 | 来源 | 是否随会话增长 |
|---|---|---|
| 系统提示 | 核心指令与工具 schema | 否 |
| 项目上下文 | CLAUDE.md、自动内存 | 否 |
| MCP 工具定义 | 延迟模式下仅名字，否则全量 | 部分 |
| 工具结果 | read_file、bash 输出 | 是 |
| 对话消息 | 用户消息与助手回复 | 是 |
固定税决定每次请求的底线成本，增长量决定上限。常见的工作场景下，会话从空到 50 轮上下文会从起步的几千 token 涨到几万 token，首字延迟与生成时延都跟着涨。继续放任不管，模型开始出现”重复要求你重新解释””文件读取结果被截断””多步计划漏掉前面步骤”等质量信号。
二、三个最容易被忽略的增长源
工具调用历史是被反复低估的元凶。每一次 readfile、grep、bash 调用都会把完整输出写回前缀。一段中等长度的 bash 输出往往几千 token，几次之后就把前缀撑大；readfile 读入的几百行源代码同样会驻留到会话结束。
重复读取是另一种隐性成本。Claude 在多步任务里经常对同一文件或同一目录多次读取，每次都把内容重新追加到对话历史，前面读到的版本并不会被覆盖。
CLAUDE.md 与自动内存一旦变胖就成了固定税，胖一次影响整段会话。行业建议把 CLAUDE.md 控制在 200 行以内，把冗余流程搬到 Skill 里按需加载，Skill 的内容只在被调用时进入上下文，闲置时为零成本。
三、固定税与增长量的治理顺序
治理要按顺序展开，乱序会导致成本计算失真：
- 先用 /context 看清上下文分布，确认大头在哪一类；
- 精简 CLAUDE.md，删除过时指令，把详细流程拆到 Skill；
- 减少 MCP 工具数，停用 /mcp 中没在用的服务器，优先选用 CLI 工具；
- 在子目录与 .claudeignore 中裁剪无关文件，让 grep / read_file 不再吐出大块无关内容；
- 在同一任务内主动 /compact，而不是等到快满再让系统自动触发；
- 不同任务之间用 /clear 隔离，避免历史互相污染。
顺序的逻辑是：先看清再动刀，先动固定税（一次付出长期生效）再动增长量（每次请求持续付费）。
四、压缩、清空与重绕三种工具的差异
| 命令 | 是否发请求 | 保留内容 | 缓存命中 | 适用场景 |
|---|---|---|---|---|
| /clear | 否 | 加载时已固定的系统提示与项目上下文 | 顶层缓存不变 | 切换到不相关任务 |
| /compact | 是（一次性摘要请求） | 系统提示、项目上下文，加上摘要 | 项目上下文层重新从磁盘加载，命中条件较严 | 同一长任务中途瘦身 |
| /rewind | 否 | 截回到之前某一轮的历史 | 命中早期缓存条目 | 走错方向、想丢弃尾部改动 |
压缩与清空经常被误用。/clear 看起来”杀伤力大”，但因为不发起请求，成本几乎为零，反而是切任务时最经济的动作；/compact 才需要为摘要请求付费，但它保留了任务状态，适合在长任务里瘦身。
压缩前给 Claude 一条具体指令（例如”重点保留测试输出、代码变更与 API 调整”）能显著提升摘要保真度。摘要写进 CLAUDE.md 同样有效：把”压缩时关注 X / Y / Z”写进文件，以后所有会话都默认按这条偏好走。
五、把搜索与读写移出主上下文
主上下文里塞满工具结果是性能黑洞，把这类工作交给子代理是更便宜的做法。Claude Code 内置的 Explore 子代理默认用 Haiku，权限只读，运行在独立上下文窗口，搜索结果只回传一段摘要而不是完整 grep 输出。
要启用，提示词里写明”先用 Explore 搜索整个 src 目录的鉴权相关文件”即可。对自定义场景，可创建专门的子代理：
---
description: 文档巡查代理，仅读权限，使用 Haiku
tools: [Read, Grep, Glob]
model: claude-haiku-4-5
---
梳理 docs/ 目录，给出每篇文档的最后修改时间与一句话摘要，不要回传完整正文。子代理在自己的上下文窗口里工作，主对话只接收几百 token 的结果。这等于把”在主窗口里读 10 个文件”换成”在子窗口里读 10 个文件 + 主窗口收到 1 段摘要”，主上下文的增长量被压到接近零。
六、按场景选择模型与工作模式
模型越强单回合越慢，盲目用 Opus 处理简单任务会让会话更慢也更贵。一个粗略的分层是：架构级决策与复杂重构用 Opus，常规编码与解释用 Sonnet，搜索、巡查、格式整理用 Haiku。
工作模式方面要善用 Plan Mode：进入 Plan Mode 会把工作流切成”先做计划再动手”两段，计划阶段可以反复迭代却不调用修改类工具，避免写错了再回滚的成本。退出 Plan Mode 时如果配合的是 opusplan 模型设置，模型会从 Sonnet 切到 Opus 触发一次缓存重建，耗时比平时多一拍，但计划结果通常更值得这拍等待。
七、几条避免”半夜被会话卡死”的工作习惯
- 同一类任务用同一个会话做到底，不要混进无关的杂活；
- 接近 50% 上下文占用就主动 /compact，不要等到 90% 被动触发；
- 任务跨度大时拆成多个会话，让每个会话的”增长量”从零起步；
- 任何长任务开始前用 /rename 给当前会话命名，方便 /resume 找回；
- 长时间离开前主动 /clear，让下次的缓存从干净状态开始。
常见问题（FAQ）
Q1：/clear 和 /compact 哪个更省？
/clear 不发请求成本几乎为零，/compact 要为摘要请求付费，但能保留任务状态，按需选用。
Q2：为什么开了 MCP 后明显变慢？
每个 MCP 工具定义都进前缀，几十个工具加起来吃 10%–15% 的窗口；用延迟模式或停用闲置服务器能立刻改善。
Q3：怎么判断该 /compact 了？
/context 显示某一项已占满过半，或会话超过几十轮而任务还在同一主题上，就是 /compact 的窗口期。
