到了今天，很多 Harness 的 compaction 还是阻塞式的：任务正跑着，突然开始压缩，一等就是几十秒到几分钟。 到底是什么拖住了这块的改进——产品决策，还是技术原因？

从压缩本身的操作来讲，这个是原子化的，喂进去的封闭历史只有压缩失败和压缩成功两个状态，这个是肯定不会是能中途操作的。从产品设计来讲，理论上可以在工具执行的时候并行压缩，但是这样不仅要求压缩要更早触发，还需要完整处理快照回滚运行恢复等一系列问题，还需要预估工具的执行时间避免中途超时打断等等问题，所以相比把压缩过程无感化的代价，更好的管理上下文及时清理掉早期的工具调用返回，或者多多编排使用子代理工作可能是一个更好的替代方案。（不过专门调一个压缩模型来在某次调用的时候替换调前面的上下文也可以，但是这样容易搞出雷霆大掉缓，对于追求缓存率的用户挺灾难的）

如果是为了产品体验，感觉这些技术上的难题都是可以解决的。

算是一种平衡之选吧，并行压缩造成的各种问题即使都实现完善了也是用户可感的卡顿，目前意义不是很大而且对全文效果还是有损伤。不过dsh有一个插件实现的压缩挺有意思，把旧历史整理成一个完整文件，上下文直接截断只留指针按需追加，可能也是一个不错的方向，不过我没用过不知道效果如何。