安装和管理 DeepSeek Harness（DSH）插件

9 月 9 日预发布选择提示

0.1.5-alpha.1 已发布到 npm alpha 通道，latest/next 仍为 rc.1。本页原固定命令与适用版本保留；新版会话 V3、Agent/Inbox 和侧栏接口需分别评估，不把能安装当作插件兼容验证。先读新版变化与升级备份及回退边界，再决定是否使用独立数据副本评估；单独 Profile 不自动隔离所有存储。

当前任务入口与历史基线

2026-09-06 核对的 npm 默认版为 0.1.2-rc.1。本文下方 0.1.1-rc.2 命令与 alpha.2 清单说明保留其历史审阅范围，不表示它仍是当前默认版；本次未重审整篇插件指南。

• 接入消息平台：IM 飞书接入、微信与 Telegram 差异。
• 维护已有环境：按安装方式更新 DSH、卸载插件与保留数据。

先看完整路径

安装 DSH 插件不是把包名复制进命令就结束。更稳妥的顺序是：在插件中心找到候选条目，阅读插件详情里的兼容性与权限，确认目标 Profile，执行安装，再用 dump-config 核对配置层；若站内已有专属配置教程，继续按教程完成配置、验证和回滚准备。

在 DeepSeek Harness 0.1.1-rc.2 中，Profile 是一套具名组装，Bundle 是向该组装贡献 Cordis 配置层的分发格式。只有包清单声明了 DSH Bundle，插件管理命令才会把它加入 Profile 的 Bundle 列表。

alpha.2：安装后怎样看清插件组合

2026-08-31 本次复核的是 alpha.2 的插件清单界面；下方 CLI 安装与卸载步骤仍按 0.1.1-rc.2 基线阅读，没有执行第三方插件测试。在该次历史核对时，新版包已存在于 npm，但默认通道仍是 0.1.1-rc.2，先看alpha.2 更新与升级判断再决定是否评估。

在 alpha.2 Web 中打开“设置 → 插件 → 插件列表”：

1. 先看默认展开的“会话插件”组；预设切换器用于选择要查看的 Agent 预设，不是选择安装 Profile。
2. 输入模块名或条目 ID 搜索。搜索会展开分组，并提示其他预设中的匹配；可进入相应预设查看。
3. 展开条目，核对完整模块标识、来源、配置状态和运行状态。预设条件启用不等于当前已经运行。
4. 展开“全局插件”。如果模块全局停用但由预设提供，查看“启用于”所列预设，不要只凭停用字样重新安装。
5. 安装或配置变化后重新打开设置取得新快照；读取失败可重试。该清单不会订阅 Loader 变化，也不会在重连后自动刷新。

这是只读清单，切换预设只改变显示，不会修改当前会话或写入设置。 实际默认预设和新会话预设仍在各自入口选择。它不能替代下面的 Profile 包管理，也不构成权限隔离。官方清单说明 ↗（外部链接，在新标签页打开）

安装位置看 Profile；会话如何组合能力看 Agent Preset；是否处于运行状态看清单与日志；能访问哪些资源仍需独立审查权限。不要把这四个问题混在一起，也不要由官方界面更新推断社区插件全部兼容。

v0.1.2-alpha.1 对插件和 Profile 的影响

GitHub 的 0.1.2-alpha.1 预发布版允许插件在模型设置页增加 Provider 登录控件。这使第三方认证可以进入统一设置流程，但不会自动提高插件的证据等级。安装前仍要审查插件来源、登录回调、凭据存储、撤销方式和网络权限；本文没有运行第三方插件，也不能由官方 Release 推导出目录中的社区插件都已兼容 alpha。

官方 Release 同时说明，DeepSeek 官方适配器默认会随请求提供已启用插件的包名和版本，部署方可以配置关闭；可选的 Session 日志增量上传则默认关闭。两者不是同一个开关。企业或敏感项目应在升级前分别记录：

• 哪些 Profile 启用了哪些插件及版本；
• 插件包信息是否允许随官方 DeepSeek 请求提供；
• Session 日志增量上传是否保持关闭；
• 登录插件可以读取和保存哪些凭据；
• 日志、代理和监控系统是否会保留相关元数据。

截至 2026-08-28，npm 默认安装仍为 0.1.1-rc.2。准备评估新能力时，先阅读v0.1.2-alpha.1 更新内容与升级判断和DSH 更新、回退与卸载指南，使用独立 Profile 与可撤销测试凭据；不要批量改写现有插件的兼容版本标签。

插件安装的核心命令

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 中。相对路径和 file:、link: 形式会先锚定到调用目录。本文根据固定官方源码说明机制，没有安装或运行示例插件，也不代表 52DSH 已验证其安全性或当前兼容性。

Profile 与 Bundle 的关系

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

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

要查看实际配置树：

dsh --profile web --dump-config

--dump-config 不启动应用，它会展示 Bundle、Profile、Home 和命令行 patch 叠加后的配置。更完整的组合原理见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，仍应验证来源和内容。若安装输出明确提示构建脚本被阻止，进入DSH 插件 allowBuilds 排障查看最小授权和复核方法，不要把所有依赖加入白名单。

安装后怎样验证

1. 重新执行 dsh --profile <name> --dump-config，确认目标 Bundle 出现在预期配置层。
2. 新启动对应 Profile；官方当前版本不会把新增 Bundle 热加入已经运行的 Profile。
3. 检查插件提供的入口、工具或设置是否出现，不要先授予真实凭据或宽泛工作区。
4. 用测试目录和最小权限执行插件文档中的验证动作。
5. 保存命令、DSH 版本、插件版本、预期结果与实际结果；源码审阅不能记作运行实测。

站内插件详情负责回答“它做什么、兼容什么、需要哪些权限”，专属配置教程负责回答“怎样安装、配置、验证与清理”。如果某个插件还没有专属教程，应先以仓库固定版本说明为准，不要根据描述猜测命令。

卸载与验证

使用同一 Profile 执行 remove：

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

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

卸载 npm 依赖不会自动删除插件曾写入的业务数据、外部账号或凭据。执行前先查看插件自己的清理说明，并保留 Profile 配置备份。完整的升级、回退、卸载和残留清理路径见DeepSeek Harness 更新与卸载指南。

MCP 与 Skills 不是同义词

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

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