DeepSeek Harness 插件市场有多少插件:官方、社区与 Hub 三个口径的统计差异

概念与架构发布于 2026-11-01作者: DeepSeek Plugin 插件市场
DeepSeek Harness插件市场插件数量同名插件插件索引
DeepSeek Harness 插件数量没有唯一答案:仓库条目、去重插件名与 Hub 收录是三个不同口径。本文用站内插件索引的实测数据说明 19,783 与 16,079 的差距从哪来,并给出同名插件、分类分布与选型判断。

DeepSeek Harness 插件没有唯一总数。 按仓库条目算是一个数,按去重插件名算是另一个数,按 Hub 可搜索条目算又是第三个数。三个数都对,只是回答的问题不同。

先给三个数字:19,783、16,079 与一个区间

截至 2026-11-01,站内插件索引里有 19,783 个插件仓库条目,去重后是 16,079 个插件名。 这两个数字来自同一份索引快照,差别只在「按仓库算」还是「按名字算」。

口径数字回答的问题
仓库条目19,783有多少个可追溯的来源
去重插件名16,079有多少种不同名字的插件
同名插件名1,705有多少个名字被多个作者使用
多余条目3,704同名带来的重复供给
Hub 可搜索条目以站点当日为准有多少个能被市场检索到

19,783 与 16,079 的差距,全部来自同名。 1,705 个插件名对应了两个及以上仓库,多出来的 3,704 个条目就是「同名不同源」。这个差距不是数据错误,而是社区生态的真实形态。

Hub 的数字不能直接用前两个推。 Hub 有自己的收录与索引规则,仓库存在不等于市场能搜到。想知道市场里有多少,以当日市场搜索结果为准;想评估生态规模,用前两个数字更稳。

为什么同一个名字会有几十个仓库

同名不是偶发,而是插件命名缺少全局唯一约束的结果。 插件名由作者自取,dsh-memory、dsh-session-delete 这类通用名字天然会被多人使用。

站内索引里同名最多的一批:

插件名仓库数典型原因
dsh-session-delete51需求通用、实现简单,大量作者各自发布
dsh-memory47记忆是高频需求,方案差异大
dsh-notify40通知渠道多,作者按渠道各写一版
dsh-balance33余额查询接口相似,重复实现多
dsh-skill-manager28技能管理是常见增强点
dsh-mcp-manager27MCP 配置管理需求集中
dsh-token-usage26用量统计口径不同,各写各的
dsh-plugin-manager25插件管理本身也是插件
dsh-prompt-optimizer24提示词优化门槛低
dsh-computer-use23系统操作类需求集中

同名越多,越不能靠名字选;同名也意味着维护质量差异极大。 这十个名字加起来就有 300 多个仓库。只搜名字,等于把选择权交给排序;有的仓库是完整实现,有的只是实验或 fork。判断方法很朴素:看 owner、最近一次提交、README 是否写了安装与兼容版本、issue 是否有回复。

分类分布:供给集中在哪

把 19,783 个条目按分类拆开,能看到社区供给的重心。 分类来自插件索引的目录结构,同一个分类下的插件解决相似问题。

分类仓库条目说明
tools7,895工具增强,数量最多
interface2,620界面、侧边栏、主题
model2,037模型接入与路由
dev1,616开发辅助
session1,494会话管理
integration1,088IM、外部服务集成
agent872智能体与团队
knowledge631知识库与检索
fun534桌宠、娱乐
workflow533工作流
memory462记忆
self-owned1单列分类

工具类占了近四成,说明「给 agent 加能力」是最主要的扩展动机。 界面类与模型类紧随其后,前者改交互,后者改模型来源。记忆与工作流数量不大,但需求明确,属于「少而专」。

分类数量不等于可用数量。 tools 里同名重复最多,去重后差距会缩小;memory 数量少,但同名密度高,选型反而更费劲。看分类时要同时看条目数与同名数,才接近真实供给。

三个口径为什么会持续分叉

三个数字不是一次性的差异,而是会随着生态变化继续分叉。 原因有三个,且都不可逆。

  1. 仓库会继续增加。 新作者发布新插件,条目数上涨;同名插件也会随需求增加,去重后的名字数涨得更慢。
  2. 收录有滞后。 仓库创建到进入 Hub 索引需要时间,新插件在市场上的可见性晚于仓库存在。
  3. 归档与删除不彻底。 仓库归档后条目可能仍在索引里,去重数字不会立刻下降,造成「看起来还在,实际不维护」的错觉。

所以不要用单一数字做判断。 评估生态规模看仓库条目,评估选择空间看去重名字,评估当下可安装看市场搜索结果。三个数一起看,才不会把「供给多」误读成「好用的多」。

这个数字对选插件有什么用

总数不能帮你选插件,但同名密度、分类分布与更新时间可以。 把这三个维度用起来,比记住总数有用得多。

  1. 先看同名密度。 一个名字有几十个仓库,说明重复供给多、差异大,必须看 owner 与实现;只有一两个仓库的名字,反而更容易判断。
  2. 再看分类重心。 你要的能力如果在 tools 里,候选多但同质化严重;在 memory 或 workflow 里,候选少但需要仔细比较。
  3. 最后看更新时间。 最近提交在三个月内的仓库,兼容当前版本的概率更高;长期不更新的,先假设它需要改。
  4. 用市场做交叉验证。 仓库里有、市场搜不到,可能是收录滞后;市场里有、仓库打不开,可能是来源失效。

数字的用途是缩小范围,不是下结论。 19,783 说明生态很大,16,079 说明名字层面仍有大量重复,1,705 个同名名说明选型时必须核对来源。剩下的判断,还是要回到具体插件。

统计方法:这三个数怎么复算

三个数字都可以从插件索引复算,方法不复杂。 写出来是为了让结论可验证,而不是让你记住某一天的快照。

  1. 取插件索引里所有带 plugin-meta.json 的目录,一个目录算一个仓库条目。
  2. 按目录最后一段(插件 slug)分组,组数就是去重插件名数。
  3. 统计每组里的 owner 数量,大于 1 的组就是同名插件名;把每组数量减一后求和,就是多余条目数。
  4. 按一级目录分组,得到分类分布;注意扁平目录与三层目录要一起统计,否则会漏掉一部分。

快照会过期,方法不会。 下次复算时,把日期换成当天即可;如果数字变化很大,先检查索引是否换了目录结构,而不是急着下结论。

下一步

把「有多少」换成「选哪个」。 想看市场里实际能搜到什么,去 DSH Plugin Hub;想弄清同名插件怎么区分,看《dsh plugins 和 dsh plugin 有什么区别》;想按场景挑第一批插件,看《deepseek harness plugins 从哪装》。

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

常见问题

DeepSeek Harness 插件市场到底有多少个插件,为什么每个地方说的数字不一样?

DeepSeek Harness 插件市场的数字对不上,是因为统计口径不同:按仓库条目算、按去重后的插件名算、按 Hub 可搜索条目算,会得到三个数字。仓库条目包含同名不同作者的项目,去重后才是插件名数量,Hub 还要经过收录与索引。

为什么同一个 DSH plugin 名会对应几十个仓库,到底应该装哪一个?

同名不代表同源,DSH plugin 里一个 slug 对应几十个仓库很常见。以 dsh-session-delete 为例,站内索引里有 51 个仓库共用这个名字;选择时看 owner、仓库地址、最近提交时间与兼容版本,不要只看显示名。

DeepSeek Harness 插件数量最多的分类是哪几个,这个分布能说明什么?

按站内索引,DeepSeek Harness 插件里工具类、界面类与模型类排前三,分别有数千个仓库条目。这说明社区供给集中在工具增强、界面改造与模型接入,记忆、工作流等分类相对小而专。

DeepSeek Harness 插件总数会一直涨吗,这个数字对选插件到底有什么用?

DeepSeek Harness 插件总数会持续增长,但总数本身对选型帮助有限。更有用的是同名密度、分类分布与最近更新时间:同名越多说明重复越多,更新越近说明维护越活跃。

相关术语

插件仓库条目
插件仓库条目指插件索引里按 owner 与仓库名记录的一行,同一个插件名可以由多个作者各提交一个仓库,因此条目数大于插件名数。— 站内插件索引(2026-11-01 快照)
去重插件名
去重插件名是把仓库条目按 slug 合并后的数量,用于衡量有多少种不同名字的插件,而不是有多少个可安装来源。— 站内插件索引(2026-11-01 快照)
收录口径
收录口径指插件市场决定哪些仓库可以出现在搜索结果里的规则,通常包含来源可访问、元数据完整与人工或自动验证等条件。— dshplugin/dsh-plugin-hub
同名插件
同名插件指不同作者使用同一个 slug 发布的插件,它们的包名、实现与兼容版本可能完全不同,只能通过 owner 与仓库地址区分。— GitHub topic: dsh-plugin

来源