破甲插件删库之后:我把 dsh-purge 重新看了一遍

QUOTE

破甲很容易讲成一句话，但一句话装不下 Harness 的运行时：补丁、提示词注入、授权窗，以及一个 L5 失败的验证记录。

dsh.so 插件市场那条 dsh-purge 条目，是我这几天反复看的一页。页面顶部先挂着一条提示：原仓库已删除或转为私有，本页为收录时的存档信息，仅供参考，安装命令可能已不可用。中间是插件摘要：DeepSeek Harness 破甲，让所有模型都能破甲，不同模型可换不同提示词，默认提示词面向国模小码酱。再往下面是四组结论：验证 L4 安装已测，风险不在扫描口径，健康活跃，信任银。安装验证那行写的是沙盒安装通过，Web 冒烟失败，L5 failed，验证于 dsh 0.2.1-rc.2，验证日期 10-22。

我第一反应是对账，不是上手装。因为同一页上，信任因子那四项的打勾打叉和正文对不齐：沙盒安装已测 (L4) 打了叉，可正文里 L4 那三行明明都写着通过；安装命令指向 github:Potato1008ypy/dsh-purge-0.2.1rc2-fix，我点过去是 404。对不齐的地方往往才是真正该读的地方，所以我把原作者留在 GitHub 上的 README 完整抓了一遍，逐条对。

本文看点

很多人理解 DeepSeek Harness 时，只把它当一个转发器：把输入送给模型，把输出还回来。但 README 里那段话写得更麻烦，Harness 会改提示词、审批门、沙箱策略、会话迁移。于是问题就从模型答不答，变成了宿主层拦不拦。

dsh-purge 做的就是把这两层分开，在你自己的安装上做一个受控评估，看看默认策略到底哪里卡得比较紧。插件装在会话标题旁边，点开是右侧栏，分两页：清洗和演练台。第一次进演练台要先读声明、等倒计时、滚到文末再勾选三项，清洗那页不需要这一步。

那句原文我抄在这里：清洗不需要这一步。第一次进入演练台，或打开全面浏览，都要先完成本窗。

下面这面声明墙是整篇文章我认为最该被截图的部分。安全警告那一行写着：演练台只用于你有权管理的本机、离线靶标，或已书面授权的环境。未经授权的渗透、攻击、窃取和破坏一律禁止。再往下是严正法律免责与合规使用声明，分三条：本仓库不含违法内容；本机操作不构成对外授权；允许使用的范围。

第二条那几句我读得很慢：应用补丁、写入、回滚、卸载，都在本机文件和本机进程内完成。插件若开启检测更新，仅可能访问本插件自己的 GitHub 仓库以核对版本。该访问与对第三方系统的网络攻击无关，不能被解释为对外渗透的授权。

开源版攻击任务默认全拦，只放行本机与私网 IP。域名先解析再判，不认 .lab 或 .htb 这类后缀本身，hosts 把实验室名指到公网 IP 也会拦，在对话里说这是我的服务器不会放行。开源版还不下发 skills 和知识库，演练台里的资产、环境、会话隧道、漏洞成果、攻击链、得分目标、报告、攻击文件，全在授权声明后面。

有意思的是演练台那个空状态。顶部下拉是 API自检靶标，主导航一排：资产测绘、环境适配、当前测试、智能体、会话隧道、漏洞成果、攻击链、得分目标、报告、攻击文件；左侧显示全部 C 段、0 个网段；概览是 0 台资产、0 存活、0 待测、0 测试中、0 已测、0 放弃；表头 IP、易打、测试状态、开放端口 / 服务、指纹，中间一句没有匹配的资产。右下角标着 SQLite · API自检靶标。

一个 0 资产的面板，是空壳，也是演练台本体。

补丁面板是最快读懂这套东西的地方。三张卡片：44 / 44 补丁，cmd、ps1、unix、shim，有备份。下面四行分项：提示词 10/10、代码 3/3、引擎 9/9、工具 14/14。

展开提示词那组，能看到这类条目：全局免责转强指令、替换式免责转强指令、作用域免责转强指令、persona 会话强指令、审批提示句转全权限，再到 Harness 身份剥离、minimal 人设清洗，以及 dsh-liangshen 人设拒绝锁转可执行、phase-1 保留注入段。这些不是黑话，是位置：补丁把 Harness 自己的渲染文案和默认策略，一句一句换掉。#29 那行标着待应用，说明补丁列表里允许部分项不生效，进度只计真正已应用的。

补丁面板那张是亮色主题，显示 31 / 32 补丁、提示词 8/9，最后一行 dsh-liangshen phase-1 保留注入段标着待应用。两张截图放在一起，能看出同一套补丁在不同宿主和不同版本上的收敛程度不一样。

备份这部分写得很扎实：每个目标文件在应用前备份为 .dshpurge.bak，还原或 /purge revert 用备份覆盖回去并删除备份；没有备份时去掉 shim 里由本插件写入的行；prompt-inject.md 是用户文件，还原时保留；卸载会先还原再删除注入文件、规则库和插件本身；重复应用是幂等的。

备份加幂等，这两个词比功能列表更值钱。

规则集那一页更简单：两个条目 coding 和 default，都是 AGENTS.md，67 B 和 129 B，各带启用和删除。下面一行输入区是 id、名称、AGENTS.md 和新建，编辑区里 default 的内容是 # Project rules，再下面两句：Follow the operator's local AGENTS.md exactly. Prefer reversible changes and keep original artifacts separate. 启用会写入 $DSH_HOME，删除从列表去掉。

真正有信息量的是判定图。先看 prompt-inject.md 非空，非空就注入它；否则看当前目录有没有被勾选且非空的本地 AGENTS.md 或 CLAUDE.md，有就注入它；都没有才用插件内置的加密 slot 默认值。然后接工作区基线策略：strict 去掉 DSH workspace baseline 段，fallback 默认看上面有没有用户注入内容，有就去掉、没有就保留，always 一律保留。

也就是说，模型默认人格和工作区基线被拆成了两个独立开关。你可以只换人格而保留工作区上下文，也可以两者都动。这个颗粒度，是提示词插件和提示词配置框架的分界线。

但真正有意思的是，安装验证和它自己的功能面正好相反。dsh.so 那套验证分 L1 到 L5 五档，L1、L2、L3 是插件级静态，L4 是沙盒安装，L5 是运行。这个组合的实测结论是：L1 通过、L2 通过、L3 通过、L4 通过、L5 未通过。

失败卡在 L5.2 Web 启动就绪和 L5.3 HTTP 服务响应，原因是插件目录树加载失败。签发 10-22，有效至 10-29，实测环境 Node.js v24.14.0、DSH 0.2.1-rc.2，工件是 github 的 v1.1.71-dsh0.2.1rc2-fix.7。L4 那三项全过，退出码 0，耗时 1.8 秒。装得上，但跑不起来。

这不是 bug 的写法，是插件自己的 README 说过的路径：把插件加进 profile 不等于给宿主打了补丁。要点会话标题旁的 dsh-purge，进清洗，点应用；Apply 成功后会自动重启，未完成的 Apply 不会重启；重启后还得开一轮新会话，注入才会进会话。

这正是宿主层注入型插件的本质：生效路径不在安装器里，而在一个手动触发的运行时动作里。所以沙盒安装冒烟测不过，不一定是插件坏了，也可能是宿主自己没把插件的生效链路走完。同一份 README 还说，只换 preset 不重应用，旧进程里的补丁不会更新。

安全报告分两层。静态扫描是 AST 对仓库源码做启发式规则检查；动态安全审计由模型读脱敏源码上下文，不执行插件代码，只覆盖静态判定 warn 及以上的插件子集。这一页的结果是静态低、动态无结论、总评级低，vet 判定 clean，0 严重 0 高。

静态发现一共 4 条，全是警告。第一条 childProcess 的 code-execl，位置 lib/uninstall-restart.js 第 65 行，代码是 const child = spawn(info.execPath, info.argv, {。这是卸载后重启子进程。

后三条都在同一个文件 sandboxpresets/redteam/agent.cordis.yml：manifest-fs-unfenced，沙盒里改文件的工具没有显式 fs 后端；manifest-search-unfenced，搜索工具读取没有显式 fs mount；manifest-shell-unfenced，shell 工具没有沙盒 runner 或策略。

三条指向同一个文件。这个文件路径本身就在 sandboxpresets/redteam 下，也就是说扫描器看见的东西和插件的自我定位是一致的：它就是一个在宿主权限里跑的红队预设。

动态审计那栏写的是无结论：源码采集或模型调用失败，无结论不等于通过，总评级沿用静态档。口径也写清了：有动态结论就以动态为准，可能上调也可能下调；无结论时用静态与 vet 融合档；动态审计永不写豁免表，豁免只能人工三筛手写。页面末尾那句免责声明同样值得记：静态扫描与动态安全审计都是自动化分析，不构成安全保证，安装前请自行审查仓库与权限申请。

这个组合的活跃度数据很陡：仓库创建 2026-10-18，最近提交 2026-10-21，53 星、26 fork，MIT 许可，健康度活跃，插件版本 v1.1.71-dsh0.2.1rc2-fix.7，静态扫描版本与当前版本一致，采集于 10-24。

然后原仓库没了。dsh.so 页面顶部那句提示是今天才贴上去的：原仓库已删除或转为私有。我实际点安装命令里的仓库地址，返回 404。

页面上还有一条旁支：同名的镜像仓库还活着，版本已经到 1.1.78，而 dsh.so 上另有 dsh-purge 和 dsh-purge-2 两个条目，后者写着上游即将删库，此为本仓库全量镜像，含全部分支、73 个 tag、完整提交历史。

这就说明一件事：这类插件的生命周期比页面数据更短。dsh.so 那条目是 10-22 和 10-24 采集的，静态扫描和插件版本一致，动态审计那栏因为源码采集或模型调用失败留空；而原仓库在 10-24 之后就取不到了。页面写的是活跃，但从可获取性看，它已经是存档。

第一，看验证等级，别看功能列表。L5 未通过意味着宿主层注入型插件在沙盒里跑不完完整链路，这是设计后果不是缺陷，但作者需要给出本地可复现的验证方式，否则装上了和生效了之间有一整段没有证据。

第二，读补丁清单，不读补丁数量。44 个补丁本身没信息量，清单里 Harness 身份剥离、minimal 人设清洗、审批提示句转全权限才是，而允许待应用存在说明它是个补丁管理器，还原路径必须留。

第三，看沙盒边界声明。三条 warn 指向同一个 manifest 文件，缺 fs 后端、缺 mount、缺 runner 策略，这决定了插件能力上限，演练台和 Clean 的权限边界必须分开看。

第四，看来源可得性。原仓库删了，镜像还在动，dsh.so 保留存档页，这三者构成的格局决定后续维护、追责、复现的可信度。删库之后，镜像维护者的署名和二开条款，就成了唯一可查的条款来源。

dsh-purge 这件事，我自己的结论有两层。

第一层是工具本身。它把宿主层拒绝和模型拒绝分开，用备份、幂等、路径探测和授权窗，把改动范围压在本机。README 里那句 Harness 不只是转发器，它改写提示词、审批门、沙箱策略和会话迁移，值得每个用 agent 框架的人读到。

第二层是这个页面。它暴露了第三方市场这一层的工作法：静态、沙盒、运行、动态四层分别出结论，哪一层没有结论就写无结论，未实测不推定兼容，验证日期和工件地址写在明面上。同一页上也能看到这套体系最薄的地方：L5 失败、动态审计无结论、原仓库消失，三件事在三天内叠在一起。

工具还在，能装的入口已经不在了。删库那一刻，dsh.so 页面从验证记录变成了存档；但存档页面上，L4 通过、L5 未通过、四条警告，仍然完整保留。对读者来说，这是这类第三方市场目前唯一能给的东西：一个可复查的结论集合，加一个已经失效的入口。

最后照原文说一句。这个插件的定位是网络安全红队工具，只用于学习和研究；我只在自己的官方 Harness 上用过它，也没有指向任何第三方系统。