技能的回歸稅 — 為什麼 LLM Agent 的技能既能幫忙也能幫倒忙

一句話核心結論

技能庫的常規評估只看平均任務成功率提升，但這隱藏了一個關鍵成本：技能也會讓已解決的任務崩潰。Sentient Labs 在 5,832 次配對任務執行中（2 個辦公室自動化基準 × 3 個模型棧 × 4 種技能條件），將淨效果分解為兩種轉換：增益（原本失敗、加技能後成功）和迴歸（原本成功、加技能後失敗）。結果令人震驚：553 次增益 vs 324 次迴歸——59% 的總增益被迴歸抵銷。更關鍵的是，最好的技能庫之所以最好，主要是因為迴歸較少，而非增益較多。論文識別出三種迴歸機制：(1) 技能描述滲透——技能僅因存在於 context 中就改變行為，即使從未被調用；(2) 接地置換——技能的程序覆蓋了 agent 對輸入的正確解讀；(3) 驗證置換——技能抑制了 agent 本來會執行的輸出檢查。分析殘留失敗（有無技能都失敗的任務）後發現：既有技能過度服務於方法/程序階段（最不需要幫助的環節），卻在接地和驗證階段（主要錯誤來源）供應不足。重新用完整試算表引擎驗算後，226 次被誤判的公式失敗得以回收。

核心洞察：技能的四種結局，而非一種

論文開篇就解構了技能評估的根本問題：

1. 傳統做法：跑一次有技能、一次無技能，比較平均成功率。Δ = 有技能成功率 − 無技能成功率。「+5%」看起來不錯，就此結案
2. 被隱藏的真相：同一個 Δ 可以來自「+15 增益、−10 迴歸」或「+5 增益、0 迴歸」——兩者淨效果相同，但第二個技能庫明顯更可靠
3. 四種結局框架：每任務配對有無技能各跑一次，落入四格之一：增益（無→有成功）、迴歸（有→無失敗）、殘留失敗（兩者皆敗）、保留（兩者皆成）
4. 反直覺發現：在 Claude Code × Sonnet 4.6 的 OfficeQA-Pro 上，三個技能庫的增益數幾乎相同（10、11、12），但迴歸數差了三倍（2、4、7）。排名逆轉——增益最多的 openai 淨效果最差；增益最少的 anthropic 淨效果最好

機制一：技能描述滲透（Skill-Description Osmosis）

最顛覆直覺的發現：技能不需要被調用就能改變 agent 行為。技能描述常駐在 system prompt 中每一回合，即使技能主體從未被讀取。

• 證據：OfficeQA-Pro 上 sonnet-4.6 的 13 次迴歸中有 9 次（69%）為滲透——技能 body 從未被調用，但答案改變了
• 案例 UID0096：Task 要求 customs-duty rate 的中心移動平均（正解 0.377）。無技能時答 37.708%（正確），三個不同技能庫在場且皆未被調用時全部答 38.757%（錯誤）。三個獨立撰寫的技能庫收斂到同一個錯誤答案——僅因描述中存在 "revised" 和 "customs" 關鍵詞就改變了 agent 對任務的解讀框架
• 雙面刃：滲透也會幫忙——OpenCode × minimax 在 SpreadsheetBench 的 52/62 增益（84%）是無調用式的。但 70/243 迴歸也是滲透
• 對 Hermes 的警示：Hermes skill library 的描述文字常駐於 system prompt——即使某個 skill 永遠不被觸發，它的描述詞彙也在汙染 agent 的解讀框架

機制二：接地置換（Grounding Displacement）

當技能確實被調用時，最常見的迴歸模式（73%，59/81）：技能的程序覆蓋了 agent 對輸入的正確解讀。

• 案例 UID0025：無技能時 agent 正確讀取了 1934 和 1946 年公共工程支出（差值 142）。加入 anthropic 技能庫後調用了兩個導航+算術技能，技能的程序引導它讀取了另一組數字，回傳 542——接地方向錯了，不是方法錯了
• 為什麼接地主導迴歸：通用導航技能（「找到表格中的數字」「計算年度變化」）不包含該任務特有的接地資訊——哪個表格、哪個年份、哪個定義。agent 本來的接地是正確的，技能的程序卻讓它「相信」了錯誤的接地
• 跨庫結構：同一任務在不同技能庫下因跟隨不同的程序而落入不同的接地錯誤——證明了問題出在技能的程序而非 agent 本身

機制三：驗證置換（Verification Displacement）

技能抑制了 agent 本該執行的輸出檢查。方法本身可能正確，但缺乏驗證環節導致答案未被確認就輸出。

• SpreadsheetBench 的大規模回收：用完整試算表引擎（實際打開活頁簿讓公式重算）重新驗證 663 次含公式的失敗——226 次（34%）的公式本身是正確的，僅因原版 value-only grader 無法評估某些函數（AGGREGATE 等）而被誤判為失敗
• 回收規模：各技能庫被回收 +11 到 +49 個任務。GPT-5.4-mini 棧從 mid-60s 拉升到 high-70s（+42~49）
• 教訓：這些任務的 agent 已經做了最難的部分（寫出正確公式），失敗只發生在驗證環節——而技能庫完全沒有提供驗證指導。一個簡單的「檢查你的公式輸出是否合理」就能回收數十個任務

殘留失敗診斷：方法不是瓶頸

既有技能和無技能都失敗的任務（殘留失敗）揭示了技能設計的根本偏差：

• OfficeQA-Pro：24 個殘留失敗中，23 個仍產出數值答案——agent 執行了方法（讀表→計算→輸出），但計算的是錯的數量。接地階段才是真正的瓶頸，但技能只教方法不教接地
• SpreadsheetBench：殘留失敗集中在輸出驗證階段——公式已存在但未被檢查。技能教了如何寫公式，沒教如何確認公式結果正確
• 技能設計偏差圖（Figure 1）：技能過度服務於中間的「方法」階段（最不需要幫助的環節），卻在「接地」和「驗證」兩個端點（主要錯誤來源）供應嚴重不足

對 Hermes / DKY 的啟發

• 技能評估必須拆解增益與迴歸：Hermes 目前只追蹤 skill 是否被使用、任務是否完成。回歸稅框架要求追蹤「這個 skill 加入前後，哪些任務從成功變失敗」。最簡單的實作：保留一組校準任務集，每次新增 skill 後重跑，計算 gain/regression 配對
• 技能描述的隱性成本：Hermes skill 的 description 欄位常駐於 system prompt。滲透機制意味著每個 skill description 都在汙染 agent 的解讀框架——即使該 skill 永遠不被觸發。應引入 skill description 精簡原則：每個詞都必須對該 skill 的觸發有必要性，否則應刪除
• 技能應包含接地與驗證，而非只有方法：現有 Hermes skill 幾乎全是程序指南（「如何做 X」）。回歸稅的教訓：應強制每個 skill 包含 (a) 何時不該使用此 skill（避免接地置換）和 (b) 如何驗證輸出正確（避免驗證置換）
• 「不要做」比「怎麼做」更重要：最安全的 skill 是告訴 agent 何時不該干涉——當 baseline 已正確接地時，skill 應被設計為「觀察到正確接地時不介入」
• 回收假性失敗的啟發：Hermes 任務完成判定可能低估實際成功率——一個看似失敗的任務，可能只是驗證環節未執行，而非方法錯誤。引入執行後驗證層（post-execution verification）可回收大量假性失敗

限制

• 配對比較每條件僅執行一次（無 seed 複製），無法估計 run-to-run 變異數——部分單任務 flip 可能來自隨機性而非真正的 skill 效應
• 跨庫對比未控制 token 數量或描述長度——無法排除「更長的 prompt 導致注意力稀釋」的混雜效應
• 僅 3/18 條件通過 Bonferroni 校正——大多數淨效果在統計上不顯著，效應量可能被高估
• 兩個基準均為辦公室自動化領域（文件 QA + 試算表操作），結論不一定能推廣到程式開發或開放式 agent 任務
• 機制分類由單一作者標記（subjective coding），非雙盲或自動化分類
• 未測試技能組合的交互效應——真實部署中 agent 同時持有多個 skill，交互作用可能產生新的迴歸模式