【免费下载链接】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 HarnessDSH中使用 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只有哨兵被拒绝后才执行收集真实被接受的档位两个细节体现“省钱”原则每个探测请求的内容只有一词pingPROBE_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 的探测机制 基线 → 哨兵 → 逐项扫描三步串行请求 一条不与真实对话抢跑路的队列。哨兵请求用一发“必错弹”区分“严格校验”与“照单全收”两种上游串行队列保证每次探测都可控、可归因、可省钱而结果以“观察”的身份按账号、按有效期管理——这就是零配置背后让每个推理档位都经得起实测的完整原理。赞分享【免费下载链接】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点击查看免费下载相关推荐本地回环端点怎么做才安全dsh-workbuddy-connect 的 Loopback Shim 源码解读本地回环端点怎么做才安全dsh workbuddy connect 的 Loopback Shim 源码解读 dsh workbuddy connect 是直接在 DSH 里用 WorkBuddy 模型模型选择、图片输入与推理档位实用指南直接在 DSH 里用 WorkBuddy 模型模型选择、图片输入与推理档位实用指南 DSHDeepSeek Harness插件 dsh workbuddyThinkingCap-Qwen3.8-27B 思考档位怎么选xhigh、medium、low 三档推理力度全解析ThinkingCap Qwen3.8 27B 思考档位怎么选xhigh、medium、low 三档推理力度全解析 ThinkingCap Qwen3.8 2大模型人工智能微调上一篇提升Git变基效率git-interactive-rebase-tool的10个实用技巧下一篇Moonshine 使用教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考