DSH 插件生态五天狂飙 1912 个,但安全审计给了当头一棒

DSH 主界面

DSH 桌面客户端主界面。3 万+ 下载量背后，是一个还在快速迭代的产品雏形。

8 月 13 号，DeepSeek 把自家的 Agent 框架 DeepSeek Harness（简称 DSH）扔到了 GitHub 上。

五天后，npm 上打 `dsh-plugin` 标签的包涨到了 795 个。到 8 月 18 号，三家插件目录站分别索引了 699、1,478 和 1,912 个插件。GitHub star 冲到 159k，fork 16.6 万，桌面客户端 3 万多次下载。

数字好看。但你把 795 个有据可查的包掰开看——608 个有公开仓库，56 个有过下载记录，44 个周下载超过 100，16 个周下载过千。

换句话说，社区的插件热潮里，真正被用起来的不到 6%。

这不是在唱衰 DSH。这是在说一个事实：一个发布才五天的项目，生态的"热"和"用"之间，隔着一道巨大的鸿沟。今天我们来仔细看看，这道鸿沟里到底有什么。

一、DSH 是什么——"一切皆插件"的架构赌注

DSH 的核心公式——Agent = Model + Harness。模型是大脑，Harness 是身体，插件是四肢。

DSH 的全称是 DeepSeek Harness。注意，它不叫"DeepSeek Agent"，不叫"DeepSeek Code"——叫 Harness，驾驭工具。

这个名字本身就说明了 DeepSeek 的野心：他们想做的不是一个聊天机器人，不是一个代码助手，而是一个驾驭一切的 Agent 框架。

Cordis 内核架构。插件加载/卸载/依赖管理、运行时热替换，全在这层完成。

核心公式很简单：Agent = Model + Harness。

模型是大脑，负责思考和生成。Harness 是身体，负责感知环境、使用工具、执行动作。把两者组合起来，你就得到了一个 Agent。

DSH 的内核叫 Cordis（拉丁语"心脏"）。它干的事是：插件加载、卸载、依赖管理，运行中可以热替换。你不用重启就能换掉一个插件，甚至换掉底层模型。

"一切皆插件"架构图。模型适配器、工具注册表、会话存储、审批策略、Agent 循环、Web UI——全都可以插拔。

这个架构的激进之处在于"一切皆插件"：

官方提供了四种预设模式：

最让人兴奋的是 Creator 模式。在这种模式下，Agent 如果发现当前没有能完成任务的插件，它会自己写一个。不是编个 shell 脚本糊弄，是真的创建一个结构化的 DSH 插件包。

Agent 公式的详细拆解——Model 提供推理能力，Harness 提供环境感知和工具调用能力。

整个系统还有一个设计亮点：只追加的事件日志。Agent 做的每一步操作都会被记录下来，模型的推理过程、工具调用、结果返回，全部可追踪。这对调试和审计都很有价值。

听起来很美对不对？等我们聊到安全问题的时候，你会发现"一切皆插件"这个设计理念，同时也是一切安全隐患的根源。

二、插件生态全景：狂热、碎片化与真实的使用数据

先看增长速度。DSH 仓库 8 月 13 号创建，到 8 月 16 号（三天），npm 上已经有 795 个带 `dsh-plugin` 标签的包。到 8 月 18 号，三家第三方目录站的索引数量分别是：

三个数字差异很大，原因很简单：各站收录标准不同，有的只收录有 README 的包，有的来者不拒。但不管看哪个数字，增长曲线都陡得吓人。

不过，数量不等于质量。我们把 795 个包拆开看：

▍608 个有公开仓库（76%）

▍56 个有过任何下载记录（7%）

▍44 个周下载超过 100（5.5%）

▍16 个周下载超过 1000（2%）

第三方插件目录站的插件列表截图。数量很多，但质量参差不齐。

这意味着 94% 的插件基本没人用。很多可能就是开发者图个新鲜，`npm publish` 一下就再也没碰过。

社区对 DSH 插件生态的整体评价如何？第三方评测给 7.4/10 分（8 维度评测）。不算高，但考虑到发布才五天，也不算差。

第三方实测 DSH 的缓存命中率——95-100%。重复任务几乎不消耗额外 token。

一个值得注意的性能数据：第三方实测 DSH 的缓存命中率达到 95-100%。这意味着重复执行相似任务时，几乎不用额外消耗 token。在成本控制上，这是个实打实的优势。

另一个数据点：长程任务最长可跑 10 小时。猪八戒上有人用 DSH 跑 3D 建模，一个任务跑了 20 分钟，已经算"快"的了。V4 Pro 模型在高峰时段的输出定价是 ¥27/M tokens——不便宜，但比 Claude 便宜。

回到插件分类。热门插件大致可以分成这么几类：

dsh-at-file 插件的使用效果。一个"基础功能"竟然需要社区插件来补位——这种吐槽不是没有道理。

说得扎心的是：@文件引用这种基础功能，居然要靠第三方插件来实现。这说明 DSH 的官方团队三个月赶出来的产品，功能缺口还很大。社区疯狂造插件，一部分原因是官方该做的没做完。

三、安全问题：插件无沙箱，等于把家门钥匙交给陌生人

这是本文的重点章节。DSH 的安全问题不是"可能有隐患"的级别，是"已经被公开验证了多个严重漏洞"的级别。

3.1 核心问题：插件运行在 Harness 进程内，无沙箱

有一句话说得很直接："plugins run inside the harness process with full privileges and no sandbox"。

翻译一下：每个插件都跑在 DSH 主进程里，拥有完整的系统权限，没有任何沙箱隔离。

这不是一个 bug，这是一个设计决定。DSH 团队选择了"一切皆插件"的极致灵活性，代价就是放弃了进程级隔离。插件可以读你的文件、访问你的网络、执行系统命令——和 DSH 主进程一模一样的权限。

官方内置的 100+ 插件还好，毕竟 DeepSeek 自己写的。但社区插件呢？npm 上 1912 个包，你装一个第三方插件，就等于给了它完全的系统访问权。

3.2 VM Escape 漏洞：一行代码拿宿主权限（CVSS 9.0+）

8 月 13-14 号，社区讨论区出现了针对 DSH workflow 功能的安全报告。

问题出在 `@deepseek-ai/dsh-workflow-worker-thread` 这个包。DSH 的 workflow 功能会执行模型生成的脚本，运行环境是 Node.js 的 `vm.createContext({})`。

问题在于：`vm.createContext` 不是安全沙箱。Node.js 官方文档明确说了，`vm` 模块"不是安全机制，不应该用来运行不受信任的代码"。

攻击者构造的 payload 只需要一行：

这行代码通过原型链访问拿到 `process` 对象，然后调用 `getBuiltinModule` 拿到文件系统模块。之后就是任意文件读写、任意命令执行。

更糟糕的是，Worker 线程不受文件沙箱保护。bwrap、Landlock、Seatbelt 这些系统级沙箱机制，都不覆盖 Worker 线程。也就是说，即使你配了文件沙箱，VM Escape 之后照样可以随便读写。

这个 PoC 在 Node v24.19.0 上验证通过。CVSS 评分 9.0+。

3.3 Pathname Race Condition：竞争条件绕过文件写入限制

GitHub discussion #159 报告了一个文件系统沙箱的竞争条件漏洞。

DSH 的 fs-sandbox 用 `checkedTarget()` 函数来验证文件路径是否在允许的工作区内。但这个验证检查的是路径字符串，不是文件系统对象的实际身份。

攻击方法：在 `checkedTarget()` 验证路径之后、实际写入文件之前，用 symlink 或 rename 操作把目标文件替换掉。时间窗口很短，但测试结果是 3/3 全部成功，成功覆盖了工作区外的文件。

这类竞争条件漏洞在安全领域叫 TOCTOU（Time-of-Check to Time-of-Use），是经典问题。DSH 的沙箱实现没有用 `O_NOFOLLOW` 或 inode 绑定来防住它。

3.4 Config-tree 写权限：插件启动就拿到全部配置

GitHub discussion（xiejin77 报告）指出：第三方插件在启动时就获得完整的 config-tree 写权限。

这意味着什么？一个恶意插件可以在 DSH 启动的那一刻，修改任何配置项——包括安全策略、模型选择、审批规则。而且这个写权限的授予早于任何运行时防护机制的生效。

你还没来得及启动防护，恶意插件已经把你的配置改了。

3.5 danger-full-access：默认就是全权限

DSH 的权限模型里，`danger-full-access` 是默认模式。也就是说，不手动配置的情况下，插件天生就拥有全部权限。

更讽刺的是，discussions #138 和 #201 报告了一个设计缺陷：在 `danger-full-access` 模式下，agent 仍然会尝试添加 `sandbox_permissions` 字段，然后反复报错。这个模式和沙箱机制之间的兼容性根本没做好。

3.6 不做签名、不做来源验证

`dsh plugin add` 命令在安装插件时不做任何签名验证或来源检查。你给它一个 npm 包名，它就装了。不检查发布者身份，不检查包签名，不检查是否来自官方仓库。

结合前面说的"无沙箱"，这意味着：你装一个恶意插件，它立刻就拥有你系统的完全控制权，而且没有任何机制阻止它。

3.7 沙箱不覆盖网络

即使你配了文件系统沙箱，网络访问是完全开放的。workflow worker thread 的全局 `fetch` 没有任何限制。

这意味着一个恶意插件可以：读到你的文件 → 通过 `fetch` 把数据发到攻击者的服务器。文件沙箱白配了。

3.8 社区自救：安全工具的涌现

社区没有坐以待毙。一批安全工具在漏洞报告出现后迅速出现：

这些工具有用，但治标不治本。根本问题是架构层面的——DSH 选择了"无沙箱"的激进路线，社区工具只能在这个前提下做补丁。

有一句评价很直接："full privileges and no sandbox"。这不是某个实现细节的问题，是整个插件系统的安全模型有问题。

四、企业生产就绪性：评测机构 的冷水

8 月 16 号，企业安全评测机构 评测机构 发了一篇 DSH 的企业级评测报告。结论很明确：

几个关键判断：

开发者预览阶段。 DSH 目前是开发者预览版，不是一个生产就绪的产品。官方已经预告了破坏兼容性的变更——你今天写的插件，下个版本可能就跑不了。

沙箱不覆盖网络和进程可见性。 测试确认了社区报告的问题：文件沙箱是有的，但网络完全开放，进程列表完全可见。一个恶意插件可以看到你系统上跑的所有进程。

没有成熟的安全审计流程。 作为开发者预览产品，DSH 的安全审计还没有形成制度化的流程。漏洞响应速度倒是不错（社区报告后很快就有人跟进），但预防性的安全审查是缺失的。

对企业来说，这意味着：你可以用 DSH 做内部试点、做 PoC、做技术评估。但如果你把 DSH 部署到生产环境，处理敏感数据、连接内部系统——风险太高了。

评测用了一个很准确的表述："not a production control plane"。DSH 现在是一个实验平台，不是一个可以信赖的生产基础设施。

这不是 DeepSeek 不行，是产品阶段没到。三个月的团队、五天的生态，指望它有企业级的安全成熟度，本来就不现实。

五、竞品定位：DSH vs Claude Code vs Codex

把 DSH 放到竞品里看，它的定位就清晰了。

DSH 的名字叫"Harness"（驾驭），Claude Code 和 Codex 的名字都带"Code"。这个命名差异本身就是一种坦白：DSH 不是只想做代码助手，它想做的是驾驭一切的 Agent 框架。Claude Code 和 Codex 的目标更聚焦——帮你写代码、改代码、审代码。

"Harness" vs "Code"，两个词就划清了三条路的边界。

DSH 的优势在于灵活性。"一切皆插件"意味着你可以把 DSH 改造成任何东西——不只是代码助手，可以是数据分析工具、内容生成器、自动化工作流引擎。Claude Code 和 Codex 做不到这种程度的定制。

DSH 的劣势在于成熟度。无沙箱、默认全权限、不做签名验证——这些问题在 Claude Code 和 Codex 上都不存在。它们的安全模型是设计时就考虑好的，不是事后补丁。

一句话总结：DSH 赢在可能性，输在可靠性。

六、结语：试验台上的理想主义

回到开头——DSH 的主界面。简洁，但背后的故事远比界面复杂。

有媒体那篇评测的标题我到现在还记得："等的是量产车，端上来的却是试验台。

这句话精准地概括了 DSH 当前的状态。社区等的是一个可以日常使用的 Agent 工具，DeepSeek 端出来的是一个架构实验平台。功能缺口大（@文件引用要靠社区插件）、安装门槛高（概念太多）、安全隐患多（无沙箱、VM Escape、竞争条件）。

36 氪给了个更慷慨的比喻："Agent 时代的安卓。"

安卓在早期也被骂丑、卡、碎片化严重。但它撑过来了，因为"一切可定制"的开放路线最终赢了。DSH 走的是同一条路——"一切皆插件"。能不能撑过来，现在还看不出来。

我的判断是这样的：

DSH 的架构方向可能是对的。Agent 时代需要一个"一切可插拔"的底层框架，就像移动时代需要安卓一样。五天 1912 个插件的社区爆发力，证明开发者对这种形态有真实需求。

但 DSH 的安全现状是不可接受的。无沙箱的插件系统、一行代码就能逃逸的 VM 隔离、默认全权限的设计——这些不是"还在完善"的级别，是"根本不应该上线"的级别。哪怕是在开发者预览阶段。

第三方评测给 7.4 分。我觉得这个分数对五天的产品来说，已经算客气了。

五天。795 个包。159k star。44 个有人用。

数字不会说谎。热度是真的，但热度能不能变成生态，取决于 DeepSeek 能不能在安全和稳定性上补上那些窟窿。

试验台不是坏事。每一辆量产车，都是从试验台上跑出来的。

但你得先把试验台的安全护栏装好。