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

插件安装的核心命令 DeepSeek Harness 通过指定 Profile 管理外部插件，命令格式是： 例如官方 CLI 文档给出的社区 UI 示例： 这些命令会在对应 Profile 目录中把参数转发给 pnpm，所以 pnpm 必须在 PATH 中。本文解释机制和风险，不代表 52DSH 已验证示例插件的安全性或当前兼容性。 Profile 与 Bundle 的关系 Profile 位于 $DSH HOME/profiles/<name ，代表一套具名 DSH 组装。web 与 headless 在第一次使用时会从官方模板自动初始化；其他 Profile 可由插件命令创建。 插件包若在 manifest 中声明 DSH Bundle，成功安装后会自动加入该 Profile 的配置层栈。没有 Bundle 声明的包仍会作为普通依赖保留，但不会仅凭“已安装”自动产生 DSH 能力。 要查看实际配置树： 更完整的组合原理见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： 成功后，插件管理器会更新 Profile 的 Bundle 列表。重新运行 dump config，确认对应配置层已经消失，再启动该 Profile 检查功能、凭据引用和残留文件。 卸载 npm 依赖不会自动删除插件曾写入的业务数据、外部账号或凭据。执行前先查看插件自己的清理说明，并保留 Profile 配置备份。 MCP 与 Skills 不是同义词 DSH 随附 MCP client 包，但默认不启用任何 MCP server。服务器命令在 Agent 沙箱外作为受信任可执行代码运行，配置前必须独立审查。Skills 更偏向可复用任务说明和资源；两者的详细边界见Skills 与 MCP。 寻找社区条目时可先阅读52DSH 插件目录验证标签，不要把“社区收录”误认为编辑验证或安全认证。