上下文压缩（Context Compaction）

什么是上下文压缩

上下文压缩（Context Compaction）是把一次长会话中已经消耗掉的历史对话，压成一份「决策 + 约束 + 当前状态」的紧凑摘要，替换掉原始的完整过程，从而腾出上下文空间让任务继续跑下去。

一个判断标准：压缩后 surviving 的是「结论」，被丢弃的是「推导过程」。 比如「我们决定用 Postgres 的 advisory lock 而不是 Redis，因为项目里没有 Redis 依赖」要留下；而中间那三十轮关于各种方案的讨论、试错与报错堆栈要丢掉。

它和几个相邻动作的区别必须先分清：

为什么需要它：三个问题，一种解法

上下文压缩不是「省 token 的小技巧」，它是长任务能不能跑完的结构性前提。它同时治三个问题：

1. 上下文腐烂（渐进退化）

Context Rot 说的是：输入 token 越多，输出质量越低——而且远没到窗口上限就开始。Chroma 实测 18 个前沿模型无一幸免。对编码 Agent 来说这是首要失败模式，比模型能力更关键。

压缩的意义在这里是主动把输入长度拉回高质量区间，而不是等它烂掉。

2. 窗口见顶（硬失败）

长上下文 再大也是有限的。以 Claude Opus 5 的 1M 上下文为例——1M 是默认值也是最大值，没有「再开大一点」这个选项。见顶之后工具会强制处理，而那时你失去了选择压缩时机的权利。

3. 成本（缓存与无效历史）

长会话里 90% 以上的输入 token 走缓存价，但会话历史本身是缓存的一部分：历史越长，每一轮要重读的前缀就越长。更关键的是，压缩会改变前缀，从而让 prompt 缓存失效——压缩后头几轮会按全价计费。这是压缩的隐性成本，见下文「代价」一节。

三种压缩方式

自动压缩（工具在接近上限时触发）

多数 CLI Agent 会在上下文接近上限时自动触发压缩。它的好处是你不用管，坏处是时机由工具决定——往往已经进入了质量下降区间才动手。

做法：把自动压缩当作兜底而不是策略。

手动压缩（/compact）

以 Claude Code 的 /compact 为代表：压缩历史但保留关键决策。

本站 Claude Code 长任务实战 给出的节奏是：每 20–30 分钟压一次，比「等它崩了再救」省一倍时间。触发信号：

把压缩挂在 commit 上是最省心的做法——每个子目标完成后 commit，紧接着压缩。这样即使压缩丢了什么，git 里还有完整的东西可以找回。

结构性卸载（外部记忆）

最被低估的一种：把状态写到文件里，而不是留在上下文里。

• CLAUDE.md / AGENTS.md：长期项目约定（见 AGENTS.md 协议）；
• 临时 NOTES.md：本轮任务的进展、卡点、下一步；
• 任务清单：把「还差什么」写成文件，会话可以随时重建。

这一招的价值在于：文件不受上下文窗口限制，也不随会话结束消失。 长任务里最常见的失败不是「模型不会做」，而是「做到一半忘了要做什么」——外部记忆直接对治这一点。

压缩什么，不压缩什么

必须留下：

• 已做出的架构决策及其理由（尤其是「为什么不用 A」）；
• 用户给出的硬约束（不许改的文件、必须兼容的版本、命名规范）；
• 当前状态：已经完成了什么、正在做什么、下一步是什么；
• 还没解决的错误与卡点；
• 涉及外部系统的事实（数据库地址、端口、鉴权方式）。

可以丢弃：

• 中间方案的讨论过程；
• 已经修好的报错堆栈；
• 重复出现的文件内容（需要时重新读）；
• 已经合并进代码的 diff。

代价：压缩不是免费的

这是最容易被忽略的一节。

1. 细节不可逆。压掉的内容不会回来。如果某个关键约束只存在于某一轮的对话里、没写进文件也没进 commit message，它就永久消失了。
2. 隐性约定最容易丢。那些「我们默认不用 any」「这个文件是生成的别手改」之类没有显式写下来的规矩，压缩后常常消失，然后 Agent 开始犯看起来莫名其妙的错。对策：把约定写进 CLAUDE.md，不要指望模型从历史里推断。
3. prompt 缓存会失效。压缩改变了前缀，之后的头几轮按全价计费。所以压缩频率不是越高越好——压得太勤，省下的长度还不够抵消缓存失效的损失。
4. 摘要本身也要 token。压缩这个动作本身是一次调用，且产出的摘要会一直占着上下文。

一句话权衡：压缩的收益随「历史有多冗余」上升，成本随「压缩有多频繁」上升。合理的落点是跟着任务结构走（每个子目标一次），而不是跟着时间机械地压。

与子 Agent 的关系

智能体编排 提供了另一种绕开上下文上限的思路：把大任务拆给子 agent，每个子 agent 有自己的独立上下文，主 agent 只收结果。

三者不互斥：长任务的标准做法通常是「子 agent 拆分 + 每个子任务内部按需压缩 + 全局用 NOTES.md 记状态」。

常见误区

「上下文大就不用压了」 错。1M 窗口也架不住一个跑三小时的任务，而且 Context Rot 在远未到上限时就已经开始拖质量。

「压得越勤越好」 错。每次压缩都会让 prompt 缓存失效、并消耗一次调用。跟着子目标走，不跟着时钟走。

「压缩等于备份」 错。压缩会丢信息。真正的备份是 git commit 和 NOTES.md。

「/compact 和 /clear 差不多」 完全不同。/compact 保留决策继续干活；/clear 什么都没了，适合换一个无关任务。

FAQ

压缩后 AI 开始犯低级错误，为什么？ 大概率是隐性约定被压掉了——那些没写进 CLAUDE.md、只存在于对话里的规矩。把它显式写进项目说明文件，然后重新压缩。

自动压缩够用吗？ 作为兜底够，作为策略不够。工具触发的时机通常已经偏晚（进入质量下降区间），主动压缩能让你自己选锚点。

一次长任务压多少次合适？ 本站的实战口径是每 20–30 分钟一次，但这个数字应该跟着任务结构调整：子目标完成并 commit 后压一次，比机械计时更合理。

压缩会不会让已花的钱白花？ 不会白花，但已缓存的前缀会失效，压缩后的头几轮按全价计。这也是不能压太勤的原因。

延伸阅读

• 概念：Context Rot · 长上下文 · 上下文工程 · Prompt Caching · AGENTS.md 协议 · 智能体编排
• 工具：Claude Code · Cline · Cursor
• 模型：Claude Opus 5.5 · Claude Opus 5 · Claude Sonnet 5
• 实践：Claude Code 跑 3 小时长任务的 4 个关键技巧 · Claude Code 上手指南

来源

• Claude Code 官方文档：上下文管理与 /compact
• 本站实战：Claude Code 跑 3 小时长任务的 4 个关键技巧（/compact 节奏与失败恢复）
• Chroma：Context Rot 技术报告（长输入导致质量下降的实测）

本条目由 AI 之家 编辑部根据公开资料整理，非厂商付费内容。压缩相关的具体命令与默认阈值随工具版本变化较快，落地前请以所用工具的官方文档为准；本站给出的「20–30 分钟」属社区经验值而非官方建议。欢迎在 反馈邮箱 反馈更新。