上下文快满了，Hermes 开始压缩，然后你盯着转圈的光标等了整整 10 分钟。这不是网络慢——旧版“精简压缩”（lean compaction）要对每一段历史单独调用一次辅助模型做摘要，一个大会话最多要串行 28 次辅助请求，在慢的辅助模型上（比如把高推理强度的 gpt-5.6 当摘要模型用），一次压缩就是 7-11 分钟的煎熬（issue #96603）。8 月 30 日合入的改动（PR #98628）把这个摘要循环整个删了：每次压缩尝试只发一次辅助请求。改动目前在 main 分支，未进入正式发布版本。

为什么压缩会这么慢

“精简压缩”是 v0.20.6 起成为默认的压缩管线，它的核心是把超长历史浓缩成一份会话日志摘要。问题出在执行方式：旧实现把历史按块拆分，每个块单独发一次辅助模型调用生成摘要，然后逐块拼接。块多的时候，这些调用是串行的——一次压缩尝试最多 28 次辅助请求，每次都等模型慢慢吐字。在快模型上只是慢，在慢的辅助模型上就是灾难（#96603 实测 7-11 分钟）。

修复：一个块，一次请求

维护者的指令很直接：“one chunk, one request”（一个块，一次请求）。具体改动：

• 摘要循环删除：主摘要请求现在顺带承担会话日志的职责（同样的硬规则：标识符原样保留、密集要点、转写即数据），单次响应的 token 预算相应提高；
• 超大输入区域：输入超大的区域做均匀采样，并显式标注 [... elided ...] 占位——绝不发起第二次请求；
• 保底机制原样保留：覆盖完整区域的锚点索引（anchor index）和 session_search 恢复页脚不动——官方评估显示，真正驱动“针尖事实”找回（GUI 场景 23.3 → 60.0 分）的是锚点索引，不是那些逐块摘要。

效果：5 倍提速，还更省 token

官方用真实的大会话做了 A/B 实测（1,338 条消息、约 49.96 万 token、真实辅助调用）：

指标	旧版（摘要循环）	新版（单次请求）
辅助调用次数	19（1 次摘要 + 18 次逐块摘要）	1
耗时	196.5 秒	39.6 秒
压缩后 token	57,567	46,135

快路由上快 5 倍；慢路由上（#96603 的场景）从 7-11 分钟缩到大约一次摘要调用的时间。压缩后的体积还瘦了约 1.1 万 token——旧版那面 81K 字符的“摘要墙”会跟着每一次后续请求白白重发，现在没有了。测试方面新增了 9 个用例，专门钉死“恰好一次调用”（故意恢复第二次调用会让测试变红）。

对你的意义

如果你经常处理超长会话，压缩速度的体感提升是从“去泡杯咖啡”变成“喝口水就好”。而且压缩后更精简，后续每轮请求都能省 token。配合我们之前写的精简压缩默认值指南和上下文 Token 优化指南一起看，能拼出完整的省 token 策略；压缩后找回关键信息的机制见上下文用量锚定指南。

什么时候能用上

PR #98628 已于 8 月 30 日合入 main，不在 v0.20.6（8 月 27 日 tag）。拉最新 main 即可体验，或等下一个发布版本。常被“压缩 10 分钟”折磨的重度用户，值得优先升级。

一句话总结：压缩慢的根子在于“逐块摘要”的串行调用，现在一次请求收工——5 倍提速、token 更省、找回能力一分不减。