9.3 KiB
OpenAI Skill 自动评分器构建指南
一、为什么需要评分器
当更新一个 Skill 并执行完成后，表面结果正常不代表真的变好了。核心问题是：
- Skill 是否真的完成了预期任务？
- 修改是否引入了新的问题（回归）？
- 如何在不同版本之间进行性能比较？
评分器的职责就是回答这些问题，让 Skill 的质量变化可衡量、可追踪。
二、运行轨迹记录
2.1 什么是运行轨迹
评分的前提是有东西可以打分。OpenAI 的做法是使用 CodeExec JSON 记录 Skill 的完整执行过程。
2.2 配置方式
{
"code_exec": true // 启用后输出结构化执行记录
}
2.3 记录内容
启用后，Skill 每执行一步都会输出结构化记录，包括：
- 跑了什么命令
- 创建了什么文件
- 执行顺序
- 时间戳
2.4 关键特性
| 特性 | 说明 |
|---|---|
| 完整性 | 记录完整执行流程，而非日志摘要 |
| 可解析性 | 结构化数据，可被程序直接读取 |
| 可调试性 | 失败时可精确定位到具体哪一步出错 |
没有运行轨迹，评分器只能看最终产物，无法分析执行过程。
三、评分器类型
3.1 确定性检查（Deterministic Checks）
3.1.1 原理
纯代码规则驱动的检查，不用大模型，写死判断逻辑，程序直接对着运行轨迹核对。
3.1.2 典型检查项
- 有没有执行 npm install
- 有没有创建 package.json
- 命令执行顺序是否符合预期
- 是否在指定目录执行操作
3.1.3 核心特性
| 特性 | 说明 |
|---|---|
| 确定性 | 同样行为每次判断结果一致，没有模糊地带 |
| 可调试 | 一旦失败，打开记录文件即可看到从哪一步开始偏离 |
3.1.4 局限性
确定性检查能回答"基础动作做了没有"，但无法回答"做出来的东西是不是你想要的样子"。
3.2 评分细则检查（Rubric-based Checks）
3.2.1 原理
使用 LLM 作为裁判，读取仓库内容，按预定义的评分细则输出结构化打分结果。
3.2.2 适用场景
很多 Skill 的验收标准本来就是软性规则，例如：
- 代码结构是否干净
- 组件组织是否符合团队约定
- 样式配置是否按既定风格落地
- 命名规范是否遵循
3.2.3 评分细则的拆解方法
把模糊的质量标准拆成若干个可独立判断的维度：
| 模糊标准 | 拆解后的维度 |
|---|---|
| 代码质量好 | 组件是否按功能分目录 |
| 是否有未使用的引用 | |
| 样式类名是否遵循命名约定 | |
| 配置项是否集中管理 |
3.2.4 关键要求：锁定输出格式
必须提前定义输出模板，规定模型必须输出哪些字段：
{
"passed": true/false,
"total_score": 85,
"dimensions": [
{
"name": "component_organization",
"score": 90,
"reason": "组件按功能正确分目录"
},
{
"name": "unused_imports",
"score": 70,
"reason": "发现3处未使用的import"
}
]
}
3.2.5 为什么必须锁死格式
| 自由输出 | 锁死格式 |
|---|---|
| 每次措辞不同 | 格式统一 |
| 无法跨版本比较 | 结果可量化 |
| 无法进自动化流程 | 可直接集成 CI/CD |
| 输出是"审稿意见" | 输出是"评估数据" |
四、评分器组合策略
4.1 分工明确
确定性检查 ──→ 抓底线（基础动作有没有发生）
评分细则检查 ──→ 抓质量（做出来的东西像不像你要的）
输出格式锁定 ──→ 防飘移（每次评分结果一致）
4.2 集成到流水线
这套组合设计之初就面向 持续集成（CI）：
- 不再依赖工程师手动触发测试
- 成为持续运行的回归守门员
- Skill 每次更新都会自动验证
五、6 类扩展检查
在基础评分器之上，可按需叠加以下检查：
5.1 命令数与循环检测
检查运行记录里执行了多少条命令
目的：检测行为退化
案例：如果一个 Skill 以前 6 步能完成，现在要 18 步，表面上任务还是完成了，但系统正在变差。
5.2 消耗量追踪
记录每次运行消耗的 token 数量
目的：防止 Skill 越来越臃肿
- 每次执行越来越贵
- 每次执行越来越慢
5.3 构建检查
# skill 完成后直接执行构建命令
npm run build
目的：端到端验证
- 很多项目表面完成，构建就露馅
- 成本低，应该默认开启
5.4 运行时冒烟检查
# 启动开发服务器
npm run dev
# 发送测试请求
curl http://localhost:3000/api/health
目的：验证服务是否真正可用
注意：这类检查更慢，按风险等级决定是否每次都执行。
5.5 仓库清洁度检查
检查任务完成后是否出现不该有的文件
目的：确保系统没有被"弄脏"
5.6 权限回归检查
验证 skill 是否还能在最小权限下正常工作
目的：防止权限漂移
- 某次改动后悄悄开始依赖更高权限
- 权限漂移在自动化后会变成结构性风险
5.7 扩展策略
原文建议：先加快速检查，再按风险叠加慢检查
不是一次全上，是按需扩展
| 检查类型 | 速度 | 建议频率 |
|---|---|---|
| 命令数检测 | 快 | 每次 |
| 消耗量追踪 | 快 | 每次 |
| 仓库清洁度 | 快 | 每次 |
| 构建检查 | 中 | 每次 |
| 运行时冒烟 | 慢 | 按风险 |
| 权限回归 | 慢 | 定期 |
六、5 条核心原则
原则一：量真正重要的东西
Don't measure for the sake of measuring. First, think about what you'd actually care about if it got worse.
不要为了有指标而有指标，先想清楚什么变差了，你会真的在意。
原则二：先写清晰可检查的定义
If the success criteria are fuzzy, the evaluation will be too.
验收标准模糊，评估就没有意义。先把"什么叫做对"写成可执行的判断。
原则三：把评估扎在真实行为上
Record the full execution trace and write deterministic checks around the actual actions taken.
记录 Skill 的完整运行轨迹，围绕实际执行的动作写确定性检查。
原则四：规则不够时，再让模型补上
Use rubric-based evals to handle quality judgments that rules can't cover, not as a replacement.
用评分细则处理规则覆盖不了的质量判断，顺序不能反。确定性检查在前，LLM 评分在后。
原则五：让真实失败去驱动样本增长
Every time you manually fix something, turn it into a test case.
每次手动修复都是一个信号，把它变成测试用例，让 Skill 持续把这件事做对。
七、整体流程图
┌─────────────────────────────────────────────────────────┐
│ Skill 执行 │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ CodeExec JSON 记录运行轨迹 │
└─────────────────┬───────────────────────────────────────┘
▼
┌───────┴───────┐
▼ ▼
┌───────────────┐ ┌─────────────────┐
│ 确定性检查 │ │ 评分细则检查 │
│ (规则驱动) │ │ (LLM 裁判) │
└───────┬───────┘ └────────┬────────┘
▼ ▼
└────────┬─────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 结构化评估结果（跨版本可比较） │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 进入 CI/CD 流水线 │
└─────────────────────────────────────────────────────────┘
八、参考资料
- 原文标题：Testing Agent Skills Systematically with Evals
- 原文链接：https://developers.openai.com/blog/eval-skills
- 视频来源：慢学AI（BV1HWd6BsEmG）