推理档位补全 junjundesk/dsh-default-reasoning-efforts

dsh-default-reasoning-efforts

给 DeepSeek Harness（DSH）用的 Host 插件：所有没有声明推理等级的模型，自动获得 high / xhigh / max 三档。

配套 dsh-codex-effort-slider 用：滑条能不能滑到某档，取决于模型有没有那一档；本插件负责把缺的档位补上。

为什么必须改配置（而不是在界面上「造」三档）

档位不是 UI 变出来的，是 Host 侧 LLM 适配器报出来的模型能力：

profile 配置 reasoningEfforts → dsh-llm-pi-ai: resolveModelReasoning() → pi-ai thinkingLevelMap → getSupportedThinkingLevels() → reasoningInfo() → ctx.llm.resolveModelInfo() → 模型目录（浏览器）→ 官方菜单「推理等级」那一行 / 滑条刻度

配置里没写 reasoningEfforts 的模型，解析结果是 reasoning: false （手写声明的模型不在 pi-ai 内置目录里，没有可继承的能力）。后果是双重的：

1. 模型目录里没有档位 → 官方菜单连「推理等级」那一行都不渲染 → 滑条无处可挂；
2. 就算客户端硬塞一个档位，dsh-llm 在 resolveCallWithInfo() 里也会以 UNSUPPORTED_REASONING_EFFORT 直接拒掉这次请求。

所以唯一端到端成立的做法是把档位写进 provider 配置，让适配器自己认。

它做什么

apply() 里做一次幂等、可重入的配置补齐：

1. 等目标 entry（默认 @deepseek-ai/dsh-llm-pi-ai）出现在 configEditor 里（退避重试约 30 秒）；
2. 读它的有效配置，找出 providers.<route>.models[] 里所有 reasoningEfforts 未声明的模型；
3. 用官方 ctx.configEditor.edit() 写回 profile patch （走 Loader 正常路径：校验 → 原子写 → 失败回滚；YAML 注释保留）；
4. ctx.emit('llm/adapters-updated') —— 已连接的浏览器会立刻重拉模型目录，不用刷新页面。

幂等：没有任何要补的模型时，一个字节都不写，也不会触发重载循环（档位已经等于目标档位的模型会被跳过，所以第二次运行是彻底的 no-op）。

热装即可生效（不用等重启）：写配置这一步被刻意放在 HMR 事务之外执行。
原因是实测踩到的坑 —— configEditor.edit() 内部是 hmr.runExclusive()，而 runExclusive 一旦发现自己已经处在一次 HMR 事务里就直接拒绝（HMR transactions cannot be nested）；插件热装/热启用时 apply() 恰好跑在这样一次事务里，而且 hmr 用的是 AsyncLocalStorage，上下文会顺着 setTimeout 一路传下去 —— 所以「晚一点再写」根本逃不出去（第一版插件就是这么静默失败的）。
现在照官方 hmr.watchConfig 的做法用 AsyncLocalStorage.exit() 把写入放到事务外，拿不到就退回普通调用；写入被拒时还会退避重试（约 37 秒），绝不静默吞掉。

默认规则

| 模型状态 | 默认行为 |
| 没写 reasoningEfforts | 补上 {high: high, xhigh: xhigh, max: max} |
| 写了 reasoningEfforts: false | 不动（显式声明「这个模型没有推理」，视为用户的明确选择） |
| 写了别的档位表 | 不动 |
| 写了但恰好就是这三档 | 不动（保证幂等） |

可选配置

$DSH_HOME/dsh-default-reasoning-efforts/config.json（不存在就用内置默认值，改完下次检查即生效）：

{
"enabled": true,
"levels": { "high": "high", "xhigh": "xhigh", "max": "max" },
"targets": ["@deepseek-ai/dsh-llm-pi-ai"],
"providers": [],
"includeDeclared": false,
"dryRun": false
}

| 键 | 含义 |
| enabled | false = 完全不动手（插件照常加载，只跳过补齐） |
| levels | 要补的档位表：键只能是 pi-ai 的七档名 off/minimal/low/medium/high/xhigh/max，值是线上拼写（off 允许 null = 不发送该参数） |
| targets | 要管的 entry 包名（默认只动 pi-ai 适配器；别的适配器 schema 不同，别乱加） |
| providers | provider route 白名单（[] = 全部） |
| includeDeclared | true = 连已声明（含 false）的模型也覆盖成 levels |
| dryRun | true = 只在日志里说会改什么，不写文件 |
| pollSeconds | 兜底自检间隔（秒，默认 30，0 = 关掉）。见下 |

新加的模型什么时候会被补上

| 时机 | 会不会补 |
| 每次 DSH 启动 | 一定。启动那次检查会扫全部模型，缺档位的一个不落 |
| 运行中在设置页新增模型 | 会，最多 pollSeconds（默认 30 秒）内 |
| 运行中手改 cordis.patch.yml 文件 | 要等下次启动（实测：这个环境里 HMR 的配置监视没把文件改动送进运行中的 Loader；反正下次启动会补） |
| 插件被禁用（enabled: false） | 不补 |
为什么要有 pollSeconds 这个自检：宿主确实会发 llm/adapters-updated / settings/document-updated / hmr/reload 这几个事件（插件都订阅了），但「事件有没有送达」不在本插件的控制范围内 —— 与其把正确性押在上面，不如按固定间隔自己看一眼：有活就干，没活就是一次纯读的 no-op。
30 秒一次的读取成本可以忽略，换来的是「新加的模型一定会被补上」这个确定性。

配置非法时会退回内置默认值，并在日志里说明原因（不静默）。

回执：它到底做了什么

每次检查的结论会写到 $DSH_HOME/dsh-default-reasoning-efforts/status.json （只在结果变化时写，不是每次事件都动磁盘）：

{
"at": "2026-10-14T01:41:46.342Z",
"pid": 23388,
"enabled": true,
"targets": ["@deepseek-ai/dsh-llm-pi-ai"],
"levels": { "high": "high", "xhigh": "xhigh", "max": "max" },
"status": "patched",
"matchedEntries": ["llm-pi-ai"],
"changedModels": [{ "provider": "local", "model": "step-5-preview", "levels": { "high": "high", "xhigh": "xhigh", "max": "max" } }],
"wrote": true,
"error": null
}

status 取值：patched（补了）/ no-change（没活可干）/ dry-run / waiting-entry （目标 entry 还没出现）/ read-failed / write-failed / crashed / disabled。
排障第一步就是看这个文件 —— 它比宿主日志好找，也比「猜插件跑没跑」可靠。

安装

面板：设置 → 插件 → 添加插件 → 填仓库地址或本目录绝对路径或命令行（非 desktop profile）：
dsh plugin --profile web add github:junjundesk/dsh-default-reasoning-efforts
本地开发时直接链本目录：
dsh plugin --profile web add link:"<本目录的绝对路径>"

零运行时依赖、无构建步骤（只用 node 内置模块），解开就能装。

测试

node test/plan.test.mjs # 43 项断言：档位规范化 / 配置规范化 / 补齐规划 / HMR 事务逃逸 / 端到端接线

测试里有一份假 configEditor：edit() 会把新配置落到 entry 上，所以「第二次运行必须一个字节都不写」这件事是被真断言守着的，而不是靠肉眼。其中一项是回归测试：用真的 AsyncLocalStorage 模拟 hmr 的事务上下文，并让 edit() 在事务内直接抛 HMR transactions cannot be nested —— 它复现了第一版插件的真实故障，也守着修复不被改回去。

已知边界

- 只改 providers.*.models[].reasoningEfforts 这一个字段，其它字段原样保留。
- 补的是声明，不是「让模型真的会思考」：端点是否接受 xhigh/max 由上游决定，与你在同一个 provider 里给别的模型写的那套拼写保持一致。
- targets 默认只含 pi-ai 适配器。别的适配器（如官方 DeepSeek）有自己的固定档位表，强行补档位可能让请求被上游拒掉。
- 卸载/关掉后，已经写进 profile patch 的 reasoningEfforts 不会自动删掉 （那是你的配置，插件不替你回滚）——想恢复就把那几行删掉。

许可

MIT。