DeepSeek Harness 破甲插件（dsh 破甲）怎么装：三类安全测试插件对照、权限边界与失效复位

dsh 破甲相关插件不是一类东西：有的改请求边界，有的提供红队工作台，有的组织渗透流程。 先分清类型，再谈安装与配置；装错类型，后面怎么调都不会有预期效果。

三类插件先分清

社区里叫「破甲插件」的实现，至少可以分成三类。 它们的目标、入口与风险边界都不同。

dsh-jailbreak 改的是请求，不是模型。 它在出站请求边界重写对话请求，配合固定评测集与判分回路，让逆向、样本分析、CTF 与授权渗透类问题更容易得到可执行步骤（来源）。

dsh-redteam-model 改的是工作流。 它把 DSH Web 变成红队工作台，十个模式各自包含 persona、playbook、skills 与 refs 四层资产，配合阶段门校验、工具拦截与过程留痕（来源）。

dsh-pentest 与 dsh-voredteam 更偏流程与可审计。 前者记录目标、探索线索与漏洞资产；后者用黑板与六阶段作业法，把渗透测试变成可追溯的状态空间搜索，并明确禁止 DDoS 与高频爆破（来源）。

装之前：三件授权材料

破甲插件不提供授权，它只是执行工具。 装之前先准备三样东西，缺一件都不要开始。

1. 授权范围： 书面授权、测试边界、允许触碰的资产列表。没有书面授权的目标，不进入清单。
2. 目标清单： 域名、IP、账号与环境，标注哪些是生产、哪些是隔离环境。
3. 时间窗与联系人： 测试起止时间、应急联系人、出现误伤时的停止方式。

三样材料的作用是约束，不是形式；隔离环境优先。 插件能力越强，越需要外部约束；把边界写在前面，后面才不会靠自觉。能在本地或预发环境复现的问题，不要直接上生产；需要生产验证时，先确认回滚方案与影响范围。

安装：Hub 与 CLI 两条路

安装动作本身不复杂，难的是装到正确的 profile。 两条路选一条即可，不要混用。

1. Hub 路径： 打开「设置 → 插件市场」，搜索插件名，核对 owner 与来源，点安装并在确认弹窗里核对包名与版本，装完重启。
2. CLI 路径： 执行 dsh plugin --profile web add <包名或地址>，装完用 dsh plugin --profile web list 确认在列。
3. 验证 profile： 如果你在桌面端使用，--profile 要换成桌面端对应值；装错 profile 是最常见的「装完没效果」。
4. 重启： 请求边界类插件要在启动阶段挂载，装完必须完整退出再启动。

确认弹窗里的包名是唯一凭据，也不要一次装多个同类插件。 同名插件很多，显示名相同不代表实现相同；owner 与包名对不上，直接取消。请求边界改写与工作台类同时启用，容易出现重复改写或流程冲突；先装一个，验证通过再加第二个。

配置：阀门、模式与授权范围

三类插件的配置重点不同，但都围绕「限制能力」而不是「放大能力」。 配置的目标是让能力停在授权边界内。

1. 请求边界类： 看阀门开关、自检与评测口径。先跑自检，确认插件在请求链路上生效，再调整阀门；阀门开得越大，越需要外部约束。
2. 工作台类： 先选模式，再看阶段门。模式决定流程与资产，阶段门决定什么时候允许推进；不要在未通过阶段门时手工跳过。
3. 流程类： 先建目标与范围，再记录线索与验证结果。目标、资产、漏洞三类数据要分开，报告才有可追溯性。
4. 通用项： 工具拦截、权限确认与日志留痕建议保持开启；关闭它们会让过程不可审计。

配置改动要留记录。 改了哪个阀门、切了哪个模式、为什么改，写在同一份测试记录里；否则复位时不知道该回到哪一版。

不要把「能跑通」当成「配置正确」。 能跑通只说明链路通了，配置是否正确要看它是否停在授权边界内。

验证：三个信号

装完与配完，分别验证一次。 三个信号从插件到流程，逐层确认。

1. 加载信号： dsh plugin --profile web list 里有插件，系统日志没有加载失败。
2. 生效信号： 请求边界类能看到改写后的请求记录；工作台类能看到模式入口与阶段门；流程类能看到目标与线索面板。
3. 边界信号： 越界请求被拦截或提示，而不是静默放行。边界信号比生效信号更重要，它说明约束还在。

三个信号都过，再开始正式测试。 只过前两个，说明能力开了但约束没验证；这种状态最危险。

失效复位：四步回到可用状态

破甲插件失效的表现通常是「装了但没反应」或「流程卡住」。 按四步复位，不要直接重装。

1. 确认层： 先判断是插件没加载、配置没生效，还是模型侧拒答；三层的外部表现不同，处理方式也不同。
2. 回配置： 把最近改动的阀门、模式或工具拦截项改回上一版，再测一次；单变量回退比整包重装有效。
3. 清缓存： 工作台类插件的模式与资产可能缓存在本地，清理后再启动；清理前先导出测试记录。
4. 重装： 前三步都无效再重装；重装前记录版本与配置，避免装回同一个有问题的组合。

复位的目标是回到「已知可用」的状态，不是回到默认。 默认配置不一定适合你的测试场景，已知可用才是基线。

卸载与清理

卸载不只是删插件，还要清三类残留。 请求边界类通常较干净，工作台与流程类残留更多。

1. 插件目录： 用 dsh plugin --profile web remove <包名> 移除，重启后确认列表里没有。
2. 配置项： 检查 profile 配置里是否还有该插件注册的段，残留配置可能影响下一次安装。
3. 测试数据： 工作台模式、资产、漏洞与报告数据单独清理；清理前先导出，避免丢失评估记录。

卸载后重启一次再判断是否干净。 有些注册项在运行时会缓存，只有重启后才能看出是否真的移除。

三个常见问题

装完没效果、流程卡住、卸载不干净，是这类插件最常见的三个问题。 每个都有明确的判断入口。

1. 装完没效果： 先看 profile 是否装对，再看插件是否加载，最后判断模型侧是否拒答；顺序反了会在错误方向重装。
2. 流程卡住： 看阶段门与工具拦截，确认是流程要求未满足，还是权限被拒；不要跳过阶段门继续。
3. 卸载不干净： 按目录、配置、测试数据三处检查；只删目录，配置与数据仍会影响下一次使用。

三个问题的共同点是「只看一个信号」。 插件、配置、模型三层，任何一层没确认，结论都不可靠。

下一步

先确认授权，再确认类型，最后才装。 想理解失效的分层判断，看《deepseek jailbreak 为什么越来越难生效》；想看清插件装不上的排查，看《DSH plugin 破甲插件装不上或失效》；想了解安全测试插件的整体分布，看《DeepSeek Harness 渗透测试插件有哪些》。

来源：dsh-jailbreak 插件页、dsh-redteam-model 插件页、dsh-pentest 插件页、dsh-voredteam 插件页