Agent Skills Can Be Harmful: An Empirical Study of Skill-Induced Failures in LLM Agents
Gen Dong, Yanjie Gao, Liqun Li, Tianyin Xu, Yu Hua, Fan Yang
cs.AI
2026-08-12
微软等对比2万余组Agent运行,确认307起技能诱发故障,近七成因技能把必填实现做错而非选错技能。
Agent skill(技能包,通常是一个 SKILL.md 文件)现在是给 LLM agent 扩展可复用操作指南的标准做法。但此前的技能评测基准只给出「用了技能后通过率是涨是跌」这种聚合数字,SkillsBench 报告过技能让 16/84 个任务通过率下降,SWE-Skills-Bench 也见过 token 开销暴涨到 451% 的案例。这些数字说明技能会帮忙、会添乱、也会浪费资源,但没人说清楚是技能里的哪一段指令、通过什么机制,把一次原本能做对的任务做错了,或者把一次原本很便宜的任务做贵了。没有这层归因,技能市场没法做筛查,出问题的技能会被反复加载、反复拖累后续任务。
论文借鉴 differential testing 的思路,给每个任务配一对「目标运行」和「参照运行」:目标运行加载被审查的技能,参照运行要么完全不加载技能,要么加载一个语义相近的替代技能(从 smithery.ai、skillsmp.com 检索,用 all-MiniLM-L6-v2 做嵌入,余弦相似度 ≥0.7 才留下)。两次运行固定任务、代码仓库、agent 框架(OpenCode 1.15.1)、模型(Claude Opus 4.6),只有技能设置不同。
在 SkillsBench(84 任务)和 SWE-Skills-Bench(490 任务)上,潜在配对空间从原始的 826 组扩展到 20664 组,跑完实际评测后筛出 665 条候选,人工核对去掉证据不足、验证器过窄、重复案例后,定稿 307 起确认的技能诱发故障:125 起功能性失败、182 起高置信度效率退化。作者进一步给每起失败标注根因子类,并训练了一个基于 GPT-5.5、跑三次投票的自动归因工具 SKILLTRIAGE。
| 失败类型 | 子类 | 数量 | 占比 |
| 功能性失败 | Task-Implementation Fault(必填项做错/漏做) | 86 | 68.8% |
| 功能性失败 | Artifact Misplacement(产出物放错位置) | 24 | 19.2% |
| 功能性失败 | Environment Mismatch(环境状态不一致) | 13 | 10.4% |
| 功能性失败 | Applicability Mismatch(技能压根不该用) | 2 | 1.6% |
| 效率退化 | Excessive Procedure(多余探索/验证/实现步骤) | 114 | 62.6% |
| 效率退化 | Context Bloat(技能正文撑大上下文) | 46 | 25.3% |
| 效率退化 | Dependency Resolution(依赖修复耗时) | 22 | 12.1% |
最反直觉的发现是:功能性失败里只有 2 起(1.6%)是因为技能压根用错了场景。剩下八成多是「看起来相关的技能」把某个必填实现元素做错了方法、值或结构(Incorrect Required-Element Fill,46 起),或者干脆漏掉了(Required-Element Omission,36 起)。效率退化那边,114 起 Excessive Procedure 里,67 起单纯是过度验证,技能把「运行完整测试套件、修完所有失败再停」这种校验清单直接变成了强制步骤。
SKILLTRIAGE 的自动归因效果:功能性失败上,高层类目匹配人工标注 117/125(93.6%),精确到子类 111/125(88.8%);效率退化上,类目匹配 145/182(79.7%),精确子类 132/182(72.5%)。
如果你在给 agent 平台接技能市场,这篇给出一个具体、可操作的筛查方向:审查技能时别只看它相不相关,要看它有没有把可选的示例、模板、检查清单,悄悄写成了「必须照做」的强制步骤,这是导致故障的主因,不是文不对题。对于自己写技能文档的人,论文的隐含建议是把任务硬性要求和参考示例、可选工作流在写法上分开,并且把长篇的示例、模板挪到按需加载的补充材料里,而不是塞进每次都会被读入上下文的正文。SKILLTRIAGE 展示的另一个可能性是,这类归因分析本身可以自动化到接近人工水平,意味着技能市场未来有可能做到持续、低成本的质量审计,而不是每次靠人工复盘。
论文自己承认的边界:研究只覆盖了 SkillsBench 和 SWE-Skills-Bench 两个基准,任务分布、agent 框架(OpenCode)、模型(Claude Opus 4.6)固定,结论是否能直接搬到别的技能生态或别的模型上没有验证。归因过程依赖人工判断验证器是否比任务本身窄、目标运行和参照运行的差异是否真的由技能引起,作者也承认这层主观性是内部效度的主要威胁,虽然用了组内共识来降低。另外,SKILLTRIAGE 的剩余错误集中在相邻子类的边界上,比如把某个必需的辅助函数缺失误判成实现错误而不是必需元素缺失,说明分类边界本身并不总是清晰,自动化工具还没到可以完全替代人工复核的程度。