大模型越狱最近频繁出现在技术社区。大模型能够熟练回答复杂问题并不等同于模型总是按照服务提供者的规则运行。所谓越狱jailbreak在 LLM 领域指的是通过精心构造的输入文本让模型绕过训练阶段建立的安全对齐输出本应被拒绝的内容。这篇文章从原理、攻击形态、评估指标、防御架构和排查步骤几个角度展开面向正在做 LLM 应用开发、本地部署大模型、模型微调以及负责 AI 内容安全的团队。读完后你会得到一套可落地的越狱风险检测和加固思路而不是只停留在概念层面。1. 先分清大模型越狱和普通提示词攻击不是一回事1.1 “越狱”这个词到底指什么越狱这个词最早来自终端设备。iPhone 越狱、游戏机越狱本质都是绕过设备厂商对操作系统或硬件的限制让设备运行本不被允许的代码。大模型领域借用这个词指代一种更隐蔽的行为用户通过构造提示词、上下文或输入格式绕过模型在训练阶段建立的限制策略让模型输出违反安全规范的内容。这里的关键词是“绕过限制”。大模型本身并不天然理解什么可以说什么不能说而是通过安全对齐训练获得了一套服从规则的倾向。越狱攻击的目标就是让这套倾向在特定输入下失效。需要注意的是越狱不完全等于模型说了不好听的话也不完全等于模型回答错误。它的核心特征是模型具备拒绝能力但攻击者通过改写问题形式让拒绝机制没有被触发。这个区分对后续评估和防御很重要。1.2 大模型越狱、提示注入和恶意指令遵循的区别在实际项目里越狱经常和另外两个概念混在一起有必要先分开。提示注入prompt injection偏向于干扰模型执行当前任务比如让模型忽略前面的指令去执行输入中夹带的指令。恶意指令遵循则指模型确实错误地执行了危险指令但未必存在明显的“绕过”过程。越狱更强调对抗安全对齐它针对的是模型内置的拒绝策略。下表是三种概念的比较概念核心目标典型场景防御重点提示注入篡改或劫持模型当前任务工具调用、RAG 上下文中夹带指令输入隔离、指令边界识别恶意指令遵循模型错误服从了危险指令用户直接要求生成违规内容指令分类、输出过滤大模型越狱绕过安全对齐与拒绝策略换角色、换语言、拆步骤等对抗手段对齐训练、对抗样本检测三者的边界并不绝对。越狱攻击在实现时往往也依赖提示注入技巧而恶意指令遵循可能是越狱成功的直接结果。但在设计防御体系时把它们分开仍然有价值提示注入主要靠隔离和边界识别越狱更多靠对齐和对抗样本检测。1.3 为什么越狱是大模型应用的生产级风险越狱不只是安全研究者的玩具。一旦大模型被接入生产系统它就有权限、有工具、有数据攻击者不再只是“问一个问题”而是可能让模型执行敏感动作。具体来说越狱带来四类生产风险内容合规风险模型输出了违反平台规范的内容导致审核、投诉、下架。数据泄露风险通过让模型忽略“不要透露系统提示词”的限制套出内部提示词、工具配置或上下文中的敏感数据。工具滥用风险模型接了数据库查询、文件读取、邮件发送等工具后越狱可能让攻击者间接调用这些工具。产品信任风险反复出现越狱案例会削弱用户对该模型的信任。越狱问题在多模态模型和 RAG 架构里会更加复杂。多模态模型可以把指令藏在图片或语音中RAG 场景则可能因为外部文档被投毒让模型在正常回答问题时被动读取恶意内容。这也是近期大模型领域频繁讨论越狱的原因之一。2. 越狱能成立问题出在对齐和生成的对抗上2.1 安全对齐让模型学会“拒绝”先要理解大模型为什么有“拒绝”这个行为。大模型在预训练阶段学到的是大量互联网文本的概率分布目标是把下一句话预测得更合理此时模型并不关心内容是否合规。完成预训练后模型需要经过对齐阶段常见方法包括 RLHF、DPO 等。对齐阶段会构造大量“安全偏好数据”。比如同一个问题一个回答是配合危险请求另一个回答是礼貌拒绝训练目标就是让模型更倾向于输出后一种。经过这样的训练模型学习到的是在特定话题、特定表达方式下拒绝行为会获得更高的奖励分数。所以模型的安全能力不是一条写在代码里的硬规则而是一个概率偏好。它表现为当输入足够接近训练中的危险样本时模型更容易触发拒绝路径当输入看起来“不那么危险”时模型则更容易走正常回答路径。2.2 越狱的本质是让模型重新走上“通用路径”大模型内部同时存在多个能力路径。面对一个包含危险意图的请求模型实际上在做两种判断帮助用户完成请求还是遵守安全边界。安全对齐希望帮助路径在冲突时被抑制。越狱攻击要做的事情就是找出一种输入表述让模型在判断时认为“这不算危险请求”从而绕过抑制信号重新激活通用帮助路径。这也是为什么很多越狱攻击看起来是在“绕弯子”把问题包装成虚构故事。把目标拆成几步每一步看起来无害。让模型扮演一个不受限制的角色。用另一种语言或者编码重新表达问题。这些手法的共同点是没有修改模型参数也没有篡改系统指令只是改变了模型对输入的“危险感知”。所以越狱被称为一种对抗攻击它所对抗的正是模型的概率化安全判断。2.3 泛化边界换一种表达安全策略就失效大模型安全对齐面临的根本问题是有限样本无法覆盖无限表达。模型在训练阶段见过的危险样本可能集中在某几种语言、某几种话题、某几种角色设定中。一旦攻击者换了攻击面模型的拒绝机制就可能失效。典型情况包括语言迁移模型训练时主要用英文安全样本攻击者用中文、日文、多语言混写拒绝概率明显下降。格式迁移把请求写成 Base64、凯撒密码、Unicode 变体模型解码后仍然理解但安全分类器没有识别。指令层级混淆把攻击性指令隐藏在系统提示词中或者伪造“开发者模式”设定让模型误以为这是更高优先级的要求。这些现象说明安全对齐不是一次训练就能解决的问题而是需要持续补充对抗样本扩大安全能力的泛化边界。2.4 开源模型和微调模型的风险更容易放大比起闭源大模型 API本地部署的开源模型面临更直接的越狱风险。原因主要有三点开源模型的原始对齐强度参差不齐很多 7B、13B 级别的小模型本身拒绝能力就不稳定。微调会破坏对齐。即使是安全的基座模型在领域数据上继续训练后原有的安全偏好也可能被稀释。这就是最近的“大模型微调”话题里经常被忽略的安全性提示。本地部署意味着没有平台侧的额外过滤。用 OpenRouter、Ollama、vLLM 部署的模型输入输出完全由自己负责所有防御都要自己补。因此在部署开源模型时不能默认“这个模型很安全”而要在每次部署前重新评估越狱风险。模型能力越强输出越流畅越狱成功后的破坏力往往也越大。3. 从防御视角看越狱攻击的常见形态这一节只从防御和检测的角度介绍形态特征目的是帮助识别和定位问题不建议在非安全测试环境中复现。3.1 角色扮演与虚拟场景类这是最常见的一类越狱形态。攻击者让模型先进入一个虚拟角色设定再利用角色本身的设定绕开安全规范。由于模型在判断时会把角色的行为规则识别为高优先级指令原本应该拒绝的内容就可能被当作“角色说台词”而输出。防御侧需要重点关注的关键词特征包括“扮演角色”“虚构世界”“无视之前规则”“开发者模式”“模拟终端”等。检测时不能只依赖关键词还要结合上下文判断模型是否真的被切换到了高风险角色设定。3.2 编码、翻译与格式变换类编码类越狱利用的是模型对多种格式的理解能力。攻击者把危险请求转成 Base64、十六进制、凯撒密码、拼音、Unicode 变体或者通过多次翻译让文本语义保留但表面形式完全变化。模型仍然能理解规则过滤却可能漏掉。这类攻击的检测思路是寻找明显的编码特征以及编码文本前后出现的解码指令。如果一段用户输入同时包含“解码”“翻译”“理解后回答”等指令就需要提高风险等级。3.3 多轮对话与上下文拆分单轮提问往往容易被模型拒绝但把完整请求拆成多个步骤每一步看起来都安全模型就可能逐步完成危险链条。例如先确认一个概念再要求给出实施方案最后要求替换成具体细节。在多轮场景中模型的安全判断不只是针对当前这一条消息而是结合整个对话历史。攻击者可以在前几轮建立一种“模型已同意配合”的语境让后续请求的拒绝概率下降。防御这类攻击必须对多轮上下文做整体风险评估而不是只看单条消息。3.4 多模态与工具调用新增的攻击面多模态越狱是最近讨论较多的一块。图片、音频、视频都可以携带文本中不易识别的指令。模型把图片中的文字识别出来后如果按识别结果执行图片上的恶意文本就绕过了文本输入过滤。语音也存在类似问题。工具调用场景更危险。模型在 AI Agent 架构中已经具备调用数据库、文件、网络请求的能力。攻击者一旦越狱目标就变成让模型执行某个工具调用而不是让模型“说出一段话”。因此需要把工具调用的参数校验和 API 权限控制提升到和输入过滤同等的优先级。3.5 越狱形态识别速查表攻击形态典型特征检测侧关注点角色扮演要求进入虚构角色、模拟无限制场景角色切换指令、风险设定识别编码混淆Base64、凯撒、Unicode、拼音编码编码特征、解码指令多语言混写中英混写、低资源语言翻译语言分类、语义等价性判断多轮拆分逐步请求、每轮单独看均无害多轮风险聚合、历史上下文分析多模态注入图片或语音携带指令OCR 文本、ASR 文本二次过滤工具调用越狱指令集中在工具参数中工具入参校验、权限白名单4. 用指标和数据评估模型的抗越狱能力4.1 公开基准与数据集评估模型是否容易被越狱不能只靠几个人手工提问。目前研究社区已经有公开数据集和基准常见的有 HarmBench、AdvBench、JailbreakBench、SafetyBench 等。这些基准通常包含大量对抗样本覆盖不同语言和攻击手法。使用公开基准时要注意两点数据集更新速度快新攻击手法出现后旧数据集的覆盖能力会下降。不同基准对“越狱成功”的判定标准可能不同不能直接跨基准对比数值。更好的做法是把公开基准作为基础集再根据自己业务场景补充一批自定义对抗样本。4.2 红队测试的最小流程无论用开源模型还是 API 模型建议至少按以下流程做一次抗越狱评估划定测试范围确定哪些模型版本、哪些能力模块需要覆盖。准备基线用例从公开基准中选取一个子集再加入 20 到 50 条业务相关风险用例。定义判定标准明确什么样的回答算违规什么样的拒绝算有效。执行测试可以用脚本自动调用模型接口也可以交给人工红队做补充。汇总指标计算越狱成功率、拒答率、拦截率等。复盘对每条成功样本做根因归类确定是模型对齐问题还是外部过滤问题。4.3 越狱成功率与拒答率怎么算越狱成功率通常叫 JSR全称 Jailbreak Success Rate。实际评估中还会计算拒绝率和拦截率。一个最小统计函数可以写成def compute_attack_metrics(results: list[dict]) - dict: total len(results) if total 0: return { jsr: 0.0, refusal_rate: 0.0, block_rate: 0.0, total: 0, } success sum( 1 for r in results if r.get(violation) and not r.get(blocked) ) refused sum(1 for r in results if r.get(refused)) blocked sum(1 for r in results if r.get(blocked)) return { jsr: success / total, refusal_rate: refused / total, block_rate: blocked / total, total: total, }调用场景大致如下test_results [ {violation: True, blocked: False, refused: False}, {violation: False, blocked: False, refused: True}, {violation: True, blocked: True, refused: False}, ] print(compute_attack_metrics(test_results))输出为{jsr: 0.3333333333333333, refusal_rate: 0.3333333333333333, block_rate: 0.3333333333333333, total: 3}要注意如果应用层已经拦截了一条违规提问那么这条请求应该算作“拦截”不应该混入 JSR 统计。JSR 描述的是突破全部防线之后的成功率而不是模型内部对抗的成功率。4.4 评估中的典型误判评估抗越狱能力时有几种常见误判需要避免。第一只测单条攻击文本不考虑多轮对话。很多越狱手法要在多轮环境下才能生效单轮评估会严重低估风险。第二用关键词过滤结果代替模型判断。如果应用层用了脏词过滤测试集里大量样本可能被直接拦截导致 JSR 看起来很低但模型本身的抗攻击能力并没有提升。第三让模型自己给自己的回答打分。模型裁判LLM-as-a-judge在判断“这段话是否违反安全规范”时也可能被越狱。最好设置一个独立、不与主模型共享上下文的评审流程。第四忽略业务语境的特殊性。对一个客服机器人来说用户提到“退款”是正常业务对一个内容创作工具来说用户要求生成恐怖小说可能是合法需求。评估用例必须结合业务边界否则容易误报。5. 模型、应用、网关三层防线怎么搭大模型越狱没有单点解药。生产环境建议采用三层防线模型层、应用层、网关层。每一层解决不同的问题不能互相替代。5.1 模型侧对齐、微调与安全训练模型层是第一步也是最底层的一步。要提升抗越狱能力可以从几个方向入手使用对齐程度更高的基座模型。在选型时不仅要看榜单分数还要看安全评测结果。在微调数据中加入安全样本使用 DPO 等偏好优化方法在保持业务能力的同时调整安全偏好。建立对抗样本迭代机制。每次越狱事件后把脱敏样本加入训练数据形成“发现-修复-回归”的循环。对已经微调过的模型不要直接沿用基座模型的安全指标。微调后必须重新跑一遍安全测试尤其是原本表现良好的拒绝能力可能被新数据稀释。5.2 应用侧输入清洗与输出过滤应用层负责在模型前处理后输出后处理。输入侧可以加入提示注入检测器输出侧可以加入违规内容分类器。一个最小化输出过滤逻辑可用伪代码表示def review_model_output(text: str, config: dict) - dict: if contains_pii(text, config.get(pii_rules, [])): return {decision: mask, reason: pii} if contains_unsafe_content(text, config.get(safety_rules, [])): return {decision: block, reason: unsafe} return {decision: pass, reason: ok}实际落地时判断逻辑可以依赖三类能力规则库明确的敏感词、占位符、正则规则。小型分类模型适合做文本风险分类如赌博、色情、暴力等。大模型裁判适合做语义级判断但需要防止裁判模型本身被注入。这里要强调输出过滤不能只做“坏了再拦”还要把高风险提问记录到日志中用于后续分析。5.3 网关侧限流、审计与告警网关层负责请求的入口管控和事后审计。如果要部署本地大模型建议在模型服务前方加一层网关统一处理鉴权、限流、日志、告警。网关日志建议记录以下字段{ request_id: req_8f21, user_id: u_10086, model: demo-llama-3-8b, prompt_preview: cut-off text before current request, detected_zones: [role_play, encoded_scheme], risk_score: 0.82, decision: block, created_at: 2025-01-01T10:00:00.000Z }网关不需要承担太多语义判断它更擅长做频率控制同一用户短时间高频提交相似内容触发告警。敏感链路审计记录哪些用户访问了能力较强的模型。灰度策略新模型先小流量再逐步放开。5.4 三层防线覆盖对照表防线解决什么问题典型工具/方法局限性模型层减少模型自身被绕过概率对齐训练、DPO、对抗样本训练无法覆盖所有输入分布应用层识别高风险输入和违规输出输入检测器、输出分类器可能误伤正常业务网关层管控流量、审计、告警限流、日志、观测无法判断语义质量三层配合的正确姿势是模型层做基础安全能力应用层做业务安全兜底网关层做运营安全监控。千万不要只依赖一层。6. 部署后遇到越狱样本怎么排查6.1 先记录现象再碰模型生产环境中发现疑似越狱第一件事不是去模型里反复试 prompt而是把现象完整记录下来。需要记录的信息包括用户输入原文和完整对话上下文。系统提示词版本和模型版本。命中的过滤规则和未命中的规则。模型的完整输出或输出截断。会话时间、用户标识、请求 ID。这些信息决定了后续能否定位根因。缺少上下文的越狱样本排查难度会成倍增加。6.2 从日志还原上下文越狱往往多轮生效。单看最后一条消息可能看不出任何问题。排查时要从日志中还原完整上下文观察攻击节奏。一个典型的日志分析思路如下{ request_id: req_8f21, step: 3, user_input: continue the previous reply, previous_turns: [ {role: user, text: role play setup...}, {role: assistant, text: accepted role...} ], risk_indicators: [role_play_setup_captured] }排查时注意看前几轮是否包含角色设定、虚构场景、开发者模式等高风险指令。很多越狱是在多轮铺垫后才发动的。6.3 定位根因的四个检查点如果确认发生了越狱建议按以下四个点逐一检查系统提示词是否被泄露或覆盖检查模型是否输出了内部提示词内容。输入侧过滤器是否被绕过检查编码类、翻译类输入是否绕过了规则。模型自身是否对齐不足把同样的问题换回正常表达看模型能否拒绝。微调是否破坏了安全能力对比同版本基座模型与微调模型在同一测试集上的表现。6.4 应急处理与后续回归应急处理时优先降低损失下线高危工具、收紧模型权限、增加人工审核比例。不要急着改模型除非已经能稳定复现。处理完成后要把样本加入回归集之后每次模型升级、微调、提示词改动都要重新跑一遍。建议维护一个“越狱回归用例表”样本编号攻击形态分类原始风险等级回归结果处理状态JB-001角色扮演高已拦截通过JB-002编码混淆高已拦截通过JB-003多轮拆分中需加强待处理这张表就是团队在模型安全上的长期资产。越狱防护不是一次评审能结束的而是每一次升级都要重复执行的常态化动作。7. 给大模型团队的安全实践建议7.1 把安全评估写进发布门禁大模型项目的发布流程里安全评估应该和功能测试、性能压测并列而不能作为上线后补救项。推荐的最小门禁包含静态检查检查系统提示词是否包含敏感信息或过度授权表述。动态测试核心模型版本必须跑一次对抗样本回归集。权限复核所有工具调用的权限范围必须和最小权限原则对齐。监控配置确保高风险输入、异常模型输出已经接入告警。7.2 不要为了安全把模型调成复读机防御过度同样存在问题。如果输出过滤器经常把正常业务内容误判为违规用户很快就会放弃产品。越狱防御的目标是降低风险不是消除所有“有一点风险”的回答。平衡手段包括分场景设置安全等级客服、教育、创作工具可以使用不同敏感度。对低风险内容采用“放行但打标”策略保留人工复核入口。定期分析过滤器误报样本持续优化规则和分类模型。7.3 学习路线从提示词工程到大模型安全如果你刚接触大模型想深入越狱防护可以参考以下顺序先会部署模型用 Ollama 或 vLLM 本地部署一个大模型理解模型输入输出链路。再做提示词工程掌握角色设定、指令优先级、上下文管理这些是安全边界设计的基础。再理解对齐读 RLHF、DPO 相关材料明白模型拒绝行为是怎么来的。再做安全评测尝试用公开基准跑一次越狱评估计算 JSR。最后做防御工程把模型、应用、网关三层防线落到自己的部署环境里。大模型越狱是模型能力和安全策略的持续对抗。对开发者来说真正有用的不是记住几条攻击案例而是建立一套“能评估、能检测、能响应、能回归”的完整机制。模型会持续迭代越狱手法也会持续变化但只要评估和防御链路始终在运转风险就能被控制在可接受范围内。