Agent 跑得越久,账本越厚。多轮交互留下的任务记录、工具返回和中间结论不断堆进上下文,token 一路上涨,最后都得靠「压缩」续命:让大模型把长历史总结成一份摘要,替换掉原文。问题是,这一步本身就是一次完整的生成任务——用你最贵的模型,把你最长的历史复述一遍。压缩触发的那个瞬间,界面看起来像卡住了,后台其实在整理记忆,而用户只能在旁边干等。
压缩慢在哪
上下文压缩(context compaction)的困难一直是道两难题:总结得太省,信息丢失,后续任务掉分;总结得太细,延迟飙升,交互体验先崩掉。理想状态是压缩足够勤、摘要足够准、等待足够短,但三件事互相牵制。论文对这一步的开销说得直白:用大模型总结长历史会引入可观的延迟,所以压缩必须在整个「信息保留」和「延迟」之间找平衡点。换句话说,压缩不是免费的管家,它自己就是账单上的一笔大支出。
槽位并行,逐行验收
SpecCompact 的起点是一个关键观察:结构化的摘要槽位(summary slots)如果各自独立生成,信息照样保得住。这句话把摘要内部的依赖链拆开了。于是整个框架变成一条流水线:先微调一个小模型担任 drafter,让它并行起草各个槽位;目标大模型不再亲自从头写摘要,只对草稿逐行验证,被拒绝的行才由它出手修补;后续的起草再拿更新过的槽位前缀当条件。系统层还配了一组优化,专门削减重复的上下文处理和重复的模型调用。这套「小模型起草、大模型验收」的结构,和投机解码在 token 层的逻辑同源:验证比生成便宜,那就把最贵的算力只花在把关上。
提速多少,代价是什么
数字层面:在 AppWorld 和 τ³ 两个基准、两个目标模型上,SpecCompact 的压缩环节比 Hermes 式总结提速 2.04 到 5.63 倍;在 Hermes 内做的用户研究里,压缩提速的中位数达到 8.68 倍。要说明的是,这些倍数比的是压缩环节本身的耗时,任务端到端成绩是另一回事,论文单独做了下游评估,结论是效果随模型和任务变化,存在权衡——速度拿到手了,质量端并没有一刀切的保证(论文)。
所以呢
我的看法:这篇论文真正值得记住的不是那个 8.68 倍,而是「验证比生成便宜」这个不对称性正在被一路泛化——从 token 级的投机解码,一路搬到语义级的摘要验收。对做 agent 基建的人来说,压缩延迟从此要按交互路径上的一等公民来预算:它不再是后台批处理,而是用户能直接感知的卡顿。更实际的问题是选型:如果你的 agent 已经在用大模型做周期性总结,这篇论文给了一个把等待时间大幅压缩、又不必重训主模型的可参考配方。下次排查「我的 agent 为什么慢」,先看一眼它多久压缩一次历史。