前言¶

用 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 自稱的「分支完整、未實測」，未做真機複覈。