结论先行：Claude API 现在支持「按需会话压缩」（conversation compaction）——你可以主动把一段历史消息让模型摘要成一个带签名的压缩块，后续请求用这个块替掉原文。这样既省 token，又能保留最近若干轮的原始对话不变，是跑长程智能体和超长上下文任务时控制成本的关键手段。
为什么需要会话压缩
长程智能体往往要在同一个会话里跑几十甚至上百轮：工具调用、反思、子任务层层叠加，上下文很快被撑爆，token 成本线性上涨。过去只能靠自己写摘要逻辑手动裁剪，既容易丢信息，又破坏提示词缓存前缀。 2026-09-14 的发布把这件事做成了 API 一等公民。
提示：压缩不等于丢弃。你可以只压缩「较早的」消息，把最近几轮原样保留，兼顾省钱和上下文连续性。
怎么触发压缩
在请求里带上 Beta 头 compact-2026-09-04，并设置顶层的 compaction 参数。 API 会返回一个带签名的压缩块（signed compaction block），它是对你发出的那些消息的摘要。后续请求把这个块放在最前面、替掉被摘要的消息即可。
curl https://api.anthropic.com/v1/messages \
-H "anthropic-beta: compact-2026-09-04" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-5-5",
"messages": [ "此处为待压缩的历史消息" ],
"compaction": { "type": "auto" },
"max_tokens": 1024
}'四个关键特性
- 你来决定何时压：不必等上下文满，可在任何合适的节点主动压缩。
- 可后台运行：压缩请求本身支持在后台执行，不阻塞主链路。
- 近期原样保留：摘要之后，你可以继续保留最近若干轮逐字原文，模型拿到的是「摘要 + 近期原文」的组合。
- 思考块可留存：在支持保留思考（preserved thinking）的模型上，被保留轮次里的 thinking 仍然有效，不会因为压缩而作废。
和提示词缓存怎么配合？
压缩块本身是一段稳定的前缀内容，配合 Prompt Caching 可以让后续请求继续命中缓存。关键点在于：把「变动频繁」的近期对话放在压缩块之后，把「相对稳定」的摘要和初始指令放在前面，这样缓存前缀的稳定性最高。具体取舍可参考 Anthropic 长上下文用法 里关于缓存前缀的实战结论。
四步接进你的智能体
- 在请求头加 anthropic-beta: compact-2026-09-04，并置顶层的 compaction 参数（auto 或显式指定范围）。
- 拿到返回的签名压缩块，把它存入会话状态，作为下一轮请求的最前消息。
- 保留最近 N 轮原始消息在压缩块之后，确保模型对「刚发生的事」记忆清晰。
- 若模型支持 preserved thinking，确认被保留轮次的 thinking 块随请求回传，避免重新计算。
注意：压缩块是「签名」的，意味着它由模型生成且可验证；不要手工篡改块内容，否则校验会失败。生产环境以官方文档为准。
延伸阅读
想系统压低长上下文成本，建议结合 Anthropic 长上下文用法 与 Claude Opus 5.5 发布解读，以及 Anthropic 提示词工程最佳实践 一起看。
会话压缩会丢信息吗？
压缩会把较早的消息摘要化，必然有信息折损；但你可保留近期轮次原文，把折损控制在可接受范围。
压缩块能放进提示词缓存吗？
能。压缩块是稳定的前缀内容，放在请求前部即可参与缓存命中，降低后续成本。
需要 Beta 头吗？
需要，当前为 compact-2026-09-04 Beta 能力，生产环境建议先小流量验证。
压缩能后台跑吗？
可以，压缩请求支持后台执行，不阻塞主对话链路。
评论 (0)