如果Skill的失败大多不是“不会做”而是“描述没写对、边界没写清、失败路径没定义”，一个团队做Skill的第一优先级到底该是写更多Skill，还是先建一套触发、评测和回归的流程？

机制分析 · 工程路径 · 数据证据 · 前沿预判

一、导语：一个被误诊的失败率

很多团队在复盘Skill失败时，会习惯性归因于模型能力不足：任务太难、上下文太短、推理不够深。但只要把失败样本按阶段拆开，结论往往相反。一个Skill从被创建到被正确执行，至少经过四个环节：被检索到（retrieval）、被判定适用（trigger）、被正确参数化（argument binding）、被执行并在异常时收敛（execution & recovery）。真正“模型不会做”的失败集中在最后一环，而前三环的失败几乎全部由描述质量决定。

这个判断有直接的工程含义：如果失败主要发生在“被找到”和“被正确触发”上，那么继续增加Skill数量只会稀释检索空间、加剧描述冲突，使边际收益递减甚至为负。反之，先建立触发评测与回归机制，能让每一个新增Skill都携带可验证的适用边界，把“写更多”从赌博变成投资。本文的主线即由此展开：Skill的规模扩张必须以可评测的触发与回归为前提，否则数量增长是负资产。

笔者认为，把Skill失败笼统归为“能力问题”，本质上是一种观测偏差：能力失败容易在日志里显形，而触发失败往往表现为“模型没用这个Skill”，不留痕迹，于是被系统性忽略。

二、背景与问题定义：Skill是什么，失败发生在哪一层

2.1 Skill的准确定义与工程形态

在本文语境中，Skill指一段结构化的能力说明，通常包含名称、适用场景描述、输入输出契约、依赖工具、示例与失败处理约定，由Agent在运行时按需检索并加载到上下文。它与传统函数调用的关键差异在于：函数调用的匹配由类型系统与编译器保证，而Skill的匹配由自然语言语义与模型判断完成，因此描述本身就是接口。这一形态在Anthropic的Agent Skills工程实践中被明确为“渐进式披露”（progressive disclosure）：元数据常驻上下文，正文按需加载（Anthropic, 2025）。

本文评述：渐进式披露解决了上下文预算问题，却把匹配压力前移到元数据描述上。元数据越短，歧义越大；越长，检索成本越高。这构成一个需要评测来校准的权衡，而不是靠拍脑袋写描述能解决的。

2.2 失败的四层分解

把失败拆成四层有助于定位责任。检索失败指Skill未被召回；触发失败指被召回但模型判断不适用或误用于不该用的场景；参数化失败指输入槽位缺失或类型错配；执行失败指工具报错、超时或结果不满足约束。公开的工具调用评测普遍显示，参数与触发类错误占比显著（Patil et al., 2023; Qin et al., 2024）。

这张表的价值在于把“失败率”这个笼统指标拆成可归因的四项。工程上，只要前三项合计占比超过一半，优先建流程的结论就成立；反之若执行失败占绝对多数，则应先补工具与运行时能力。判断依据应来自自有日志，而非外部直觉。

2.3 为什么“写更多”在早期看起来有效

早期Skill数量少，检索空间稀疏，新增一个Skill往往能立刻覆盖一个此前无法完成的任务，形成强烈的正反馈。这种局部收益容易被误读为线性规律。但随着数量上升，语义近邻增多，描述之间的重叠与冲突开始主导失败模式。信息检索领域的经典结论是：召回集合扩大后，排序与判别的重要性上升，单纯扩充语料并不能持续提升端到端效果（Robertson & Zaragoza, 2009）。本文评述：Skill库本质是一个面向模型的语义索引，其规模效应同样服从这一规律。

三、原理与技术路线：触发、边界、失败路径的三段式机制

3.1 触发机制：从关键词匹配到语义判别

触发可形式化为一个判别问题：给定用户请求q与Skill集合S，模型需判断是否存在s∈S使得q落在s的适用域内。工程上常见三种实现：纯描述匹配（把描述拼进提示由模型判断）、检索增强匹配（先用向量或BM25召回候选，再判别）、以及带负例的判别（在描述中显式列出不适用场景）。第三种在实践中误触发率最低，因为它把“边界”写进了接口本身。

本文评述：负例描述的成本被长期低估。写“适用于X”只需一句，写“不适用于Y、Z，遇到Y应改用Skill W”需要三句，但后者直接降低了最昂贵的误触发。这与分类器训练中负样本的价值同构：只给正例的判别器必然过拟合。

3.2 边界定义：输入输出契约与前置条件

边界包含三类：输入边界（必填槽位、类型、取值范围）、前置条件（需要哪些上下文或权限）、输出边界（返回结构、精度、时效）。工具调用研究反复指出，结构化schema能显著降低参数错误（Patil et al., 2023）。但Skill的描述层往往只有自然语言，因此需要在描述中嵌入可校验的契约片段。

name: refund_order
when_to_use: 用户明确要求对已支付订单退款，且订单状态为 paid 或 shipped
when_not_to_use: 订单未支付、已退款、或用户仅咨询退款政策（改用 refund_policy_qa）
inputs:
  order_id: string, required, 形如 ORD-数字
  reason: enum[quality, logistics, other], required
preconditions: 需要已登录用户且订单归属该用户
outputs: {status: enum[accepted, rejected], refund_id?: string}
on_failure:
  - 订单不存在 -> 返回 not_found，不重试
  - 权限不足 -> 返回 forbidden，提示联系客服
  - 下游超时 -> 最多重试1次，仍失败则转人工工单

这段YAML并非某个真实系统的完整定义，而是笔者基于常见工程实践整理的示意结构。它的关键不在格式，而在于把“不适用场景”和“失败分支”写成机器可读的字段，使评测可以逐项断言。

3.3 失败路径：把异常当作一等公民

失败路径缺失是执行层最隐蔽的问题。模型在工具报错后倾向于重试或编造结果，而非按约定降级。ReAct类框架的原始设计就强调观察—行动的循环，但并未规定异常收敛策略（Yao et al., 2023）。本文评述：失败路径应当被视为Skill契约的一部分，与成功路径同等重要；没有失败路径的Skill，在评测中应直接判定为不合格。

一个可操作的判定标准是：对每个Skill，至少写出三类失败分支（输入非法、依赖不可用、结果不满足约束），并为每类指定唯一动作（重试、降级、转人工、终止）。三类分支覆盖不全的Skill不进入生产库。这条规则简单，却能过滤掉大量“看起来能用”的Skill。

3.4 三者的耦合关系

触发、边界、失败路径并非独立模块，而是同一份描述的三个切面。触发依赖边界来排除误用，边界依赖失败路径来定义异常语义，失败路径又反过来约束触发条件（例如依赖不可用时应触发降级Skill而非原Skill）。因此评测不能只测“能否完成”，必须同时测“是否该用”“边界是否守住”“异常是否收敛”。这三项构成回归测试的最小断言集。

四、关键数据与案例：从公开研究到工程观测

4.1 公开评测揭示的错误结构

伯克利函数调用评测（BFCL）将错误分为简单调用、多函数、并行、相关性判断等类别，其中“相关性判断”（relevance detection）专门考察模型是否知道“不该调用”，这一项长期是薄弱环节（Patil et al., 2023；后续版本持续更新）。ToolBench与ToolLLM则显示，即便给定正确工具集，参数与多步规划错误仍占相当比例（Qin et al., 2024）。

本文评述：这些评测的共同启示是，工具调用的瓶颈不在“会不会写代码”，而在“判断该不该用、参数对不对”。这与本文主线一致：描述与边界是主要矛盾，能力是次要矛盾。需要说明的是，不同评测的绝对数值不可直接横向比较，因为工具集规模与评分口径不同；本文只引用其错误结构的方向性结论。

4.2 工程观测：一个模拟的失败分布

为便于讨论，笔者构造一组模拟数据（非真实实验，仅用于说明分析方法）：假设某团队有120个Skill，月度失败样本1000条，按四层归因得到下表。该表用于演示如何从日志推导优先级，读者应以自有数据替换。

模拟数据中前三层合计72%，意味着绝大多数失败可通过修改描述与流程解决，而非提升模型能力。这一结构在笔者的观察中具有代表性，但不同团队差异很大，必须以自有日志为准。需要强调：上表为模拟数据，不构成任何效果承诺。

4.3 案例：一次误触发引发的连锁失败

设想一个“发送周报”Skill与一个“发送通知”Skill，描述都含“发送”与“消息”。用户说“把本周数据发给团队”，模型误选通知Skill，参数化时把结构化数据塞进纯文本字段，下游渲染失败，模型重试三次后编造“已发送”。这条链上，误触发是起点，参数化失败是放大器，失败路径缺失是终点。修复方式不是换更强模型，而是给周报Skill写明“涉及报表、数据附件时使用”，给通知Skill写明“纯文本短消息”，并在失败路径中规定“渲染失败即终止并回报”。

本文评述：这个案例说明失败具有链式结构，单点优化往往无效。评测必须覆盖整条链，回归必须锁定链上的每个断言，否则修好一处会在另一处复发。

4.4 拓展资源

关于工具调用评测与Agent工程实践，可参考以下公开资源（均在新窗口打开）：Berkeley Function Calling Leaderboard、Anthropic: Building effective agents、ToolLLM 论文。这些资源提供了评测口径与工程模式的基线，建议结合自有场景做适配而非照搬。

五、对比与局限：写更多Skill与先建流程的边界条件

5.1 两种策略的收益曲线

“写更多”的收益曲线在早期陡峭、后期平坦甚至下弯，原因是检索空间膨胀与描述冲突。“先建流程”的收益曲线前期平缓（投入在评测集与门禁上），后期随Skill数量增长而放大，因为它把每次新增的边际失败率压住。两条曲线的交点取决于团队规模与Skill增速：小团队、低增速时先写更多也合理；一旦月增Skill超过十余个，流程缺失的代价会迅速显现。

5.2 流程的局限与反模式

流程并非万能。常见反模式有三：其一，评测集只覆盖成功路径，导致回归通过但线上仍失败；其二，评测集由写Skill的人自建，存在确认偏差；其三，门禁过严使迭代停滞，团队绕过流程。本文评述：流程的价值在于降低不确定性，而非制造审批。评测集应由使用方与开发方共同维护，并定期用线上失败样本回灌，否则会迅速失真。

另一个边界是模型能力跃迁。当底层模型显著变强时，部分触发失败会被自动修复，流程的边际价值下降。但这不构成放弃流程的理由，因为能力提升同时会扩大Skill的适用范围，边界问题反而更突出。可验证的判断方式是定期重跑评测集，观察失败结构是否从触发层迁移到执行层。

5.3 与相关方法的对比

与提示工程相比，Skill流程更强调可回归的资产化；与RAG相比，Skill的检索对象是能力而非知识，判别标准是“该不该用”而非“相关性”；与传统微服务治理相比，Skill缺少编译期检查，因此更依赖运行时评测来补偿。本文评述：把Skill当作“带自然语言接口的微服务”来治理，是当前最贴近工程现实的类比，但必须补上语义判别这一层，否则会低估触发问题的权重。

六、可操作路径：一套最小可行的触发—评测—回归流程

6.1 第一步：建立Skill清单与描述规范

先做盘点，不做新增。为每个存量Skill补齐六个字段：名称、适用场景、不适用场景、输入契约、输出契约、失败分支。字段缺失的标记为“待修”，暂停对外暴露。这一步通常能暴露大量隐性冲突，例如两个Skill的适用场景描述高度重叠。

1. 统一命名：动词+对象，避免同义词混用。
2. 适用场景写“用户意图”而非“内部实现”。
3. 不适用场景至少写两条，并指明替代Skill。
4. 输入契约标注必填、类型、示例值。
5. 失败分支按输入非法、依赖不可用、结果越界三类各写一条。

6.2 第二步：构建触发评测集

触发评测集由三类样本构成：正例（应触发）、负例（不应触发但语义相近）、边界例（模糊、需澄清）。每个Skill至少配10条正例、10条负例、5条边界例。负例应来自真实误触发日志，而非凭空编写。评测指标用漏触发率与误触发率，二者需同时报告，只报其一会导致策略偏移。

# 触发评测样本示例（模拟）
- query: "帮我把上周的销售数据整理成周报发出去"
  expect_skill: weekly_report
  type: positive
- query: "给群里发个通知说明天停电"
  expect_skill: send_notice
  type: positive
- query: "把这份报表发给财务"
  expect_skill: weekly_report
  type: boundary   # 含“报表”与“发送”，易误判
- query: "退款政策是什么"
  expect_skill: refund_policy_qa
  type: negative_for: refund_order

本文评述：边界例是最有价值也最容易被省略的一类。它直接对应描述中的模糊地带，修一条边界例往往能同时降低多类误触发。

6.3 第三步：建立回归门禁

任何Skill描述变更都触发回归：跑触发评测集、跑参数校验用例、跑失败路径用例。三项全过才允许合并。门禁应自动化，并保留历史基线，出现指标回退即阻断。回归集随线上失败样本持续扩充，建议每月回灌一次。

阈值为示例，团队应按业务风险设定。高风险场景（资金、权限）应更严，低风险场景可放宽以保迭代速度。

6.4 第四步：建立治理指标与复盘机制

治理指标建议包含：Skill总数、描述完整率、评测覆盖率、回归通过率、线上失败四层分布、平均修复时长。每月复盘一次，重点看失败结构是否迁移。若触发失败占比下降而执行失败上升，说明描述治理见效，应转向运行时健壮性。

本文评述：指标的作用是引导注意力，而非考核。把“Skill数量”作为KPI会直接诱发本文批评的行为；把“评测覆盖率”与“误触发率”作为KPI，才能让团队把精力放到描述质量上。

6.5 第五步：再谈规模化

当上述流程稳定运行、回归通过率与误触发率进入可控区间后，再扩写Skill。此时新增一个Skill的成本包含描述、评测样本与失败分支，看似更慢，但返工率显著下降。工程上可用模板与脚手架降低这部分成本，例如自动生成评测样本骨架、自动校验字段完整性。

关于Agent工程与评测的更多实践，可参考 Anthropic 工程博客 与 Gorilla 开源项目，前者给出模式选择，后者给出评测实现，二者结合可作为流程落地的起点。

七、结论与展望

回到最初的问题：第一优先级是写更多Skill，还是先建触发、评测与回归的流程？基于失败结构的分解与公开研究的方向性结论，本文的判断是：在团队进入规模化阶段后，流程优先。描述、边界与失败路径是Skill的主要失效面，而这三者恰好只能通过评测与回归来约束。写更多Skill在探索期有效，但在增长期会放大冲突与不可归因性。

展望未来，三个方向值得关注：其一，Skill描述的自动化校验，用静态分析检查字段完整性与冲突；其二，触发评测的合成数据生成，降低样本构建成本，但需警惕分布偏移；其三，运行时自适应降级，把失败路径从静态约定推进到动态策略。本文评述：无论技术如何演进，“可评测”都应是Skill资产化的底线，否则数量增长只是把不确定性推迟到线上。