拆解 1.1 万个 DeepSeek Harness 插件后发现的治理空白

我们对 GitHub 上带有 dsh-plugin 标签的 1.1 万多个仓库做了逐一梳理、装了一个探针插件试验，并把下载量高的二十几个插件拉来跑了一夜。结论很直白：表面上的“生态繁荣”掩盖不了几乎不存在的治理与质量把控。

不同来源对“有多少插件”给出截然不同的数字，原因是社区内部没有一个公认的插件定义。把整个生态想象成一个漏斗，从上游到下游数量大幅流失——第一层到第三层掉了约 81%，再往下又掉了约 55%。换句话说，所谓的 1.1 万个“插件”里，真正能按 DeepSeek Harness 规则被识别和安装的，可能不足千个，具体取决于你采用的统计口径。本文数据截至 2026 年 8 月 25 日。

官方对插件生态的说明极为简陋：README 和 CONTRIBUTING 里只用一句话建议给仓库打 dsh-plugin 标签以便发现。实际情况是，GitHub 标签的门槛为零，任何人都能为任何仓库打上该标签，不需审批，也不要求与 dsh 有实际关系。因此大量无关项目、蹭热度的仓库、以及恶意或误导性内容都能进入到“插件池”里，造成信息噪音和安全风险。举例：按 GitHub 的默认“最佳匹配”排序，排序靠前的项目里竟有一个早在 2020 年就完成的简历生成器，只因被打了标签而出现在 dsh 插件排名中。 龙8头号玩家

我们还参考并聚合了一份社区公开的拒稿记录，共 1,883 条。聚合结果显示，约 93%（1,752 条）的拒绝理由是“按 dsh 的规则装不上”：缺少 dsh.bundle 声明、没有 dsh 依赖或没有 dsh 能发现的技能布局。被拒并不意味着仓库就是空壳；我们随机检查了 50 个被拒仓库的体积与语言分布，发现：只有 1 个小于 5KB（基本只是 README），中位数约为 407KB，12 个超过 5MB，最大的达到 336MB。用到的编程语言五花八门：TypeScript、JavaScript、Python、Rust、PowerShell、C、C++、Swift、Go、Shell 等。其中约三成使用的语言根本无法通过 npm 路径生成 dsh 插件——插件机制事实上沿用了 npm 的生态，Node 之外的语言自然进入受限。

总体上，那些贴上 dsh-plugin 标签的仓库大致可分为三类： - 空壳类：几乎只有说明文字或模板，根本没有可用插件代码；样本里 50 个只有 1 个是极小的空壳。 - 完成度不足类：代码存在且看起来是为 dsh 写的（宿主端与浏览器端都有），但没有按 dsh 规定打包或声明，导致官方安装命令识别不了——理论上修改很小就能生效，但很多项目就是“差最后一步”。 - 无关挂靠类：根本不是 dsh 插件的程序，却被打上了标签；如 Windows 启动器、macOS 状态栏组件、各种桌面客户端（样本中就有多个同名的 desktop 项目），甚至有人用标签发布把界面改成 2005 年门户风格的插件，从而制造噪音和误导。

此外还有大量重复或容易混淆的命名，例如 505 个仓库名里含有 deepseek-harness-desktop，多个团队各自命名冲突、域名也分散，给新用户识别可信插件带来极大困难。官方生态中缺乏的关键治理要素更明显：没有集中插件目录、没有搜索与排序规则、没有版本兼容矩阵、没有签名或校验机制、没有明确的安全上报通道，也没有官方推荐清单或质量筛选体系。 龙8头号玩家

总结：DeepSeek Harness 推动了“Everything is a Plugin”的理念，但在开源热潮下，如果没有明确的准入标准、质量控制和安全治理，插件数量的增长反而变成了噪音与风险放大器。当前的现实是门槛过低且缺乏监管，导致大量无效、未打包或无关项目混入生态，给用户使用和平台安全都带来了隐患。若要把生态做成真正可用、可被信任的市场，必须补上目录检索、签名校验、兼容说明、举报与审查机制等治理环节。