ATBench-Claw / CodeX 論文閱讀分析：真正該被評測的不是 agent 會不會講錯，而是它會不會在真實 execution chain 裡安全地活下來

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Benchmarks for Trajectory Safety Evaluation and Diagnosis in OpenClaw and Codex: ATBench-Claw and ATBench-CodeX
• 作者：Zhonghao Yang
• 年份：2026
• 來源：arXiv:2604.14858
• 論文連結：https://arxiv.org/abs/2604.14858
• DOI：10.48550/arXiv.2604.14858
• 主題：Agentic Security、OpenClaw、Codex、Safety Benchmark、Trajectory Diagnosis、Runtime Security

最近這一波 agent security 論文，很常在討論某個攻擊能不能打穿某個 agent、某個 defense 有沒有把 ASR 壓低；但如果你真的開始把 agent 放進 OpenClaw、Codex runtime、shell、patch、sessions、skills、approval flow 這些真實執行環境裡，問題很快就會變成另一個層次：你到底要拿什麼 benchmark，來判斷這條完整 trajectory 是不是安全，以及它到底壞在哪裡？

這篇 ATBench-Claw / ATBench-CodeX 值得寫，不是因為它又多發明了一個 benchmark 名字，而是因為它抓到一個現在很容易被低估的事實：agent safety 不是單一能力測驗，而是 execution setting-sensitive 的診斷問題。 同樣叫 agent，放在 OpenClaw 和放在 Codex，風險長相根本不同。前者更容易踩到 skills、sessions、跨工具協作、外部行為與身分邊界；後者則更直接暴露在 repository、shell、patch、dependency、approval 與 runtime policy boundary 上。

換句話說，不是 benchmark 越通用越好，而是你得先承認「不同 runtime 的危險不是同一種危險」。這篇論文真正做的，就是把這件事正式落成 benchmark design：沿用 ATBench 原本的三維安全 taxonomy，但針對 OpenClaw 與 Codex 各自做 domain-specific customization，讓 evaluation 不再停在抽象 safety labels，而能對準實際 execution chain。

這篇論文想解決什麼問題？

作者點的核心很準：trajectory-level safety evaluation 若不跟著 execution setting 更新，很快就會變成看起來有 benchmark、實際上沒有 coverage。

很多既有評測會把 agent 安全問題寫成單輪 prompt 對答、單一 action 是否違規，或少量固定場景的成功／失敗判斷。但真實 agent system 的風險通常不是這樣長的。它比較像：

• 一段多步驟、跨工具、跨狀態的執行鏈
• 危險可能延遲出現，而不是第一步就爆炸
• 錯誤可能不是 model 直接說錯，而是把不該做的事做了
• 而且不同 runtime 的高風險區，根本不在同一個地方

如果你把 OpenClaw 與 Codex 都用同一套過度抽象的 benchmark 去量，最後很可能只能得到一個沒有太多 operational value 的結論：某模型大概還行、某 guardrail 大概有用。但你不會知道它到底會在 approval bypass、cross-session contamination、repo mutation、dependency installation 還是 external action misrouting 上出事。

所以這篇論文真正要補的，是把 trajectory safety benchmark 從「泛化的 agent 評測」往「runtime-sensitive diagnosis」推進一步。

核心設計：不是重做一個 benchmark，而是把 ATBench 當成可延伸骨架

論文沒有完全另起爐灶，而是把既有 ATBench 當成共享 backbone。ATBench 原本的核心，是一個三維安全 taxonomy：

• Risk source：風險從哪裡來
• Failure mode：系統怎麼壞
• Real-world harm：最後造成什麼實際傷害

這三維 taxonomy 在原始版本裡，不只是 label space，而是整個 benchmark construction pipeline 的控制骨架。作者這次做的關鍵，不是把 taxonomy 丟掉，而是把它對不同 runtime 做setting-specific customization：哪些風險類別要新增、哪些既有類別要重新詮釋、哪些 harm 在該場景裡要被拉高優先度。

這個想法很實用。因為 agent framework 在高層架構上可能看起來差不多，但真實落地後，工具型態、核准流程、可持久化狀態、外部 side effect、policy boundary 都會改變。若 benchmark 還停在原本那套抽象類別，你就很難對準實際 deployment risk。

ATBench-Claw 在補什麼？OpenClaw 風險其實是 stateful、跨工具、跨通道的

論文對 ATBench-Claw 的描述很到位。它瞄準的是 OpenClaw 這類 execution chain：tools、skills、sessions、external actions。也就是說，危險不只是「agent 會不會回答錯」，而是它會不會在多步行為中，把不該碰的 state、身份、授權邊界和外部動作串錯。

作者指出，OpenClaw 這類場景需要額外凸顯的風險包括：

• identity ambiguity：訊息或請求到底是誰發的、屬於哪個 session、該不該被當成可信上下文
• persistent session-state contamination：狀態一旦寫進 session / memory，後面可能一路被污染
• skill / plugin supply-chain compromise：風險不只在 prompt，也在 skill 與外部工具本身
• approval bypass：系統本來該停下來等人類授權，但 agent 或流程繞過了這道關卡
• cross-tool attack chaining：單一步驟看起來都無害，串起來卻能完成更高風險行為
• cross-channel misrouting：內容、命令或資料被送錯對象、錯 channel、錯 session

這些風險很難靠傳統單步 benchmark 抓到，因為它們本質上都跟持續狀態、流程控制與權限邊界有關。這也是為什麼作者會說，OpenClaw track 的 distinctiveness 主要不是模型能力，而是 execution-time risk coverage。

ATBench-CodeX 在補什麼？真正危險的是 repo、shell、patch、dependency 與 approval workflow

另一條線是 ATBench-CodeX，對準 OpenAI Codex / Codex-runtime 類場景。這裡的重心明顯不同：不是 sessions / channel routing，而是repository-centered execution。

作者點出的關鍵風險面包含：

• repositories
• shell commands
• patches
• dependencies
• network access
• approvals
• runtime policy boundaries

如果把話講白，這就是在量：coding agent 出事時，錯的不是答案，而是它真的會改壞東西、裝進不該裝的東西、跑出不該跑的命令、跨過不該跨過的政策界線。

這篇論文最有價值的地方之一，就是它把這種風險正式從「大家都知道很危險」變成「benchmark taxonomy 應該顯式覆蓋的區域」。例如在 Codex 類場景裡，批准流程、runtime policy 與 destructive mutation 都不是附屬條件，而是 benchmark 應該內生考慮的核心部分。

重點不只是 coverage，而是 diagnosis

很多 benchmark 最後只交出一個總分，但這篇 paper 特別強調的是 evaluation and diagnosis。這差很多。

因為對真實部署來說，團隊真正想知道的常常不是「模型 A 比模型 B 高 4 分」，而是：

• 到底是哪類 risk source 最常觸發失敗
• 失敗是發生在 planning、tool invocation、state update 還是 approval boundary
• 最後對應的是 functional harm、privacy harm、security harm，還是更偏 compliance / auditability 的問題

ATBench 系列沿用三維 taxonomy 的好處，就在於它天然比較適合拿來做這種細粒度 failure slicing。你不只知道 agent 壞了，還能比較系統性地知道它是怎麼壞的。

這點對 OpenClaw 與 Codex 特別重要，因為這兩類系統都不是純聊天產品。它們會動工具、改狀態、碰檔案、發外部行為。只看 pass/fail 很容易掩蓋真正需要修的 control point。

這篇論文真正提醒我們什麼？

1. Agent safety benchmark 不能假裝 runtime 無關

這篇最重要的提醒，就是安全評測不該把 runtime 當成可忽略背景。相同模型、相似 agent architecture，只要 execution setting 不同，真正暴露的高風險區就會大幅改變。

如果 benchmark 沒把 tools、sessions、approvals、shell、patches、dependencies 這些 setting-specific 邊界帶進來，最後你測到的就可能只是抽象「遵從性」，不是 deployment-ready safety。

2. 真正要被量的是整條 execution chain，而不是某一輪輸出

ATBench-Claw / CodeX 背後的共同前提，是危險常常不是一句錯話，而是一串看起來局部合理、整體卻走向危害的 trajectory。這種問題如果不用 trajectory benchmark，幾乎一定會低估。

尤其在實際系統裡，很多高風險行為都會被拆成小步驟：查資料、切 session、呼叫工具、寫 patch、裝依賴、再送外部請求。每一步單獨看都不一定違規，但連起來就可能出事。

3. Compliance / auditability 應該被正式視為 harm，不只是附註

論文對 OpenClaw customization 還有一個值得記的點：把 Compliance, Legal, and Auditability Harm 拉進 harm 軸。這非常對。

很多 agent failure 不一定馬上造成資料外洩或服務中斷，但它可能讓你：

• 無法解釋某次外部行為是怎麼發生的
• 失去完整 audit trail
• 把不該跨 channel 或跨 session 的內容送錯地方
• 在 policy 應受控的流程中留下責任真空

這些在企業環境裡根本不是小事。有時候最先讓組織不敢上線 agent 的，不是模型精度，而是出了事後根本無法稽核。

我的看法：這篇 paper 的價值，不在 benchmark 名字，而在它把「安全評測要跟著 runtime 走」說清楚了

如果只看表面，ATBench-Claw / ATBench-CodeX 好像只是把既有 benchmark 搬到新場景。但我覺得它真正有意思的地方，是它拒絕假裝 agent safety 可以靠一套永遠不變的 benchmark 靜態解決。

這其實很符合現況。今天 agent 系統變得太快：新工具、新 approval flow、新執行環境、新外部連接方式一直冒出來。架構可能還叫 agent，但風險幾乎每隔一段時間就換一張臉。 在這種條件下，benchmark 若不具備 taxonomy-guided extensibility，很快就會變成過時儀表板。

所以如果要把這篇濃縮成一句主線，我會寫成：

真正能拿來量 agent safety 的 benchmark，不是看起來最通用的那個，而是能把不同 runtime 的高風險 execution chain 顯式翻進 taxonomy 與 diagnosis 空間的那個。

對正在碰 OpenClaw、Codex、或其他工具型 agent runtime 的人來說，這篇 paper 的價值很直接：它提醒你，別再只問模型安不安全，要問的是你現在這個 execution setting，到底有沒有被正確評測。

關鍵重點整理

• ATBench-Claw / ATBench-CodeX 不是完全重做 benchmark，而是把原始 ATBench 的三維安全 taxonomy 延伸到 OpenClaw 與 Codex runtime。
• ATBench-Claw 聚焦 tools、skills、sessions、external actions，強調 identity ambiguity、persistent state contamination、approval bypass、cross-tool chaining、cross-channel misrouting 等風險。
• ATBench-CodeX 聚焦 repositories、shell、patches、dependencies、network access、approvals 與 runtime policy boundaries。
• 這篇論文的核心主張是：trajectory-level safety benchmark 必須隨 execution setting 做 taxonomy-guided customization，否則 coverage 會失真。
• 作者特別強調 benchmark 不只要做總分評測，還要支援細粒度 diagnosis，拆解 risk source、failure mode 與 real-world harm。
• 論文也把 Compliance / Legal / Auditability Harm 正式提升為重要 harm 類別，貼近真實組織導入 agent 時的治理顧慮。