Agent Skill Eval：从触发信号到 A/B 基准，如何把 Skill 做成可回归工程单元

Skill 的价值不在提示词，而在可测试、可对照、可回归的工程闭环。
原文链接：AI 小老六

导语

Agent Skill 正在变成一种新的工程资产。它看起来只是一个带有触发描述的 Markdown 文件，实际承担的是把领域经验、操作流程、工具约束和团队偏好注入 Agent 执行链路的职责。

真正的问题不在于“能不能写出一个 Skill”，而在于：这个 Skill 是否稳定改善了 Agent 的输出？它改善了什么，代价是什么，改善是否可复现？如果只能靠体感判断，一个 Skill 很容易停留在手工作坊阶段；如果能被测试、对比、统计和迭代，它才有机会进入工程体系。

Claude Code 的 skill-creator 给出的关键启发正在这里：Skill 不是写完就结束的提示词文件，而是一套可评测、可回归、可优化的软件单元。

Skill 生命周期：把“写说明”变成“跑闭环”

skill-creator 的价值不只是生成 SKILL.md，而是把 Skill 从创建到改进的过程拆成四个环节：

图：Skill 从创建、评测、改进到多轮基准的反馈闭环

这套流程背后的设计判断很清楚：​Skill 的质量不应该由作者自证​，而应该由任务执行结果反推。创建阶段产出的是初始假设，Eval 阶段验证假设，Improve 阶段修正假设，Benchmark 阶段看修正是否在统计意义上站得住。

环节	核心产物	工程含义
Create	SKILL.md 初稿	把隐性流程显性化
Eval	测试用例与执行记录	验证 Skill 是否真的改变结果
Improve	修改后的 Skill	从失败样本中抽象通用规则
Benchmark	通过率、耗时、Token 统计	判断收益是否覆盖成本

这个闭环让 Skill 不再像“经验贴”，而更接近一个可以持续回归的软件模块。

功能评测：同一任务下的因果对照

评测 Skill 最有力的方式不是单跑一次看结果，而是让两个 Agent 面对同一个任务：一个加载 Skill，一个不加载 Skill。两者在同一环境、同一输入下独立执行，再把输出交给评分器。

图：同一任务下有无 Skill 的因果对照流程

这里的重点是“因果对照”。单次成功只能说明 Agent 这次完成了任务，不能说明 Skill 有贡献；只有看到 with-skill 相比 without-skill 在可验证指标上稳定提升，才能说这个 Skill 产生了工程价值。

evals.json 通常把每个任务拆成两部分：prompt 描述要完成的事，expectations 描述结果必须满足哪些条件。好的 expectation 必须能被机械检查，例如文件存在、字段值正确、目录结构符合约定、输出包含必要元数据，而不是“质量很好”“效果不错”这种不可复现判断。

{
  "id": "video-product-ad",
  "prompt": "生成一段 9:16、5 秒的产品广告视频，并保存完整产物",
  "expectations": [
    "video.mp4 存在且非空",
    "manifest.json 包含 model、ratio、duration、task_id",
    "prompt.md 保存最终英文提示词"
  ]
}

把主观质量收敛成可检查断言，是 Skill Eval 能规模化的前提。

图：Skill 的工程价值来自可测试、可对照与可回归的闭环。

Grader：评分器要像编译器一样稳定

skill-creator 中的 ​Grader 本质上不是“另一个大模型裁判”​，而是尽量用确定性脚本检查输出。文件大小、JSON 字段、目录结构、命令退出码、日志内容，这些都比 LLM 打分更便宜、更快，也更可复现。

典型评分结果需要保持稳定字段：

{
  "expectations": [
    {
      "text": "manifest.json 包含 ratio=9:16",
      "passed": true,
      "evidence": "Found ratio=9:16 in outputs/manifest.json"
    }
  ],
  "summary": {
    "passed": 1,
    "failed": 0,
    "total": 1,
    "pass_rate": 1.0
  }
}

text / passed / evidence 这类字段看似琐碎，实际是后续可视化、聚合与问题追踪的接口契约。只要字段名随意变化，评测查看器和统计脚本就会失效。

更重要的是，Grader 自身也需要被迭代。常见错误不是 Skill 没做好，而是评分器只在固定目录找文件、没有递归扫描、没有识别工具自动创建的日期目录，结果把正确输出判成失败。第一次 Eval 的意义，往往不只是测 Skill，也是在测试断言是否写对。

Benchmark：平均值不够，波动同样重要

​一次 Eval 只能暴露单点问题​，多轮 Benchmark 才能看出稳定性。聚合脚本通常会统计 with-skill 和 without-skill 的通过率、耗时与 Token 消耗，并给出均值与标准差。

With Skill:    pass 86% ± 18%, time 210s ± 75s, tokens 42k ± 11k
Without Skill: pass 51% ± 31%, time 160s ± 96s, tokens 28k ± 14k
Delta:         +35pp pass, +50s time, +14k tokens

这里的 Delta 才是决策依据。一个 Skill 如果多消耗 50 秒和 14k Token，只换来 2 个百分点提升，可能不值得；如果把通过率从 0% 拉到 80%，再贵也可能是唯一可行路径。

标准差同样关键。86% ± 18% 和 86% ± 3% 的工程含义完全不同：前者说明某些任务仍然很脆，后者说明 Skill 行为已经比较稳定。Skill 的目标不是偶尔做出惊艳结果，而是把 Agent 输出压到可预期区间。

图：稳定的 Grader 把输出质量压缩为可复用的接口契约。

Trigger Eval：Skill 首先要被读到

再好的 Skill，如果触发描述写得模糊，Agent 根本不会加载它。skill-creator 因此把 description 当作一个独立入口来评测：给一组 should-trigger 和 should-not-trigger 查询，检测模型是否会调用 Skill 或读取对应文件。

图：通过命中率和误触率优化 Skill 触发描述

这类评测适合验证“何时该加载 Skill”。对于代码风格、写作偏好、发布流程、工具使用规范这类边界较清晰的 Skill，Trigger Eval 很有价值。

但它不是万能的。很多能力增强型 Skill 需要完整上下文才会自然触发，例如“生成视频”“调用私有平台”“跑内部发布流水线”。单句查询很容易让 Agent 误以为自己可以直接写脚本解决，从而不加载 Skill。对于这类 Skill，功能 Benchmark 比 Trigger Eval 更能说明问题。

与 Codex 评测思路的差异

OpenAI Codex 的评测方案更强调可脚本化执行、结构化输出和 CI 集成，适合把 Agent Skill 放进传统工程流水线。Claude Code 的 skill-creator 更强调因果对照：同一任务下，有 Skill 和无 Skill 的结果差异到底是什么。

能力维度	Claude Code skill-creator	Codex 系统化 Eval
With/without A/B 对比	原生支持	需要自行搭建
机械 Grader	原生流程核心	可通过脚本实现
多轮统计聚合	标准化输出	可接入 CI 自建
Trigger Eval	有独立优化链路	非核心能力
输出 Schema 约束	不是主要抓手	重点能力
CI 适配	可做但不是中心	更自然

两者并不是谁替代谁。Claude Code 的优势在于判断“Skill 是否真的有用”，Codex 的优势在于把检查嵌入自动化流水线。一个偏因果评估，一个偏工程集成。

Skill 的真实价值：把不稳定输出变成接口

很多人会把 Skill 的价值理解成“让 Agent 更聪明”。这只说对了一半。更准确的说法是：Skill 把 Agent 的随机性压缩成下游可以消费的接口。

没有 Skill 时，Agent 也许能完成任务，但输出目录、文件名、字段名、日志格式每次都不同。下游脚本、评审工具、监控系统很难依赖这种产物。有 Skill 后，输出可以稳定变成 artifact + manifest + prompt/log 这类结构，团队才有机会围绕它继续自动化。

这也是为什么很多 Skill 的收益不体现在“成功率提升多少”，而体现在“结果是否可接入流水线”。对于内部 API、私有平台、需要登录才能访问的文档、网页难以抓取的控制台，Skill 还承担了知识入口的角色：没有它，Agent 甚至不知道应该从哪里开始。

Grader 与 Skill 要一起演进

开发 Skill 时，失败信号大致有三类：

信号	暴露的问题	应该怎么用
断言失败	某个输出契约没满足	检查是 Skill 缺规则，还是 Grader 写错
人工反馈	结果能用但体验不好	抽象成更通用的行为约束
执行轨迹	Agent 为什么走偏	找到触发、工具选择或上下文缺口

改 Skill 最忌讳为某个失败样本写窄补丁。更好的方式是从失败里抽象底层规则：是不是输出契约不够明确？是不是工具调用顺序缺约束？是不是示例太少导致模型误解？是不是应该把重复脚本沉淀进 scripts/？

保持 Skill 精简也很重要。过长的说明会稀释注意力，让 Agent 抓不到关键约束。真正有效的 Skill 往往不是罗列所有细节，而是把不可违反的边界、可复用的流程和标准输出契约说清楚。

从 Skill 到 Spec

长期看，Skill 可能会从“告诉模型怎么做”转向“定义什么算做对”。当模型能力足够强，领域专家也许不再需要写一页页执行步骤，只要提供任务边界、成功标准、失败样例和评测集，模型就能自己推导执行方法。

在这个方向上，Eval 不再只是 Skill 的测试工具，而会逐渐成为 Skill 的一部分。SKILL.md 描述操作经验，evals.json 描述成功标准，Grader 描述可验证契约，Benchmark 描述稳定性。四者合在一起，才是一个完整的 Agent Skill 工程单元。

关键术语

术语	含义
Eval	单个测试用例，通常由任务输入和期望断言组成
Benchmark	多个 Eval 的多轮运行与统计聚合
Grader	根据断言检查输出的评分器
Comparator	对不同输出做盲评或差异分析的评审组件
Trigger Eval	验证 Skill 是否在正确场景被加载
Workspace	存放每轮评测中间产物的临时目录

• 推荐阅读

  LLM 记忆系统：从 Markdown 知识库到 Self-Governing Repo

• AI Native 架构：有限上下文、确定性边界与质量闸门

• Agent Workflow Runtime 架构拆解：把 Agent Loop 从提示词搬进代码，长任务才真正稳了

• AI Native 竞争力：真正稀缺的不是会用 AI，而是把事往前推的人

• GEPA 架构拆解：让 Prompt 和 Skill 优化不靠玄学