v2.8.6 — 摘要调用不再思考

改了什么

DSH 的压缩摘要默认跟着会话模型的推理设置走。总结历史并不需要思考链，关掉它同时省下
输出 token 和首字延迟。

天真做法已经在生产上崩过一次：直接给压缩调用盖上 reasoningEffort:'off'。
ReasoningEffortId 是 adapter 私有的不透明字符串，dsh-llm 会拿它比对该模型自己
公布的能力，不在集合里就在发起任何 provider I/O 之前抛
UNSUPPORTED_REASONING_EFFORT。结果不是"少想一点"，而是整个压缩事务失败。

现在怎么做

1. 先问再写：用 llm.resolveCallConfig({provider, model, reasoningEffort}) 探测，
   它是无 provider I/O 的能力查询。
2. 能降就降：该路由不接受"完全关闭"就沿阶梯降到它接受的最便宜一档，并记一条
   警告说明降到了哪一档。
3. 不确定就不写：一个档位都不接受、或能力查询本身报错，就把这个字段整个略过 ——
   本功能只是优化项，不能让它有机会拖垮压缩。
4. 兼容 llama.cpp：选中的是"完全关闭"档时，额外带一个顶层
   reasoning_effort:"none"。camelCase 那个字段会被 llama.cpp 的 OpenAI 兼容解析路径
   忽略（不在它的 schema 里）；llama.cpp 认的是顶层这个。两个字段同时发，DeepSeek 端点
   认前者、忽略后者，llama.cpp 端点认后者、容忍前者。

新增配置项 summarizationReasoningEffort：档位名不在阶梯里的 adapter 可以显式指定。
它仍然要过 resolveCallConfig，不被接受就退回阶梯并记警告 —— 绝不硬写。

一处必须说清的出处

llama.cpp 兼容字段的做法与"顶层 reasoning_effort:"none" 会被无条件解析成
enable_thinking=false"这个判断，来自 @falling-ts/dsh-force-compact
的实测结论（它引了 llama.cpp/tools/server/server-common.cpp:1295-1304）。
本仓库没有独立做过端到端验证。 已确认的是这个字段一定会到达 adapter
（dsh-llm 的派发是整体展开 options 往下传的），所以最坏情况是端点忽略它 —— 不会报错。

验证

• npm test 四个夹具全绿（含新增的 73 项断言）。
• test/quiet-effort.mjs 用的还是本仓库的套路：从源码里抽真函数跑，而不是复制一份。
  它钉住的是"不确定时绝不写字段"这条安全性质 —— 路由不声明任何档位、能力查询抛非档位
  错误、宿主没有能力查询 API，这三种情况断言一次 stream() 都不发。
• 传入一份硬写 'off' 的实现时该夹具应当失败。

v2.8.5 — README 面向小白从头重写

纯文档改动，没有任何行为变化。装过 2.8.4 的不需要更新。

安装（两步，不用 git、不用 npm）

1. 下载 dsh-compact-suite-2.8.5.tgz
2. 在 DSH 里打开 设置 → 插件 → 安装，选中刚才下载的这个 .tgz

装完按 DSH 的提示刷新或重启一次。

为什么重写

旧 README 是给开发者写的：30 秒概览、两栏「问题 → 做什么」表、六条实现机制、
触发点公式、HTTP 接口表、版本沿革。对第一次打开仓库的人，第一屏回答不了
「这是干什么的」，而且读起来很「机器味」。

这次按「读者是完全小白、且没有耐心」来写：

• 顶部三行讲清问题和它给出的答案，不绕。
• 功能是加粗关键词开头的短列表，每条一句话，不展开原理。
• 安装是一条下载链接 + 一次文件选择，不用 git、不用 npm、不用自己打包。
• 面板逐个对着真实控件写，名字和界面一字不差。
• 常见疑问只留 3 条真的会被问到的。

从 318 行压到 62 行，删掉了公式、机制编号、接口表、版本历史这些对小白是噪音的内容。

验证

• npm test 三个夹具全绿（142 项断言 / 0 失败）—— 代码一行没动，属于回归确认。
• README 里的每个控件名都逐字对着 lib/client.js 核对过（压缩 / 接管压缩阈值 / 触发阈值 /
  保留量 / 摘要模型 / 压缩记录）。

---

本 release 的附件就是要安装的文件；从源码打包的方式见 README 末尾的「从源码安装（开发者）」。

v2.8.4 — README 修正 + 压缩记录的「计算中」

文档与显示层改动，压缩行为、阈值计算、记录写入逻辑都没有变化。装过 2.8.3 的只需刷新页面。

1. README 修正一处错话

原文第一行写的是「阈值滑块往上拖，压缩还是提前触发」—— 但滑块是本插件的，原版 DSH
既没有压缩面板也没有滑块。把它放进「你会遇到的问题」，等于拿插件自己的 UI 当用户装插件之前
的处境，逻辑上不成立。改成：

原版没有压缩面板，什么时候压只能由引擎自己算

同时在触发点公式前点明归属（滑块是本插件的，原版没有），并把「于是滑块失效」改成
「只把比例调大没有用」，去掉同一处暗示。

2. 压缩记录：未结清的行不再只显示一个破折号

after 只在下一次用量采样到达时才写（这是 2.8.2 的修复），所以刚压完必然悬空。以前那格
只显示 —，落在数字位上分不清是 0、是出错、还是还没算完。现在：

位置	现在显示
after 那格	弱色的 —，与真实数字在颜色上区分开
节省量那格	「计算中」——空白看起来像「省了 0」
列表上方	一行说明 + 条数：N 条还在计算中：下一条消息发出后自动补上。
悬停	真实原因：provider 还没为新内容回报用量，这个数等下一次请求之后才算得准

只在确实有未结清行时出现；全部结清时不留这一行。面板每 5 秒刷新，所以下一次请求回报用量后
最多 5 秒自己就填上，不需要手动刷新。

它不是在后台算，是在等下一次请求。 如果会话之后一直没有新请求，就会一直停在「计算中」。

验证

三个夹具全绿（142 项断言 / 0 失败）。新增的断言做过变异测试，每一刀都必须被抓住：

变异	结果
去掉 dcs-pending 弱色标记	被抓住
去掉列表上方的提示行	被抓住
待回填计数永远返回 0	被抓住
节省量那格改成印数字	被抓住
破折号改成印 beforeTokens（复现旧 bug）	被抓住