装插件之前,没人告诉你它跑在哪里

先说一个很顺畅的过程。

打开 DeepSeek Harness 桌面端，侧栏点「插件」，输入一个 npm 包名，点安装。几秒钟后，这个插件就出现在你的软件里了。

不需要命令行，不需要装 Node，不需要理解依赖树。页面上还能看到它的介绍和来源，也可以随时停用、卸载。

整个过程非常像 App Store。

这大概就是桌面端这次更新最舒服的地方之一。官方延续「一切皆插件」的设计：从一个小工具到整个交互界面，都能以插件的形式装进来。而按官方模型 API 用户口径统计，大约 60% 的 Harness 用户已经在使用第三方插件。

但我想说的不是"插件好不好用"，而是另一件更容易被跳过的事：点下那个按钮之后，这个插件会跑在哪里。

这个答案，官方文档里写得清清楚楚——只是写在大多数人不会去看的地方。

安装前，系统只回答五个问题

在真正安装之前，宿主会先去读一遍你输入的包名指向什么。这套流程在官方插件管理模块的文档里有明确描述：它向注册源询问，然后答复给你——

包的名称、版本、一句话描述、它是否声明为一个组合包，以及这个答复来自哪个注册源。

就这五项。

一切正常的话，安装界面会展示包名、一句话简介和版本，pnpm 的命令与输出折叠在「查看安装详情」后面。

也就是说，安装前系统告诉你的是"这个包存在、它叫什么、它是第几版"，而不是"它装进来之后会做什么"。

这五项里没有任何一项是关于权限或行为的。这不是疏忽，这就是这套机制目前的能力边界。官方文档在同一节里还留下一句更实在的话：

安装成功不代表模块一定能够激活。

三句写在官方文档里的话

接下来是三个机制层面的细节。它们都写在官方文档里，只是很少被引用。

第一句：已安装的插件代码，运行在宿主进程内，不受工作区沙箱限制。

原文是：

已安装的 Host 代码在宿主进程内运行，不受工作区沙箱限制。

这句话需要拆开看。你平时在会话里见到的那套沙箱，管的是模型：模型的文件写入和编辑，模型的 shell 命令。而插件是另一回事——它是你自己这台电脑上、这个软件进程里运行的一段代码。

所以"沙箱"这两个字容易带来一个不太准确的联想，以为它在保护整台电脑。它保护的是你交给模型的那部分操作。

第二句：连模型的沙箱，也只管文件，不管网络。

官方对沙箱 Bash 执行器的说明写得很直接：

模式只约束文件影响——网络仍不受限制，进程可见性因后端而异。

并且自我限定得更彻底：

限制只覆盖文件影响——不提供网络限制和统一的进程可见性保证，因此这些模式不是通用安全沙箱。

文件这一侧确实是有围栏的。比如 workspace-write 模式下，模型只能写入你指定的工作区目录和平台临时目录。这个机制是有效的。但如果你以为"我开了沙箱，所以它在联网和数据外发上也是被管住的"，那就属于过度解读了。

顺带说一句 danger-full-access：它不是"更宽的沙箱档位"。官方措辞是——它是有意绕过沙箱的显式无约束模式。

第三句：批准一次构建脚本，等于授权它用你的身份执行命令。

这条最贴近普通用户。

装插件时，pnpm 会拦下依赖的安装脚本，然后你会看到一个按钮：「允许这些脚本并重试」。

官方对这一操作的定义是：

授权按包名保存在当前 profile，允许以宿主用户的权限执行命令，并在再次安装失败后保留。

三个要点：它执行命令的身份是宿主用户，也就是你自己；授权是按包名持久保存的，不是一次性的；就算这次安装最后失败了，这份授权依然保留。

另外还有两处机制细节值得知道。一是桌面端目前不支持插件自动更新，升级需要先卸载再装新版。二是在"创造模式"下，Agent 可以通过插件管理工具替你安装插件，而这个工具的操作门槛是 danger-full-access 或逐次批准。

这个生态长得比治理快

把这些机制放在一起，再看这个生态现在的样子，会更有体感。

我在 npm 上做了几组查询（数据截至本文写作时）：

最后一行挺有意思：官方的插件市场还在规划中，第三方做的"帮你在 Harness 里找插件"的插件，一个月已经跑出近三万次下载。

还有一类现象值得单独提。npm 上已经出现了一批"元插件"——插件市场、插件管理器、插件发现工具、插件开发脚手架，它们自己都是插件。其中 dsh-plugin-marketplace 上月下载 5314 次，dsh-plugin-guide 5395 次，dsh-plugin-mgr 2012 次。

生态的娱乐化也同步来了：有人做换肤插件，有人做界面右下角的余额挂件。

同时，很多包的发布者字段显示为 GitHub Actions——意味着它们由 CI 流水线自动发布，你很难从 npm 页面上判断背后是谁在维护。

这些都不是"这个生态很糟"的证据。恰恰相反，一个还在预览阶段的产品能有六千多个插件，是很有活力的信号。但它的生长速度和治理速度，显然不在一个量级上。官方自己也在同一篇发布文章里说，要"推动插件 API 趋于清晰和稳定""建设官方插件市场"。这些是进行时，不是完成时。

落差是怎么产生的

我认为是图形界面把一句重要的警告给抹平了。

在命令行时代，你要装一个插件，敲的是 dsh plugin add <包名>。哪怕你不懂技术，那个终端窗口本身也会给你一点心理预警：我正在往系统里装一个全局的、权限不小、可能不会自动更新的东西。

现在这个过程变成了一次点击，界面还很亲切地告诉你"这是某某插件，版本 1.2.3，来自 npm"。

你获得的信息量，其实和命令行时代差不多；但你获得的谨慎感，少了很多。

这不是 DeepSeek 的问题。官方文档把这些机制写得非常详细，甚至比不少同类产品更透明。问题在于："讲清楚了"和"用户知道了"是两件事。 文档是写给开发者的，而这次桌面端更新，把用户群扩大到了不写代码的人。

装插件前的五个问题

与其劝人别装插件——这既不现实也没必要，60% 的用户在用，插件就是这个产品的核心价值——不如留下一张能用的清单。

第一，它的源码仓库能打开吗？ 插件页会显示来源。如果点过去是空仓库、README 只有一句话，先放下。

第二，最近三个月动过吗？ Harness 迭代很快，几个月不更新的插件大概率已经失效。而且记住，它不会自动升级，你装的是哪个版本就是哪个版本。

第三，它需要联网吗？需要读写文件吗？ 这个生态里绝大多数插件确实需要这两样，所以"需要"本身不是罪证。但如果一个纯本地的小工具要联网，值得多问一句为什么。

第四，它是"元插件"还是真功能？ 插件市场、插件管理器、插件指南这类包，本身不提供能力。装之前想清楚，你要解决的是"找不到插件"，还是"没有能力"。

第五，第一次先拿只读任务试它。 这是唯一一条能覆盖所有未知情况的建议：先让它在只读任务、测试目录里跑一遍，确认行为符合预期，再放进你的正式工作区。

还有一条铁律：不确定的插件，放在虚拟机或专用设备上试。 原因很简单——前面那三个机制已经说明，它不受你给模型设的那套沙箱约束。

写在最后

写这篇不是要说插件危险，也不是要质疑"一切皆插件"这个方向。我认同这个方向，六千多个包也说明了它的生命力。

我想说的只是：插件页给的那点信息——包名、版本、一句话简介——是用来帮你确认"有没有装错包"的，不是用来帮你判断"这个包安不安全"的。

这两件事在命令行时代很容易分辨，因为那时候你得自己敲命令。现在它们被藏进了同一个按钮里。

点之前，多看一眼它跑在哪里，就够了。

资料与口径

• DeepSeek Harness v0.2 预览版发布说明（官方公众号，2026-09-29）：用于核实"约 60% 官方 API 用户使用第三方插件""建设官方插件市场""推动插件 API 趋于清晰和稳定"等表述。
• 桌面端安装包内置文档 @deepseek-ai/dsh-plugin-manager、@deepseek-ai/dsh-client-ui-plugin-manager：本文引用的"安装前 inspect 返回的五项信息""已安装的 Host 代码在宿主进程内运行，不受工作区沙箱限制""构建脚本授权按包名持久保存""不支持自动更新"等表述，均出自此处。
• 桌面端安装包内置文档 @deepseek-ai/dsh-bash-sandbox、@deepseek-ai/dsh-fs-sandbox：本文引用的"模式只约束文件影响""不是通用安全沙箱""danger-full-access 有意绕过沙箱""策略围栏，而非内核边界"等表述，均出自此处。
• npm registry 公开数据（2026-09-30 查询）：dsh-plugin 关键词命中数、dsh 搜索命中数，以及 dsh-find-plugin、dsh-plugin-marketplace、dsh-plugin-guide、dsh-plugin-mgr 的下载量与版本信息。
• 本文讨论的是机制与使用建议，不声称发现任何具体漏洞，也不对任何具体插件作安全性判断。npm 数据与插件数量会持续变化，请以查询当日结果为准。