AI 代理／評測
相關技能也可能拖垮代理：307 個失敗案例多源於錯誤實作與過度驗證
微軟研究院等團隊以有、無技能的成對軌跡，確認 125 個功能失敗及 182 個效率退步案例。問題通常不是技能不相關，而是代理把通用範例、驗證清單或環境假設誤當成任務硬性要求。
代理技能通常以 `SKILL.md` 封裝程序、範例及驗證規則，但「內容與任務相關」不代表載入後一定有益。微軟研究院、華中科技大學等研究者提出差分稽核方法：固定模型、代理框架、任務、容器與驗證器，只改變技能配置；若有技能的執行失敗，而無技能或另一個語意相近技能的執行成功，便把後者當作偽 oracle，定位技能造成的行為差異。[論文](https://arxiv.org/abs/2608.11888)
研究從 [SkillsBench](https://www.skillsbench.ai/) 與 [SWE-Skills-Bench](https://github.com/GeniusHTX/SWE-Skills-Bench) 出發，再從公開技能站檢索相似候選，把潛在成對比較由 826 組擴至 20,664 組。經排除證據不足、驗證器過窄及重複案例後，留下 307 個技能誘發問題：125 個功能失敗與 182 個高信心效率退步。功能失敗中，86 例屬任務實作錯誤；其中 46 例填入錯誤 API、值或輸出結構，36 例直接漏掉必要元素。只有兩例源自技能適用範圍本身判斷錯誤。
效率退步的門檻是 token 與時間都增加，且至少一項超過參考執行兩倍。114 例來自額外程序，當中過度測試、重建或除錯占 67 例；純粹由技能正文膨脹上下文造成的則有 43 例。團隊另以 SkillTriage 分析成對軌跡，對功能失敗的精確子類別符合人工標註 88.8%，效率問題為 72.5%。
工程上的訊息不是停用技能，而是把技能視為需要版本化評測的執行政策：正文保持精簡，範例與完整清單延遲載入，並依變更風險與剩餘預算縮放驗證範圍。不過實驗只使用 OpenCode 1.15.1 與 Claude Opus 4.6，根因分類亦包含人工判斷；結果是否能跨模型、框架及企業私有技能重現，仍待驗證。