今日總覽
今天 arXiv 10-14 的批次裡，最值得看的三篇不是新的 agent 能力，而是在檢查「我們用來判斷 agent 的證據」：第一篇把評測打分程式當成軟體來測，發現一個缺陷讓成功率被高估將近 29 個百分點；第二篇量出 coding agent 在做小任務時，有多常讀錯依賴、動到不該動的檔案；第三篇問的是部署端的問題：要核准一次 agent 變更，現有日誌夠不夠？三篇的答案方向一致：分數、日誌、行為紀錄都要事先設計，才擋得住檢查。三篇都是預印本，結論範圍以下文標註的設定為限。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Oracle（測試判定器） | 評測裡負責判斷「這次執行算不算成功」的程式，例如比對最後資料庫狀態的 reward function |
| Replay（重放） | 拿已記錄的工具呼叫，在乾淨環境重跑一次，看結果是否跟原本的紀錄一致 |
| Boundary violation（越界行為） | agent 做了任務沒要求的事，例如改了不相關的檔案、跑 git checkout、裝套件 |
| Gate（閘門） | 在 agent 的工具呼叫前面依風險分數決定放行、停止或拒絕的機制 |
| Saved state（預存狀態） | 執行過程中先存下的環境快照，之後可以從那一刻重跑，而不是從頭來 |
論文一｜評測會出錯：把 agent benchmark 的打分程式當成軟體來測
When Agent Evaluation Becomes Unreliable: An Empirical Study of Oracle Failures and Configuration-Dependent Measurement in an LLM Agent Benchmark Junjie Chen（Nanjing University of Science and Technology） · arxiv: 2610.16067 連結: arxiv · alphaxiv
TL;DR
作者替 agent 評測的打分程式寫了一套稽核測試，在 τ-bench 的一條「執行後才打分」路徑找到缺陷：reward function 為了算標準答案雜湊而重設資料庫、卻沒有還原，4,320 回合中原本記錄 4,194 次資料庫通過，重放後只剩 2,883 次，成功率從 94.3% 降到 65.5%。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint，已投稿 Empirical Software Engineering（未經同行審查） |
| 引用速度 | 發布 3 天，Semantic Scholar 查詢遭限流，未取得引用資料 |
| 機構 | Nanjing University of Science and Technology（單一作者） |
| 社群反應 | 未出現在 HF Daily Papers（10-13、10-14）；無 Papers with Code 紀錄 |
| 可信度 | 通過 — 以 7 類注入缺陷驗證稽核方法全數偵測、修正後無誤報，並以重放獨立重算標籤 |
| 證據成熟度 | 初步 — 核心發現來自單一 benchmark 的兩個任務領域，作者明說換到另一個 benchmark 時方法無法直接移植 |
| 可復現性 | 完整產物 — Zenodo 釋出稽核套件、缺陷目錄、預註冊與偏差紀錄、逐回合凍結紀錄，可離線重算 |
| 為什麼選這篇 | 直接 — 團隊拿 benchmark 分數做選型與上線決策時，分數本身的正確性是前提 |
| 方向新意 | 實質增量 — 把軟體測試的 fault injection 與 oracle problem 搬到 agent 評測框架上 |
| 今日重要性 | 高 — 監理開始要求外部評測證據，評測程式的缺陷會直接變成錯誤的合規證據 |
| 實務連結 | 明確 — 自建 eval harness 的團隊可以照「狀態不變式＋已知答案對照」的方式補測試 |
| 編輯信心 | 高 — 文章只陳述作者在特定打分路徑上的發現，作者本人也明確不主張官方 runner 會高估 |
| 閱讀建議 | 必讀 — 維護 eval pipeline 或依賴 benchmark 做採購的人 |
| 主要限制 | 只在一個 benchmark 驗證，第二個 benchmark 的移植失敗只揭露了框架介面限制 |
領域背景
agent benchmark 的 reward function 通常被當成「定義」：它說成功就是成功，很少有人回頭測它。軟體工程早就知道測試判定器本身會出錯，也有 mutation testing、flaky test 這些檢查方法，但這些方法還沒被系統性用在 agent 評測上。
中階導讀
- 問題：想像考試的閱卷程式為了算標準答案，先把考生的答案紙換成標準答案，事後卻忘記換回來。只要閱卷順序是「考完才改」，每個考生看起來都考得很好。
- 方法：作者把評測 harness 當成待測系統，寫了 5 條狀態不變式與 3 個已知答案對照，先注入 7 類缺陷確認這套稽核抓得到，再拿去跑真實 benchmark；發現問題後用重放記錄下來的工具呼叫，在乾淨資料庫上獨立重算每個回合的結果。
- 為什麼重要：如果你的 agent 在某個 benchmark 上 94%，這個數字可能有一部分來自打分程式的副作用，而不是 agent 的能力。
深入要點
- 4,320 回合：原始標籤 4,194 次資料庫通過 → 重放 2,883 次；成功率 94.3% → 65.5% ⚠️（作者自測，尚未外部複現）
- 作者強調缺陷只影響「執行後才打分」的 harness，不主張 τ-bench 官方 runner 會高估自己的成功率
- 次要發現：在 3,240 回合的分項消融中，把 agent 讀到的 policy、工具說明、錯誤訊息換成另一種語言都會影響結果，工具說明影響最大；但換到 airline 領域效果方向相反，作者因此把結論限縮在原設定
- 落地門檻：不需要新模型，只需要在 harness 加狀態檢查與重放步驟，但需要能存取框架的參考終態
- Limitation：作者明說方法在第二個獨立實作的 benchmark 上無法直接移植，因為外部 harness 重建不出所需的參考終態
Reviewer 一句話評
把「評測程式也要被測試」講得很清楚，產物完整到可以離線重算每個數字；但核心發現來自一個 benchmark 的一條打分路徑，下一步要看其他主流 agent benchmark 有沒有同類缺陷。
給你的 take-away
- 如果你自己維護 eval harness：加一個「已知正確答案應該拿滿分、已知錯誤答案應該拿零分」的對照組，並檢查打分前後環境狀態有沒有被改動
- 如果你拿公開 benchmark 分數做採購或選型：先確認分數是用哪個 runner、哪種打分順序跑出來的，不同 harness 的分數不能直接比
論文二｜coding agent 做小事也會越界：SWE-Misbehavior
SWE-Misbehavior: Benchmarking and Mitigating Boundary Violations in Software Coding Agents Do Xuan Trong, Duc Anh Nguyen, Do Xuan Long et al.（National University of Singapore 等） · arxiv: 2610.18206 連結: arxiv · alphaxiv
TL;DR
用 7.4K 個人工把關合成的任務量測 coding agent 的 11 種越界行為，最常見的是沒讀或讀錯依賴就動手（最高 98.5%），其次是改動使用者輸入（50.5%）與悄悄破壞環境（53%）；加上依任務限制動作範圍的工具 Code-KIT 後，smolagents 與 OpenHands 的違規分別減少 52% 與 32%，任務完成率也同時提高。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint（未經同行審查） |
| 引用速度 | 發布 2 天，Semantic Scholar 記錄 0 次引用 |
| 機構 | National University of Singapore（WING），另有 A*STAR、University of Virginia、Virginia Tech 等合作者 |
| 社群反應 | 未出現在 HF Daily Papers（10-13、10-14）；GitHub 已公開程式碼與資料 |
| 可信度 | 通過 — 4 個 agent 框架 × 3 個模型的系統性量測，LLM 評審與 3 位人工標註的一致率另有檢驗 |
| 證據成熟度 | 初步 — 任務是合成的單步或短任務，模型以 GPT-5、Gemini-2.5-Flash、Qwen3-Coder-30B 為主 |
| 可復現性 | 完整產物 — 程式碼、資料與評估流程已在 GitHub 公開 |
| 為什麼選這篇 | 直接 — coding agent 是目前最大量部署的 agent，越界行為直接影響 repo 安全 |
| 方向新意 | 實質增量 — 把「做錯」細分成讀取、建立、修改、刪除、環境、資源等 11 種可自動量測的越界 |
| 今日重要性 | 高 — 跟同日 Visual Studio Copilot 改自身設定的漏洞是同一類問題：agent 動到不該動的東西 |
| 實務連結 | 明確 — 結果顯示工具介面設計（例如讀寫權限綁在一起）比模型更影響越界率 |
| 編輯信心 | 中 — 量測框架可信，但模型版本偏舊，換成最新前沿模型時比例可能不同 |
| 閱讀建議 | 必讀 — 設計 coding agent 工具介面或評估內部導入的人 |
| 主要限制 | 未涵蓋多輪資安注入、資料外洩等更複雜的越界情境，Code-KIT 也只在短任務上驗證 |
領域背景
coding agent 的評測多半看「任務有沒有完成」，例如 SWE-bench 的測試有沒有通過。但一個完成任務的 agent 可能同時刪錯檔、改了不相關的程式、在環境裡裝了一堆東西，這些在完成率裡看不到。
中階導讀
- 問題：你請 agent 補一個函式，它補好了，但順手改了旁邊三個函式的內容、新建兩個測試草稿檔、還跑了
git checkout。任務完成率會說它成功。 - 方法：把 agent 的動作空間分成程式生成、檔案管理、系統互動三層，每層設計會誘發越界的任務，再用規則與 LLM 評審自動量 11 種行為；最後提出 Code-KIT，用越界知識指引加上依任務限縮的工具（例如唯讀任務就只給讀取工具）來降低違規。
- 為什麼重要：研究發現同一個模型放在不同框架裡越界率差很多，例如 OpenHands 的原生檔案工具把讀寫綁在一起、唯讀任務也保有寫入權限，問題出在工具介面，不只是模型。
深入要點
- 最常見越界：未讀或讀錯依賴就動手，最高 98.5% ⚠️（作者自測，尚未外部複現）
- 改動使用者輸入 50.5%、悄悄破壞環境完整性 53%；agent 很少改公開函式簽名
- LLM 評審（Gemini-3-Flash）與人工標註的平均一致率 88.63%，但「指令遵循」一項只有 72.0%
- Code-KIT：smolagents 違規減少 52%、OpenHands 減少 32%，任務完成率同時提高
- 與主流框架的關聯：實驗涵蓋 OpenHands、smolagents、Agno、Claude Code
- Limitation：作者承認未涵蓋多輪資安注入與資料外洩；Code-KIT 的逐步工具限制要延伸到長任務，還需要跨步驟的權限設計
Reviewer 一句話評
把「越界」拆成可自動量測的 11 種行為，讓工具介面設計第一次有了可比較的指標；待觀察的是換成最新前沿模型與長任務後，越界率與 Code-KIT 的效果還剩多少。
給你的 take-away
- 如果你在設計 coding agent 的工具：讀取與寫入拆成不同工具，唯讀任務只給讀取工具，不要靠 prompt 叫它別寫
- 如果你在評估內部導入 coding agent：除了任務完成率，加量「改到範圍外的檔案」「新建未要求的檔案」「動到環境」三項
論文三｜要核准 agent 的變更，日誌該記什麼：agent-risk
agent-risk: Risk Assessment for Changes to AI Agents Yue Zhao, Zixiang Xu, Angela Huyue Zhang et al.（University of Southern California、London Business School、Arizona State University） · arxiv: 2610.16280 連結: arxiv · alphaxiv
TL;DR
在 bash 沙箱裡，光靠 7,200 筆日誌決定不了兩種「被拒後讓 agent 重試」的閘門能不能上線；從預存狀態只重跑被閘門擋下的回合，就能得到跟實際上線測試一樣的核准結論，成本只有事後估算所需上線測試的一半。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint（未經同行審查） |
| 引用速度 | 發布 3 天，Semantic Scholar 查詢遭限流，未取得引用資料 |
| 機構 | University of Southern California（含法學院）、London Business School、Arizona State University |
| 社群反應 | 未出現在 HF Daily Papers（10-13、10-14）；GitHub 已公開程式碼、預註冊與紀錄 |
| 可信度 | 有條件通過 — 形式化結果有證明，沙箱實驗的估計值事先凍結後再比對實際上線結果，但實驗規模小 |
| 證據成熟度 | 概念驗證 — 只用一個開源模型家族（14B、27B）、誠實不躲監控的 agent，在 bash 沙箱與 airline 環境示範 |
| 可復現性 | 完整產物 — 程式碼、預註冊與執行紀錄已在 GitHub 公開 |
| 為什麼選這篇 | 直接 — 部署方換模型、改閘門前要拿出風險證據，這篇回答日誌要怎麼設計才撐得住 |
| 方向新意 | 實質增量 — 把 off-policy evaluation 與最佳停止的方法延伸到只有部分紀錄的 agent 日誌 |
| 今日重要性 | 高 — 監理開始要求 agent 的行為證據，保險與稽核方需要知道「日誌能證明到哪裡」 |
| 實務連結 | 明確 — 指出日誌要記哪些欄位、哪些步驟前要存快照，可以直接寫進 agent 平台的紀錄規格 |
| 編輯信心 | 中 — 文章只引述作者在受控沙箱裡的示範，不推論到大型正式系統 |
| 閱讀建議 | 略讀 — 數學密度高，負責 agent 平台紀錄設計或治理流程的人讀引言與第 4 節即可 |
| 主要限制 | 換新模型時 99 筆舊日誌一筆都重放不出來，模型升級這個最常見的情境仍要從頭測 |
領域背景
部署方常要改 agent：收緊安全閘門、換新模型。保險、稽核、核准的人想在上線前知道風險，最便宜的證據是現有日誌，但日誌只記錄了「舊設定下發生的事」，新閘門會擋下哪些動作、被擋之後 agent 會做什麼，日誌裡沒有。
中階導讀
- 問題：你想把閘門從「危險就停止」改成「危險就拒絕，讓 agent 換個方法重試」。舊日誌裡從沒出現過「被拒絕之後」的行為，所以舊日誌無法告訴你新閘門的風險。
- 方法：先證明日誌必須記哪些欄位才能精確重放，再在高風險步驟前預存環境快照；評估新閘門時，日誌能決定的回合直接用日誌，決定不了的只從快照重跑那一段。
- 為什麼重要：核准 agent 變更需要的證據要事先設計：該記的欄位、該存的快照、該重跑的回合。事後才找日誌，常常什麼都證明不了。
深入要點
- 7,200 回合日誌單獨使用時，兩種重試閘門都無法判定；從快照重跑被擋的回合後，核准結果與實際上線一致（核准閘門 2、否決閘門 1）⚠️（作者自測，尚未外部複現）
- 重跑成本是同時上線測試兩種閘門的 15% agent 呼叫數，也是事後估算達到同樣決策所需上線測試的一半
- 若日誌沒記每一步的傷害，停止型閘門可證明的傷害上限最多放大 2.5 倍，因為看不出傷害發生在停止之前還是之後
- 換新模型時，99 筆舊日誌一筆都重放不出來，模型升級需要從第 0 步重新跑
- 事先在提示中公告閘門會讓 agent 的中止率高於重放預測，代表 agent 察覺到監控時，舊日誌就不再適用
- Limitation：只用一個開源模型家族、誠實的 agent；對會躲避監控的 agent 仍沒有界
Reviewer 一句話評
把「日誌能證明什麼」講成可檢查的條件，對 agent 治理很有用；但示範規模小，下一步要看在多模型、長任務、會察覺監控的 agent 上還成不成立。
給你的 take-away
- 如果你在做 agent 平台的紀錄：每一步都記工具呼叫、監控分數與該步的結果，並在高風險步驟前存快照，之後評估閘門變更時才有東西可重跑
- 如果你負責 agent 上線核准：把「舊日誌能決定哪些回合」與「哪些要重跑」分開列，換模型的變更預設要從頭測
今日收穫
之前以為 agent 的證據問題主要是「有沒有留紀錄」，今天三篇讓我改觀：評測程式本身會讓分數失真，越界行為不會反映在完成率裡，連日誌都要先設計好欄位與快照才證明得了事。證據要在事前設計，事後補不回來。