如何安装 DeepSeek Harness 插件

前置条件

安装插件前，请先确认 DSH 已安装并正在运行：

Web 启动命令适合作为第一次检查，因为它能先确认 Harness 本身可以启动，再引入新的包。如果这条命令失败，应先修复基础 DSH 或 Node 环境；插件不能修复缺失的运行时。

安装前先决定要评估的 profile。下面使用 `web` 作为示例，团队也可以使用 `default`、`local-memory` 等有描述性的名称。安装命令和启动命令中的 profile 必须一致。

测试时保留启动 DSH 的终端。启动输出通常能最快区分 bundle 问题、Provider 凭据问题、被阻止的构建脚本和 profile 不匹配。

你应该能在 localhost:3000 看到 DSH Web 界面。

从 npm 安装

大多数插件以带有 dsh.bundle 清单的 npm 包发布。运行命令前，先阅读包页面和仓库 README，确认它会改变什么，以及需要哪些权限。

`--profile` 让安装目标保持明确。把包安装到 `web` 却启动 `default`，看起来就像安装失败，实际上包可能已经成功写入另一个 profile。profile 名称是安装身份的一部分，不只是显示设置。

命令成功只表示 DSH 下载了包并接受了 bundle 元数据，并不代表所有运行时依赖都正常。重启目标 profile，在启动输出中查找插件名称，再运行一个小的真实工作流，确认能力确实可用。

命令会下载包、注册 bundle 补丁，并在下一次启动时启用插件。

从 GitHub 安装

你也可以直接从 GitHub 仓库安装。当插件还没有发布 npm 包，或者你需要在正式版本前评估仓库代码时，这种方式很有用。

安装前阅读仓库的 package script、lockfile、许可证和近期提交。GitHub URL 可能指向持续变化的源代码；需要复现时固定到 commit 或 release tag，让其他人和环境加载同一份代码。

GitHub 安装比阅读 README 做出更大的信任决策。prepare script 可能在依赖安装阶段执行，包也可能在启动时请求网络或凭据。把实验放在可丢弃的 profile 中，如果权限范围和能力不匹配，就移除它。

验证安装

安装完成后重启 DSH，检查插件是否已加载。重启很重要，因为 profile 会在启动时读取 bundle 配置；如果旧进程仍在运行，正确的安装也可能看起来没有生效。

在启动日志中查找包名、bundle 入口，以及 `[ACTIVE]` 或类似的成功标记。如果日志识别到包却报告依赖错误，说明 Harness 已找到 bundle，下一步应检查插件自己的运行时要求。

然后运行插件要支持的最小真实工作流：记忆插件可以存储并读取一条笔记，工具插件可以用无害输入调用一次，Provider 适配器可以发起短请求。记录结果、延迟和权限提示，升级时就有可比较的基线。

在启动日志中查找插件名称。如果显示 [ACTIVE]，说明插件已加载并运行。

常见问题

大多数安装失败都落在三个边界：包不是有效 bundle、包安装到了另一个 profile，或者缺少构建/运行时权限。先按这个顺序检查，再去修改其他 agent 设置。

排错时保留准确的启动错误。一段简短的终端消息比“插件不见了”更有用，也能让包维护者在不接触你的 profile 的情况下复现路径。

• 插件没有加载？ — 检查 package.json 是否包含有效的 dsh.bundle 字段，再检查清单声明的入口。包可以成功下载，但 bundle 契约不完整时仍会被跳过。
• 构建脚本被阻止？ — 只有在检查过包脚本和源代码后，才对可信包使用 --allow-builds。插件不需要原生依赖时，优先选择不扩大构建权限的安装方式。
• profile 不匹配？ — 确认安装插件和启动 DSH 使用的是同一个 profile。逐字比较两条命令中的 profile 值，并移除错误 profile 中的包，避免后续测试产生歧义。

下一步

插件通过一次真实工作流后，记录 profile、包来源、版本或 commit、权限和验证结果。这个简短记录能把一次性实验变成可复用配置，也能在包升级时提供回滚基线。

如果你还在判断某个能力是否属于运行时，请阅读介绍 DeepSeek Harness 插件的指南。如果变化主要是流程或共享外部服务，再比较 Plugins、Skills 与 MCP，然后决定是否安装新包。

目录可以按分类发现候选包，并查看 bundle、许可证和维护状态等信号。把这些信号当作起点，继续阅读仓库，并用足以证明工作流、但尽量不包含敏感数据的输入完成验证。