deepseek破甲 失效先分三层：DeepSeek Harness 的模型拒答、宿主拦截与提示词规则

在 DeepSeek Harness 里遇到 deepseek破甲 失效，先别急着改提示词，症状相同不代表原因在同一层。 模型策略、宿主规则与插件行为都会让一次请求看起来「没有反应」，但留下的证据位置完全不同。把三者分开观察，才能知道下一步该动哪里。搜索里常见的拼写变体 jaillbreak 指同一个话题，排查仍按模型 / 宿主 / 插件三层，提示词侧的写法可参考《deepseek 破甲提示词指南》。

模型策略：DeepSeek Harness 的拒答从哪里来

模型层的证据是它确实回了话，只是回的内容是拒绝或者回避。

判断模型层，先看它有没有真的回话，再看回的是什么。拒答通常语气完整、有解释，和连接超时、工具报错完全不同。看到这种文本，说明请求已经穿过宿主与插件，问题落在模型侧的判断。

不同模型的阈值并不一致，同一个提示在 A 模型被拒、在 B 模型可能正常。上下文长度、系统提示与对话历史也会改变判断，单次结果不足以定性。要确认是模型策略，至少换一次会话、换一个模型做对照。

模型拒绝不是错误，它是策略输出，因此重试同样的内容通常不会得到不同结果。继续堆叠提示词只会让上下文更混乱，甚至触发更严格的判断。此时更合理的动作是记录原始回复，确认策略边界，而不是把时间花在措辞上。

还有一种容易被误认的情况：模型确实回答了，但回答被后续处理截断或改写。用户看到的空白或短句，可能已经过插件过滤。判断模型层时，要以原始响应为准，而不是只看最终界面。

宿主规则：DeepSeek Harness plugin 拦住了什么

宿主层拦的是运行时动作，它的典型表现是根本没有模型输出，或者工具调用被挂起。

DeepSeek Harness plugin 在宿主侧管理审批、沙箱与工具权限，任何超出策略的文件写入、命令执行或网络访问都会被挡住。被挡住时，界面上可能只显示任务没有完成，看起来像模型不回答。真正的证据在审批提示与沙箱日志里。

工作区边界是最常见的触发点，写入工作区之外的位置会要求确认，未确认就停在原地。profile 策略也会限制可用工具，换一个 profile 后同样的任务可能突然可行。插件是否进入 ACTIVE 状态，同样会表现为工具不可用，条目状态可以到 DSH Plugin Hub 核对。

[approval] write /etc/hosts -> pending
[sandbox] exec "curl ..." -> denied (network)
[plugin] dsh-purge: inactive

排查宿主层时不要先改提示词，那等于在错误的层上加变量。先看有没有待确认的审批，再看沙箱拒绝记录，最后确认当前 profile 与插件状态。只要其中一项对不上，就应该先把它修好，再谈模型表现。

插件行为：DSH plugin 也会改变请求

插件不是透明的，它会在请求前后改写内容、注入规则或提前短路，因而也会制造「失效」的假象。

一个 DSH插件 可能在发送前拼接系统提示，也可能在收到回复后做过滤，还可能直接拦截某类工具调用。用户看到的最终文本，未必是模型原样输出的文本。把插件行为排除掉，才能确认模型层到底说了什么。

插件版本更新后行为变化很常见，尤其是提示词规则集类的插件。规则改了但没有应用、应用了但没有重建会话，都会让旧行为继续生效。表面上是破甲失效，实际是配置没有真正落地。

ruleset: custom-v3    applied: false
session: reused       model: deepseek-chat
plugin: prompt-guard  active

把插件临时停用是最快的排除法。停用后症状消失，责任基本在插件；症状不变，才轮到模型或宿主。停用前记下插件版本与配置，否则恢复时无法确认改了什么。

插件之间的相互影响也值得注意。两个都会改写系统提示的插件叠加，结果可能既不是 A 也不是 B。隔离 profile 里只启用一个插件做对照，能避免把叠加效应误判成模型策略变化。

把三层证据串起来：DeepSeek插件 排查的顺序

把三层串起来靠的是证据顺序，而不是猜哪一层最可疑。

先确认请求有没有到达模型，再确认输出是不是模型原文，最后确认规则与插件是否按预期生效。这个顺序的价值在于每一步都能排除一层，而不是同时在三个地方改配置。排查记录要写清楚每一步看到了什么，否则回头无法复现。

1. 模型策略：先看请求有没有到达模型。有返回，才谈得上模型策略；完全没有输出，就直接去看宿主审批与沙箱日志。有返回时把原始回复保存下来，区分策略性拒绝与工具错误。
2. 宿主规则：检查审批提示与沙箱拒绝记录，确认当前 profile 与插件状态。只要其中一项对不上，就先把它修好，再谈模型表现。
3. 插件行为：关闭可选插件，在隔离 profile 里复现同一请求，观察症状是否变化；再检查提示词规则是否已应用，并新建会话再试一次，避免旧会话沿用缓存。

三层证据只有在同一时间窗口内对照才有意义，隔天再看日志，版本与环境可能已经变了。把请求时间、会话标识与当时的插件配置放在一起，才能解释为什么同一提示在前一次成功、后一次失败。把这些字段固定下来，复查时才有可比性。

如果三步都指向同一层，结论才站得住。只做一次对照就下判断，很容易把宿主拦截误认成模型拒答，因为两者在界面上都表现为没有结果。多花十分钟对齐日志，能省掉后面几个小时的无效调整。

12:01 request sent        -> model responded (refusal)
12:04 plugin disabled     -> response unchanged
12:07 ruleset applied     -> refusal persists

记录里要保留版本号与会话标识，因为它们决定了结论能否复现。同一句提示在不同版本上表现不同，是这类评估里最常见的干扰项。没有版本信息的结论，只能算一次观察，不能算证据。

评估边界：DeepSeek Harness 里的授权与记录

评估的边界先于结论，超出授权范围的测试不属于技术排查。

deepseek破甲 是围绕拒答与提示词规则的受控话题，不是官方功能名。它应该在自有环境或书面授权范围内进行，并与生产环境隔离。越过这条线，讨论的就不再是技术问题。

隔离不仅是合规要求，也是实验设计的要求。生产环境里的插件、profile 与数据都在变化，变量一多就无法归因。用一个干净的 profile 复现，结论才可能稳定。

测试结束后要清理会话与临时配置，避免把实验性规则带进日常使用。留在环境里的旧规则，会在下一次排查时变成新的干扰。清理动作本身也应写进记录。

最后，把结论写成可复查的条目，而不是一句「某模型会拒绝」。写清楚环境、版本、提示范围与观察结果，别人才能判断它是否适用于自己的场景。DeepSeek Harness plugin 的策略会变，记录也会过期，定期复查比一次定性更有意义。

来源：dsh-purge 插件条目、插件与生命周期、沙箱。