Agent回归评测配置：用固定用例集防止改坏已有能力
Agent 改一次 prompt 或换一个模型，原本能完成的任务可能悄悄失败。
回归评测配置要解决的就是这个问题：把核心任务固化成可重复执行的用例集，每次改动后自动跑一遍，用统一标准判定通过或失败，出现退化就拦住上线。
先明确评测范围和判定标准
回归评测不是把所有对话都存下来重放，而是挑出业务上不能坏的能力。
配置前先做两件事：
- 列出核心场景，例如“查询订单状态”“按条件筛选商品”“拒绝越权操作”，每个场景写 3 到 5 条典型输入，覆盖正常路径和边界情况。
- 为每条用例确定判定方式。Agent 输出是自然语言，不能直接字符串比对，常见做法有三种：精确匹配关键字段、用规则检查必须包含或禁止出现的内容、用另一个模型按评分标准打分。
新手容易把判定标准写得太宽，比如“回答看起来合理就算过”，这样回归评测失去意义。
建议每条用例至少有一个确定性检查点，例如工具调用参数是否正确、最终答案是否包含订单号、是否拒绝执行删除操作。
用例文件建议用 JSON 或 YAML 管理，和代码一起提交到版本库。
一个最小用例结构如下：
{
"id": "order_status_001",
"input": "帮我查一下订单 A1024 到哪了",
"expect": {
"must_contain": ["A1024"],
"must_not_contain": ["无法查询"],
"tool_calls": ["get_order_status"]
}
}搭建可重复执行的评测入口
评测脚本要能独立运行，不依赖手动点击。
下面是一个 Python 示例，思路是读取用例、调用 Agent、按规则判定并输出汇总。
实际接入时把 run_agent 替换成你的 Agent 调用逻辑即可。
import json
def check_case(case, answer):
expect = case["expect"]
for word in expect.get("must_contain", []):
if word not in answer:
return False, f"缺少关键词: {word}"
for word in expect.get("must_not_contain", []):
if word in answer:
return False, f"出现禁止内容: {word}"
return True, "ok"
def main():
with open("cases.json", encoding="utf-8") as f:
cases = json.load(f)
failed = []
for case in cases:
answer = run_agent(case["input"])
ok, reason = check_case(case, answer)
if not ok:
failed.append((case["id"], reason))
print(f"共 {len(cases)} 条，失败 {len(failed)} 条")
for case_id, reason in failed:
print(case_id, reason)
return 1 if failed else 0
if __name__ == "__main__":
raise SystemExit(main())运行命令：
python eval_agent.py退出码为 0 表示全部通过，非 0 表示存在失败用例。
把这个命令放进 CI 流水线，每次提交代码或修改 prompt 后自动执行，失败就阻断合并。
结果对比与退化定位
只看通过率不够，还要知道哪条用例退化、退化原因是什么。
建议每次评测输出一份结构化结果文件，包含用例 ID、通过状态、失败原因和 Agent 原始输出。
对比两次结果时重点看：
- 新增失败用例集中在哪个场景，是否和本次改动相关。
- 原本通过的用例变成失败，属于明确退化，必须处理。
- 原本失败的用例变成通过，确认不是判定规则被放宽导致的假通过。
如果使用模型打分，要固定打分模型和评分提示词，并保留每次的评分理由。
打分模型本身升级也会改变结果，这一点在排查退化时要考虑进去。
常见坑与验证方式
配置回归评测最容易踩的坑是用例和判定标准一起改。
改 prompt 的同时顺手放宽了检查条件，评测永远通过，但线上质量在下降。
正确做法是先固定评测集，再改 Agent，对比结果。
另一个坑是评测环境不稳定，比如工具接口超时导致用例失败。
评测脚本应区分“Agent 回答错误”和“环境调用失败”，后者重试或标记为跳过，不要混进通过率。
验证配置是否有效，可以故意把某条用例的预期答案改错，跑一次确认脚本能报失败；
再恢复原样，确认全部通过。
这一正一反两次运行能证明评测链路真正在工作。
最后提醒：回归评测覆盖的是已知场景，不能替代线上监控。
用例集要随着业务迭代补充，每出现一次线上问题，就把它沉淀成一条新用例，评测集才会越来越贴近真实风险。
