四Claude Code Token 进阶法——Compaction 长会话上下文压缩的用法与边界【先讲一个真实场景】有一个需求需要反复迭代同一个组件的原型要改 8 版每次改完还要测试、反馈、再改。理想情况下这应该是一个连续的会话——从第一版的草稿开始逐步演进到最终版。但问题是到第 5 版的时候session 已经积累了十几万 token 的历史对话。每一轮新的请求都得把这十几万 token 全部再发给模型一遍哪怕其中 80% 的内容在第 6 轮以后已经完全不相关了。这时候 Compaction上下文压缩功能出现了——它是 API 层面的一个机制当上下文长度接近上限时服务端会自动把早期的历史对话总结成一个摘要块替换掉原始的长篇内容从而减轻后续请求的负担。听起来很美好但它怎么用、有什么限制、什么情况下不能用——这些问题在实际使用中很容易踩坑。下面详细介绍一下。什么是 CompactionCompaction 是 Claude API 的一项特性beta headercompact-2026-01-12它的目的是在长对话中自动管理上下文长度。当对话历史接近上下文窗口极限时API 会把早期的对话内容总结为一个 compact block这个 summary block 会取代原来的长篇历史出现在下一次请求的上下文中后续请求只需携带「summary 近期对话」而不是完整历史这样的好处是随着对话轮数增加输入 token 的增长速度会放缓甚至趋于平稳而不是线性上升。什么时候应该用 Compaction适用场景说明长迭代的原型开发同一个 UI 元素反复迭代需要保留早期讨论的上下文复杂的多步骤代码重构涉及大量文件修改的 refactor 任务历史有价值深度问答对话客户支持、技术咨询类需要多轮追溯连续的任务流一系列紧密关联的子任务不宜断开成新会话什么时候不应该用 Compaction不适用场景原因独立的、彼此无关的任务每个任务都有自己的最佳上下文混在一起反而浪费敏感信息对话compaction 总结可能会丢失或模糊某些细节需要精确回溯的场景法律/审计等场合需要原始记录的精确性短任务20 轮还没到压缩的必要阶段加了也没意义对于你的原型代码开发场景大多数情况下应该用独立会话而不是依赖 Compaction。只有在确实需要连续追踪的复杂任务上才考虑用。如何使用 Compaction对 Claude Code CLI 用户不需要手动配置。Claude Code 自身已经实现了上下文管理机制长会话到一定程度会自动触发 compaction你不需要干预。对直接调用 API 的用户需要在请求中添加 beta header 和 context management 配置client.beta.messages.create( betas[compact-2026-01-12], context_management{edits: [{type: compact_20260112}]}, messageshistory, ... )并且最关键的一点你必须把返回的完整response.content包含 compact block原样传递给下一轮请求而不能只提取其中的 text 部分。如果丢了 compact block压缩就会失效下一轮又会回到老样子——重新发送完整历史。⚠️这是一个极易踩坑的地方很多人以为只要打开 compact 开关就可以了实际上客户端的正确行为传递完整的 content比开关更重要。Compaction 能节省多少这取决于对话的模式和内容。一般来说如果对话历史中早期内容确实有用如需求背景、设计决策compaction 可以保留这些信息而把字数压缩 70%~90%如果早期内容是纯闲聊或无效讨论compaction 可能反而会总结出一些不必要的信息极端情况下历史完全无用compaction 可能节省不明显从实践来看对于一个 100 轮左右的长会话compaction 之后每轮平均 input 可以从初始的 20k 降到 5k~10k 的稳定水平。Compaction 的局限性不能逆转已经累积的历史compaction 是对未来请求生效的已经产生的大 input 不会再回去补救摘要可能丢失细节summarization 会抽象掉一些具体细节不适合需要精确引用的场景Claude Code 自动管理对普通用户无需操心CLI 已内置不能替代会话拆分compaction 不是魔法它把长会话变成了「带摘要的长会话」但仍然是一个会话。如果你的会话里混了多个不相关的任务compaction 帮不了你——应该拆分成多个短会话我的实际操作选择在我的工作流程中我对 Compaction 的态度是优先靠会话拆分而不是靠 Compaction 救场。理由 - 拆分会话一个任务一个会话可以在源头上避免历史累积这是最根本的方法 - Compaction 是对已经失控会话的补救手段而不是预防手段 - 对于原型迭代这类任务即使使用 Compaction仍然可能混杂不同任务的上下文碎片所以我的策略是 1.能用单会话搞定的≤50 轮不做 compaction会话结束后直接丢弃 2.必须多轮深入的如复杂代码 refactor用 Compaction 保持效率 3.跨多个不相关任务的坚决拆分成多个会话不要指望 Compaction 来救【之前的工作流】我以前对 Compaction 的理解和使用方式是 - 听说它能节省 token → 以为是自动省钱的魔法 → 一开到底 - 不管会话里做了几件事全都塞进去 → 期望 Compaction 帮我清理 → 结果 Summary 里依然保留了不相关的内容 - 误以为开了 Compaction 就可以无限延长会话 → 导致 session 长期不关闭 - 没有意识到传递 response.content 的重要性 → 实际上有的客户端实现没有正确处理 compact block → Compaction 效果大打折扣结果是Compaction 确实用上了但并没有达到预期的节省效果反而增加了理解的复杂性。【现在的工作流】现在的做法先评估任务是否需要连续性——如果不需要一个任务一个会话别犹豫需要连续性的任务——在 API 请求中正确开启 Compact并保证传递完整的 response.content定期检查会话长度——一旦 turns 超过 100评估是否应该总结后关闭当前会话新开一个干净的会话不把 Compaction 当作万能药——它只是辅助工具不是解决问题的根本方案【最关键的体会】Compaction 是一项聪明的技术它通过智能摘要在长对话中平衡上下文长度和记忆能力。但它不是银弹。Compaction 正确的定位是当确实需要保留长历史上下文时帮你减少每轮的开销而不是替代良好的会话划分习惯。真正有效的 token 管理仍然是能分就分能短则短实在长时用 Compact永远别让它变成一个大杂烩。【分享一句话】Compaction 不是让你可以任意延长会话的理由——它是长会话中的减压器不是无限续费的通行证。适用读者需要处理长对话场景的开发者和高级用户[下一篇实战复盘]