DeepSeek Harness 的插件体验短板：安全权限未生效，好插件用户找不到

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

距离 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。我们把它的源码读了一遍，实际逻辑是：

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

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

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

它没有加任何权限档。它注册的那个 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」解决了“什么可以被扩展”。现在还没有解决的是：谁来决定什么值得被安装。

文章来自于微信公众号 “AI科技评论”，作者 “AI科技评论”