一、今日学习概览
今天把一个第三方开源插件 dsh-workbuddy-connect 接入 DeepSeek Harness，实现直接在 Harness 里调用 WorkBuddy 桌面 App 的模型，并做出「开机自启动 + 一键打开」的稳定入口。整段围绕四件事：插件怎么安全拿到本地凭据、怎么把模型分组注册进 Harness、pnpm 11 的新构建校验怎么放行、以及桌面双击场景下脚本为什么总是 "打不开"。全程先审源码再装、改配置先备份、不绕过官方校验。
二、我的收获
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、把 llm-workbuddy provider 合入组合树。
第三次分解：拆透凭据链路。凭据是 $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—— 本质是分层解耦。
- 安装：内核 0.2.0-rc.2 ↔ 插件 0.7.4 严格对应（rc.1→0.7.0、0.1.5~0.1.7→0.6.5）
- 注册：进
dsh.profile.bundles→ 组合树出现llm-workbuddy - 鉴权：读本地凭据 → 拉起 WorkBuddy.exe 解密 → 只发官方域名
- 验证：模型选择器出现「WorkBuddy」分组 → 选免费模型 Hy3 → 正常回复 → 显示 WB.2,000 积分
3. 测试：业务案例理解
真实案例一：dsh web 启动后模型选择器没有 WorkBuddy 分组，--dump-config 一查组合树里根本没有 llm-workbuddy—— 因为 plugin add 只装了包没注册 bundle。加进 bundles 后重启，分组立刻出现。
真实案例二：桌面双击一键脚本 "打不开"。逐个排查出三个叠加的坑：① 脚本带中文，cmd.exe 按 GBK 解析时中文乱码成命令直接崩（改纯 ASCII）；② cmd 的 for /f 读不了 web 写入的日志，type/PowerShell 却能读（改用 PowerShell 读日志）；③ dsh 不在用户 PATH，Explorer 环境找不到命令（改用绝对路径调用）。三个都修掉才彻底好。
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 用内置核心（
runtime.json的desktopVersion=0.2.0-rc.2），desktop profile 由官方 Electron 版托管管理，CLI 直接拒绝--profile desktop，不得绕过校验。
三、我的思考
整个接入的核心是分层解耦—— 把「模型来源」和「应用使用」拆开，跟数据库三级模式的思路一脉相承：底层换模型源，上层业务程序不用重写。而最值得称道的是凭据留在本地、解密在本地、token 只发官方域名，插件自身不落盘密钥，把 "少拿权限、少留数据" 做到很干净。另外这趟排障让我意识到："能用" 和 "好用" 之间差的是对环境的敬畏—— 同一个脚本，在我的终端里好好的，拿到 Explorer 双击就崩，因为 PATH、编码、文件锁这些运行环境假设都不同。
四、遇到的困难与解决方案
困难：pnpm 11 拦截 @google/genai、protobufjs 构建脚本，装包失败。
解决：废弃的 onlyBuiltDependencies 换成 pnpm-workspace.yaml 的 allowBuilds 白名单（两个脚本先人工核查为良性）。
困难：插件装了但模型选择器不出现分组。
解决：--dump-config 定位到 bundle 未注册，把插件加进 dsh.profile.bundles，重启生效（改前已备份）。
困难：WorkBuddy 装在自定义路径，插件找不到凭据去解密。
解决：设置用户级环境变量 WORKBUDDY_ELECTRON_BIN 指向 WorkBuddy.exe。
困难：一键脚本桌面双击 "打不开"。
解决：三层根因 —— 中文编码乱码（改纯 ASCII）、cmd for /f 读不了被锁 / 兼容差的日志（改用 PowerShell 读）、dsh 不在用户 PATH（autostart 用绝对路径调用）。
困难：想要一个 "一直用的网址"。
解决：dsh web 的 token 每次重启就换是安全设计，没有固定网址选项。改为「登录自启动 + 一键脚本自动读最新网址并打开」，入口固定、网址自动刷新。
五、存在的不足
对 DSH 插件协议的理解停留在 "会装会用"，没到 "会写一个自定义 bundle patch" 的深度；$wbEncrypted 加密密钥的底层派生算法没有深入源码；桌面 App 端（desktop profile）因官方托管管理，仍需在 App 内「插件」面板手动添加，尚未完成对话级验证。
六、下一步计划
尝试在桌面 App 的「插件」面板手动添加 dsh-workbuddy-connect，完成桌面端验证；学习手写一个 dsh 插件的 cordis.patch.yml，吃透 provider 注册机制；给一键脚本补一个 "检测不到网址时的更友好提示"，让边界情况更好懂。
浙公网安备 33010602011771号