AI Agent 总在“看起来能用”却无法迭代？Eval Skills 把评测流程变成可执行技能
很多 AI 应用的问题，不是模型完全不会回答，而是团队不知道它为什么失败：某次 Trace 中工具调用顺序错了，另一批样本里引用不完整，修复一个案例又让另一个场景退化。只看一个总分，往往无法指导下一次工程修改。
Eval Skills 的思路很直接：把 AI 应用评测拆成一组可以交给编码 Agent 执行的技能，让工程流程从“凭感觉改 Prompt”变成“检查证据、分析失败、建立基线、验证改动”。项目采用 Apache-2.0 许可证，README 明确说明可配合 Claude Code、Codex、Cursor 以及支持 Agent Skills 的其他助手使用。
它解决的不是“再做一个排行榜”
Eval Skills 并不试图训练基础模型，也不提供脱离业务的万能质量分数。它要求团队从一个真实执行开始：先看完整 Trace，确认发生了什么，再由领域人员判断什么结果才算正确。Agent 可以整理证据、聚类失败和实现检查，但不能替人定义产品质量。
官方给出的工作流可以概括为六步：
- 检查证据：复用生产流量、Trace、数据集和已有评测，必要时先捕获一次真实执行。
- 审阅样本：抽取有代表性的案例，由人记录失败表现及其影响。
- 分析错误：把标注聚类成失败模式，结合频率和影响确定优先级。
- 建立可信评测：整理可复用案例，用人工判断校准 grader，并形成可重复的基线。
- 运行 Descent：一次只验证一个改进假设，检查回归后再保留或撤销改动。
- 持续维护：把新的生产失败重新送回审阅流程，持续更新回归集。
这里最值得注意的是“先证据、后指标”。如果应用连一次完整执行都还无法解释，直接建设复杂仪表盘通常只会增加维护成本。
安装与入口
项目推荐通过 Skills CLI 安装：
npx skills add https://github.com/confident-ai/codex-eval-skills
如果使用 Claude Code，也可以把它作为插件加入：
/plugin marketplace add confident-ai/codex-eval-skills /plugin install eval-skills@eval-skills
安装完成后，项目提供多个按阶段拆分的技能。最主要的两个入口是 eval-build 和 eval-descent：前者帮助应用从当前状态走到经过审阅、拥有可信 grader 且可以运行的基线；后者围绕这条基线进行有边界的改进实验。需要更细粒度操作时，还可以使用 eval-trace 获取首个可分析的 Trace，使用 eval-error-analysis 聚类失败模式，或使用 eval-grade 检查自动判断是否与专家标注一致。
这种拆分对日常开发很有用。比如你刚接入一个 Agent，不必先搭完整评测平台，可以先让 Agent 执行一次真实请求；如果已经有大量生产 Trace，则从 eval-discover 开始做样本审阅；如果已有评测但总分可疑，则优先审计原始结果、错误通过和错误拒绝，而不是马上优化应用。
三种运行方式与一个关键边界
README 将运行方式分成三类：完全托管、使用本地评审界面但采用托管 grader，以及完全本地构建。完全托管适合希望减少自定义工具维护的团队；本地模式则更便于控制评审界面、存储、运行器和 grader 配置。即使评审与编排在本地，基于模型的 grader 仍可能调用外部服务，因此凭证、数据脱敏和网络边界仍要单独规划。
更重要的边界是：评测技能不能替团队回答“什么是好结果”。它可以把失败证据整理得更清楚，却不能凭空提供领域标准。对于支付、客服、代码修改等场景，仍应由产品和工程人员先写出可观察的验收条件，再让 Agent 帮忙生成案例、检查结果并维护回归集。
实践建议：把评测当作开发闭环
一个低成本的落地顺序是：先选一个用户真实可感知的 AI 功能，保存一次完整 Trace；再人工审阅少量正常和失败案例，写出失败模式；随后只建立一个小型、可重复的评测集。每次修改 Prompt、工具描述或模型配置时，固定使用同一批案例，对比 grader 版本和原始结果，确认改进没有把错误转移到另一个类别。
Eval Skills 的价值不在于“自动替你打分”，而在于把评测过程变成 Agent 能执行、开发者能检查、团队能复用的工作流。对于已经拥有 Trace、但仍靠截图和主观印象排查问题的 AI 应用，它提供了一条从失败证据走向可验证迭代的实用路径。