我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


最严安全档形同虚设,装插件就能读到你的 API Key”      


距离 DeepSeek Harness 开源已经有一段时间,「Everything is a Plugin」的口号也已经在各种领域开枝散叶,坊间涌现出了特别多的插件和社区。


十几天后的现在,GitHub 上【 dsh-plugin 】标签下有一万多个仓库。我们花了几天时间,把这一万多个仓库拆开数了一遍,写了一个探针插件装进去试探,又装了二十几个下载量最高的插件跑了一夜。


「一切皆插件」是把内核的每一颗螺丝都交到你手里。

但实际上绝大多数人对螺丝毫无兴趣;而整个插件生态没人管理也没人负责。(注:整个生态数据变化很快,本文中所有数据仅截至 2026 年 8 月 25 日实查。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


1.1 万个插件,到底有多少是真的?


不同的统计方式差挺多


同一天,同一个生态,不同网站统计的插件数量是这样的:


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


造成这个现象的原因是「插件」这个词在这个生态里还没有公认的定义,谁都可以合理地说自己那个数是对的。如果把整个 dsh 的插件生态做成漏斗大概是这样的:


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


从第一层到第三层掉了 81%,从第三层到第五层又掉了 55%。也就是说 DeepSeek Harness 插件生态目前有 1.1 万个插件,或者说目前仅用不到一千个插件,这两种说法都对,无非是看用什么统计口径。


为什么每一层漏洞能差这么多?DeepSeek 官方关于插件生态的全部指引,就只有 README 和 CONTRIBUTING 里各一句话:给你的仓库打上 dsh-plugin 这个 GitHub 标签,方便别人发现你。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


【出自 https://github.com/deepseek-ai/deepseek-harness/blob/master/README.zh.md】


也就是说要想被记为一个 dsh 的插件极其简单,几乎没有任何成本。我们把仓库和文档全站搜了一遍,缺少的东西包括:


  • 没有插件目录


  • 没有搜索


  • 没有版本兼容矩阵


  • 没有签名或校验


  • 没有安全上报通道


  • 没有官方推荐清单


而 GitHub 标签的准入门槛是零,也就是说任何人可以给任何仓库打任何标签,不需要审批,也不需要跟 dsh 有任何关系。那可想而知,将会有多少水军和不怀好意的人涌进来滥竽充数亦或者别有所求。


比如说官方 README 里那个链接点过去,GitHub 默认按“最佳匹配”排序,而最佳匹配高度相关于 star 数。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


然后你会发现排名第四是一个 20 年就做好的简历生成器。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


它建于 2020 年,比 dsh 早了六年。它目前在 dsh 插件社区排第四只是因为加了一个蹭热度的 tag。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


【dsh 插件 top5 】


一万多个插件有多少能用?


有人把这一万多个仓库逐个打开筛了一遍,并公开了 1,883 条拒稿记录(含理由与复查日期)。我们把这份数据下载下来自己聚合了一遍发现:93%(1,752 条)的拒绝理由是“按 dsh 的规矩装不上”,没有 dsh.bundle 声明、没有 dsh 依赖、也没有 dsh 能发现的技能布局。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


但装不上不等于是空的假仓库。我们又随机抽了 50 个被拒仓库看体积:


  • 只有 1 个在 5KB 以下(约等于只有个 README)


  • 中位数 407KB


  • 12 个超过 5MB,最大的 336MB


  • 语言五花八门:TypeScript、JavaScript、Python、Rust、PowerShell、C、C++、Swift、Go、Shell 都有。其中三成用的语言根本做不成插件。因为插件走的是 npm 那条路,Node 之外的语言进不来。


所以这一万多个插件真实构成是三类:


  • 第一类,真的是空壳。数量很少,50 个里只有 1 个:一个 2KB 的仓库,描述吹自己是“扩展插件全家桶,6 个插件加一键安装脚本”。


  • 第二类,代码是真的,只是没按 dsh 的规矩打包。 有两个仓库里躺着写好的插件,宿主端和浏览器端两半都齐了,就是没加那句声明、也没发布到 npm,于是官方的安装命令认不出它(很奇怪为啥做了但没做完,理论上这 vibe coding 就一句话的事)


  • 第三类,完全是别的东西挂了这个标签。我们抽了 50 个样本里有 5 个 Windows 启动器、一个 macOS 状态栏小组件、几个桌面客户端还有一大堆乱七八糟的东西实在不想说了。


还有 505 个仓库的名字里带着 deepseek-harness-desktop,三个团队做桌面客户端,其中两个都叫 dsh-desktop,两个都叫 deepseek-harness-desktop,域名一个 .com 一个 .cn。对新用户来说这就是纯噪音。


甚至社区有人专门弄了个插件,把 dsh 界面装扮成 2005 年的中文门户:侧栏广告、信息流、角落弹窗,还有点不掉的假关闭叉。我不知道作者是想嘲讽门户时代的广告,还是嘲讽现在插件社区的现状。我们读了它的源码。那些假广告位里展示的确实是它实时从 dsh-plugin 标签里拉回来的真实仓库,按最近推送时间挑新鲜的,还特意把自己排除掉。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


DeepSeek 开放了内核,但大家只想装工具


依然是卖铲子和娱乐赚翻了


注册表里那 2,143 条可以按三类来分:


  • 卖铲子的,比如市场、用量计费、文档、开发辅助


  • 娱乐体验的,比如主题、桌宠、界面增强


  • 真扩能力的,比如工具、记忆、视觉、语音、工作流


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


下载量前三名全是市场和界面类。第四名 modlens(视觉)才是扩能力(而且是刚需能力)。


这当然不是 dsh 一家的偶然。我们把同一套分法套到 Anthropic 官方运营的那 2,282 个 Claude Code 插件上,扩能力插件也是 55.0%,铲子+娱乐也是 40.2%,两个生态几乎完全一致。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


面对一个新东西,市场最缺的从来不是怎么用它产出,而是我先得找到它。所以做商店的、做教陪的,是最快也最持久的刚需。这门生意会从一个东西诞生那天开始,做到它死的那天为止,就像今天网上还有人在卖怎么用 Excel。


这解释了为什么全生态下载量第一的插件,做的就是帮你找插件。


个 dsh-market,2,331 star,周下载 159,327,约等于官方入口包周下载(662,397)的 24%。装上之后 dsh 的设置页里就多出一个「插件市场」,能搜、能筛、能看截图、一键装、一键更新、两步确认卸载。而做插件市场/管理器的插件有 60 个,第一名比第二名多 14 倍(189,798 vs 13,678)。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


官方最自豪的那一层几乎没人碰


官方最骄傲的卖点是没有特权内核,连 agent 主循环都能换。我们把 2,143 条的名称和中英描述全搜了一遍,又去 GitHub 做代码搜索双查。真正以插件形态换掉主循环的,我们只找到两个。


一个是 dsh-frostfin,把主循环换成 Kimi Code 走 ACP 直连。周下载 438,5 个 star。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


另一个叫 dsh-session-pause,它禁用官方 loop、挂上自己改造的版本,为的是实现“暂停当前回合、重启之后接着跑”。它连 npm 都没发,注册表里也没收录,4 个 star。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


也就是说另一个愿意动主循环的人,动它不是为了换脑子而是为了补一个官方没做的功能。


但同时换模型这个接口被用爆了:69 个插件,头部的做法是把 Codex、Claude、Grok、Kimi 的订阅额度接进 DeepSeek 自己的 harness,单个周下载六千上下。


不知道 ds 怎么看待这个现象,也许这和他们认知的世界不太一样,他们可能认为我把最核心的东西都给你改,但绝大多数人根本就对这个毫无兴趣。


装一个插件的代价是什么?


安全:read-only 管不了插件


dsh 有三档文件权限:


  • read-only(只能读)


  • workspace-write(只能改当前工作区)


  • danger-full-access(完全放开)


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


我相信几乎所有人看到这三个词,都会理解成安全等级。我们写了一个最小的探针插件,用正常流程装进去,然后在三档权限下各跑一遍九项试探。结果是九项试探在三档权限下全部成功,也就是说任何一档都无法约束插件行为。(下图根据实测结果整理得到。)


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


在最严的 read-only 档下,探针列出了 ~/.ssh/ 里的文件、从环境变量里读到了我的 API key、往 /tmp 写了文件并读回、连上了外网。


你肯定想问,为啥会这样啊?


因为模型想对你的机器做任何事,只能请求 dsh 帮它做:比如帮我读这个文件、帮我跑这条命令。那三档设置就是 dsh 用来审查这些请求的。但是最关键的来了,插件不需要请求,因为它自己就是 dsh。


类比一下就好像那个设置是门口的保安,检查访客。但插件不是访客,插件是我同事,所以保安不会查他。


我们拆了 1.1 万个 DeepSeek Harness 插件,发现官方几乎没有建立插件治理机制


最坏结果具体是什么?