别再裸奔发布 Skill：Google DeepMind 这场 21 分钟演讲讲透了 eval 为什么是准入门槛

本文整理自 Google DeepMind 工程师 Philipp Schmid 在 AI Engineer 的演讲。核心问题不是 Skill 有没有用，而是没有 eval 的 Skill 无法判断何时该触发、何时该退休，也无法证明它真的让 Agent 变好。原视频：https://www.youtube.com/watch?v=0vphxNt4wyk

AI Agent 圈子里，Skill 已经变成一个很顺手的抽象：一个文件夹，一个 SKILL.md，再配一些脚本、模板、参考资料。你把团队经验写进去，Agent 下次就更像一个懂行的人。

问题也在这里。Skill 太容易写了，导致它也太容易被信任。

Philipp Schmid 这场演讲的判断很简单：不要发布没有 eval 的 Skill。不是因为 Skill 不重要，恰恰相反，是因为 Skill 已经开始影响 Agent 的真实行为。没有评测，你不知道它是在帮忙，还是在制造噪声。

Skill 的第一层风险：你不知道失败来自哪里

演讲一开始，Philipp 做了一个现场调查：谁在用 coding agent 写代码？几乎所有人举手。谁在用 Skill？不少人举手。谁给这些 Skill 写了 eval？手明显少了很多。

这就是当前状态：大家都在给 Agent 加 Skill，但很少有人给 Skill 加验收。

Skill Bench 做过一个大规模观察：它索引了超过 5 万个 Skill，几乎没有 Skill 带 eval。很多 Skill 是 AI 自动写出来的，看起来结构完整，读起来也像那么回事，但没有被系统测试过。

裸 Skill 最大的问题不是“写得差”。真正麻烦的是：Agent 本身就是非确定性的。任务失败时，你很难判断原因：

• 是 Skill 描述太弱，模型没触发？
• 是 Skill 触发错了，把模型带偏？
• 是 Skill 本身过时了？
• 还是任务本来就超出了模型能力？

没有 eval，这些问题全都混在一起。你只能凭感觉改提示词，凭感觉加规则，最后把 Skill 写成一坨越来越长的补丁。

这和我们知识库里一直讲的 Harness Engineering 是同一个问题：模型不是单独工作的，模型外面的上下文、工具、状态、验证门禁，都会改变结果。Skill 属于 harness 的一部分。改 Skill 就是在改系统，不是在改文档。

Agents we use 和 Agents we build 不是一回事

演讲里有一个很重要的区分：我们使用的 Agent，和我们构建给别人用的 Agent，不是同一种使用环境。

我们自己用 Claude Code、Cursor、Antigravity 这类工具时，人还在环路里。你知道有哪些 Skill。模型没触发，你会立刻发现，然后补一句“用某某 Skill”，或者直接用 slash command 调起来。

但你把 Agent 做进产品里，面向客户或普通用户时，情况就变了。客户不会说：

请使用退款 Skill 帮我处理这个问题。

他只会说：

我想退款。

这时 Skill 只能靠模型自己触发。模型能不能在浅提示、口语表达、信息不全的情况下找到正确 Skill，就变成产品可靠性问题。

所以用户显式触发 Skill 和模型自动触发 Skill，要分开看。前者更像工作流快捷方式；后者才真正需要严肃评测触发率、误触发率和结果质量。

这也是为什么 Skill 的 description 不是简介，而是路由规则。它决定模型什么时候看见这个能力，什么时候不要碰它。

好 Skill 不是长文档，而是渐进披露

Philipp 对 Skill 的定义很朴素：一个文件夹，里面有 SKILL.md，再加一些能让 Skill 真正工作的资产。

关键在于 progressive disclosure，渐进式披露：

1. 第一层是名称和 description。它们通常会进入模型上下文，负责告诉模型什么时候该用。
2. 第二层是 SKILL.md 主体。这里放任务契约、约束、关键步骤。
3. 第三层是 references、scripts、templates、assets。只有需要深入处理某个分支时，模型才去读。

这套结构不是为了好看，而是为了控制成本和干扰。

description 是每次模型调用都要付的成本。SKILL.md 一旦被加载，也会吃掉上下文。如果你把 AWS、GCP、Azure 三套部署细节全塞进主文件，模型处理一个 GCP 任务时也会读到一堆无关云厂商信息。

Skill Bench 的结论也很直接：人写的 Skill 效果最好；AI 自动生成的 Skill 可能反而拉低表现；SKILL.md 最好控制在 500 行以内。

这和本库里的 Skill 设计五层模型能接上：description 解决“能不能被叫到”，contract 解决“叫到以后会不会做对”。主文件应该像门，不应该像仓库。

两类 Skill：能力型会过期，偏好型更耐久

演讲把 Skill 分成两类：capability skills 和 preference skills。

能力型 Skill 教模型做当前还做不稳定的事。例如使用某个新 API、遵循某套框架脚手架、生成特定 SDK 代码。它们天然是临时的。模型升级后，这些知识可能已经内化到模型里，旧 Skill 反而变成负担。

偏好型 Skill 则更耐久。它编码的是团队或个人的偏好：命名习惯、文章风格、代码审查口径、发布流程、企业内部工具约定。这些东西基础模型很难从公开训练语料里学到，因为它们只存在于你的组织里。

这一区分很有用。能力型 Skill 的核心问题是“什么时候退休”；偏好型 Skill 的核心问题是“别被模型升级冲掉”。两者都需要 eval，只是 eval 的目的不同。

• 能力型 Skill：评估加不加 Skill 是否还有效，决定何时删除。
• 偏好型 Skill：评估团队偏好是否仍被稳定执行，防止回归。

换句话说，Skill 不是写完就永久加持。它有生命周期。

写 Skill 的八个实用原则

Philipp 在演讲中给了几条写 Skill 的经验。放到工程实践里，可以压成八条。

1. description 写 why、how、when

description 不是营销文案，而是模型的触发说明。

坏写法是泛泛而谈：

这个 Skill 可以帮助你开发 Web 应用。

好写法要更像指令：

当任务需要编写 React 组件并使用 Tailwind CSS 时，使用这个 Skill。不要用于 Angular、后端 API 或通用 Web 文档任务。

这里同时包含了 why、how、when，以及负向边界。

2. 写指令，不写散文

模型不需要一篇温柔的说明文。它需要知道该做什么。

不要写：

Interactions API 推荐用于多轮对话，因为它可以处理 session state。

直接写：

构建多轮聊天应用时，使用 Interactions API 管理 session state。

这不是风格问题，是行为控制问题。被动信息不一定改变模型动作，指令才更容易改变动作。

3. 保持主文件精简，把细节分层

Skill 的主文件应该保留：触发条件、输入输出、边界、默认路径、验证方法。

具体供应商文档、长示例、历史坑、模板，放到 references 和 scripts 里。模型需要时再读。

这条规则有一个副作用：它逼你区分“每次都必须知道的契约”和“某个分支才需要的资料”。这比单纯压缩 token 更重要。

4. 给模型合适的自由度

如果一个流程每次都完全一样，不要写成 Skill 让模型一步步执行。写脚本。

Skill 适合“目标稳定、路径需要判断”的任务。脚本适合“路径稳定、变量有限”的任务。

比如“读取配置、替换端口、重启服务”这种固定流程，脚本更可靠。Skill 可以告诉 Agent：配置文件在哪里，允许改什么，改完怎么验收。真正的机械动作交给确定性层。

这也对应我们常说的分工：确定性执行交代码，不确定性判断交模型。

5. 明确负例，防止过度触发

很多 Skill 只写“什么时候用”，不写“什么时候不用”。这会让模型过度触发。

“用于 Web 开发任务”这种 description 几乎一定会误触发。React、Angular、后端接口、CSS 修补、SEO 配置，都会被它吸进去。

更好的写法是列出负例：

• 只用于 React 组件，不用于 Angular。
• 只用于 Tailwind CSS，不用于普通 CSS 主题修改。
• 只用于新建组件，不用于代码审查。

负例不是啰嗦。负例是路由边界。

6. 一开始就写 10 到 20 条测试提示

Philipp 建议新建 Skill 时，先写 10 到 20 条 prompt。最小配置可以是：

• 5 条应该触发的 happy path。
• 5 条不应该触发的 negative path。
• 如果有真实用户轨迹，再加真实 case。

这一步不需要上来就做复杂平台。哪怕 JSON 文件加一个 Python runner，也比没有强。

7. 清理 no-op 指令

AI 生成的 Skill 很容易写一堆 no-op：

• 写清晰、高质量代码。
• 实现前先理解需求。
• 保持可维护性。

这些话通常不会改变模型行为。模型本来就知道要写清晰代码。它缺的是你的项目里什么叫“清晰”，什么叫“通过验收”，什么是不能碰的边界。

no-op 的坏处不是占几行字，而是污染注意力。Skill 每长一截，真正有效的指令就更难被模型抓住。

8. 定期做 ablation，知道什么时候退休

评测 Skill 时，不要只测“带 Skill 能不能过”。还要测“不带 Skill 能不能过”。

如果模型不用 Skill 也能稳定完成任务，Skill 就可能该退休了。保留 eval，不一定保留 Skill。

这个判断对能力型 Skill 尤其重要。模型升级很快，六个月前必需的规则，今天可能已经是成本和干扰。

Skill eval 可以很简单：JSON + Python + Regex

演讲后半段给了 Google DeepMind 内部的一个例子：Gemini Interactions API Skill。

这个 API 发布在模型训练之后，所以模型不知道最新接口。团队为它做了一个 Skill，目标是让模型生成新的 Interactions API 代码，而不是继续使用旧 SDK、旧模型 ID、旧方法。

他们做了 117 个测试用例，来源包括真实用户问题、合成 case、用户反馈。每条 case 大概包含：

• prompt：用户会怎么问。
• language：TypeScript 或 Python。
• should_trigger：是否应该触发 Skill。
• expected checks：结果里应该出现或不应该出现什么。

很多检查只是 regex：

• 是否用了正确 SDK。
• 是否用了正确 model id。
• 是否调用了正确方法。
• 是否避开旧模式。

这类 eval 便宜、快、可回归。它不需要每次都请一个 LLM 当裁判。

当然，复杂任务可以用 LLM-as-judge。比如要看完整 trace、判断 Agent 是否按正确步骤执行、是否进行了必要验证。关键不是“评测一定要高级”，而是“每次改 Skill 都能看到是否退化”。

真正要测的是 outcome，不是模型有没有第一步读 Skill

一个容易走偏的 eval 是：检查模型第一轮有没有加载 Skill。

Philipp 的建议更实用：测 outcome，不要只测 path。

如果模型第五步才加载 Skill，但最终完成任务，也可以接受。如果模型没加载 Skill 也完成了，可能说明模型已经学会，Skill 可以考虑退休。

这会把 eval 从“监督模型姿势”拉回“监督结果质量”。

好的 Skill eval 应该关心：

• 最终产物是否符合契约。
• 是否避开了明确禁止的旧模式。
• 是否在该拒绝时拒绝或降级。
• 是否在该触发时能触发并完成任务。
• 多次 trial 下是否稳定。

Agent 是非确定性的，所以每个 case 最好跑多次。一次通过不代表稳定，三到六次 trial 更接近可靠性判断。

对团队来说，Skill eval 是准入治理，不是测试洁癖

这场演讲和我们之前沉淀的“Skill 准入治理”几乎是同一个方向。

我们自己的判断是：Skill 的核心工程问题不是“有没有文档”，而是“不稳定”。今天好用，明天失效；一个模型好用，另一个模型误触发；演示能跑，上线后没有反馈闭环。

Google DeepMind 的做法给了一个更具体的落地形态：每个 Skill 旁边放 eval。每次改 Skill 都跑。只有改动改善结果，或者至少不破坏回归，才能合入。

这相当于给 Skill 做 CI/CD：

1. Skill 是能力单元。
2. Eval 是准入门禁。
3. Trace 是调试证据。
4. Ablation 是退休机制。

没有这四件事，Skill 就只是可复用 prompt。它能让 Agent 看起来更专业，但你不知道它有没有让系统更可靠。

一个最小可执行版本

如果你现在有一堆 Skill，但没有 eval，不需要先搭大平台。可以从最小版本开始。

先挑一个最常用、最容易出错、业务价值最高的 Skill。写一个 eval_cases.json：

[
  {
    "name": "react_component_happy_path",
    "prompt": "帮我做一个 React 组件，用 Tailwind 实现卡片列表",
    "should_trigger": true,
    "checks": {
      "must_contain": ["className", "map("],
      "must_not_contain": ["ngFor", "Vue"]
    }
  },
  {
    "name": "angular_negative_path",
    "prompt": "帮我改一个 Angular 模板的样式",
    "should_trigger": false,
    "checks": {
      "must_not_contain": ["React skill loaded"]
    }
  }
]

再写一个 runner：把 prompt 喂给你的 agent harness，保存输出和 trace，然后跑断言。

最开始只做三类检查就够了：

• 触发：该用时用了，不该用时没用。
• 输出：关键模式出现，旧模式不出现。
• 稳定：同一 case 多跑几次，不靠运气过。

等这些跑起来，再加 LLM-as-judge、真实用户轨迹、跨模型、跨 harness。

最后那句 homework 值得照做

演讲最后的作业很朴素：回去以后，挑一个你最常用的 Skill，写五条测试 prompt。

这比“重构所有 Skill”更现实。

如果五条都写不出来，说明这个 Skill 的契约还没清楚。如果写出来一跑，发现正例不触发、负例乱触发、输出靠运气，那也很好。至少问题从感觉变成了证据。

Skill 真正的价值，不是把经验写进 Markdown。价值在于：这份经验能被正确触发、稳定执行、持续回归，并且在过期时被删掉。

不要发布没有 eval 的 Skill。不是口号，是 Agent 工程进入生产环境后的最低门槛。