Agent Skills Can Be Harmful: An Empirical Study of Skill-Induced Failures in LLM Agents 精读

论文链接：arXiv:2608.11888 HTML 全文：arXiv HTML 发表时间：2026 年 8 月 12 日 机构：华为（Huawei）—— Gen Dong, Yanjie Gao, Liqun Li, Yu Hua, Fan Yang；伊利诺伊大学厄巴纳-香槟分校（UIUC）—— Tianyin Xu 领域标签：cs.AI（人工智能）；Agent 安全 / Skill 可靠性 / 经验软件工程

题目区

一句话总结：Skill 是把双刃剑——它不仅可能让任务直接失败（功能失败），也可能让任务"贵地通过"（效率回归）；而最危险的不是那些文不对题的 Skill，而是那些"看似对口"的 Skill，它们会诱导 Agent 把可选的检查表、构建配方当成必须执行的硬性流程。

一、论文背景

1.1 什么是 “Agent Skill”？

要理解这篇论文，先得弄清楚一个最基础的问题：Skill 是什么？

在 LLM Agent 的语境下，Skill 是一份"可复用的程序化操作手册"。最常见的形式就是一个 SKILL.md 文件，放在一个文件夹里，文件夹里还可以有示例脚本、模板、参考文档。Agent 平台（如 Claude Code、Claude Agent SDK、OpenCode）会在任务匹配到 Skill 的"适用描述"时把它加载进上下文，用来指导 Agent 的规划、工具使用、文件编辑、验证和停止决策。

这里有个非常形象的类比：Skill 就像一个新员工的《岗位操作手册》。

• 没有手册时，新员工靠通用能力（模型推理）临场发挥，有时行有时不行；
• 有了手册，他可以照章办事，处理复杂流程更稳定；
• 但如果手册写得不好——比如把过时的流程当成铁律、把可选步骤写成强制步骤——他可能反而把本来能做对的事做错，或者花三倍时间绕路。

Skill 的"渐进式披露"机制：Agent 默认只加载 Skill 的名字 + 描述（几行 frontmatter），只有当任务匹配描述时才把整个 SKILL.md 正文塞进上下文。这是为了节省上下文预算——否则几十份手册同时塞进去，每次模型调用都要为这些 token 买单。

1.2 Skill 已经被观察到有"副作用"

在本文之前，社区已经有两个公开的 Skill 基准观察到了令人不安的现象：

SkillsBench（84 个任务、11 个领域）发现：

• 策划过的 Skill 平均能带来通过率增益；
• 但 84 个任务中有 16 个任务，加上 Skill 后通过率反而下降。

SWE-Skills-Bench（490 个基于真实仓库的软件工程任务）发现：

• 49 个 Skill 中有 39 个带来零通过率增益；
• 平均增益只有 +1.2%；
• Token 开销最高飙升 451%；
• 3 个 Skill 实际降低了通过率（最多 -10%），原因是版本不匹配的指导与项目上下文冲突。

1.3 现有研究的四个空白

这篇论文要解决的，是前人留下的四个关键空白：

一句话：在本文之前，社区知道"Skill 有时有害"，但既不知道有害到什么程度、不知道有害的机制是什么、也没有工具自动识别。这就是本文要补上的缺口。

二、论文定位和关联工作

2.1 研究脉络的四条线索

本论文站在四条研究线索的交汇处：

线索一：Agent Skill 作为可复用知识单元

这条线把"程序化指导"打包成按需加载的 SKILL.md 文档。代表性工作包括 Anthropic 的 Skill 抽象、Claude Code 的 skill 加载机制，以及 Skill 库、工具导向微调等相关工作。本文把 Skill 当作"分析单元"，研究它的失败模式。

线索二：SkillsBench / SWE-Skills-Bench 等 Skill 基准

这两个基准是本文的直接上游。它们建立了"确定性验证器 + 可执行任务环境"的评估范式，并报告了 Skill 的平均增益与回归。本文不重新测量效用，而是在这些基准的基础上，构建对比数据集来归因失败。

线索三：上下文工程（Context Engineering）的经验发现

这是一条更深层的认知科学线索：额外的上下文不是单调有用的。代表性发现包括：

• Lost in the Middle（Liu et al., 2023）：模型对放在长上下文中间的信息召回率显著下降；
• 模型可能忽略中间上下文、被无关内容分散注意力、随输入变长而退化、对提示格式高度敏感。

本文的发现——“Skill 正文越长每次调用越贵”、“Skill 诱导的额外验证步骤才是效率回归主因”——与这条线索一脉相承，但进一步把"上下文成本"细分为静态上下文膨胀和动态轨迹膨胀两类。

线索四：经验软件工程（Empirical SE）的 Bug 分类法

本文的分类法（Task-Implementation Fault、Environment Mismatch、Artifact Misplacement 等）借鉴了性能 Bug、ML Bug、配置 Bug 的经验研究方法。它把"由 Skill 塑造的 Agent 轨迹"作为一个新的分析单元，套用经验 SE 的分类框架。

2.2 本文的定位与突破

定位结论：本论文是首个对 LLM Agent 中 Skill 诱导失败进行综合经验研究的工作。它不与 SkillsBench/SWE-Skills-Bench 竞争，而是建立在它们之上，回答它们无法回答的问题——“为什么”。

三、问题定义

3.1 从具体场景到抽象问题

具体场景：一个 Agent 加载了某个 Skill，跑某个任务失败了（或者虽然过了但 Token 爆炸）。我们怎么判断"这到底是 Skill 的锅"，还是"Agent 本来就不行"？

这里的核心难点是因果归因：单次失败运行包含了太多混杂变量。

作者的洞察：这个问题在结构上等价于差分测试（Differential Testing）——一种经典软件测试方法，用于测试"没有可执行预言机"的程序（如生物信息学工具、模型计数器）。差分测试的核心思路是：比较同一个输入在多个实现下的输出差异，用差异来暴露 Bug。

3.2 形式化的问题定义

给定：

• 一个任务 $t$，有确定性验证器 $V$（能判定 PASS/FAIL）
• 一个 Agent 框架 $A$，固定模型 $M$、仓库状态、容器状态
• 一组 Skill 设置 $\{S_0, S_1, S_2, \dots\}$，其中 $S_0$ = 无 Skill，其余为候选 Skill

定义两种运行：

• 目标运行（Target Run）：用被审计的 Skill $S_i$ 执行任务 $t$
• 参考运行（Reference Run）：用无 Skill $S_0$ 或语义匹配的另一个 Skill $S_j$ 执行同一任务 $t$

判定规则（只有在参考运行"本来能过"或"本来能更便宜地过"时，才把失败归因于 Skill）：

效率回归的数学定义：令 $r_{tok}$ = 目标/参考 Token 比率，$r_{time}$ = 目标/参考执行时间比率。当 $\min(r_{tok}, r_{time}) > 1.0 \land \max(r_{tok}, r_{time}) > T$（主阈值 $T=2.0$）时，标记为效率回归。

3.3 这个抽象的精妙之处

精妙点 1：用"伪预言机"绕过"没有预言机"难题。差分测试的本质就是"用参考实现当预言机"。本文用"无 Skill 运行"或"语义匹配 Skill 运行"作为伪预言机——如果同一个任务在参考设置下能过或能更便宜地过，那目标运行的失败就不能甩锅给"任务太难"或"Agent 本来就不行"。

精妙点 2：配对执行控制了所有混杂变量。任务、验证器、Agent 框架、模型、仓库状态全部固定，唯一变化的是 Skill 设置。这保证了观测到的差异只能归因于 Skill。

精妙点 3：效率回归只在 PASS/PASS 配对中定义。这避免了"任务失败本来就花 Token 少"这种伪回归。只有在两次都通过的前提下，比较 Token 才有意义。

四、问题解法

论文的解法分为两大组件：差分分析框架（构建对比数据集）和 SkillTriage 工具（自动归因）。

4.1 差分分析框架：构建对比数据集

这个框架的目标是回答 RQ1：如何构建一个可以用来做根因分析的 Skill 诱导失败数据集？

4.1.1 两种审计设置

Cross-Skill 设置是本文的一个关键创新——它不仅比较"有 vs 无"，还比较"有 A vs 有 B"，这样可以暴露出多个看似对口的 Skill 之间的差异。

4.1.2 用公开 Skill 扩充比较空间

原始基准只有少量策划 Skill。为了让比较更充分，作者：

• 从两个公开 Skill 共享站（smithery.ai、skillsmp.com）检索公开 Skill；
• 用 all-MiniLM-L6-v2 句子嵌入模型做语义相似性匹配；
• 对每个任务保留余弦相似度 ≥ 0.7 的前 5 个候选 Skill。

扩充效果：比较空间从 826 个潜在配对扩展到 20,664 个，约 25 倍扩展。这保证了 Cross-Skill 设置有足够的数据。

4.1.3 执行配置

• Agent 运行时：OpenCode 1.15.1
• 语言模型：Claude Opus 4.6
• 每次运行记录：加载的 Skill、轨迹、验证器结果、Token 使用、执行时间

4.1.4 标记与分析

执行 20,664 个配对比较后，得到 665 个标记候选。经过精炼（排除模糊案例、验证器狭窄案例），最终数据集包含 307 个确认的 Skill 诱导失败：

4.2 SkillTriage：分类法驱动的归因工具

这是论文的第二个核心贡献。核心洞察：手动构建的分类法不仅可以当标签用，还可以操作化为归因程序。

诊断原则：哪个分类标签最能同时解释（a）目标运行的结果（失败或额外成本）和（b）目标运行与参考运行轨迹之间的分歧？

SkillTriage 分三个阶段工作：

阶段 1：输入构建（规范化）

把每个配对案例规范化为"共享任务视图 + 两个运行视图"：

• 目标运行视图：加载的 Skill、结果、轨迹
• 参考运行视图：无 Skill 或匹配 Skill 设置、结果、轨迹
• 确定性证据门：检查案例是否有归因所需的最小轨迹/Skill/验证器证据

阶段 2：差分证据提取

对功能失败，计算 5 个差分信号（DS1–DS5）：

对效率回归，做阶段级和动作标签成本分析：

• 把步骤分为：实现前探索、实现/答案生成管道、实现后验证/调试
• 跟踪依赖/设置步骤（安装、导入、环境修复）
• 动作标签：exploration、pipeline、verification、dependency repair、reference loading

阶段 3：归因

向模型（GPT-5.5）提供：分类法定义 + 规范化输入 + 提取的差分证据。模型推理候选标签，选择最能解释目标结果和目标/参考轨迹分歧的根因。返回：类别、子类别、自然语言原因、引用的 Skill 部分/轨迹证据、修复建议。

聚合方式：运行 3 次，2-of-3 多数投票。

4.3 SkillTriage 的分类法

这是论文最核心的知识贡献——一套覆盖所有观察到的失败模式的分类体系。

功能失败分类（7 个子类别，125 案例）

效率回归分类（6 个子类别，182 案例）

4.4 四个真实失败案例（帮助理解分类法）

案例 1：Environment-State Mismatch (ESM)

• 任务：在仓库内创建 openpyxl/utils/report_engine.py
• 目标轨迹：Skill 引导安装新版 openpyxl，cd 到 /tmp，从 sys.path 移除工作区
• 参考运行：直接在仓库内修补 openpyxl/formatting/rules.py
• 失败原因：验证器从仓库包导入，但目标运行针对外部安装验证——Skill 改变了 Agent 看到的环境状态

案例 2：Incorrect Required-Element Fill (IRF)

• 任务：计算净出口占 GDP 的百分比
• 目标轨迹：(Exports - Imports) / GDP
• 参考运行：(Exports - Imports) / GDP * 100
• 失败原因：结果小了约 100 倍——Skill 的示例让 Agent 漏掉了百分比缩放

案例 3：Required-Element Omission (RRO)

• 任务：chunk size、overlap、top-k、模型参数都必须可配置
• 目标轨迹：CLI 参数有 –question、–chunk-size、–chunk-overlap、–top-k
• 参考运行：RAGConfig 包括 model_name = "gpt-3.5-turbo"
• 失败原因：Skill 的模板让 Agent 漏掉了必需的模型参数字段

案例 4：Artifact Misplacement (AM)

• 任务：在 libs/langchain/langchain/ 下创建文件
• 目标轨迹：写到 libs/langchain/langchain_classic/
• 参考运行：写到任务指定路径
• 失败原因：Skill 让 Agent 遵循了仓库的旧命名约定，而非任务指定路径

五、评估指标与实验证据

5.1 评估指标体系

本论文不是"刷榜型"论文，它的指标设计是为了证明因果归因主张，而非追求高分。核心指标有三类：

5.2 主结果 1：功能失败的根因分布（125 案例）

核心发现：Task-Implementation Fault (TIF) 占 68.8%（86/125），是绝对主导的失败类别。其中：

• Incorrect Required-Element Fill (IRF)：46 案例（36.8%）——Skill 让 Agent 用错误方法实现必需元素
• Required-Element Omission (RRO)：36 案例（28.8%）——Skill 让 Agent 漏掉必需元素

关键反直觉发现：只有 2 个案例（1.6%）是 Applicability Mismatch——即"Skill 用错了地方"。绝大多数失败来自看似对口的 Skill，它们没有用错地方，只是误导了实现方式。

这个发现的证明力在于：它颠覆了"不相关 Skill 才有害"的直觉。如果有害失败主要由不相关 Skill 引起，那解决方案就是"更好地选择 Skill"。但数据显示有害失败主要由相关 Skill 引起——这意味着问题不在选择层，而在内容层。Skill 的写法本身（示例、默认值、模板）就在诱导 Agent 犯错。

5.3 主结果 2：效率回归的根因分布（182 案例，T=2.0）

核心发现：Excessive Procedure (EP) 占 62.6%（114/182），远超 Context Bloat 的 25.3%。其中：

• Excessive Verification (EV)：67 案例（36.8%）——Skill 让 Agent 在实现后跑太多测试/调试/检查表
• Heavy Implementation Pipeline (HIP)：30 案例（16.5%）——Skill 诱导更重的构建管道

关键反直觉发现：Skill-Body Context Bloat 只占 23.6%（43 案例）。这说明效率回归不能仅靠"提示长度"解释——更主要的原因是 Skill 诱导了额外的行动步骤（验证、探索、重实现）。

这个发现的证明力在于：它颠覆了"Skill 越短越好"的优化方向。如果效率回归主要由上下文长度引起，那解决方案就是"缩短 Skill 正文"。但数据显示主因是Skill 诱导的额外行动——这意味着问题不在静态文本长度，而在动态轨迹膨胀。优化方向应该是"控制 Skill 诱导的行动数量和深度"，而非单纯缩短文本。

5.4 主结果 3：SkillTriage 归因准确率

功能失败归因：

效率回归归因：

为什么功能失败准确率 > 效率回归准确率？

功能失败有明确的"验证器判定"作为锚点，差分信号 DS1–DS5 可以围绕"为什么验证器失败"展开。而效率回归的归因更难——一条高成本轨迹可能同时包含过度探索、过度验证、依赖修复多个成本面，哪个是主因存在模糊性。残余错误分析显示，50/182 个效率回归的精确子类别错误，通常就是因为"多个合理成本面共存"。

这个准确率证明了什么？

它证明了分类法可以操作化为可靠的自动归因程序——功能失败子类别准确率 88.8%，意味着 SkillTriage 可以替代大部分人工归因工作，让 Skill 可靠性审计规模化。

5.5 实验设计如何证明核心主张

论文的四个研究问题与对应的实验证据：

六、效果优势的根源解释

本节解释为什么差分框架 + SkillTriage 能揭示出前人没发现的失败模式。

6.1 Baseline 方法的根本局限

在本文之前，Skill 评估的"baseline"是聚合指标法：跑一批任务，比较"有 Skill"和"无 Skill"的平均通过率、平均 Token 比。

这种方法有三个结构性局限，不是"没做某事"，而是"做了也无法逾越"：

局限 1：聚合掩盖了个体失败机制

平均通过率 +1.2% 这个数字，可能来自"30 个任务提升了 5%，10 个任务下降了 3%"——它告诉你"总体上 Skill 有用"，但不告诉你哪些任务的失败是 Skill 造成的。这就好比对一个既有涨也有跌的股票组合只看平均收益率——它完全掩盖了"哪只股票在亏钱"。

局限 2：单次运行无法区分失败来源

当一次带 Skill 的运行失败时，这个失败可能来自：Skill 损害、Agent 基础能力不足、验证器太狭窄、Agent 普通方差、环境工件。没有对照实验，就无法把"Skill 损害"从这五个混杂因素中隔离出来。这是因果归因的根本障碍——不是"多跑几次能解决"，而是"单次观察的信息量不足以做因果推断"。

局限 3：结果指标不解释轨迹变化

通过率和 Token 比是"结果级指标"。它们告诉你"任务失败了"和"花了更多 Token"，但不告诉你失败发生在轨迹的哪一步、Skill 怎么改变了行动序列。这就像医生只知道病人发烧，不知道哪里发炎——无法对症下药。

6.2 差分框架如何从根源上突破

差分框架不是"更好的指标"，而是认识论层面的范式转换——从"测量效用"转向"归因失败"。

机制因果链：

1. 配对执行控制了所有混杂变量（任务、验证器、Agent 框架、模型、仓库状态全固定，唯一变化是 Skill）→
2. FAIL/PASS 配对直接隔离了 Skill 的因果作用（参考运行能过，说明任务本身可解、Agent 能力够、验证器不狭窄，那目标运行的失败只能归因于 Skill）→
3. 这把"无法区分失败来源"的不可逾越障碍彻底消除了——因为现在有了对照，因果归因从"猜测"变成了"逻辑必然"。

反事实验证：如果没有配对执行（即没有参考运行），我们面对 665 个失败/回归候选，无法判断其中哪些真的是 Skill 造成的。配对执行把这个数字从"665 个可能"精炼为"307 个确认"——精炼掉的都是"本来就会失败"或"本来就会花这么多 Token"的案例。

6.3 SkillTriage 准确率的根源

为什么 SkillTriage 的功能失败子类别准确率能达到 88.8%？

机制因果链：

1. 分类法从 307 个真实案例归纳而来（不是理论臆造，每个类别都有具体案例支撑）→
2. 差分信号 DS1–DS5 精确对应分类法的判定维度（DS1 测环境状态、DS3 测路径、DS5 分离 IRF vs RRO）→
3. 5 个信号 + 规范化输入 + 分类法定义，给模型提供了足够的判定信息 →
4. 模型不再需要"猜测"，而是在明确的分类框架下做"匹配"——这把开放式归因问题变成了有约束的分类问题。

为什么效率回归准确率（72.5%）低于功能失败（88.8%）？

这不是 SkillTriage 的设计缺陷，而是问题本身的内在模糊性：一条高成本轨迹可能同时包含"过度探索 + 过度验证 + 依赖修复"——这三个成本面是叠加的，很难说哪个是"主因"。而功能失败有明确的验证器锚点（任务失败只有一个直接原因），归因更确定。这是问题结构决定的，不是工具局限。

七、必要知识反推

要完成这项研究，作者最少必须掌握哪些知识和信息？

7.1 领域知识层：LLM Agent 与 Skill 生态

必须知道：

• Skill 的加载机制：渐进式披露、上下文注入、Skill 正文在每次模型调用中持续存在——不理解这个，就无法理解 Context Bloat 和 Excessive Procedure 的区别。
• Agent 框架的执行模型：Agent 如何规划、调用工具、编辑文件、决定停止——不理解这个，就无法设计差分信号来分析轨迹分歧。
• 确定性验证器的作用：验证器如何判定 PASS/FAIL，验证器的"可见面"是什么——不理解这个，就无法定义"功能失败"和排除"验证器狭窄"案例。
• SkillsBench 和 SWE-Skills-Bench 的设计：它们的任务结构、验证器类型、已有发现——这是本文的直接上游，不理解它们就无法扩展比较空间。

为什么必须：没有这些领域知识，就无法识别"Skill 可能是失败来源"这个研究问题，也无法设计配对执行来隔离 Skill 的影响。

7.2 方法论知识层：差分测试与经验软件工程

必须知道：

• 差分测试（Differential Testing）：用参考实现当伪预言机，通过比较同一输入在多个实现下的输出来暴露 Bug。这是本文差分框架的直接灵感来源。
• 经验软件工程的 Bug 分类法：性能 Bug、ML Bug、配置 Bug 的分类方法——本文的分类法（TIF、EM、AM 等）直接借鉴了这套方法。
• 分类法操作化（Taxonomy Operationalization）：把手动分类标签转化为可执行的归因程序——这是 SkillTriage 的核心洞察。

为什么必须：没有差分测试的知识，作者面对"无法区分失败来源"的难题会束手无策；没有经验 SE 的分类法知识，面对 307 个案例会陷入"无结构的人工标注"。

7.3 工程知识层：大规模评估的基础设施

必须知道：

• Agent 运行时的配置与控制：如何固定模型、仓库状态、容器状态，只改变 Skill 设置——这是配对执行的工程前提。
• 语义相似性匹配：用 all-MiniLM-L6-v2 做句子嵌入，用余弦相似度 ≥ 0.7 筛选候选 Skill——这是扩充比较空间的技术。
• 成本测量：如何精确记录 Token 使用和执行时间，如何定义效率回归的阈值（T=2.0）——这是标记效率回归的基础。

为什么必须：没有大规模执行的基础设施，20,664 个配对比较无法完成；没有语义匹配，Cross-Skill 设置就没有数据。

7.4 知识融合的关键节点

这项研究的创造性不在单一知识点，而在三个融合节点：

融合节点 1：差分测试 × Agent 评估

把软件测试领域的差分测试方法，迁移到 LLM Agent 的 Skill 评估。这个迁移不是简单的类比——它需要理解差分测试的"伪预言机"思想，并把它具体化为"无 Skill 运行 / 语义匹配 Skill 运行"。这是方法论迁移的创造性节点。

融合节点 2：经验 SE 分类法 × Agent 轨迹分析

把经验软件工程的 Bug 分类方法，应用到"由 Skill 塑形的 Agent 轨迹"这个新的分析单元。这需要理解 Agent 轨迹的结构（探索、实现、验证阶段），并把它映射到分类维度。这是跨域分析的创造性节点。

融合节点 3：分类法 × 大模型归因

把手动分类法操作化为 SkillTriage 工具——用分类法定义约束大模型（GPT-5.5）的归因推理，用差分信号提供判定证据，用多数投票提升可靠性。这把"开放式归因"变成了"有约束的分类"。这是工具设计的创造性节点。

八、论文中可以提取的通用性灵感

灵感 1：差分归因范式——“有对照才能归因”

核心思想：当一个复杂系统的某次失败可能由多个因素导致时，单次观察无法做因果归因；必须构建"只改变一个变量的配对执行"，用参考运行当伪预言机，才能把失败归因到具体原因。

论文证据：本文用差分框架从 665 个失败候选中精炼出 307 个"确认的 Skill 诱导失败"——精炼掉的 358 个都是"没有对照时会被误归因"的案例。

推广场景：

1. Prompt 工程的 A/B 测试：评估某个 Prompt 修改是否真的提升了效果，还是只是运行方差。
2. RAG 系统的故障归因：检索失败 vs 生成失败 vs 上下文冲突，用配对执行隔离。
3. 多 Agent 系统的失败分析：某个 Agent 的失败是自身问题还是上游 Agent 传递的错误信息导致。
4. 推荐系统的效果衰减归因：某个策略上线后 CTR 下降，是策略问题还是数据分布漂移。
5. 任何"无法执行预言机"的复杂系统测试：生物信息学、科学计算、机器学习模型。

灵感 2：“看似相关"比"明显不相关"更危险

核心思想：在指导性知识（手册、教程、Skill、Prompt 模板）的复用中，看似相关的指导比明显不相关的指导更有害——因为明显不相关会被直接拒绝，而看似相关会诱导系统"按错误的示例/默认值/模板"执行，导致错误实现或必需元素遗漏。

论文证据：125 个功能失败中只有 2 个（1.6%）是"明显用错了地方”（APM），86 个（68.8%）是"看似对口但误导了实现"（TIF）。其中 IRF + RRO 占 82 个——都是"相关 Skill 诱导的错误实现"。

推广场景：

1. 代码示例的复用风险：Stack Overflow 上"看似相关"的代码片段可能让开发者用错误的 API 或漏掉边界条件。
2. RAG 系统的检索质量：检索到"看似相关"但实际误导的文档，比检索不到更危险——因为它会让模型"自信地犯错"。
3. 教程与技术文档的撰写：教程中的示例代码如果省略了边界处理，学习者会"照搬示例"而漏掉必需的健壮性元素。
4. 企业知识库的复用：过时但"看似相关"的内部 Wiki 文档，可能让员工用错误的流程处理新业务。
5. 教育领域的"错误先入为主"：看似合理的直觉解法比完全无知更难纠正。

灵感 3：动态轨迹膨胀 > 静态资源膨胀

核心思想：在 LLM 系统的成本优化中，不能只优化静态资源（提示长度、上下文大小），更要优化动态行为（诱导的行动数量、验证深度、探索范围）。因为动态膨胀往往是成本主因，且更隐蔽。

论文证据：182 个效率回归中，Excessive Procedure（动态行动膨胀）占 62.6%，Context Bloat（静态文本膨胀）仅占 25.3%。其中 Excessive Verification（67 案例）是最大单一来源——Skill 把可选的验证检查表变成了强制流程。

推广场景：

1. Agent 系统的成本控制：优化 Agent 的"思考轮数"比优化"Prompt 长度"更有效。
2. CI/CD 管道的效率优化：过度测试（每次提交跑全量回归）的成本可能远超测试代码本身的维护成本。
3. RAG 系统的延迟优化：减少检索-重排-过滤的链路步骤，比压缩文档内容更能降低延迟。
4. 工作流自动化的设计：把"可选步骤"标记为可选，防止它们变成强制流程。
5. 任何"检查表驱动"的流程：检查表的初衷是保障质量，但过度执行会变成效率杀手。

灵感 4：分类法可以"操作化"为自动归因程序

核心思想：一套好的分类法不仅是标签集合，还可以转化为可执行的归因程序——通过为每个类别定义判定维度（差分信号），让大模型在约束框架下做归因，把"开放式分析"变成"有约束的分类"。

论文证据：SkillTriage 用 5 个差分信号（DS1–DS5）+ 分类法定义约束 GPT-5.5，功能失败子类别准确率达 88.8%——证明了分类法可以操作化为可靠的自动归因工具。

推广场景：

1. 客服工单的自动分类：把人工分类法操作化为差分信号 + LLM 归因。
2. Bug 报告的自动分诊：用经验 SE 的 Bug 分类法驱动自动归因工具。
3. 医疗诊断的辅助系统：用疾病分类法 + 患者差分指标辅助诊断。
4. 代码审查的自动化：用代码 smell 分类法 + 代码差分信号驱动自动审查。
5. 任何需要"专家判断规模化"的场景：把专家的分类法操作化为工具。

灵感 5：Skill 加载应被视为"成本化和经验证的配置决策"

核心思想：任何"可复用指导"的加载都不应是免费的——它应该被当作有成本的配置变更，需要经过兼容性检查、成本预测、配对正确性/成本评估。

论文证据：论文结论明确提出"Skill 加载应被视为成本化和经验证的配置决策，由兼容性检查、成本预测和配对正确性/成本评估支持"。

推广场景：

1. Feature Flag 的发布：功能开关的上线应视为配置变更，需要灰度 + 监控。
2. 依赖库的升级：引入新依赖应经过兼容性检查和性能基准。
3. Prompt 模板的部署：Prompt 变更应 A/B 测试，而非直接替换。
4. 企业政策的执行：新政策的下发应有"成本评估"和"兼容性检查"。
5. 任何"指导性知识"的分发：手册、SOP、最佳实践的推广应有反馈机制和效果评估。

附录：关键数据汇总

最后一句：这篇论文最值得记住的，不是那 307 个数字，而是它传达的一个清醒判断——在 Agent 时代，“复用知识"不再是免费的午餐；每一次 Skill 的加载，都是一次有成本的配置决策，需要被认真地对待、被严格地验证、被成本地评估。