[Bug] v0.1.7-alpha.1 深度搜索中上下文被频繁压缩：5分38秒内触发6次（仅1-4条/1.4k-3.6k tokens），并伴随 summary-not-smaller 空转

[ashu1800]

环境

• dsh: 0.1.7-alpha.1（本地 dsh --version / npx @deepseek-ai/dsh --version 均为此版本）
• profile: web
• 模型路由：provider ohub / model deepseek-v4.1-flash，request/context 中 contextWindow: 400000，request/header 中 reasoningEffort: max, maxTokens: 300000
• 会话：session-6ec4299a-625f-4339-850e-9047d2eeef25，session.v4.jsonl 共 261 条记录（user/message 22，assistant/message 26，tool/call 32，tool/result 39），基本集中在一个 turn 内（全程约 8 分钟）

现象（有截图）

一次“深度搜索”（界面计时 5 分 38 秒）过程中，右侧轨迹密集出现“上下文已压缩”：

• 已压缩 1 条历史记录（约 1431 tokens）
• 已压缩 3 条历史记录（约 2770 tokens）
• 已压缩 1 条历史记录（约 1923 tokens）
• 已压缩 4 条历史记录（约 2919 tokens）
• 已压缩 3 条历史记录（约 3633 tokens）
• 已压缩 1 条历史记录（约 2135 tokens）

合计约 15 条、约 1.5 万 tokens，被拆成 6 次压缩，平均不到 1 分钟一次。每次只压 14 条、1.4k3.6k tokens，体感是“刚写一点就压一次”。

对 session 日志的取证

session.v4.jsonl 中与压缩相关的记录：

• compaction/start: 20 次
• compaction/end: 20 次
• compaction/summary: 16 次
• compaction/prune: 8 次（shadowedTokenCount 多在 2400~8600 之间，均只覆盖单条 seq）

其中 4 次 compaction/end 带 error，全部是“摘要比被压缩内容还大”类空转：

• summary is not smaller than the shadowed content (1044 estimated framed tokens >= 137)
• summary is not smaller than the shadowed content (2239 estimated framed tokens >= 2239)
• summary is not smaller than the shadowed content (2417 estimated framed tokens >= 2409)
• summary is not smaller than the shadowed content (2688 estimated framed tokens >= 2687)

即：阈值似乎压得很勤（小到 137 tokens 的 span 也会触发一次 compaction），而这种小 span 压完摘要反而更大，白白烧一次摘要调用，符合“频繁但无效”的观感。

已排查过的相关讨论（均不是同一个问题）

• 小窗口路由下 compaction 会持续失败：摘要调用跟随会话路由导致「压缩自锁」 #7423《小窗口路由下 compaction 会持续失败》：说的是摘要请求跟随小窗口路由导致的确定性自锁，我的环境是 contextWindow 400000 的大窗口，不属于该场景。
• [严重 Bug] 中文/工具密集长会话出现 compaction thrashing：持续阻塞正常使用 #2737《compaction thrashing》、BUG 报告：compaction 反复压缩不可压缩 checkpoint 导致死循环 #4776《反复压缩不可压缩 checkpoint 死循环》、低效压缩，每次只压缩一轮对话 #5279《低效压缩，每次只压缩一轮对话》：症状描述接近，但都是 8 月~9 月初、老版本下的报告；当前是 0.1.7-alpha.1 新出现的体感，且没有 checkpoint 死循环，只是阈值过勤 + 小 span 空转。

期望

1. 确认 0.1.7-alpha.1 是否收紧了 proactive compaction 的触发阈值（结合 maxTokens: 300000 + reasoningEffort: max 的大预留下，实际可用窗口是否被提前吃掉很多，导致过早/过勤触发）。
2. 如果小 span（百~千级 tokens）本就不该触发，建议加一个最小 span 门限；summary is not smaller than shadowed content 这类可预判的空转能否在摘要调用前剪枝掉。
3. 如需复现数据，我可按需提供脱敏后的 session.v4.jsonl 片段（完整文件 1.6MB，含本机路径等信息，故未直接贴附件）。

[ashu1800]

[dsh-session-session-6ec4299a-625f-4339-850e-9047d2eeef25.zip](https://github.com/user-attachments/files/32518771/dsh-session-session-6ec4299a-625f-4339-850e-9047d2eeef25.zip)

[songlairui]

根据原帖提供的 request/context 和 request/header，结合 0.1.7-alpha.1 的实现，这里很可能不是上下文真的接近 400K，而是输出预留将 proactive compaction 的有效触发线压到了约 34K。

实际触发线怎么算

compaction-basic 的 resolveCompactSpec() 当前使用：

thresholdTokens = floor(min(
  contextWindow * thresholdRatio,
  contextWindow - reservedCompletionTokens - headroomTokens
))

其中默认 thresholdRatio = 0.8、headroomTokens = 65536；输出预留优先取最近请求头的 config.maxTokens，否则取 adapter 的 defaultMaxTokens。

代入原帖的值，在没有额外压缩策略覆盖的情况下：

contextWindow = 400000
maxTokens = 300000

触发线 = min(320000, 400000 - 300000 - 65536)
       = 34464 tokens

因此，400K 的名义窗口，实际只到约 34K 请求压力就会触发压缩。这也解释了为什么仅调整触发比例不一定有效：限制来自第二项的减法预算，而不是比例。这条计算本身不需要再为 reasoningEffort: max 单独扣一次预算。

版本间也确实存在策略差异：0.1.5-rc.1 的对应函数只按 floor(contextWindow * thresholdRatio) 计算，而 0.1.7-alpha.1 增加了输出预留和 headroom 限制。对于原帖这组值，默认策略下对应的是 320000 → 34464。这里只确认这两个版本的代码差异，尚未定位变化首次引入的具体版本/提交。

不合理之处

预留输出空间本身有安全理由，但当前设计存在几个问题，不能简单归结为用户配置错误：

1. 模型配置与每次请求预算耦合，且直接影响压缩。 llm-pi-ai 将显式配置的模型 maxTokens 暴露为请求的 defaultMaxTokens，压缩器再将其全额预留。模型允许较长输出，不代表每个 Agent 步骤都需要为最坏情况牺牲绝大部分历史上下文。更合理的是区分模型输出能力上限、请求默认输出预算和压缩安全余量；如需动态下调预算，应同步调整实际请求的输出上限。
2. 有效阈值不直观。 窗口显示为 400K，但真实触发线只有约 34K，应明确展示“窗口 − 输出预留 − headroom”的预算拆分和告警，否则用户很难理解为什么远未到窗口上限就频繁压缩。
3. 对无收益压缩缺少足够的抑制。 原帖已有 4 次 summary is not smaller，包括仅 137 tokens 的 span。当前 pre-step 在压缩失败后继续执行，后续步骤仍会再次检查压力。如果没有足够新增可压缩内容，就可能反复付出摘要调用成本。建议增加最小收益/范围保护，以及无收益失败后的冷却或上下文增长门槛，而不只是重复尝试。

另外，轨迹中“压缩了约 1.4K–3.6K tokens”表示本次被替换的历史范围大小，不是完整请求大小，也不是压缩后的净节省量。有效触发线过低与这些小范围、低收益压缩结合，就容易形成原帖描述的频繁空转。

临时解决方法：主动设置较小的 output token 上限

可以先保持真实 contextWindow 不变，将普通模型请求的输出上限设为更符合单次响应需要的值，例如在原帖 ohub provider 对应的模型条目中：

- id: deepseek-v4.1-flash
  contextWindow: 400000
  maxTokens: 64000  # 示例预算，按任务需要选择，不是模型能力上限

在默认压缩策略下：

请求输出上限	有效压缩触发线
300000（原帖请求值）	34464
128000	206464
64000	270464

注意：

• 改的是模型路由/普通请求的 maxTokens，不是 compaction-basic.maxTokens，后者控制摘要调用输出上限。
• 如果还有会话或请求级覆盖，也需检查；配置生效后核对新的 request/header.config.maxTokens。
• 不必虚增模型窗口，也不建议仅关闭压缩来掩盖问题。
• 较小上限可能截断特别长的推理或回答，应按任务需要取舍。上表是预算计算结果，仍需在原帖环境验证调整后的实际表现。

这是绕开过早触发的临时办法；有效预算展示、配置语义分离，以及无收益压缩的退避机制，仍值得在 Harness 层修正。

[zonglong1025]

实测临时方法有效，也不知道这个版本怎么考虑的，这是明细的不合理设定。

[kevinzrs123]

我昨天光压缩就遇到差不多10次bug，让dsh自己去分析源码，才知道是因为我是主动限制了上下文窗口，因此导致的一个问题就是上面提到的减法后的结果是负数，进而导致压缩失败。我不太理解这么改的目的，之前的压缩策略明明挺好的，没遇到过问题，现在只能自己写个插件去临时解决，希望官方能优化这个问题