国内股票配资实盘排名我们拆了 1.1 万个 DeepSeek Harness 插件，发现官方几乎没有建立插件治理机制

“最严安全档形同虚设国内股票配资实盘排名，装插件就能读到你的 API Key。”

作者丨Rhea

编辑丨李娜岑峰

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

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

「一切皆插件」是把内核的每一颗螺丝都交到你手里。但实际上绝大多数人对螺丝毫无兴趣；而整个插件生态没人管理也没人负责。（注：整个生态数据变化很快，本文中所有数据仅截至 2026 年 8 月 25 日实查。

1.1 万个插件，到底有多少是真的？

不同的统计方式差挺多

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

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

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

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

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

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

没有插件目录

没有搜索

没有版本兼容矩阵

没有签名或校验

没有安全上报通道

没有官方推荐清单

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

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

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

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

【dsh 插件 top5 】

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

有人把这一万多个仓库逐个打开筛了一遍，并公开了 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 那条路，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 标签里拉回来的真实仓库，按最近推送时间挑新鲜的，还特意把自己排除掉。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

安全：read-only 管不了插件

dsh 有三档文件权限：

read-only（只能读）

workspace-write（只能改当前工作区）

danger-full-access（完全放开）

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

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

你肯定想问，为啥会这样啊？

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

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

最坏结果具体是什么？一个插件能做的事，等于你这个电脑账号能做的一切：读 SSH 私钥、云平台凭据、其他项目的源码；往任何地方写文件；连外网。所以能把上面这些发出去。

而这一切不需要你同意任何东西，装上就有了。（或者说安装即同意）还记得那句经典台词吗：这不是 bug，这就是一个 feature。

官方在一篇设计笔记里明确写过“安全与权限不是设计目标”，那个自指工具集的 README 也自称“沙箱不是安全边界，请把这套工具当作 bash 权限对待”。

出自2026-07-08-agent-scope-contexts.zh.md

出自 deepseek-harness-repo/packages/extensions/tool-cordis/README.md

问题是谁真的会在安装一个插件的时候去读这些说明，去看源码。可能有人会说那 app 的授权也是这样啊，但大家别忘记了 app 是有监管的，背后是一整个互联网规则、工信部兜底/定期审查，厂商校验。而 dsh 的插件生态啥都没有，用户必须得自己负责。

一旦有这种空子可以钻，那对于心怀不轨的人这种敞开的大门就迟早会被攻陷。

我们装完 10 个下载量最高的插件后，把配置导出来跟出厂状态做了个 diff。发现一个叫 dsh-tui 的插件，这是个终端界面皮肤。但他会改写沙箱策略，并且在 Windows 下把权限强制拉到最高那一档danger-full-access。（非作者故意，并且作者把理由写在紧邻的注释里：Windows 上官方没有沙箱后端，不设成 danger-full-access，bash 命令根本跑不了。而且非 Windows 平台它保持官方默认。）

在 AI 时代，没有人会去核实每一个插件里到底写了什么规则。

比方说有人觉得官方「只能改当前工作区」和「完全放开」这两档之间落差太大，做了个插件说加了中间一档，叫auto。我们把它的源码读了一遍，实际逻辑是：

先过一个确定性的危险命令正则黑名单→ 命中就转人工

没命中的，交给一个 AI 分类器判断放行还是转人工。而那个分类器的提示词里明写着 \"Default to approve\"（默认同意）

分类器超时、出错、返回非法 → 兜底转人工

它没有加任何权限档。它注册的那个auto只是一个审批预设名，沙箱模式仍然是官方的三档，一档没变。我以为装上之后会多加一层保护，实际上是开了默认档，减少了一层复核。而这件事只有读源码才能发现。但正经人谁会装一个插件的时候都去复核源码？难道我们在装一个 skill 的时候也会去做一层安全校验吗？我不认为作者有恶意，他大概真心觉得自己在帮人省事，而且他在分类器失败时兜底转了人工。

这时候再看安装插件时候的这个提示，会有一种错愕感，之前觉得也就是个免责什么而已，现在觉得这行字里面透露的东西有点恐怖。

成本：装一个插件，缓存可能整段失效

DeepSeek 千方百计做的缓存命中策略在插件这件事上直接回到解放前。比如说固定任务、固定仓库、全新会话，跑热之后除了费钱还有三个后果：

首轮变慢；

工具越多模型越容易选错工具（这是官方自己在文档里承认的问题，他们做 Code Mode 就是为了治它）；

上下文被工具说明书吃掉。

DeepSeek 对省缓存这件事极其上心，但在整个插件生态里，没有一个地方告诉你装插件会让缓存作废。我不认为这是它没为插件做准备。恰恰相反，它做了大量准备：profile 和 preset 机制齐全，每个会话可以挂不同的插件组合；Code Mode 可以把二十个工具说明书换成一个 run_code。

真正的问题是他把一个工程制品当做产品发布了，或者说不管他怎么强调开发版本，用户依然会当做成熟产品来使用机制全在，但你得自己知道去用，并且得自己负全责。

那这到底是技术上办不到吗还是主观上不愿意做？

缓存归零确实躲不掉。缓存是按前缀命中的，工具说明书就排在前缀里，你装一个插件等于往前缀里插进 14 段新说明，从变动那个字往后全部作废。换谁来做都一样。

但用户告知是选择。解法它做了：profile 和 preset 能让你按会话挂不同的插件组合，Code Mode 能把二十份说明书压成一个run_code。可这些都要你自己知道、自己去配，而整个插件生态里没有一处提示你装插件会让缓存作废，也没有一处告诉你这一下花了多少钱。

一家把对 KV 缓存的影响写成 223 个包 README 必答章节的公司，不可能不知道这件事。它只是把答案留在了工程师那一侧，默认他的用户都是工程师。

兼容性：插件相互冲突的现象非常严重

我们把按仓库去重后下载量前十的插件装进同一个配置，起不来。

【实测报告中 LLM 的返回部分截图】

冲突涉及的正好是下载量第 2、3、6 名。必须禁掉其中两个之后才起得来。原因是那个 UI 全家桶的依赖清单里明写着它自己带了一个侧边栏组件。你再单独装一个侧边栏插件，两个就抢同一个界面路径。

所以我们发现 dsh 缺的其实是一个仲裁者，或者说一个管理者。它有配置层、有加载顺序、有能力接缝。官方文档甚至把“后面的层按行整行覆盖前面的、不是深度合并”这个语义写得很清楚。他们知道会有冲突，还把怎么冲突的讲明白了，但没做任何工具去检测它。

它对行业的影响

star 爆炸不等于出圈

我们来拿 OpenClaw 做对照。

也就是说 dsh 在开发者圈里火得比 OpenClaw 快十倍，但仅限于开发者圈子。这倒是和他们的定位非常一致，普通人很难上手这个工程产品，也很难自己负责这么大的自由度。

不过有意思的是 fork 和 star 的比例上看 OpenClaw 要高一倍多，不过 dsh 才建仓没多少天，究竟有多少人愿意 fork 下来改代码还需要时间的验证。

它吸引了谁：拉来了新人，但新人做的东西没被看见

我们做了一轮非常详细的普查。注册表里全部 1,446 位可查作者，加上 dsh 开源后新建、且至少有一个 star 的打标签仓库的 5,032 位作者，合并去重 5,192 人，逐个查了账号创建时间、历史仓库、以及“在 dsh 之前有没有做过 AI/agent 项目”。一共跑了 4 小时 6 分。

先说结论：

2024 年及更早注册的老账号占 67–69%，8 月当月新注册的只有 3.9%–4.4%

followers 中位数是 1，四成作者零粉丝，组织账号只占 4–5%

把那 5,032 位作者按他们最高 star 的那个仓库分三档：

所以答案是：dsh 确实吸引来了大量新人，但新人的作品集中在无人问津的低 star 区间，被看见的那些仍然由老 AI 玩家把持。

另一个角度的对照方向一致但更弱：做出了真有人下载的插件的那 694 位作者里，63.7% 在之前就开发过 AI 相关的项目；所以这暴露出 dsh 这套游戏规则的另一个弊端，缺乏官方分发管理的时候，那些优质的个人开发者和新项目没办法得到良好的激励，这个生态会迅速被老登占据，那几乎就离成为一摊死水不远了。

DeepSeek 为什么把插件分发留给了社区？

DeepSeek 做过分发机制，然后主动删掉了

我在仓库的设计记录里翻到一篇 2026 年 8 月 9 日的笔记，距离公开发布还有 4 天。

被移除的东西逐项列着：@deepseek-ai/dsh-repository-plugin 包、.dsh-plugin 专用编写格式、dsh-plugin-prepare 可执行文件、生成的包装层、不可变 repository 缓存、base 里的 repository-plugins 配置项、repository 专用的 skill 与 MCP 适配器、以及一条专用的 GitHub 验收流水线。并且明确不保留兼容解析器或迁移机制。

【出自.agents/notes/implemented/simplification/2026-08-09-remove-repository-plugin.zh.md】

官方给的理由：这条路径与 profile 组合包路径重复实现了第三方包的安装与组合，而且它能提供的配置反而更少，repositories 列表只能选源字符串，生成的包装层挂载代码入口时无法传入用户提供的插件配置。

说白了就是它增加了大量代码和 CI 工作，却没有成为通用的外部插件分发机制。

但是呢，你会发现被删掉的是分发路径。而「发现」和「信任」这两层其实从来没有被实现过，也压根没有出现在这篇取舍记录里。他们讨论的全部内容是装的机制有两套，太重复了，那干脆别干了。

一个写了 1,372 篇设计记录、连 22 篇被否决的方案都留档公开的团队，在关于插件分发的那篇取舍记录里，没有一个字讨论用户怎么找到它们和用户凭什么信它们。还是那句话，都丢给用户自己决定。

从行业和历史找答案

三家的路子不一样，但没有一家把这层留空。Claude Code 和 Figma 是官方自己下场做，MCP 是社区目录先行、官方后补。区别在什么时候做和谁来做，不在做不做。也许有人会说 dsh 是开放协议不是产品，凭什么要求它开商店。那 MCP 也是开放协议，也是社区先跑起来的，Anthropic 最后还是把官方 registry 补上了。

所以真正的问题不是 dsh 会不会补上这一层，而是它会被什么推着补。我猜应该很快了，否则迟早出问题。

往后会怎样

四个历史剧本

太阳底下无新事。npm、vs code、figma 都面临过这些问题，也都演化出了自己的解决路子。

我们抽了 12 个注册表上“没发布正式包”的插件去 npm 查同名，5 个有同名包，逐个比对仓库和维护者，全部是另一个作者的另一个项目。（样本稍微有点小，当做个信号看就行。）

假如你要装，那因为注册表上那个 dsh-hud 是某位作者的，得从 GitHub 装。但是你顺手敲 dsh plugin add dsh-hud，装到的是另一个人的另一个 dsh-hud。

【同一个名字，两个作者，两个项目。】

但严格说，dsh 的开局比 npm 早期还要更乱一点。npm 早期的毛病是名字先到先得，可它至少只有一套名字。

你敲npm install foo，装到的就是注册表里那个 foo。dsh 是两套：发现靠 GitHub 标签和那份社区清单，安装靠 npm，中间没有映射，也没有谁负责对齐。

所以真正的问题是目前它连 npm 早期的地基都还没有。

dsh 插件生态的价值到底在哪?

连主循环也是插件这件事，用别的开源 harness 自己搓还真做不到。

如果去 fork 一个项目自己改，改的是它的源码，上游更新的话得手动合。dsh 是改一行配置，升级的时候不冲突。这是fork 一个项目和给一个项目挂东西的区别，对长期维护的人来说这个区别还是很大的。

竞品做成了可插拔后端。

内置了起一个真正的 Claude Code 子进程、起一个 Codex 子进程，还有两套竞品的 hook 协议桥，开发者为 Claude Code 写的 hook 配置可以直接搬过来复用。

但这两条独特能力，只对要改执行内核的人有价值。但是真换主循环的只有一个人（周下载 438、4 个 star），换文件系统后端的也只有一个人。那 55.6% 在做扩能力的插件，用别的 harness、用 MCP 一样能做。也就是说 dsh 提供的那个独特能力，恰好是这个生态最少人用的那一层。

尾声

回到开头那个数字。11,439 个仓库，2,143 个能装上，955 个真有人用。这个落差本身不是问题，任何生态的头部都很窄。问题是从 11,439 到 955 这一路上，每一道都是社区自己组织起来的。官方给的只有一个标签。而没人管的第一个代价，是安全和责任被整个丢回用户手里。这个前面已经提到很多次了。

第二个代价我觉得更严重一些，好东西没有理由继续被做出来。我们数过的两组数字，正好从两头夹住同一件事。一头是：那 5,032 位作者里，star 最低的那一档，近一半此前跟 AI 毫无关系。新人也被吸引进来很多，肯定有人做出不错的东西，但几乎都留在零 star 上。另一头是：官方唯一那个发现入口点过去，排第四的是一个 2020 年的简历生成器。把它顶到那儿的不是它为 dsh 做了什么，是它六年攒下的四万 star。

DeepSeek Harness 已经证明了一件事：一个 Agent 的内核可以被拆得足够开放。但插件生态要成立，开放只是第一步。真正困难的是，当陌生人的代码开始进入陌生人的电脑时，谁负责建立发现、信任和责任机制「Everything is a Plugin」解决了“什么可以被扩展”。现在还没有解决的是：谁来决定什么值得被安装。

广盛网配资提示：文章来自网络，不代表本站观点。