agent自动化评测体体系如何建立

Agent 上线后最常见的坑是：改了一句提示词、换了一个模型，表现到底变好还是变坏，谁也说不清。人工点几遍不算评测，跑一遍全挂也不叫体系。这篇按「先定指标、再攒用例、然后自动化、最后让结果可信」的顺序，给出一套能落地的搭建思路和检查清单。

Agent 上线后最常见的坑是：改了一句提示词、换了一个模型，表现到底变好还是变坏，谁也说不清。人工点几遍不算评测，跑一遍全挂也不叫体系。问题往往不在 Agent 本身，而在于没有一套能复跑、能对比、能拦住回退的评测流程。

这篇按「先定指标、再攒用例、然后自动化、最后让结果可信」的顺序讲搭建思路。目标不是一次做到完美，而是先有一个能跑通的小闭环，再逐步加厚。以下是四步落地顺序和每步的检查清单。

第一步：把「好用」拆成能自动判的指标

「这个 Agent 好不好用」是没法自动判的，得拆成几层能从运行记录里直接取值的东西。建议至少覆盖三层：结果层看任务有没有完成，过程层看工具调用对不对、步数和耗时是否合理、有没有反复打转，格式层看输出结构是否合规。每一层都要能从日志里自动抽出来，抽不出来的指标先别放进跑批。

指标定义一定要写清边界条件：什么算「完成」、以什么为凭据、什么算「部分完成」。这些不写死，不同人跑出来的分数就没有可比性。另外，机器判定不了的项不要硬塞进自动跑批，转成规则校验或进人工抽检池更实际。

• 每层指标给出一个可执行的判定规则，而不是一个形容词
• 把判定规则和用例存在一起，改规则要能被评审看到
• 主观项单独列一张抽检表，按周期人工过一遍
• 指标数量先少后多，一开始只留能稳定取值的几项

第二步：攒用例集，覆盖成功路径和该失败的地方

用例的来源一般有三个方向：线上真实请求抽样、人工构造的边界与对抗样例、历史出过的问题回填。每条用例必须带期望结果和判定方式，缺判定方式的用例就是废用例，跑出来也没法用。用例数量不必一开始就大，先保证关键场景都有覆盖。

用例要按场景分组打标签，跑批时能按组出分。这样某类问题变差时，能马上定位到是哪一组在掉分，而不是只看到一个总分下滑。分组维度可以按业务场景分，也可以按难度分、按工具依赖分。

用例集还要分两份：一份固定的回归基线，长期不动，专门用来做历史对比；一份持续新增的探索集，用来发现新问题。两者混在一起，历史分数就没法比了。新发现的坑先进探索集，验证稳定后再并入基线。

第三步：把跑批接进流程，别靠人手动点

跑批程序的第一要求是输入固定、工具桩固定。外部接口要么用录制回放，要么用假数据，否则同一条用例两次结果不同，评测就失去意义。这一点比跑得快、跑得多都重要。

1. 先跑单条挑一条用例手动跑通，确认能拿到判定结果和完整调用链
2. 加护栏单条用例设步数上限和超时上限，跑飞的直接判失败并记录现场
3. 小批量跑先按一个分组跑一轮，检查报告结构是否够用
4. 产出报告按组汇总分数、与基线的差异、失败用例原样记录，能直接贴进评审
5. 挂触发手动跑稳定后，再挂到每次提示词、模型或工具配置变更之后

触发方式不要一上来就全自动。系统还没稳的时候，频繁跑批只会制造噪声；先做到「变更后手动触发一次跑批」，等结果稳定可信了再考虑自动挂载。

第四步：让结果可信，能拍板

可信的前提是处理随机性。关键用例要重复跑多次看通过率，而不是看单次结果；温度等参数在跑批时固定下来。只跑一次就下结论，是评测结果不可信最常见的来源。

另外，接入的模型或中转通道本身有波动。评测前先确认通道状态，分数异常偏低时先排查接口层面的问题，再怀疑 Agent 逻辑。通道质量可以到 /sites 看中转站的可信度信息，需要时用 /tools/speed-test 做连通性检查，避免把通道抖动当成 Agent 退化。

分数只做对比，不做绝对背书。结论要配失败样本一起看，避免出现总分涨了但关键场景更差的情况。给评测定一条止损线：低于基线多少就拦下这次变更，什么情况下允许带着已知问题上线，这些在跑批之前就写清楚，事后争议会少很多。

评测的价值不在于给出一个分数，而在于让每次变更都有据可依、能回头查。