https://x.com/peterpme/status/2100947795788128297… https://arxiv.org/html/2608.11888v1… https://x.com/robinebers/status/2106311149545533710… https://x.com/kirill_shevch/status/2091100277990465848…

Agent Skills 可能有害：LLM Agent 中技能诱发失败的实证研究

来源：https://arxiv.org/html/2608.11888v1 Gen Dong1、Yanjie Gao2、†、Liqun Li3、Tianyin Xu4、Yu Hua1、Fan Yang2 单位：1华中科技大学　单位：2Microsoft Research　单位：3Microsoft　单位：4伊利诺伊大学厄巴纳-香槟分校

摘要

Agent skills 是目前为 LLM Agent 扩展可复用指导的事实上的标准机制。一个 skill 可以影响 Agent 的任务执行方式，涵盖规划、工具使用、问题求解与验证等环节。既往研究关于 agent skills 的结论并不一致：部分 skill 能提升任务成功率，另一些则毫无作用，甚至会增加 token 消耗与执行时间，乃至降低成功率。本文对 skill 诱发的 Agent 失败进行了系统分析，将任务失败与成本回退归因到具体加载的 skill 上。我们提出了一个差分分析框架：通过将目标 skill 引导的运行与「无 skill」或「语义匹配 skill」的参考运行（该参考运行解决了同一任务，或以更低成本完成该任务）进行对比，把某次失败或回退归因到某个 skill。我们将该框架在 SkillsBench 和 SWE-Skills-Bench 上加以实例化，共得到 307 例 skill 诱发失败，其中包含 125 例功能失败与 182 例效率回退。我们还构建了 SkillTriage——一个基于分类法的归因工具，它能对成对样本进行规范化、提取差分证据并生成分诊报告。主要发现包括：(1) skill 诱发的功能失败很少由明显不相关的 skill 导致；相反，看似相关的 skill 往往会让 Agent 错误实现或遗漏任务所必需的实现要素。在 125 例功能失败中，**任务实现缺陷（Task-Implementation Fault）**占 86 例（68.8%），产物位置错误与环境不匹配分别占 24 例和 13 例。(2) skill 诱发的效率回退并不能仅由 prompt 长度来解释。当回退源于上下文开销时，几乎全部由 skill 正文的强制文本造成（46 例上下文开销案例中有 43 例），但从整体上看，**过度流程（Excessive Procedure）**占主导，182 例中有 114 例（62.6%）。(3) 在过度流程内部，最大的来源是过度验证与沉重的实现流水线，分别贡献 67 例和 30 例。这表明 skill 往往会把验证清单和构建配方变成必须完成的额外工作。基于上述发现，我们提出了相关研究课题与工具改进方向，以实现更安全、更注重成本的 skill 复用。

00footnotetext:本工作是在 Gen Dong 于 Microsoft Research 实习期间完成的。†通讯作者。

I　引言

LLM Agent 正越来越多地被用于解决复杂的软件工程及其他知识密集型任务，其方式是将模型推理与工具、代码仓库及外部环境相结合。为了让过程性指导能在不同任务间复用，近期的系统引入了 skills：即把任务特定的流程、示例、约束与工具使用指导编码为指令包。一旦被选中，skill 就会被插入 Agent 的上下文，并可能影响规划、文件编辑、命令执行、验证以及停止决策。

然而，这种机制也带来了风险。一个 skill 可能在主题上与任务相关，但在具体操作上并不正确：它可能暗示一条不兼容的路径、过度规定某个工作流、引入不兼容的依赖或运行时状态，或鼓励不必要的验证。这类指导可能在任务失败时导致功能失败，或在任务只有以显著更高的 token 消耗或更长执行时间才能通过时导致效率回退。这些问题尤其棘手，因为 skill 本就是为复用而设计的，因此一个有害的 skill 会反复对未来 Agent 的执行产生偏置。

最近的 skill 基准测试表明，这一风险并非凭空假设。SkillsBench 报告了精心筛选的 skill 带来的平均收益，但也观察到 84 个任务中有 16 个任务的通过率下降 [1 (https://arxiv.org/html/2608.11888v1#bib.bib4)]。SWE-Skills-Bench 报告称平均改进有限，许多 skill 没有通过率提升，且有案例的 token 开销高达 451% [2 (https://arxiv.org/html/2608.11888v1#bib.bib5)]。这些结果表明，skill 既可能带来帮助、也可能造成伤害或浪费资源，具体取决于任务与 skill 内容。

然而，现有评测留下了四个缺口，使得 skill 诱发失败难以研究。第一，核心挑战不只是检测失败的运行，而是把失败隔离出来并归因到所加载的 skill 上。单独一次带 skill 的失败运行，无法区分 skill 诱发的危害、基座 Agent 的能力局限、验证器的作用范围、Agent 本身的常规波动，或环境因素造成的伪失败。因此，识别 skill 诱发失败需要对比证据。第二，现有的 skill 基准测试旨在衡量效用，而非揭示失败机制。因此，它们原始的 skill 设置难以提供研究 skill 诱发失败所需的负样本。第三，聚合的通过率与成本比给出了结果层面的指标，却无法解释 skill 是如何改变 Agent 轨迹的。关于长上下文、无关上下文以及 prompt 敏感性的相关研究可以解释广义的上下文效应 [3 (https://arxiv.org/html/2608.11888v1#bib.bib8)、4 (https://arxiv.org/html/2608.11888v1#bib.bib9)、5 (https://arxiv.org/html/2608.11888v1#bib.bib12)、6 (https://arxiv.org/html/2608.11888v1#bib.bib10)]，但它们并不能识别某个具体的 skill 文档究竟是如何导致面向验证器的功能失败，或导致被隐藏的效率回退。最后，即便人工进行了失败归因，这种方法也无法扩展到 Agent 平台或 skill 市场——在这些场景中，新的 skill 以及 skill 的更新必须被持续筛查。

在本文中，我们对 LLM Agent 中 skill 诱发的失败进行了一项系统的实证研究。受差分测试（differential testing）[7 (https://arxiv.org/html/2608.11888v1#bib.bib31)] 的启发，我们构造了成对的目标/参考执行，其中以「无 skill」或「语义匹配 skill」的执行作为伪预言机（pseudo-oracle）。只有当同一任务在该成对比较设置下本可以被解决、或能以更低成本解决时，该设计才会把失败归因于 skill。我们将该研究在 SkillsBench 和 SWE-Skills-Bench 上加以实例化，用语义匹配的公开 skill 对原始基准设置进行补充，并分析任务规格、skill 内容、执行轨迹、验证器结果、token 消耗与执行时间。随后，我们为功能失败与效率回退推导出根因分类法，并构建了 SkillTriage——一个基于分类法的工具，用于规范化成对样本、提取差分证据并生成用于分诊的归因报告。

具体而言，本研究回答以下研究问题：

1. 1.RQ1：如何为根因分析构造一个 skill 诱发 Agent 失败的对比数据集？ 为了回答该问题，我们设计了一种受差分测试启发的对比构造方式，将每一次目标 skill 引导执行与「无 skill」或「语义匹配 skill」的参考运行配对，后者作为伪预言机。依据我们的对比标注标准，我们确认了 307 例 skill 诱发失败，其中包含 125 例功能失败和 182 例高置信度效率回退。详细描述见第 III 节 (https://arxiv.org/html/2608.11888v1#S3)。
2. 2.RQ2：skill 诱发的功能失败的根本原因是什么？ 为了回答该问题，我们对已确认的功能失败，人工分析了任务规格、skill 内容、执行轨迹、验证器输出与产物。研究揭示了若干值得注意的发现。例如，大多数功能失败并非由明显不相关的 skill 导致。相反，看似相关的 skill 往往使 Agent 错误实现或完全遗漏某个必需字段、API 行为、计算、输出格式或领域规则。在 125 例功能失败中，任务实现缺陷占 86 例（68.8%），而面向验证器的产物问题与环境边界问题分别占 24 例和 13 例。详细分析见第 IV 节 (https://arxiv.org/html/2608.11888v1#S4)。
3. 3.RQ3：skill 诱发的效率回退的根本原因是什么？ 为了回答该问题，我们分析了在加载 skill 后 token 消耗与执行时间双双增加的目标/参考配对样本，其中至少有一个指标超过主要的 T=2.0 阈值。研究表明，高置信度效率回退以过度流程为主，而非仅仅由 prompt 长度造成。在主要的 T=2.0 阈值下，过度流程占 182 例中的 114 例（62.6%），主要由过度验证（67 例）和沉重的实现流水线（30 例）驱动。详细分析见第 V 节 (https://arxiv.org/html/2608.11888v1#S5)。
4. 4.RQ4：如何自动将 skill 诱发的 Agent 失败归因到其根本原因？ 为了回答该问题，我们构建了 SkillTriage——一个基于分类法的归因工具，它能规范化成对样本、提取差分证据并生成分诊报告。针对功能失败与效率回退，它与人工标注的精确根因的匹配率分别为 111/125（88.8%）与 132/182（72.5%）。详细评测见第 VI 节 (https://arxiv.org/html/2608.11888v1#S6)。

综上，本文做出如下贡献：

1. 1. 我们指出了 LLM Agent skill 复用中一个关键且及时的问题：即使 skill 在主题上相关，也可能导致功能失败或严重的效率回退。我们从 SkillsBench 和 SWE-Skills-Bench 构造了一个包含 307 例已确认 skill 诱发失败的对比分析数据集，其中每个样本均由「无 skill」或「语义匹配 skill」的参考运行加以验证，并标注为功能失败或效率回退。
2. 2. 我们呈现了 LLM Agent 中 skill 诱发失败的首项系统性研究，对功能失败与效率回退进行了分类，并分析其根本原因。
3. 3. 我们开发了工具 SkillTriage，用于规范化成对样本、提取差分证据，并将 skill 诱发的 Agent 失败归因到根因。我们通过自动归因评测展示了 SkillTriage 的实际效用与有效性。

II　背景

LLM Agent 中的 Agent skills

Agent skill是一种结构化的程序性知识包，可在推理时增强 LLM Agent，而不修改模型参数 [8 (https://arxiv.org/html/2608.11888v1#bib.bib3)]。在当前的 Agent 系统中，一个 skill 通常围绕一个命名的 SKILL.md 文件组织。skill 框架会为某个任务挑选一个或多个 skill，并将其内容加载到 Agent 的上下文中。一旦加载，skill 就可能影响 Agent 的规划、代码仓库探索、工具使用、代码修改、测试以及停止决策。

Skill 内容

一个 skill 通常包含四类信息。第一，元数据，如 skill 名称、描述、frontmatter 或「何时使用」文本，用来指示该 skill 何时适用。第二，主体部分给出过程性指导，包括任务求解步骤、实现规则、工作流约束与检查清单。第三，补充文件可能提供示例、模板、schema、脚本、参考文档或其他按需加载的可复用资源。第四，验证指导可能建议测试、预期输出、调试步骤或完成标准。这些组成部分之所以重要，是因为它们会成为 Agent 有效任务上下文的一部分，而不再是被动的文档。

---
name: rag-backend-helper
description: Use for backend RAG applications.
---

# RAGBackendHelper

1. Inspect the repository structure and identify the app package.
2. Install or import vector-store and document-loader packages.
3. Add retrieval code under the app's retriever module.

4. Run the full test suite and fix all failures before stopping.

See examples/rag_template.py for a reference implementation.

图 1：一个简化的 SKILL.md 示例，展示典型的 skill 组成部分。

图 1 (https://arxiv.org/html/2608.11888v1#S2.F1) 说明了 skill 可以注入的信息类型。描述部分提供了适用性信号；仓库与模块相关的措辞会影响 Agent 在何处写入产物；依赖安装指示可能改变执行环境；验证检查清单则会增加流程开销。因此，skill 既可以通过提供可复用知识来发挥作用，也可能在其假设与具体任务不匹配时误导 Agent。

Agent 执行轨迹

执行轨迹是 Agent 在尝试完成任务时产生的、按顺序排列的模型交互、工具调用与中间动作序列。一条轨迹可能包含模型响应、工具调用、文件操作、搜索、代码修改、命令执行以及与环境的其他可观测交互。在本文中，根因分析均基于执行轨迹进行，而不仅仅依赖最终任务结果。

III　方法

III-A　研究设计

我们采用受差分测试启发的对比设计，将失败归因于所加载的 skill，而非基座模型的能力局限、任务难度或重复执行之间的常规差异。图 2 (https://arxiv.org/html/2608.11888v1#S3.F2) 展示了该设置：成对执行中保持任务、验证器、Agent 框架、模型、仓库或容器状态以及输入数据不变，仅改变 skill 设置，包括「无 skill」和各种候选 skill。每次运行产生两类可观测结果：一类是正确性结果，由任务验证器或测试衡量；另一类是成本结果，由 token 消耗与执行时间衡量。

我们将被审计的那次运行定义为目标运行（target run）。参考运行（reference run）是在不同 skill 设置下（要么无 skill，要么语义匹配的 skill）对同一任务的另一次执行。在本文中，PASS 与 FAIL 表示单次运行的确定性验证器结果。对于成对比较，FAIL/PASS 表示目标运行失败而参考运行通过，PASS/PASS 则表示两次运行均通过。我们在全文中使用两种审计设置。「有/无 skill」比较将使用被审计 skill 执行的目标运行与同一任务上不使用任何 skill 的参考运行进行对比。跨 skill 比较将目标运行与同一任务上另一个语义匹配的 skill 设置进行对比。对于功能失败，目标运行失败而参考运行通过；对于效率回退，两次运行均通过，但目标运行成本显著更高。参考运行扮演的是伪预言机的角色，而非真值解：它表明在同一任务与验证器条件下，该任务是可以被解决的、或者能以更低成本解决的。在任务、验证器、仓库、模型与 Agent 框架保持固定的前提下，只有 skill 设置发生变化；因此，当参考运行通过或更高效地完成任务时，它便提供了对比证据，可以在受控条件下把差异归因于所加载的 skill。

我们将失败分为两类：

• • 功能失败（Functional failure）：目标运行未通过验证器，而参考运行通过。
• • 效率回退（Efficiency regression）：目标运行与参考运行均通过