自动优化 Agent，首先需要一套值得相信的评测。否则，迭代越快，越可能把系统推向错误目标。这篇文章把工作分成两部分：用 /claude-api build-eval 建立评测，再用 /claude-api hillclimb 搜索更好的提示词、模型配置或执行方式。
下面按“如何判断评测可靠、如何执行优化、如何解释结果”梳理方法，保留原文 9 张图及关键实验数据。图下的阅读提示和文末的方法边界为本站编辑解读。
一、评测要先过哪些检查？
作者提出的四个观察角度，可以整理成一张诊断表：
| 检查项 | 应当看到什么 | 异常时优先排查 |
|---|---|---|
| 任务代表性 | 覆盖真实业务关心的问题 | 是否只选了容易生成、容易评分的题目 |
| 能力与得分的关系 | 更强模型、更多思考通常带来更好表现 | 题意是否含糊，评分器是否误判 |
| 有效提升空间 | 最强配置仍有可解决的失败 | 任务是否不可能完成，评分要求是否未写进题目 |
| 运行稳定性 | 重复运行的波动足够小 | 评分一致性、effort 配置、环境残留及基础设施错误 |
图 1｜可靠评测的四个观察角度。读图时同时看曲线走势、距满分的差距和误差条：单看最高分，无法判断一套评测是否适合做优化。
还有一个容易忽略的偏差：只收集当前模型做错的题目，会过度关注这个模型特有的弱点。选题应结合人工难度判断、真实故障和业务价值。线上流量也不天然完整，因为用户可能只尝试自己认为能成功的功能。
图 2｜两种采样方式。左图集中选择当前模型能力曲线的低谷；右图依据人的难度判断选题。重点是让评测覆盖有价值的问题，而非只针对一个模型的失败模式。
二、build-eval 如何把想法变成可用评测？
先审输入，再审评分
样例来源有优先级：生产交互记录、缺陷与支持工单、少量人工编写案例，最后才是根据代码库合成的任务。使用生产记录前，需要明确数据留存和敏感信息要求；合成样例也应以真实业务为依据。
生成后先逐项审阅，确认输入具有代表性。图 3 展示的邮件分流评测有 24 个输入，标签帮助人检查任务类型和难度覆盖。这一步需要用户确认，而不是生成完就直接开跑。
图 3｜输入审阅页。它解决的是“测什么”的问题，先于“得多少分”。
评分方式应与输出类型匹配。固定标签、JSON 结构、测试结果等，优先用代码验证；开放式答案可以让另一个模型依据可核查标准评分，并给出理由。做两两比较时，应隐藏基线身份并随机排列顺序；评委模型也应与被测模型分开。
人还需要检查一批已评分的完整记录，确认评分器的判断符合预期。之后再估算案例数、重复次数、模型数与运行成本，执行基线，报告置信区间。
图 4｜结果与执行记录相连。原图中的基线均值为 0.681；逐案例得分可以继续追溯到每次运行的 JSON 记录。总分负责概括，记录负责解释。
实际交付物包括样例、评分器、运行器、逐案例 JSON、完整交互记录和结果页。运行时还应检查同一输出重复评分是否一致，排除超时、API 错误和回答截断。如果基线已在约 95% 以上，应考虑把目标转向成本或延迟。
三、hillclimb 怎样避免越改越偏？
先限定目标和修改范围
提示词、Skill 说明和工具描述容易试验与撤销，也更容易把结果变化归因到具体改动。模型、effort 和其他 API 参数同样可以优化；允许修改执行框架代码时，则要更加明确范围。
目标最好可以直接验证，例如“质量不下降时降低成本”。开始前，还要确认评测噪声小于值得采取行动的最小收益；否则先增加样例或重复次数。
留出集用于检查泛化
训练集允许优化器查看失败记录，留出测试集的具体样例则不开放。这里的“训练”指搜索配置与改动，并不意味着训练模型权重。不要把失败案例原样写进提示词，也要防止模型从文件或仓库直接获得参考答案。
图 5｜框架过拟合的不同路径。为了评测添加专用 OCR 工具、硬编码目录命令、针对特定措辞打补丁，都可能让分数提高，却没有改善真实业务；直接获取参考答案则属于更明显的泄漏。
每轮提出一项有明确原因的改动，再检查训练集与测试集。如果只改善训练集而测试集停滞，应警惕过拟合并撤销；发生退步也应回退。原文的质量优化流程会保留两侧都改善的版本。
图 6｜“分析失败—提出补丁—运行评测—决定保留或回退”的循环。分析器读取的是训练集失败，测试集提供独立的表现反馈。
连续两三轮无进展时，先对失败按根因分类，分清能力不足、题目含糊、评分器错误和环境问题；如果收益小到无法测出，也应暂停微调、改善测量条件。最终报告需要比较基线和选定版本，并展示不确定性；噪声范围内的上涨不足以支持合并。
图 7｜版本比较报告。示例中 v1 的训练集与测试集均为 0.875；v2 加入完整示例后只改善训练集，因此被撤销。更多提示内容不保证更好的泛化。
四、两个案例里，究竟改善了什么？
客服任务：把质量和成本一起看
原文使用 44 张工单，其中 30 张用于搜索，14 张留出。搜索阶段的主要结果如下；这些数字不能与留出集成绩混为一谈。
| 搜索阶段配置 | 准确率 | 每张工单的 token 成本 |
|---|---|---|
| Opus 4.8，high effort 基线 | 74.4% | 4.6 美分 |
| 清理提示词后使用 Opus 5.5，low effort | 87.8% | 1.9 美分 |
| Sonnet 5，low effort | 88.9% | 约 1 美分 |
| Sonnet 5，进一步完善提示词 | 98.9% | 仍约 1 美分 |
提示词清理涉及强制工具调用、冗余推演步骤和矛盾规则；后续又完善分流与退款上限规则。降本也有定价因素：文中称 Opus 5.5 相比 Opus 4.8，输入、输出 token 单价低 20%，缓存读取低 60%。
图 8｜搜索阶段的成本—准确率路径。模型、effort、提示词和价格共同变化，不能把全部收益归因于某一个因素。
最终在 14 张留出工单上，准确率从 78.6% 提高到 90.5%，成本约为原来的五分之一。这组留出结果，比搜索阶段接近满分的数字更值得关注；它仍然只是该工作负载的实验结果。
API Skill：既修说明，也检查测量工具
第二个案例优化 claude-api Skill。得分从约 66% 起步，补足八项功能说明后达到 74%，修正 C# 与 Java 类型表后达到 77%。
进一步分析发现，有些说明虽然存在，模型仍会沿用旧 API 写法。增加新旧写法对照、调整提醒位置后，分数升至 80%。这说明文档的组织方式与纠错提示，可能和信息是否齐全一样重要。
图 9｜多轮优化的阶段变化。曲线从 66.1% 到第 24 轮的 87.9%；正文使用了取整后的数字。末段同时包含评分器修正与 Skill 改动。
剩余失败中，有任务要求与评分条件不一致，也有评分器与真实 API 行为冲突。修正这些问题并继续完善 Skill 后，最终得分约为 88%。因此，整条曲线同时记录了应用改进和测量修正，不能视为固定评测下的纯能力增长。
五、开始使用，以及结果的边界
在 Claude Code 中，/claude-api build-eval 适合从业务问题和真实样例出发搭建评测；已有可信评测后，再用 /claude-api hillclimb 按质量或成本目标迭代。工具说明位于 claude-api Skill 仓库。
编辑补充：反复根据同一留出集选择版本，仍可能逐渐适应这个集合。正式决策时，可以再用一组未参与选择的新样例复核。若修改了题目或评分器，也应在修正后的评测上重新运行基线，保证前后可比。
全文与全部原图来源：Lance Martin，Automating eval design and hillclimbing with Claude。文中百分比、模型配置与费用均为原文报告的数据。