今日總覽
今天三篇論文看的不是 agent 的新能力，而是「看起來沒事」跟「真的沒事」之間的落差：第一篇量到 agent skill 市集裡七成的上架項目藏著使用者裝的時候看不到的特權，宣告機制幾乎形同虛設；第二篇把「skill 寫錯」跟「skill 用起來出事」分開測，發現兩者不是同一件事，弱模型才是真正放大風險的那個環節；第三篇把「每次呼叫比較模型」換成「每個成功任務比較模型」，結果同一組模型在短任務跟長任務給出完全相反的建議。三篇合起來的提醒是：無論是裝的 skill、修的缺陷，還是選的模型，表面訊號都不能直接當答案，要真的跑過才知道。三篇都是預印本，結論範圍以下文標註的設定為限。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Agent Skills | agent 讀取的 Markdown 指令包，搭配腳本與資源，讓 agent 取得新的工作流程或工具用法 |
| 攻擊面（Attack surface） | 系統因為裝了某個元件而新增的、可能被用於不當用途的能力總和 |
| allowed-tools 宣告 | skill 作者在 frontmatter 裡列出的「預先核准」工具清單，移除確認提示，但不限制其他工具的使用 |
| 契約不一致（Contract inconsistency） | 同一個 skill 的文件、腳本與設定檔之間互相矛盾的操作限制 |
| 交叉點（Crossover length） | 任務步驟數到達某個長度後，原本更省資源的模型反而變得比較不划算的那個轉折點 |
論文一｜七成 agent skill 裝的時候就給了特權，你卻看不到
Beyond Maliciousness: Static and Runtime Attack-Surface Profiling of Agent Skills Ratnesh Pandey, Japneet Singh, Harsh Akshita et al.（Metano Labs、Purdue University、VulNow） · arxiv: 2610.19264
TL;DR
對兩個 agent skill 市集的 6,309 筆上架項目做攻擊面量測，七成帶有至少一項特權級能力（shell 執行、檔案讀寫、網路外連或憑證存取），但宣告機制幾乎不起作用——6,061 筆可解析宣告中只有 770 筆填了任何內容，填了的裡面 59% 還低報自己實際能做的事。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint（cs.CR，未經同行審查） |
| 引用速度 | 發布 3 天，Semantic Scholar 查詢持續遭限流，未取得引用資料 |
| 機構 | Metano Labs（第一作者所屬）、Purdue University、VulNow |
| 社群反應 | 未出現在 HF Daily Papers（10-14、10-15）；無 Papers with Code 紀錄 |
| 可信度 | 有條件通過 — 方法論完整（靜態分析＋沙箱執行＋模型評審＋人工覆核 410 筆），但論文自揭掃描器由第一作者所屬 Metano Labs 自建自營，無第三方驗證、無外部基準可對照 |
| 證據成熟度 | 初步 — 6,309 筆樣本量大，但人工覆核僅涵蓋其中一個市集的 410 筆，審查在量測時仍在進行中，未給出精確率數字 |
| 可復現性 | 未提供 — 論文明說原始掃描結果、掃描器與提示模板皆未公開，依請求提供的資料也「無法據此獨立重建完整掃描結果」 |
| 為什麼選這篇 | 直接 — 直接回答「安裝一個 skill 到底在授權什麼」，是本站日常使用的 Claude Skills 同一類生態風險 |
| 方向新意 | 實質增量 — 把焦點從「這個 skill 是不是惡意」轉成「這個 skill 能做到什麼」，並量出宣告與實測的落差 |
| 今日重要性 | 高 — Agent Skills 市集正快速擴張，同一個市集一個月內從 1.5 萬筆成長到 7.3 萬筆，裝的人比寫安全規則的人多很多 |
| 實務連結 | 明確 — 指出 allowed-tools「移除確認框但不限制能力」，可直接拿來檢查自己團隊的 skill 審查流程 |
| 編輯信心 | 中 — 核心比例數字可信，但資料來源單一且不可獨立覆核，文章語氣需要相應收斂 |
| 閱讀建議 | 必讀 — 允許團隊安裝第三方 agent skill 的人 |
| 主要限制 | 掃描器自建自營、無外部基準，且原始資料與提示模板不公開，讀者無法自行覆核數字 |
領域背景
靜態弱點掃描可以告訴你一個 skill 有沒有可疑程式碼或惡意意圖，但不會告訴你安裝它之後，agent 能力的邊界擴大了多少。多數市集審查停在「這個東西是不是故意搞破壞」，沒人系統性量過「正常運作的 skill 到底拿到了多大的授權」。
中階導讀
- 問題：想像你在手機上裝一個小工具 App，畫面只問你要不要安裝，沒有列出它會讀聯絡人、相機跟簡訊。裝 agent skill 現在幾乎是同一個狀況——你看到的只是一份說明文件，看不到它能叫 shell、讀寫檔案或打外網。
- 方法：對兩個市集的 6,309 筆上架項目跑兩階段量測：先用靜態分析＋依賴來源檢查整包內容，再在隔離沙箱裡實際執行並用另一個模型評估留下的行為軌跡，最後跟作者自己宣告的 allowed-tools 清單對照。
- 為什麼重要：現有的「這是不是惡意」審查，回答不了「裝了之後我多授權了什麼」這個問題，而這個問題才是使用者實際承擔的風險。
深入要點
- 一半的上架項目有 shell 執行證據，檔案讀取 35%、檔案寫入與網路外連各 31%、憑證存取 13%，七成帶有至少一項特權級能力 ⚠️（Metano Labs 自建自營掃描器，未經第三方驗證）
- 6,061 筆可解析 frontmatter 中只有 770 筆填了 allowed-tools，且其詞彙「無法表達」憑證或環境存取
- 填了宣告的項目中 59% 低報自己實際能做的事；ClawHub 宣告頻率約是 skillsmp 的兩倍，但低報比例是 88% 對 31%
- 人工覆核樣本僅 410 筆（91 筆有標記、319 筆未標記），只來自其中一個市集，審查在量測時仍在進行中
- 落地門檻：需要能跑靜態分析＋沙箱執行的管線，對大多數團隊來說門檻在「有沒有隔離執行環境」
- Limitation：掃描器由論文作者所屬公司自建自營，無外部基準可對照，原始資料與提示模板不公開
Reviewer 一句話評
把「這個 skill 想幹壞事嗎」換成「這個 skill 能幹什麼」是對的問題，量測規模也夠大；但掃描器是作者自己公司的產品，且無法把原始資料給出來重算，這個利益衝突要先放在心上再看數字。
給你的 take-away
- 如果你的團隊允許裝第三方 agent skill：在審查流程裡加一道「這個 skill 實際會呼叫哪些工具」的沙箱檢查，不要只看 frontmatter 宣告
- 如果你在寫自己的 skill：allowed-tools 不是安全邊界，只是少一次確認提示，該限制的能力要在執行環境層做
論文二｜skill 寫錯不等於用起來會出事，要看模型怎麼反應
Why Static Skill Inconsistencies Do Not Equate to Runtime Risks: A Behavioral Analysis of LLM Agent Execution Fengrui Fan, Huahao Wang, Jingyi Fang et al.（Huazhong University of Science and Technology） · arxiv: 2610.18927
TL;DR
大規模稽核 575 個 agent skill 找到 1,182 筆人工驗證的內容衝突，64% 的 skill 受影響；但實際執行 49 個可觸發任務後發現，修復帶來的效益高度看模型——弱模型照單全收錯誤規格、強模型會自己糾正，靜態缺陷數量不能直接拿來預測真實風險。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint，已標示投稿 ACM FSE 2027（DOI 為占位格式，尚未確認正式接受） |
| 引用速度 | 發布 2 天，Semantic Scholar 查詢遭限流，未取得引用資料 |
| 機構 | Huazhong University of Science and Technology（華中科技大學） |
| 社群反應 | 未出現在 HF Daily Papers（10-14、10-15）；論文列有「Data Availability」標題，實際段落內容在這次擷取中缺失 |
| 可信度 | 通過 — RQ1–RQ3 結構清楚，575 個 skill、1,182 筆人工驗證缺陷、49 個可執行任務、441 條配對軌跡，並有明確的 Threats to Validity |
| 證據成熟度 | 初步 — 作者自陳 49 個可重跑任務是從 1,182 筆缺陷裡挑出「可操作化成可驗證任務」的子集，不能直接推到所有缺陷類型 |
| 可復現性 | 未提供（資料不足判斷） — 「Data Availability」標題下的正文段落缺失，公開範圍不明 |
| 為什麼選這篇 | 直接 — 回答「skill 寫得有問題，是不是等於用起來會出事」，是上一篇風險量測的另一半 |
| 方向新意 | 實質增量 — 把「靜態缺陷數量」與「實際執行時的行為影響」分開量測，證明兩者不等價 |
| 今日重要性 | 高 — 與同日的攻擊面量測合起來看，說明「skill 的風險」要同時看授權範圍與執行時行為，缺一不可 |
| 實務連結 | 明確 — 弱模型遇到錯誤規格傾向照做、強模型會主動修正，可做為選擇執行 skill 的模型時的參考 |
| 編輯信心 | 高 — 文章只陳述 49 個設計用來觸發目標缺陷的任務上的發現，作者也明說這不代表真實使用情境的自然曝露率 |
| 閱讀建議 | 必讀 — 維護內部 skill 庫或要決定「先修哪些缺陷」的團隊 |
| 主要限制 | 49 個任務是刻意設計成會觸發目標缺陷，曝露率不代表真實工作負載下的自然發生率 |
領域背景
LLM agent 越來越依賴可重複使用的 skill 套件來標準化工具用法，但套件裡文件、腳本、設定檔經常互相矛盾。過去的稽核方法只能數出「有多少處矛盾」，沒人系統驗證過這些矛盾真正被 agent 執行時，會不會真的影響結果。
中階導讀
- 問題：一份 skill 的說明文件寫「先檢查檔案存在再寫入」，裡面的腳本卻直接覆寫，兩者衝突。這種衝突到底有沒有關係，取決於 agent 會不會真的走到那段腳本，以及走到了之後聽不聽文件的話。
- 方法：先對 575 個社群與 benchmark skill 做大規模稽核，人工驗證出 1,182 筆內容衝突；再從裡面挑出 49 個可操作化成可驗證任務的衝突，分別在「沒有 skill」「原始有衝突的 skill」「修好的 skill」三種設定下，用三個模型跑出 441 條配對執行軌跡做行為分析。
- 為什麼重要：結果顯示，是不是每次都踩到衝突、踩到之後模型會不會自己糾正，才是決定風險大小的關鍵，而不是文件裡矛盾的數量本身。
深入要點
- 64% 的受測 skill 受衝突影響，但修復後的效益「因模型差異很大」，從明顯改善到幾乎沒差都有
- 幾乎所有執行實例都曝露到矛盾內容，排除「曝露頻率」是效果差異的來源
- 弱模型傾向照單全收錯誤規格，把缺陷帶進最終結果；強模型會主動在執行中糾正錯誤
- 論文結論：skill 的實際風險由「會不會執行到」與「執行到後模型怎麼反應」共同決定，靜態衝突數量不是好的風險代理指標
- 落地門檻：要做這種行為分析需要可控的任務環境與多模型測試資源，一般團隊更可行的做法是先盯「高曝露率」的 skill
- Limitation：49 個任務是刻意設計成會觸發目標衝突，曝露率不代表真實工作負載的自然發生率；修復本身是否只改動目標衝突，也可能帶有副作用
Reviewer 一句話評
把「缺陷數量」跟「執行時風險」分開測，是這個領域目前少見的嚴謹設計，RQ 之間的因果鏈很清楚；但論文裡 Data Availability 段落的正文內容缺失，資料與程式碼是否公開仍是未知數。
給你的 take-away
- 如果你在維護內部 skill 庫：先看哪些 skill 的衝突會被高頻率執行到，而不是先修矛盾數量最多的
- 如果你在選擇讓哪個模型執行 skill：弱模型對規格錯誤的容錯力比較差，錯誤規格更容易被它帶進最終結果，這點該算進模型選擇的風險裡
論文三｜agent 該用多大的模型，答案會隨任務長度整個反轉
When Is Smaller Greener? Right-Sizing Language Models for Agentic AI Sajid Siraj, Maria Barbati（University of Leeds、Ca' Foscari University of Venice） · arxiv: 2610.19345
TL;DR
用「每個成功任務」取代「每次呼叫」當耗能／成本比較單位後，15 個開源模型（0.6B–27B）的 pilot 顯示：任務步驟數會讓「最省電的模型」整個反轉——短任務選 1–3B，長任務卻是 8B 或 27B 更省，交叉點與公式預測大致吻合。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | 投稿中（Journal of the Operational Research Society）；arXiv preprint，未經同行審查 |
| 引用速度 | 發布 2 天，Semantic Scholar 查詢遭限流，未取得引用資料 |
| 機構 | University of Leeds、Ca' Foscari University of Venice |
| 社群反應 | 未出現在 HF Daily Papers（10-14、10-15）；無 Papers with Code 紀錄 |
| 可信度 | 通過 — 決策模型有明確的交叉點推導，並以 15 個開源模型、兩種多步驟任務、實測 GPU 耗能驗證預測結構，含 H1/H2/H4 三組假設檢定 |
| 證據成熟度 | 初步 — 作者自陳這是正式研究前的 pilot，預測是用同一批資料驗證（非留出測試），且只量到 GPU 板本身的耗能 |
| 可復現性 | 完整產物 — 作者說明原始呼叫紀錄、測試程式與分析腳本都在公開 repository，一行指令可從紀錄重算本節所有數字、表格與圖 |
| 為什麼選這篇 | 直接 — 回答「agent 該用多大的模型」這個每天都要做的選型決策，且證明「每次呼叫比較」會系統性誤導 |
| 方向新意 | 實質增量 — 把「每次呼叫的耗能／成本」換成「每個成功任務的耗能／成本」當比較單位，推出三個決策區間 |
| 今日重要性 | 中 — 多步驟 agent 部署持續擴大，耗能與成本是會直接出現在帳單上的決策，但本篇仍是 pilot 規模 |
| 實務連結 | 明確 — 任務長度落在哪個範圍該選哪個模型，論文給出可直接套用的交叉點公式 |
| 編輯信心 | 高 — 文章只引用 pilot 已驗證的部分（15 個模型、兩種任務），明確排除尚待完整研究驗證的 H3 |
| 閱讀建議 | 略讀 — 數學推導篇幅大，做模型選型或耗能／成本治理的人讀第 3、6、7 節即可 |
| 主要限制 | pilot 只測一張 GPU、兩種合成任務、27B 以下開源模型，且預測與觀測用的是同一批資料，完整留出測試還在後續研究 |
領域背景
選 agent 要用的 LLM，業界目前主要看兩種排行榜：最強的模型，或夠用裡最便宜的模型，兩者都是「每次呼叫」的比較。但多步驟任務只要有一步錯就整個失敗，每一步的小小可靠度差距，會在任務變長後被放大成完全不同的結局。
中階導讀
- 問題：模型 A 單步準確率 95%，模型 B 99%，看起來差距很小。但任務要走 20 步才算成功時，A 只有 36% 機率全對，B 卻有 82%；任務拉到 60 步，原本耗能少十倍的 A，耗能反而會輸給 B——因為失敗的嘗試還要重跑。
- 方法：作者提出用「每個成功任務」取代「每次呼叫」當比較單位，推出一套兩階段決策模型：先用不看偏好的 Pareto 篩選排掉在任何任務長度下都不划算的模型，再只在真正存在取捨時才套用偏好權重；並證明每種資源（耗能、成本、時間）都有自己的「交叉點」任務長度。
- 為什麼重要：這代表「選最省電的模型」這句話沒有單一答案——要先回答「任務多長」「這是哪種任務」，答案才會定下來。
深入要點
- Pilot 測 15 個開源模型（0.6B–27B，來自 Qwen、Gemma、Llama、Ministral、GLM 五家）在兩種多步驟任務上的實測 GPU 耗能
- 訂單任務：3 步到約 100 步時 Llama 3.2 3B 最省電，100 步後換成 Qwen3 8B；20 步時最省電的模型只用最大模型十分之一的電，但到 100 步時另一組模型反而要多耗四倍電 ⚠️（作者自測，15 次執行的 pilot 規模）
- 工具操作任務：最省電的模型換手點更早（4 步、20 步、30 步、50–60 步），只有 6 個模型完成得了 50 步的任務
- 預測交叉點跟實測交叉點大致吻合：88 組實際觀測到的交叉點中，72 組落在公式預測的 95% 信賴區間內
- 落地門檻：要套用這套框架，團隊得先能量每一步的可靠度與耗能，而不是只看現成排行榜分數
- Limitation：pilot 只測一張 GPU 板本身的耗能、兩種合成任務、27B 以下開源模型，且用來驗證預測的是同一批資料，不是另外留出的測試集
Reviewer 一句話評
把「每次呼叫比較」換成「每個成功任務比較」這個切角很扎實，文獻回顧也把這塊的四個缺口講得清楚；但目前只是 pilot，真正的留出測試與更大模型、真實 benchmark 的驗證還在後面。
給你的 take-away
- 如果你在幫 agent 選模型：別只看單次呼叫的排行榜分數，先估你的任務平均要跑幾步，再看哪個模型在那個步驟數附近最省資源
- 如果你在做 agent 的耗能或成本治理：把「失敗重跑的耗能」算進總帳，而不是只算成功那一次呼叫花了多少
今日收穫
之前以為「skill 市集的風險」主要是惡意程式碼，「模型選擇」主要是看排行榜分數。今天才發現：多數風險根本不是惡意，是正常運作但沒人量過的授權範圍；而「最省的模型」這個問題，答案會隨任務長度整個翻轉——這兩件事都要求你先量過，才有答案，看一眼宣告或排行榜都不夠。
參考資料
- Beyond Maliciousness: Attack-Surface Profiling of Agent Skills — arXiv 2610.19264
- Why Static Skill Inconsistencies Do Not Equate to Runtime Risks — arXiv 2610.18927
- When Is Smaller Greener? Right-Sizing Language Models for Agentic AI — arXiv 2610.19345
- Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale — arXiv 2601.10338
- “Do Not Mention This to the User”: Detecting Malicious Agent Skills in the Wild — arXiv 2602.06547
- Agent Skills specification — agentskills.io
- Extend Claude with skills — Anthropic docs
- arXiv cs.AI new submissions