前言¶

DeepSeek Harness（下文称 dsh）把「一切皆插件」写进架构：界面、工具、技能都可以从外部装进来。官方仓库 deepseek-ai/deepseek-harness 也建议插件作者给仓库打上 GitHub topic dsh-plugin，方便被发现。问题是 topic 下面的仓库会越来越多，个人账号和组织之间还会转移，靠人工翻搜索结果、或者只盯某一个组织，很容易漏掉能用的插件，也分不清该按 bundle、Cordis 插件还是 skill 来装。

更麻烦的是安装本身。插件跑在当前 dsh 进程里，装进去等于把会话、工具和本机命令权限交给它。社区目录站点 deepseek-harness-plugin.com 是独立收录站，和 DeepSeek / 幻方没有官方从属关系，页面上的安装命令也不能替代自己看源码。

Nagi-ovo 维护的 dsh-find-plugins 就是冲着这件事来的：在智能体对话里用自然语言描述需求，它去全 GitHub 的 dsh-plugin topic 里找候选、解释差别，等你选好以后先做一轮权限汇报，再安装并验证是否挂载成功。本文按目录详情页、GitHub 仓库 README、skills/find-plugins/SKILL.md 以及官方 deepseek-harness 仓库交叉核对后整理。

这是什么¶

dsh-find-plugins 是一款技能插件，仓库托管在 Nagi-ovo/dsh-find-plugins，维护者是 Nagi-ovo，许可证为 BSD-3-Clause。社区目录把它归在「技能」分类。截至 2026-08-17，GitHub 与目录页上的星标均为 130。仓库主要语言是 JavaScript，创建于 2026-08-13，目录收录日期为 2026-08-15。

它解决的不是「写一个新插件」，而是这几件事：

• 按自然语言需求，从全 GitHub 的 dsh-plugin topic 找出公开候选
• 对照 README、package.json 和仓库文件，判断该按 bundle、Cordis 插件还是 skill 安装
• 用户选定之后、动手之前，先汇报这个插件要什么权限
• 安装完成后验证是否挂载成功

Skill 入口文件是 skills/find-plugins/SKILL.md，技能名是 find-plugins。SKILL.md 写得很明确：只负责找和装；要开发新插件，应转去 make-dsh-plugin。

核心功能¶

把 topic 当目录，不把某个组织当目录¶

Skill 把 GitHub 的 dsh-plugin topic 当作插件身份，不把某个 owner 或组织当作目录。仓库属于个人还是组织并不重要：只要是公开仓库并带有这个 topic，转移之后仍然能被发现。搜索结果以当前的 fullName 和 url 为准，不根据旧 owner 猜地址。

检索脚本是仓库自带的 skills/find-plugins/scripts/search-topic.mjs。它调用 GitHub Search API，查询条件是 topic:dsh-plugin is:public archived:false，再过滤掉 fork、已归档和已禁用的仓库。脚本会处理分页（每页 100 条，最多 10 页），并按 fullName 去重。认证方面依次复用 GITHUB_TOKEN / GH_TOKEN、本机 gh 登录令牌以提高限额；都没有时使用公开 API。限流时需要先 gh auth login 再重试，而不是退回某个组织的仓库列表。

README 还提到：如果当前账号能读取 dsh-external/hub 的 catalog.json，可以把其中的分类、安装说明当作补充信息。Hub 不是主目录，GitHub topic 才是。Hub 缺失、私有、或仍指向转移前地址，都不能覆盖仓库当前声明。

先筛少量候选，再判断装法¶

Skill 不会把 topic 下的仓库全部打开。它先用用户需求对照仓库的 name、description、topics，优先看最近有推送的命中项，只对语义最匹配的少量仓库读取 README、package.json 和文件树，然后按仓库当前声明判断安装类型：

• package.json 声明了 dsh.bundle.patch：按 bundle 安装
• 含一个或多个 SKILL.md，且没有 bundle 声明：按 skill 安装
• README 明确要求写入 cordis.patch.yml，但没有 bundle 声明：按 cordis 安装
• 只有 .dsh-plugin / repository 旧格式：标成「需迁移」，不能直接安装
• 仍无法判断：标成「需核对」，不要编造安装命令

references/install-methods.md 还补充了优先级：多种方式并存时，bundle 优先于 cordis，再其次才是社区管理器 marisa / mygo。最新 DSH 已经移除 repository 这种旧格式；只有旧标记、没有 bundle 的插件，Skill 会停下来说明需要迁移，而不是写过期配置。marisa / mygo 由对应管理器接管，本 Skill 不代劳。

产出最多 3 行候选表：名字、一句话用途、最近更新、装法。表后用一句话说明首选理由。一条都不匹配时，会直说 topic 目录里没有，并问是否转去写一个新插件。

仓库 README 给了两个对照例子（并写明「检索命中纯属巧合」）：「想把数据和流程画出来」可以找到 dsh-visualize；「想给 Web UI 加点 2005 年互联网味道」可能会找到 dsh-ads。

装之前先汇报权限，有没有问题都要说¶

用户点头之后、动手之前，Skill 会先看一遍这个插件装进来会拿到什么。SKILL.md 把这一步写成不能跳过：插件运行在用户的 DSH 进程里，能读会话、调工具、跑命令，装它等于授权。

至少看这四处：

1. package.json 的 lifecycle scripts：preinstall、install、postinstall、prepare 在 Git / npm 安装时会执行
2. 对外动作：网络请求、子进程、写 $DSH_HOME 之外的路径、改 shell 配置或系统设置
3. 读取的会话数据和凭据：会话日志、settings、.env 或 credentials
4. 仓库本身的可信度：最近推送时间、star 数、作者是否还有其他 dsh 插件、README 与代码是否对得上

不管有没有发现问题，都要汇报，三到五行讲清：查了哪几处、这个插件实际要什么权限、有没有和它宣称的用途对不上的动作。有可疑项就把原文贴出来，不要转述。汇报完再问一次是否继续；用户说停就停在这里，不要顺手装完。

安装过程中如果冒出检查时没看到的动作（新的下载源、额外的写入路径、要求提权），同样停下来把原文交给用户。

装完还要验证挂载¶

安装完成后进入验证。web 等长驻界面会监听 patch 文件改动后热载；一次性运行则要下次启动才生效。Skill 会请用户确认相应 UI、工具或技能条目出现。没出现时依次排查：服务日志中的 hmr/config-update-failed、Git spec 是否仍用了转移前 owner、ref / path 拼写、profile 目录的 pnpm install 是否成功。

完成态只有一个：用户选中的插件在他的 DSH 里可用。

安装与启用¶

社区目录页给出的安装命令如下，在 DeepSeek Harness 终端中运行即可：

dsh plugin add github:Nagi-ovo/dsh-find-plugins

如需可复现安装，目录页建议固定 commit 哈希：

dsh plugin add github:Nagi-ovo/dsh-find-plugins#<commit>

把 <commit> 换成仓库里实际的提交哈希，不要留占位符。

仓库 README 还提供了技能目录的安装方式。可以把下面这句话发给 DSH：

请从 https://github.com/Nagi-ovo/dsh-find-plugins 安装 dsh-find-plugins skill

手动安装时，把 skills/find-plugins/ 整个目录复制到技能发现根。常用位置是：

• 全局：$DSH_HOME/skills/（默认 ~/.dsh/skills/）
• 只给当前项目：<项目根>/.dsh/skills/，或 <项目根>/.agents/skills/
• 和其他 Agent 共用：${DSH_AGENTS_HOME:-~/.agents}/skills/

目录有 watcher，放进去即可生效，不必重启。复制的是含 SKILL.md 的 find-plugins 目录，而不是仓库根目录里的 README 和图片。

目录页提醒：插件以当前 dsh 进程的权限运行，安装时可能执行代码。安装前请检查源代码仓库和许可证。

典型用法¶

SKILL.md 把触发条件写得很直白。用户想给 DeepSeek Harness 找插件时，可以直接说：

有没有插件能把数据和流程画出来？

帮我装个能给 Web UI 加点复古味道的插件

生态里有什么好玩的

也可以直接点名：

帮我装 dsh-visualize

用户已经点名某个插件时，Skill 会先核对当前仓库和装法，再进入权限汇报，而不是再搜一遍。

完整流程可以按这六步理解：

1. 取候选池：运行 search-topic.mjs，得到公开、未归档、非 fork 的 dsh-plugin 仓库列表
2. 筛选并确认装法：只打开最匹配的少量仓库，产出最多 3 行候选表
3. 用户拍板：停下来等选择
4. 安全检查并汇报：无论有没有问题都汇报一次，再问要不要继续
5. 安装：按确认出的类型打开 references/install-methods.md，照对应小节操作
6. 验证挂载：确认 UI、工具或技能条目已经出现

官方 deepseek-harness 仓库目前处于 developer preview，文档写明会有破坏性变更。Skill 里的安装命令也按「最新 DSH」来写，例如从源码 checkout 根目录用 pnpm dsh plugin --profile <profile> add ... 安装 bundle。具体命令以目标插件仓库当前声明为准，不要把旧的 .dsh-plugin 配置抄回去。

适用场景与注意事项¶

适合这几类情况：

• 已经在用 DeepSeek Harness，想按需求从社区 topic 里找现成插件，而不是只翻某一个组织
• 分不清目标仓库该按 bundle、Cordis 插件还是 skill 安装
• 安装前希望先看到权限汇报，而不是直接执行 plugin add
• 仓库刚从个人账号转到组织（或反过来），需要按当前 fullName 安装，避免用转移前的 Git spec

使用时注意下面几点。

第一，插件以当前 dsh 进程的权限运行。dsh-find-plugins 自己会帮你检查别人的插件，但它本身同样是装进 dsh 的技能，安装前应阅读仓库源码和 BSD-3-Clause 许可证。目录页也写了同一条：安装时可能执行代码。

第二，它只覆盖打了 dsh-plugin topic 的公开仓库。没打 topic、已归档、fork、私有仓库，都不会出现在候选池里。检索命中不等于推荐，README 里的例子也声明「纯属巧合」。

第三，GitHub API 有限额。没有 GITHUB_TOKEN / GH_TOKEN、也没有 gh 登录时，公开搜索仍能工作，但更容易被限流。限流后应先认证再重试。

第四，社区目录和 dsh-external/hub 都是补充信息源，不能覆盖仓库当前的安装声明。目录站点与 DeepSeek / 幻方没有官方从属关系，不要把它当成官方应用商店。

第五，本 Skill 不负责开发新插件，也不代劳 marisa / mygo 这类外部管理器。旧的 repository 格式已经从最新 DSH 移除，遇到只有旧标记的仓库，应视为需要迁移，而不是强行安装。

小结¶

dsh-find-plugins 把「在对话里找插件」落成一套可核对的流程：用 GitHub 的 dsh-plugin topic 当目录，筛少量候选、判断装法、先汇报权限再安装，最后验证挂载。对已经在用 DeepSeek Harness、又不想靠人工翻仓库的人来说，它把发现和安装收进同一次对话里，同时把「装插件等于授权」这件事写进了默认步骤。

目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-find-plugins/

GitHub：https://github.com/Nagi-ovo/dsh-find-plugins