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