推理档位怎么选才靠谱？dsh-workbuddy-connect 哨兵请求与串行队列原理图解-开发者社区

【免费下载链接】dsh-workbuddy-connect

将 WorkBuddy 桌面 App 包含的模型自动接入 DeepSeek Harness，零配置使用。Bring the models in the WorkBuddy desktop app into DeepSeek Harness with zero configuration.

项目地址：https://gitcode.com/gh_mirrors/ds/dsh-workbuddy-connect

点击查看免费下载

在 DeepSeek Harness（DSH）中使用 WorkBuddy 桌面 App 的模型时，dsh-workbuddy-connect 用一种叫哨兵请求的探测机制，自动测出每个模型真实支持的推理档位（reasoning effort），全程零配置。这套机制看似简单，背后却藏着三个关键设计：一次“必然被拒绝”的哨兵探测、一套防误判的三步流程，以及保证不干扰正常聊天的串行队列。下面带你读懂它的完整原理。

为什么不能直接挨个试档位？

推理档位（low/medium/high/xhigh/max）决定了模型思考的深度。WorkBuddy 里部分模型没有明确声明自己支持哪些档位，这时插件需要去“问”上游接口：这些档位到底能不能用？

最直觉的做法是逐项发送请求测试。但实测发现一个坑：有些模型虽然接受reasoning_effort参数，却会忽略未知值并悄悄回退到默认行为。也就是说，你发来什么值它都返回 200 成功——哪怕这个值根本不存在。此时逐项扫描得到的全是“假阳性”：每个档位都“通过”，但没有任何一个档位真正生效。

哨兵请求：一发“必错弹”判断上游是否校验

哨兵请求（sentinel probe）就是为破解这个难题设计的。核心思路只有一句话：

发一个不可能存在的随机档位值给上游，看它接不接受。

这个哨兵值由随机数生成器产出，形如probe_sentinel_3fa9...（十六进制随机数），保证每次不同、绝不可能撞上某个真实档位。结果分两种：

上游拒绝了哨兵（返回参数校验错误码）→ 说明上游真的在校验这个参数，此时逐项档位扫描的结果才有意义；
上游居然接受了哨兵→ 说明它对参数“照单全收”，逐项扫描的结果一律不可信，检测到此为止，避免白白多花积分。

这一步回答的正是逐项扫描永远回答不了的问题：上游到底认不认这个字段。

完整的三步探测流程

在 probe.ts 中，顺序被刻意固定下来——这不是性能优化，而是归因逻辑的要求：

步骤	做什么	为什么
1️⃣ 基线请求	不带`reasoning_effort`发一次普通请求	先证明模型、凭据、请求格式本身没问题，后续的 400 才能归因到档位参数上
2️⃣ 哨兵请求	发一个随机非法档位值	判断上游是否校验该字段（见上一节）
3️⃣ 逐项扫描	依次发送`low`/`medium`/`high`/`xhigh`/`max`	只有哨兵被拒绝后才执行，收集真实被接受的档位

两个细节体现“省钱”原则：

每个探测请求的内容只有一词ping（PROBE_PROMPT），输出上限只有 1 个 token——反正答案内容从不被读取，只看 HTTP 状态与错误码；
每个请求附带 30 秒超时（PROBE_REQUEST_TIMEOUT_MS），防止某次探测挂起把整个队列卡死。

另外，扫描中途只要出现一个既非“接受”也非“参数错误”的模糊回答（比如限流、网络故障），整轮结果会被标记为unknown，而不是把部分结果当成结论——宁可少声称，不可错声称。

串行队列：为什么一次只跑一个探测

探测会发送真实计费请求，所以 probe-service.ts 实现了严格的串行队列（serial queue），两条规则是结构性的，不是建议：

一次只有一个探测在跑：用户真实的聊天请求不能与探测扫描争夺上游配额和连接；
没有明确授权就什么都不发生：每次探测都由用户在界面上手动点击确认触发，绝不自动扣积分。

队列的工作方式很优雅：

新请求通过queue.then(...)挂到前一次运行之后，天然排队，手动 API 与未来的自动触发共用同一队列，永远不会重叠；
如果同一账号、同一模型已有进行中的探测，重复点击会共享同一个 Promise，不会发起第二轮请求；
一次探测失败不会“毒化”后续队列——链尾捕获异常后继续存活；
若模型在模型目录中已声明档位、或已有有效缓存结果，队列内会直接短路返回，一个请求都不发。

检测结果如何使用：观察而非能力承诺

检测结果被称为“observation（观察）”，措辞有讲究：

它只表示当前上游接受了这些档位写法，不承诺档位一定改变推理效果、速度或积分消耗；
结果按账号隔离存储：同一模型在不同订阅账号下可用的档位可能不同，记录只服务产生它的账号，切换账号后切回来也能找回自己的旧记录（见 probe-store.ts）；
结果有14 天有效期，且当上游模型目录中该模型的关键字段变化（记录带指纹）时自动失效，避免过期的观察继续授予档位选项；
上游明确声明了档位的模型（如 GLM-5.3 系列可选 low / high / max）永远直接采用声明值，本地探测结果永远排在声明之后。

检测完成后，被接受的档位会直接出现在输入框旁的模型选择器里：

在哪里触发探测

设置 → 插件 → WorkBuddy Connect 卡片：展开后的「状态」标签里有完整的推理档位检测列表，每个模型旁有“开始检测 / 重新检测”按钮，还能看到最近一次检测的时间（国内版、国际版各有一张卡片）；
输入框旁的「推理等级」控件：检测到档位后，这里会显示“已接受：low / medium / high / xhigh / max · 点击可重新检测”，即点即测（见 WorkBuddyProbeControl.tsx）。

一句话总结

dsh-workbuddy-connect 的探测机制 =基线 → 哨兵 → 逐项扫描三步串行请求 + 一条不与真实对话抢跑路的队列。哨兵请求用一发“必错弹”区分“严格校验”与“照单全收”两种上游，串行队列保证每次探测都可控、可归因、可省钱，而结果以“观察”的身份按账号、按有效期管理——这就是零配置背后，让每个推理档位都经得起实测的完整原理。