在 DeepSeek Harness 中安装插件
先理解 Profile 与 Bundle 的关系，再安装经过审查的包，处理 pnpm 安装阶段构建提示，并在重启后确认插件真正生效。
本页内容
社区插件出现在目录里只代表可发现。安装前仍要检查仓库、包信息、权限、安装脚本和维护状态。
先理解 Profile 和 Bundle
DSH 的 Profile 有自己独立的依赖与 Bundle 组合。一个插件装进某个 Profile，不会自动复制到其他 Profile。只有包 manifest 声明了 DSH 所需 Bundle 元数据时，CLI 才会把它加入 Bundle 层。
Profile
位于 $DSH_HOME/profiles/<name> 的可运行组合，先确认你到底要修改哪个 Profile。
Bundle
向 Profile 启动组合贡献 cordis.patch.yml 的包。
普通依赖
依赖可以安装成功但不会自动变成 Bundle；没有 Bundle 声明时 CLI 会提示。
使用 dsh plugin 前先检查 pnpm
仅运行 npx @deepseek-ai/dsh web 不要求你先装 pnpm，但插件管理不同：官方 dsh plugin 命令会把包操作交给 pnpm，因此 pnpm 必须在 PATH 中。
pnpm --version安装前先审查插件
- 确认仓库和包确实属于预期作者。
- 阅读 README 与 package install/build scripts。
- 检查它可能访问的文件、网络、凭据和外部可执行程序。
- 审查完成后优先固定明确版本或 commit，不要盲目追随不断变化的分支。
它的安装和运行不是“模型文字建议”，而是在你的机器上执行软件依赖，应按普通本地软件的安全标准审查。
把包添加到正确的 Profile
官方通用命令格式：
dsh plugin --profile <name> add <package-or-git-spec>把 <name> 换成你确实想修改的 Profile。相对本地路径会以运行命令时所在目录为基准。
先进入作者仓库或包页面确认当前安装方式，再固定你审查过的版本或 commit。
看到 allowBuilds 时先停止并检查
Git 源码插件可能在安装时执行 prepare 构建。pnpm 10+ 会先阻止这类安装阶段构建，因此首次 add 可能失败，并提示 allowBuilds 与对应 Profile 的 pnpm-workspace.yaml。
只有你已经检查源码，并且明确愿意允许这段安装阶段代码执行时，才按照 pnpm/DSH 打印的 key 修改该 Profile 的配置，然后重新运行 add。
它代表允许依赖在安装阶段执行代码。不要为了让报错消失就直接批准。
Bundle 变化后要重启
add/remove/update 成功会修改磁盘上的 Profile，但正在运行的 Profile 仍保持启动时加载的 Bundle 集合。修改 Bundle 成员后重启对应 Profile；如果由 DSH Desktop 管理，则重启 Desktop/Profile。
普通 cordis.patch.yml 编辑可以热加载，但 Bundle 成员变化跨越了启动边界。
验证插件是否真正生效
- 01
确认 Profile
你重启的必须是刚才修改的那个 Profile。
- 02
确认能力出现
检查目标工具、Preset 选项或 Provider 是否出现；“安装成功”不等于功能已经激活。
- 03
小范围测试
先用可丢弃工作区执行一个小任务，再让插件访问重要项目或凭据。
常见问题
pnpm is not recognized
安装 pnpm 或修复 PATH。npm quick-start 可用，并不代表插件管理已经有 pnpm。
Git 插件首次 add 出现 allowBuilds
检查安装脚本；确认愿意执行后，只加入 pnpm 打印的对应 key，再重试。
命令成功但插件没出现
重启 Profile。当前启动周期不会自动更换 Bundle 集合。
一个 Profile 有插件，另一个没有
Profile 的依赖和 Bundle 是独立的，需要分别安装和审查。
依赖装好了但没出现功能
包可能没有声明 DSH Bundle，或 Bundle 只注册了休眠 Provider，还需要对应 Preset/Tool row 才会启用。
DeepSeek Harness CLI 行为参考，其中明确记录 pnpm 转发、Bundle 重新计算、重启边界和 Git 源码插件的 allowBuilds 行为。