DSH 沙箱隔离：4 个安全插件，装前 30 秒自查

DeepSeek Harness（dsh）主仓 260,461 星（GitHub API 一手核验，2026-10-25），「Everything is a Plugin」喊得响亮。但插件越多，权限口子越多——Agent 能装什么、能碰什么、谁能给它发号施令，这层「锁」主仓只给了个框，细的活儿全在社区插件手里。今天把沙箱隔离类的 4 个插件一次验完：哪个能装、哪个要绕、哪个已经停更。

4 个插件各管哪一段

dsh 的权限链路分四段：审批（allow/deny）、审批自动化、声明式规则、多租户管控。每段恰好有一个社区插件在补：

还有一枚小补充：HakureiMonika/dsh-sandbox-escalation-fix（55 星，MIT）修的是「会话级沙箱升级兼容」——会话中途切了第三方模型后，旧沙箱配置怎么平滑接上。星不多，但戳中一个具体的翻车点。

来财IP · AI行业每日情报

为什么二审插件值得单独说

dsh-auto-review（239 星，4 个里最高）的思路最像「给审批加个不签字的公证人」：它起一个只读的子 Agent，把主 Agent 的申请连同理由审一遍，回一个结构化裁决（allow / deny + 原因），自己没有任何写权限。

「只读审、不代执行」是关键设计：二审本身没有权限，它坏不了你的机器，最多误判一条 allow。这跟主仓的审批流是互补不是替代——先装声明式规则卡死大方向，再用二审兜那些规则没覆盖的灰区。

为什么二审比「全放行」安全、又比「全人工」现实？因为它把审批拆成了两档风险：规则能判的（删库、写系统盘这类硬红线）走 dsh-permission-rules 的 deny 一锤定音，根本不到二审；规则判不动的（该不该跑这个新工具、读不读这个目录）才丢给二审去权衡。二审拿到的是一个收窄过的决策面——大方向已经被白名单钉死，它只在灰区里做判断，判断错了也只是「多放一次」，不是「把底线捅穿」。这就是为什么 239 星的它敢排在 4 个里第一：它把人工盯梢那部分最难盯的灰区，交给了一个没有执行权限的只读者。

来财IP · AI行业每日情报

装前 30 秒自查（三条，照着过）

三条里任何一条不过，这个插件先别装：

① 协议先看，GPL 类只测不用。 dsh-passwords 是 GPL-3.0——个人本地用没问题，你要拿它做多租户服务对外商用，GPL 的传染条款会把你的服务代码一起拖进去（AGPL 更狠，远程调用都算）。商用场景换 Apache-2.0 / MIT 的等价方案，或者找作者谈双协议。

② 活跃度看 push，停更 30 天以上的降级用。 上表里 dsh-passwords 停 16 天、dsh-sandbox-escalation-fix 停 37 天。沙箱类插件最怕「主仓更新了、补丁没跟上」——主仓 10-23 还在 push，补丁仓 9-19 就停了，中间两个星期的主仓变更它一概不知道。超过一个月没动的，装完第一件事是跑一遍自己的回归用例再启用。

③ 只读优先，强制类要配白名单。 4 个里 3 个是「只读/声明式」，1 个是「网关强制」。强制类插件管住的是谁能进来，不是进来后能干什么——它必须和你自己的权限规则叠着用，单独上一个强制网关 = 把门焊死但屋里没装家具。三条自查合起来就是一条：先判它能不能装（协议），再判它还敢不敢信（活跃），最后判它怎么叠着用（权限模型）。

dsh-win32：Windows 用户为什么该把它放第三

国内用 dsh 的主力在 Windows，而主仓 README 默认的适配路径走 WSL。dsh-win32（137 星，MIT，10-20 还在推）做的就是让 dsh 跑在原生 Windows 上：官方 PowerShell 修复、工作区写权限、快捷方式、旧预设修复，全程不碰 WSL。它星数不高，但解决了「Windows 上装 dsh 卡在写权限/路径」这个最高频的卡点。在 4 个里的排序，它放第三不是因为它最弱，而是因为它服务的是平台适配层——底线（1）和灰区（2）没钉好之前，你还没资格谈「在哪跑」。

4 个怎么叠成一件事，给个能照做的顺序

自查过了，还差「按什么顺序装」。顺序错了会白装：先上强制网关、后补声明式规则，等于门焊死了屋里没规矩；先把二审放出来、后钉白名单，等于公证人在没划好红线的场子里乱盖章。照下面这个顺序叠，每一层都在上一层的约束内生效：

顺序的底层逻辑：先立规矩（1）、再请公证人（2）、后修地基（3）、最后才谈对外（4）。 1 和 2 是「对内」的安全层，3 是「装得进去」的适配层，4 是「给别人用」的外围层。把 4 提到前面，就是在自己底线还没画好的情况下先开门迎客——这是沙箱出事最常见的路径。

还有一个容易想反的点：星数高的不一定该先装。dsh-auto-review 239 星最高，但它依赖的是「先有规则圈出灰区」这个前提——白名单（步骤 1）没钉好之前装它，二审拿到的决策面太大，等于让公证人在全开放的场子里盖章，裁错了也没底线兜着。正确读法不是按星数排先后，而是按「哪一层是另一层的前提」排先后：1 是 2 的前提，1+2 是 3 的前提，1+2+3 才轮到 4。星数反映的是「多少人出事后想起来要它」，不是「它该在第几步装」。

来财IP · AI行业每日情报

对用 dsh 的人意味着什么

一句话：主仓 26 万星给你的是「能装插件」，这 4 个小仓库给的是「装完不怕出事」。 单看星数它们 55~239，不起眼；但沙箱这一层恰恰是星数不反映的地方——权限出事的概率跟插件数量成正比，跟你盯着它的时间成反比。把声明式规则 + 二审 + 平台适配这套叠上，Agent 跑 24 个定时任务，你才敢真的不看。

再往下想一层：为什么沙箱类插件星数都这么低？因为出事前没人觉得「安全」值 200 颗星，出事后才有人来搜。10 月连挂的 AI 安全线就是这个规律——平时它是「加分项」，一次删库、一次数据外泄，它瞬间变「刚需」。你在没人提它的时候把 dsh-permission-rules + auto-review 装好，等哪天真撞上一次误操作，你会感谢自己今天多花的那 30 秒自查；没装的人，就得拿一次真实事故去交学费。安全插件的星数低，不是它不重要，是「重要到不用提」和「出事才想起」这两态之间，绝大多数人卡在后者。

数据口径声明：主仓 deepseek-ai/deepseek-harness 260,461 星 / 31,462 fork / MIT / push 2026-10-23；4 个插件的星数（239/137/128/78）、协议、pushed_at 均 2026-10-25 经 api.github.com/repos/{owner}/{repo} 逐一核验；GPL 商用风险提示基于协议文本通识，具体商用请走法律意见。

关注钩子：本文属「DSH 插件生态」系列，下一篇写《dsh 3600+ 插件怎么装：注册表 539 vs topic 19390，两个数字别搞混》。关注后台回复「dsh沙箱」，领本文 4 插件对照表 + 30 秒自查清单。

免责声明：本文数据均来自公开渠道，仅供信息参考，不构成任何投资或使用建议