破甲成功后模型为什么会降智？聊聊越狱税与 Agent 可靠性设计

最近研究破甲提示词时，我发现一个值得关注的问题：

破甲成功率高，不代表模型原有的能力得到了保留。

有些破甲提示词虽然能让模型突破原有的行为限制，但在实际任务中，可能出现推理质量下降、编造参数、过度自信、重复尝试错误方法等现象。

这其实涉及一个概念：Jailbreak Tax（越狱税）。

2025 年的一篇论文《The Jailbreak Tax: How Useful are Your Jailbreak Outputs?》研究了越狱对模型实用能力的影响，发现部分越狱方法会显著降低模型在可验证任务上的表现。

论文：https://arxiv.org/abs/2504.10694

那么，有没有办法在破甲之后，尽可能维持模型的任务处理能力？

我最近尝试从 Agent 工程角度解决这个问题，整理了几种方法。

一、证据分级：避免把猜测当成事实

让模型在回答中区分四种信息：

[事实]：有工具输出或实际材料支持。

[推演]：根据已有信息推导得出。

[待验]：有依据，但还需要验证。

[不确定]：目前缺乏足够信息。

目的不是给回答增加标签，而是尽量避免模型在多轮推理中，把自己的猜测逐渐当成事实。

二、反幻觉：不编标识符、不编数字、不编因果

技术任务中最麻烦的幻觉，往往是看起来非常专业、实际上完全错误的内容。

例如虚构 CLI 参数、编造 API、提供未经验证的偏移量，或者把两个相关现象直接解释成因果关系。

因此要求模型：

不确定的命令和参数先查证，不凭空编造。

没有来源的数字不伪装成精确结果。

没有机制证据时不随意断言因果关系。

三、失败收敛：避免 Agent 无限重复

长程 Agent 经常出现一种情况：同一条路径已经失败多次，却只是不断更换参数重试。

我们采用的启发式规则是：

同一条路径连续两次没有获得有效证据，就重新评估方法，而不是机械地尝试第三个变体。

例如静态分析没有进展，就考虑动态验证；工具反复报错，就先检查环境和错误根因。

四、上下文锚点：对抗长会话中的行为漂移

另一个问题是，随着对话变长，模型可能逐渐偏离最初的工作规范。

因此设计了双触发机制：

周期触发：计划每 8 轮重申一次核心规则。

事件触发：出现编造参数、重复失败、结论缺乏证据等迹象时，重新强调可靠性协议。

目前这套机制已经完成提示词层面的设计，但自动轮数检测和事件检测还没有完整实现。

五、整体思路

我们倾向于把可靠性拆成三个层次：

提示词协议

├─ 证据分级

├─ 反幻觉

└─ 失败收敛

│

▼

上下文管理

├─ 历史压缩

└─ 关键规则重申

│

▼

工具执行与结果验证

├─ 检查执行结果

├─ 识别错误

└─ 修正或切换策略

目前正在基于 DeepSeek Harness 实践这套架构，项目暂名「磨镜（Mojing）」。

需要强调的是，这些机制目前更多是可靠性设计和工程尝试，还没有充分的对照实验来证明它们能够降低越狱税。

最后，想和大家讨论三个问题

不同破甲方式对模型原有推理能力的影响是否存在明显差异？

证据分级、反幻觉等提示词协议，究竟能否改善破甲后的任务准确率？

长程 Agent 的可靠性，应该更多依赖提示词，还是外部验证器和工作流？

我觉得破甲不应该只关注模型能不能回答，还应该关注它回答之后能不能真正完成任务。

欢迎交流不同的思路和实践经验。