[Bug] dsh v0.2.1-alpha.2: 达到 40% 上下文（约 37.9k/96k）时触发连续/疯狂的上下文压缩死循环

[nullptroot]

问题描述 (Description)

在使用本地 llama.cpp 部署的模型进行长文本交互时，配置的总上下文窗口为 96k。但在对话进行到约 40% 左右（当前触发时约为 37.9k / 96k）时，系统开始出现持续且密集的上下文压缩（Compaction），导致日志被重复的压缩记录刷屏，对话无法正常推进。

环境与配置 (Environment)

• DSH 版本: 0.2.1-alpha.2

• 推理后端: 本地 llama.cpp

• 模型: Qwen 27B 量化版本

• 配置上下文大小: 96k

复现步骤 (Steps to Reproduce)

1. 启动 dsh 并加载本地 llama.cpp 模型端点。

2. 进行多轮长上下文的编码或对话任务。

3. 当上下文占用累积达到约 39% ~ 40%（约 37.9k tokens）时触发压缩。

4. 现象：该问题已连续 2 次稳定复现，触发后系统会反复尝试压缩，并在日志中抛出类似 summary is not smaller than the shadowed content 的提示，陷入异常状态。

[oldzhang82]

有几个自查点：
1、dsh升级后多了一个headroom的概念。96k-headroom和96k*0.8，会选孰低执行。
2、压缩会调用大模型，默认是thinking模式，大量的思考过程会循环触发压缩的红线。
这两个坑我都踩过，你可以从这两方面看看。如果都不是，我也没办法了

[nullptroot]

nice,看起来是headroom的原因,且顶层的设置不生效需要配置到各个agent里去,你有试过压缩不使用thinking模式吗,好用吗

[oldzhang82]

是可以全局生效的，可能是已经有聊天记录的无法生效吧。
压缩没必要用thinking模式的，改了压缩会快很多。换个说法就是，压缩的坏处，你开thinking模式也救不回来，哈哈。
另外就是你可以尝试大模型那边改成256K。毕竟96K太少了，减去系统提示词，再减工具定义那些，剩下的太够呛了。

[jeffcao]

是可以全局生效的，可能是已经有聊天记录的无法生效吧。 压缩没必要用thinking模式的，改了压缩会快很多。换个说法就是，压缩的坏处，你开thinking模式也救不回来，哈哈。 另外就是你可以尝试大模型那边改成256K。毕竟96K太少了，减去系统提示词，再减工具定义那些，剩下的太够呛了。

可以说一下，压缩不用thinking模式的具体配置吗？

[oldzhang82]

可以说一下，压缩不用思维模式的具体配置吗？

你不是在dsh里用吗？你直接跟dsh说，压缩采用nothinking模式，他会帮你做的

[jeffcao]

晓得了，谢了