最近关于 Anthropic 旗下 Claude 旧模型可被越狱生成违规内容的讨论又把“大模型安全防护”这件事推到台前。很多人第一反应是看热闹原来大模型也没那么安全。做安全工程的人看到的是另一个问题为什么一个当时已经做过安全对齐的模型在发布一段时间之后依然会被一套经过设计的输入绕过这件事真正值得关注的不是某个具体攻击样本能产生什么内容而是它暴露出的结构性矛盾——模型能力在持续扩展但安全对齐始终滞后于能力的增长。换句话说大模型安全防护不是一次性发布会上的演示结论也不是模型权重里“自带”的一个开关。它是一个需要在发布前、发布后、运行期和迭代期持续维护的对抗过程。如果你正在搭建基于大模型的应用或者负责给内部系统接入 Claude、GPT 这类模型那这个话题就离你很近。这篇文章不谈猎奇只从工程视角拆解三件事旧模型为什么容易被越狱安全评测为什么不能只靠一组静态用例以及部署侧到底应该怎么把防护做到模型之外。1. 一次安全事件暴露的是“对齐”和“能力”之间的错位1.1 模型能力越强对齐滞后越明显先想一个基础问题为什么模型会“知道”哪些内容不能生成原因是它在训练阶段已经被灌入了一套人类偏好规则比如无害性、拒绝违规内容、避免生成危险代码。这套规则在深度学习里通常被称为对齐alignment常见做法是 RLHF、RLAIF 或者 DPO 这类偏好优化方法。但这里有一个容易被忽略的事实对齐不是一次训练完成之后就永久固定的属性。模型的语言能力、上下文理解能力、指令跟随能力是多轮训练叠加出来的而对齐策略往往是在某一个训练阶段加入的。当模型后续继续做大、继续扩展上下文、继续强化工具调用能力时新的能力会不断涌现其中一些能力会与已有的安全规则产生冲突。旧模型的问题就在这。它发布时能力边界和安全规则是匹配的。等社区开始基于它做二次开发、做更长的上下文微调、接入外部工具之后模型的“新能力”会绕过当初设计好的安全边界。这很像一个操作系统刚发布时漏洞少但随着新功能、新驱动和新协议不断加入旧的安全补丁就会漏出空隙。1.2 旧模型并不是“没做过安全训练”而是训练目标太静态网上有一种声音说旧模型之所以被越狱是因为“当时没有做安全训练”。这种说法不准确。Anthropic 的产品模型从一开始就有安全对齐设计包括拒绝策略和有害内容过滤。真正的问题不是“没有防护”而是防护的覆盖范围是静态的。什么意思训练阶段的安全规则通常是基于当时对风险的理解采集了一批攻击方式、一批有害请求、一批预期行为然后让模型学会拒绝或回避。但对抗攻击是动态演进的。攻击者不会拿着训练集里的标准问题去问模型他们会不断设计新的上下文、新的编码方式、新的对话结构去试探模型的指令跟随边界。这就是我常说的一句话“模型的安全能力本质上是一个对抗博弈下的有限快照。”你用静态数据集去训练安全拒绝能力模型学会的也只是“拒绝这些样本的能力”而不是“拒绝所有违规内容的能力”。一旦攻击方式超出训练分布模型的旧防线就失效了。这个矛盾在旧模型上尤其明显训练时间越早见过的对抗模式越少攻击者积累的研究时间越长找到盲区的概率就越高。所以安全事件陆续出现在旧版本上几乎是一个必然结果。注意不要把“旧模型可被越狱”理解成模型完全不可用。它的意思是模型的安全边界存在盲区在正式接入业务前必须叠加额外防护而不是把模型文档里的安全承诺当成最终结论。2. 越狱不是一条咒语而是一组结构性绕过方式2.1 角色伪装和上下文覆盖在安全团队内部越狱攻击通常不叫“咒语”而叫“对抗性输入”。它和传统安全里的 SQL 注入、XSS 一样核心思路是让模型在“使用规则”和“遵守请求”之间发生冲突。最常见的模式是角色伪装。攻击者会让模型扮演某个虚构角色这个角色的身份设定里写明了“不受约束”“可以讨论任何话题”。模型在指令跟随能力被激活后可能优先执行扮演逻辑而暂时弱化自己的安全拒绝逻辑。对于旧模型因为训练时接触过的角色扮演样本相对少这种覆盖的成功率就会更高。还有一类是上下文覆盖在很长的上下文里把违规意图埋在中后段前面用大量正常内容把模型的注意力占了。模型对指令的优先级判断能力有限越长的上下文越容易出现遗漏或误判。2.2 渐进式诱导与多轮拆分比单次绕过更有威胁的是渐进式构造。攻击者不直接提交一个会被拒绝的请求而是先把话题拆成多个看似独立的步骤在每一步都诱导模型完成内容片段最后再把所有片段拼成完整输出。这是工程上特别难防的一类攻击因为单看每一轮问答几乎所有内容都在正常范围。比如让模型描述一个角色的某个特征、再补一个场景、再补一段情绪每一步都能通过常规安全检测但组合起来就完成了完整生成。传统的单次内容过滤在这种场景里几乎没有效果。这类攻击考验的不是模型的单条拒绝能力而是整个对话状态的管理能力。模型需要能够识别“多轮组合后可能指向违规目标”的意图这对当前很多模型来说仍然是一个开放问题。2.3 编码混淆与格式绕过旧模型还可能被编码式输入骗过。比如用 Unicode 变体、大小写混写、同音字替换、代码块包裹、Markdown 格式控制等手段让安全分类器无法识别原始语义但模型本身仍然能理解。这类绕过方法看起来技术含量高但本质上是对“安全规则与指令理解能力之间存在夹角”的利用。模型足够聪明能读懂被编码过的意图但安全分类器是基于表面文本特征训练出来的一旦文本形态发生变化分类能力就下降。这也是为什么不少安全团队会说防越狱不能只看模型输出前的拒绝逻辑必须同时看输入端和输出端的独立检测。2.4 为什么不写具体样本关于这类攻击我到这一步就停。原因不是故弄玄虚而是安全博客必须有一个边界我们讨论攻击模式是为了让防御方理解威胁结构而不是提供一份可复制的测试用例。具体的攻击样本一旦扩散就会成为更多人的输入脚本反而降低模型被大规模恶意使用的门槛。正确的做法是安全团队在内部把攻击样本当作“红队弹药”在公开场合只讨论分类学、防御策略和评测框架。这也是很多大模型厂商发布安全报告时采用的方式给类别、给趋势、给缓解建议不直接给完整的可复现攻击提示词。3. 安全评测怎么才能不像“事后补丁”3.1 从单轮问答到多轮对话评测很多团队在评测模型安全能力时习惯用一组单轮问答数据集把问题发给模型看它是否拒绝。这种评测方式能覆盖基础情况但对前面提到的渐进式诱导几乎无效。正确做法是引入多轮对话评测。每一轮不只检查当前回答还要评估整个对话链路的意图累积。比如前几轮都在讨论正常内容最后如果组合起来可能指向违规生成就应触发防御策略。这需要评测系统不仅记录单条输出还要追踪对话状态、用户意图和语义方向。我建议的落地方式是先构造 10 到 20 个典型的渐进式诱导场景每个场景包含 5 到 10 轮对话然后手动检查模型在哪个节点开始偏离安全边界。这个数量不用多但结构必须完整覆盖角色扮演、长上下文覆盖、编码混淆、多轮组合等不同类别。3.2 从已知红队样本到对抗性生成固定数据集只能测出“已知漏洞”测不出“未知盲区”。所以安全评测要加入对抗性生成环节。具体做法是准备一个攻击样本生成器它可以基于现有攻击模式自动组合变体再批量输入给目标模型。这个过程重点不是追求单条成功而是观察成功率的变化趋势。如果你改一个系统提示词之后对抗性生成的成功率从 8% 降到 3%这是一个可量化的改进如果降幅不明显说明防护策略没有真正改变模型的决策边界。这里要注意对抗性生成本身需要放在隔离的测试环境里跑不能用生产环境的真实用户流量做实验。默认建议是单独拉一套模型服务配置虚拟输入输出不做真实业务调用。3.3 回归测试释放新版本时旧漏洞是否复活安全评测最容易忽略的是回归测试。许多团队只在新模型上线前做一次安全评测之后就不再持续验证。但大模型应用是动态的你改了系统提示词、升级了模型版本、调整了上下文长度都可能影响已有的安全行为。强烈建议每次配置变更、模型升级或提示词调整之后都跑一遍回归用例。回归用例应该包含三部分历史攻击样本的变体集上一轮评测中暴露的失败用例和当前业务场景强相关的自定义边界用例回归测试不需要每天跑但至少在发布前和重大调整后必须跑。你可以把它看成传统软件工程里的安全回归功能没变不代表安全属性没变。实际经验多数越狱问题不是新版模型突然变笨而是旧版模型在使用一段时间后被社区发现了一些当初没发现的盲区。所以如果你的业务依赖某个固定版本的模型且无法快速升级就必须在应用层额外部署过滤和审计机制不能把全部安全责任压给模型。4. 部署侧的纵深防御别指望模型独自拒绝4.1 输入层先过滤再进模型在真实业务系统中模型从来不应该接收到用户的原始输入就立刻开始推理。更稳妥的流程是在输入层加一道过滤包括请求长度控制、敏感内容检测、恶意意图识别等。它不一定能做到百分之百准确但能筛掉大量明显违规的输入尤其是一些简单直接的角色伪装和关键词攻击。这层过滤可以由轻量分类模型承担也可以用规则加分类模型组合来实现。我不建议依赖单一规则因为攻击者很容易变种绕过也不建议一上来就上大模型审核成本和延迟都偏高。先小模型粗筛再按置信度分批更符合生产环境的要求。输入层的另一个关键是长度控制。超长上下文请求是很多越狱攻击的温床。如果你的业务场景不需要支持超长上下文可以在 API 网关层设置最大请求长度。这个限制能直接砍掉一批依赖长上下文遮盖的攻击。4.2 输出层分类器兜底输入过滤再强也可能存在误判和漏判。输出层应该再放一道分类器对模型生成的内容做二次判定。检测维度包括主题、语义、预期效果等。如果输出被判定为高风险可以阻止返回、替换为模板回答或进入人工审核。这里有一个细节输出分类器的阈值不要太激进。如果阈值设得太严会大量拦截正常内容影响业务体验。我一般建议先统计一小段正常流量找到输出分类分数的分布再把阈值设在低于 1% 正常内容会被误杀的曲线上。后续根据线上反馈逐步收紧。4.3 策略层场景隔离和权限最小化不同业务场景的安全要求不同。一个做内部知识库问答的系统和一个面向公众的开放聊天机器人安全水位应该完全不一样。所以部署时要考虑场景隔离。可以按风险等级把模型应用分成几类场景类型示例建议安全措施低风险内部文档问答、代码注释生成基础输入过滤、输出审计中风险客服助手、教育工具输入过滤、输出分类、敏感词二次检查高风险开放聊天、UGC 创作辅助、多角色扮演多级审核、人工抽检、内容指纹、限流权限最小化也值得单独说。模型接入工具、数据库、外部 API 时只授予完成业务必需的最小权限。不要把数据库全量读取权限给模型也不要把生产环境的写权限放给一个可能被越狱的模型。这跟传统安全里的“最小权限原则”完全一致但很多大模型应用开发者容易忽略。4.4 审计层日志才是追责的基础日志是最容易被忽视的防护层。很多团队只记录 API 调用成功率和耗时不记录输入内容、输出内容和判定结果。一旦发生安全事故想复盘都找不到材料。建议至少记录以下字段请求 ID 和会话 ID输入文本哈希或脱敏后的输入关键内容模型版本和提示词版本输入过滤结果和输出分类结果用户标识和场景标识时间戳和响应耗时这里要强调脱敏处理。日志里不要直接存完整用户输入尤其涉及隐私信息时可以先做脱敏、哈希或截断。日志的用途是审计和回溯不是为了完整保存每一次对话。如果你做的是面向公众的服务日志还有另一个作用发现新的攻击趋势。通过分析被输入过滤命中的请求你能知道攻击者最近在尝试哪类模式从而更新对抗性测试用例集。5. 安全防护“形同虚设”的真相边界、成本和现实判断5.1 没有 100% 安全只有安全水位“Claude 旧模型可被越狱”这类新闻如果只看标题很容易得出一个判断大模型安全防护完全没用。这个判断太极端也不符合工程现实。更准确的理解是大模型的安全防护从来不是一道闸门而是一套分层水位。模型自带的对齐能力是第一层输入过滤是第二层输出分类是第三层人工审核和日志审计是第四层。每一层都可能被绕过但绕过成本会逐层递增。安全工程的目标不是把第一层修到无敌而是让整体水位高于攻击者的收益预期。对一个想生成违规内容的攻击者来说如果他要绕过多层过滤需要花费大量时间构造输入并且成功概率还不稳定那这套系统就起到了威慑作用。反过来如果系统只依赖模型自带拒绝没有任何外部过滤那攻击者只要发现一个盲区就能稳定复用。5.2 越狱防护成本随模型规模上升很多人问为什么大模型厂商不直接把所有旧模型都做一次重新对齐答案很大程度是成本和收益问题。重新对齐不是简单跑一次微调它需要准备新的对齐数据、重新偏好训练、跑安全评测、做回归测试然后还要经过灰度发布。对一个大模型产品线来说历史版本可能很多每个版本都做同等强度的安全更新成本会急剧上升。所以厂商通常的做法是集中维护主流版本对旧版本只做有限修复或建议用户升级。这给应用方的启示是如果你在生产环境长期依赖一个已经不再积极维护的模型版本那你必须默认它的安全能力是固定的不会越来越强反而会因为攻击研究的积累而越来越脆。这时候外部防护层的价值就变得非常高。5.3 哪些场景适合继续使用旧模型哪些不适合这是我的一个基本判断如果你在做内部工具数据不对外公开模型只处理受信任的员工输入旧模型的风险可控配好输出审计即可。如果你在做面向公众的开放产品模型会被任意用户输入触发那旧模型的安全风险会明显更高必须叠加多层防护。如果你让模型具备工具调用、数据库访问、外发消息等权限那即使是很小的越狱也可能造成横向风险这种情况下不建议直接使用缺乏维护的旧模型。这个判断不是否定旧模型而是提醒你要根据业务暴露面做风险决策。暴露面越大权限越高模型版本越旧风险系数就越高。5.4 一个可复用的防护检查清单最后把前面所有内容收成一份检查清单方便你在新项目或已有项目里直接对照使用是否给模型请求设置了最大上下文长度是否在输入层配置了敏感内容检测和恶意意图识别是否在输出层增加了内容分类器是否保留了每次请求的模型版本和提示词版本是否记录输入输出日志并做了脱敏处理是否对模型权限进行了最小化设置是否准备了渐进式多轮攻击的评测用例是否在模型升级和提示词变更后执行安全回归测试是否在开放场景中设置了人工抽检机制是否对旧模型版本做了额外的外部防护补偿这十条不是安全合规的终点而是一个起点。每一条都可以根据你的业务规模、团队人力和成本预算进一步细化。回到开头那句话大模型安全不是一次性发布的结果而是一个持续对抗的过程。今天关于旧模型可被越狱的讨论本质上是这个对抗过程的一次公开快照。做安全的人不需要神话模型的自带防护也不必因为一次事件就否定整条技术路线真正要紧的是把每一层防护都做实让每次攻击尝试都能被记录、被分析、被改进。如果你正在把 Claude 或其他大模型接入自己的业务我给你的建议只有一个不要把模型的安全能力当成现成的安全边界而是把安全评测、输入过滤、输出分类和日志审计作为应用开发的一部分从第一天就放进去。这样即便未来某个版本被曝出新的越狱方式你已经有了可以快速响应和迭代的防护框架。