压缩时机调控 zyd232/dsh-compaction-policy

dsh-compaction-policy

别让 DeepSeek Harness 过早压缩你的对话——把触发点放到你想要的位置。

对话变长时，DSH 会自动压缩较早的历史。在很多模型上，它触发得远早于「上下文占用 80%」，而且过几步又会再压一次。这个插件把决定权还给你：它不改任何配置文件，只调整运行中的压缩引擎。

这个插件适合你吗？

只要下面任意一条听着耳熟，答案多半是「适合」：

- 你的模型上下文窗口小于约 330,000 token（大多数本地模型、不少托管模型都这样）。
- 上下文环看起来才用了一半，DSH 就开始压缩对话。
- 压缩刚结束，过几步上下文环又爬回同一位置，于是压缩反复发生。

如果你只用超大窗口（比如 1M），内置行为本来就接近 80%，多半不需要这个插件。

为什么会这样

每一步开始前，DSH 会估算下一次请求有多大，再和这个触发值比较：

trigger = min(window × 0.8, window − output reserve − 65536)

- window —— DSH 所知的模型上下文窗口。
- output reserve —— 请求要求服务商为回答预留的 token 数。
- 65536 —— DSH 固定预留的安全余量。

问题出在公式的后半段：不管窗口多大，它都减去固定的 65,536 token。窗口一旦低于约 330,000，这个固定减项就成了两个限制里更紧的那个，于是它变成真正的触发点：

| 上下文窗口 | DSH 实际触发位置 | 80% 应在的位置 |
| 128k | ~62k（49%） | 102k |
| 150k | ~84k（56%） | 120k |
| 256k | ~190k（74%） | 205k |
| 1M | ~678k（68%） | 800k |

窗口很小时（大约 65k 以内），固定余量会吞掉整个窗口：DSH 干脆拒绝配置主动压缩，只在请求因过长被拒之后才反应——这丢掉的历史远比一次计划好的压缩多。

为什么改配置文件没用

在 DSH 0.2 里，压缩策略藏在每个智能体预设内部，而预设是作为一个整体定义来寻址的：配置档配置文件也好，插件自己的配置层也好，都改不了其中单个字段。想把它写进磁盘，只能替换整个预设体——这会把你的预设钉死，再也拿不到 DSH 的更新。

所以这个插件不碰任何文件。它在 DSH 运行时改变压缩引擎的行为。

它做什么

- 低于你的触发点时，它回答「无事可做」，DSH 自己的检查根本不会跑。
- 达到或超过时，决定直接交回 DSH——和原版行为完全一致。
- 请求过长后的紧急恢复、手动 /compact 命令，一律不碰。
- 插件内部一旦出错，它就退到一边，DSH 的行为和原来完全就像插件没装一样。

适用的 DSH 版本

| DSH 版本 | 状态 |
| 0.2.1-rc.3 | 已验证 —— 本版本就是针对这个构建开发和测试的 |
| 后续的 0.2.x / 0.3.x | 预期可用：peer 范围是开放的，万一内部接缝变了，插件会自行退让，不会弄坏你的会话 |
| 早于 0.2.0-rc.2 | 不支持 —— 它包装的是按智能体预设的压缩引擎，这个引擎只在 0.2 系列里才有 |

机器可读的版本信息在 package.json 里：@deepseek-ai/ 的 peer 范围是开放的，测试过的构建记录在 dsh.verifiedWith。如果你的构建上它什么都不做，也不会弄坏任何东西 —— 先确认 Settings 里列出了 Compaction policy，然后带上 dsh --version 提 issue。

_最后验证：DSH 0.2.1-rc.3，2026-10-28（此前为 0.2.1-rc.2）。_

安装

dsh plugin --profile <your profile> add github:zyd232/dsh-compaction-policy

用你实际在跑的配置档 —— 桌面应用用 desktop，dsh web 用 web，或者你自己的配置档名。然后重启 DSH：插件条目只在启动时读取，不重启什么都不会变。

你不需要开新会话。已有会话会在下一步自动接上。

要卸载的话：

dsh plugin --profile <your profile> remove dsh-compaction-policy

设置在哪里

打开 Settings，看左侧边栏：内置分区旁边会多出一个 Compaction policy 条目。面板跟随 DSH 的语言设置（Settings → General → Language），默认英文，也包含中文。

里面的内容都保存到 DSH 常规的设置文档，立即生效 —— 不用重启。每个字段还有一个恢复默认按钮，用来清掉你的覆盖值。

设置项

| 字段 | 默认值 | 含义 |
| Enable | 开 | 关掉插件，回到 DSH 的原有行为。 |
| Routes | | 管哪些路由：provider 或 provider/model，逗号或空格分隔。 = 所有路由。 |
| Trigger ratio | 0.8 | 上下文达到窗口的这个比例时开始压缩。0.8 = 80%，也是 DSH 自己的默认值。 |
| Output reserve (tokens) | 24576 | 留给模型回答的余量。DSH 自己的值是 65536；提前触发的问题就靠这个参数解决。 |

怎么选值

先讲通用规则，再给例子。

- Trigger ratio —— 保持 0.8 就行，除非你想要额外的安全余量。窗口非常小的时候，有些人喜欢 0.7。
- Output reserve —— 设成你实际预期的最长回答，再加一点余量。16384–32768 能覆盖大多数聊天和编码工作；写超长文件的模型可能要更多。余量太小，请求可能因为回答没地方放而被拒。
- Routes —— 只想影响部分服务商时收窄范围。比如 llama-cpp（仅限 llama.cpp 提供的本地模型）、ollama、openai，或者用 ollama/ 逐个列出该服务商下的每个模型。

默认预留 24,576，对大约 123k 以上的每个窗口，触发点就变成干净的 80%；低于这个值则保持等比例。

怎么判断它在起作用

压缩会记录在会话日志里。如果你想要数字而不是感觉，就取压缩前那一刻的请求大小，除以模型的窗口：现在它应该落在你的触发比例附近，而不是以前那个 ~50% 的位置。

从界面上看，上下文环应该会继续增长，越过它以前会掉下去的那个点。

限制

- 它只移动触发点。 一次压缩保留多少历史、摘要可以有多长，仍然由 DSH 的压缩后端决定。
- 极小的窗口依然无解。 如果窗口连请求本身都装不下（固定的系统提示词加上工具 schema），任何策略都帮不上忙。DSH 的后端会拒绝为这样的路由配置主动压缩，本插件也刻意不去碰它，而不是无限重试。
- 它依赖 DSH 内部实现。 它通过 DSH 的服务 API（agentPresets.serviceFor(…, 'compaction')）找到正在运行的压缩引擎，并包装它的 compactIfNeeded 方法。如果未来的 DSH 重命名了该服务或改变了签名，插件就需要更新——在那之前它只会什么都不做，而不是乱来。
- 语言。 面板和本文档提供英文和中文，跟随 DSH 的语言设置；欢迎贡献更多语言。
- 兼容性。 @deepseek-ai/* 的 peer 范围刻意保持开放（>=0.2.0-rc.2，无上限），这样未来的 harness 版本永远不会阻止插件安装或加载。