Agent 评测怎么做?测试开发看懂离线评测、在线巡检与归因闭环

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

摘要

Agent 越来越容易搭，但真正进入生产环境之后，难点很快就从“能不能跑”变成了“跑得对不对”。

模型升级以后效果有没有提升？ Prompt 改完会不会引入退化？ Tool 调用成功了，为什么最终结果还是错的？ 线上出现 Bad Case，到底是模型、Prompt、Skill、RAG 还是工具出了问题？

这些问题，本质上已经进入软件质量保障的范畴。

对测试开发来说，Agent 评测并不是一套完全陌生的东西。

离线评测对应回归测试，在线评测对应线上巡检，Trace 对应链路追踪，Case 归因对应缺陷定位，评测集则会逐渐成为 Agent 项目最重要的测试资产之一。

一套完整的 Agent 评测体系，可以概括成：

四个模块、三种能力、两条 Loop、一套资产。

一、Agent 越容易做，评测反而越重要

现在搭一个 Agent，门槛已经比前几年低了很多。

模型本身的指令遵循、工具调用、多步推理、长上下文能力越来越强，Agent 框架也把规划、记忆、状态管理、工具注册等能力逐渐封装起来。

一个 Agent 很快就能跑起来。

但真正进入生产环境之后，问题才开始变复杂。

比如：

• Demo 阶段效果不错，一接真实用户就大量翻车
• 小流量没问题，一扩量问题集中出现
• Prompt 改了几十版，却说不清到底有没有变好
• 模型升级后部分能力提升，部分能力却出现退化
• 线上结果错了，却不知道到底是哪一层的问题

这类问题最后都会回到一个核心：

团队缺少稳定、可重复、可量化的判断机制。

传统软件测试一直在解决同一个问题：

不是“感觉系统没问题”，而是用测试证明系统现在到底处于什么质量水平。

Agent 评测也是一样。

二、Agent 评测到底在测什么？

早期做大模型测试，很多人习惯关注最终答案：

输入问题↓模型输出↓判断答案对不对

这种方式适合简单问答，但不适合复杂 Agent。

一个真实 Agent 任务可能是：

用户输入   ↓理解意图   ↓制定计划   ↓选择 Skill   ↓调用 Tool   ↓获取外部数据   ↓处理中间结果   ↓继续推理   ↓生成最终结果

只要其中任何一步出问题，最后结果都可能失败。

所以 Agent 评测不能只关注：

最终答案对不对？

还必须关注：

Agent 是怎么完成这件事的？

这也是 Agent 评测非常关键的变化：

从答案评测，走向行为评测。

对于测试开发来说，被测对象也随之改变了。

以前主要测：

• 页面
• 接口
• 服务
• 数据库

现在还需要测试：

• Prompt
• RAG
• Memory
• Tool
• Skill
• MCP
• Workflow
• Agent 执行轨迹

三、先看全景：Agent 评测体系怎么搭？

一套完整的 Agent 评测体系，主要包括四部分：

• 离线评测
• 在线评测与在线监控
• Case 挖掘与归因
• Agent 观测基建

测试开发可以直接这样理解：

这套体系解决的其实就是三个问题：

能不能发现问题？能不能定位问题？能不能让系统持续变好？

四、两条 Loop，决定 Agent 能不能真正持续迭代

Agent 评测不是跑一次测试就结束，而应该形成两条持续运转的闭环。

第一条：Agent 迭代 Loop

线上出现 Bad Case 后，通过 Trace 做问题归因。

最终可能定位到：

• Prompt 写得不够清楚
• Skill 描述导致路由错误
• Tool 参数生成错误
• RAG 召回有问题
• 上下文丢失
• 模型能力不足

修复之后重新跑离线评测，确认核心能力没有退化，再进入下一轮上线。

这就是 Agent 自身的能力演进。

第二条：评测体系迭代 Loop

不是每个失败 Case 都是 Agent 的错。

还有两种常见情况：

第一种：评测集没覆盖。

线上出现了一个新场景，但现有评测集中根本没有类似样本。

那这个 Case 就应该进入评测集。

第二种：评测标准有问题。

Agent 的行为实际上符合用户需求，但现有 Rubric 却判定失败。

这时要修的就不是 Agent，而是评测标准。

所以评测体系本身也必须持续升级。

五、评测集，是 Agent 项目最重要的测试资产

传统测试团队长期积累的是测试用例库。

Agent 团队未来长期积累的，会是：

Eval Dataset。

一个完整的评测 Task，至少要包含：

输入+期望行为 / 参考结果+评价标准

其中评价标准一般会继续拆成：

• Metrics
• Rubric

比如测试一个“自动生成测试用例 Agent”。

如果只写：

测试用例质量要高。

这个标准没办法稳定执行。

可以继续拆成：

原本非常主观的“好不好”，就被拆成了可以执行的质量检查项。

这和测试用例设计本身没有本质区别：

把模糊需求拆成可验证条件。

六、Agent 评测集，要同时建端到端和过程评测

Agent 评测集至少要分成两类：

端到端评测集

和

过程评测集。

端到端评测

比如一个 Agent 的任务是：

根据 PRD 自动生成 Web 测试用例。

最终需要判断：

• 是否完成任务
• 核心功能是否覆盖
• 输出是否可用
• 是否符合最终交付要求

关注的是：

用户最后有没有拿到可用结果。

过程评测

继续往下拆：

PRD 解析正确率      ↓功能点提取准确率      ↓测试点覆盖率      ↓测试用例生成质量      ↓格式正确率

假设最终结果突然从 90 分掉到 70 分。

端到端评测只能告诉你：

版本退化了。

过程评测可以继续告诉你：

PRD 解析正常 功能点提取正常 测试点覆盖率从 92% 降到了 68%

问题就能快速定位。

所以：

端到端评测负责报警，过程评测负责找问题。

七、离线评测，就是 Agent 的回归测试

只要 Agent 发生变更，都应该重新跑离线评测。

常见变更包括：

• 模型升级
• Prompt 修改
• 知识库更新
• Skill 新增
• Skill 下线
• Tool 更新
• Workflow 调整

整个过程和传统回归测试高度相似：

这里有一个很重要的前提：

评测环境要尽量固定。

因为回归测试本质上是控制变量。

同一批样本、同一套 Rubric、同一套执行环境，只改变 Agent 版本，才能判断分数变化到底来自哪里。

八、Agent 回归不能只跑一次

传统接口测试经常是：

执行一次↓Pass / Fail

Agent 不一样。

模型输出存在随机性。

同一个 Task 连跑几次，可能得到：

第一次：Pass第二次：Pass第三次：Fail第四次：Pass第五次：Pass

这时更有价值的数据不是：

第一次有没有通过。

而是：

这个任务的稳定通过率是多少。

所以 Agent 评测通常需要：

• 多次 Trial
• Pass Rate
• Pass@k
• 稳定性统计

未来 Agent 测试会越来越关注：

概率稳定性。

而不是只看一次执行结果。

九、评测门禁不能只有一个总分

Agent 发布不能简单规定：

总分 80 分以上就可以上线。

不同问题的严重程度完全不同。

比如：

安全类、数据准确性类问题，通常不应该被“平均分”稀释掉。

所以 Agent 回归更适合使用：

分层门禁。

真正有约束力的评测，还应该接入 CI/CD 或发布流程。

否则评测报告再完整，也只是建议。

十、离线守住已知，在线负责发现未知

离线评测有一个天然限制：

只能测已经进入评测集的问题。

评测集没有覆盖的场景，永远测不出来。

所以 Agent 质量体系必须同时建设线上能力。

主要包括：

• 在线评测
• 在线监控
• 巡检
• AB
• 影子模式

在线评测和在线监控的区别

举个例子。

Tool 调用成功率：

100%

超时：

0

异常：

0

监控看起来一切正常。

但如果 Tool 返回的数据是错的，Agent 最终给用户的结果仍然可能是错的。

所以：

可用性正常，不代表质量正确。

十一、线上监控至少要看三类指标

① 可用性

例如：

• Skill 成功率
• Tool 成功率
• 调用失败率
• 超时率
• 异常类型

② 性能和成本

例如：

• Token 消耗
• 平均响应时间
• 平均执行步数
• 模型调用次数

Agent 系统相比传统软件，还多了一个非常重要的质量维度：

成本。

比如同一个任务：

旧版本8 Step5000 Token10 秒

升级以后：

新版本25 Step20000 Token30 秒

即使最终结果提升了一点，也要重新评估这个版本是否值得上线。

③ 行为监控

例如：

• 任务类型分布
• Skill 调用频率
• 平均对话轮次
• Agent 执行路径

这类指标特别适合发现新的用户需求。

如果某类任务比例突然增加，而现有 Agent 在这个场景表现很差，就意味着：

评测集也需要跟着变化。

十二、Bad Case 不应该修完就结束

传统软件线上出了 Bug，经常是：

发现问题↓修复↓验证↓关闭 Bug

Agent 更适合做成：

发现 Bad Case↓问题归因↓修复 Agent↓加入评测集↓以后每次版本自动回归

这样一个线上事故，才能真正变成长期资产。

Case 池可以继续拆成两类：

Good Case

代表系统已经做得比较好的案例。

可以进入：

Golden Dataset

用于定义：

什么水平才算好。

Bad Case

代表系统已经踩过的坑。

可以进入：

Error Dataset / 错题集

用于确保：

同样的问题不要再犯第二次。

十三、Trace 是 Agent 测试绕不开的一层

Agent 出了问题，最大的麻烦之一就是：

最终结果错了，但不知道中间发生了什么。

一次 Agent 执行可能经历：

用户输入↓模型调用↓任务规划↓Skill 选择↓Tool 调用↓返回数据↓上下文更新↓再次推理↓最终输出

如果系统只保存：

用户输入+最终答案

基本很难做稳定归因。

所以 Agent 观测基建必须能够提供 Trace。

Trace 至少应该记录什么？

冷启动阶段，不一定一开始就把观测平台做得很重。

但至少要做到：

最小可归因。

也就是拿到一个 Bad Case 后，可以通过 Trace 还原当时到底发生了什么。

十四、Agent 问题怎么做归因？

Agent 最终失败，不等于：

模型不行。

问题可能发生在很多层。

这套排查过程，其实和测试开发熟悉的 Bug 定位非常像：

发现问题↓稳定复现↓查看日志↓分析调用链↓确认根因↓修复↓回归

只是 Agent 的链路更长，而且多了模型、Prompt、上下文、RAG、Tool、Skill 等新的变量。

十五、还有一种问题：评测标准本身错了

Agent 评测有一个很容易被忽略的风险：

评测判定失败↓不断优化 Agent↓Agent 越来越适合 Benchmark

但用户真正想要的东西，可能没有变好。

这种情况本质上就是：

过度拟合评测集。

所以遇到 Bad Case 时，不要永远默认：

Agent 错了。

还要检查：

• Rubric 是否合理
• 样本是否还有代表性
• 用户需求是否变化
• 评测集分布是否跟真实流量一致

否则最后可能出现：

评测分越来越高，真实用户却越来越不满意。

十六、测试开发团队可以怎么开始？

不需要一开始就把整套平台一次建完。

Agent 评测更适合从最小闭环开始。

第一阶段：先把回归跑起来

至少准备：

• 一批核心端到端 Task
• 一批关键过程 Task
• 基础 Rubric
• 简单回归脚本

先能判断：

改完到底有没有退化。

第二阶段：让 Bad Case 回流

线上每发现一个典型问题：

Bad Case↓定位↓修复↓加入 Eval Dataset

逐渐形成：

• 黄金集
• 错题集
• 必过集
• 挑战集

第三阶段：补齐 Trace

保证：

• 模型调用看得见
• Tool 调用看得见
• Skill 路由看得见
• 执行路径看得见

做到真正可归因。

第四阶段：接入研发流程

最后把评测真正放到：

代码 / Prompt / Skill 变更        ↓     自动 Eval        ↓     质量门禁        ↓       发布

这时候 Agent Eval 才真正成为质量体系的一部分。

十七、Agent 评测为什么值得测试开发关注？

Agent 时代，并没有让测试变得不重要。

恰恰相反。

随着软件逐渐具备：

• 推理
• 规划
• 工具调用
• 记忆
• 自主执行

被测系统反而变得更复杂了。

过去测试开发主要解决：

软件代码写得对不对。

现在还要继续解决：

Agent 理解得对不对。

路由选得对不对。

工具调得对不对。

执行过程对不对。

最后的事情到底有没有办成。

这会带来一批新的测试工程问题：

• Agent Eval Dataset 怎么建？
• Rubric 怎么设计？
• Tool Calling 怎么测试？
• Skill 路由怎么测试？
• RAG 怎么评测？
• 多轮 Agent 怎么回归？
• Trace 怎么采集？
• Bad Case 怎么自动归因？
• Eval 怎么接入 CI/CD？
• 在线巡检怎么做？

这些问题，最终都离不开测试工程能力。

写在最后

一套完整的 Agent 评测体系，可以收敛成四句话：

离线评测守住已知问题。

在线评测和监控负责发现未知问题。

Case 挖掘与归因负责找到问题发生在哪里。

Trace 和观测基建负责让整个过程真正可分析、可复现、可回归。

最后，所有线上问题继续沉淀回评测集：

当软件开始具备推理、规划和自主调用工具的能力之后，我们该怎样重新做好质量保障。

这才是 Agent 时代测试开发真正值得提前布局的方向。