OpenAI：如何用 Evals 证明 Agent Skill 没有被改坏

评估 Skill 的基本单元不是最终答案的一次主观观感，而是“输入 Prompt—完整运行轨迹与产物—一组可解释检查—可比较分数”；只有这个闭环存在，迭代才有证据。

1. 原文说了什么

先定义成功，再写 Skill

OpenAI 把 Skill 评估看成轻量端到端测试。写 Skill 之前，先把成功拆成少量必须满足的目标：

• 结果目标：任务是否真的完成，产物能否运行。
• 过程目标：是否触发 Skill，是否执行了必要步骤和工具。
• 风格目标：输出是否符合约定结构和规范。
• 效率目标：是否出现无意义循环、重复命令或 token 膨胀。

只看最后文件可能掩盖错误路径；只看工具调用又不能证明产物可用。因此，需要同时保留 trace 与 artifacts。

先手工触发，暴露隐藏假设

原文以创建 React、Vite 与 Tailwind 示例项目的 Skill 为例。早期应显式调用 Skill，观察它是否漏装依赖、错误假设目录为空、触发过宽或跳过顺序。每次人工修复都是一个未来评估样本。

用小型 Prompt 集守住路由边界

单个 Skill 不需要一开始就建设大型 benchmark。原文建议先用约 10～20 个提示，覆盖四种情况：

1. 明确点名 Skill 的显式调用。
2. 不点名但意图匹配的隐式调用。
3. 带有真实噪声和业务背景的上下文调用。
4. 与目标相邻、但不应该触发的负向对照。

这个 CSV 会随着真实失败逐渐增长，成为 Skill 必须持续做到什么的活记录。

两层评分：确定性检查＋结构化质检

第一层使用 codex exec --json 捕获 JSONL 事件，对命令、顺序和文件进行确定性检查。例如是否运行安装命令、是否创建 package.json、是否留下多余文件。失败时可以直接回看事件序列，定位回归原因。

第二层处理结构、样式和约定等难以写成布尔规则的问题。可以启动一个只读评审，让 Codex 按 rubric 检查产物，并通过 --output-schema 返回固定 JSON 结构。这样，模型评审至少能被解析、比较和追踪，而不是输出一段自由文本。

当 Skill 逐渐成熟，再按风险增加构建检查、运行时冒烟测试、仓库清洁度、命令次数、token 预算和权限回归。原则是先使用快速、可解释的信号，只有确实降低风险时才增加重型检查。

2. 我是怎么理解的

这套方法可以看成 Agent 版本的测试金字塔：

• 最底层是快速、便宜、可解释的事件与文件断言。
• 中间层是构建、冒烟和真实环境的端到端检查。
• 顶层才是成本更高、稳定性更弱的模型量表评分。

最重要的变化是把 trace 当作一等产物。传统软件测试通常知道函数调用和状态变化；Agent 如果只留下最终文本，就无法判断它是正确执行、偶然成功，还是走了危险路径后碰巧得到相同结果。

评估还把“是否触发”与“触发后是否做好”分成两个问题。前者验证路由，后者验证能力。很多 Skill 看似内容写得很好，真正失败点却是根本没有加载，或在相邻请求上误加载。

3. 我的判断是什么

我认同从小样本和确定性检查开始。这比一上来构造复杂的 LLM Judge 更容易调试，也更能解释一次修改为什么变好或变坏。

但要把它用于生产，还需补上三点：

1. 重复运行：模型有随机性，单次通过不能代表稳定通过；关键样本需要多次运行并记录分布。
2. 隔离与权限：自动评估会执行真实命令，应在临时目录或沙盒中运行，并采用最小权限。
3. 防止评估过拟合：开发集可用于迭代，但还需要未参与调试的保留样本检查泛化。

模型量表也不能因为输出了 JSON 就自动可信。Rubric 必须具体，评审应只读，关键结果仍要由确定性信号或人工抽查兜底。

4. 可以怎么使用

一套最小 Skill 评估目录可以包含：

evals/
├── prompts.csv             # 正例、隐式触发、真实噪声、负例
├── run-evals.*             # 启动 Agent 并保存轨迹
├── deterministic-checks.* # 命令、文件、顺序与退出状态
├── rubric.schema.json      # 结构化质量评分
└── artifacts/              # JSONL、产物与评分结果

最小实施顺序：

1. 写出 3～5 个不可妥协的成功条件。
2. 选择 10～20 个真实 Prompt，至少包含一个相邻负例。
3. 在隔离目录运行并保存 trace、stdout、stderr 和最终产物。
4. 先写确定性 grader，再补只读 rubric grader。
5. 同时比较无 Skill 与有 Skill，避免只看新版本之间的差异。
6. 每次人工修复都转成回归样本。
7. 在 CI 中设定失败门槛，并保存历史分数与成本趋势。

做到这一步，Skill 的改动才从“感觉更好”变成“有证据证明没有被改坏”。