如何判断 Agent/LLM 的改动是否真的带来了提升当输出总在变化时问题LLM 输出具有随机性non -deterministic修改 Prompt、模型或 Agent 流程后如何判断是真的变好了而不是“感觉更好了” 核心共识不要比较单次输出结果。 应当比较多次运行后的统计结果任务通过率Pass Rate历史回归案例表现Agent 执行轨迹实际业务指标 而不是依赖主观感受。 核心观点与实践1. 比较通过率而不是单次输出最常见的建议是每个测试样例运行 5~10 次。统计通过率对比不同版本之间的表现。 示例旧版本9/10 通过新版本6/10 通过 即使单次输出看起来都不错统计结果仍能揭示真实退化。2. 建立“噪声区间Noise Band”一种被广泛认可的方法对已验证版本运行 (K) 次。记录每个测试的最小值与最大值作为参考区间。新版本只有超出区间才视为真实变化。 好处 避免把随机波动误判为改进追逐不存在的问题。⚠️ 注意 小样本得到的区间只是观察到的范围并不是真实边界。3. 每个 Bug 都变成测试用例一个高赞实践Every bug becomes a test.做法 保存真实失败案例每次修改后重新回放新 Bug 不断加入测试集。优点 测试集来源于真实问题随着产品发展持续增长不容易失效stale。4. 用“已知错误配置”检测测试集是否过时一个很有启发性的观点保留曾产生问题的旧配置。定期使用当前测试集重新运行。如果旧配置仍然失败说明测试集有效如果旧配置突然通过说明测试集可能已经失效。本质上是在测试测试集本身。5. 优先使用程序化检查评价时优先使用代码验证JSON 是否合法Tool 是否调用正确 / 参数是否完整必填字段是否存在是否包含要求的事实 只有无法自动验证的部分再交给 LLM Judge。因为代码验证更便宜、更稳定、偏差更小。6. Judge Model 存在偏见讨论中认为如果评审模型与被测模型属于同一模型家族则很可能拥有相同盲点共享同类偏见。 解决方案使用两个不同模型家族作为 Judge独立运行。仅当两者指出相同问题时才高度信任。不要只让 Judge 打分而要要求其指出具体问题、给出明确阻塞项。因为“感觉有点差”基本没有价值。7. 关注执行轨迹而非最终文本真正容易发现回归的是 Agent 的行为变化。可以比较Tool 名称与参数结构Tool Call 次数与 Retry 次数是否缺少某些关键操作如 read_file 原因 输出文本会波动但 Agent 行为通常更稳定。例如多出一次 shell 调用或者少了一次文件读取往往比文本差异更能说明问题。8. 建立变更账本Ledger不要只依赖测试集。每次修改记录改了什么希望影响哪个指标最终结果如何 并在指标真正产生变化后再填写结论。这种方式关注真实业务结果而不是固定样本。9. “空白 ≠ 通过”讨论中最受认可的一句话之一Empty is unknown, never pass.某些指标需要数天甚至更久才能体现。此时没有结果 ≠ 修改成功而是 没有结果 尚未知道。因此Unknown 应当阻塞后续判断不应自动记为 Pass否则容易造成错误结论。10. 警惕评估器本身的问题有人分享了真实案例某候选方案看起来优于现有方案最后发现问题出在评分器——评分器使用了旧运行中的基线数据而非同批次对照数据。经验 对照组和实验组应同时测量先确认基线来源再解读结果。 最值得记住的几句话 Different prose is fine; updating the wrong record isnt. (文本表达不同没关系更新错记录才是真问题。) Every bug becomes a test. (每一个真实 Bug 都应该成为永久测试用例。)⏳ Empty is unknown, never pass. (空白意味着未知而不是通过。) 一句话总结评估 Agent/LLM 改进时不要看单次输出而要看重复运行后的统计结果、真实回归案例、执行轨迹和业务指标重点是不被随机性和主观感觉误导。