dsh plugins 和 dsh plugin 有什么区别：DeepSeek Harness 四种搜索意图与对应入口

dsh plugins 和 dsh plugin 的区别不在语法，而在你搜它的时候想干什么：找插件、装插件、查命令、看源码。四个意图对应四个入口，走错入口就会出现「搜到了但装不上」「装上了但找不到」这类问题。

先看搜索结果：四个词各指向什么

把四个高频写法放在一起看，差异一目了然。 这不是搜索引擎的随意分配，而是页面标题、仓库命名与命令文档共同造成的。

带 s 的词更像「逛」，不带 s 的词更像「做」。 你在搜 dsh plugins 时，多半还没决定装哪个；搜 dsh plugin 时，多半已经有一个具体动作要完成。理解这一点，后面的入口选择就不会乱。

带横杠的词是标识符，不是自然语言。 dsh-plugin 出现在包名、仓库名、topic 里，它的作用是唯一标识，不是描述。拿它去搜文章，结果反而更杂。

意图一：找插件——先进市场，再出站搜

找插件的首选入口是 DSH Plugin Hub，不是搜索引擎。 位置在「设置 → 插件市场」，它把分类、搜索、来源、兼容版本放在同一张卡片上（来源）。

1. 打开「设置 → 插件市场」，先用分类缩小范围：记忆、浏览器、界面、模型、工具。
2. 在分类里用中文名、英文名或包名搜索；三种写法命中率不同，中文名适合概念，包名适合精确查找。
3. 看卡片的来源、版本、更新时间与验证状态，确认不是同名但不同作者的条目。
4. 点进详情，复制安装命令或直接一键安装。

站外搜索适合「发现」，不适合「确认」。 搜 dsh plugins 能看到博客、合集与 GitHub topic，但这些页面往往没有兼容版本与验证状态。发现之后回 Hub 或仓库核对，才是完整路径。

中文词适合入门，英文词适合精确查找。 搜「dsh 插件」容易找到解释型文章，搜 dsh-plugin 容易找到仓库与包页。知道自己在哪个阶段，就不会拿入门文章当安装依据。

意图二：装插件——认命令，不认文章

装插件的唯一可靠入口是 dsh plugin 命令族。 文章里的按钮、复制命令、一键安装，最终都要落到这条命令上（来源）。

1. 先确认目标 profile：dsh plugin --profile web list 能列出列表，说明这个 profile 可用。
2. 用 dsh plugin --profile web add <包名或地址> 安装；包名来自 npm，地址可以是 github:用户名/仓库名。
3. 安装完成后重启，让插件在启动阶段完成注册。
4. 再用 list 与 dsh --dump-config 验证，确认包在列表里、配置树里有对应段。

不写 --profile 是最常见的错误。 命令会落到默认 profile，而你在另一个环境里找入口，于是得出「装了但没生效」的结论。先确认 profile，再执行安装，能省掉一半排查。

命令词与插件名长得像，但用法不同。 dsh plugin add 是动作，dsh-plugin-xxx 是标识。看到一篇文章把两者混着写时，以命令行为准：能直接粘贴执行的那一行，才是安装入口。

意图三：查命令——用帮助，不用猜

查命令不要靠搜索文章，直接问 CLI。 版本差异会让旧文章里的参数失效，--help 永远对应当前安装的版本。

1. 执行 dsh plugin --help，看当前版本支持哪些子命令。
2. 执行 dsh plugin add --help，看安装参数与 profile 选项。
3. 把帮助里的示例复制到终端，先在一个不重要的 profile 里试。
4. 记下当前版本号，方便以后对照文章里的写法是否过时。

帮助信息比文章更短，但更准。 文章会省略版本前提，帮助不会。遇到「文章说可以，实际报未知参数」时，先回帮助确认，再判断是版本差异还是文章过时。

把常用命令写成自己的速查表。 安装、列表、移除、更新四条就够日常使用；写下来，比每次搜索快，也不会被不同文章的写法带偏。

意图四：看源码——去 GitHub 与 npm，不去市场

看源码的入口是仓库，不是市场。 市场展示的是元数据，仓库才有实现、提交记录与 issue（来源）。

1. 从 Hub 详情页找到来源标注，确认 owner 与仓库名。
2. 打开仓库，先看 README 的安装段与兼容版本，再看 package.json 的 engines 与依赖。
3. 需要追问题时看 issue 与提交记录，确认问题是否已修、修在哪个版本。
4. 要装未发布版本时，用 github:用户名/仓库名 引用，而不是 npm 包名。

同名仓库很常见，owner 才是唯一标识。 dsh-memory、dsh-browser 这类通用名字在社区里可能有多个实现。只看名字会装错，核对 owner 与包名才不会。

npm 页适合确认版本，GitHub 页适合确认实现。 两边信息不一致时，以仓库的 package.json 与 release 为准；npm 上的 latest 标签有时落后于仓库。

三个走错入口的卡点

绝大多数「搜到了但没用」都能归到三个卡点。 每个卡点都有一个明确的判断动作，不需要重装。

1. 装到了错误的 profile。 你按文章的命令装进 web，却在桌面端找入口。判断方法：在两个 profile 下分别执行 list，看包落在哪个里。
2. 把显示名当成包名。 市场里的显示名可以重复，包名与 owner 不能。判断方法：对比详情页的来源与安装命令，命令里的标识才是唯一凭据。
3. 把索引当成实时。 新仓库从提交到被 Hub 收录有时间差，搜不到不代表不存在。判断方法：先在 GitHub topic 或 npm 搜包名，再回 Hub 看是否已收录。

三个卡点的共同点是「入口与目标不匹配」。 找插件用了命令入口，装插件用了文章入口，看源码用了市场入口——动作没错，入口错了。先确认意图，再选入口，问题会少很多。

一张意图-入口对照表

把四个意图压成一张表，贴在需要的时候看一眼。

入口选对，后面的动作才有意义。 同一个词在不同阶段指不同入口，这不是矛盾，而是搜索意图的正常分层。

下一步

先确定意图，再打开对应入口。 想找插件，直接去 DSH Plugin Hub；想装插件，看《DSH plugin 怎么安装》；想弄清插件与插件包的区别，看《dsh plugins 到底指什么》。

来源：dsh CLI README、DeepSeek Harness 官方文档 - 第一个插件、GitHub topic: dsh-plugin、DSH Plugin Hub 插件页