摘要

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 Step
5000 Token
10 秒

升级以后：

新版本

25 Step
20000 Token
30 秒

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

③ 行为监控

例如：

• 任务类型分布
• 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 时代测试开发真正值得提前布局的方向。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。