上下文压缩 compaction

压缩的机制（截至 2026-08 已经是一等公民 API）

流程是：按输入 token 数达到阈值触发 → 生成一段摘要块 → 摘要块之前的内容全部作废 → 从摘要继续。几个必须知道的细节：

1. 阈值默认 15 万 token，最低只能设到 5 万。 这个下限本身就是官方在告诉你：不要频繁小压。
2. 压缩是一次额外采样，单独计费。 用量要跨所有迭代汇总，只看顶层的输入输出 token 字段会算漏账。
3. 自定义摘要指令是「完全替换」，不是追加。 这是最容易踩的坑——你只写了「重点保留代码片段」，就等于把默认提示里「保留状态、下一步、已有结论」全删了。
4. 可以在压缩后暂停，让你把最近几条消息原样接在摘要后面，避免刚说完的关键信息立刻被摘要走样。
5. 带工具时压缩可能失败：模型在摘要那一步跑去调工具了，返回一个空摘要。解法是在指令里明确写「这一步只写文本，不要调用任何工具」。
6. 摘要用的是同一个模型，不能换个便宜的来做。

缓存的机制

• 层级 tools → system → messages，改上层废下层；
• 写入只发生在断点处，读取时向前回溯，回溯窗口是 20 个 block。这意味着一轮加太多 block，会把上一次的写入推出窗口，明明内容没变也命中不了；
• 有最小可缓存长度门槛，按模型不同为 512 / 1024 / 2048 / 4096 token 不等。不到门槛不缓存，且不报错——两个缓存字段都是 0 就是这种情况；
• 计费：5 分钟写入约 1.25 倍原价、1 小时写入约 2 倍，命中约 0.1 倍；命中会免费续期，续期从请求开始时刻算起（生成耗时也算在寿命里）；
• 常见的隐形失效项：工具定义顺序变了、某些语言序列化时 JSON 键顺序不稳定、图片增删、思考或 effort 配置变动、tool_choice 变化。

压缩与缓存怎么和解（这是本篇最值钱的一段）

「压缩会击穿缓存」这个说法要说得更精确：击穿的是会话前缀，不是全部。

官方给的解法是：在系统提示词末尾单独打一个缓存断点。这样压缩发生时，系统提示词那段缓存仍然有效、照常读取，只有新生成的摘要需要作为新内容写入一次。长系统提示词因此可以跨多次压缩一直活着。

再配合「少次大压」，整笔账就清楚了：