dsh-workbuddy-oauth

dsh-workbuddy-oauth

把 WorkBuddy / CodeBuddy 的模型接入 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness)。

国内版与国际版各一套端点，自己走 OAuth 设备码流程——不读桌面 App 的凭据文件，所以不用装桌面 App，也不受它的安装位置、凭据加密格式与版本号影响。密码不经过本插件：授权在浏览器完成，插件只拿令牌。

• 多账号——同时登录多个，选号时自动跳过被限流的；某个账号额度耗尽只停它一个，其余照常服务。
• 会话粘性——同一个对话粘住同一个账号，不会中途换人；但不粘坏账号，下一条消息就换到健康的那个，上下文不丢。

---

安装

前置：pnpm 在 PATH 上、Node.js ^22.19.0 || >=24.0.0，以及一个 WorkBuddy / CodeBuddy 账号（国内版或国际版均可）。不需要安装桌面 App——登录由本插件自己走 OAuth 设备码流程完成。

> 要求 DSH 0.2.0-rc.2 或更高。 本插件的 peer 依赖声明为 ^0.2.0-rc.2，不再支持 0.1.x 与 0.2.0-rc.1：DSH 在 0.2.0 把设置服务换成了 Config 表单门面，同时把 pi-ai 升到 0.87（Context 类型收窄），跨代混用会出现两套 pi-ai 并存。只跟最新一代，省掉这层兼容负担。

从 GitHub 安装（推荐）

dsh plugin --profile web add github:molly-ovo/dsh-workbuddy-oauth
dsh web

本仓库包含构建好的 lib/，所以这一步不需要 pnpm install、也不需要构建，装完即可用。

从本地源码安装

git clone https://github.com/molly-ovo/dsh-workbuddy-oauth.git
dsh plugin --profile web add ./dsh-workbuddy-oauth

两种方式的共同点

dsh plugin 会把参数转发给 pnpm 在 profile 目录里执行，成功后自动对账 dsh.profile.bundles——本插件声明了 dsh.bundle.patch，装上即接管模型目录，无需手改 profile 文件。web profile 首次使用时自动从模板初始化。

装完刷新浏览器。模型 provider 目录在进程启动时组成；若模型没出现，重启 dsh web。

> 升级：重新执行一次安装命令即可。GitHub 形式的依赖在 lockfile 中锁定 commit SHA，不会自动跟随新提交，需要重新 add 来重新解析。

确认已生效——运行 /wb-status 应有输出。若没有：确认该 profile 的插件行 enabled、llm-workbuddy-oauth 已注册，并检查「插件」页是否能看到本条目。

卸载：

dsh plugin --profile web remove dsh-workbuddy-oauth

账号凭据与插件状态都在 $DSH_HOME/workbuddy-oauth/ 下，卸载不会删除；要彻底清理请手动删该目录（见[隐私](#隐私)）。

---

用法

登录：卡片顶部「登录 · 国内版 / 国际版」→ 浏览器完成授权 → 回卡片点「我已完成授权」。也可以直接用命令，两条路径走的是同一套实现。

| 命令 | 作用 |

|---|---|

| /wb-login [cn \| global] | 登录（默认 cn），会弹出可直接点击的授权链接 |

| /wb-status | 查看已登录账号、区域、令牌有效期 |

| /wb-account [enable\|disable] | 启用 / 停用账号 |

| /wb-logout [uid 前缀] | 退出登录（只删本插件保存的凭据，不动上游账号） |

登录、状态、账号管理与积分查询也可在 设置 → 插件 → DSH WorkBuddy OAuth 卡片中完成。composer 输入区右侧另有一个探测控件，用于探测当前模型的推理档位。

> 探测会向上游发出真实请求并消耗少量积分，因此有二次确认。

---

工作原理

DSH 模型选择器
  └─ pi-ai adapter（注册 provider route）
       └─ 回环端点  127.0.0.1，进程内，带一次性共享密钥
            └─ 上游  copilot.tencent.com / www.workbuddy.ai 等

• 无常驻进程、无对外端口。 回环端点在本插件进程内，只绑 127.0.0.1，并校验进程内生成的共享密钥。
• 凭据每账号一文件，原子写入，权限 0600。
• 令牌刷新惰性触发（过期前 5 分钟），进程内单飞 + 跨进程文件锁——上游会轮换 refresh token，并发刷新会让第二个请求送出已被消费的令牌。
• 设备指纹按 uid 稳定派生，同账号恒定、跨账号隔离；登录流程不带指纹。

同类方案的凭据来源主要有三种，本插件选了第一种：

| 路线 | 凭据来源 | 需要桌面 App | 代表实现 |

|---|---|---|---|

| 本项目 | 自己的 OAuth 设备码流程 | 不需要 | — |

| 读桌面凭据 | 桌面 App 的本地文件 | 需要 | [dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect) |

| 外部代理进程 | 本地网关进程 | 视实现而定 | workbuddy2api 系（如 [tearslee/dsh-workbuddy2api](https://github.com/tearslee/dsh-workbuddy2api)） |

代价是要自己维护登录流程；换来的是不依赖桌面端的安装位置、凭据加密格式与版本号。

为什么不 fork

本插件没有 fork dsh-workbuddy-connect，而是把它需要的模块移植（vendor）进来。

主要原因是两者的取舍不同：connect 复用桌面 App 的凭据文件，本插件改为自己走 OAuth 设备码流程。改动集中在凭据来源这一层，但会牵动登录、刷新、状态落盘等多处，改到后来已经不太像同一个项目。

另一个考虑是我自己的：fork 在 GitHub 上是一种公开的关联，会出现在上游的 fork 列表里。我的这种做法上游作者未必认同，不想因为自己的选择给他添麻烦，所以没有走 fork。