compaction.mdx 2.6 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768
  1. ---
  2. title: "上下文压缩 - Compaction 优雅遗忘机制"
  3. description: "详解 Claude Code 上下文压缩策略:当对话 token 接近 200K 上限时,如何通过 Compaction 机制智能压缩历史消息,保留关键信息。"
  4. keywords: ["上下文压缩", "Compaction", "token 管理", "对话压缩", "上下文窗口"]
  5. ---
  6. {/* 本章目标:解释 Compaction 机制的设计和策略 */}
  7. ## 为什么需要压缩
  8. 每次 API 调用的 token 有上限(通常 200K)。一场长时间的编程对话可能产生:
  9. - 大量的文件内容(AI 读了几十个文件)
  10. - 长篇的命令输出(构建日志、测试结果)
  11. - 往返的对话历史
  12. 不压缩的话,很快就会撞到 token 上限,对话被迫终止。
  13. <Frame caption="上下文压缩前后对比">
  14. <img src="/docs/images/compaction.png" alt="上下文压缩示意图" />
  15. </Frame>
  16. ## 压缩的策略
  17. Claude Code 提供了多层压缩机制:
  18. <AccordionGroup>
  19. <Accordion title="自动压缩">
  20. 当 token 接近上限时,系统自动触发压缩。AI 生成一份当前对话的**摘要**,替换掉早期的详细消息。效果就像人类的"记忆"——记住要点,忘记细节。
  21. </Accordion>
  22. <Accordion title="手动压缩">
  23. 用户可以随时通过 `/compact` 命令主动触发压缩。可以附带提示语(如 `/compact 聚焦在认证模块的修改上`),引导 AI 保留特定信息。
  24. </Accordion>
  25. <Accordion title="Micro Compact">
  26. 更细粒度的局部压缩——不是压缩整个对话,而是压缩某些特别长的工具输出(比如一个 5000 行的测试日志)。
  27. </Accordion>
  28. </AccordionGroup>
  29. ## 压缩边界
  30. 压缩后,系统在消息历史中插入一个"边界标记"。后续的 API 调用只发送边界之后的消息:
  31. ```
  32. [早期的 50 条消息] ← 被压缩
  33. [压缩摘要边界] ← 一段浓缩的摘要
  34. [后续的 10 条消息] ← 正常发送
  35. ```
  36. 这个设计保证了:
  37. - 压缩后的摘要为 AI 提供了历史上下文
  38. - 新的对话不受旧消息的 token 负担
  39. - 用户无感知——对话继续自然进行
  40. ## 压缩前后的 Hooks
  41. 压缩是一个可能丢失信息的操作,因此系统允许用户在压缩前后执行自定义脚本:
  42. - **Pre-compact Hook**:压缩前执行,可以标记"这些信息不能丢"
  43. - **Post-compact Hook**:压缩后执行,可以验证关键信息是否保留
  44. ## 什么信息会被保留
  45. 压缩不是简单的截断,AI 会智能地决定保留什么:
  46. - 用户的核心需求和目标
  47. - 重要的决策和原因
  48. - 当前工作的状态(改了哪些文件、做到哪一步)
  49. - 之前犯过的错误(避免重蹈覆辙)