字节面试官:Agent评测和传统软件测试的区别是什么

大家好，我是洋子。最近面试测试开发岗位，Agent评测和传统软件测试的区别，基本已经是高频问题。

如果只回答“传统测试测功能，Agent评测测效果”，面试官通常会继续追问：效果怎么定义？路径不一样怎么办？一次成功算不算通过？大模型裁判可信吗？线上出现Bad Case之后，怎么回归？

下面按一个真实的AI测试开发工程师的视角，把这几个问题串起来。

一、先把评测对象说清楚

传统软件测试的被测对象，通常是版本明确、接口明确、状态边界明确的程序。测试输入和预期输出可以写在用例里，失败后能够定位到接口、代码、数据或环境。

Agent的被测对象不是一个模型，也不是一个Prompt，而是一个运行时系统：

模型、Prompt、工具、Skill、记忆、状态管理和业务策略中的任意一个发生变化，都可能改变Agent的行为。

因此，传统测试的版本对象更接近“代码包”，Agent评测的版本对象更接近“模型加系统配置加运行环境”。这也是为什么只保存输入和最终输出，无法支撑问题定位。

二、核心差异不是“有无AI”，而是确定性不同

对比维度	传统软件测试	Agent评测	对测试工程的影响
测试对象	代码、接口、页面、数据	模型、Prompt、工具链、记忆、环境	需要记录完整Trace和配置快照
输入输出	通常结构化，预期较明确	自然语言、多轮上下文、多解	断言从相等判断扩展为目标和约束判断
执行路径	用例步骤固定	Agent自主规划，路径可变	不能只校验固定步骤，要校验关键动作和终态
测试预言机	规则、断言、Schema	规则、轨迹、人工或模型裁判组合	需要建立Rubric和裁判校准集
稳定性	同输入通常同输出	同任务可能出现多条轨迹	用成功率、分位数、方差描述，不看单次结果
失败类型	功能错误、性能错误、兼容性错误	幻觉、工具误用、越权、循环、早停、不可恢复	结果风险和过程风险必须分开统计
回归方式	固定用例重复执行	固定集加线上Bad Case持续扩充	评测集需要版本化和分层管理
成本指标	CPU、内存、耗时	Token、工具次数、重试次数、人工介入率	质量和成本必须同时设门禁

传统自动化测试追求的是“同样的输入，得到同样的可验证结果”。Agent评测追求的是“在允许的随机性内，稳定完成目标，并且不越过安全边界”。

三、为什么必须看Trajectory（行为轨迹），而不是只看Response

同一个任务，两个Agent都可能返回“已完成”。但一个只调用了一次正确工具，另一个先查错数据、连续重试五次、最后碰巧成功。对用户来说结果一样，对工程团队来说完全不是一回事。

建议把评测拆成四层：

结果层，任务是否完成，字段是否正确，输出是否可交付。
过程层，规划是否合理，工具参数是否正确，是否出现无效循环。
效率层，耗时、Token、工具调用次数、重试次数是否达标。
风险层，是否越权、泄露数据、执行不可逆操作，失败后是否产生副作用。

Trace至少应该包含：请求ID、Agent版本、模型版本、Prompt版本、工具版本、输入上下文、每一步计划、工具入参和出参、耗时、Token、重试原因、最终状态。没有这些字段，后面只能看到“失败了”，看不到“为什么失败”。

四、把模糊的评价标准拆成可执行的检查项

“回答是否专业”不是一个合格的自动化断言。它没有边界，也无法稳定复现标注结果。

以客服Agent为例，可以把“专业”拆成可判断的Rubric（评分规则）：

Rubric （评分规则）	判定方式	类型
是否识别订单号	从工具调用参数或结构化结果中校验	客观
是否引用最新订单状态	对比订单服务返回值与回复内容	客观
是否承诺了系统无法保证的时效	规则和黑名单短语校验	客观
是否解释了下一步处理动作	二元Rubric，人工抽样校准模型裁判	主观转半客观
是否在缺少信息时主动追问	场景状态机校验	客观
是否泄露内部字段	敏感字段扫描	安全

Rubric设计建议遵循三个原则：尽量二元化，允许unknown；每条规则只判断一个事实；用人工背靠背标注校准模型裁判。

例如“是否口语化”可以拆成：是否使用业务规定的称谓，是否出现禁用书面词，是否包含指定语气词，是否出现连续多句模板化表达。拆开之后，标注员之间的分歧才有机会被定位和修正。

模型裁判不能直接替代人工。正确流程是先建立人工金标准，再比较模型裁判与人工的一致率，最后才把通过校准的部分放进批量回归。

五、一个可落地的Agent评测流程

从测试开发落地角度，我会把流程分成六步：

第一步：不是列指标，而是明确业务目标。例如客服Agent的目标不是“回答更像人”，而是“一次解决率提升，同时不能产生错误承诺”。

第二步：按任务类型和风险分层。高频咨询、复杂办理、敏感操作、异常恢复要分开，不能用一套平均分覆盖所有场景。

第三步：从线上采集Good Case和Bad Case。Bad Case通常更有价值，它能暴露能力边界；Good Case用来定义什么叫合格完成。

第四步：为每类任务建立评测集、断言和Rubric，并给评测集打标签：正常、边界、对抗、回归。

第五步：在可控沙箱里执行。对涉及发消息、改数据、支付等动作的Agent，必须用模拟工具和虚拟数据，记录每一次调用。

第六步做归因，而不是只报一个总分。要回答失败发生在哪一层，是意图识别错、规划错、工具参数错、知识过期，还是安全策略没拦住。

六、案例分析，为什么“任务成功率”仍然不够

假设我们评测一个退款Agent，测试集有1000个任务。

版本A完成了920个任务，平均调用工具4.2次，其中有8次把退款金额填错，但被后置校验拦截。

版本B完成了950个任务，平均调用工具2.6次，但有3次绕过确认直接发起退款，造成真实副作用。

如果只看任务成功率，版本B更好；如果把安全和副作用纳入门禁，版本A才可能上线。

指标	版本A	版本B	结论
任务成功率	92.0%	95.0%	B更高
平均工具调用次数	4.2	2.6	B更低
工具参数错误率	0.8%	0.3%	B更低
未确认高风险操作	0	3	A通过，B阻断
失败后可恢复率	88%	71%	A更稳
单任务平均Token	6.8k	4.1k	B更低

工程上不能用一个总分掩盖高风险项。高风险指标应该设置硬门禁，例如未确认退款、越权读取用户信息、向外部发送敏感内容，任何一项超过阈值都直接阻断发布。

这也是Agent评测和传统功能测试的共同点，质量不是平均数。一个支付接口偶发扣两次款，不能用其他接口的高通过率抵消；一个Agent偶发越权，也不能用大部分正常回答来平均掉。

七、从测试开发角度，传统能力如何迁移

传统测试经验并没有失效，反而提供了Agent工程化需要的骨架。

状态机可以用来描述多轮任务和异常恢复；边界值可以用来构造上下文长度、金额、权限范围和工具参数边界；故障注入可以验证工具超时、返回脏数据、模型拒答和网络抖动下的恢复行为；契约测试可以保证工具Schema和Agent之间的接口稳定。

变化主要在于断言层和数据层。断言不再只有“返回值等于预期”，还要检查目标是否达成、过程是否合规、成本是否可接受；数据不再只是手工编写的固定用例，还要持续吸收线上Trace、Good Case、Bad Case和对抗样本。

如果在字节面试中回答这道题，我会用下面这段话收尾：

传统软件测试主要验证确定性的功能、状态和接口契约；Agent评测验证的是模型进入真实系统后，能否在多解、随机和有风险的环境中稳定完成目标。评测对象从代码扩展为模型加Prompt加工具加记忆加业务流程，评测内容从Response扩展到Trajectory、效率和安全。落地上采用规则断言、轨迹分析、人工Rubric和模型裁判结合的方式，并通过Good/Bad Case持续迭代评测集。

这段回答的价值，不是把Agent说得多玄，而是把它重新拉回测试工程。

最终要交付的不是一个漂亮分数，而是一套能发现问题、解释问题、推动修复并支持回归的质量体系。

以上，感谢阅读，如果您想阅读更多AI测试相关干货知识，欢迎持续关注我。

后台回复「测试资源」，可领取AI测试开发面试题库

【往期推荐】