前言¶

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