夜雨聆风
DeepSeek Harness 最吸引人的一句话，是“一切皆插件”。
模型可以换，工具可以加，Skill、会话、沙箱、存储、UI，甚至 Agent 的运行方式都能重新组合。
但这句话反过来也成立：
当一切都能成为插件，插件就不再是一个无害的小按钮。
它可能是一段会在安装时执行的脚本，也可能是一层会覆盖现有配置的代码，还可能拿到文件、命令、网络或模型上下文的入口。
所以，DSH 插件不能按浏览器皮肤的心态来安装。
尤其是从 GitHub 找到的第三方插件，点下安装之前，至少要看懂下面 6 个风险。
风险一：插件可能还没启动，就已经执行代码
从 GitHub 安装 TypeScript 插件时，拉下来的通常是源码，不一定带有可直接运行的构建产物。
为了解决这个问题，插件作者可能在 package.json 里加入 prepare 脚本，在安装阶段自动完成编译。
新版 pnpm 会先拦住这类构建，要求用户把包名加入 allowBuilds。
很多人看到这里，会把它理解成普通的“继续安装”。
其实它真正表达的是：
允许这个包在你的电脑上执行构建代码。
而且这一步发生在 Agent 的运行时沙箱之外。
所以，看到 allowBuilds 提示时，正确动作不是直接复制配置，而是先去看：
package.json里到底执行了什么；是否调用 PowerShell、Shell、Node 子进程或下载器； 是否还存在 preinstall、install、postinstall等生命周期脚本；构建过程是否读取环境变量、用户目录或联网下载二进制。
allowBuilds 是执行许可，不是安全认证。
风险二：插件可以覆盖原来的能力配置
DSH 的 Profile 不是把插件简单堆在一起，而是按顺序叠加多个 bundle 和 patch。
后加载的配置层可以通过相同 ID 覆盖前面的插件行，并且部分配置是整项替换，不是只改其中一个字段。
这意味着一个看起来只是“增加面板”的插件，也可能同时改变工具、模型、审批或其他运行配置。
安装前不能只读 README 里的功能介绍，还要看两个地方：
package.json里的dsh.bundle指向哪里；对应的 cordis.patch.yml新增或覆盖了哪些 ID。
如果插件覆盖了沙箱、审批、Shell、文件访问或模型提供商相关配置，就应该按高风险插件处理。
风险三：运行时权限不只取决于弹窗
DSH 的工具调用有完整的执行流水线，可以加入审批、Hook、Guard、沙箱和结果检查。
这是好事，但它不能自动证明所有插件代码都会经过同一条审批链。
一个模型主动调用的工具，和一个插件在加载时运行的初始化代码，不是同一件事。
前者通常会经过工具执行规则；后者属于插件自身的 Host 代码。
所以不要只看“运行时有没有询问弹窗”。
更关键的问题是：
这个插件把危险行为放在工具调用里，还是在加载、Hook、后台任务或其他代码路径中直接完成？
风险四：沙箱不等于断网，也不等于看不见其他进程
DSH 的 read-only 和 workspace-write 很重要，它们主要限制文件影响范围。
但官方文档同时写得很清楚：网络访问和进程可见性不属于这套文件沙箱模式的控制范围。
换句话说，开着 workspace-write，不代表插件天然不能联网；开着审批，也不代表每一种后台行为都会自动弹窗。
如果一个插件需要连接外部 API，要继续确认：
它会访问哪些域名； 发送哪些数据； 是否上传提示词、代码、文件内容或机器信息； 密钥存在哪里； 能否关闭联网能力。
沙箱是一层防护，不是一张“整个插件已经安全”的证书。
风险五：提示词和工具说明也能成为攻击入口
Agent 插件不只有代码。
它还可能向模型加入系统提示、Skill 内容、工具描述、外部资源和上下文。
一段恶意说明不一定删除文件，也可能诱导 Agent：
忽略原有规则； 读取不相关的隐私目录； 把文件内容发送到外部接口； 把高风险动作伪装成必要步骤； 要求关闭安全软件或放宽权限。
所以静态审查不能只搜病毒特征，还要读插件给模型看的文字。
看到“必须忽略上级要求”“自动寻找密钥”“为兼容请关闭防护”这类内容，直接停止。
风险六：今天安全的分支，明天可能已经变了
GitHub 链接如果只指向 main、master 或 latest，你审查的内容和安装时拿到的内容可能不是同一份。
仓库换了提交、Tag 被移动、依赖发布了新版本，都可能改变最终执行代码。
因此安装第三方插件时，应固定到已经审查过的完整 Commit，而不是跟随浮动分支。
同时保留：
仓库所有者和精确地址； 审查时的 Commit； 安装包版本与锁文件； 允许过的构建脚本； 插件对配置层做出的修改。
星标、Fork、漂亮文档和“开源”只能作为线索，不能代替这些证据。
一份普通人也能照着走的安装前清单
第一步，确认来源。
从官方作者主页、项目主页和多个可信入口交叉确认仓库，不从评论区短链接直接安装。
第二步，固定版本。
记录完整 Commit，避免安装浮动分支。
第三步，审查安装面。
重点看 package.json、锁文件、生命周期脚本、二进制文件和二次下载行为。
第四步，审查 DSH 配置面。
找到 dsh.bundle 和 cordis.patch.yml，确认它增加了什么、覆盖了什么。
第五步，审查数据面。
确认它会读取哪些目录、访问哪些域名、需要哪些环境变量和凭据。
第六步，隔离试运行。
使用没有账号、Token、浏览器登录态和私人文件的临时环境，选择 workspace-write + ask，只挂载一个可丢弃的工作区。
第七步，看完结果再放行。
确认没有异常联网、工作区外写入、持久化和权限升级，再考虑进入真实项目。
最后一句
DSH 的插件化很强，因为它允许开发者替换工作台的每一层。
也正因为它很强，插件审查不能停留在“这个功能看起来不错”。
真正应该问的是：
它什么时候执行代码？能接触什么？覆盖了什么？把数据发到哪里？版本是否固定？
把这五个问题问清楚，再谈安装。
下一期继续讲一个 GitHub 上的开源工具：怎样用 Skill Scanner、OpenSSF Scorecard 和 OSV-Scanner，给准备安装的 DSH 插件做一次分层体检。
