s08 现在有两条压缩入口：compact_history()（prepare() 超阈值时、以及 compact 工具触发）和 reactive_compact()（API 报 prompt_too_long 时触发）。文档把它们讲成「预防」和「补救」两个概念很清晰。但代码逻辑，我觉得没有很好的体现补救的价值。
首先，两个触发点面对的 messages 其实完全相同——prepare() 返回之后紧接着就是 API 调用，中间没有任何修改 messages 的代码。输入相同、目标相同，却写了两套逻辑。
建议是文档继续讲两个概念，代码收敛成一个 compact(messages, active_request, keep_tail, label)，两条路径变成不同参数：预防用 keep_tail=3, label="Compacted"，补救用 keep_tail=0, label="Reactive compact"。
s08 现在有两条压缩入口：
compact_history()（prepare()超阈值时、以及 compact 工具触发）和reactive_compact()（API 报prompt_too_long时触发）。文档把它们讲成「预防」和「补救」两个概念很清晰。但代码逻辑，我觉得没有很好的体现补救的价值。首先，两个触发点面对的 messages 其实完全相同——
prepare()返回之后紧接着就是 API 调用，中间没有任何修改 messages 的代码。输入相同、目标相同，却写了两套逻辑。建议是文档继续讲两个概念，代码收敛成一个
compact(messages, active_request, keep_tail, label)，两条路径变成不同参数：预防用keep_tail=3, label="Compacted"，补救用keep_tail=0, label="Reactive compact"。