Agent 测试分数很漂亮，上线就翻车？Anthropic 给出自动化评估与调优方案|agent|工作流|拟合|新模型|算法|自动化

测试满分≠线上能用！Anthropic 这套工具解决 Agent 调优的自欺欺人
拆解 Claude 全新 skill：一键构建评估集 + 自动爬山调优，规避 Agent 过拟合

2026年，AI Agent已经走过Demo秀肌肉的阶段，大规模落地成为行业主旋律。不少企业已经意识到，Agent能不能真正跑通业务，不完全取决于基座模型有多强，评估与迭代调优工程能力，才是拉开项目差距的关键。

现在一个非常普遍的行业困境是：本地跑基准测试分数很漂亮，一上线真实业务就频繁翻车；拼命修改提示词、调整Agent调度逻辑，刷高了评估集得分，结果却是典型的过拟合，线上效果毫无改善。

很多Agent试点项目止步于原型阶段，并非模型能力不够，而是缺少一套科学可自动化的评估、迭代闭环。

做Agent大家都懂要做评估，但怎么做靠谱的评估？迭代优化的时候如何规避“为测试集量身打补丁”的陷阱？怎样在提升性能的同时把运行成本打下来？

这几天，Anthropic发表了一篇名为《Automating eval design and hillclimbing with Claude》的博客文章，基于其claude‑api skill工具链，给出了一套完整可落地的工程解法，把评估设计、爬山调优全部做成自动化工作流，把行业大量踩坑沉淀出来的原则直接封装进命令。

王吉伟频道翻译了此文，帮助大家学习与理解这套“自动化评估与爬山调优”方法论与工程实践。公众号主页回复：Automating，获取该文以及文中提及的相关文章的中、英版本。

以下是正文。

利用 Claude 实现评估设计与爬山算法的自动化 Automating eval design and hillclimbing with Claude 设计评估和对抗它们的原则，而不自欺欺人，以及 claude-api 技能中构建评估和爬坡命令如何发挥作用。

作者：Lance Martin
日期：2026.09.28

评估能够反馈应用或专项能力在各类任务上的实际表现。但设计评估方案，并且在评估的基础上迭代优化性能、同时规避自欺式刷分，这件事并不简单。我们已在claude‑api skill（链接见文末）中补充了上述两项工作的实操指引。

借助该技能，你可以在代码库内部构建评估，使用/claude‑api build‑eval命令；也可以运行/claude‑api hillclimb命令，针对评估结果迭代优化应用。该过程会保留一组独立样本集，以此检测过拟合问题。

本文将首先介绍高质量评估设计与爬山调优的核心原则，随后说明Claude Code如何结合该技能落地这些原则，最后展示若干命令实操示例。

评估设计 EVAL DESIGN

一套设计完备的评估体系通常具备四项特征（图1）：

评估任务与生产环境对齐。选取测试任务时，应当模拟实际生产环境，也就是这套能力或应用的真实使用场景。部分任务之所以被选中，仅仅是因为样本容易生成、打分便捷。但必须保证任务分布能够真实反映业务的核心诉求。
模型能力与思考投入越高，性能应当随之提升。能力更强的模型、更高的思考投入，通常应当取得更优评估结果。如果不满足该规律，往往是任务描述存在歧义，或是打分器校准异常，从而拖累评估表现。
前沿模型仍具备可提升空间。即便是当前性能最强的模型，开启最高等级思考模式，评估得分也应当显著低于满分。否则就无法可靠判断改动是否真正带来性能收益。需要特别注意：该性能缺口不能源于无解或存在歧义的任务。一个典型信号是：无论重复运行多少次，某一任务始终失败。合格的测试任务应当满足：两名领域专家对该任务可以得出一致结论，打分器校验的全部条件，都已在任务描述中明确写明。
多次运行结果方差较低。结果波动大，往往源于任务定义模糊，或是打分器针对同一输出给出不一致的评判。配置层面同样会引入波动，例如思考强度参数未稳定生效。此外环境因素也会干扰评估结果：上一轮测试遗留的文件、Git历史记录，都有可能直接向智能体泄露答案。

FIG 1 一次优质评估的四大要素 The four elements of a good eval 对抗采样问题 Adversarial sampling

模型能力分布并非平滑均匀。如果专门选取当前模型的失败案例构建评估，本质是在采样该模型能力曲面的低谷（图2）。最终这套评估衡量的就不再是业务本身固有的难点与业务价值，而只是该模型特有的失效模式。

_FIG 2 Adversarial sampling 对抗采样

选取困难案例的依据，应当是人工判定该任务本身具备难度。纳入评估之前，需要能够清晰说明任务的难点所在。也可以收录来源于生产日志、缺陷报告、工单反馈中真实出现的应用故障案例。但不可完全采信用户流量数据：用户往往只会尝试他们预期能够正常运行的请求，完全基于用户流量生成的任务分布，难度会整体偏低。

/CLAUDE‑API BUILD‑EVAL

claude‑api技能中的该命令，将上述评估设计原则转化为一套引导式工作流。在Claude Code中执行/claude‑api build‑eval后，Claude会与你交互，在代码库中生成评估工程，并在关键节点暂停，等待你的确认。

设计评估样例 Designing examples

Claude会按照如下优先级，协助你选取评估输入样本：

生产会话记录（执行前会确认数据留存策略与敏感数据相关约束）
缺陷报告与技术支持工单
由使用者手动编写的5‑10个案例
基于代码库合成生成的案例

该技能优先使用生产流量样本；若真实样本不足，则会基于你提供的少量真实示例生成合成数据。技能会生成简易页面展示全部输入用例，等待你确认。下图为邮件路由应用评估输入样例的演示（图3）。

FIG 3 由该技能生成的示例输入审查 Example inputs review generated by the skill

校验打分器 Validating the grader

确定输入用例后，Claude会匹配适配业务输出、成本最优的打分方案：

程序化校验：当输出取值范围有限时，采用代码校验方式，例如精确匹配、从固定集合选取标签、校验JSON是否符合预设Schema、单元测试是否通过。
大模型充当裁判：当输出空间开放，存在多种有效答案但具备清晰质量标准时，默认使用该方案。由另一独立模型读取输入、模型输出，以及一套可逐条核验的评分标准（不使用1‑5分这类分级量表），输出分数与推理过程。如果存在基线版本，裁判会将基线输出与待评估输出随机打乱顺序，在不知道哪一份为基线的前提下选出更优结果。裁判模型需要手动指定，不可使用待测试的同一模型

Claude会先对小批量用例执行打分，并询问你是否对部分打分结果持有异议（图4）。在采信评估器结果前，务必抽样阅读打分完成的会话记录（这里链接了一篇有关AI Agents评估的博文，见文末）；打分逻辑出错，是评估配置失效最常见的诱因。

打分器完成校验后，技能会告知评估集规模（用例数量 × 重复次数 × 模型数量）以及预估运行时长，运行基线版本，输出附带置信区间的基线分数。最终交付产物包含：全部测试用例、打分器、评估执行脚本；每个用例对应一行JSON记录以及完整会话记录；网页页面列出每条用例得分，附带会话记录跳转链接。如果你需要图表等额外内容，可直接告知Claude，它会生成附加静态页面，本地打开，无需加载任何网络资源。

FIG 4 各输入项附带推荐评分的结果页面示意图 Schematic of the results page generated with suggested grades for each input. 诊断检查 Diagnostic checks

在基线运行阶段，Claude会自动完成多项校验：

打分器校验：将同一输出交由打分器重复打分，检测评判结果是否发生变化。
链路校验：检测超时、API报错、输出截断，避免基础设施层面的问题被误判为模型性能波动。
性能余量检测：若基线得分已经达到95%及以上，技能将发出告警，提示爬山调优应当将目标转向降低成本、降低延迟，而非提升质量。

爬山调优 Hillclimbing

拥有一套可靠的任务打分体系之后，就可以着手优化应用。爬山调优非常适合对思考强度、提示词这类参数进行调优，权衡成本与性能。选择调优对象时可参考以下通用建议：

迭代成本低廉：调优对象的修改、回滚成本应当较低。大量内部项目与客户都聚焦文本类对象，例如提示词、技能指令。这类内容修改与回滚都十分便捷。与之相对，如果在爬山调优过程中对智能体调度框架做开放式修改，往往会产生大量代码改动，并不适合该方案。
效果具备可归因性：评估分数的变化，应当能够明确归因于爬山调优正在修改的对象。部分落地效果较好的实践聚焦技能触发逻辑：评估指标即技能触发率，指标与被修改的技能描述直接耦合。
目标范围清晰收敛：一种常见失败模式是提出开放式需求，笼统要求提升性能，却忽略评估集的性能余量。评估分数接近饱和，或是调优对象范围界定模糊（例如无边界要求更新调度框架），迭代流程极易陷入停滞。即便评估性能已经触达上限，也依然有一个非常实用的优化目标：在保持性能水平不变的前提下降低成本。

过拟合问题 Overfitting

即便是经过精心设计的评估集，也很难完全复刻生产环境真实任务分布。因此，对评估集过拟合是一类普遍问题：系统在评估集表现大幅提升，但在真实生产流量上性能没有改善。

评估集的信息会以多种方式泄露到调度层（包含提示词、工具、模型调用循环在内的整套模型周边代码）。举个例子：某评估任务依赖OCR能力，但OCR在生产任务中极少发挥作用。为了提升评估得分，调度层新增OCR工具，评估指标得到改善，但不会给线上业务带来收益。

更普遍的情况是：爬山调优为评估用例中的边缘特例，向调度层新增各类逻辑，拉高评估分数，但这些改动无法迁移到生产环境（图5）。

FIG 5 线束过配合的常见原因 Common causes of harness overfitting.

应对该问题有三项核心手段：

数据集拆分：划分可供爬山调优程序读取的训练集，以及完全隔离的测试集。当训练集得分上涨，但测试集得分保持不变，就是典型的过拟合信号。
禁止将失败样例直接粘贴至提示词：即便爬山调优程序可以读取失败会话记录，也不允许将失败样例直接写入提示词。
架构层面隔离参考答案：防止模型通过投机取巧的方式直接获取评估答案刷分。

claude‑api技能会自动落实以上原则。

/CLAUDE-API 爬山调优 /CLAUDE‑API HILLCLIMB

claude‑api技能中的hillclimb命令，将上述原则封装为引导式工作流。在Claude Code中执行/claude‑api hillclimb，Claude会迭代优化，面向指定评估集提升效果。你可以限定允许修改的范围，包括：

系统提示词
技能与指令文件
工具描述
模型选型、思考强度以及其余API参数
调度层代码

正式启动前，Claude会确认你的优化目标（例如提升性能，或是维持性能前提下降低成本），随后将评估样本随机拆分为测试集与训练集。如果优化目标为降本（这里链接了一篇降低成本并提升性能的博文，链接见文末），工具会综合多项成本影响因素，包括提示词缓存、校验提示词与所选模型的兼容性、模型与思考强度选型。

首轮迭代开始前，Claude会测算评估体系本身的噪声水平（仅由随机因素就可以造成多大分数浮动）。如果噪声幅度高于你预期的最小有效提升幅度，工具会明确提示，并建议增加用例数量或重复运行次数。

每一轮迭代流程：Claude读取上一轮训练集的失败会话，以补丁diff的形式提出一处修改。每一轮改动力求效果能够显著高于评估噪声；优先从根源修复失效行为（重写存在缺陷的逻辑片段，补充缺失规则），而非仅做措辞改写。

完成补丁修改后重新运行评估。随后执行校验逻辑：如果训练集得分提升，但测试集得分无变化，则判定为过拟合，回滚补丁；如果出现性能倒退，同样执行回滚；只有训练集与测试集同步提升，才保留本次补丁（图6）。

FIG 6 爬山算法所使用的流程 The process used by the hillclimber.

当连续两到三轮分数不再提升，Claude会读取训练集剩余全部失败样例，按照根因分类。如果潜在收益小于评估噪声，工具不会继续迭代，而是建议扩充用例或增加重复运行次数。该步骤能够识别歧义测试用例、调度层故障、运行波动。只有真实业务故障，才会进入后续爬山迭代。

爬山调优全部完成后，代码版本将停留在测试集表现最优的版本，输出对比基线的测试结果与置信区间（图7）。如果性能增益落在噪声区间内，工具会给出明确提示，不建议合并该版本。

FIG 7 爬山法生成的报告示意图 Schematic of the report generated following hillclimbing. 示例 EXAMPLES 以降低成本为目标的爬山调优 Hillclimbing for cost reduction

我们针对一套内部客户支持基准（链接见文末）测试集执行/claude‑api hillclimb，优化目标为降低成本同时改善性能。该基准共44条工单，30条作为训练集，14条作为隔离测试集。基线配置为Opus 4.8，默认高思考强度，训练集决策准确率74.4%，单工单token成本4.6美分。

爬山调优首先审计提示词，移除强制工具调用流程、草稿步骤，删除互相矛盾的规则。随后尝试Opus 5.5搭配低思考强度。该配置达到性能基线，准确率87.8%，单工单成本降至1.9美分，不足原先的一半。

成本下降一部分来源于Opus 5.5定价（相关链接见文末）：输入、输出token价格较Opus4.8降低20%，缓存读取成本下降60%。在确认Opus5.5满足性能门槛后，爬山调优继续向下测试更低成本模型。Sonnet5开启低思考强度，准确率88.9%，性能基本持平，单工单成本进一步下降至1美分（图8）。

FIG 8 成本优先爬山算法 Cost‑focused hillclimbing.

最后Claude优化提示词，补充路由规则、退款上限交叉校验逻辑，Sonnet5准确率提升至98.9%，成本基本不变。针对调优全程未见过的14条隔离工单，最终配置得分90.5%；原始基线得分78.6%，整体成本仅为原来的五分之一。

以提升性能为目标的爬山调优 Hillclimbing for performance improvement

另一个案例为claude‑api技能本身，该技能提供API使用指引与Claude开发通用建议，包含本文提到的子命令。我们希望该技能可以输出正确调用API的业务代码，基于官方文档构建评估集。

评估基线通过率为66%。我们向爬山调优程序开放文档与SDK访问权限，使其定位并且自行修复缺陷（图9）。工具发现技能缺失8项能力说明。

在技能文档中补齐对应内容后，性能提升至74%；随后定位C#、Java类型表格存在错误，修复后性能达到77%。

FIG 9 侧重性能的爬山算法 Performance‑focused hillclimbing.

连续两轮分数停滞之后，Claude对剩余失败样例做根因归类。普通迭代会针对最高频故障执行一次修改；该阶段不做代码变更，仅对全部剩余失败做原因梳理。该复盘步骤带来多处关键发现：

综合全部失败样例可以看出，技能文档已经具备对应内容，但Claude依然会输出训练阶段记忆的旧版API格式。为了解决该问题，爬山调优在技能文档顶部新增对照表，引导模型从旧写法迁移至当前API：例如将已经被新版Opus废弃的固定token预算深度思考切换为自适应思考；Web搜索、网页抓取工具同样完成新旧版本映射。同时将C#、Java中固定预算思考的风险提示挪至示例之前。本次改动将性能提升至80%。

部分用例无论如何迭代，性能始终没有改善，这代表用例本身或者打分器存在缺陷。例如某任务要求捕获一类错误，但打分器却强制要求至少三层异常调用链。Claude改写任务描述。另有一处打分规则和官方文档冲突，通过真实API测试确认文档描述正确。修正以上问题，再迭代技能内容，最终评估通过率接近88%。

快速上手

你可以在Claude Code中直接通过claude‑api skill 调用以上子命令：

运行/claude‑api build‑eval，为你的业务场景生成评估集。你可以提供样例（例如运行追踪日志）来约束生成方向。Claude将遵循本文所述原则生成用例与打分器，关键环节等待人工确认。

运行/claude‑api hillclimb：当你已经具备评估集，可以执行该命令，设定优化目标（提升性能，或保性能前提下降低成本）。迭代过程自动防范过拟合；在首轮迭代以及分数停滞时，检测打分器缺陷、调度层故障等评估本身存在的问题，同时完成噪声校验。

致谢：感谢Misha Khalman完成该技能开发；感谢Misha Khalman、Michael Segner、Matt Bell、Matt Thanabalan提供审阅、内容贡献以及产品支持。

后记：工程方法论产品化

Agent开发有一句很实在的话：构建Agent不难，把Agent迭代变好才难。

过去，设计评估集、做调优迭代，高度依赖工程师个人经验。评估样本随便凑、打分逻辑粗糙、迭代不做隔离测试，最后就会造出一堆“测试满分、上线残废”的AI应用。

Anthropic这套工具最大的价值，不只是提供两条便捷指令，而是把一整套工程方法论产品化：告诉开发者该怎么构建贴合生产业务的评估、怎么识别打分器的漏洞、如何用训练‑测试集拆分对抗过拟合，同时兼顾性能提升与成本优化。

当然工具只是载体，底层逻辑不会变：评估样本要源于真实业务，调优不能脱离生产目标，分数只是参考，线上业务价值才是最终标尺。无论是做企业客服Agent、代码开发Agent，还是各类垂直业务智能体，这套评估‑调优的思路都可以复用。

随着Agent落地走向深水区，未来企业之间比拼的，早已不是能不能快速写出一个Agent原型，而是有没有成熟的评估治理、自动化迭代体系。谁能把评估闭环做扎实，谁的Agent才能够从Demo真正走向生产环境。

claude-api skill：https://github.com/anthropics/skills/tree/main/skills/claude-api
揭秘 AI 智能体评估体系 Demystifying evals for AI agents：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
一些常见的成本驱动因素 a few common cost drivers：https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform
内部客户支持基准 internal customer support benchmark：https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform
借助 Claude 平台降本增效 Reducing cost and improving performance with Claude Platform：https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform
充分发挥 Claude 与 Claude Code 中 Opus 5.5 的能力 Getting the most out of Opus 5.5 in Claude and Claude Code ：https://claude.dev/blog/getting-the-most-out-of-opus-5-5/

看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，也可以给个星标，你的支持就是我的动力。

全文完

王吉伟频道图书《一本书讲透Agentic AI》已出版，完整构建Agentic AI在企业应用中的全景式知识体系，内容跨越 “基础认知-技术原理-业务应用-组织战略-实操指南” 五大板块，为读者提供从认知共识、技术解构、业务对接到组织变革的端到端路线图，欢迎大家关注。

【赠书福利进行中】

感谢大家的长期关注与支持。欢迎小伙伴们在文末留言与转发，王吉伟频道会随机选取读者，《一本书讲透Agentic AI》包邮到家。

【文末福利1 】：后台发消息研报2026，获取15篇 2026年 AI Agent研报。