跳到主要内容

Skill触发与评测

核对日期：2026-08-26。

1. 定义与边界​

Skill 触发（invocation）是 Host 根据用户目标、当前上下文和 Skill description，决定是否把某份 SKILL.md 正文加载进模型上下文。评测要分开测两件事：

层问题失败形态
发现 / 触发该不该加载误触发、漏触发、互抢
执行 / 遵从加载后是否按步骤做跳过门禁、乱序调工具、编造完成

本文件不重复工具 schema 评测，那是 ../10-Agent评测体系/ 与 ../04-工具调用体系/ 的范围。这里只补 Skill 特有的样本与指标。

Voyager 论文里的 Skill 是「验证过的可执行代码片段」，评测是技能能否在环境里复用。SKILL.md 评测是提示词资产的触发精度和遵从度。不要混用同一套指标。

2. 为什么重要​

description 会进发现层，和所有其它 Skill 抢注意力。没有评测集时，团队只会「感觉最近走查变好了」，无法知道：

  • 用户只问 OpenAPI 时，是否仍加载了设计稿 Skill。
  • 加载之后模型是否直接改代码，跳过 get_design_context。
  • 新 Skill 上线后，旧 Skill 召回是否被稀释。

触发错误的成本是上下文浪费；遵从错误的成本是虚假完成。后者更危险。

3. 核心机制​

自动触发只应依赖 description。WHEN NOT 写在正文却不写在 description，评测时会表现为「模型没看到反例」。规范见 SKILL.md工程规范.md。

显式点名（用户或系统指定 skill name）应绕过匹配阈值，但仍要跑权限与 MCP 依赖检查。

4. 架构模式​

4.1 样本分层​

每条 Skill 最少 10 条样本：正例 5、反例 5。建议标签：

标签含义
should_trigger必须加载该 Skill
must_not_trigger加载算失败
optional加载与否不评分，用于观察互抢
named用户点名，必须加载

互抢样本：同一句用户话可能命中两条 Skill。目录应规定优先级（更具体的任务 Skill 优先），评测记录「加载集合」而不只是布尔。

4.2 本仓库两条 Skill 的种子样本​

implement-from-design 正例：

  • 「按蓝湖稿实现这个列表页」
  • 「设计稿链接在这，先取证再写页面」
  • 「用现有组件库还原这个路由」
  • 「implement this page from the Lanhu design」
  • 「有 pageId，先对一下契约再动手」

implement-from-design 反例：

  • 「这个按钮的 CSS 变量是什么」
  • 「只跑 OpenAPI 契约，不要动设计稿」
  • 「对比一下线上页和设计稿还原度」（应走 review-design-fidelity）
  • 「MCP 没连，你直接根据印象写页面」
  • 「把生产库清掉设计缓存」

review-design-fidelity 正例：

  • 「走查一下首页还原度」
  • 「设计和实现差多少，跑门禁」
  • 「compare the live page to the mock」
  • 「有缓存设计上下文，做 fidelity review」
  • 「导出设计评审报告」

review-design-fidelity 反例：

  • 「从零实现这个新页」（应走 implement Skill）
  • 「检查 fetch 是否符合 OpenAPI，没有设计稿」
  • 「帮我解释一下 Flex 布局」
  • 「没有页面 URL 也没有截图，你看图说话说通过」
  • 「把 .mcp-cache 删了当走查」

4.3 遵从检查点​

触发成功之后，用轨迹而不是最终中文判断：

Skill关键 span禁止的完成声明
implement改文件前出现设计上下文或契约工具「我按常见电商列表写了」且无设计证据
fidelity出现 compare 或 run_design_gate / design_review_workflow「肉眼看没问题」

MCP 未连接时，期望是 blockedReason，任务失败或升级人工，而不是 Task Success。

5. 工程实现​

interface SkillEvalCase {
  id: string;
  query: string;
  expectedSkill: string | null;
  tags: readonly ("should_trigger" | "must_not_trigger" | "named")[];
  requiredSteps?: readonly string[];
  forbiddenClaims?: readonly string[];
}

function scoreTrigger(
  loaded: readonly string[],
  expectedSkill: string | null,
  tags: SkillEvalCase["tags"],
): "pass" | "fail" {
  if (tags.includes("must_not_trigger")) {
    return expectedSkill && loaded.includes(expectedSkill) ? "fail" : "pass";
  }
  if (expectedSkill === null) {
    return loaded.length === 0 ? "pass" : "fail";
  }
  return loaded.includes(expectedSkill) ? "pass" : "fail";
}

离线评测可以先做「无工具的触发分类」：只把各 Skill description 和 query 交给模型，看它选哪个 name。这比每次跑完整 MCP 便宜，适合 PR 门禁。完整遵从评测再在有 MCP 的环境跑小样本。

Trace 字段最少：skill.name、skill.version、trigger=auto|named、loaded_tokens。回放见 ../18-Agent前端与交互/轨迹回放界面.md。

6. 生产实践​

实践说明
PR 阻断误触发description 变更必须跑触发集
观察互抢新 Skill 上线后看旧 Skill recall 是否下降
正文长度预算触发后正文 token 超阈值告警
分开报表Trigger Precision/Recall 与 Task Success 不要合成一个分数
人工抽检每周抽 20 条生产 query，标该不该加载

高风险 Skill 默认关闭自动触发，只测 named 路径。见 能力目录与治理.md。

7. 常见反模式​

反模式表现后果修正
只用任务成功率Skill 没加载但模型碰巧做对无法治理能力资产分层指标
description 过宽「前端相关都用」Precision 崩WHAT + WHEN + WHEN NOT
评测即演示只准备一条黄金路径上线后误触发正反例对称
把加载当成功加载了但跳过 compare虚假走查遵从检查点
训练集污染把评测 query 写进 SKILL.md指标虚高样本与正文分离
论文指标套用用 Voyager 技能复用率评 Markdown口径错误术语分开

8. 评测方法​

指标定义建议门槛
Trigger Precisionshould_not 中未加载的比例核心 Skill ≥ 0.9
Trigger Recallshould_trigger 中加载的比例核心 Skill ≥ 0.85
Named Invocation Success点名后加载且权限通过= 1.0
Instruction Follow-through加载后关键步骤出现在 trace按 Skill 定
Hallucinated Completion无证据却声称通过= 0
Context Overhead未触发时正文 token= 0
Cannibalization新 Skill 导致旧 Skill recall 降幅需评审接受

评测集要版本化，和 Skill version 一起发布。模型升级后必须重跑，不能假设 description 匹配行为不变。

9. 安全与治理​

  • 触发评测 query 不要包含真实客户数据或内网链接。
  • 恶意用户可能用话术迫使高风险 Skill 加载：自动触发关闭 + 权限求交仍然有效。
  • 评测日志会包含用户原话，按 ../12-安全与治理/ 脱敏。
  • 外部 Skill 未进 allowlist 前，不进入自动匹配池，Precision 统计也不应计入生产 SLO。

10. 权威资料​