Agent 上线后怎么不退化？回归测试与持续评测全流程

最隐蔽的事故：静默退化

Agent 最可怕的问题不是崩溃，而是静默退化。你优化了一个提示词、把模型从 A 换成 B、给工具加了个参数——没人报错，但某个场景下的表现从 90 分掉到了 60 分。

更糟的是，你两周后才发现，而且不知道是哪次改动造成的。

根因很简单：Agent 是非确定性系统，改一处可能影响全局，而你如果没有回归测试，就只能靠用户投诉来发现问题。

回归测试和普通测试的区别

普通单元测试是”输入 A → 期望精确输出 B”。但 Agent 的输出是自然语言，没有唯一正确答案。

所以 Agent 回归测试的做法是：

• 准备一批代表性问题（覆盖核心场景 + 已知边界）
• 每次改动后批量跑一遍
• 用评分器（规则 / 模型裁判 / 人工）打分
• 对比新旧分数的变化

核心不是”对不对”，而是”有没有变差”。

第一步：造黄金测试集

这是最重要也最费功夫的一步。原则：

• 从真实流量里抽，而不是自己编问题
• 覆盖分级：高频核心场景 60%、边界 25%、已知历史 bug 15%
• 每道题都有人工标注的”期望要点”（不是精确答案）
• 规模起步 50 条，够用再扩

历史 bug 一定要进测试集，否则改着改着又把它改回来了——这叫回归，也是这类测试命名的由来。

第二步：选对评分器

三类评分器，按场景混用：

• 规则评分：格式、关键词、工具调用是否成功、是否超时。便宜、稳定，优先用。
• 模型裁判：用强模型判断答案是否满足”期望要点”。处理开放性问题，但要注意裁判自身有偏差和波动。
• 人工评分：抽 5%–10% 复核，用来校准模型裁判。

关键技巧：模型裁判的提示词也要版本化。裁判提示词一改，历史分数就不可比了。

第三步：接入 CI

回归测试只有自动化才有价值。每次提交 / PR 自动跑：

• 分数低于基线阈值 → 直接卡住合并
• 分数变化超出波动范围 → 标记人工复核
• 单条用例从通过变失败 → 高亮具体是哪条

把它做成一道质量闸门，才能阻止退化进入生产。

第四步：处理”合理波动”

LLM 输出天然有波动，同一输入两次结果可能不同。解决办法：

• 每道题跑 3–5 次取统计值（比如通过率），而不是单次
• 建立分数分布基线，判断变化是噪声还是真实退化
• 温度调低的任务，波动小，可用单次；创造性任务必须多次

不做多重采样，你会把噪声当成退化，天天虚惊。

一个务实的落地顺序

1. 先抽 30 条核心场景，手写期望要点
2. 用规则 + 模型裁判跑起来
3. 记录基线分数
4. 接进 CI，设阈值卡口
5. 每周把线上发现的 bad case 补进测试集

常见坑

• 测试集从不更新：线上问题不断，测试集还停留在半年前 → 形同虚设
• 模型裁判提示词随手改：历史分数全失效
• 只跑单次：把波动误判成退化
• 只看总分：掩盖了某个场景的严重退化 → 要按场景分组看

一句话总结

Agent 上线不是终点，持续评测才是。用真实流量造黄金测试集，用规则 + 模型裁判做评分，用 CI 设质量闸门。没有回归测试的 Agent，等于开着一辆没有刹车的车在升级。