DSH 插件安装指南：Profile、Bundle、pnpm 与卸载

插件安装的核心命令

DeepSeek Harness 通过指定 Profile 管理外部插件，命令格式是：

dsh plugin --profile <name> <pnpm args>

例如官方 CLI 文档给出的社区 UI 示例：

dsh plugin --profile tui add github:deepseek-harness/turtle-ui
dsh plugin --profile tui remove turtle-ui

这些命令会在对应 Profile 目录中把参数转发给 pnpm，所以 pnpm 必须在 PATH 中。本文解释机制和风险，不代表 52DSH 已验证示例插件的安全性或当前兼容性。

Profile 与 Bundle 的关系

Profile 位于 $DSH_HOME/profiles/<name>，代表一套具名 DSH 组装。web 与 headless 在第一次使用时会从官方模板自动初始化；其他 Profile 可由插件命令创建。

插件包若在 manifest 中声明 DSH Bundle，成功安装后会自动加入该 Profile 的配置层栈。没有 Bundle 声明的包仍会作为普通依赖保留，但不会仅凭“已安装”自动产生 DSH 能力。

要查看实际配置树：

dsh --profile web --dump-config

更完整的组合原理见DeepSeek Harness 架构解析。

安装前必须检查什么

• 仓库、发布者、包名和许可证是否一致；
• 安装期间是否执行 prepare 或其他构建脚本；
• 插件会注册哪些工具、读取哪些文件、启动哪些进程；
• 是否需要网络、API Key、Cookie、数据库或外部服务；
• 是否声明兼容的 DSH 版本、操作系统和卸载方法；
• 代码仓库与发布包内容是否能对应。

插件进入 Profile 后可能运行在 DSH 进程中。安装成功不等于安全审计通过，也不等于它只能访问当前 workspace。

Git 插件与 allowBuilds

官方说明，随源码发布的 Git 托管插件常通过 prepare 脚本在安装时构建；pnpm 10 及以上默认可能阻止该脚本，并输出 allowBuilds 提示。正确做法不是关闭所有保护，而是：

1. 核对被阻止的包确实是你准备安装的插件。
2. 阅读它的 package.json 和构建脚本。
3. 只把输出提示中的具体键加入该 Profile 的 pnpm-workspace.yaml。
4. 重新执行原安装命令并检查最终依赖树。

已经构建的 tarball 或本地 checkout 不一定需要 allowBuilds，仍应验证来源和内容。

卸载与验证

使用同一 Profile 执行 remove：

dsh plugin --profile <name> remove <package>

成功后，插件管理器会更新 Profile 的 Bundle 列表。重新运行 --dump-config，确认对应配置层已经消失，再启动该 Profile 检查功能、凭据引用和残留文件。

卸载 npm 依赖不会自动删除插件曾写入的业务数据、外部账号或凭据。执行前先查看插件自己的清理说明，并保留 Profile 配置备份。

MCP 与 Skills 不是同义词

DSH 随附 MCP client 包，但默认不启用任何 MCP server。服务器命令在 Agent 沙箱外作为受信任可执行代码运行，配置前必须独立审查。Skills 更偏向可复用任务说明和资源；两者的详细边界见Skills 与 MCP。

寻找社区条目时可先阅读52DSH 插件目录验证标签，不要把“社区收录”误认为编辑验证或安全认证。