2026 年如何寻找 DeepSeek Harness 插件

DeepSeek Harness（dsh）没有官方插件市场或注册表。唯一被官方认可的发现机制，是一个官方建议插件作者给仓库打上的 GitHub 话题（topic）：dsh-plugin。除此之外——awesome 列表、应用内"插件市场"插件、包括本站在内的精选目录——全都是社区在这一个嘈杂信号之上搭建出来的基础设施。

在你去找插件之前，先搞清楚这个空白很重要，因为它决定了你该如何评估找到的东西。下面讲清楚实际存在哪些渠道、每种渠道的工作方式，以及那条能判断一个仓库到底是不是真实 dsh 插件的关键检查。

为什么没有官方市场

dsh 的 README 只是要求插件作者给自己的仓库加上 dsh-plugin 话题标签"以便被发现"——这就是官方发现机制的全部内容。没有 marketplace.json，没有注册表 API，也没有 deepseek-ai 官方维护的精选列表。在代码库里搜索"marketplace"或"registry"，只能找到 Cordis 框架内部的概念（插件加载器的依赖图）以及 dsh 子代理桥接里用到的一个 Claude Code 环境变量——跟插件商店毫无关系。

这是一个仍处于开发预览期的项目有意为之的取舍，但这也意味着任何人都可以搭一个"市场"并自称权威。事实上已经有好几个人这么做了。

GitHub 话题：覆盖面广、噪声大、无过滤

https://github.com/topics/dsh-plugin

截至 2026 年 8 月，这个话题标签下有数千个仓库。这是你能撒下的最大的网，但它完全是自我申报的——一个仓库出现在这里，只是因为作者加了标签，而不是因为有人验证过它是一个能用的插件。很多结果是 fork、模板、废弃的实验项目，或者只是提了一句"兼容 dsh"却根本没交付一个可用 bundle 的项目。

话题页适合用来浏览有什么新东西，但它本身不构成信任信号。

唯一权威的检查：package.json 里的 dsh 字段

判断一个 GitHub 仓库是不是真实的、可安装的 dsh 插件，只有一个可靠方法：打开它的 package.json，看有没有 dsh 字段。

{
  "name": "dsh-hello-plugin",
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }
}

声明了 dsh.bundle 的包是一个bundle——安装时它会给你的配置打补丁。声明了 dsh.profile 的包是一份完整的profile定义。一个打了 dsh-plugin 话题标签、但 package.json 里没有 dsh 字段的仓库，dsh plugin add 并不会把它当成插件对待——pnpm 依然会乐意把它当普通依赖装进去，但 dsh 不会激活它的任何配置，还会打印一条警告。这正是一份精选目录在把一个仓库从话题搜索的噪声里筛出来、收录为真实插件之前所做的检查。

如果你在装之前要评估一个插件，这就是第一步——完整流程见我们的插件安全清单。

社区 awesome 列表

目前最有用的精选资源是社区维护的 awesome-dsh-plugin/awesome-dsh-plugin 仓库——一份人工审核过的 README，把插件分到 UI 增强、主题、记忆、工具与能力、技能、工作流与自动化、通知、模型与提供商、开发与运行时、纯玩乐等分类下。它是一个第三方、社区运营的项目，不是 DeepSeek 官方资产，但人工审核让它比原始话题搜索干净得多。

其他社区 awesome 列表也存在,各自用着不同、互不兼容的分类体系——它们之间没有统一标准可以趋同,因为压根没有官方标准。把任何一份 awesome 列表当作调研的起点,而不是认证。

应用内"插件市场"插件

值得单独说一类插件：它们的全部作用就是在 dsh Web UI 内部加一个可浏览的插件商店。dsh-market 在 Settings 里加了一个页面,用来浏览、搜索社区目录并一键安装;dsh-webui-market-plugin 做了类似的事,把 awesome-dsh-plugin 目录呈现在 GUI 里;dsh-find-plugin 则换了个思路,直接给 agent 本身一个工具,让它按关键词或分类去搜索一份精选注册表,你只需要在对话里描述需求就行。

这些插件确实方便,但要保持清醒:它们本身就是普通的 dsh 插件,和其他任何插件一样被安装、执行,它们的"一键安装"便利性并不附带对市场里那些插件的任何额外审查。装一个市场插件,不会让市场里的那些插件变得更安全。

直接搜索 npm

因为 dsh plugin add 本质上是 pnpm add 的一层薄封装,npm 本身就是一个合法的发现渠道,而不只是分发渠道。发布了构建产物(而不是只把源码推到 GitHub)的作者,通常会给自己的包打上 dsh-plugin 关键词,你可以直接用 registry 的公开搜索 API 查询:

curl "https://registry.npmjs.org/-/v1/search?text=keywords:dsh-plugin"

这里同样适用和 GitHub 话题一样的提醒:这个关键词也是自我申报的。一个包可以带着 dsh-plugin 关键词、却在 package.json 里没有声明 dsh 字段——关键词只是让它出现在搜索结果里,真正让 dsh plugin add 把它识别为插件(而非普通依赖)的是那个字段。如果一个包两者都有,通常是最顺畅的安装路径,因为发布到 npm 的插件自带构建产物,可以跳过我们在 GitHub 安装指南里讲到的 allowBuilds 提示。

各发现渠道对比

渠道	覆盖面	是否精选	信任信号
GitHub 话题 dsh-plugin	最广(数千个打标仓库)	无——自我申报	无;需自行核实 dsh 字段
社区 awesome 列表	中等(数百个)	人工审核,第三方维护	比原始话题搜索好,但仍非官方
应用内市场插件	因市场而异	通常镜像某个 awesome 列表或话题搜索	取决于它拉取的那份列表
FindHarness	收录 800+,精选自 awesome 列表加 npm/话题发现	收录前核实 dsh 字段	仅是目录,不是安全审计

FindHarness 自己的做法

本站从两个层级索引插件:一部分是从社区 awesome 列表中精选而来,另一部分来自更广的发现流程——从 npm 关键词搜索和 GitHub 话题里拉取,再筛选出 package.json 里确实声明了 dsh 字段的仓库。可以浏览完整目录,也可以直接进入某个分类——比如工具与能力(Tools & Capabilities),或者开发与运行时,本系列里提到的大多数诊断类和插件管理类工具都在这个分类下。

被本站收录,意味着这个插件通过了 dsh 字段检查、背后有一个真实的 GitHub 仓库——但这不是一次安全审查。在安装任何你没有亲自检查过的插件之前,先读一遍插件安全清单。

FAQ

有没有官方的 DeepSeek Harness 插件商店？

没有。唯一的官方发现机制是 GitHub 的 dsh-plugin 话题。任何被称为"市场"或"插件商店"的东西——包括应用内的市场插件——都是第三方、社区搭建的项目。

我怎么知道一个 GitHub 仓库是不是真的能用的 dsh 插件？

打开它的 package.json,看有没有带 bundle 或 profile 子字段的 dsh 字段。这正是 dsh plugin add 自己用来判断要不要激活配置补丁的字段。没有 dsh 字段,顶多也就是当成普通依赖装进去,不会被当作插件。

该信哪份 awesome 列表？

没有一份是官方的,而且它们各用一套互不兼容的分类体系。把任何一份 awesome 列表当作调研的起点,然后自己核实 dsh 字段、亲自看源码,再决定要不要安装。

应用内插件市场插件比直接安装更安全吗？

不会。它们只是普通插件,在你手动也能找到的、同样来自 GitHub 或 npm 的包之上,加了一层浏览界面。一键安装的便利性并不等于安全保证。

npm 关键词搜索也能找到真实插件吗？

可以——在 npm 上搜索 dsh-plugin 关键词能找到已发布的包,和 GitHub 一样,真正确认它可安装的是 package.json 里的 dsh 字段,而不是关键词标签本身。

下一步

找到一个想试试的插件之后,读一遍如何安装 DeepSeek Harness 插件了解精确的 dsh plugin add 语法;如果插件没有发布到 npm,可以深入看看专门讲 GitHub 安装的这篇。在你对任何未经自己审查的插件运行安装命令之前,先过一遍插件安全清单。