前言¶

用 DeepSeek Harness 跑智能体，模型这一层通常要自己搭：找 endpoint、填 key、处理分组。如果模型是通过 WorkBuddy 桌面 App 使用的，事情更麻烦——登录态在 App 内部，模型列表在 App 里，没有现成的 API key 能直接抄给命令行工具。

下面介绍的 dsh-workbuddy-model 走的是另一条路：直接复用 WorkBuddy 桌面 App 已经登录的账号，把 App 里的模型注册成 DSH 的一个 provider。

这是什么¶

一句话：把 WorkBuddy / WorkBuddy AI 桌面 App 里已登录的模型接入 DeepSeek Harness。国内版与国际版各自显示自己的模型分组，各用各自的账号与积分。

仓库：a404855501/dsh-workbuddy-model（https://github.com/a404855501/dsh-workbuddy-model），npm 包名 dsh-workbuddy-model，发布版本 0.1.3，许可证 MIT。包内 author 是 arnen7000。README 的「来源」一节写明，它是基于 npm 包 dsh-workbuddy-connect@0.7.9 的构建产物修改而来，主要改动是适配 DSH 桌面版。

先限定一下它的能力范围：插件提供的是模型调用能力，不是把 App 界面搬进 DSH，也不是把模型权重导出到本地。分发形态只有预构建产物 lib/，仓库里没有可重建的源码树。

核心功能¶

插件做的事可以拆成三条：

1. 从 WorkBuddy 桌面 App 的登录态取凭据。Windows 上读 %LOCALAPPDATA% / %APPDATA% 下的 CodeBuddyExtension/.../auth，解密时定位 WorkBuddy.exe；macOS、Linux 各有一套路径分支，均未在真机上跑过。
2. 把模型注册成 DSH provider。provider id 是 workbuddy（国内版）与 workbuddy-ai（国际版）。
3. 不引入重依赖。README 明确不需要 Python，也不需要原生编译工具链；运行时依赖全是纯 JS，没有 .node 模块。

包 exports 除了入口 lib/index.js，还导出 ./client 与 ./cordis.patch.yml；package.json 里 dsh.bundle.patch 指向这个 patch 文件，说明它是通过 bundle patch 挂进宿主的。bin 是 lib/bin.js。

安装与启用¶

前置只有一条：本机已安装并登录 WorkBuddy 桌面 App（国内版 WorkBuddy 或国际版 WorkBuddy AI 任一）。

命令行安装：

dsh plugin --profile web add github:a404855501/dsh-workbuddy-model

或者走 DSH 插件市场：打开插件市场，搜索 workbuddy-model，点安装。安装、升级、卸载都在界面里完成，不用记命令。

需要固定到某个本地快照（改代码、锁版本）时，用本地目录装：

dsh plugin --profile web add <本插件目录>

桌面版走法不一样：desktop profile 由 App 独占，dsh plugin --profile desktop add 会被 CLI 拒绝。要在桌面版用，得走 App 自带的插件页：侧栏插件 → 添加插件 → 箭头 → 安装第三方插件，输入 dsh-workbuddy-model（npm 包名）或 file:<本插件目录>；安装源选中国大陆镜像源，装完点立即启用。本地路径必须带 file: 前缀，裸路径会被 pnpm 当成 link: 软链，在部分机器上会静默装不上。

装完核验：

dsh plugin --profile web list

末尾不应出现 is incompatible with dsh ...。升级用同一条 add 命令，重启 dsh 后生效。

安装脚本授权¶

第一次安装大概率遇到 ERR_PNPM_IGNORED_BUILDS。原因不在插件的构建本身：依赖 @earendil-works/pi-ai 会带进 @google/genai 与 protobufjs，这两个包各声明了一个安装脚本，pnpm 默认不执行。

README 对两个脚本的描述是：protobufjs 的脚本只检查依赖方写的版本前缀，不符就在 stderr 打一行 WARN；@google/genai 的 preinstall 是一条 echo。都不写文件、不联网、不编译。

桌面版插件页直接点允许这些脚本并重试。命令行下，CLI 会在 profile 的 pnpm-workspace.yaml 里写好占位项，把 set this to true or false 改成 true，再重跑同一条 add 命令：

allowBuilds:
  '@google/genai': true
  protobufjs: true

授权保存在当前 profile，之后不再询问。

环境要求¶

内核版本这里 README 内部有两处说法：安装环境表写 >= 0.2.1-rc.1，「适用范围」一节又写最低 0.1.7，并说明更老的内核（如 0.1.5-rc.2）实测会在加载阶段失败，因为它带的 @deepseek-ai/schemastery 没有 .volatile()；0.1.2 起会直接报 this DSH core is too old …。作者同时强调，package.json 的 peerDependencies 里故意没有声明任何 @deepseek-ai/* 版本区间：这些包由宿主提供，声明区间只会在宿主使用预发布版时被误判成「环境太老」。

跑过真实对话的组合只有 Windows x64：内核 0.2.1-rc.3（桌面版）、0.2.1-alpha.2、0.2.2-alpha.2、0.1.7-rc.1，国内版 5.9.3、国际版 5.8.4。上表之外但 0.1.7 以上的环境可以装，作者不保证好用。

平台支持按凭据来源分：

• Windows x64：已实测
• macOS：未实测（分支完整），读 ~/Library/Application Support/CodeBuddyExtension/...
• Linux：未实测（分支完整），探 $XDG_CONFIG_HOME 与 $XDG_DATA_HOME；WSL 额外探挂载的 Windows 目录

非 Windows 平台若自动发现不到解密用的 Electron 二进制，可以显式指定：

# 国内版
WORKBUDDY_ELECTRON_BIN=/path/to/WorkBuddy
# 国际版
WORKBUDDY_AI_ELECTRON_BIN=/path/to/WorkBuddyAI

macOS / Linux 上 WorkBuddy 桌面 App 是否存在、是否写同样的 auth 文件，README 明确说未验证；路径分隔符与大小写敏感性差异也只有在对应平台上跑一次才能确认。

适用场景与注意¶

适合谁：本机已经装了 WorkBuddy 桌面 App 并登录，想在 DSH 里直接调用 App 内那份模型、又不想自己写一套 provider 的人。可以在 App 里多端共用同一账号与积分。

装之前先看这几条：

1. provider id 会撞。注册的 id 是 workbuddy / workbuddy-ai，与 dsh-workbuddy-connect 等其它 WorkBuddy 桥插件相同。同时装两个，后注册的那个静默不激活——不报错，只是模型列表里没有它。装之前先卸掉别的桥。
2. 本质是伪装客户端。插件把 DSH 伪装成 WorkBuddy 官方客户端去调接口，上游有渠道校验机制，随时可能再次失效。App 升级、上游改校验规则，都可能让它失效。
3. 以当前 dsh 进程权限运行。插件跑在启动 dsh 的那个进程权限里，它能读到的凭据路径、网络出口和文件系统范围都等同于该进程。安装前建议自己过一遍 lib/ 的代码与许可证（MIT，另有 THIRD_PARTY_NOTICES.txt）。
4. 没有源码树。本仓库只发预构建产物 lib/，lib/ 就是唯一实现来源。

卸载：

dsh plugin --profile web remove dsh-workbuddy-model

remove 会同时移除 dependencies 与 bundles 登记，不需要手动改配置。只有 CLI 不可用或 profile 已经装坏时，才需要手工删掉 package.json 里的依赖行与 dsh.profile.bundles 中的条目，再 pnpm install。

附：信息来源¶

插件仓库：https://github.com/a404855501/dsh-workbuddy-model

社区目录页：https://www.skillhub.cn/plugins/a404855501/dsh-workbuddy-model

以上版本号、命令与平台说明均来自仓库 README 与 package.json；macOS / Linux 部分为 README 自称的「分支完整、未实测」，未做真机复核。