Claude Code 报 Error during compaction 怎么解决？三种压缩报错要分开治
用 Claude Code 干长活的人，迟早会在某一次 /compact 之后看到一行红字，然后整个会话卡在那儿——上下文满了压不下去，想接着干也干不了。
麻烦的是，「压缩失败」在 Claude Code 里其实是三种不同的报错，长得像，成因完全不一样，解法也不通用。网上很多帖子把它们混在一起讲，照着做没效果，多半就是治错了病。这篇按报错原文把它们拆开，并且明确标出哪些是官方文档给的做法、哪些只是社区的绕过办法、哪些到今天仍然没有定论。
一、先对号入座：你看到的是哪一条
Error during compaction: Conversation too long
Not enough messages to compact.
Autocompact is thrashing: the context refilled to the limit...
三条报错对应三种完全不同的处境：
| 报错 | 实际发生了什么 | 治的方向 |
|---|---|---|
Conversation too long | 压缩这个动作本身要占上下文，但剩余空间已经装不下生成的摘要了 | 先腾出一点空间，再压 |
Not enough messages to compact. | 对话轮数太少，没东西可总结 | 不是故障，换个思路处理 |
Autocompact is thrashing | 压缩成功了，但立刻又被灌满，连续几次后系统主动停手 | 治「谁在灌满它」 |
第一条最常见，第三条最容易被误判成第一条。先看清楚自己是哪一条，再往下走——这一步省下的时间比后面所有步骤加起来都多。
二、Conversation too long：压缩自己也要占地方
这条报错的反直觉之处在于：你是因为上下文快满了才去压缩的，结果它告诉你因为太满所以压不了。
原因不难理解。/compact 的工作方式是让模型读一遍现有对话、写出一份摘要，然后用摘要替换掉原文。写摘要这个动作本身要占输出空间，如果剩余窗口连摘要都放不下，这一步就失败了。所以它不是「压缩坏了」，而是你启动压缩启动得太晚了。
官方给的做法
官方错误参考页对这条的处理是三步，按顺序试：
- 按两次 Esc，打开消息列表，往回退几条消息
- 回退之后再运行
/compact - 如果回退腾出的空间仍然不够，直接
/clear
第一步是关键，也是最容易被跳过的一步。往回退几条消息意味着把最近那几轮从上下文里摘出去——通常正是那几轮里有一次超大的文件读取或工具输出，把窗口撑爆的就是它们。退掉之后再压，成功率会明显不一样。
如果你不确定该退到哪里，运行 /context 看一眼上下文的消耗构成，哪一块占得离谱一眼就能看出来。
社区在 issue #7530 里给的绕过办法
官方三步不管用的时候，还有一条流传比较广的路子。先说清楚：这是社区在 GitHub issue #7530（已关闭，134 条评论）里给出的绕过办法，官方文档没有收录，也没有确认过。
那条高赞评论给的步骤是：
^C^C（连按两次 Ctrl+C 退出claude）- 重新运行
claude /resume恢复上一个会话- 再执行
/compact
评论者称自己试了约 30 次全部成功。同一个帖子里还有人反映，在剩余 25%、甚至 12% 的时候也照样撞上这条报错——这说明它并不严格等于「上下文完全用尽」，所以你在还有空间的时候遇到它，不必怀疑自己看错了。
为什么退出重进会有用，公开信息里没有解释。这是一条经验性的绕过办法，不是原理性的修复，能不能用要你自己试。好消息是它没有破坏性：退出 claude 不会丢对话，/resume 能在同一目录接回来。
三、Not enough messages to compact.：这不是故障
看到这条，很多人的第一反应是「明明上下文都满了，怎么会没东西压」。
官方排查页专门解释过这个看起来矛盾的情况：即使上下文已经满了，也可能出现这条提示——典型场景是你一次性粘贴了一大段内容，一下就把窗口灌满了，但对话轮数只有寥寥几轮。摘要是从「多轮对话」里提炼的，只有两三轮、其中一轮特别巨大，就没有可总结的结构。
所以这条不该按报错治。对的做法是处理那一大坨内容本身：
- 如果那段内容来自文件，别粘贴，改成按路径让 Claude 去读——官方在
Request too large那条里给的也是同一个建议：按路径引用大文件，而不是把内容贴进去 - 如果确实需要它在上下文里，让 Claude 分块读，比如指定行号区间或某个函数
- 如果那段内容已经用完了，直接
/clear重开更省事
四、Autocompact is thrashing：压缩没坏，是有人一直在灌
这条报错的完整形态是 Autocompact is thrashing: the context refilled to the limit...，意思官方写得很直白：自动压缩成功了，但一个文件或工具输出立刻又把上下文灌满，连续好几次都这样。Claude Code 于是主动停止重试，避免在一个不前进的循环里空烧 API 调用。
这是三条里唯一一条系统主动踩刹车的。它不是失败，是保护。
官方给的四条恢复办法：
- 让 Claude 分块读那个超大文件——指定行号区间或某个函数，而不是整个读进来
- 运行
/compact时带上重点，把大输出丢掉，例如/compact keep only the plan and the diff - 把涉及大文件的工作交给子代理去做，子代理跑在独立的上下文窗口里，不会污染主会话
- 前面的对话已经不需要了，就
/clear
第三条是四条里最值得记住的。子代理有自己的上下文窗口，让它去啃那个大文件、只把结论带回来，主会话就不会被原始内容撑爆。很多人是在反复撞上 thrashing 之后才想起来还有这个用法，其实它本来就是为这类场景准备的。
第二条那个写法也值得单独说一句：/compact 是可以带指示的，不是只能光秃秃地敲。你告诉它保留什么，摘要就会围着那部分组织，被大输出挤掉重点的概率会小很多。
五、怎么确认自己真的修好了
压缩类的问题有个讨厌的地方：当时看起来好了，干十几分钟又回来了。所以别只看「这次没报错」，按下面两条确认：
/context看构成。压缩之后跑一次，看占比最大的那块是不是降下来了。如果压完之后某个大块纹丝不动，说明它每轮都在被重新塞进去，你治的是症状不是病根。/doctor做一次整体自检。官方排查页把它列为不确定该看哪里时的第一站，它会检查安装、设置、扩展和上下文用量，发现问题会在你确认后应用修复。如果claude已经起不来了，就在 shell 里跑claude doctor。
六、以后怎么少碰到
压缩报错基本都是上下文卫生问题的滞后表现。几条能明显减少复发的习惯：
- 别等满了才压。上下文的余量是有用的资源，压缩本身要花掉一部分——留着最后一点余量去压，等于把成功率压到最低。
- 大文件按路径引用，不要粘贴。这条在官方文档里出现了不止一次（
Prompt is too long、Request too large、thrashing 三处都提到），说明它是最高频的诱因。 - 关掉用不上的 MCP 服务。官方在
Prompt is too long那条里明确给了/mcp disable <name>——每个挂着的 MCP 服务都会把自己的工具定义塞进上下文，挂五六个不用的，开局就先吃掉一块。 - 精简
CLAUDE.md。它每次会话都会进上下文，写得越长，你每一轮的可用空间越少。 - 重启不丢对话。这一点很多人不知道，导致宁可硬扛也不敢退出。实际上关掉之后在同一目录跑
claude --resume就能接回来，该退就退。
七、把三条对照着记
最后压成一张表，下次看到红字直接对：
| 你看到的 | 第一步该做什么 | 证据级别 |
|---|---|---|
Conversation too long | 两次 Esc 回退几条 → 再 /compact → 还不行 /clear | 官方文档 |
Conversation too long（官方三步无效） | 退出 → 重开 → /resume → /compact | 社区办法，官方未确认（issue #7530） |
Not enough messages to compact. | 不当故障治，改掉「大段粘贴」的用法 | 官方文档 |
Autocompact is thrashing | 找出每轮灌满上下文的那个大输出，交给子代理或分块读 | 官方文档 |
三条报错里，前两条治的是你自己的上下文用法，第三条治的是某一个具体的大输出。方向搞对了，剩下的都是体力活。
本文所引官方处理均来自 Claude Code 官方错误参考与排查文档，社区办法来自 GitHub issue #7530，核对日 2026-08-08。产品行为会随版本变化，具体以官方文档与你所用版本的实际表现为准。