摘要
过去做大模型评测，我们更多关注一个问题：模型回答得好不好。
但进入 Agent 时代以后，测试对象正在发生变化。
Agent 不只是生成一段文本，而是会理解任务、制定计划、调用 Tool 或 Skill、读写文件、访问系统、修改状态，并根据执行结果不断调整下一步动作。
因此，Agent 评测的核心已经从 Response Evaluation，逐渐扩展到 Task、Trace、Trajectory、Outcome 和整个任务执行系统。
这篇文章从软件测试工程视角系统拆解：
Agent 评测是什么、Agent 评测指标怎么设计、Trace 为什么重要、LLM as Judge 怎么使用、短程 Agent 与长程 Agent 有什么区别，以及 Skill 和长程 Agent 应该如何做自动化评测。
一、Agent 评测是什么？它和大模型评测有什么区别？
如果把 AI 评测的发展过程拉长来看，会发现测试对象一直在变化。
传统机器学习时代，我们评测的是一个相对明确的模型。
分类任务看 Accuracy、Precision、Recall、AUC；回归任务看 MAE、RMSE。
核心问题很简单：
预测准不准？
到了大模型时代，测试对象开始变复杂。
除了正确性，还需要关注：
推理能力
指令遵循
代码能力
长文本能力
幻觉
安全性
于是 Benchmark、人工评测和 LLM as Judge 逐渐成为常见方法。
而进入 Agent 阶段以后，评测对象再次发生变化。
我们测的已经不只是一个模型，而是：
模型 + Prompt + Tool / Skill + Memory + 环境 + 工作流组成的任务系统。
所以 Agent 评测真正需要回答的是：
这个系统能不能稳定地把用户交给它的事情做完？
可以用一张表理解三者的区别：
阶段
主要评测对象
核心问题
机器学习模型
单模型
预测准不准
大语言模型
基座模型能力
能力强不强
Agent
完整任务系统
任务能否稳定完成
这也是理解 Agent Evaluation 最重要的一步：
Agent 评测不是给大模型换几个新指标，而是被测对象本身已经变了。
二、为什么 Agent 评测不能只看最终答案？
这是 Agent 测试与传统大模型测试最容易混淆的地方。
假设现在有两个 Agent，都完成了同一个任务：
根据门店数据生成一份经营分析 PPT。
第一个 Agent：
读取数据
↓
调用分析 Skill
↓
生成 PPT
第二个 Agent：
读取错误文件
↓
工具调用失败
↓
重新规划
↓
重复查询
↓
调用另一个 Skill
↓
再次失败
↓
不断重试
↓
最后生成 PPT
只看最终结果：
两个 Agent 都成功了。
但真正上线以后，这两种 Agent 完全不是一个质量水平。
第二个 Agent 可能存在：
Token 消耗过高、执行时间过长、工具调用不稳定、路径不可复现，甚至存在误操作风险。
因此一个完整的 Agent 评测，至少应该覆盖四个维度：
维度
关注内容
结果
任务有没有完成
过程
执行步骤是否合理稳定
效率
时间、Token、Tool Call 是否合理
风险
是否越权、误操作、产生安全问题
所以 Agent 评测里有两个越来越重要的概念。
Response Evaluation
评价最终输出。
例如：
答案正确吗？
报告可用吗？
文件生成了吗？
Trajectory Evaluation
评价任务执行轨迹。
例如：
调用了什么 Tool？
Tool 参数是否正确？
执行顺序是否合理？
是否出现无意义重试？
是否发生状态污染？
Response 告诉我们结果怎么样，Trajectory 告诉我们为什么会得到这个结果。
三、为什么 Trace 会成为 Agent 测试的基础能力？
做传统系统测试的人，对下面这个场景应该很熟悉：
线上出了问题。
打开日志。
然后发现——
关键过程没记录。
Agent 时代同样会遇到这个问题，而且更加严重。
一次 Agent 执行通常可能经过：
用户目标
↓
理解意图
↓
任务规划
↓
选择执行动作
↓
调用 Tool / Skill
↓
环境返回结果
↓
判断是否满足预期
↓
重新规划 / 修正 / 重试
↓
最终结果
如果系统只保存：
用户输入
+
最终回答
那么出现 Bad Case 时，我们几乎无法准确判断问题到底来自哪里。
可能是：
Prompt 理解错了；
规划步骤错了；
Tool 选择错了；
调用参数错了；
Skill 返回异常；
Memory 发生污染；
环境本身发生变化；
或者 Agent 对中间结果理解错误。
所以 Agent 系统需要 Trace。
一个真正有价值的 Trace，至少应该能够还原：
任务输入、规划信息、Tool/Skill 调用、调用参数、中间结果、状态变化、环境交互、重试修正和最终 Outcome。
它的价值和传统分布式系统里的调用链非常接近。
过去测试和运维追踪：
Service A
↓
Service B
↓
Database
Agent 系统则开始追踪：
Model
↓
Planning
↓
Tool / Skill
↓
Environment
↓
Model
所以可以得到一个很重要的工程结论：
没有完整的过程观测，就很难建立可靠的 Agent 自动化评测。
四、Agent 评测指标应该怎么设计？
很多团队刚开始做 Agent Evaluation 时，很容易先讨论：
准确率多少？
Tool 调用成功率多少？
Judge Model 给几分？
但真正的问题应该先换一下：
我们到底希望这个 Agent 帮业务解决什么问题？
因为模型能力指标和业务价值之间，并不是直接等号。
例如模型的 Tool Calling 能力明显提高，并不一定意味着用户任务完成率提高。
任务完成率提高，也不一定意味着用户愿意继续使用。
所以一个比较实用的 Agent 指标体系，可以拆成三层。
第一层：业务目标层
回答：
Agent 有没有真正产生业务价值？
常见指标包括：
DAU、留存、转化、任务完单率、人工节省时长、成交金额等。
第二层：Agent 能力层
回答：
Agent 有没有把用户交给它的事情做好？
例如：
任务完成率、一次成功率、交付可用率、规划合理率、Tool / Skill 调用成功率、纠错成功率。
第三层：模型能力层
回答：
底层模型能力是否足以支撑 Agent？
例如：
推理能力、指令遵循、检索能力、长文本处理、代码能力。
于是形成：
模型能力
↓
Agent能力
↓
业务价值
中间的 Agent 能力层 就是连接模型和业务的桥梁。
这也是为什么仅看 Benchmark 经常会出现一个问题：
模型评分提升了，业务却没感觉。
因为真实 Agent 系统中还存在 Prompt、RAG、Tool、Skill、Memory、Workflow 和执行环境。
模型只是整个链路中的一部分。
五、客观评测、主观评测和 LLM as Judge 应该怎么配合？
Agent 评测并不是所有问题都需要交给大模型判断。
最稳定的方案，通常是：
能写规则的先写规则，不能写规则的再使用 Rubric 和 Judge Model。
客观评测：解决“对不对”
例如：
是否调用正确 Tool；
API 是否成功；
JSON 字段是否完整；
文件是否真实生成；
数据库状态是否发生预期变化；
Tool 参数是否满足约束。
这类指标可以通过：
Rule-based Evaluation
Ground Truth Evaluation
State Check
代码断言
直接判断。
它们最大的优势是：
稳定、便宜、可重复、非常适合自动回归。
主观评测：解决“好不好”
但有些指标没有唯一答案。
例如：
任务规划合理吗？
客服回复自然吗？
报告有没有洞察？
最终交付物是否真正对用户有帮助？
这时就需要 Rubric。
比如评价一份分析报告，可以拆成：
评价维度
权重
关键判断
主旨清晰
30%
是否偏题、是否覆盖要求
逻辑结构
30%
结构和论证是否合理
语言规范
20%
表达是否清晰规范
内容深度
20%
是否存在有效分析和洞察
然后由人工或者 LLM as Judge 进行评估。
Rubric 为什么越具体越好？
例如：
“客服回复是否足够口语化？”
这是一个非常模糊的指标。
不同评测员很可能给出完全不同的答案。
如果把它继续拆：
是否存在明显书面公文表达？
是否大量使用机械模板？
是否使用自然交流词？
是否出现不符合用户习惯的专业术语？
判断就会稳定很多。
如果还能进一步变成：
Yes / No
0 / 1
True / False
人和人的标准更容易统一，AI 和人工的结果也更容易对齐。
所以 LLM as Judge 真正的难点并不只是：
Judge Model 够不够强。
更重要的是：
Rubric 有没有定义清楚。
六、短程 Agent 和长程 Agent 的评测有什么区别？
这是当前 Agent Evaluation 中变化最大的一部分。
早期大量 Agent 的形态其实比较接近 ChatAgent：
Query
↓
Answer
用户提出一个问题。
Agent 返回一个答案。
例如：
AI 客服、问答助手、简单查询 Agent。
这类系统的测试重点仍然集中在：
准确性、相关性、流畅性、有用性和安全性。
我们可以把它称为 短程 Agent（Short-horizon Agent）。
而 Coding Agent、Research Agent、Computer Use Agent，以及越来越多的企业工作 Agent，开始进入 Long-horizon Agent 阶段。
它们面对的不是：
回答一个问题。
而是：
完成一件事情。
例如：
根据我上传的门店数据和上月经营投放数据，生成一份经营分析 PPT。
它可能需要执行：
读取门店数据
↓
调用经营数据 Skill
↓
获取投放数据
↓
写入 CSV
↓
执行数据分析
↓
调用 PPT Skill
↓
生成文件
所以短程 Agent 和长程 Agent 的测试重点明显不同。
维度
短程 Agent
长程 Agent
输入形式
Query
Prompt / Task
目标
给出回答
完成任务
期望对象
Answer
Expected Behavior
评测重点
回复质量
任务完成 + 过程质量
环境交互
较少
大量
状态复杂度
相对较低
显著更高
主要测试对象
Response
Trace + Outcome
自动化需求
较高
更高
最核心的变化可以概括成一句话：
过去主要判断“说得怎么样”，现在还要判断“事情到底做成没有，以及是怎么做成的”。
图片
七、长程 Agent 的 Test Case 应该怎么写？
长程 Agent 出现以后，传统的：
输入
+
预期输出
已经不够描述一个 Case。
一个更适合长程 Agent 的任务评测结构可以包含几个核心对象。
Task
一个具有明确输入和成功标准的测试任务。
例如：
根据门店数据和经营投放数据生成一份经营分析 PPT。
Trial
Agent 执行一次 Task 的完整运行实例。
因为大模型存在概率性，同一 Task 通常需要执行多次 Trial，才能判断稳定性。
Trajectory / Trace
一次执行过程中产生的完整轨迹。
例如：
Tool 调用、Skill 调用、中间结果、环境交互、状态变化以及重试记录。
Outcome
任务结束后，真实环境中的最终状态。
这是一个非常重要的概念。
因为 Agent 最终回复可能说：
PPT 已经生成完成。
但测试真正应该检查的是：
文件系统中是否真的存在 PPT？
文件能否正常打开？
里面的数据是否正确？
Agent 说它完成了，并不等于环境里真的完成了。
Grader
用于评价 Agent 表现的评分逻辑。
Grader 可以是：
规则校验；
状态检查；
Ground Truth；
Judge Model；
Tool Call 检查。
Expected Behavior
长程 Agent 的预期结果不一定是一段固定文本。
更多时候是：
预期它完成哪些关键行为。
例如：
Prompt：
结合门店数据和 4 月投放数据生成经营分析 PPT。
Expected Behavior：
① 获取 4 月投放数据并保存
② 正确读取门店数据
③ 联合两份数据完成分析
④ 调用指定分析能力
⑤ 最终生成可用 PPT
运行完成以后，通过 Trace 和 Outcome 判断这些行为到底有没有真正发生。
于是长程 Agent 的评测对象可以理解成：
Prompt
+
Expected Behavior
+
Trajectory
+
Outcome
这比传统的：
Query
+
Answer
明显复杂得多。
八、为什么长程 Agent 测试越来越离不开 Sandbox？
短程问答 Agent 主要产生文本。
但长程 Agent 会真的修改环境。
它可能：
创建文件、删除文件、运行代码、安装依赖、调用 API、访问数据库，甚至修改生产系统中的某些状态。
例如测试：
将当前环境里的某个 Python 依赖升级到指定版本。
如果直接在共享测试机执行，那么第一个 Case 跑完以后，环境就已经改变。
第二个 Case 的起点和第一个 Case 不一样了。
这会直接破坏评测的可重复性。
因此长程 Agent Eval Harness 中，需要越来越重视：
执行沙箱。
每一个 Case 最好拥有：
可初始化
可隔离
可观测
可回滚
可重复
的执行环境。
其实这个思想测试工程师非常熟悉。
传统自动化测试一直强调：
Case 之间不要互相污染。
到了 Agent 时代，这个原则没有消失，反而更加重要。
九、Skill 为什么会成为 Agent 测试的新对象？
现在很多 Agent 的能力并不是全部来自大模型。
而是通过各种 Skill 扩展。
例如：
数据查询 Skill；
文件处理 Skill；
浏览器操作 Skill；
代码执行 Skill；
经营分析 Skill；
PPT 生成 Skill。
随着 Skill 数量增长，新的测试问题也会出现。
Skill 自己能不能工作？
这是单 Skill 测试。
Skill 接进 Agent 以后还能不能工作？
这是 Agent 集成测试。
Skill 升级以后，会不会把原来的 Agent 搞坏？
这是 Agent Regression。
比如某个 Skill 升级以后改变了输出字段。
单独测试这个 Skill：
全部通过。
但下游 Agent 仍然按照旧字段解析结果。
于是整个业务任务失败。
这和我们熟悉的：
接口兼容性、组件升级、依赖变更
其实非常接近。
所以 Skill 的质量体系未来很可能逐渐形成：
Skill 单测
↓
Skill 准入评测
↓
Agent 集成评测
↓
历史 Case 回归
↓
线上运行观测
这也是软件测试工程经验可以直接迁移到 Agent 工程里的地方。
十、一套完整的 Agent Evaluation 平台应该具备什么能力？
如果企业未来同时维护大量 Agent 和 Skill，仅靠人工抽几个 Case 已经不够。
一个真正工程化的 Agent Evaluation 平台，至少需要几类基础能力。
① Case / Benchmark 管理
统一维护：
任务、输入、上下文、Expected Behavior、Rubric 和历史版本。
② Trace 与回放
能够查看一次 Agent 执行过程中发生了什么，并复现问题现场。
③ Sandbox
保证不同 Case 独立运行，减少环境污染。
④ Evaluation Engine
同时支持：
规则评测、状态评测、Ground Truth、LLM as Judge 和自定义代码评测。
⑤ 报告与归因
不仅告诉你：
73 分。
还应该告诉你：
问题发生在规划、Skill、工具、环境还是最终结果。
⑥ Regression
模型、Prompt、Skill 或 Agent 版本发生变化以后，自动执行历史测试集。
⑦ Quality Gate
将评测结果接入发布流程。
例如：
新版本
↓
Agent Eval
↓
核心 Case 是否通过
↓
达到门禁
↓
灰度 / 发布
当这一步真正建立起来以后，Agent Evaluation 才从：
“看看效果怎么样”
变成软件工程中的：
质量基础设施。
十一、测试开发工程师做 Agent 测试，应该重点补哪些能力？
如果你本身就在做软件测试或测试开发，其实完全没有必要把 Agent Evaluation 看成一个陌生的新岗位。
很多底层思想一直没有变。
Agent 领域
传统测试中的对应能力
Trace
日志 / 调用链
Task
测试场景
Expected Behavior
预期结果
Benchmark
回归测试集
Sandbox
测试环境隔离
Tool / Skill Test
接口 / 组件测试
Trajectory Evaluation
流程与链路测试
Outcome Check
状态断言
Evaluation Gate
CI/CD 质量门禁
真正发生变化的是：
被测软件开始具有概率性。
传统软件中：
输入 A
→
程序路径基本确定
→
输出 B
Agent 系统中：
输入 A
→
模型动态规划
→
可能选择不同工具
→
产生不同执行轨迹
→
最终完成任务
因此测试开发需要把两套能力结合起来：
一套来自传统软件工程：
自动化、接口测试、系统测试、可观测性、环境治理、CI/CD。
另一套来自 AI 系统：
Benchmark、Rubric、LLM as Judge、Trajectory Evaluation、Agent Eval。
未来比较有价值的 Agent 测试工程师，很可能不是只会写 Prompt 的人，而是能够：
把一个具有概率性的 Agent，做成一个可以观测、测试、回归和稳定交付的软件系统。
十二、Agent 评测最终要解决的，不是“打多少分”
一个 Agent 第一次上线时，不可能拥有一套完美的 Benchmark。
实际工程通常是逐渐演进的。
先从最重要的业务场景建立少量核心 Case。
然后上线或灰度。
持续收集 Bad Case。
再把典型失败场景加入 Regression Dataset。
同时沉淀高质量 Good Case，反过来定义“什么叫做好”。
最终形成：
线上运行
↓
发现 Bad Case
↓
问题归因
↓
沉淀测试 Case
↓
优化 Model / Prompt / Skill
↓
自动回归
↓
重新发布
所以成熟的 Agent Evaluation，不应该只是一次 Benchmark。
它更像一个不断增长的质量资产库。
每一个真正有价值的 Bad Case，都应该成为下一次版本升级时不会再次踩中的坑。
写在最后
Agent 正在从一个“会聊天的模型”，逐渐变成一个真正参与业务执行的软件系统。
它会规划任务、调用工具、读取文件、修改状态、执行代码，并根据环境结果继续决策。
所以测试对象自然也会从：
模型最后说了什么
扩展成：
任务有没有完成、过程是否合理、环境是否发生了正确变化，以及整个系统能不能稳定重复这一过程。
这也是为什么 Agent 测试正在越来越多地涉及：
Trace、Trajectory、Task、Expected Behavior、Outcome、Rubric、LLM as Judge、Skill Evaluation、Sandbox 和 Evaluation Harness。
对于软件测试和测试开发从业者来说，这并不是传统测试被 AI 取代。
恰恰相反。
过去积累的自动化、系统测试、日志分析、接口测试、测试环境、回归体系和质量门禁，正在重新成为 Agent 工程化最重要的基础能力。
区别只是，我们接下来要测试的系统，开始自己决定下一步该怎么走了。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
