Skill触发靠description和请求做语义匹配，描述里不写触发短语和反例，模型要么不调用、要么在不相关场景乱触发？

工具调用 · 语义路由 · 描述工程 · 评测方法

目录

一、导语：一次“没被调用”的故障复盘

一个内部知识库检索Skill上线两周，调用率异常偏低。日志显示，用户明确问“帮我查一下上季度报销政策的变更点”，模型却直接凭记忆作答，没有触发检索。排查后发现，该Skill的描述只有一句：“用于查询公司内部文档。”这句话在语义上过于宽泛，既没有覆盖“报销政策”“变更点”这类具体意图词，也没有说明“当问题涉及内部制度、需要引用原文时必须调用”。模型在“能凭常识回答”与“需要外部证据”之间，选择了前者。

把描述改成包含触发短语与强制条件的版本后，漏触发显著下降；但紧接着又出现了新问题：用户问“报销流程一般要几天”，模型也去调用检索，而这类问题本可由通用常识回答，属于典型的误触发。一次修改，把失效从一端推到了另一端。这个案例说明，Skill触发不是“写不写描述”的问题，而是描述文本是否构成一份足够精确的路由契约的问题。

笔者认为，把Skill描述当作“功能说明”来写，是当前工程实践中最普遍的认知偏差。功能说明面向人类读者，允许模糊与省略；而路由契约面向的是模型的语义匹配过程，必须显式覆盖“何时用、何时不用、用什么词、缺什么条件就不该用”。这两种写作目标的差异，正是漏触发与误触发的共同根源。

二、背景与问题定义：Skill触发的语义路由本质

2.1 从函数调用到Skill：同一套决策骨架

工具调用机制的基本流程是：系统把可用工具的名称、描述与参数模式（JSON Schema）注入上下文，模型在生成过程中决定是否输出一个结构化调用请求，运行时再执行并把结果回填。OpenAI在2023年6月发布的函数调用能力说明中，明确了“模型根据描述判断何时调用”这一设计取向（OpenAI, 2023）。此后，Anthropic于2024年11月发布的Model Context Protocol（MCP）把工具、资源与提示模板抽象为可插拔的服务端能力（Anthropic, 2024），Skill这一说法在工程语境中逐渐泛化为“可被模型按需加载的能力单元”。

本文评述：无论叫函数、工具还是Skill，决策骨架是一致的——描述文本是唯一的语义入口。参数模式约束“怎么调”，描述文本决定“调不调”。很多团队在参数校验上投入大量精力，却在描述上只写一句话，这相当于给一个高精度接口配了一个低精度路由器。

2.2 问题定义：把触发问题形式化

设用户请求为 q，Skill集合为 S = {s₁, s₂, …, sₙ}，每个Skill有描述 dᵢ。模型的触发决策可近似视为一个映射：

trigger(q, S) = argmax_i  sim( φ(q), φ(dᵢ) )   subject to  sim > θ

其中 φ(·) 表示模型内部的语义表示，θ 为隐式阈值。这个形式化是简化的：真实决策还受指令遵循、上下文位置、参数可满足性等因素影响。但它足以解释两类失效——当 dᵢ 与 q 的语义重叠不足时漏触发；当 dᵢ 与多个不同意图都高度重叠时误触发。

需要强调的是，θ 不是可调参数，而是模型行为涌现的结果。工程上能施加影响的杠杆，几乎全部落在 dᵢ 的写法上。这正是“描述工程”值得被当作独立课题的原因。

2.3 为什么“语义匹配”比“关键词匹配”更难控

关键词匹配的失败是可见的：词没出现就不匹配，规则可枚举。语义匹配的失败是隐性的：模型会做同义扩展、意图归纳与上下文推断，一个宽泛描述可能覆盖远超预期的请求集合。检索增强生成（RAG）领域对“查询-文档语义鸿沟”的讨论（Gao et al., 2023）在此同样适用——描述是被检索的“文档”，用户请求是“查询”，而模型是那个既做检索又做判断的复合体。

笔者认为，工程团队常低估的一点是：语义匹配的召回与精确是同一段文本的两个侧面，无法通过“写得更详细”单向优化。写得更详细会提升召回，但也可能扩大语义覆盖导致精确下降。描述工程的核心不是“写多”，而是“写准边界”。

三、原理与技术路线：描述文本如何参与决策

3.1 描述在上下文中的三种角色

描述文本并非只在一个环节起作用。综合现有工具调用实现与相关研究，它在三个层面参与决策：

本文评述：多数讨论只关注第二层，忽略了第一层。候选生成阶段一旦漏掉，后续再精确的判断也无从发生。因此描述中必须包含足够具体的意图词与实体词，让Skill在语义索引阶段就能被“检索到”。

3.2 指令遵循与“强制调用”条件

现代指令微调模型对“必须”“当……时”这类条件句有较强的遵循能力。这意味着描述中可以直接写入强制规则，例如“当用户问题涉及内部制度原文、且答案无法从通用常识确定时，必须调用本Skill”。这类规则在效果上接近一个软性的策略约束。

但笔者要提醒一个边界：强制规则的强度依赖于模型对指令的遵循程度，不同模型、不同上下文长度下表现并不一致。把关键路由逻辑完全寄托于一句“必须调用”，在工程上是不稳健的。更可靠的做法是在运行时增加一层可编程的前置路由或后置校验，把描述作为第一道语义过滤，而非唯一防线。

3.3 语义匹配的可观测近似

虽然无法直接读取模型内部的 φ(·)，但可以用外部嵌入模型对“描述-请求”对做相似度打分，作为触发倾向的近似观测。实践中可用开源嵌入模型（如BGE系列、E5系列）构建离线打分器，用于批量筛查描述覆盖度。需要注意，外部嵌入与模型内部表示并不等价，这类打分只适合做相对排序与覆盖度诊断，不能直接当作触发概率。

相关教程可参考：OpenAI Function Calling 官方指南、Model Context Protocol 文档、BGE 中文嵌入模型页。

四、失效模式解剖：漏触发与误触发的成因图谱

4.1 漏触发的四类成因

第一类是词汇覆盖不足：描述使用抽象词（“查询文档”），用户使用具体词（“报销政策变更点”），语义重叠被稀释。第二类是缺少强制条件：模型倾向于用自身知识作答，若描述未声明“必须调用”，它不会主动检索。第三类是描述位置与长度劣势：在长上下文中，靠后的Skill描述更容易被忽略，这是“迷失在中间”现象（Liu et al., 2023）在工具场景的延伸。第四类是参数不可满足的隐性劝退：若描述暗示需要用户提供复杂参数，模型可能判断“条件不满足”而放弃调用。

4.2 误触发的三类成因

第一类是描述过宽：一句“用于处理文本”几乎覆盖所有请求。第二类是缺少反例：描述未说明“不适用于什么”，模型无法排除相近但不相关的意图。第三类是多Skill语义重叠：两个Skill描述高度相似，模型在二者间随机选择，表现为“在不相关场景调用了错误的那个”。

关键洞察：漏触发与误触发并非两个独立问题，而是同一段描述在“语义覆盖度”这一维度上的两端。描述覆盖不足则漏，覆盖过泛则误。优化必须同时约束两端，单侧优化只会把故障推向另一端。

4.3 一个成因对照表

五、描述工程：可复用的结构与模板

5.1 六段式描述结构

综合工程实践与相关规范（如OpenAI对工具描述的建议、MCP对工具元数据的约定），笔者提出一个六段式结构，每段服务于一个明确的决策环节：

1. 能力声明：一句话说明做什么，用动词开头，避免“用于”这类弱动词。
2. 触发短语：列出5–15个用户可能使用的具体表达，覆盖同义词与口语变体。
3. 强制条件：明确“当……时必须调用”的判据，如“涉及内部制度原文”“需要引用可核验来源”。
4. 反例边界：明确“不适用于……”的场景，至少3条，覆盖最易混淆的邻近意图。
5. 参数语义：每个参数说明含义、格式、取值范围与默认行为。
6. 失败与降级：调用失败时的行为约定，如“返回空结果时提示用户补充关键词”。

本文评述：六段式并非越长越好。经验上，描述总长控制在200–400字（中文）较为均衡，超过后边际收益递减，且会挤占上下文预算。触发短语与反例是信息密度最高的两段，应优先保证。

5.2 一个可落地的描述模板

name: internal_doc_search
description: |
  检索公司内部制度、流程与政策文档，返回原文片段与出处。
  触发短语：查制度、查政策、报销规定、流程原文、制度变更点、
  内部文档、政策依据、条款出处。
  强制条件：当问题涉及内部制度原文、需要可核验出处、
  或用户明确要求“查一下公司规定”时，必须调用本Skill，
  不得凭记忆作答。
  不适用：通用常识问题、行业通用知识、与公司制度无关的
  技术问题、纯计算或格式转换任务。
  参数：
    query (string, 必填)：检索关键词，建议包含制度名称与
      变更维度，如“报销政策 变更点”。
    top_k (integer, 可选, 默认5)：返回片段数量，范围1–20。
  失败降级：无结果时返回空列表并提示用户补充关键词，
  不得编造出处。

这个模板的价值不在于文字本身，而在于它把“路由契约”的每个要素都显式化了。工程上可以把它做成配置项，由产品与算法共同维护，而不是散落在代码注释里。

5.3 触发短语的采集方法

触发短语不应拍脑袋写。可行路径有三条：其一，从真实日志中抽取“本应触发但未触发”的请求，人工归纳其表达模式；其二，对Skill的功能做同义词扩展，覆盖口语、缩写与行业黑话；其三，用嵌入模型对候选短语做聚类，保证覆盖不同表达簇而非同义堆砌。

笔者认为，第三条最容易被忽视却最有价值。很多描述写了十个触发短语，实际全在同一语义簇内，覆盖度并未提升。聚类后按簇取样，才能用有限字数覆盖更广的请求空间。

5.4 反例的写法：具体到意图，而非泛泛而谈

“不适用于无关问题”这类反例几乎无效，因为“无关”本身需要判断。有效的反例应指向具体的邻近意图。例如检索Skill的反例应写成“不适用于通用常识问答（如‘什么是复利’）”“不适用于纯格式转换（如‘把这段转成表格’）”。反例越具体，模型越容易在边界处做出排除判断。

可参考的工程讨论：Anthropic 关于构建有效Agent的工程文章、LangChain 工具调用教程。

六、评测方法与关键数据：把“感觉”变成指标

6.1 评测集构建

触发评测需要三类样本：正样本（应触发，含多种表达变体）、负样本（不应触发，含邻近意图）、边界样本（可触发可不触发，用于观察稳定性）。每类建议不少于100条，正样本按表达簇分层抽样，负样本按邻近意图分层。

涉及数据集时需说明预处理：以公开工具调用评测集为例，需先剔除描述缺失或参数模式不完整的条目，再按Skill去重，最后人工标注触发标签并做双人一致性校验（Cohen's κ 建议不低于0.8）。若使用自建日志数据，需脱敏并去除含个人信息的请求。

6.2 核心指标

6.3 模拟数据示例与解读

以下为一组模拟数据（非真实实验，仅用于说明指标关系）：某检索Skill在描述优化前后，正样本召回从62%升至89%，负样本误触发率从8%升至21%；加入反例段后，误触发率回落至9%，召回保持在86%。这组模拟数据揭示了一个常见规律——补触发短语提升召回但抬高误触发，补反例压低误触发但可能轻微损失召回，二者需要在同一轮迭代中协同调整。

本文评述：工程上不应追求单一指标的极值，而应设定业务可接受的双阈值，例如“召回≥85%且误触发≤10%”，在此约束下寻找描述的最优写法。这与检索系统的P-R权衡是同一逻辑。

6.4 评测执行要点

评测应在固定温度（建议0或接近0）、固定系统提示、固定Skill集合的条件下进行，避免变量污染。每个样本建议重复3次，统计触发稳定性。对于边界样本，稳定性比单次结果更有信息量——一个在3次中触发2次的样本，说明描述在该边界上存在歧义。

七、多Skill冲突与上下文预算

7.1 语义重叠的量化与消解

当Skill数量增长，描述之间的语义重叠不可避免。可用嵌入模型计算描述两两相似度，构建相似度矩阵，对超过阈值（如0.85）的Skill对做人工审查。消解手段包括：差异化能力声明、明确各自的适用域、在反例中互相排除。

笔者认为，多Skill冲突的本质是产品边界不清，而非描述技巧不足。两个功能高度重叠的Skill，无论描述怎么写都会互相干扰。此时正确的动作是合并或重新划分职责，描述工程只能缓解、不能根治。

7.2 上下文预算与描述长度

每个Skill的描述都占用上下文预算。当Skill数量达到数十个，描述总长可能挤占用户输入与推理空间，且加剧“迷失在中间”。可行策略包括：按场景分组加载Skill、对描述做分层（短描述用于候选生成，长描述按需展开）、以及用检索式路由先筛候选再注入完整描述。

相关实践可参考：MCP 发布说明、Lost in the Middle 论文页。

八、工程落地路径：从描述到上线闭环

8.1 五步落地流程

1. 职责定义：明确Skill的输入、输出与不做什么，先定边界再写描述。
2. 描述初稿：按六段式结构撰写，触发短语与反例各不少于5条。
3. 离线评测：用分层评测集跑召回、误触发、选错率，记录基线。
4. 灰度上线：小流量观察真实日志中的漏触发与误触发，按周迭代描述。
5. 回归与版本化：描述变更纳入版本管理，每次变更跑回归集，防止“修一处坏一处”。

8.2 运行时兜底

描述是第一道过滤，不是唯一防线。建议在运行时增加两类兜底：其一，前置规则路由，对高确定性的意图直接指定Skill，绕过语义匹配；其二，后置结果校验，对调用结果做置信度检查，低置信时回退到澄清提问而非强行作答。

本文评述：把描述工程与运行时兜底结合，才是稳健方案。纯靠描述优化，等于把系统稳定性押在模型行为的概率分布上；纯靠规则路由，则失去语义泛化能力。二者互补，边界清晰。

8.3 一个最小可用的检查清单

九、对比与局限：描述工程能解决什么、不能解决什么

9.1 与其他路由方案的对比

本文评述：描述工程不是银弹，它的最佳位置是“第一道语义过滤 + 低成本迭代层”。对高确定性、高风险的场景，应叠加规则或专用路由器；对长尾、快速演进的场景，描述工程性价比最高。

9.2 边界条件与失效前提

描述工程的有效性依赖若干前提：模型具备足够的指令遵循能力；Skill数量在上下文可承载范围内；描述与请求使用同一语言或模型具备跨语言对齐能力。当这些前提不成立时，描述优化的收益会显著衰减。此外，描述无法解决“模型根本不知道该能力存在”的问题——这属于系统提示与能力发现机制的设计范畴。

十、结论与展望

Skill触发失效的两端——漏触发与误触发——在机制上同源：描述文本作为语义路由契约，其覆盖度与边界清晰度共同决定了触发质量。把描述当功能说明写，必然在两端反复摇摆；把描述当路由契约写，才能在同一轮迭代中协同约束召回与精确。六段式结构、分层评测集、双阈值约束与运行时兜底，构成了一条可落地的工程路径。

展望未来，三个方向值得关注：其一，描述自动生成与自动评测，用日志与嵌入聚类辅助生成触发短语与反例；其二，分层路由架构，短描述做候选生成、长描述做精细判断，缓解上下文预算压力；其三，可学习的路由策略，在描述语义匹配之上叠加轻量分类器，兼顾泛化与可控。笔者认为，短期内描述工程仍是性价比最高的杠杆，但长期看，它会被纳入更系统的能力发现与路由框架之中，成为其中一层而非全部。

主要参考文献