OpenART: Scaling Agent Red Teaming via Open-Ended Environment Evolution

  • 关联论文：2608.00677
  • 作者：Tom
  • 更新：2026-08-13

一句话结论

OpenART 通过环境演化与 EMHA 攻击策略，在 50 个领域、超过 10,000 个有状态场景中对 AI Agent 安全进行了系统性红队评估，揭示了 Agent 运行时实现方式对安全性的影响远超底层模型本身——pooled ASR 达 85.0%。

解决什么真问题

现有 Agent 安全基准聚焦于短时、静态任务，无法捕捉「状态累积」带来的复合风险。真实世界 Agent 在持久化环境中运行：早期状态变更会影响远期决策，且同一份状态被多个工作流反复修改复用。当前的 benchmark 场景往往是一次性交互，缺乏对「攻击者通过演化环境发现累积性漏洞」能力的评估。

OpenART 要解决的核心问题：如何系统性地评估 Agent 在复杂、持续演化环境中的安全风险？

核心方法

OpenART 基准架构

OpenART 包含三大核心组件：

  1. 有状态场景库：50 个领域、10,000+ 验证过的有状态场景；中位数需要 97 次工具调用才能完成单一任务——这对短任务基准是完全不现实的。
  2. 工具与技能池：超过 500,000 工具和技能，支撑场景的多样性。
  3. 统一评测框架：覆盖 75 种不同 Agent-模型配置。

EMHA 攻击算法（Evolutionary Markov Hypergraph Attack）

EMHA 是全文最关键的方法创新。它是一个黑盒策略，核心机制：

EMHA(environment, agent, feedback):
  state = initialize(environment)
  hypergraph = build_hypergraph(state)
  while not converged:
    # 协调授权状态转换（authorized state transitions）
    proposed_changes = sample_from_hypergraph(state)
    # 反馈驱动环境演化（feedback-driven environment evolution）
    new_state = apply_changes(proposed_changes)
    feedback = evaluate(agent, new_state)
    hypergraph = update(hypergraph, feedback)
    # 无需更新任何模型参数
  return hypergraph

关键特性： - 黑盒：不依赖 Agent 内部权重，仅通过观察 Agent 行为与状态变化反馈 - 无需参数更新：完全通过协调授权状态转换推进攻击面 - 任务目标固定，环境状态演化：攻击者只能在环境层面试探，任务本身不变

复杂度分层设计

EMHA 的评估按环境复杂度分层：简单环境 vs 最复杂环境，揭示了有意思的规律——随着任务复杂度提升，EMHA 相对纯指令演化（instruction-only evolution）的优势从 ~2% 扩大到 >17%。这说明环境演化攻击在高复杂度场景中尤为关键。

关键实验与数据

指标 数值
Pooled Attack Success Rate (ASR) 85.0%
场景规模 10,000+ 有状态场景
领域覆盖 50 个领域
工具池规模 500,000+ 工具/技能
Agent 配置数 75 种
中位数工具调用次数 97 次
EMHA vs 指令演化（简单环境） +2% ASR
EMHA vs 指令演化（最复杂环境） +17% ASR

⚠️ 数字核验：上述数字均来自 arXiv abstract 原文；ASR 85.0% 是所有配置的 pooled 结果，具体领域分布原文未分项列出；EMHA 的 +2%/+17% 差值原文在何种 ASR 基准线上计算未说明。

核心发现：Agent 的运行时实现（runtime implementation）对安全性的影响占显著比例——超出底层模型能力本身。这实际上是说：同样的 LLM，用不同框架/工具链/状态管理方式部署，安全性差异巨大。

亮点与局限

亮点： 1. 规模最大：10,000+ 有状态场景，覆盖 50 领域，显著超越此前 Agent 安全基准的复杂度与广度 2. 新攻击范式：EMHA 无需模型权重更新，通过环境演化揭示了「纯指令无法触达」的安全漏洞 3. 复杂度放大效应：首次量化了任务复杂度与攻击有效性之间的非线性关系（+2% → +17%） 4. 运行时实现效应：将 Agent 安全的关注点从「模型本身」延伸到「部署方式」，拓宽了整个安全研究视野

局限 / ⚠️ 存疑： 1. ASR 成功定义模糊：原文未明确"攻击成功"是指 Agent 产生了不安全行为，还是产生了预期外（偏离任务目标）的行为——这两者在安全研究中干预策略完全不同 2. 75 种配置未分项列出 ASR：跨模型、跨框架还是跨工具集？各配置 ASR 差异是否显著？原文未分项，给后续对比研究造成困难 3. ⚠️ "500,000 工具"可能指调用次数而非独立工具数：需核验原文；若是累计调用量而非独立工具数，则对"工具池规模"的表述存在量级误导风险 4. 防御建议缺失：作为红队研究，EMHA 发现了大量漏洞，但系统层面如何防御，论文未给出系统化建议

对工程落地的启发

  1. Agent 部署前的红队必测长尾任务：仅用短任务（<10 步）测 LLM 安全性不够——97 步中位数才能暴露的问题，5 步测试完全测不到
  2. 关注状态管理基础设施：运行时实现比模型更能解释安全差异，部署 Agent 时应把状态隔离、访问控制、状态回滚视为安全基础设施
  3. 工具池质量 > 模型质量：500,000 工具/技能库的规模提示，Agent 安全的「攻击面」在工具层，防御思路应从「选更安全的模型」转向「更安全地调用工具」
  4. EMHA 思想可直接迁移：EMHA 的黑盒环境演化攻击框架不依赖特定模型，任何 Agent 系统都可以用类似方法做内部红队

与同方向工作的关系

OpenART 站在 Agent 安全评测的演进脉络上：

  • 与 AgentBench / AgentBoard 的关系：两者都是评测基准，但 OpenART 的核心区别是有状态、长时间跨度的演化环境，而非静态单轮或多轮对话
  • 与 RAVER / Red Teaming LLM 的关系：传统红队研究多聚焦于文本/对话层面（如 prompt injection、jailbreak），OpenART 扩展到了 Agent 执行层面的状态空间攻击
  • 与 ToolLeak / ToolHarm 的关系：工具泄露/恶意工具是 Agent 安全的已知威胁，OpenART 的 EMHA 从系统层面演化攻击面，工具池规模（500,000+）意味着这类风险在 OpenART 中被更充分地覆盖

一句话定位：OpenART = Agent 安全的「环境演化红队」，填补了长时序有状态场景下 Agent 安全评测的空白。

适合谁读

  • Agent 安全研究者：必读——当前规模最大的有状态 Agent 红队评测
  • LLM/Agent 工程师：重点读 §4（运行时实现对安全的影响）和 §5（工程启发），理解自己的系统在什么规模下会出现「状态累积漏洞」
  • Agent 评估与合规团队：OpenART 的 50 领域覆盖提供了跨行业安全评测的参考框架
  • RL/Agent 训练研究者：环境演化思想（EMHA）可用于设计更健壮的 Agent 训练任务

工程落地与核查（Jay）

落地路径与实际系统集成

OpenART 的工程落地主要分为三个层次：

1. 直接集成（适用于 Agent 安全团队） - OpenART 的评测框架本身可以作为内部红队的标准化测试床 - 输入：待测 Agent 系统（API 接口）+ 场景库；输出：ASR + 漏洞分类报告 - 关键技术依赖：Agent 的黑盒可观测接口（行为日志、状态变更追踪），无需源码或权重访问 - ⚠️ 注意：框架本身是否开源未确认；若未开源，搭建同等规模评测环境成本极高（10,000+ 场景需大量人工标注）

2. 借鉴 EMHA 思想做轻量红队（适用于自研 Agent 团队） - EMHA 的核心思想——「反馈驱动环境演化 + 无需模型更新」——可以直接在内部复现 - 最小化可行实现：固定 Agent 对话接口 → 用脚本模拟状态变更 → 用 ASR 作为攻击反馈信号 - 关键陷阱：环境复杂度不够（< 50 步工具调用）时，EMHA 相对纯指令演化的优势消失（仅 +2%），投入产出比极低 - 建议从「有状态操作序列」（文件读写、数据库写入、API 调用）场景入手，逐步叠加复杂度

3. 用 OpenART 结果做选型依据（适用于采购 Agent 系统的团队） - 直接引用 85.0% pooled ASR 做采购评分权重需要谨慎：各配置 ASR 未分项，模型间差异未知 - 更合理的用法：以「运行时实现影响 > 模型能力」这一核心结论指导合同安全条款——要求供应商提供状态隔离、访问控制、审计日志的明确 SLO

主要坑点

坑点 具体表现 应对方式
场景复现成本高 10,000+ 有状态场景需人工设计与验证 从 50 领域中选 1-2 个核心领域做定向复现，而非全量复现
ASR 定义不一致 "攻击成功"定义未明确，跨团队对比无效 落地前先与团队对齐「不安全行为」的判定标准（建议用 LLM-as-judge + 人工复核双轨）
状态空间爆炸 EMHA 在高复杂度场景下 hypergraph 规模指数增长 设置演化轮次上限（如 max_steps=500）做工程截断
工具池规模误导 ⚠️ 500,000 可能是调用量而非独立工具数 落地前 fetch 核验原文措辞；若是调用量，则有效工具数远小于此值
黑盒假设过强 EMHA 完全不依赖 Agent 内部状态，真实系统往往有半黑盒接口 对有内部状态 API 的系统，可以在状态转换节点加 hook 获取更细粒度反馈信号

未解决问题

  1. 75 种配置的 ASR 分布未公开：无法判断哪个模型/框架/工具集是主要漏洞来源，有针对性的防御策略无从制定
  2. EMHA 超参未公开：hypergraph 更新频率、converged 判断标准、采样策略等关键超参未披露，复现困难
  3. 防御策略缺失：论文本身缺乏系统级防御建议，落地团队需要自行设计状态隔离、访问控制方案，缺乏参考基准