Agent Skills Can Be Harmful：當技能反而傷害 Agent — 307 個技能誘發失敗的實證拆解
一句話核心結論
技能（skill）是擴充 LLM agent 的標準機制，但 Microsoft Research 這篇實證研究揭示一個反直覺真相：傷害 agent 的通常不是明顯不相關的技能，而是「看起來很相關」的技能。透過差分分析框架（把技能引導的執行與無技能／語義匹配技能的參考執行逐案對比），研究在 SkillsBench 與 SWE-Skills-Bench 上確認 307 個技能誘發失敗——其中 125 個功能失敗、182 個效率迴歸。核心發現：Task-Implementation Fault 佔功能失敗的 68.8%（看似相關的技能讓 agent 把任務要求的實作元素做錯或漏做）；Excessive Procedure 佔效率迴歸的 62.6%（技能把「驗證清單」和「建構配方」變成每案都強制執行的額外工作，過度驗證 67 例、重型建構管線 30 例）。團隊同時釋出 SkillTriage，一個分類學引導的自動歸因工具，以 88.8% 準確率定位功能失敗根因。
307 個失敗
125 功能失敗 + 182 效率迴歸。SkillsBench + SWE-Skills-Bench 兩個基準、差分對比確認
相關技能才致命
功能失敗中僅 2 例（1.6%）是明顯不相關技能。68.8% 是 Task-Implementation Fault
不是 prompt 太長
效率迴歸 62.6% 是 Excessive Procedure（多做步驟），只有 25.3% 是 context 膨脹
SkillTriage
分類學引導自動歸因，功能失敗 111/125（88.8%）、效率迴歸 132/182（72.5%）命中根因
方法：差分分析框架（Differential Analysis）
技能的效果「好壞混雜」是已知事實，但過去研究無法把失敗歸因到具體技能。這篇論文的關鍵貢獻是把「差分測試」的思維搬到技能評估上：
- 對照構建（Contrastive Construction）：每個目標技能引導的執行，配對一個「無技能」或「語義匹配技能」的參考執行作為偽神諭（pseudo-oracle），解同一道題。若目標執行失敗而參考執行成功 → 確認是技能誘發的功能失敗；若目標執行 token 與時間雙雙增加、且至少一項超過 T=2.0 門檻 → 確認是技能誘發的效率迴歸
- 根因分類（Taxonomy）：功能失敗分四類（適用性錯配／環境錯配／任務實作錯誤／產物錯位）；效率迴歸分三類（context 膨脹／過度程序／依賴解析）
- 自動歸因（SkillTriage）：正規化配對案例 → 抽取差分證據 → 產出分診報告，把失敗歸因到具體子類
這個框架之所以重要，是因為它把「技能好不好」從主觀感受變成可量測、可歸因、可自動化的工程問題。
功能失敗分類：125 例
| 類別 | 定義 | 數量 | 佔比 |
|---|---|---|---|
| Task-Implementation Fault (TIF) | 看似相關的技能讓 agent 把任務要求的欄位、API 行為、計算、輸出格式或領域規則做錯或漏做 | 86 | 68.8% |
| Artifact Misplacement (AM) | 產物被放到與任務指定路徑或整合點不同的位置 | 24 | 19.2% |
| Environment Mismatch (EM) | 技能推薦或依賴的依賴套件／runtime 在環境中失效，或間接導致環境狀態錯配 | 13 | 10.4% |
| Applicability Mismatch (APM) | 技能的 metadata 給出不完整／誤導的適用性信號，導致 agent 在不適用的任務上套用技能 | 2 | 1.6% |
TIF 內部：Incorrect Required-Element Fill（IRF，做錯必要元素）+ Required-Element Omission（RRO，漏做必要元素）合計 82 例，是 TIF 的主體。
效率迴歸分類：182 例
| 類別 | 子類 | 數量 | 佔比 |
|---|---|---|---|
| Excessive Procedure (EP) | Excessive Verification（過度驗證：重複測試／除錯／重建／清單核對） | 67 | 36.8% |
| Heavy Implementation Pipeline（重型建構管線） | 30 | 16.5% | |
| Excessive Exploration（過度探索） | 17 | 9.3% | |
| Context Bloat (CO) | Skill-Body Context Bloat 43 + Supplementary-Material Bloat 3 | 46 | 25.3% |
| Dependency Resolution (DO) | 技能引導 agent 使用脆弱／不相容的 runtime 依賴，需要安裝與配置才能跑通 | 22 | 12.1% |
Excessive Procedure 小計 114 例（62.6%），遠高於 Context Bloat 的 46 例（25.3%）——直接推翻「效率迴歸只是因為 prompt 變長」的直覺。
四大發現
- 相關技能才致命：125 個功能失敗中只有 2 個（1.6%）可歸為「明顯不相關的技能」。絕大多數是「看起來高度相關」的技能，卻讓 agent 把任務要求的必要元素做錯或漏做（TIF 68.8%，其中 IRF+RRO 佔 82 例）
- 效率迴歸不是 prompt 太長：Excessive Procedure 佔 62.6%，遠高於 Context Bloat 的 25.3%。技能把可選活動變成強制步驟——倉庫檢查、重型建構流程、重複驗證、廣範圍診斷
- context 膨脹幾乎全來自強制技能正文：46 例 context 開銷中，43 例是 Skill-Body Context Bloat（強制載入的技能正文），僅 3 例是補充材料膨脹。技能正文應精簡，範例／範本／長清單應改為延遲載入
- 過度驗證與重型建構管線是最大來源：Excessive Procedure 內，Excessive Verification 67 例、Heavy Implementation Pipeline 30 例。技能作者應讓驗證範圍與建構深度依任務不確定性、變更規模與預算調整，而非預設無條件跑完整流程
對 Hermes / DKY 的啟發
- Hermes 本身就是重度技能系統：Hermes 的技能（skill）、Profile、Kanban 派工機制正是這篇論文研究的對象。它的結論直接適用於 DKY 的技能庫設計——「看起來相關」的技能（例如某個部署 skill）可能正把不必要的驗證步驟或重型管線強加給每一次任務
- 技能的驗證清單要「按需縮放」：論文最大發現是「技能把驗證清單和建構配方變成強制工作」。DKY 的技能文件裡大量 checklist（如部署五步檢查），應該標明何時可跳過、依任務不確定性與變更規模縮放，而不是每次都無條件跑完整流程
- 精簡技能正文、延遲載入範例：context 膨脹 93%（43/46）來自強制正文。技能文件應把「永遠載入的指令」壓到最短，範例、範本、長清單、背景資料移到明確的 lazy-load 觸發器之後
- 差分評估是技能品質的黃金標準：與其問「這個技能有沒有用」，不如問「同一個任務，加技能 vs 不加技能，成功率和成本差多少」。DKY 對自有技能的評估應採用這種配對對比，而非單次成功與否
- 「看起來相關」是最大的風險信號：技能適配性不能只靠名稱與描述判斷。適用性錯配（APM）雖只佔 1.6%，但真正的殺手是「相關但不精準」的技能——它會讓 agent 信心滿滿地做錯。技能載入應是「有成本、需驗證」的決策，而非預設動作
限制
- 結論基於 SkillsBench 與 SWE-Skills-Bench 兩個以軟體工程／通用任務為主的基準，未覆蓋創意寫作、科學推理等非工程任務的技能失敗模式
- 效率迴歸以 T=2.0 的 token/時間倍增門檻界定「高信心」，更細微的迴歸（如 1.5×）可能被排除
- SkillTriage 對效率迴歸的精確子類歸因（72.5%）低於功能失敗（88.8%），邊界案例（如 Excessive Exploration vs Heavy Pipeline）仍難自動區分
- 研究以單一 agent 框架與特定技能庫為基礎，跨框架（不同 harness／不同技能格式）的泛化性待驗證