前言¶

DeepSeek Harness（以下簡稱 DSH）是 DeepSeek 開源的智能體運行時，口號是「一切皆插件」：模型提供方、工具、界面、會話，都可以按插件裝進同一個進程。官方倉庫目前仍處於開發者預覽階段，接口會變。社區裏也有人維護插件目錄站點，用來檢索第三方插件；它和 DeepSeek / 幻方沒有官方從屬關係，不能當成官方應用商店。

實際落地時，卡點經常不在 DSH 本身，而在額度從哪來。不少公司並不直接發 DeepSeek、OpenAI 一類的平臺 Key，只給內部的 WorkBuddy 積分。DSH 默認模型列表裏又沒有「CodeBuddy 中國區」這一項。Axiaohungry 維護的 dsh-llm-codebuddy 就是爲這個缺口寫的：用 WorkBuddy 簽發的 API Key，在 DSH 裏調用 CodeBuddy 的模型服務。

本文依據插件目錄頁、GitHub 倉庫 README、package.json / 源碼，以及 npm 上的 dsh-llm-codebuddy@1.3.4 交叉覈實。文中命令和界面步驟以倉庫 README 爲準；目錄頁給出的 GitHub 安裝寫法會單獨註明。

這是什麼¶

dsh-llm-codebuddy 是一款「模型與提供方」類插件。安裝後會在 DSH 裏註冊名爲 CodeBuddy 中國區 的 Provider（內部 id 爲 codebuddy-cn）。你在 WebUI 填入從 WorkBuddy 拿到的 API Key，就可以拉取當前賬號可用的模型、改上下文窗口和最大輸出，再按普通 DSH 對話去用。

倉庫 README 寫得很清楚：API Key 由 WorkBuddy 提供，插件用這把 Key 去調 CodeBuddy 的模型接口；DSH 裏顯示的提供方名稱仍是 CodeBuddy 中國區。作者同時聲明：這是第三方適配器，不是 WorkBuddy、CodeBuddy 或 DSH 的官方插件。

幾個容易混在一起的名字，按插件自己的說明分開看：

• WorkBuddy：簽發 / 提供 API Key 和積分的一側；
• CodeBuddy：使用這把 Key 做推理的產品側；
• dsh-llm-codebuddy：把上述服務適配進 DSH 的社區插件。

不要和 DeepSeek 官方文檔裏「把 DeepSeek API 配進 WorkBuddy / CodeBuddy」那條路徑搞反。那是讓 WorkBuddy 去調 DeepSeek；這個插件是讓 DSH 去消化公司已有的 WorkBuddy 額度。

許可證爲 MIT，主要語言是 JavaScript。package.json 當前版本爲 1.3.4，npm 上同名包與倉庫一致。截至 2026-08-17，GitHub 倉庫顯示 13 顆星；社區目錄頁當時仍顯示 8 顆星，以倉庫即時數據爲準。

核心功能¶

根據 README 和源碼，插件當前做到的事情可以分成幾塊。

1、在 WebUI 的「添加提供方」裏直接出現 CodeBuddy 中國區，不必手改 DSH 全局安裝目錄。

2、配置面只要求一把 WorkBuddy API Key。Key 走 DSH 憑據服務保存，不會寫進模型目錄，也不會進插件源碼。輸入新 Key 並保存會替換舊值；輸入框留空再保存，則保留原 Key。

3、點「獲取可用模型」時，插件請求 CodeBuddy 的 /v3/config，只導入當前 Key 在 CLI Agent 下被授權的模型。別人賬號裏能看到的模型，不代表你這邊也能導入。更換 Key 後需要重新獲取一次。

4、導入之後可以改模型 ID、顯示名稱、上下文窗口、最大輸出 Token，也可以增刪條目、再同步一次目錄。沒有自定義目錄時走在線目錄；在線接口暫時不可用時，用插件內置目錄兜底。已知字段留空會繼承在線或內置值；全新模型若缺少容量信息，上下文窗口默認 262144，最大輸出默認 32768。點「恢復默認模型」會清掉自定義目錄。

5、思考檔位按模型各自聲明，而不是全站共用一套。DSH 界面上的檔位會被轉成 reasoning_effort 發給 CodeBuddy，推理在雲端執行。候選檔位是：

off / minimal / low / medium / high / xhigh / max

實際出現哪些檔位，取決於 /v3/config 裏該模型的 supportsReasoning、onlyReasoning、thinkingLevelMap 和 reasoning.effort。未手動選擇時，用服務端爲該模型返回的默認檔位；服務端沒聲明就不強行指定。

6、作者在 README 中寫明：已在 DSH 0.1.0-rc.6 上驗證。環境要求是 Windows / Linux / macOS，Node.js >= 22.19.0，並且本機已經裝好 DSH。安裝器自帶所需的 pnpm，不必再全局裝一份。DSH 仍是預發佈，以後如果改插件接口，這個插件可能要跟着升級；普通的 DSH 更新不會覆蓋它。

安裝與啓用¶

社區目錄頁給出的安裝命令是：

dsh plugin add github:Axiaohungry/dsh-llm-codebuddy

這是目錄站點統一的 GitHub 源寫法。如需可復現安裝，目錄頁建議固定 commit 哈希：

dsh plugin add github:Axiaohungry/dsh-llm-codebuddy#commit

把 #commit 換成實際提交哈希。插件以當前 dsh 進程的權限運行，安裝時可能執行代碼，裝之前應先看源碼和許可證。

倉庫 README 推薦的是 npm 包上的一鍵安裝，會同時寫進 DSH 的 web 和 headless 兩個 Profile：

npx --yes dsh-llm-codebuddy@latest install

也可以按 Profile 分開裝：

dsh plugin --profile web add dsh-llm-codebuddy@latest
dsh plugin --profile headless add dsh-llm-codebuddy@latest

只用 WebUI 時，執行第一條即可。裝完後重啓 DSH。

兩種入口不要混着理解：目錄頁走 GitHub 源；作者推薦走已發佈的 npm 包，安裝器還會處理 profile 和 pnpm 構建策略。日常使用以 README 的 npx ... install 更完整；若堅持用目錄頁那條 github: 命令，同樣需要先檢查倉庫內容，並在安裝後確認 Web Profile 裏已經出現該包。

在 WebUI 裏接上模型¶

按 README 的步驟：

1、打開「設置 → 模型」。
2、點擊「添加提供方」。
3、選擇 CodeBuddy 中國區。
4、輸入從 WorkBuddy 獲取的 API Key 並保存。
5、再點該 Provider 的「編輯」，展開「自定義設置」。
6、點擊「獲取可用模型」，勾選需要的模型並導入。
7、按需改上下文窗口、最大輸出等參數，然後保存。

再次編輯已配置的 Provider 時，會直接顯示上次保存的模型目錄。

如果裝完看不到 CodeBuddy，先確認已經重啓 DSH，再檢查 Web Profile：

dsh plugin --profile web list --depth 0

獲取模型失敗時，確認 Key 來自 WorkBuddy 且仍然有效，重新輸入後再點「獲取可用模型」。接口臨時不可用時，插件仍會提供內置目錄，但那只是兜底，不能代表當前賬號的真實權限。

工作原理¶

README 把調用鏈畫成：

WorkBuddy 提供 API Key
          ↓
DSH Agent → 本插件 → CodeBuddy /v2/chat/completions
                    ↘ CodeBuddy /v3/config（獲取模型）

分工也寫在同一節：DSH 負責 Agent 循環、上下文、工具調用和權限；WorkBuddy 提供 Key；插件負責 Provider 註冊、模型目錄轉換和請求兼容；CodeBuddy 負責推理並返回結果。

源碼裏當前使用的地址是 https://copilot.tencent.com/v2（對話）和 https://copilot.tencent.com/v3/config（模型目錄）。倉庫另附一份第三方開發說明，作者寫明這是根據已安裝客戶端和實際接口響應整理的，不是騰訊官方 API 承諾；路徑、Header 和字段可能隨 CodeBuddy 更新。本文只說明插件現在怎麼接，不把這些接口當成穩定公開 API。

內置兜底目錄裏能看到若干模型 ID，例如 deepseek-v4-pro、deepseek-v4-flash、glm-5.2、kimi-k2.7、minimax-m2.7 等。它們只在在線目錄拿不到時使用。真正能調哪些模型，仍然以當前 Key 在 /v3/config 的 agents[name=cli].models 爲準。插件不會把當前 Key 未授權的模型強行顯示出來。

配置值如果超過服務端真實限制，CodeBuddy 仍可能直接拒絕請求。把上下文窗口填得很大，並不等於服務端會按這個數字執行。

更新與卸載¶

更新：重新跑安裝命令即可拉到最新版。

npx --yes dsh-llm-codebuddy@latest install

更新後重啓 DSH。README 寫明模型配置和 API Key 不會被覆蓋。

卸載：

npx --yes dsh-llm-codebuddy@latest uninstall

卸載命令會：備份 ~/.dsh/settings.yaml；只刪除 llm-pi-ai.providers.codebuddy-cn；保留其他 Provider 和 DSH 設置；從 web、headless 兩個 Profile 移除插件；保留 API Key 憑據，方便以後重裝。備份文件名類似：

settings.yaml.codebuddy-backup-2026-08-14T12-00-00-000Z

源碼倉庫、本地安裝包和 API Key 都不會被這條命令刪掉。卸載後如果界面還顯示舊頁面，關掉正在跑的 DSH 再啓動；已經運行的進程不會自動把內存裏的插件卸掉。

適用場景與注意事項¶

適合的情況比較具體：本機已經在用 DSH，公司或團隊只發 WorkBuddy 積分，希望繼續在 DSH 的 Agent 循環、工具和權限模型裏工作，而不是改去 CodeBuddy 客戶端。Windows、Linux、macOS 都可以，前提是 Node.js 版本滿足 >= 22.19.0，並且 DSH 版本與插件驗證過的 0.1.0-rc.6 接近——DSH 仍在快速迭代，接口變了就要看插件是否同步。

不適合把它理解成「官方模型通道」或「穩定的騰訊開放 API」。作者自己把項目定位爲第三方適配器；模型目錄、思考檔位、可用模型列表都跟當前 Key 綁定，換一把 Key 結果就可能不同。也不適合在沒看過源碼的情況下，把任意社區插件直接裝進生產環境。

安裝前至少做這幾件事：打開 GitHub 倉庫覈對 README 與許可證；確認安裝命令來自目錄頁或倉庫原文，而不是口頭拼接；插件會以當前 dsh 進程權限運行，安裝時可能執行代碼；若走 GitHub 源，儘量固定 commit。API Key 只放在 DSH 憑據或環境變量裏，不要寫進 Git。

小結¶

dsh-llm-codebuddy 解決的是一個很窄、但真實存在的缺口：額度在 WorkBuddy，工作流在 DSH。它把 CodeBuddy 中國區 註冊成 DSH 的 Provider，用現有 Key 拉模型、改參數、發推理請求，不改 DSH 全局安裝目錄。能力邊界也清楚：第三方適配、按 Key 授權、接口可能變，裝之前要自己看源碼。

目錄頁：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-llm-codebuddy/

GitHub：https://github.com/Axiaohungry/dsh-llm-codebuddy