技能的回歸稅：分解為什麼技能幫助與傷害 LLM Agent

技能庫的常規評估只看平均任務成功率提升，但這隱藏了一個關鍵成本：技能也會讓已解決的任務崩潰。Sentient Labs 在 5,832 次配對任務執行中，將淨效果分解為增益和迴歸：553 次增益 vs 324 次迴歸——59% 的總增益被迴歸抵銷。最好的技能庫之所以最好，主要是因為迴歸較少，而非增益較多。三種迴歸機制：(1) 技能描述滲透——技能僅因存在於 context 中就改變行為；(2) 接地置換——程序覆蓋正確的輸入解讀；(3) 驗證置換——程序抑制輸出檢查。既有技能過度服務於方法階段，卻在接地與驗證階段失靈。

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

1. 傳統做法：比較平均成功率。Δ = +5% 看似不錯，就此結案
2. 被隱藏的真相：同一個 Δ 可以來自「+15 增益、−10 迴歸」或「+5 增益、0 迴歸」——第二個技能庫明顯更可靠
3. 四種結局框架：每任務配對落入四格：增益、迴歸、殘留失敗、保留
4. 反直覺：Claude Code 上三個技能庫增益數幾乎相同（10/11/12），但迴歸數差三倍（2/4/7）。增益最多的 openai 淨效果最差

技能不需要被調用就能改變 agent 行為。技能描述常駐 system prompt，即使主體從未被讀取。

• 證據：sonnet-4.6 的 13 次迴歸中 9 次（69%）為滲透——技能 body 從未被調用，答案卻改變了
• 案例 UID0096：三個獨立技能庫在場且皆未被調用，全部收斂到同一錯誤答案——僅因描述中 "revised" 和 "customs" 關鍵詞改變了 agent 的解讀框架
• 雙面刃：滲透也會幫忙（84% 的 SpreadsheetBench 增益是無調用式），但也造成 70/243 迴歸

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

• 案例 UID0025：無技能時 agent 正確讀取數字得 142。加入技能後被導航程序引導到錯誤的數字，回傳 542——接地錯了，不是方法錯了
• 根因：通用導航技能不含該任務特有的接地資訊（哪個表格、哪個年份）。agent 本來的接地是正確的，技能讓它「相信」了錯誤的接地

技能抑制了 agent 本該執行的輸出檢查。方法正確，但缺乏驗證環節。

• 大規模回收：完整試算表引擎重算 663 次公式失敗——226 次（34%）公式本身正確，僅因 value-only grader 無法評估而被誤判
• 回收規模：GPT-5.4-mini 棧從 mid-60s 拉到 high-70s（+42~49）
• 教訓：agent 已寫出正確公式，失敗只在驗證環節——技能完全沒提供驗證指導

• OfficeQA-Pro：24 個殘留失敗中 23 個仍產出數值——方法執行了，但計算的是錯的數量。接地是真正的瓶頸
• SpreadsheetBench：殘留失敗集中在輸出驗證階段。技能教了如何寫公式，沒教如何確認結果正確
• 技能設計偏差：過度服務於方法階段（最不需要幫助），卻在接地和驗證（主要錯誤來源）供應不足

• 技能評估必須拆解增益與迴歸：保留校準任務集，每次新增 skill 後重跑並計算 gain/regression 配對
• 技能描述的隱性成本：每個 skill description 都在汙染 agent 的解讀框架——即使從不被觸發。應精簡 description 至觸發必要詞彙
• 技能應包含接地與驗證，而非只有方法：強制每 skill 包含 (a) 何時不該使用 和 (b) 如何驗證輸出
• 「不要做」比「怎麼做」更重要：最安全的 skill 告訴 agent 何時不該干涉
• 引入執行後驗證層：可回收大量假性失敗——任務看似失敗，可能只是驗證未執行

• 每條件僅執行一次，無 seed 複製——部分 flip 可能來自隨機性
• 跨庫對比未控制 token 數量，無法排除注意力稀釋效應
• 僅 3/18 條件通過 Bonferroni 校正，多數淨效果不顯著
• 兩個基準均為辦公室自動化，不一定推廣到其他 agent 任務
• 機制分類為單一作者主觀標記
• 未測試技能組合交互效應