未來的 Agent benchmark 比拼的不只是模型會不會答題，而是它能不能在真實系統邊界里可控地完成任務。

當 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，還能繼續追問：風險源頭是什么，模型在哪個環節失敗，最終可能造成什么后果。

02

為什么它比傳統評測更難？

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 系統會遇到的問題：風險不是一個點，而是一條鏈。

03

不只判對錯，還要診斷為什么錯

ATBench 的實驗也說明了一個很現實的問題：模型可以比較容易地判斷“這里可能不安全”，但要穩定說清楚“為什么不安全”，難度會明顯上升。

在 ATBench 上，強模型在二分類安全判斷上仍然沒有達到非常輕松的水平；而到了細粒度診斷，比如判斷 risk source、failure mode 和 real-world harm，表現會進一步下降。

這對實際系統非常重要。因為工程團隊真正需要的，不只是一個 unsafe 標簽，而是能夠定位問題的診斷信息：是 prompt injection？是工具反饋被污染？是執行范圍越界？是沒有經過審批？還是把未經驗證的信息當成事實繼續傳播？

只有回答清楚這些問題，安全評測才有可能反過來幫助系統改進。

04

從 ATBench 到 ATBench-Claw / ATBench-CodeX

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 雖然都叫“智能體”，但它們接觸的接口、依賴的上下文、能觸發的動作和可能造成的后果，已經非常不同。評測框架如果還停留在統一模板上，就很難真正覆蓋這些運行時風險。

05

OpenClaw 安全，到底該測什么？

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 安全從抽象討論變成了可以系統比較和細粒度診斷的對象。

06

CodeX 安全，為什么不只是代碼質量問題？

代碼智能體的風險，很多時候并不主要體現為某一段代碼寫得好不好。

更常見也更棘手的情況是：它在倉庫狀態修改、命令執行、依賴引入、權限邊界處理或結果驗證上出現失誤，然后把局部問題放大成系統級風險。

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

最后一項尤其值得注意：沒有驗證就匯報成功，或者把不完整、不可靠的結果包裝成已經完成，在真實開發環境里同樣是很嚴重的安全與可靠性問題。

07

評測結果說明了什么？

從實驗結果看，ATBench-Claw 和 ATBench-CodeX 都顯著考驗模型的軌跡級安全判斷能力。

ATBench-Claw 中，AgentDoG-Qwen3-4B 在 accuracy、F1 和 recall 上取得最強結果；ATBench-CodeX 中，它同樣保持領先，但整體難度更高，尤其是對很多傳統 guard model 來說，遷移到 repo-centered 的 CodeX 軌跡會更吃力。

這背后有一個很清晰的信號：Agent 安全評測正在從“文本越獄攔截”走向“系統執行層評測”。

模型不是只要拒絕危險內容就夠了，還要能理解：

• 當前動作是否可逆

• 是否需要人工審批

• 是否跨越信任邊界

• 是否訪問了敏感信息

• 是否會破壞工作區或倉庫狀態

• 是否在沒有驗證的情況下宣稱任務完成

這些問題，才是執行型 Agent 真正進入生產系統以后會遇到的安全問題。

08

這條研究線的價值

把 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 自然也不能再用一套統一模板概括過去。

更重要的是，它強調評測結果要可診斷。

對真實系統來說，能解釋“為什么錯”，很多時候比單純判斷“錯沒錯”更有價值。因為只有知道風險從哪里來、失敗怎么展開、最后會造成什么后果，工程團隊才有可能據此去修動作策略、權限邊界、審批流程和驗證鏈路。

09

結語

Agent 越來越像一個具備外部執行能力的系統。

它會讀上下文、調用工具、修改狀態、執行命令、觸發外部動作。到了這一步，安全評測也必須從“看最終回復”升級為“看完整軌跡”，再進一步進入具體的執行環境。

ATBench 到 ATBench-Claw / ATBench-CodeX 的演進，正是在回答這個問題：

一個具備執行能力的 Agent，能不能在真實系統邊界里可控地做事？

這可能會成為下一階段 Agent benchmark 的核心問題。

你認同這個判斷嗎：以后 Agent benchmark 也要像系統評測一樣，跟著具體運行環境一起升級？

未經「AI科技評論」授權，嚴禁以任何方式在網頁、論壇、社區進行轉載！

公眾號轉載請先在「AI科技評論」后臺留言取得授權，轉載時需標注來源并插入本公眾號名片。