一个编码会话会经历多少次上下文压缩?
一次 压缩 是论文与
total_input_growth 中那些单纯的尺寸桶相区分的行为事件:当运行中的上下文接近其上限时,它会被 summarize/丢弃成一段简短的历史,然后再缓慢地重新累积。我们从每个步骤的总输入长度(prefix_tokens + newly_append_tokens)结构性地检测它,在每个会话内按 round_pk 排序。当三个条件全部成立时,步骤 i 即为一次压缩:
- 大幅缩减 ——
total[i-1] - total[i] >= 64k(--min-drop-tokens,默认为growth.MAJOR_REDUCTION_MIN_TOKENS)。因此每一次压缩同时也是一次 major reduction;压缩是同时满足 (2) 和 (3) 的那个严格子集。 - 接近上下文上限 —— 下降前的水平
total[i-1]至少达到该会话观测到的最大总输入的--near-max-ratio(0.75)。下降发生在会话的峰值附近,而不是在早期的小幅回落处。 - 恢复缓慢 —— 在接下来的
--rebound-steps(3)个步骤内,上下文没有反弹到下降前水平的--rebound-ratio(0.75),且其后至少还有一个步骤。一个立即弹回的下降是 branch/edit 产物,不是压缩。
每一次压缩都归因于步骤 i 的触发器,使用论文其余部分通用的同一套
用户触发 / 工具触发 划分:user_message →
用户触发(一个显式的 /compact,或一个迫使 summarization 的新请求);
tool_result → 工具触发(循环中途的自动压缩)。