搜索到一个名字合适的插件，最容易做的事是马上安装。更值得先花几分钟检查的是：它针对哪个 Harness 版本，提供哪种能力，你准备怎样证明它生效。
本文的 Harness 基线是 0.2.0-rc.2，社区包信息核对日期为 2026-10-15。本轮核对了包声明，未把第三方插件在新版上的运行效果写成已通过。先按profile 篇准备独立试验方案，不直接改日常使用的 profile。
先看一个容易装错版本的例子
dsh-find-plugin 可以提供查找插件的工具。它当时在旧 Harness 中有过运行记录，但这不能保证新版兼容。
本轮查看 [email protected] 时发现：它有 dsh.bundle.patch，同时 @deepseek-ai/dsh-tools 的 peer 范围是一组 0.1.x 范围，没有声明支持 0.2.0-rc.2。
所以正确结论是：它能被识别为 bundle，但不能仅凭这点推荐给本系列的新版环境。缺少兼容声明并不等于已经证明它运行失败，也不等于可以忽略这个缺口直接宣称兼容。
不安装，也能先排除不合适的包
在练习项目目录运行：
npm view [email protected] \
version dsh peerDependencies dependencies scripts --json
依次看下面几项：
| 信息 | 作用与边界 |
|---|---|
dsh.bundle.patch |
声明 bundle 配置入口，不代表完整功能可用 |
peerDependencies |
插件声明依赖的宿主接口范围，需与实际安装版本逐项核对 |
dsh.client.platform |
是否带 Web 客户端部分，决定该在哪里观察效果 |
dependencies 与 scripts |
带入哪些依赖、构建和安装过程可能做什么 |
| 仓库与版本记录 | 能否找到兼容性说明、实际代码和已知限制 |
不要只看“零依赖”。peer 依赖同样构成运行契约，bundle、宿主服务和浏览器 UI 的接口都可能随版本变化。
一个声明覆盖新版的候选，也仍需试验
例如，核对日的 [email protected] 声明了 @deepseek-ai/dsh-tools 的 ^0.2.0-rc.2 peer 范围，并带 Web 客户端部分。它比只有旧版 peer 范围的包更适合作为当前版本的候选，但声明匹配只是进入试验的条件。
先从 Web 模板建专用 profile：
npx --no-install dsh --profile plugin-lab \
--from-default-profile web --dump-config > plugin-lab-before.yml
如果检查代码和依赖后决定试用，再执行以下安装与启动步骤。这是待验证的第三方示例流程，不是本轮已经跑通的 UI 效果：
npx --no-install dsh plugin --profile plugin-lab add [email protected]
npx --no-install dsh --profile plugin-lab --dump-config > plugin-lab-after.yml
diff -u plugin-lab-before.yml plugin-lab-after.yml
npx --no-install dsh --profile plugin-lab --no-open --port 3101
使用带认证信息的启动 URL 访问页面，检查对应 UI 能力、浏览器错误和启动日志。带 Web UI 的插件，不该用一条 headless 回答来判断是否生效。如果它的能力与新版内置界面重复，也要判断是否有必要保留。
给安装结果分三个层次
包已安装：依赖清单和实际版本正确，安装过程没有被忽略的兼容性或构建错误。
插件已加载：组合配置包含它贡献的层和条目，目标 profile 启动时没有相关异常；Web 插件还要检查客户端部分是否出现。
目标行为出现：实际执行一次它应当改善的操作。工具型插件检查真实工具调用与参数；UI 插件检查操作前后状态。一个包名出现在回复中，不能证明发生过工具调用。
这三个层次应分别记录。dsh-find-plugin 在旧版日志里使用的工具名是 find_dsh_plugin，条目 ID 又不同于包名；新版插件仍应从当前配置和实际事件获取名字，不能把旧名字当通用规则。
卸载也要验证
结束候选插件的试验：
npx --no-install dsh plugin --profile plugin-lab remove dsh-plugin-mgr
npx --no-install dsh --profile plugin-lab --dump-config > plugin-lab-removed.yml
检查依赖和运行层是否退出，重启该 profile 后确认相应能力不再加载。如果插件曾写入额外状态，卸载包是否清理这些状态，需要按插件自己的实现核对，不从一次 remove 成功推断“所有痕迹都清空”。
真正值得保留的插件，应当有一个可描述的收益和一个可重复的验证任务。完成这两点，比插件列表有多长更重要。已有能力只需要调参数时，优先用配置覆盖层。