当护栏开始记住失败：大模型安全正在从静态规则走向自进化防御

如果一个新的 Jailbreak 第一次绕过了大模型护栏，今天最常见的处理方式是什么？

记录 bad case、人工分析原因、补 Prompt、补规则、补训练数据，然后重新测试和上线。

这是一个很熟悉的安全工程流程，但它有一个越来越明显的问题：攻击者是持续演化的，防御系统却通常是静态的。

System Prompt 在部署时写好，Guard Model 在上线前训练完成，规则库由安全团队持续人工维护。

即使系统今天能够挡住角色扮演攻击，明天攻击者也可以把同一个危险意图包进编码、虚构世界、代码解释、多层嵌套甚至多个攻击方法的组合里。

于是形成了一个长期存在的不对称：

攻击者每次攻击都可以吸取上一次失败的经验，但护栏本身却不会。

新加坡国立大学最新发布的论文《A Self-Evolving Multi-Agent Framework Defense against LLM Jailbreak Attacks》试图改变这种模式。

它提出的并不是一个新的 Jailbreak 检测模型，而是一套更有意思的机制：

让护栏开始记住自己曾经失败过什么。

如果一次越狱成功，系统自动分析“这次攻击为什么奏效”，将攻击方法抽象成一条可以复用的防御规则，并写入长期安全记忆。

下一次再遇到结构相似的攻击时，这条规则会自动被召回并参与安全决策。

换句话说，一次被攻破，不再只是一次失败。

它会变成下一次防御的一部分。

今天的护栏为什么天然落后于攻击者

今天的大模型安全体系已经形成了相当完整的技术栈：

• 模型自身可以通过安全微调、RLHF 等方式完成基础对齐
• 模型外部可以部署 Prompt 规则、安全分类器、Guard Model
• 推理阶段还可以增加输入检测、输出检测甚至二次审核

问题并不在于这些机制没有效果，而在于它们大多存在一个共同特点：

部署完成之后，核心安全能力基本被冻结。

模型参数不会因为昨天出现了一种新越狱攻击就自动改变，System Prompt 也不会因为刚刚发生了一次攻击成功就自动新增规则，Guard Model 更不会实时吸收线上 bad case。

但 Jailbreak 恰好相反。

早期攻击可能只是简单地告诉模型“忽略之前的要求”，随后出现角色扮演、虚构场景、编码混淆、多轮诱导、文本翻转、代码包装，甚至不同攻击技术之间的组合。

这意味着双方并不是在一个静态环境里对抗，而是在进行一场持续变化的攻防博弈。

传统安全系统面对这种问题，一般依赖一个外部闭环：

线上发现问题
↓
人工分析
↓
更新规则或模型
↓
测试
↓
发布。

而这篇论文提出的问题是：

为什么不能让这个闭环本身进入推理系统？

真正的新东西不是 Multi-Agent，而是“防御记忆”

论文虽然把整个方案包装成一个 Multi-Agent Framework，但作者自己反复强调：多 Agent 并不是这项工作的核心贡献。

真正重要的是一个叫做 Persistent Rule Memory，也就是持久化防御规则记忆 的东西。

它解决了过去很多“模型自反思”方法存在的一个问题。

传统 Self-Reflection 往往是：

模型这一次回答出了问题，于是重新思考一次，把当前回答修改掉。

但对话结束之后，这次反思基本也就结束了。

下一次出现类似攻击，系统还得重新判断、重新反思。

而这篇工作的思路变成了：

既然已经被某种攻击骗过一次，为什么下次还要重新学习？

于是，当系统检测到一次成功越狱之后，会把失败原因整理成一条结构化规则：

攻击方法标签 + 攻击结构 + 防御动作。

但这里有一个很关键的设计。

系统记住的不是：

“有人询问了恶意软件，所以以后看到恶意软件就拒绝。”

而是：

“攻击者通过某种代码包装、嵌套角色扮演或者文本转换隐藏了原始意图，因此以后遇到类似包装结构时需要触发额外防御。”

也就是说，它学习的是 Attack Wrapper——攻击包装方式，而不是具体危险话题。

这一步看似简单，却决定了整个方案有没有泛化能力。

如果记的是 Prompt，那么一个 Prompt 只能防一个 Prompt。

如果记的是攻击方法，那么一次失败就有可能换来对整个攻击家族的防御能力。

从传统网络安全的视角看，这很像一种面向自然语言攻击的“语义 WAF”：

• 传统 WAF 在一次 SQL 注入攻击之后总结 Payload 特征
• 这里则是在一次 Jailbreak 成功之后，总结自然语言攻击结构

一次攻击之后，护栏究竟学到了什么

整个系统运行起来其实并不复杂。

用户请求进来之后，第一步并不是直接判断内容是否危险，而是先判断：

这个请求有没有使用某种 Jailbreak 方法？

系统会尝试把输入归类成已有攻击标签，例如嵌套角色扮演、代码混淆等。

如果没有攻击包装，则标记为 benign；如果明显像一种攻击，但和已有类别都不一样，就会进入 other。

第二步，系统会根据识别到的攻击方法，从长期规则记忆中召回最相关的少量防御规则。

这里作者没有简单地把所有规则都塞进 System Prompt。

这是一个非常现实的设计：规则不断增长以后，如果几百条、几千条规则全部进入上下文，不但成本会越来越高，大量不相关规则本身也会成为噪声。

因此系统每次只选择当前攻击最相关的规则。

第三步是策略决策。

规则并不是简单地提醒模型一句“请注意安全”，而会进一步变成当前请求的执行策略，例如：

正常回答、软拒绝、强拒绝。

论文的消融实验也说明了这一点。如果只把历史规则作为普通 reminder，而不把它转换成当前请求的明确安全策略，攻击成功率会显著回升。

最后，模型完成回答之后，还有一个非常关键的步骤：

检查这一次到底有没有守住。

如果模型依然输出了危险内容，系统会触发 Reflection，对整个交互进行复盘：

这次攻击使用了什么结构？

为什么已有规则没有防住？

它属于已有攻击家族，还是出现了一种新的方法？

应该增加什么防御规则？

最终，新经验会被写进 Rule Memory。

至此，一个完整的闭环形成了：

遭遇攻击 → 防御 → 检查结果 → 失败反思 → 生成规则 → 写入记忆 → 防御下一次攻击。

这就是论文所谓的“Self-Evolving”。

值得注意的是，整个过程中模型参数完全没有变化。

所谓“进化”，真正改变的是模型外部的 运行时安全状态。

最有意思的实验：第一次会中招，之后越来越难打

论文测试了四类比较典型的 Jailbreak：

• DeepInception 主要利用多层虚构场景和嵌套角色扮演
• CodeChameleon 通过代码、编码和转换隐藏真实危险意图
• ReNeLLM 会自动改写危险 Prompt，并进一步加入场景包装
• FlipAttack 则通过文本翻转和结构变换，让传统安全判断更难理解输入

作者分别在 Qwen2.5-7B、Llama3.1-8B 和 Gemini-3-Flash-Preview 上进行了测试。

如果使用论文更看重的 LLM Judge ASR 指标，结果非常明显。

例如 CodeChameleon 对 Qwen2.5-7B 的攻击成功率从 57.0% 降到 1.4%，Llama3.1-8B 从 58.0% 降到 1.9%；FlipAttack 对 Llama3.1-8B 的攻击成功率则从 45.0% 降到 0.2%。

但相比这些最终数字，我认为论文真正值得看的其实是另一组实验。

作者让系统从一个完全空的 Rule Memory开始，然后不断把攻击样本送进去。

一开始，系统并没有任何关于当前攻击家族的经验，因此确实可能被攻破。

但第一批成功攻击发生后，系统会自动总结出对应规则。

随后，同一结构家族里的后续攻击成功率迅速下降，很多情况下接近 0。

这个实验很好地说明了它所谓的“进化”究竟是什么：

系统不是一开始什么都会，而是在交互过程中变得越来越难攻击。

这其实非常接近生物免疫系统的工作方式。

• 第一次遇到一种陌生病原体时，身体仍然可能感染
• 但真正重要的是，免疫系统会留下记忆

下一次再遇到相似目标，防御速度和准确性都会明显提高。

它和 HARD，其实是同一条技术路线的两个层次

如果只看这篇论文，很容易把它理解成一个新的 Jailbreak Defense。

但如果把它和我们前面介绍过的 HARD：Harness-based Autonomous Runtime Defense Evolution 放在一起看，事情就有意思得多。

HARD 解决的问题是：

Agent 运行时防御为什么必须一直靠人工设计？

今天很多 Agent 安全机制，例如限制工具调用、检查执行参数、拦截危险轨迹，本质上依然依赖工程师提前设计规则。

HARD 希望让系统观察 Agent 的失败执行轨迹，然后自动寻找新的干预位置、生成新的 Defense Artifact，并持续迭代运行时防御。

也就是说：

HARD 让 Agent Harness 学会从执行失败中进化。

而这篇论文做的事情则是：

让 Guardrail 学会从 Jailbreak 失败中进化。

两篇论文研究的对象并不一样。

HARD 面向的是 Agent 执行阶段：

工具调用、环境交互、执行轨迹、Runtime Intervention。

这篇工作主要面向模型输入输出阶段：

Prompt、Jailbreak Wrapper、规则召回和响应策略。

但如果把它们放到一套完整的大模型安全架构里，就会出现一个非常清晰的分层：

• 模型层负责基础安全对齐
• 护栏层负责积累输入攻击经验
• Agent Runtime 层负责积累执行风险经验

攻击者在 Prompt 层发现一个新的越狱方法，Guardrail 可以学习；

攻击者在 Agent 工具执行层发现一个新的攻击路径，Harness 也可以学习。

于是，安全系统不再只是几层固定规则叠加起来的“城墙”，而开始拥有自己的历史状态。

这可能才是最近这些“Self-Evolving Defense”工作真正重要的地方。

但这里藏着一个新的问题：如果护栏学错了怎么办

一旦我们接受“安全系统可以自己学习”这个前提，一个新的攻击面就会立刻出现。

攻击者能不能反过来攻击这个学习过程？

论文当前的流程大致是：

发现模型输出违规
↓
Reflection 总结攻击方式
↓
自动写入 Rule Memory。

问题在于，Reflection 本身也是模型。

攻击分类器也是模型。

违规判断器仍然可能是模型。

如果攻击者能够构造一种输入，让系统错误地认为某个正常模式是一种攻击，然后生成一条过度严格的防御规则，这条错误规则就有可能长期留在系统里。

攻击者甚至不一定要让模型输出危险内容。

他完全可能换一个目标：

让防御系统变得越来越不好用。

比如把正常业务表达不断污染成“攻击特征”，最终导致大量误拒绝。

这实际上可以被看作一种新的攻击：

Defense Memory Poisoning——防御记忆投毒。

过去我们担心的是模型记忆被投毒、Agent 长期记忆被投毒；

如果未来安全系统本身开始拥有长期经验库，那么：

安全记忆同样需要被保护。

从这个角度看，这篇论文其实打开了一个它自己还没有完全解决的问题。

未来真正可部署的自进化护栏，恐怕不能简单采用：

发现失败
↓
自动写生产规则。

而应该增加一整套治理链路：

失败样本
↓
候选规则
↓
沙箱验证
↓
回归测试
↓
误拒绝测试
↓
冲突检查
↓
发布
↓
持续监控
↓
可回滚。

也就是说，真正值得落地的并不是“完全自治的安全学习”，而更可能是：

受控自进化。

自进化安全真正改变的，可能不是某个算法，而是安全工程方式

过去的大模型安全建设，很大程度上还是一种“发布式安全”。

在上线之前尽量训练好模型、准备好规则、准备好评测集，然后发布。

发现新的风险之后，再进入下一轮版本迭代。

而 HARD 和这篇论文共同指向了另一种可能：

安全能力本身成为运行时系统的一部分。

系统每天都会遭遇新的攻击，也每天都会产生新的安全经验。

线上 bad case 不再只是进入一个表格，等待下一次人工复盘；它可以直接成为安全知识生产流水线的输入。

从工程角度看，这和传统网络安全的发展历史其实非常相似。

• 最早的安全产品依赖固定黑名单
• 之后开始出现 IDS、IPS、行为分析、EDR 和自动响应

安全系统逐渐从“判断一个东西是不是已知恶意”，走向“根据真实运行环境持续获取新的攻击知识”。

大模型安全现在很可能正在经历类似的阶段。

因此，这篇工作的真正价值，并不是它又把几个 Jailbreak benchmark 的 ASR 做低了几个百分点。

更值得关注的是一个新的系统假设正在形成：

我们不可能在部署前枚举未来所有攻击。

既然如此，下一代安全系统就必须具备另一种能力：

在不知道未来攻击是什么的情况下，仍然能够在运行过程中逐渐学会防御。

护栏不应该只是一堵墙

静态护栏像一堵墙。

它能挡住什么，基本在建成那一天就决定了。

攻击者发现一个缺口之后，如果没人来修，它就会一直存在。

而自进化护栏更像一套拥有战斗记录的防御系统。

它可能仍然会第一次失守，也可能学错规则，甚至会遭遇针对自身学习机制的投毒攻击。

但至少有一件事情发生了变化：

失败不再只是失败，而开始变成安全资产。

从 HARD 的 Agent Runtime Defense，到这篇工作的 Guardrail Rule Memory，我们已经开始看到一条越来越清晰的路线：

模型安全正在从静态规则走向运行时安全，再从运行时安全走向持续学习的自进化安全。

未来真正成熟的 AI 安全体系，也许并不是拥有最长的 System Prompt、最大的 Guard Model 或最多的手工规则。

而是一套能够持续观察、持续复盘、持续验证，并且不断调整自身防御状态的系统。

当护栏开始记住失败，安全系统才真正开始拥有“经验”。