插件生态普查 Chinesezjc/dsh-plugin-census

DSH Plugin Census

对 DeepSeek Harness 插件生态的可复现普查：dsh-plugin 话题里实际有些什么，以及其中哪些真的装得上。

免责声明。 本项目是个人维护的社区项目，不是 DeepSeek 官方产品，不代表 DeepSeek 的立场。被收录不构成推荐，未被收录也不是对质量的评判。
维护者向 DeepSeek Harness 上游提交贡献，但这不使本目录具有权威性。
所有判定都由本仓库的脚本产出且可复现——请核对它们，而不是相信它们。

为什么做这个

dsh-plugin 话题在 2026-08-18 有 6923 个仓库，四天前是 1064 个。GitHub 的话题页按 star 排序，而 star 最高的条目恰恰最不可能是插件。

话题是被完整枚举的，不是采样：14347 个唯一仓库，做法是围绕搜索 API 单次查询 1000 条的上限做分片。契约探测则跨运行累积，所以下表覆盖的是目前已探测的 17432 个仓库：

| Star | 符合插件契约的比例 |
| 0 | 84.9% |
| 1-2 | 83.0% |
| 3-9 | 83.5% |
| 10-49 | 82.8% |
| 50+ | 64.3% |
| 全部 | 83.3% |

只有最高那一档偏低，其构成解释了原因：带这个话题的高 star 仓库大多是这个话题本身的目录项目——awesome-dsh-plugin（6439）、 AdamPlatin123/awesome-dsh-plugins（1098）、 0xsline/awesome-deepseek-harness（649）——加上周边工具，例如 Tencent/BrowserSkill（1089）。它们都不是插件，也都没声称是，但都排在访问者真正要找的插件前面。

更早一次测量（2026-08-14，n=999）发现合格率随 star 单调下降，从 0 star 的 64.5% 降到 50+ 的 36.4%。该结论已不再成立，早先那组数字不应再被引用：生态在三天内增长到 5.7 倍，且本探针现在能在子包中找到 bundle，而早先那次找不到。

样本构成

全部 17432 个被探测仓库，按判定分类：

| 判定 | 数量 | 占比 |
| CONTRACT_OK | 14071 | 80.7% |
| NO_DSH_FIELD | 1367 | 7.8% |
| NO_PACKAGE_JSON | 1003 | 5.8% |
| DSH_WITHOUT_BUNDLE_PATCH | 811 | 4.7% |
| PATCH_FILE_EMPTY_OR_INVALID | 56 | 0.3% |
| VENDORED_HARNESS | 49 | 0.3% |
| TREE_UNREADABLE | 27 | 0.2% |
| MALFORMED_PACKAGE_JSON | 23 | 0.1% |
| PATCH_FILE_MISSING | 17 | 0.1% |
| BUNDLE_UNDETERMINED | 7 | 0.0% |
| FIRST_PARTY_HARNESS | 1 | 0.0% |

探测是累积的：每次运行把 API 配额先花在从未探测过的仓库上，然后是最陈旧的，所以这张表覆盖的是 14347 个已枚举仓库中不断增长的一部分，而不是每次重新采样。

VENDORED_HARNESS 标记的是携带了 harness 副本、而非插件的仓库：它之所以满足契约，是因为它内含 DSH 自己的 bundle 包。这 49 个的 fork 全部为 false，即源码复制而非 GitHub fork，所以按 owner 查或按 fork 状态查都发现不了它们；它们只能按第一方包名识别。其中最大的是 fufankeji/deepseek-harness-studio，260 star。

数据保鲜期

这些数字描述的是某一时刻的某一份样本，而这个时刻很短。全部 257 个被判为不合格的仓库在首次探测数小时后被重新探测：其中 2 个已变为合格，因为作者在这段间隔里加上了 dsh.bundle——songoao25/dsh-plugin-guardian 在 08:58、 xinyuehtx/dsh-plugin-hooks-ordering 在同日 07:54。这两处变化都不是探针修复带来的，是作者自己提交的。

请把这里的任何数字当作带时间戳的一次读数，而不是长期成立的事实。脚本已包含在仓库内，以便重新测量，而不是让人相信既有结果。

定时 workflow 直接印证了这一点：在上述数字写下数小时后的一次运行，在同样的单次查询上限下产出了 742 条而非 763 条目录。两次之间探针没有任何改动——只是这个话题「最近更新的那一页仓库」已经是另一批了。

「契约已验证」的含义

验证复刻的是 DSH 加载 bundle 时实际执行的检查，见 packages/boot/app-boot/src/profile.ts:388-397。共三级，每一级对应加载器会抛出的一个独立失败：

| 层级 | 检查 | 缺失时加载器的行为 |
| 1 DECLARED | package.json 中有 dsh.bundle.patch | 在 profile.ts:391-393 抛错 |
| 2 RESOLVED | 声明的路径存在 | 在 profile.ts:395 读取失败 |
| 3 PARSED | patch 文件含有 patch 条目 | 在 profile.ts:396 解析失败 |

只有达到 PARSED 的条目才被列为插件。

如实说明的局限： 第 2、3 级在实践中拦下的很少——3810 个声明了 patch 的仓库中只有 73 个在这两级失败。静态验证在第 1 级就基本到顶了，剩余的不确定性只能靠实际安装插件来消除。安装验证尚未实现；本仓库不声称任何插件能运行。

Surface 归因

每个已验证插件都被归因到它所扩展的 surface，证据按强度分级，且置信度一并公布：

| 置信度 | 依据 | 数量 | 占比 |
| high | 依赖 @deepseek-ai/dsh-client-（client 侧）或 @deepseek-ai/dsh-host- 及 host 专用包（host 侧） | 7891 | 56.1% |
| declared | 插件自己的 dsh.client 或 dsh.host 块声明了该 surface | 3810 | 27.1% |
| medium | 有 @deepseek-ai/ 依赖，但没有一个依赖能区分 client 与 host，surface 记为 indeterminate | 492 | 3.5% |
| low | 没有 @deepseek-ai/ 依赖，surface 由名称或描述中的关键词猜测 | 1218 | 8.7% |
| none | 既无依赖证据也无关键词命中——根本没有归因 | 660 | 4.7% |

high 与 medium 这 8383 行基于已安装的依赖。另有 3810 行为 declared：插件自己的 dsh 块声明了 surface——这是作者的声明而非已安装的包，所以排在依赖证据之下、猜测之上。

归因此前只读依赖，因而丢掉了这些声明，并用猜测取而代之。这些猜测里有 52% 把 surface 搞错了——283 个中有 147 个在读到声明后发生了改变，所以这是正确性缺陷，不只是标注问题。

low 是从仓库名里的一个词做出的猜测，并被如实标注。none 行的 surface 是 indeterminate、证据为空：它是归因的缺失，不是弱归因，不应被读成对该插件的任何判断。

剩下的猜测已经接近这套方法能判定的下限。 仍然是 low/none 的那些条目只有 dsh.bundle 块，而且通常连依赖都没有，清单里已经没有可读的东西了。用 bundle patch 文件里声明的 seam 来归因这条路已经测过并被否决：在 30 个 surface 已知的插件里，23 个根本没有 inject 块、只有 1 个给出了 seam，所以这条规则无法用任何数据校准。要解决这些条目需要本普查不收集的证据——实际安装该插件，或读它的源码。

可安装性

符合契约说明插件声明了合法的 patch，但不说明这个包能被获取。有两种失败模式无需安装即可判定：

| 判定 | 含义 | 数量 |
| published | 声明的包名可在 npm registry 解析 | 6501 |
| git-only | 不在 npm 上；只能用 Git specifier 安装 | 7384 |
| unpublishable-scope | 仓库不属于该组织，却用 @deepseek-ai/ 命名自己 | 184 |
| unknown | registry 没有给出结论——这不是对该包的判断 | 2 |

另有 49 个仓库原样携带 @deepseek-ai/dsh-base（样本外至少还有两个： my-dsh/oh-my-dsh 与 BenHuHuan/dhs-tuicode）。它们不是命名错误的插件，而是 harness 的源码副本，因此被归为 VENDORED_HARNESS 并从目录中排除，不计入上表。

被阻断的条目在目录中单独列出。它们满足 bundle 契约，但只有 DeepSeek 组织能向 @deepseek-ai scope 发布，所以这些名字无法由其当前所有者创建，
dsh plugin add @deepseek-ai/... 对它们全部失败。这是改名即可修复的命名缺陷，
不是对代码质量的评价。

该检查有意不标记 @deepseek-ai-community 这类形近 scope。那些是独立且可自由注册的 scope，其所有者可以正常发布，因此是可安装的——品牌混淆是另一个问题，本目录不对此做裁定。

成对比较排名（尚在收敛中）

排名问的是「两个插件里，有经验的 DSH 用户更信任哪个」。这个问题能区分一维分数区分不了的案例：FengYangXun123/dsh-opencode-usage（7 个文件）赢了 GongYuanCaiJi/dsh-claude-code-templates（5057 个文件），而且赢的是小的那个——后者 5057 个文件里有 5031 个在 skills/ 下、lib/ 只有 3 个，主要是在打包别人的东西。被规模带偏的一维绝对分把两者判为相等，成对比较没有。

评级用 Elo，只由真实发生过的比较驱动。不施加任何目标分布。 强行凑成正态意味着把几百个插件压到证据不支持的低分上，而这些判断写着别人仓库的名字。

这些评级还不构成排名。 目前 4676 个条目有评级，平均每个只比过 1.8 场（最多 41 场），跨度仅 1427 to 1708。Elo 大约需要 10-20 场才有意义，发布这些数字是为了展示机制正在累积，不是推荐。

分档边界落在评级值上而非条目数上，因此同一个评级不会被拆到两档，公布的区间也不重叠。
档位大小因此不均匀，而这种不均匀本身就是结论：4676 个已评级条目中有 2096 个只比过 1 场，评级只能落在少数几个离散值上，堆在区间两端。

| 分档 | 评级区间 | 条目数 | 平均场次 |
| 最高档 | 1508–1708 | 1841 | 1.8 |
| 次高档 | 1500–1507 | 693 | 1.9 |
| 次低档 | 1492–1498 | 1194 | 1.2 |
| 最低档 | 1427–1489 | 948 | 2.4 |

分布表逐值列出，因为某一档里若被单一数值主导，就看不出评级有多集中。条目数少于 10 的分数值合并成一行——比较次数最多的条目就在其中，因为反复比较会让评级离开「只打一场」所能产生的那几个值。

| 评级 | 条目数 | 平均场次 |
| 1516 | 715 | 2.0 |
| 1512 | 139 | 2.0 |
| 1508 | 946 | 1.1 |
| 1504 | 253 | 1.6 |
| 1501 | 12 | 2.0 |
| 1500 | 421 | 2.0 |
| 1496 | 223 | 1.5 |
| 1492 | 954 | 1.1 |
| 1489 | 12 | 2.7 |
| 1488 | 133 | 2.1 |
| 1487 | 46 | 2.0 |
| 1486 | 65 | 2.0 |
| 1485 | 88 | 2.2 |
| 1484 | 555 | 2.0 |
| 其他 75 个分数值 | 114 | 10.4 |

目录内所有条目都参与排名。 早先的版本只在部分条目之间比较，理由是「池太大无法收敛」——这个判断是错的，它来自一个有 bug 的模拟：同分时按数组下标配对，而下标同时又编码了真实实力，于是每轮第一次都让实力最接近的对打，比较几乎不携带信息。
把同分改成随机配对后，全目录排名在每个条目 10 场时达到 Spearman 0.87、20 场时 0.93。

发布分布而非排名列表，因为同一个模拟显示：整体分层的收敛远早于精确名次——在 rho=0.87 时，按评级取的前 15 名里只有 0-1 个属于真实前 15。发布排行榜会宣称这套方法并不具备的精度。

配对会优先复配已有比较的条目，让评级越过第一场继续深化——早先「优先配对比较次数最少的」策略会在整个目录上铺开而永远不深化：跑了两轮之后，每个有评级的条目都恰好只有 1 场，按此速度要到 10 场需要约 453 轮。现在每轮预算的一半用于复配 10 场以下的条目，另一半给新条目开张。复配预算的一部分用于连胜擂台：候选是比较次数最少的条目，同一场次内 rating 低的优先，再按 rating 排序依次挑战下一位更强的，胜者留在台上继续挑战更强者，因此持续取胜的插件能在一次运行里连爬数级，而不是赢一场相邻对手就停下。
场次优先是因为它代表不确定性：2026-09-13 时 rating 在 1492 及以下的 1255 个条目中，有 1195 个只打过 1-2 场，所以低 rating 通常意味着「尚未验证」。若改成纯粹按 rating 选，同一批弱插件会被永远钉在擂台上——每输一场它们的 rating 仍是最低，下一轮又被选中，最低的 25 个条目因此平均打了 9.6 场（全池平均 1.65）。同场次内 rating 低的排在前面，让最缺验证的低分条目先上。刷新把 100 次比较与枚举并行执行，两者花的是不同的 API 配额，所以只给整轮增加约 2% 时间，而不是额外的 13 分钟。另有一个只跑排名的 workflow 每两小时复跑一次评级、每次 200 次比较，在两次刷新之间继续收敛而不重新枚举话题。有些对始终得不出结果：某一对在 8 次相同尝试里只成功 2 次，因为模型的思考过程与答案争抢 token 预算。未解决的对只损失覆盖率，不损失正确性——没有任何评级被移动。

已发布的包声明了什么

契约验证读的是仓库里的 package.json。而用户执行 dsh plugin add 装的是已发布的 tarball。这是两个不同的产物，而它们并不一致。

在 6501 个能在 npm 上解析的包中：

| 状态 | 含义 | 数量 | 占比 |
| bundle-ok | 已发布的清单声明了 dsh.bundle | 5928 | 91.2% |
| bundle-missing | 已发布的清单没有 dsh.bundle——DSH 会拒绝把它作为 profile bundle 加载 | 338 | 5.2% |
| package-missing | 声明的包名已无法在 registry 上解析 | 63 | 1.0% |
| unreadable | registry 读取失败；这不是对该包的判断 | 172 | 2.6% |

其中 401 个（6.2%）按包名装不上，尽管它们的仓库满足契约。bobcat848/dsh-calculator 的仓库里有 dsh.bundle 和完整的 dsh.client 块，而已发布的 dsh-calculator@0.0.1 连 dsh 字段都没有； orriduck/dsh-tui 在 0.2.19 上同样如此。装上并注册为 profile bundle 会失败并报 declares no dsh.bundle in its package.json——已对 @deepseek-ai/dsh@0.1.0-rc.7 实测确认。

这是发布环节的缺口而不是仓库写错了——通常是构建过程重写了 package.json 却没有把 dsh 块带过去。目录选择报告它而不是删掉这些条目，因为仓库确实满足契约，修复权在作者手里。

失效扫描

scripts/scan-decay.mjs 会重新检查每个已收录条目，报告四种状态，只标记、从不删除：gone（404）、archived（已归档）、dormant（30 天内无 push）、 unbundled（契约已不成立）。无法得出结论的探测被报为 inconclusive，而绝不报为失效——因为每个失效状态都会促使他人删除条目，而证据可能并不支持。

全部 14071 个条目：

| 状态 | 数量 |
| live | 9242 |
| archived | 95 |
| gone | 224 |
| unbundled | 69 |
| dormant | 4437 |
| inconclusive | 4 |

dormant: 0 反映的是话题的年龄，不是它的健康度。 目录条目中最久的一次 push 距今 46 天，所以 30 天的休眠阈值根本还触发不了。这已经不再是过去那种采样偏差——枚举现在覆盖整个话题，而不是「最近更新的那一页」——但这个数字仍然说明不了长期维护情况，因为这个生态里还没有任何项目有时间沉寂下来。

inconclusive 有 4 个（0.0%），这是扫描本身的局限，不是对那些仓库的判定。
失效扫描与探针共用同一份每小时 API 配额，配额耗尽的那次运行会如实报告「没查成」而不是去猜。拒绝阈值是 40%，所以这次仍然发布了；读者应把失效表理解为「覆盖了实际能查到的那些条目」。

失效扫描与探针一样是增量的，原因相同：逐条重扫每次要为每个目录条目花掉 2 次 API 调用，且随目录增长——占到每小时配额的 85%，并让一次定时运行以 45.4% inconclusive 被直接拒绝。现在每次只检查一个有界批次（最旧的优先），其余沿用已存结果，所以本表中的某个状态可能来自比上面那些数字更早的一次运行。

被判定为失效的 4825 个条目（inconclusive 不是失效，已排除）：

| 条目 | 状态 |
| 1HelloMan1/dsh-stats-dashboard | archived — repository is archived |
| 777-Zen/dsh-capability-index | archived — repository is archived |
| aa2246740/dsh-grok-plan-mode | archived — repository is archived |
| an4nsi/dsh-fork-view | archived — repository is archived |
| Andy8647/dsh-automode | archived — repository is archived |
| brunhildzhou/dsh-all-warmup | archived — repository is archived |
| Bryan-cmf/dsh-skill-gate | archived — repository is archived |
| Bryan-cmf/dsh-skill-trail | archived — repository is archived |
| careyourcake/dsh-plugin-litsearch-zotero | archived — repository is archived |
| ccch1mneyyy/dsh-working-activity | archived — repository is archived |
| chen731215-dev/dsh-tavern | archived — repository is archived |
| cherrchen/dsh-client-ui-details-host | archived — repository is archived |

……另有 4813 个见 data/decay.jsonl。

复现

1. 采集带该话题的仓库 gh api "search/repositories?q=topic:dsh-plugin&sort=updated&per_page=100&page=1" > /dev/null

2. 三级契约探测
node scripts/probe-contract.mjs data/contract.jsonl

3. surface 归因
node scripts/attribute.mjs data/surface.jsonl

4. 可安装性（npm registry + 保留 scope 检查）
node scripts/installability.mjs data/installability.jsonl

5. 对目录做失效扫描
node scripts/scan-decay.mjs data/decay.jsonl

6. 每个门禁的负例控制
node scripts/test-gates.mjs
node scripts/test-monorepo.mjs
node scripts/test-inconclusive.mjs
node scripts/test-decay.mjs
./scripts/test-fetch.sh

scripts/test-gates.mjs 存在的理由是：不会失败的门禁不算门禁。它断言第 3 级判定会拒绝空文件、纯空白、纯注释和散文文件，并断言保留 scope 规则会标记外部 owner、同时不误伤有权发布者、无关 scope 和形近 scope。两个门禁都带一个哨兵断言，一旦规则被改成无条件放行就会失败；两者都通过注入缺陷并确认测试变红来验证过。

数据

| 文件 | 内容 |
| data/repos-raw.jsonl | 搜索 API 返回的仓库元数据 |
| data/contract-v3.jsonl | 三级契约判定 |
| data/surface-v3.jsonl | 带置信度的 surface 归因 |
| data/installability-v3.jsonl | npm 解析与保留 scope 判定 |
| data/catalog.jsonl | 合并、分类后的目录 |
| data/decay.jsonl | 每个条目的失效状态 |
| data/npm-manifest.jsonl | 每个已发布包声明了什么，与其仓库的对比 |
| data/ratings.jsonl | 成对比较得出的 Elo 评级，含每个条目的场次 |

搜索 API 单次查询最多返回 1000 条结果。scripts/enumerate-topic.mjs 先按 star 桶、再按创建日期分片绕过这个上限，最终枚举到 14347 个唯一仓库——即整个话题，不是样本。日期边界取自结果计数而非排序，因为这个搜索后端根本不支持按创建时间排序。

相关项目

已有多个目录覆盖这个生态，各有取舍：

- AdamPlatin123/awesome-dsh-plugins
——运行级测试（装进 DSH、拉起本地模型、观察工具调用），通过本地 cron 而非 Actions 运行。是这个生态里最彻底的验证。
- Sunrisepeak/dsh-index——定时发现 workflow，带 pnpm pack 校验和失效 pin 告警。
- wangshunnn/oh-my-dsh——每八小时从 topic:dsh-plugin 刷新一次 registry，带 schema 校验。

本项目不在「单仓库深度」上竞争，且上面有两个项目在判据上领先于它：

- awesome-dsh-plugin/awesome-dsh-plugin
（6439 star）对每个 PR 运行投稿门禁（scripts/check-submission.mjs）：树中任意位置的 dsh.bundle、仓库年龄、commit 数。它的树遍历比本项目更严谨——它把被截断的树或超出上限的 manifest 数视为未知而非「不存在」，而本探针此前不这样处理。它还会解析 npm 发布状态（scripts/probe-npm.mjs），并通过校验已发布包是否指回同一仓库来防止名称抢注。已有约 1300 份投稿经过它。
- omdsh-dev/dsh-plugin-check
对单个仓库应用 36 条判据——清单协议、patch 结构、构建布局、TypeScript 导入、row-id 注册——远比这里公布的三级契约更细。

本项目仍然独有的部分：

- 非投稿式覆盖。 上述两个项目检查的是被提交给它们的仓库。本项目探测的是话题范围内的样本，无论有没有人投稿，因此它测量的是生态本身而不是它的收件箱。
- vendored harness 检测。 本样本中 5 个仓库原样携带 @deepseek-ai/dsh-base 且 fork: false。它们靠内含 DSH 自己的包通过契约检查，而按 owner 查或按 fork 查都发现不了。
- 拒绝猜测的失效扫描。 scripts/scan-decay.mjs 报告 gone、archived、 dormant 和 unbundled，并把探测不成功的情况报为 inconclusive 而不是失效，因为每一个失效状态都会促使他人删除条目，而证据可能并不支持这个删除。
- 公布整个样本的分布而非精选列表：判定占比、按 star 档的合格率、以及全部 17432 个被探测仓库的可安装性，探针脚本一并提供。

更深入的单仓库审计已经存在，但未发布——见 AUDIT-EXPERIMENTAL.md。它的首个实现在每一个被测仓库上都产生了误报，因此在通过人工标注的固定样本集之前，不会有任何判据上线。

许可证

MIT