天天打卡一小时编程 | 打通 DeepSeek Harness 与 WorkBuddy：dsh-workbuddy-connect 插件接入实战

一、今日学习概览
今天把第三方开源插件 dsh-workbuddy-connect 接入到 DeepSeek Harness，实现了在 Harness 里直接调用 WorkBuddy 桌面 App 的模型。核心是搞懂三条链路：插件怎么拿到本地凭据、怎么把模型分组注册进 Harness 的组合树、以及 pnpm 11 的新构建校验怎么放行。整段偏工程排障，不写业务代码，重点搞明白「为什么装完分组不出现」「为什么 plugin add 不等于生效」「凭什么插件能安全读到桌面 App 的登录态」。

二、我的收获

1. 分解：拆四层理解
   第一次分解：分清「装什么」。插件是一个 npm 正式包（0.7.4，MIT 协议），运行时唯一第三方依赖是 @earendil-works/pi-ai，它只读 WorkBuddy 桌面 App 的本地登录文件，从不回写，token 只发官方域名 —— 先审源码再安装。
   第二次分解：拆清 DSH 的 profile /bundle 机制。dsh plugin add 本质上只是 pnpm add 装包，不注册 bundle 就永远不会生效；要让插件真正合入组合树，必须把它加进 profile package.json 的 dsh.profile.bundles 数组，dsh 才会应用它的 cordis.patch.yml。

第三次分解：拆透凭据链路。凭据是 $wbEncrypted 加密格式存盘，插件靠拉起 WorkBuddy.exe 在本地解密、密钥只内存缓存不落盘；当 App 装在自定义路径时，得用环境变量 WORKBUDDY_ELECTRON_BIN 告诉插件去哪找它。

第四次分解：拆解 pnpm 11 的构建校验。onlyBuiltDependencies 和 package.json 的 pnpm 字段在 pnpm 11 已废弃，正确写法是 pnpm-workspace.yaml 里的 allowBuilds 白名单。
2. 组合：完整逻辑链条
主逻辑：插件把 WorkBuddy 的模型包装成一个 llm-workbuddy provider 挂进 Harness 的 provider 抽象层，应用层完全感知不到模型来自另一个 App。
安装：npm 正式包 0.7.4 ↔ 内核 0.2.0-rc.2 严格对应（rc.1→0.7.0、0.1.5~0.1.7→0.6.5）
注册：进 dsh.profile.bundles → 组合树出现 llm-workbuddy
鉴权：读本地凭据 → 拉起 WorkBuddy.exe 解密 → 只发官方域名
验证：模型选择器出现「WorkBuddy」分组 → 选免费模型 → 对话正常回复 → 显示 WB.2,000 积分
3. 测试：业务案例理解
举真实案例：第一次 dsh web 启动，模型选择器里根本没有 WorkBuddy 分组，--dump-config 一查，组合树里压根没有 llm-workbuddy 条目 —— 因为 plugin add 只装了包没注册 bundle。把插件加进 bundles 后重启，分组立刻出现。
再举一个：pnpm install 报 ERR_PNPM_IGNORED_BUILDS，@google/genai、protobufjs 的构建脚本被拦。人工核查两个脚本都是良性的（protobufjs 生成 stub、genai 是 Google 官方 SDK），用 allowBuilds 白名单放行，退出码才变 0。
4. 语言严谨性
dsh plugin add ≠ 插件生效，还要注册 bundle，这个点最容易想当然。
版本匹配是硬约束：内核 0.2.0-rc.2 → 0.7.4、rc.1 → 0.7.0、0.1.5~0.1.7 → 0.6.5，错配不生效。
桌面 App 内置核心是 0.2.0-rc.2（runtime.json 的 desktopVersion），跟独立 CLI 是两套，desktop profile 由 App 管理，不能用独立 CLI 绕过。

三、我的思考
插件接入本质是分层解耦—— 把「模型来源」和「应用使用」拆开，跟数据库三级模式的思路一脉相承：底层换存储、换模型源，上层业务程序不用重写。这套机制的巧妙在于凭据留在本地、解密在本地、token 只发官方域名，插件自身不落盘任何密钥，把「少拿权限、少留数据」做到了很干净。日常里我们选模型、切模型，本质就是在消费 provider 抽象层。

四、遇到的困难与解决方案
困难：pnpm 11 拦截 @google/genai、protobufjs 构建脚本，装包失败。
解决：废弃的 onlyBuiltDependencies 换成 pnpm-workspace.yaml 的 allowBuilds 白名单。
困难：插件装了但模型选择器不出现分组。
解决：--dump-config 定位到 bundle 未注册，把 dsh-workbuddy-connect 加进 dsh.profile.bundles，重启生效（改前已备份）。
困难：WorkBuddy 装在自定义路径 E:\全解工具\WorkBuddy，插件找不到凭据去解密。
解决：设置用户级环境变量 WORKBUDDY_ELECTRON_BIN 指向 WorkBuddy.exe。
困难：Web 和桌面 App 是两套 profile，桌面端内置核心版本未知、规则不同。
解决：读 runtime.json 确认 desktopVersion=0.2.0-rc.2，确认必须走 App 官方合规方式，不得绕过校验。

五、存在的不足
桌面 App 端的插件安装还在推进，未完全验证；对 DSH 插件协议的理解停留在「会装会用」，没到「会写一个自定义 bundle patch」的深度；凭据加密里密钥具体怎么派生（$wbEncrypted 的底层算法）没有深入源码。

六、下一步计划
完成桌面 App 端（desktop profile）的合规安装与对话验证；学习手写一个 dsh 插件的 cordis.patch.yml，把 provider 注册的机制真正吃透；尝试接入更多本地模型源，验证抽象层的复用性。