compaction.mdx 2.4 KB

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