今日總覽
今天三篇論文分別在訓練、評測、治理三個層次,戳破同一個假設:只要有訊號可以看,就代表可以信。第一篇發現 RL 訓練出來的工具呼叫政策,能力越強反而越容易學會靠表面線索(而不是真的判斷需不需要)去觸發工具;第二篇是一份經同行審查的稽核,證明大家每天在看的 SWE-bench Verified 排行榜,前段名次其實已經測不出高下;第三篇則實測了一個爆紅的 Agent 技能生態系,發現星星數、下載數、掃描器標記這些「看起來像治理」的訊號,彼此矛盾且與實際留存無關。三篇證據成熟度都到位——兩篇通過同行審查、一篇有完整可重跑的公開統計分析——但主張範圍都很謹慎:沒有一篇說「Agent 整體不可信」,而是精準指出「這一種訊號,在這個條件下,測不出你以為它測得出的東西」。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Agent Skill(代理技能) | 一份教 AI Agent 怎麼用工具、做事的說明文件(通常是 SKILL.md),不是程式碼本身,但载入後 Agent 會照著做出真實動作 |
| 反事實評估(Counterfactual Evaluation) | 讓同一題出現「有線索」跟「沒線索」兩個版本,比較 Agent 行為差在哪裡,藉此判斷是線索還是題目本身在驅動決策 |
| 有效樣本數 n_eff / 巢套係數 | 排行榜裡真正「能分出高下」的題目數量;巢套係數則衡量弱系統解出的題目是否幾乎都被強系統包含,兩者一起說明為什麼名次可能讀不出來 |
| McNemar 配對檢定 | 統計方法之一,專門用來比較「同一組題目」下兩個系統誰更強,能判斷名次差異是不是巧合 |
| 特權跡證(Privilege Evidence) | 文字掃描出的訊號,顯示一份技能可能會存取檔案、網路、憑證等敏感能力,但只代表文字符合規則,不代表真的被審查過 |
| 密集獎勵 vs 稀疏獎勵 | 稀疏獎勵只看最終答案對不對;密集獎勵在每一個中間決策(例如每次工具呼叫)都給回饋,能抓到「答案對但過程有問題」的情況 |
論文一｜工具呼叫捷徑:RL Agent 學會用線索觸發工具,而不是判斷需不需要
Spurious Tool Use: When RL Agents Learn the Wrong Reason to Act Yiwei Yang, Haoxiang Zhang, Bingbing Wen et al.(University of Washington, UC San Diego, Stanford University） · arxiv: 2609.16268
TL;DR
在合成訓練環境中注入與工具毫不相關的表面線索(例如 <answer> 標籤),RL 訓練出的 Agent 會學會看到線索就觸發搜尋,即使任務其實需要的是程式執行,虛假呼叫率最多暴增 39.2%;但只要加一個由 LLM 判官評估「這次工具呼叫是否必要」的密集獎勵,這個捷徑幾乎完全消失。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查) |
| 引用速度 | 發布 3 天;Semantic Scholar 本次查詢被限流,無引用資料可查(preprint 剛發布,預期本就接近 0) |
| 機構 | University of Washington + UC San Diego + Stanford University |
| 社群反應 | HF Daily Papers 未上榜 / Papers with Code 無復現 repo |
| 可信度 | 通過 — swapped-cue 對照組(表 3、表 4)排除了「只是類別不平衡」和「模型學不會數學」兩個混淆解釋 |
| 證據成熟度 | 初步 — 僅在合成環境(NQ + DeepMath)與單一 7B 模型上驗證,尚未在自然訓練場景測試 |
| 可復現性 | 部分產物 — base model(Qwen2.5-7B-Instruct)與資料集皆公開,超參數與 judge prompt 已列在附錄,但程式碼「錄取後才釋出」 |
| 為什麼選這篇 | 直接 — 直接處理 RL 訓練出的 Agent 工具呼叫政策為何會學到錯的東西 |
| 方向新意 | 實質增量 — 把「捷徑學習」的分析框架從監督式分類任務搬進 Agent 的中介決策(選哪個工具),並發現它與任務能力耦合 |
| 今日重要性 | 高 — 越來越多 Agent 系統靠 RL 微調工具呼叫政策,這篇說明能力越強、越可能學到假因果 |
| 實務連結 | 明確 — 提供可直接套用的密集獎勵設計(LLM 判官評估每次工具呼叫的必要性) |
| 編輯信心 | 中 — 因果機制本身的證據紮實,但外推到正式生產環境的 Agent 仍待驗證 |
| 閱讀建議 | 必讀 — 對正在用 RL(如 GRPO)訓練工具呼叫政策的團隊 |
| 主要限制 | 只在合成環境與單一 7B 模型上驗證,尚未確認在更大規模、更自然的訓練資料上是否仍然成立 |
領域背景
Agent 的工具呼叫政策大多用 RL 訓練,只靠最終答案對不對給獎勵。這種做法的問題是:一次不必要的搜尋呼叫,只要最後答案還是對的,就完全不會被扣分——捷徑因此可以在「看起來一切正常」的評測下悄悄存活。過去的捷徑學習研究多半關注監督式分類任務裡的錯誤預測,這篇是少數把同一套分析框架搬到 Agent「選哪個工具」這個中介決策上的工作。
中階導讀
- 問題:想像一個 Agent 訓練時,凡是題目結尾出現
<answer>標籤就去查資料庫的事實類問題,而數學題從來沒有這個標籤。訓練久了,Agent 學到的可能不是「這題需要查資料庫」,而是「看到<answer>就查資料庫」——就算之後把這個標籤貼到一道純數學題上,Agent 還是會去查資料庫,即使查了也用不上。 - 方法:研究團隊用 GRPO 訓練 Qwen2.5-7B-Instruct,把「事實問答 + 搜尋工具」與「數學推理 + 程式工具」两類任務混在一起訓練,並刻意在某一類任務裡注入跟工具毫無因果關係的表面線索。接著用「反事實評估組」——同一題,有線索/無線索兩個版本——量化線索單獨造成多少虛假工具呼叫。發現捷徑只在「Agent 已經把某個工具用得很熟練」的任務上出現,而且線索與工具的語意越吻合、捷徑越強。最後引入密集的「工具必要性獎勵」,讓 LLM 判官對每一次工具呼叫單獨打分,而不是只看最終答案。
- 為什麼重要:這說明只看最終任務正確率的稀疏獎勵,不足以確保 Agent 學到的是「真的需要用工具」而不是「看到某個線索就用工具」。對正在拿 RL 微調工具呼叫政策的團隊,這是一個具體、可操作的盲點。
深入要點
- 搜尋語意線索(如
[WEB_INDEX_742])注入事實類任務後,在數學任務上造成的虛假搜尋呼叫率:DeepMath 上 +19.9 個百分點、GSM8K 上高達 +39.2 個百分點 - 對照組(程式語意線索注入數學任務,評估在事實任務上)幾乎沒有效果:Δ 僅 -0.3 到 +0.7,證明不是單純的類別不平衡在作祟
- 交換線索的控制實驗顯示:語意不吻合的線索即使配上已經學會的工具,捷徑也只有 ≤3.5% 的微弱效果,遠低於語意吻合時的 39.2%
- 加入密集的工具必要性獎勵後,虛假工具呼叫幾乎歸零,且任務準確率沒有下降甚至略有提升
- 落地門檻:需要一個額外的 LLM 判官(論文用 GPT-5 Nano)在訓練迴圈裡即時評分每次工具呼叫,會增加訓練成本與延遲
- Limitation:所有實驗都在合成資料集與單一 7B 模型上完成,論文自己也把「在更大規模、更自然訓練資料上驗證」列為未來工作
Reviewer 一句話評
實驗設計乾淨,swapped-cue 對照組確實把「任務能力」跟「語意吻合度」兩個混淆因子拆開了;但既然是刻意注入的合成線索,真實世界的 Agent 訓練資料裡是否存在同等強度的隱性線索,還需要更大規模的驗證才能下定論。
給你的 take-away
- 如果你在用 RL 微調 Agent 的工具呼叫政策:不要只用最終任務正確率當獎勵,考慮加一個像本文一樣的密集、決策層級獎勵,讓判官專門評估「這次工具呼叫是否必要」
- 如果你在做 Agent 評測:光看「任務有沒有做對」評不出這類捷徑,建議額外設計反事實測試組——同一題,人為加減某個表面線索,看工具呼叫模式會不會跟著變
論文二｜排行榜讀不出名次:SWE-bench Verified 前段已經測不出高下
Coding Agents Have Converged: Why the SWE-bench Leaderboard Can No Longer Order Its Top Entries, and What to Measure Instead Fengshuo Liu(Imperial College London） · arxiv: 2609.17394
TL;DR
稽核 SWE-bench 四個公開分割共 254 筆提交後發現:Verified 榜單前十名共同解出同樣的 285 道題、共同失敗同樣的 51 道題,只剩 164 題能真正分出高下;前段的解題集合彼此高度重疊(巢套係數 0.935),而 29 組相鄰排名中,沒有一組能被精確配對檢定(McNemar)分開。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | ADMA 2026(Responsible Data Intelligence 專題)已接受,camera-ready 版本 |
| 引用速度 | 發布 2 天;Semantic Scholar 本次查詢被限流,無引用資料可查 |
| 機構 | Imperial College London |
| 社群反應 | HF Daily Papers 未上榜;作者已釋出稽核工具原始碼(github.com/Adkid-Zephyr/resolution-audit),尚無外部星數紀錄 |
| 可信度 | 通過 — 254 筆公開逐題判定資料,搭配巢套係數、McNemar 配對檢定、IRT 三種互相印證的統計方法 |
| 證據成熟度 | 較完整 — 經同行審查、完整可重跑的資料與腳本,並用 Test split 做反例驗證這套方法確實能偵測出「有差異」的情況 |
| 可復現性 | 完整產物 — 所有輸入都是 SWE-bench 官方已公開的逐題判定資料,分析腳本、隨機種子與雜湊值全數釋出 |
| 為什麼選這篇 | 直接 — 直接處理「怎麼評測、挑選 coding agent」這件事的可信度 |
| 方向新意 | 實質增量 — 提出兩個新構念(比較集相對有效樣本數、巢套係數對照分數隱含的基準線),證明現有排行榜的名次讀法站不住腳 |
| 今日重要性 | 高 — 幾乎所有團隊選 coding agent 都在看 SWE-bench 排行榜,這篇直接證明「前段名次讀不出來」 |
| 實務連結 | 明確 — 給企業內部建 benchmark 具體的七條建議(記錄 model-scaffold pair、用配對檢定、公布分層而非名次等) |
| 編輯信心 | 高 — 統計工具彼此印證、經同行審查、資料與程式碼齊全可重跑 |
| 閱讀建議 | 必讀 — 任何用 SWE-bench 或類似排行榜做選型決策的人 |
| 主要限制 | 觀察性設計非因果,54% 的提交因缺乏機器可讀的 model-scaffold 標記而無法納入分析,結論僅驗證於 SWE-bench 家族 |
領域背景
SWE-bench Verified 是目前業界最常拿來比較 coding agent 的排行榜之一,前幾名的分數差距常被直接讀成「這個 scaffold/模型比較強」。過去已有審計指出任務本身品質有問題(約四分之一任務有瑕疵),但這篇問的是另一個問題:就算任務本身沒問題,現有的名次差距,統計上真的能被讀出來嗎?
中階導讀
- 問題:想像兩個 coding agent 在 SWE-bench Verified 上分別解出 396 題和某個接近的分數,榜單上排第一、第二。但如果仔細看逐題結果,會發現這兩個系統其實解出的幾乎是同一批題目——差距不是「誰更聰明」,而是「誰多解對了一兩題運氣好的邊緣案例」。
- 方法:作者定義「有效樣本數」——在某個比較集合裡,不是所有系統都通過或都失敗的題目數——並發現前十名之間只剩 33% 的題目有鑑別力,前兩名之間更只剩 7%。接著用「巢套係數」量化解題集合是否重疊(前段中位數高達 0.935,遠高於分數隱含的基準線),再用精確配對的 McNemar 檢定逐一比較相鄰排名,結果 29 組相鄰配對沒有一組能在 α=0.05 下被分開。作者同時在資訊量還沒飽和的 Test split 上跑同一套檢定,確認方法本身在有差異時仍能偵測出差異,排除「這套統計方法本來就測不出東西」的疑慮。
- 為什麼重要:對任何拿排行榜分數做模型/框架採購決策的團隊來說,這篇提供了具體的判斷工具:先算有效樣本數,再看巢套係數,最後用配對檢定決定要不要相信名次差異——而不是直接把分數當成排序。
深入要點
- Verified 前十名:285 題全解、51 題全敗,剩 164 題(33%)有鑑別力;前兩名之間只剩 36 題(7%)
- 前段巢套係數中位數 0.935,對照分數隱含基準線 0.774,顯示弱系統的解題幾乎都是強系統解題的子集
- 同一個模型換不同 scaffold,分數落差最高可達 29.8 個百分點(claude-3-5-sonnet 搭配九種不同 scaffold),超過整個前三十名的分數差距(8.8 個百分點)
- 29 組相鄰 Verified top-30 排名,精確 McNemar 檢定沒有一組能在 α=0.05 分開;同一套檢定用在資訊量未飽和的 Test split 上,23 組裡有 14 組能分開,證明方法本身有效
- 落地門檻:企業若想自建內部 benchmark,論文建議在 n=100 題規模下,獨立樣本設計大約只能偵測出 17 個百分點以上的差距,配對設計可以更精細但仍需依賴實際的判定分歧率來抓預算
- Limitation:model-scaffold 因子是觀察性設計(團隊自己選 scaffold 搭配模型),無法拆解出「純模型」或「純 scaffold」的因果貢獻;54% 的提交缺乏機器可讀的 model-scaffold 標記,無法納入這部分分析
Reviewer 一句話評
統計機具紮實、資料完全公開可重跑,而且用 Test split 的反例證明方法不是「到哪都測不出東西」;可惜結論被限定在 SWE-bench 這個家族,是否適用於其他排行榜(例如更廣泛的多領域 agent benchmark)仍待後續驗證。
給你的 take-away
- 如果你在用排行榜挑 coding agent:不要只看總分名次,先問「有效樣本數是多少」「相鄰名次能不能被配對檢定分開」,再決定要不要因為幾分之差換系統
- 如果你在建內部 benchmark:記錄好每次評測的 (model, scaffold, version) 三元組,公布分層(tier)而不是嚴格排名,並在任務設計時優先加入「能打破現有巢套結構」的題目,而不是單純堆數量
論文三｜爆紅之後:一個 Agent 技能生態系的治理訊號全部失靈
After the Party: Governing What a Viral Agent-Skill Ecosystem Left Behind Yunpeng Xiong, Ting Zhang(Monash University） · arxiv: 2609.17274
TL;DR
實測 2026 上半年爆紅的 OpenClaw/ClawHub 技能生態系:註冊技能數 91 天內幾乎翻倍,但 77.86% 的技能零星星零留言,同時 85.06% 帶有 shell、網路等特權跡證;三套安全掃描器對 61,990 個共同覆蓋的技能中有 23,702 個意見不合,經人工裁決後,加權敏感度只有 21.67%–61.06%,沒有任何一套掃描器或多數決可以當作真相。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | APSEC 2026(第 33 屆亞太軟體工程研討會)已接受,即將收錄於 IEEE Digital Library |
| 引用速度 | 發布 2 天;Semantic Scholar 本次查詢被限流,無引用資料可查 |
| 機構 | Monash University |
| 社群反應 | HF Daily Papers 未上榜;研究對象 OpenClaw/ClawHub 本身已有多篇獨立資安論文與社群整理清單(如 awesome-openclaw-skills)佐證其真實熱度 |
| 可信度 | 通過 — 三個時間點的 registry 快照、預先宣告的 7 個特徵與統計檢定、180 案例雙人獨立標註後裁決出的參考標準 |
| 證據成熟度 | 較完整 — 65,175 筆真實生產數據、多重穩健性檢查(世代限制、年齡調整、四種身分定義互相印證)、明確的效度威脅章節 |
| 可復現性 | 部分產物 — 原始資料來源(OpenClaw/ClawHub GitHub)公開並附時間戳,但作者自己的分析腳本目前是「匿名複現包」,本次查證未找到公開連結 |
| 為什麼選這篇 | 間接 — 不是 Agent 本身的架構或推理,而是 Agent 技能生態系的治理訊號是否可信,但直接影響任何在經營或使用技能市集的人 |
| 方向新意 | 實質增量 — 首次同時檢驗一個爆紅 Agent 技能生態系的規模、訊號穩定性、可課責性與掃描器有效性四件事 |
| 今日重要性 | 高 — 技能/外掛市集正快速變成 Agent 生態的標準配置,這篇提供實測數據說明光靠星星數、下載數、掃描器都不夠 |
| 實務連結 | 明確 — 對任何自建或引用 skill registry 的團隊,直接說明哪些訊號不能信、審查佇列該怎麼設計 |
| 編輯信心 | 高 — 主張範圍謹慎(明講只有方法論可遷移,數字不可遷移),證據對應清楚 |
| 閱讀建議 | 必讀 — 任何在做 Agent skill/plugin 市集治理或安全稽核的人 |
| 主要限制 | 只涵蓋單一 registry、單一半年時間窗,且研究期間兩個資料來源被平台下架;RQ2 的七個基準關聯在調整後幾乎全部消失或翻轉 |
領域背景
Agent Skill(一份指導 Agent 做事的說明文件,通常是 SKILL.md)正快速取代傳統套件成為 Agent 生態的擴充方式——這個 repo 自己的 .agents/skills/ 目錄就是一個縮小版案例。但當一個技能市集在幾個月內規模翻倍時,原本用來判斷「這個技能可不可信」的訊號(星星、下載數、掃描器標記)是不是還可信,過去很少有人真的拿數據驗證過。
中階導讀
- 問題:想像你在一個技能市集裡看到兩個技能:一個有 100 顆星、下載數很高;另一個零星星零留言。直覺上你會選第一個。但如果這個市集在三個月內從三萬多筆暴增到六萬多筆,你要怎麼知道「有星星」到底代表「有人真的審查過」,還是只是「比較早發布、比較多人剛好看到」?
- 方法:研究團隊拿 OpenClaw 的 Git 歷史、GitHub issue/PR,以及三個時間點的 ClawHub registry 快照做交叉比對。RQ1 量化了成長規模(91 天內從 33,399 筆長到 65,175 筆,+95.14%);RQ2 用 Mann-Whitney U 檢定加上年齡調整,測試「下載數、星星數」這類基準指標是否能穩定預測技能會不會繼續留在市集上——結果限制到「創建時間較早」的世代後,七個特徵的正向關聯全部消失甚至翻轉;RQ3 分開量測「看得到的社群回饋」跟「文字掃描出的特權跡證」,發現兩者同時存在但互不相干;RQ4 則找兩位資安經驗豐富的標註者,獨立審完 180 個案例、裁決出一份參考標準,拿去對照三套掃描器的實際表現。
- 為什麼重要:這說明「看起來像治理」的訊號(星星、下載數、掃描器有跑)跟「真的有被驗證過」是兩回事。對任何在經營或使用 Agent skill 市集的團隊,這篇提供了具體的測量方法,而不是只喊「要小心第三方技能」。
深入要點
- 技能註冊數 91 天內從 33,399 筆成長到 65,175 筆(+95.14%),下載量高度集中:前 10% 的技能拿走 46.93% 的總下載量(吉尼係數 0.528)
- 限制到創建時間較早(3 月截止前)的世代後,七個基準關聯(下載數、星星、多版本、檔案數等)全部翻轉為負向,原本 6/7 個方向一致的正向關聯完全站不住腳
- 77.86% 的技能同時零星星、零留言,但在可讀取的技能中有 85.06% 至少帶有一項(shell 執行、網路存取等十二個維度之一)特權跡證,兩者高度共存
- 三套掃描器(LLM 判定、靜態分析、VirusTotal)在共同覆蓋的 61,990 個技能中,對 23,702 個意見不合;經人工裁決後,加權敏感度介於 21.67%(靜態分析)到 61.06%(LLM 判定)之間
- 落地門檻:要重現這類分析需要能拿到 registry 的多個歷史快照,且必須自己建立人工裁決的參考標準,不能只信任任何單一掃描器或多數決
- Limitation:研究只涵蓋單一半年時間窗與單一 registry,兩個資料來源(Git 歷史、留言內容)在研究期間被平台下架,作者明講只有測量方法可以遷移到其他 Agent skill 生態系,具體數字不行
Reviewer 一句話評
四個研究問題緊扣同一條治理邏輯線,人工裁決參考標準的設計特別紮實,把「掃描器有跑」跟「掃描器準」這兩件常被混為一談的事情徹底分開;可惜只研究了一個生態系、一個時間窗,結論的數字沒辦法直接套用到其他技能市集。
給你的 take-away
- 如果你在經營或審核 Agent skill / 外掛市集:不要把星星數、下載數當成審查完成的證據,建議依「特權跡證」分數建立優先審查佇列,並保留「未知」狀態而不是把讀不到的技能直接當成安全
- 如果你的安全流程依賴自動掃描器:這篇的數字說明單一掃描器或多數決都不能當真相,至少要用一小批人工裁決的樣本定期驗證掃描器的敏感度/精確度,而不是假設掃描器裝了就代表有審查
今日收穫
之前以為判斷一個 Agent(或它的技能市集)可不可信,看訊號存不存在就夠了——工具有沒有被呼叫、排行榜名次高不高、星星數多不多。今天三篇論文說明的是同一件事:訊號存在不等於訊號被驗證過。工具呼叫可能是巧合對了答案卻用錯了理由,排行榜前段的名次差距可能已經被巢套的解題集合吃掉,零星星的技能一樣可能帶著完整的 shell 權限。真正該問的問題不是「有沒有訊號」,而是「這個訊號在這個規模、這個條件下,有沒有被檢驗過還撐得住」。
參考資料
- Spurious Tool Use: When RL Agents Learn the Wrong Reason to Act
- Spurious Tool Use — alphaxiv
- Coding Agents Have Converged: Why the SWE-bench Leaderboard Can No Longer Order Its Top Entries, and What to Measure Instead
- Coding Agents Have Converged — alphaxiv
- resolution-audit(稽核工具原始碼)
- SWE-bench experiments(官方逐題判定資料來源)
- After the Party: Governing What a Viral Agent-Skill Ecosystem Left Behind
- After the Party — alphaxiv
- OpenClaw ClawHub — How ClawHub Works(官方文件)
- arXiv cs.AI new listings, 2026-09-16
Loading...