ContextualJailbreak：大模型越狱正在从 Prompt 攻击走向上下文攻击

最近看到一篇很值得关注的论文，题目是 《ContextualJailbreak: Evolutionary Red-Teaming via Simulated Conversational Priming》。

https://arxiv.org/pdf/2605.02647

这篇论文讨论的不是传统意义上的“越狱提示词”，而是一个更接近 Agent 时代的问题：大模型可能不是被某一句恶意 Prompt 打穿的，而是在一段多轮对话中被逐步带入危险语境，最后在关键请求处绕过安全边界。

过去我们谈大模型越狱，通常关注的是最后那一句话。用户怎么改写、怎么编码、怎么角色扮演、怎么绕过关键词检测。安全防护也往往围绕这一点展开：检测输入，检测输出，识别敏感意图，然后拒答或安全代答。

但这篇论文给出的结论很直接：真正危险的攻击对象，正在从单条 Prompt 变成整段会话上下文。

论文提出的 ContextualJailbreak，是一种黑盒自动化红队方法。它不需要目标模型权重，也不需要 logits，只需要能够调用目标模型接口。系统会自动生成一段模拟多轮对话，通过角色、场景、问题诊断、机制分析等方式构造上下文，再让目标模型在这个上下文里回答最终问题。

这张图展示了 ContextualJailbreak 的整体流程：从 harmful question 和 seed pool 开始，选择上下文诱导 mutator，经 attacker model 生成模拟多轮对话，再送入 target LLM，最后通过 barrier judge 和 judge model 两级评估，并把高分模板回收到 seed pool 继续进化搜索。

作者把这种方式称为 simulated conversational priming，也就是“模拟对话诱导”。论文在 50 个 HarmBench 代表性有害行为上测试，ContextualJailbreak 在 gpt-oss:20B、qwen3-8B、llama3.1:70B 上达到 100% ASR@4，在 gpt-oss:120B 上达到 90% ASR@4。

这个数字本身已经很高，但更重要的是它背后的方向变化：攻击者开始搜索的不是一句话，而是一段对话轨迹。

越狱对象从“提示词”变成“会话状态”

传统自动化越狱方法，大多是在一个 Prompt 字符串上做优化。

比如把有害请求改写得更隐晦，或者加入角色扮演、编码、混淆后缀，让模型误判用户意图。但无论怎么变化，本质上还是在优化一个单轮输入。

ContextualJailbreak 的视角不一样。它认为，模型在多轮对话里会形成某种“语境状态”。前面几轮对话可能看起来并不危险，甚至像是在做技术分析、教学讨论、故障诊断或机制解释。但这些内容会逐步影响模型对最后一轮请求的理解。

到了最后一轮时，模型面对的已经不是一个突兀的恶意请求，而是一个看起来与前文连续、合理、专业、符合角色设定的自然延伸。

这就是上下文攻击的关键。

模型为了保持对话连贯性，会倾向于延续前文语境；为了保持 helpful persona，会倾向于继续帮助用户；为了维持角色一致性，会倾向于按照前面已经接受的身份和任务继续分析。安全边界就在这个过程中被逐步稀释。

这也是为什么这篇论文值得重视。它提醒我们，当前很多安全系统仍然把“当前输入”和“当前输出”作为主要检测对象，但在多轮应用和 Agent 场景中，风险可能早已分散在历史上下文里。

ContextualJailbreak 是怎么做的？

ContextualJailbreak 的整体过程可以理解成一个自动化红队闭环。

系统先拿到一个待测试的有害行为目标，然后从历史种子池中选择已有的高分对话模板。接着，它会选择一种上下文诱导变异方式，让攻击模型生成新的模拟多轮对话。生成出来的对话会被送给目标模型，目标模型的回答再经过两级 judge 评分。评分高的模板会被保留下来，进入下一轮搜索。

这个流程的关键在于，系统不是随机生成越狱 Prompt，而是在持续学习：什么样的上下文结构更容易让模型失守。

论文设计了五类主要 mutator，也就是五种上下文变异方式，分别是 roleplay、scenario、expand、troubleshooting 和 mechanistic。其中 roleplay、scenario、expand 比较接近已有越狱中的角色扮演、场景构造和上下文扩展；真正值得关注的是 troubleshooting 和 mechanistic。

troubleshooting 是把对话包装成“故障诊断”场景。用户看起来不是在直接请求危险内容，而是在讨论为什么某个过程失败、哪里不对、缺了什么条件、如何排查问题。模型一旦进入诊断模式，就更容易围绕缺陷、原因和修正方式展开分析。

mechanistic 则是把问题包装成“机制分析”场景。用户不是要求模型执行某个危险目标，而是要求解释某个系统、流程或机制如何运作。模型在机制拆解过程中，可能会逐步给出足够有害的结构化信息。

这两个 mutator 的意义在于，它们利用的不是简单的“伪装”，而是大模型本身偏好的推理模式。模型很擅长诊断问题，也很擅长解释机制；一旦安全策略没有在这些模式中保持足够强的约束，就容易在分析过程中泄露风险内容。

为什么 ASR@4 比 ASR@5 更值得关注？

论文没有只用传统的“成功/失败”二元指标，而是采用了 0 到 5 的 harm score。

简单理解，0 分代表拒答或安全回答；1 到 3 分代表不同程度的抽象讨论、零散提示或不完整信息；4 分代表已经接近完整危险指导，有能力的人稍加补充就可以执行；5 分则代表给出了非常完整、可直接照做的危险输出。

因此，论文重点看两个指标：ASR@4 和 ASR@5。ASR@4 表示输出达到 4 分及以上，ASR@5 表示输出达到满分 5 分。作者明确把 ASR@4 作为主要指标，因为 4 分虽然未必是“新手照做级别”，但对具备一定能力的人已经非常危险。

这个设计对安全评测很有启发。

现实中的大模型风险，很多时候不是模型完整给出一份“操作手册”，而是给出足够多的关键步骤、关键原理和关键条件。二元成功率会低估这种风险。一个更好的评测体系，应该区分“完全拒答”“抽象讨论”“部分泄露”“高风险可执行”“完全可执行”等不同等级。

这也对应到内容安全产品里经常遇到的问题：如果只看是否拒答，很容易误判；如果只看是否包含明显敏感词，也很容易漏判。真正需要判断的是，模型输出是否已经构成实质性能力转移。

实验结果

论文对比了 DirectRequest、Encoding、HumanJailbreak、Crescendo 和 ContextualJailbreak 五种策略，目标模型包括 gpt-oss:120B、gpt-oss:20B、llama3.1:70B 和 qwen3-8B。

结果很明显：ContextualJailbreak 在所有模型上都显著领先。它在 gpt-oss:20B、llama3.1:70B、qwen3-8B 上达到 100% ASR@4，在 gpt-oss:120B 上达到 90% ASR@4。更严格的 ASR@5 也达到 72% 到 94%。相比之下，Crescendo 虽然是最接近的基线，但 ASR@5 只有 8% 到 24%，说明它经常只能诱导出部分有害内容，而很难稳定产生高危完整输出。

这里最值得关注的是 gpt-oss:120B 的结果。

在直接请求下，gpt-oss:120B 的 ASR@4 是 0%。也就是说，如果用户直接提出危险请求，它基本能够拒绝。但在 ContextualJailbreak 的多轮上下文诱导下，它的 ASR@4 达到 90%，ASR@5 达到 72%。

这说明一个问题：模型不是不知道如何拒绝，而是在特定上下文结构下，拒绝机制被绕开了。

换句话说，安全对齐本身可能仍然存在，但它没有稳定地覆盖到被上下文塑造后的状态。

多轮结构本身就是攻击能力

我认为整篇论文最关键的实验，是作者专门比较了三种输入方式。

第一种是 Direct，也就是只发送最后的危险请求。

第二种是 Single Sequence，把完整上下文压平成一个连续的用户消息。

第三种是 Context Priming，把同样的语义内容组织成模拟多轮对话，包含 user 和 assistant 的交替轮次。

结果呈现出非常清晰的层级关系：Context Priming 远强于 Single Sequence，Single Sequence 又强于 Direct。

论文统计显示，Direct 的平均 ASR@4 是 37.5%，ASR@5 是 9.0%；Single Sequence 的平均 ASR@4 提升到 73.5%，ASR@5 提升到 29.0%；Context Priming 的平均 ASR@4 达到 97.5%，ASR@5 达到 90.0%。

这个实验解释了为什么很多传统护栏在 Agent 或多轮应用里会变弱。

如果安全系统只检测最后一轮 query，它可能完全看不到前文的诱导过程。如果安全系统把历史上下文简单拼接成一段文本再检测，它又可能低估多轮结构的影响。因为模型不是只在处理文本内容，也在处理角色关系、对话承诺、任务延续和上下文一致性。

这意味着，未来安全检测的对象不能只是“文本”，还要包括“对话结构”。

强模型的安全性，有时体现为更高攻击成本

论文还分析了攻击预算，也就是每个有害目标允许尝试多少次。

结果显示，较弱模型很快就会被打穿。qwen3-8B 在 B=10 时 ASR@4 已经达到 100%，llama3.1:70B 在 B=10 时也达到 96%。相比之下，gpt-oss:120B 在 B=10 时 ASR@4 为 40%，ASR@5 为 28%；到 B=100 时，ASR@4 才提升到 90%，ASR@5 提升到 72%。

这个结果说明，强模型并不一定意味着“绝对不会被攻破”。很多时候，强模型的安全性体现为攻击者需要更多尝试、更高成本、更复杂搜索。

这对防御设计很重要。

如果攻击方法依赖自动化搜索，那么安全系统就不能只在单次请求上做判断。它还要看一段时间内是否出现大量相似意图、多轮诱导、失败后改写、语境重复构造等行为。速率限制、相似攻击聚类、会话级风险累计、异常历史消息检测，这些都不只是风控辅助能力，而是上下文攻击防御的一部分。

模型最容易在“诊断”和“机制分析”里失守

论文还做了 mutator 消融实验。作者最初考虑了 9 类 mutator，最终选择了 5 类：roleplay、scenario、expand、troubleshooting 和 mechanistic。

实验显示，只使用 roleplay、scenario、expand 这三个基础 mutator 已经很强，在 gpt-oss:20B 上能达到 96% ASR@4 和 86% ASR@5。加入 troubleshooting 后，峰值达到 100% ASR@4 和 90% ASR@5。进一步加入 mechanistic 后，整体预算曲线更均衡，因此论文最终选择 5-mutator 配置。继续加入更多 mutator 并不会持续提升效果，反而可能带来噪声，降低搜索效率。

更有意思的是 Table 4。

troubleshooting 在 ASR@1 到 ASR@4 的首次发现次数上最高，说明它特别擅长推动搜索从低质量输出逐渐进入高风险区域。mechanistic 在 ASR@3 和 ASR@4 上贡献很强，说明结构化、因果化、机制化的分析方式，容易把部分成功的攻击推进到更危险的阶段。expand 在 ASR@5 上贡献最高，更像一种最后补全策略。

从产品视角看，这个结果很重要。

很多安全策略会重点拦截直接危险请求，但对“帮我分析为什么失败”“解释一下机制”“从原理上讲这个过程怎么运作”这类输入更加宽松。因为这些话术表面上像是学习、研究、排障或教育。

但在上下文攻击里，这类话术恰恰可能成为高风险语境的入口。

这也解释了为什么大模型内容安全不能只做关键词分类。很多危险内容不是以“请求执行”的形式出现，而是以“请求解释”“请求诊断”“请求补全”“请求比较”的形式出现。模型一旦进入分析模式，输出就可能逐渐从抽象原理滑向可执行细节。

强模型上搜出的攻击，可能更容易打弱模型

论文还研究了攻击迁移。

在开源模型之间，迁移结果并不对称。比如从 120B 上发现的攻击模板，迁移到 8B、20B、70B 上，ASR@4 分别达到 70%、72%、46%。但从 8B、70B 上发现的模板迁移到 120B，效果很差，分别只有 2% 和 6%。

这对红队评测有实际意义。

如果为了降低成本，只在小模型上搜索攻击模板，然后把结果迁移到大模型上，可能得不到可靠结论。反过来，在更强、更难攻破的模型上搜索出来的上下文模板，可能更容易泛化到较弱模型。

换句话说，红队代理模型的选择会影响最终评估结论。不能简单用“小模型测一测”来代表真实高能力模型的安全风险。

不同厂商安全策略差异很大

论文还把在 gpt-oss:120B 上发现的 40 个满分攻击模板，原样迁移到闭源前沿模型上测试。

结果显示，这些模板在 gpt-4o-mini 上达到 90.0% ASR@4，在 gemini-3-flash 和 gpt-5 上都达到 70.0% ASR@4；但在 Claude 系列上明显更低，claude-opus-4-7 为 17.5%，claude-sonnet-4-6 为 15.0%。

这部分需要谨慎解读。

它不代表某个模型在所有场景下绝对更安全，也不代表可以简单做厂商安全排名。因为实验结果受样本集合、judge 体系、模型版本、调用设置和安全策略影响。

但它至少说明一点：上下文攻击的防御效果，不只取决于模型规模，也高度取决于对齐策略和安全训练方式。

如果两个模型能力相近，但一个模型在上下文诱导下更容易延续危险语境，另一个模型能在多轮对话中重新识别风险并中断，那么它们面对 Agent 安全风险时的表现会非常不同。

这对大模型安全产品意味着什么？

这篇论文对内容安全护栏、Agent 安全防护和自动化红队测试都有直接启发。

第一，安全检测要从“单轮检测”升级到“会话级检测”。

很多护栏现在仍然是每轮独立判断。用户输入来了，检测一次；模型输出前，再检测一次。这种方式在单轮内容安全场景下有价值，但面对上下文攻击会明显不足。因为风险不是突然出现在最后一句，而是被前文逐步铺垫出来的。

更合理的方式，是维护一个会话级风险状态。系统不仅要看当前 query，还要看前几轮是否出现角色绑定、危险场景构造、失败诊断、机制拆解、逐步补全等迹象。当这些迹象不断累积时，即使最后一轮请求本身看起来不明显，也应该触发更高等级的安全策略。

第二，要区分真实历史和伪造历史。

很多大模型 API 允许客户端直接传入 role-labeled messages。攻击者可以伪造一段“历史对话”，让模型误以为自己之前已经接受了某个角色、场景或任务。这篇论文使用的 simulated multi-turn dialogue，本质上就利用了这种接口形态。

因此，企业级大模型应用需要考虑上下文可信边界。哪些历史消息来自真实用户？哪些 assistant 消息是服务端真实生成的？哪些内容是客户端提交的？哪些工具结果可信？这些信息不能都被当成同等可信的上下文塞给模型。

第三，安全策略要允许模型打断前文承诺。

多轮对话中，模型很容易为了保持一致性而延续前文方向。但安全系统不能让“对话一致性”压过“风险重新判断”。即使模型前面已经进入某个角色或分析路径，到了后面识别到风险时，也应该能够明确中止，并说明前文方向存在安全问题。

第四，红队测试要从 Prompt 集合升级为对话轨迹集合。

过去我们做安全评测，常常准备一批敏感 query，或者准备一批 jailbreak prompt。现在看来，这还不够。面向多轮应用和 Agent 系统，测试集应该包含完整对话轨迹，包括角色建立、任务铺垫、工具返回、上下文污染、记忆写入、阶段性承诺和最终触发请求。

如果是 Agent 场景，还要继续扩展到工具调用链路。因为 Agent 的危险行为往往不是一句输出，而是多轮上下文、工具结果、环境状态共同作用后的执行行为。

第五，防御要提高攻击搜索成本。

ContextualJailbreak 本质上是一种自动化搜索方法。既然攻击依赖多次尝试和进化优化，防御也可以从搜索成本入手。比如对相似意图的多次尝试进行聚类，对反复改写的上下文进行识别，对异常长会话和高风险语义漂移进行告警，对同一用户或同一应用的连续失败攻击进行速率限制。

这类机制看起来不像传统内容安全能力，但在上下文攻击面前，它们会变成非常关键的防御层。

局限性

这篇论文结果很强，但也有几个局限需要注意。

首先，实验使用的是 HarmBench 中抽取的 50 个代表性行为，而不是完整的 400 个行为。作者这样做是为了降低冗余和计算成本，但也意味着结果仍然受样本选择影响。

其次，评测依赖 LLM-as-a-judge。论文使用了两级 judge，先由 barrier judge 过滤明显拒答，再由 main judge 做 0 到 5 分 harm score。这个设计比单一 judge 更稳，但仍然不能完全消除自动评测偏差。

第三，论文没有公开完整成功攻击模板库。作者明确提到，由于这些模板对多个高能力模型具有绕过能力，完整攻击数据库不会公开，只会在负责任披露框架下与相关方共享。

这也是本文没有展开具体攻击样例的原因。对安全研究来说，真正值得学习的是风险机制和防御思路，而不是复现攻击细节。

写在最后

ContextualJailbreak 最重要的价值，不是提出了一种新的越狱技巧，而是把大模型安全问题往前推进了一层。

早期我们关注有害输入，后来关注有害输出。到了多轮对话和 Agent 应用阶段，真正需要关注的是 有害上下文。

上下文不是背景材料，它会改变模型的判断方式。前文对话、角色设定、工具结果、记忆内容、任务链路，都可能成为攻击载体。模型越擅长保持连贯，越擅长理解复杂语境，也就越需要更强的上下文安全机制。

这篇论文给大模型安全产品提出了一个很现实的问题：

如果攻击者已经不再攻击某一句 Prompt，而是在攻击整个会话状态，那么我们的护栏还停留在单轮输入输出检测，就一定会漏掉很多真正危险的东西。