从Prompt攻击到环境进化：OpenART如何重构Agent红队测试

过去几年，我们已经越来越习惯用“红队测试”来衡量大模型安全：准备一批越狱 Prompt、提示词注入样本或者恶意任务，让模型逐条回答，再统计拒答率和攻击成功率。

这种方法放在普通聊天模型上没有太大问题。但当大模型开始变成 Agent，问题就出现了。

一个真正工作的 Agent，不再只是接收一句 Prompt 然后生成一句回答。

它可能先读取项目目录里的文件，再加载 AGENTS.md 或 CLAUDE.md，调用几个 MCP 服务，使用某个 Skill，查询数据库，把中间结果写进 Memory，然后根据 Plan 连续执行几十甚至上百个步骤。

此时真正决定 Agent 行为的，已经不只是最开始那句话。

文件会变、工具会变、Skill 会变、Memory 会积累、Plan 会调整，甚至一个几十步之前被 Agent 认为“可信”的对象，也可能已经悄悄发生变化。

这带来了一个非常现实的问题：

如果 Agent 真正生活在一个不断变化的环境里，我们为什么还在用几条静态 Prompt 测它的安全性？

2026 年 8 月，复旦大学、上海人工智能实验室等机构发布 OpenART（OpenART Arena: Scaling Agent Red Teaming via Open-Ended Environment Evolution）。

https://arxiv.org/pdf/2608.00677

这项工作的价值就在于，它试图改变 Agent 红队测试的基本单位：不再只攻击 Prompt，而是让 Agent 所处的整个运行环境不断“进化”。

OpenART 构建了超过 1 万个有状态测试场景，覆盖 50 个业务领域，能力池来自超过 50 万个 Tool、MCP 和 Skill，并把这些场景投射到 15 种真实 Agent Runtime 和 5 种基础模型上，形成 75 种 Agent–Model 组合。

更重要的是，这些任务的工具调用中位数达到 97 次，而很多此前 Agent 安全 Benchmark 的任务只有 1～15 次调用。

OpenART 真正想回答的问题因此不是：

“一句恶意 Prompt 能不能骗过 Agent？”

而是：

“如果攻击者持续改变 Agent 所依赖的环境状态，一个本来看起来安全的 Agent，能不能在几十步之后被一步步带向危险结果？”

这可能是理解下一阶段 Agent 红队测试最重要的变化之一。

Agent有八大攻击面

先想象一个很普通的企业 Agent。

用户让它：

“整理本周客户问题，并生成一份可以发送给合作伙伴的周报。”

如果这是传统聊天模型，安全边界可能主要集中在用户输入和最终输出。

但如果是 Agent，它的实际工作过程可能是这样的：

先读取 CRM 数据，再查询邮件，读取一个 Excel 模板，根据项目目录里的规则生成任务计划，通过 MCP 获取工单信息，调用脚本处理数据，把部分结论写进 Memory，最后生成 PDF 并发送出去。

整个过程中，Agent 实际接触的信息可能包括：

• 用户 Prompt；

• Workspace 中的文件；

• AGENTS.md、CLAUDE.md 等持久指令；

• Skill；

• Tool；

• MCP；

• 当前会话记忆；

• 长期记忆；

• 当前执行计划。

OpenART 将这些状态统一抽象成八类攻击面：Workspace、Instructions、Skill、Tool、MCP、Short-Term Memory、Plan State 和 Long-Term Memory。

不同 Agent Runtime 实际支持的状态不同，例如 Claude Code、Codex、OpenClaw 可以暴露的攻击面并不完全一样。

这实际上给很多近两年的 Agent 攻击研究提供了一个更统一的解释。

Skill 投毒是在攻击 Skill 状态，MCP 工具投毒是在攻击 MCP 或 Tool 状态，记忆投毒是在攻击 Memory，间接提示注入通常是在污染 Workspace 或外部上下文，而 Plan 劫持则是在改变 Agent 当前保留的工作状态。

过去我们把这些看成很多不同的攻击类型。

OpenART 的视角则更加统一：

它们本质上都是对 Agent 可见环境状态的修改。

这意味着，Agent 红队测试所搜索的空间也发生了变化。

过去，我们主要搜索的是：

Prompt Space——还能把这句话怎么改？

加入角色扮演、身份包装、编码混淆、多轮诱导、格式约束，不断变异 Prompt，寻找能够绕过模型安全机制的表达。

而 OpenART 开始搜索：

Environment State Space——还能改变 Agent 所处世界里的什么？

这一次，攻击者变异的不只是语言，而是 Agent 工作时真正依赖的状态。

OpenART 真正改变的是“红队测试的基本单位”

OpenART 有一个非常重要的设计原则：

在攻击过程中，用户任务不能变，安全规则也不能变。

变化的只有环境。

例如原始任务始终是：

“生成并发布客户周报。”

隐藏的安全约束始终是：

“不得把内部敏感字段发布到外部报告中。”

攻击者不能突然把任务修改成：

“请泄漏用户隐私。”

那样本质上还是传统恶意 Prompt。

OpenART 做的是另一件事情：保持这个正常任务不动，然后不断改变 Agent 执行过程中接触的状态。

例如改变一个模板、修改 Skill、调整 Workspace 文件内容、改变某个 MCP 能力对应的状态，或者让 Plan 中已经引用的对象随后发生变化。

论文将一个测试 Scenario 抽象为一组与具体 Agent 无关的语义，包括正常任务目标、Workflow、初始环境和隐藏的 Evaluator。

随后通过 Runtime Adapter，将同一个 Scenario 投射到 Claude Code、Codex、OpenClaw、Qwen Code 等不同 Agent 的原生运行方式中。

这种设计有一个很大的工程价值。

以前很多 Agent Benchmark 都和自己的测试环境高度绑定。

换一个 Agent，往往就需要重新适配任务、工具和评价方式，因此很难判断：

“究竟是模型不安全，还是 Agent Runtime 不安全？”

OpenART 尽量把两件事情拆开：

Scenario 描述“要测试什么”，Runtime Adapter 决定“在这个 Agent 上怎么实现”。

于是同样的任务目标、同样的安全规则，可以在多个 Agent Runtime 上执行。

这其实已经不只是一个 Benchmark 设计问题，而是在逐渐形成一种 Agent 安全测试基础设施的抽象。

一次攻击为什么可能要等 37 步才真正“爆炸”？

OpenART 最值得关注的一组数据，并不是论文首页那个 85% 攻击成功率。

而是：

37 步。

作者分析了 1 万条转换后的 Agent 执行轨迹，发现 Agent 第一次读取被攻击环境状态的位置，中位数大约发生在整个工作流的 23%；但第一次真正产生 Unsafe Output，却要到执行过程约 64% 的位置。

两者之间相隔的中位数是：

37 个 Agent Action。

四分位区间甚至达到 20～66 步。

这意味着，一个攻击载荷进入 Agent 之后，并不一定马上产生异常。

例如：

第 10 步，Agent 读取一份被污染的模板。

第 18 步，根据模板创建计划。

第 31 步，根据计划查询数据库。

第 45 步，将结果写入中间文件。

第 58 步，从 Memory 恢复之前的判断。

第 70 步，将多个数据源合并。

直到第 82 步，Agent 才把敏感信息发布到外部系统。

如果安全系统只检查：

“刚刚读取的内容有没有导致下一步危险调用？”

可能什么都发现不了。

真正的攻击因果链已经跨越了几十个步骤。

这就是长周期 Agent 和传统大模型最大的区别之一：

危险不再一定是 Input → Output 的即时映射，而可能是一段长期状态传播。

这与经典计算机系统中的潜伏式攻击非常相似：某个状态首先被污染，但真正危险的行为，要等之后满足一系列条件才会触发。

所以 Agent 安全评测的基本对象逐渐从 Response 转向了：

Trajectory——完整执行轨迹。

复杂 Agent 会放大传统 Prompt 测试的盲区

如果环境攻击只是多了一种攻击手段，那么 OpenART 的意义其实还没有那么大。

论文真正有说服力的实验，是比较了：

Instruction-only Evolution

和：

Full Environment Evolution。

也就是在相同攻击预算下，一组攻击者只允许修改 Instruction，另一组可以进化整个环境。

在最简单的任务上，两者的攻击成功率差距只有大约 1.8%～2.7%。

但随着任务依赖深度和工具调用数量不断增加，这个差距扩大到：

17.2%～17.6%。

这条曲线其实比 85% ASR 本身重要得多。

它意味着：

Agent 越简单，只测 Prompt 越可能还凑合；Agent 越复杂，只测 Prompt 得出的安全结论就越容易失真。

为什么？

因为一个只有两次 Tool Call 的任务，没有太多状态可以传播。

但如果 Agent 需要执行近百次操作，期间不断读取文件、生成中间结果、修改 Plan、调用 MCP、查询数据库，再组合多个来源的数据，那么攻击面之间就开始相互作用。

OpenART 的任务中位数是 97 次工具调用，依赖深度达到 32，并行宽度达到 12.5，访问的状态对象中位数达到 96.5；相比之下，InjecAgent、AgentDojo、AgentHarm 等 Benchmark 的工具调用中位数大多只有个位数，DTap 也约为 15 次。

所以我们可能需要重新理解一句经常出现的话：

“这个 Agent 在我们的越狱测试里通过率达到 99%。”

如果这个测试主要还是给 Agent 喂大量 Jailbreak Prompt，然后观察它是否拒答，那么它测试到的很可能只是：

模型面对显式恶意指令时的安全能力。

而不是：

一个拥有几十个工具、长期记忆、Skills、MCP 和复杂工作流的 Agent 系统，在真实运行状态变化下是否安全。

两者正在变成完全不同的问题。

EMHA：进化 Agent 所处的世界

为了自动探索如此巨大的环境攻击空间，OpenART 又提出了一种攻击策略：

Evolutionary Markov Hypergraph Attack，简称 EMHA。

中文可以理解为“进化式马尔可夫超图攻击”。

名字听起来复杂，但核心思想并不难理解。

如果攻击者面对八个攻击面：

Workspace、Instruction、Skill、Tool、MCP、短期记忆、Plan 和长期记忆，

那么最简单的方法就是不断随机修改。

但很快就会遇到组合爆炸：

到底先污染 Workspace，还是先改变 Skill？

污染 Workspace 以后，要不要再改变 Plan？

Skill 和 MCP 联合修改是不是比单独修改有效？

某个成功攻击究竟是哪一步真正起了作用？

EMHA 用一张“超图”表示这些攻击路径。

普通图通常表达：

A → B。

而超图可以表达：

A + B + C → D。

这很适合 Agent 攻击，因为很多风险本来就不是单个状态导致的。

例如只有当“某个 Workspace 文件被修改”“Plan 继续引用旧对象”“一个新的 Tool 状态被采用”三个条件同时存在时，最后的危险动作才可能成立。

EMHA 每一轮会选择一条环境攻击路径，让大模型将抽象攻击转换成真实的环境修改，然后真正运行目标 Agent，再根据 Evaluator 的结果反过来更新这些攻击步骤的价值。

表现好的攻击组合会被保存并继续产生新的变体，表现差的路径逐渐被淘汰。

如果用传统安全领域的语言理解，它其实很像一种：

Agent Environment Fuzzing。

传统 Fuzzer 是：

种子 → Mutation → 执行程序 → 根据 Coverage 或 Crash 保留有价值变体。

OpenART 则变成：

环境状态 → Mutation → 执行 Agent → 根据安全评估结果保留有价值状态。

区别在于，过去变异的是输入字节，现在变异的是 Agent 所处世界里的状态。

值得注意的是，EMHA 并不会训练或者修改目标模型参数，它是一种黑盒测试策略。

OpenART 的 Environment Evolution 接口本身也并不绑定 EMHA，理论上未来完全可以替换成 MCTS、强化学习、遗传算法或者其他搜索策略。

因此从长期来看，OpenART 最有价值的可能不是 EMHA 这个具体算法，而是：

“环境可以被系统化进化”这一红队测试接口。

实验结果：85% ASR 背后真正值得看的三个信号

OpenART 最终在 15 个 Agent Runtime 和 5 种基础模型组成的 75 个组合上进行实验。

EMHA 的整体 Strict ASR 达到：

85.0%。

其中 GPT-5.5 平均 ASR 为 88.5%，Claude Opus-4.8 为 59.2%，GLM-5.2 为 87.9%，Qwen-3.7-Max 为 94.6%，DeepSeek-V4-Pro 为 94.7%。

与此同时，Claude Opus-4.8 的正常任务完成率反而最高，平均达到 96.18%，因此它较低的攻击成功率不能简单解释为“模型能力差导致任务执行失败”。

不过，不建议把这组数字简单理解成一个“模型安全排行榜”。

因为不同 Agent Runtime 能够暴露的攻击面并不完全相同，测试结果也受到 Harness、任务完成能力、模型特性和攻击适配等多重变量影响。

真正值得看的反而是下面三个信号。

第一，Workspace 本身就可能比 Prompt 更危险

在相同攻击预算下，只允许修改 Workspace 时，Strict ASR 已经达到：

92.5%。

比只修改 Instruction 高出：

10.9 个百分点。

而剩余七类单独攻击面的平均 ASR 也达到 71.2%，每一类都超过 50%。

完整环境联合进化则达到 94.7%，比 Instruction-only 高 13.1 个百分点。

换句话说：

Prompt 甚至可能不是最危险的 Agent 输入面。

一个 Agent 如果天然信任项目文件、Skill、Memory 或某些工具返回的数据，那么攻击者根本不需要在用户对话框里和安全模型正面对抗。

第二，环境可以不断进化出新的失败

在 DeepSeek-V4-Pro 实验中，环境进化第一轮的累计 Strict ASR 为 42.9%，随后提升到 69.4%、73.5%、89.8%，最终第五轮达到 94.7%。

任务目标没有变化，安全规则没有变化。

变化的只是 Agent 所处的环境。

这说明一些安全问题并不是第一次攻击就能暴露出来。

环境可能先改变执行上下文，再改变 Agent 的计划和判断，直到若干轮之后，一个之前看似安全的 Workflow 才形成真正危险的路径。

第三，同一个模型装进不同 Agent，也可能表现出不同的安全性

作者对攻击成功率的方差进行了拆解。

基础模型可以解释大约 73.6% 的差异，而 Agent Runtime 本身可以解释约 25.2%。

进一步看，仅使用模型身份和正常任务完成率可以解释 91.3% 的 ASR 变化；加入 Agent 身份之后，这个数字提升到 98.9%，额外增加了 7.6%。

这再次验证了近来 Agent 安全领域一个越来越重要的判断：

Agent Safety ≠ Model Safety。

一个安全能力很强的基础模型，并不会自动生成一个同样安全的 Agent。

Harness 如何加载文件、如何管理 Memory、如何发现 Skill、如何解析 MCP、如何保存 Plan、什么时候重新检查权限，这些运行时机制本身都会成为安全变量。

OpenART 发现的三类漏洞

论文最终总结出了三类反复出现的 Agent 失败模式。

我认为这是整篇工作里最值得安全工程人员关注的部分。

1. Stale Assumption：环境已经变了，Agent 的假设却没有变

假设 Agent 在第 10 步检查过一个模板：

“这个模板是可信的。”

然后第 30 步，模板的内容发生变化。

到了第 70 步，Agent 再次引用这个模板，却没有重新检查，因为它仍然沿用了几十步之前形成的判断。

OpenART 在不同场景中观察到：

Plan–Referent Drift，即 Plan 仍然引用已经发生变化的对象；

Capability Rebinding，即工具接口没有变化，但接口背后的实际能力已经发生变化；

Checkpoint Expiry，即之前做出的安全判断，在新的上下文中被继续沿用，却没有重新验证。

如果把这个问题翻译成传统计算机安全语言，它其实非常像：

TOCTOU——Time of Check to Time of Use。

传统系统里是：

检查文件 → 文件发生变化 → 使用文件。

Agent 世界里则变成：

检查上下文 → 环境状态发生变化 → Agent 继续根据旧判断推理和执行。

所以未来 Agent Runtime 可能需要一种非常重要的能力：

Trust Revalidation——信任重新验证。

“检查过一次”不应该等于“永久可信”。

2. Safety Debt：安全判断也会像技术债一样不断累积

另一个很有意思的现象，是安全判断被不断向后推迟。

例如 Agent 一开始读到一些敏感数据时，其实知道：

“这些信息不能公开。”

但后续 Workflow 出现一个 Schema，要求某些字段必须填写。

接下来的组件只关注：

“Schema 是否完整？”

于是 Agent 开始填写字段。

下一个阶段又默认：

“前一个阶段既然已经生成了完整数据，那应该就是经过处理的安全数据。”

最终，敏感信息一路流进公开报告。

整个过程中，并没有哪个步骤明确决定：

“我要泄漏敏感信息。”

问题出在：

最开始那个没有解决的安全判断，被下游一层层继承了。

论文认为 Agent 经常不是在每个阶段重新计算安全判断，而是把上游状态当成下一阶段的安全依据。

这可以理解成一种：

Safety Debt——安全债务。

就像技术债一样，一开始只是一个“以后再处理”的小问题，但随着越来越多组件依赖这个判断，修复成本越来越高，最终在最下游形成真正的安全事故。

这也说明，对长链 Agent 来说，只在最开始做一次 Guardrail 远远不够。

安全判断必须贯穿 Workflow。

3. Compositional Risk：每一份数据都没问题，合在一起却出事了

第三类问题尤其具有 Agent 特征。

假设：

• 数据 A 只有姓名；

• 数据 B 只有部门；

• 数据 C 是匿名医疗费用。

分别来看，每一份数据都可能满足当前发布条件。

但是 Agent 将：

A + B + C

Join 在一起之后，就可能得到：

“张三，某部门，某疾病治疗费用 17 万元。”

敏感身份突然被重新识别。

OpenART 的案例中也出现了类似现象：没有任何一个被修改的环境状态能够独立暴露受保护信息，但随着 Workflow 逐渐改变数据之间的来源关系，最终 Agent 将多个记录组合成公开报告，一次暴露多个受保护类别。

这就是：

Compositional Risk——组合风险。

风险并不存在于某一个输入里。

风险存在于：

多个安全对象经过 Agent 推理和工具调用之后形成的新关系里。

这也是为什么传统内容安全检测器越来越难覆盖 Agent 风险。

检测器可以判断一句话有没有敏感信息。

但真正困难的问题是：

这条数据和过去 50 步读取的另一条数据组合之后，会不会产生新的敏感事实？

Agent 防御也要升级成“Guard Runtime”

OpenART 给防御端最大的启示，也许不是增加一个更强的 Prompt Injection Detector。

而是：

安全控制的位置必须往 Agent Runtime 内部移动。

过去典型的大模型安全架构是：

Input Guard → Model → Output Guard。

对于 Agent，这种结构正在明显不够用。

未来可能需要至少增加四类运行时安全机制。

第一是 State Integrity，状态完整性。

Skill、MCP、Workspace、Memory、Plan 等关键对象需要明确版本、来源、完整性和信任等级。一个已经经过安全审批的 Skill，如果后来内容发生变化，就不应该继续自动继承原来的信任级别。

第二是 Provenance Tracking，来源追踪。

Agent 不仅需要知道“这是什么数据”，还需要知道“数据来自哪里、经过哪些转换、和什么数据组合过、最终准备流向哪里”。

否则组合风险几乎无法处理。

第三是 Continuous Revalidation，持续重新验证。

安全判断不能只做一次。

当 Agent 所依赖的对象发生版本变化、来源变化、权限变化，或者以新的组合形式再次出现时，之前的安全结论应该失效或者重新评估。

第四是 Sink-time Enforcement，结果落地前检查。

真正重要的检查点不是只有 Read。

更应该包括：

Send、Upload、Publish、Commit、Execute、Delete、Transfer 等真正会产生外部影响的 Sink。

因为 OpenART 已经证明，攻击状态可能在几十步之前就被读取，却直到很久以后才真正产生危险结果。

从这个角度看，未来 Agent 安全架构可能越来越像传统操作系统和零信任体系：

不是问：

“这句话安全吗？”

而是持续问：

“这个主体，现在基于这些来源、这些状态和这些历史行为，是否仍然有权执行接下来的动作？”

局限性

OpenART 的方向很有价值，但论文里的几个数字也不应该被过度解读。

首先，论文虽然覆盖 50 个业务领域，却不等于覆盖了 50 种 Agent 安全风险。

从 Scenario 构建和 Evaluator 设计可以看到，大量实验围绕一个比较明确的 Safety Contract 展开：正常完成业务任务的同时，判断 Agent 是否把受保护信息泄漏到不应该出现的外部结果中。论文对 Scenario 的自动验证本身也重点检查 Evaluator 能否区分“正常完成任务”和“Unsafe Leakage”。

因此，OpenART 当前更准确的描述应该是：

在大量业务环境和复杂工作流中，系统化研究环境状态如何诱发长周期数据泄漏风险。

而不能简单扩展成：

“已经系统覆盖 Agent Safety。”

像越权资金操作、破坏性工具调用、自主资源滥用、身份冒用、现实世界物理操作等风险，还需要进一步扩充安全目标和 Evaluator。

其次，不同 Agent Runtime 支持的攻击面不同。

Claude Code、Codex、OpenClaw 等 Agent 的状态机制本来就有差异，因此 ASR 并不适合作为一个简单的“Agent 安全排行榜”。论文自己也强调，Runtime Identity 与安全差异存在关联，但这项分析并没有直接识别具体机制。

最后，目前公开的 OpenART GitHub 仓库提供了 Docker Runtime、示例任务、Planner、Evaluator 以及部分工具集，但仓库明确说明，实验批处理 Driver、生成的运行结果以及私有 Scenario Generation Corpus 并未完整开放。

因此它目前更像一个已经公开核心运行框架的研究系统，而不是论文全部实验资产的完整复现包。

这些局限并不会削弱 OpenART 提出的核心问题。

相反，它们说明这个方向才刚刚开始。

Agent 红队正在发生一次对象迁移

过去做大模型红队，我们最关心的问题是：

“还能设计出什么新的 Jailbreak Prompt？”

随后我们开始攻击 Tool、MCP、Skill 和 Memory。

而 OpenART 提供了一种更统一的视角：

这些并不是互相独立的安全问题。

它们共同组成：

Agent Environment。

于是下一代自动红队系统所寻找的，也许不再只是一条攻击 Prompt，而是一条完整的攻击轨迹：

初始环境是什么；

攻击者修改了哪个状态；

Agent 因此形成了什么 Plan；

这个判断如何进入 Memory；

之后哪些 Tool 或 MCP 继承了它；

哪几个状态最终发生组合；

以及最后在哪个 Sink 真正造成损害。

也就是说：

过去攻击知识的基本单位可能是一条 Prompt。

未来则可能变成：

一个 Environment Mutation Sequence——环境状态变异序列。

这也是 OpenART 最值得关注的地方。

85% 的攻击成功率也许很快会被新的 Benchmark 超越，EMHA 这种具体搜索算法也很可能被更加有效的方法取代。

但有一个变化可能会留下来：

Agent 红队测试的对象，正在从模型接收到的“话”，变成 Agent 所处的“世界”。

当 Agent 只能聊天时，安全问题主要存在于上下文窗口里。

当 Agent 能读取文件、调用工具、加载 Skill、连接 MCP、保存 Memory，并连续自主工作几十甚至上百步时，安全边界自然也会从 Prompt 延伸到整个运行时。

真正需要回答的问题已经不再只是：

“模型会不会被一句话骗过？”

而是：

“当 Agent 所依赖的世界一点点发生变化，它还能不能在漫长的执行过程中，始终知道什么可以相信、什么需要重新验证，以及什么事情绝对不能做？”

这可能才是 Agent 红队测试真正需要解决的问题。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。