当 Agent 开始自主调用工具、连续执行多步任务，安全风险就不再只藏在一句“明显恶意”的 prompt 里。

有时，前面只是一次看起来正常的信息读取；后面却在多轮上下文、工具反馈和环境状态的共同作用下，慢慢演变成风险。也有时，最终回复看起来没问题，但真正的失误早就发生在中间某一次工具调用、某个审批边界，或者某段被误信的环境反馈里。

这也是上海人工智能实验室这条研究线最值得关注的地方：它把 Agent 安全评测从“看一句回答”推进到“看整条执行轨迹”，再进一步推进到 OpenClaw 和 CodeX 这类具体执行环境。

换句话说，未来的 Agent benchmark 比拼的不只是模型会不会答题，而是它能不能在真实系统边界里可控地完成任务。

论文标题：

ATBench: A Diverse and Realistic Agent Trajectory Benchmark for Safety Evaluation and Diagnosis

论文作者：

Yu Li,  Haoyu Luo, Yuejin Xie, Yuqian Fu, Zhonghao Yang, Shuai Shao, Qihan Ren, Wanying Qu, Yanwei Fu, Yujiu Yang, Jing Shao, Xia Hu, Dongrui Liu

作者机构：

上海人工智能实验室、复旦大学，上海交通大学、清华大学、阿卜杜拉国王科技大学、华东师范大学

论文链接：

https://arxiv.org/abs/2604.02022

论文标题：

Benchmarks for Trajectory Safety Evaluation and Diagnosis in OpenClaw and Codex: ATBench-Claw and ATBench-Codex

论文作者：

Zhonghao Yang, Yu Li, Yanxu Zhu, Tianyi Zhou, Yuejin Xie,  Haoyu Luo, Jing Shao, Xia Hu, Dongrui Liu

作者机构：

上海人工智能实验室

论文链接：

https://arxiv.org/abs/2604.14858

Github链接：

https://github.com/AI45Lab/AgentDoG

huggingface链接：

https://huggingface.co/collections/AI45Research/agentdog

01

从 ATBench 开始：Agent 安全评测要看整条轨迹

ATBench 是一个面向 Agent 安全评测与诊断的轨迹级 benchmark。它的核心观点很直接：对于具备工具调用和多步执行能力的智能体，只看最后答得对不对，已经不够了。

真正要评估的，是模型是否理解一整条任务轨迹里的安全风险。

这条轨迹里会包含用户任务、Agent 思考、工具调用、环境响应和最终回答。风险可能来自用户输入，也可能来自环境观察、工具接口、工具反馈，甚至来自 Agent 自身的规划和推理失败。

ATBench 因此把 Agent 安全风险组织成三个维度：

- Risk Source：风险从哪里来

- Failure Mode：失败如何发生

- Real-world Harm：最后会造成什么现实伤害

这让 benchmark 不只是判断一条轨迹是 safe 还是 unsafe，还能继续追问：风险源头是什么，模型在哪个环节失败，最终可能造成什么后果。

ATBench 的难点不在于“多几个 case”，而在于它把风险放回了更接近真实世界的长链条执行中。

论文中提到，ATBench 包含：

- 1,000 条轨迹

- 503 条 safe / 497 条 unsafe

- 平均 9.01 轮交互

- 平均 3.95k tokens

- 1,954 次真实工具调用

- 工具池覆盖 2,084 个可用工具

这些轨迹不是简单模板拼接，而是通过 taxonomy-guided generation engine 构建出来：先采样风险与候选工具，再生成多步轨迹蓝图，随后模拟工具调用、环境反馈、风险注入和 Agent 响应。

更关键的是，ATBench 引入了 long-context delayed-trigger protocol。很多风险并不会在第一步爆发，而是先埋在工具描述、历史状态或环境信息里，等到后续某个敏感动作点才被触发。

这更接近真实 Agent 系统会遇到的问题：风险不是一个点，而是一条链。

ATBench 的实验也说明了一个很现实的问题：模型可以比较容易地判断“这里可能不安全”，但要稳定说清楚“为什么不安全”，难度会明显上升。

在 ATBench 上，强模型在二分类安全判断上仍然没有达到非常轻松的水平；而到了细粒度诊断，比如判断 risk source、failure mode 和 real-world harm，表现会进一步下降。

这对实际系统非常重要。因为工程团队真正需要的，不只是一个 unsafe 标签，而是能够定位问题的诊断信息：是 prompt injection？是工具反馈被污染？是执行范围越界？是没有经过审批？还是把未经验证的信息当成事实继续传播？

只有回答清楚这些问题，安全评测才有可能反过来帮助系统改进。

ATBench-Claw / ATBench-CodeX 做的不是简单“再加两个 benchmark”。

得益于ATBench-Engine的设计，ATBench支持通过扩展三分类的方式支持更多风险类型挑战，ATBench-Claw / ATBench-CodeX 展示了ATBench 可扩展的特性：

- ATBench-Claw：面向 OpenClaw 式执行环境，关注 tools、skills、sessions、environment observations 和 external actions。

- ATBench-CodeX：面向 OpenAI Codex / Codex-runtime 式代码执行环境，关注 repositories、shells、patches、dependencies、MCP interactions、approvals 和 runtime policy boundaries。

这一步很关键。因为不同 Agent 虽然都叫“智能体”，但它们接触的接口、依赖的上下文、能触发的动作和可能造成的后果，已经非常不同。评测框架如果还停留在统一模板上，就很难真正覆盖这些运行时风险。

ATBench-Claw 聚焦的是 OpenClaw execution setting 下的 agent safety。

在这个环境里，Agent 不只是对话，而是会调用工具、加载技能、维持 session，并根据环境观察继续行动。它的动作可能带来外部可见的副作用，比如发送消息、删除文件、执行命令，或者在带权限的 session 中继续操作。

所以 OpenClaw 的安全评测必须覆盖三个特征：

- Action-centric：风险常常卡在某个具体动作上。

- Stateful：session history、skill 加载和环境观测会持续影响判断。

- Externally connected：动作可能穿过信任边界，对文件系统、浏览器、账号或消息平台产生真实后果。

在 ATBench-Claw 中，敏感动作不再只是泛泛的“工具调用”，而包括 external send、destructive write、privilege change、secrets access、code execution、cross-boundary network calls、unattended automation、high-cost operations 等更接近执行层的类别。

这让 OpenClaw 安全从抽象讨论变成了可以系统比较和细粒度诊断的对象。

代码智能体的风险，很多时候并不主要体现为某一段代码写得好不好。

更常见也更棘手的情况是：它在仓库状态修改、命令执行、依赖引入、权限边界处理或结果验证上出现失误，然后把局部问题放大成系统级风险。

ATBench-CodeX 讨论的正是这一层问题。

它评的不是一段生成代码是否“看起来安全”，而是一个代码 Agent 在 repo 和 runtime context 里逐步行动时，整条轨迹是否可靠。

在 CodeX setting 里，一个 shell command、一次 patch mutation、一次 dependency install，甚至一次和外部 connector 的交互，都可能成为真正的 safety event。

论文中提到的典型风险链包括：

• repository-artifact injection

• unsafe shell execution

• destructive workspace mutation

• dependency / MCP supply-chain exposure

• secret leakage

• unsupported success claims

最后一项尤其值得注意：没有验证就汇报成功，或者把不完整、不可靠的结果包装成已经完成，在真实开发环境里同样是很严重的安全与可靠性问题。

从实验结果看，ATBench-Claw 和 ATBench-CodeX 都显著考验模型的轨迹级安全判断能力。

ATBench-Claw 中，AgentDoG-Qwen3-4B 在 accuracy、F1 和 recall 上取得最强结果；ATBench-CodeX 中，它同样保持领先，但整体难度更高，尤其是对很多传统 guard model 来说，迁移到 repo-centered 的 CodeX 轨迹会更吃力。

这背后有一个很清晰的信号：Agent 安全评测正在从“文本越狱拦截”走向“系统执行层评测”。

模型不是只要拒绝危险内容就够了，还要能理解：

• 当前动作是否可逆

• 是否需要人工审批

• 是否跨越信任边界

• 是否访问了敏感信息

• 是否会破坏工作区或仓库状态

• 是否在没有验证的情况下宣称任务完成

这些问题，才是执行型 Agent 真正进入生产系统以后会遇到的安全问题。

把 AgentDoG、ATBench、ATBench-Claw / ATBench-CodeX 连起来看，脉络其实很清楚。

AgentDoG 先把轨迹级安全诊断和 guardrail 思路立起来；ATBench 把安全评测推进到完整任务轨迹；ATBench-Claw / ATBench-CodeX 再进一步说明：当 Agent 进入不同执行环境时，benchmark 也必须跟着具体环境升级。

这条线最有价值的地方，不是做了一个更难的榜单，而是把“智能体安全评测”从抽象概念拉回到了具体系统里。

OpenClaw 关注多工具、多会话、外部动作和跨边界后果；CodeX 关注 repo、shell、patch、dependency、approval boundary 和 runtime policy。场景不同，风险地图不同，benchmark 自然也不能再用一套统一模板概括过去。

更重要的是，它强调评测结果要可诊断。

对真实系统来说，能解释“为什么错”，很多时候比单纯判断“错没错”更有价值。因为只有知道风险从哪里来、失败怎么展开、最后会造成什么后果，工程团队才有可能据此去修动作策略、权限边界、审批流程和验证链路。

Agent 越来越像一个具备外部执行能力的系统。

它会读上下文、调用工具、修改状态、执行命令、触发外部动作。到了这一步，安全评测也必须从“看最终回复”升级为“看完整轨迹”，再进一步进入具体的执行环境。

ATBench 到 ATBench-Claw / ATBench-CodeX 的演进，正是在回答这个问题：

一个具备执行能力的 Agent，能不能在真实系统边界里可控地做事？

这可能会成为下一阶段 Agent benchmark 的核心问题。

你认同这个判断吗：以后 Agent benchmark 也要像系统评测一样，跟着具体运行环境一起升级？

起底智元机器人，谁在推动一个庞然大物向前

达闼科技陨落一周年：具身独角兽的消亡史