幫 AI 裝上「技能」反而害它做錯事：307 個失敗案例裡，闖禍的多半是看起來很相關的那幾個

先說這篇論文最違反直覺的一句話：

讓 AI 代理出錯的，很少是那些明顯不相關的技能。真正闖禍的，是看起來很相關、你會很放心掛上去的那幾個。

先解釋什麼是「技能」

現在要讓 AI 代理變強，主流做法是給它「技能」（agent skills）——一份可重複使用的指引，告訴它遇到某類任務該怎麼規劃、用哪些工具、怎麼驗證結果。

聽起來只有好處。但過去的研究結果一直很分歧：有些技能確實提高成功率，有些完全沒效果，有些反而增加 token 用量與執行時間，甚至讓成功率下降。

這篇論文（arXiv:2608.11888，2026 年 8 月 12 日投稿）想回答的是：到底是哪個技能害的？

他們怎麼抓兇手

研究者做了一套「差分分析」框架：同一個任務，跑三種版本互相比對——

• 掛上目標技能的版本
• 不掛任何技能的版本
• 掛上語意相近的另一個技能的版本

如果同一個任務，沒掛技能能解、掛了反而解不出來，或是解得出來但貴很多，那筆帳就記到這個技能頭上。

抓到了什麼

他們在 SkillsBench 與 SWE-Skills-Bench 兩個測試集上跑，歸因出 307 個由技能引起的失敗，分成兩類：

• 125 個功能性失敗　任務直接做錯或做不出來。
• 182 個效率退化　做得出來，但比不掛技能還貴、還慢。

注意這個比例：效率退化的案例比功能失敗還多。也就是說，技能最常見的傷害不是「弄壞」，而是「變貴」——而變貴這件事，通常沒有人在盯。

三個具體發現

一、闖禍的是「看起來很相關」的技能。論文的原話是，功能性失敗「rarely caused by obviously irrelevant skills」；反而是那些貌似對題的技能，讓代理錯誤地實作、或直接省略了任務要求的元素。

這點很重要，因為它推翻了一個很自然的防呆想法：「我只掛相關的技能就好了」。這篇說，那正是出事的地方。

二、變貴不能只怪提示變長。研究者特別檢查了這點——效率退化「not explained by prompt length alone」。多塞了字進去只是其中一部分，真正的成本在於技能改變了代理的行為。

三、最大的成本黑洞是「過度程序」。在這個類別裡，兩個最大來源是：

• 過度驗證　67 例
• 過重的實作流程　30 例

論文的結論一針見血：技能常常把「驗證清單」和「施工配方」變成了強制工作。本來是給參考的，代理當成了非做不可的。

為什麼台灣的企業該看這個

一、這解釋了很多「導入後反而更慢」的抱怨。如果貴公司導入 AI 代理後，感覺它做事變得囉嗦、每件小事都要繞一大圈確認，這篇給了名字：過度驗證，67 例裡最大的一類。

二、技能庫需要定期清理，而不是只增不減。多數團隊掛技能只加不減，因為「加了應該不會更差」。這篇證明會更差，而且平均起來，變貴的機率比變壞的機率更高。

三、成本要跟成功率一起量。只看「任務有沒有完成」會漏掉 182 個案例中的絕大多數。這與我們在代理可靠度與 DSAgentBench 兩篇談到的量測盲點是同一件事：沒被量的東西，就不會被管。

需要保留的懷疑

這是 arXiv 預印本，在本文寫作時尚無同儕審查紀錄。

• 307 個案例全部來自 SkillsBench 與 SWE-Skills-Bench 兩個測試集。這兩者偏向軟體工程任務，換到客服、文件處理、製造現場是否成立，論文沒有回答。
• 摘要沒有交代測試涵蓋哪些模型，也沒說跨模型的一致性如何。同一個技能在不同模型上未必壞在同一個地方。
• 論文提出了 SkillTriage 這個歸因工具，但摘要未提供該工具本身的準確率。歸因工具本身會不會錯判，是個公道的疑問。

常見問題

幫 AI 代理加技能會有什麼風險？

這篇論文在兩個測試集上歸因出 307 個由技能引起的失敗，其中 125 個是功能性失敗（任務做錯或做不出來），182 個是效率退化（做得出來但比不掛技能更貴、更慢）。值得注意的是效率退化的案例數比功能失敗更多，代表技能最常見的傷害是讓成本上升，而這通常沒有人在監控。

只掛「相關」的技能是不是就安全了？

論文的發現正好相反。功能性失敗很少由明顯不相關的技能造成，反而是那些看起來很對題的技能，讓代理錯誤地實作、或直接省略了任務要求的元素。所以「只掛相關的就好」這個防呆想法，正是出事的地方。

為什麼掛了技能之後 AI 做事變得很囉嗦？

論文把這歸類為「過度程序」，其中兩個最大來源是過度驗證（67 例）與過重的實作流程（30 例）。原因是技能常把原本只是參考用的「驗證清單」與「施工配方」，變成了代理認定非做不可的強制工作。