321 lines
9.4 KiB
Markdown
321 lines
9.4 KiB
Markdown
---
|
||
title: "[Milky] 为您整理《OpenAI：Skill的自动评分器怎么搭》笔记 | BV1HWd6BsEmG"
|
||
source: "milky@4ueo.com"
|
||
date: 2026-06-09 21:17
|
||
tags: [milky, bilibili, notes]
|
||
email_id: 1995
|
||
---
|
||
|
||
Milky 为您整理了《OpenAI：Skill的自动评分器怎么搭》| BV1HWd6BsEmG 笔记。
|
||
|
||
OpenAI Skill 自动评分器构建指南
|
||
|
||
一、为什么需要评分器
|
||
|
||
当更新一个 Skill 并执行完成后，表面结果正常不代表真的变好了。核心问题是：
|
||
|
||
Skill 是否真的完成了预期任务？
|
||
修改是否引入了新的问题（回归）？
|
||
如何在不同版本之间进行性能比较？
|
||
|
||
评分器的职责就是回答这些问题，让 Skill 的质量变化可衡量、可追踪。
|
||
|
||
|
||
二、运行轨迹记录
|
||
|
||
2.1 什么是运行轨迹
|
||
|
||
评分的前提是有东西可以打分。OpenAI 的做法是使用 CodeExec JSON 记录 Skill 的完整执行过程。
|
||
|
||
2.2 配置方式
|
||
|
||
`json
|
||
{
|
||
"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 关键要求：锁定输出格式
|
||
|
||
必须提前定义输出模板，规定模型必须输出哪些字段：
|
||
|
||
`json
|
||
{
|
||
"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 构建检查
|
||
|
||
`bash
|
||
skill 完成后直接执行构建命令
|
||
npm run build
|
||
`
|
||
|
||
目的：端到端验证
|
||
|
||
很多项目表面完成，构建就露馅
|
||
成本低，应该默认开启
|
||
|
||
5.4 运行时冒烟检查
|
||
|
||
`bash
|
||
启动开发服务器
|
||
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）
|
||
|
||
──────────────────────────────
|
||
— Milky 视频总结助手 |