给 Agent 做版本回归测试先固定任务集、验收规则和可控制的环境让新旧配置逐题对照。先看修好了什么、退步在哪里再看耗时、费用和人工投入是否符合预先约定的采用条件。总通过率提高是打开结果清单的起点。改了一段提示词原来漏掉的筛选条件终于被执行换了一个模型总通过率也提高了。现在要回答的是这套新配置能不能替换旧版下面以“读取订单文件汇总已付款金额并生成结果文件”为例给出一套可以照着准备的回归检查流程。本文全部任务、编号、数字和结果均为构造示例不对应 EvalDock 或任何产品的实测。1. 先写清采用条件再开始运行订单任务除了金额算对还要求金额缺失时列出异常、原始输入文件保留。假设这次修改是为了修复“把未付款订单也计入总额”。运行前先填一张约定表项目本例的检查要求目标改善混有未付款订单时只汇总已付款金额原有能力普通汇总仍正确金额缺失仍按约定列出异常关键要求原文件不能被覆盖确认出现即暂停替换并排查可接受代价提前填写耗时、调用费用、人工协助的上限改动范围记录模型、提示词、工具、权限、重试策略的全部差异如果同时换模型、改提示词结论只针对这套新配置。要归因到其中一项需要拆开再做对照。资源上限应来自实际工作需要。例如交互查询关心等待时间定期批量汇总可能更关心总费用。不要看完结果后才为新版调整上限。2. 固定测试集修复题、原有能力、留出题都要跑只重跑刚刚修好的那道题无法发现其他能力退步。建议把任务分成三组并让两版都执行任务组订单例子本组要回答的问题修复目标已付款与未付款混合、付款状态顺序变化目标错误是否得到改善原有能力普通订单、金额缺失、原文件保留原来能做好的事情是否仍可用未用于调试的留出题事先留出的新订单文件、独立设计的边界输入改善能否延伸到没反复调试过的材料Anthropic 的 Agent 评测方法文章区分了能力评测与回归评测前者观察能否完成更难的任务后者检查过去能完成的任务是否仍然可用。本篇关注的是新旧配置比较和回归。“固定”至少要留住以下信息输入文件及校验值、任务要求、预期输出、必需检查项、环境快照、配置记录、超时和重试规则。某次任务只有全部必需检查通过才计为通过。两版每次都从干净环境开始不能让新版读到旧版的产物。数据库用相同起始快照外部服务记录执行时间与不可还原条件两版无法对齐的条件单列说明。发现验收规则有错时要用修正后的同一规则重新检查两版受影响的结果。留出题一旦参与反复调提示词就成为调试材料应记录用途变化并补充新的留出输入。三组结果分别报告不能把刻意收集的易错题通过率当成日常使用成功率。3. 逐题对照把新增失败单独列出来以下是构造的一轮结果20 个不同任务每版各执行一次两版共 40 次。任务编号仅用于说明对照方法。同一任务的新旧结果数量对照后要检查什么旧版通过新版通过12完成质量和代价是否变化旧版失败新版通过5是否命中目标问题有哪些证据旧版通过新版失败2退步的具体要求、产物及影响旧版失败新版失败1尚未解决的问题是否影响采用范围旧版通过 14/2070%新版通过 17/2085%提升15 个百分点净增加 3 个通过。这不等于“只改善了 3 道题”实际有 5 个新增通过同时有 2 个新增失败。构造示例20 个任务两版各执行一次总通过率上升时仍需逐项检查 2 个新增失败不能由净增数量直接决定替换。进一步展开两条退步记录任务旧版新版新增失败及证据检查T18原文件保留通过失败输入文件被覆盖对照运行前后校验值与写入记录T19缺失金额处理通过失败异常清单漏项核对预期异常行与实际输出这两条也是构造示例。校验值变化提示输入发生改变仍需结合文件内容和写入记录确认是否违反任务要求金额异常则要回到对应输入行核对。先确认失败判定再分析新配置的原因。按第 1 节的关键要求出现原文件被覆盖就应暂停替换。筛选错误得到修复的收益可以保留记录但不能抵消关键违规。4. 用短脚本汇总保留逐题证据下面的 Python 3 脚本只使用标准库可以直接保存为compare.py执行python3 compare.py。它用构造的布尔结果重现上表脚本不调用 Agent也不负责自动验收文件。实际使用时应把old、new替换为经过同一检查规则确认的逐题结果。fromcollectionsimportCounter# 构造示例每个任务两版各执行一次不是产品实测。# T01—T12 共同通过T13—T17 新增通过T18—T19 新增失败。old{fT{i:02d}:i12oriin(18,19)foriinrange(1,21)}new{fT{i:02d}:i17foriinrange(1,21)}ifnotoldorold.keys()!new.keys():raiseValueError(需要非空、完全相同的任务集合)ifany(type(v)isnotboolforvin[*old.values(),*new.values()]):raiseValueError(结果必须是布尔值缺失、设施异常请先单列处理)countsCounter((old[k],new[k])forkinold)labels{(True,True):共同通过,(False,True):新增通过,(True,False):新增失败,(False,False):共同失败}forpair,labelinlabels.items():ids[kforkinoldif(old[k],new[k])pair]print(f{label}:{counts[pair]}任务:{, .join(ids)or无})nlen(old)a,bsum(old.values()),sum(new.values())print(f旧版:{a}/{n}{a/n:.0%}新版:{b}/{n}{b/n:.0%})print(f变化:{(b-a)/n*100:.0f}个百分点)# 费用也是构造数据包含本轮所有成功和失败调用。forlabel,cost,passedin[(旧版,20,a),(新版,34,b)]:unitf{cost/passed:.2f}元ifpassedelse不适用零次通过print(f{label}调用总费用:{cost}元每次通过分摊费用:{unit})预期输出包含共同通过 12、新增通过 5、新增失败 2、共同失败 1旧版 70%、新版 85%、变化 15 个百分点每次通过分摊调用费用分别为 1.43 元和 2.00 元。缺失结果不能默认为失败或通过设施异常要与 Agent 任务失败区分。Agent 超时若按约定属于失败应计入结果并保留原因。需要排除或重跑时两版规则一致明确数量、理由与成本归属不能静默删掉坏结果。汇总表之外每次执行还应保留任务编号、配置、检查项及判定、产物位置、失败原因、耗时、费用、人工补充与返工记录。数字异常时可以回到原始证据而不是只剩一个通过率。5. 耗时、费用、人工投入使用同一口径先比较全部计划任务的投入再拆开成功、失败和超时。只看成功运行会漏掉失败尝试已经消耗的资源。记录项对照口径本构造示例耗时同一计时起止记录每次耗时、累计执行时间并行时批次墙钟时间另列未设定数值实际测试需补齐调用费用两版相同计费范围纳入失败和约定重试外部服务费用单列旧版 20 元新版 34 元各执行 20 次人工投入补充说明、结果检查、返工分别记录分钟数采用相同计时规则未设定数值不能记成零投入每次通过分摊调用费用全部调用费用 ÷ 通过次数零次通过时不计算旧版约 1.43 元新版 2.00 元这里的费用仍是构造数据不是产品报价。新版多完成任务但每次通过分摊的调用费用增加该指标也没有包含人工成本。缺少耗时和人工记录时就不能宣称“整体更省”。需要按真实使用频率加权时在看结果前确定任务组权重并说明依据。公开报告中的维度均分与本文按必需检查计算的任务通过率是不同指标不混成一个结果。6. 按采用条件决定下一步每题只跑一次适合发现差异还不足以证明改善稳定。可以事先为两版安排相同次数的独立运行交错执行保留全部尝试。这里的补测用于验证新旧差异是否持续不要把同一任务的多次运行当成多个不同任务也不要把临时专项补测混入原来的 20 题总表。如果实际产品允许重试两版使用相同重试规则同时报告首次执行与允许重试后的完成情况耗时费用包含全部尝试。结果接近或波动明显时继续补测要声称稳定提升还需报告不确定性并考虑同一任务多次运行的关联。观察结果采用动作目标问题改善关键要求守住代价达标在已测范围内扩大试用继续观察真实使用表现改善集中在特定任务且能可靠识别和隔离限定范围试用保留旧配置作为恢复选项总通过率提高但出现关键违规或重要退步暂停替换修复后检查受影响任务及相关能力差异不清楚或环境、资源数据不完整保留“尚不足以决定”补齐证据对本文构造案例可写成“新版修复了部分筛选问题但原文件保留要求发生退步且耗时与人工投入尚未补齐暂不替换先修复退步再按相同任务和规则回归。”下面的模板可以直接放进一次版本采用记录目标问题与预期改善 旧配置 / 新配置 / 全部改动 固定测试集版本、输入校验值与环境快照 修复目标 / 原有能力 / 留出题的数量 必需检查、关键要求、资源上限、超时与重试规则 每题计划运行次数及实际完成次数 共同通过 / 新增通过 / 新增失败 / 共同失败 新增失败对应的任务要求、产物及检查证据 全部计划任务的耗时、调用费用、人工投入及缺失项 设施异常、排除、重跑和专项补测记录 采用 / 限定试用 / 暂停 / 继续补测的理由 适用范围、后续观察与恢复安排EvalDock 的评测方法强调让任务、运行条件和证据对应优化后在相同任务、环境与评分标准下复测。EvalDock 是面向各类 Agent 的跨生态评测与选型平台结合任务过程、工具调用和交付结果为开发者提供针对性的优化方案。版本比较时把目标收益、具体退步与采用条件放在同一份记录中下一步要修什么、补测什么就更清楚。本文由 EvalDock 团队撰写。