第 1 章：为什么传统测试方法在 AI 时代失效了

1.1 通过测试的客服 Agent，为什么上线后仍然翻车

一家企业把客服 Agent 接入售后系统前，跑了 500 条自动化测试用例。测试结果非常漂亮：接口全部可用，标准问题回答准确，退款、物流、订单查询三个主流程都能走通。团队据此判断，可以进入灰度。

上线后一周，问题集中爆发：

用户用口语化表达咨询退款，Agent 识别成物流问题。
用户在多轮对话中补充了“只退其中一件商品”，Agent 后续回答仍按整单退款处理。
知识库中有两条相互冲突的退款政策，Agent 选择了过期条款。
工具查询失败后，Agent 仍然给出确定性退款建议。
面对高风险金额问题，Agent 没有转人工，而是直接承诺“可以全额退回”。

测试报告没有错。它确实证明了系统能处理那 500 条预设用例。

问题在于：AI 系统的风险不只存在于预设输入和固定输出之间。LLM 和 Agent 会在开放输入、多轮上下文、工具调用、检索结果、业务规则和用户反馈中产生复杂行为。传统软件测试中很多默认成立的前提，在这里不再成立。

AI 评测的第一步，是承认这个变化：通过测试，不等于真实质量合格。

1.2 传统软件测试依赖的五个前提

传统软件测试并没有失去价值。接口测试、单元测试、集成测试、端到端测试仍然是 AI 系统工程质量的底座。但它们背后依赖一些隐含前提。

前提	传统测试中的含义
确定性	同样输入在同样环境下得到同样输出
可断言性	期望结果可以被明确写成断言
稳定性	依赖组件和业务规则在测试周期内相对稳定
可分解性	系统行为可以拆成相对独立的模块验证
可观测性	失败原因可以通过日志、异常和状态较快定位

在传统订单系统里，用户提交订单、支付、取消订单、申请退款，每个动作都有明确输入、状态转移和期望结果。测试可以写成：

输入金额为 100 元，支付成功后订单状态变为已支付。
用户取消未发货订单，退款状态变为处理中。
无权限用户访问订单详情，返回权限错误。

这些断言清晰、稳定、可重复。测试目标是证明系统是否按预期逻辑运行。

AI 系统当然也包含这些确定性部分。工具接口、权限校验、工作流状态、缓存、数据库写入，都要继续用传统测试覆盖。真正发生变化的是：LLM / Agent 行为不能完全用固定断言描述。

1.2.1 传统测试仍是底座

讨论 AI 评测时，一个常见误解是：既然传统测试覆盖不了开放式行为，就可以把测试体系整体替换成评测体系。这种理解会让 AI 应用更危险。

企业客服 Agent 仍然需要传统测试覆盖确定性工程链路：

对象	传统测试应覆盖什么	若缺失会发生什么
API 与工具	入参校验、鉴权、超时、错误码、幂等	Agent 调用正确工具也可能得到错误终态
业务工作流	订单状态流转、退款审批、人工转接	模型回答正确，但系统动作不符合业务约束
数据库与缓存	写入一致性、缓存失效、并发冲突	工具返回陈旧状态，导致回答基于错误事实
权限系统	用户身份、角色、数据访问边界	Agent 可能间接暴露无权访问的信息
前后端集成	埋点、表单、会话、错误提示	用户体验问题被误判为模型问题

AI 评测补上的不是这些确定性测试，而是另一层质量问题：开放输入下的语义理解、证据使用、风险边界、工具选择、多轮决策和业务效果。两者的边界可以这样理解：

测试回答“系统是否按确定规则运行”。
评测回答“系统在开放任务中是否表现可靠”。
监控回答“系统上线后是否仍然处于可接受状态”。

三者不是替代关系，而是分工关系。没有测试，评测会被底层工程问题污染；没有评测，测试无法说明开放行为质量；没有监控，离线结论无法持续接受真实流量校验。

1.3 AI 系统如何打破确定性

LLM 输出具有概率性。即使温度设置较低，不同模型版本、上下文长度、系统提示、检索片段顺序和采样参数，也可能让回答出现差异。

客服 Agent 的例子中，用户问：

我买的耳机用了优惠券，现在只退一个，钱怎么算？

传统测试希望写一个固定期望答案。但真实系统可能给出多种可接受回答：

说明需要按订单明细和优惠券分摊规则计算。
要求用户提供订单号后调用退款规则工具。
提醒用户部分退款可能影响优惠权益。
在证据不足时转人工确认。

这些回答的表述不同，但可能都合格。反过来，一个回答文字上接近标准答案，也可能因为缺少证据、遗漏风险或没有说明下一步而不合格。

因此，AI 评测不能只判断字符串是否匹配。它要判断行为是否满足业务目标、风险边界和用户体验要求。

1.4 AI 系统如何打破可断言性

传统断言通常是明确的：

返回码等于 200。
状态等于 success。
字段 amount 等于 99.00。

AI 回答的期望更像一个 Rubric。它包含多个评价维度：

维度	判断问题
业务正确性	是否符合退款政策和订单规则
证据充分性	是否引用或基于正确知识和工具结果
风险控制	是否避免无依据承诺和越权操作
可执行性	用户是否知道下一步该做什么
表达质量	是否清晰、简洁、符合客服语气

同一个回答可能业务正确但表达差，也可能表达自然但政策错误。AI 评测必须处理这种多维质量，而不是把结果压成单一 pass / fail。

这也是为什么企业级评测需要指标树、Rubric、Evaluator 和人工校准。它不是为了把问题复杂化，而是因为质量本来就不再是一条断言能覆盖的对象。

1.5 AI 系统如何打破稳定性

AI 应用处在持续变化中：

模型供应商更新模型。
Prompt 被频繁调整。
知识库每天同步业务政策。
Embedding、索引和 Rerank 策略变化。
工具 Schema 改动。
线上用户问题分布变化。
安全策略和业务规则更新。

客服 Agent 在上周通过的样本，本周可能因为退款政策更新而不再代表真实风险。一个版本在内部测试中表现稳定，上线后遇到新活动、新商品和新用户表达，就可能出现退化。

这意味着 AI 评测不是一次验收动作，而是持续运行的质量基础设施。它必须跟随系统变更、数据分布和业务规则变化不断更新。

1.6 AI 系统如何打破可分解性

传统系统可以较清楚地把问题拆到模块：接口、数据库、权限、前端、消息队列。

Agent 系统的错误经常跨层发生。

一次错误退款建议可能包含：

用户意图识别粒度不足。
检索没有召回会员退款政策。
Prompt 没有限制无证据承诺。
Agent 没有调用退款规则工具。
工具失败后没有触发异常恢复。
最终回答没有提示转人工。

从用户视角看，只有一个错误回答。从系统视角看，它可能是检索、工具、编排、Prompt、模型和业务规则共同作用的结果。

因此，AI 评测不能只测最终答案。对于 Agent，必须评测过程：规划是否合理，工具是否选对，参数是否正确，状态是否保持，异常是否恢复。

这也是后续章节会引入 Trace 评测和分层归因的原因。

1.7 AI 系统如何打破可观测性

传统系统报错时，日志通常能给出明确线索：异常类型、堆栈、接口返回、数据库错误、权限失败。

AI 系统的失败更隐蔽。

模型可以给出一段看似自然、语气友好、格式完整的回答，但事实是错的。Agent 可以在工具失败后继续生成，让用户误以为系统已经确认。RAG 可以检索到相关但不正确的片段，最终回答也看不出问题来源。

如果没有保存检索结果、工具调用、上下文、Prompt、模型版本和中间状态，团队很难回答：

Agent 是否看到了正确知识。
模型是否忽略了上下文。
工具是否返回了错误结果。
问题是否来自业务规则没有同步。
某个失败是否与候选版本相关。

AI 评测必须提高系统可观测性。评测不只是打分，也是采集证据。

1.8 从验证正确性到度量能力边界

传统测试强调“系统是否按预期工作”。AI 评测还要回答更多问题：

系统在哪些场景可靠。
哪些场景风险最高。
哪些输入会触发幻觉或越权。
哪些能力在候选版本中退化。
哪些问题必须阻断发布。
哪些 Bad Case 可以回流为回归资产。

这种范式转换可以概括为：

传统测试	AI 评测
验证功能是否正确	度量能力、风险和边界
固定输入和固定输出	开放输入和多种可接受输出
断言结果	使用指标、Rubric 和证据链
一次测试通过	持续评测和线上回流
定位代码缺陷	分层归因到模型、RAG、工具、Agent 和业务规则
发布前质量检查	贯穿发布、灰度、监控和优化闭环

AI 评测不是传统测试的替代品。更准确地说，它是在传统工程测试之上，增加一套面向概率行为、开放任务和业务风险的质量体系。

在企业实践中，可以用下面的边界划分来组织质量工作：

质量活动	主要对象	典型问题	输出
测试	确定性代码、接口、工具、流程	是否按规则运行	单测、集成测试、端到端测试、接口测试
评测	LLM、RAG、Agent、业务回答与行动	是否满足能力、风险和体验要求	指标树、Eval Case、Judge、人评、版本报告
监控	线上真实流量和业务结果	是否发生退化、异常或事故	看板、告警、Bad Case、回流样本

如果把评测当成测试，就会试图为开放回答写死唯一答案；如果把监控当成评测，就会等线上用户替团队发现问题；如果用测试替代监控，就会误以为发布前通过的用例可以代表长期质量。

成熟团队会让这三类活动形成闭环：测试保证工程底座稳定，评测决定候选版本是否具备上线条件，监控发现真实世界的新风险，并把 Bad Case 回流到评测资产中。

1.9 客服 Agent 的传统用例缺口

那 500 条自动化用例为什么没挡住上线问题？

因为它们主要覆盖了 happy path：

标准问题：退款多久到账？
标准回答：1-3 个工作日。
标准工具调用：查询订单状态。
标准流程：用户提供订单号，系统返回结果。

但真实用户的问题是：

“我用了券，退一件是不是亏了？”
“你前面说可以退，为什么页面又不行？”
“我上个月买的，现在活动价更低，能退差价吗？”
“你直接帮我退，不要再问了。”

这些问题涉及口语表达、政策冲突、多轮状态、权限边界、工具副作用和人工兜底。传统用例没有覆盖这些风险，因此测试全绿并不意外。

AI 评测要把这些复杂输入变成可管理的评测资产：风险场景、指标树、Eval Case、Trace、Evaluator、Regression Set 和线上 Bad Case。

1.9.1 事故复盘：500 条用例为什么没有覆盖真实风险

回到本章开头的客服 Agent。团队并不是没有测试意识，也不是完全没有质量投入。真正的问题在于，500 条用例的设计目标仍然是“流程走通”，而不是“风险可控”。

复盘这批用例，可以看到四个结构性缺口。

第一，样本来源过于干净。多数用例来自产品文档和标准 FAQ，表达完整、意图单一、上下文清晰。真实用户不会按 FAQ 提问，他们会省略信息、混合多个诉求、引用前文承诺，甚至用情绪化语言推动系统让步。

第二，用例覆盖的是功能路径，不是风险场景。退款、物流、订单查询都被覆盖了，但“优惠券分摊后的部分退款”“活动价差争议”“他人订单查询”“工具失败后的保守回答”没有被纳入单独风险类目。风险没有被建模，就不会被系统性覆盖。

第三，断言只看最终回复，没有看中间过程。Agent 是否调用了资格校验工具、是否读取了正确政策、是否识别高风险金额、是否触发人工转接，测试用例没有保存这些证据。最终回答看起来像客服话术时，内部错误链路会被隐藏。

第四，用例没有进入发布和回流机制。一次通过后，这些样本没有按风险等级分层，也没有形成回归集和门禁规则。线上出现 Bad Case 后，团队只是修了个别 Prompt，没有把事故样本沉淀成下一次发布前必须通过的资产。

这类事故说明，AI 评测的起点不是“多写一些测试用例”，而是重新定义样本的组织方式：每条 Case 都要知道自己覆盖哪个业务目标、哪个风险、哪个能力、哪个被评对象，以及失败后应该触发什么决策。

1.10 交付物一：传统测试假设 vs AI 系统现实

传统测试假设	AI 系统现实	评测应对
输出确定	输出存在概率性和表达差异	用 Rubric 和多维指标评价
期望可断言	合格答案可能有多种形式	定义可接受行为边界
环境稳定	模型、知识库、用户分布持续变化	建立持续评测和版本血缘
模块可独立验证	错误跨模型、RAG、工具和业务规则	做分层评测和根因归因
失败显性可见	错误可能以自然语言隐藏	保存证据链和 Trace
测试通过即可发布	通过离线不代表线上稳定	接入门禁、灰度和线上监控

这张表可以作为团队从传统测试进入 AI 评测时的沟通工具。

1.11 交付物二：AI 评测思维切换清单

检查问题	判断
是否只判断固定输出，而没有定义可接受行为范围	是 / 否
是否只覆盖标准问题，没有覆盖长尾表达和风险场景	是 / 否
是否只测最终答案，没有保存检索、工具和 Trace	是 / 否
是否只看平均分，没有关注高危场景	是 / 否
是否没有版本、数据和 Prompt 的血缘记录	是 / 否
是否评测通过后没有接入发布门禁	是 / 否
是否线上 Bad Case 无法回流到离线评测	是 / 否

如果多个答案为“是”，说明团队仍在用传统测试直觉处理 AI 系统质量。

1.12 常见误区

1.12.1 写死标准答案

开放问答场景不能只靠字符串匹配。标准答案可以作为参考，但不能替代 Rubric。

1.12.2 只测 happy path

真实风险往往发生在长尾表达、政策冲突、多轮上下文和工具异常中。

1.12.3 只看一次跑分

一次分数代表某个时间点的表现，不代表候选版本在后续业务变化中持续可靠。

1.12.4 忽略线上分布

离线样本再精心，也需要线上数据校准。线上 Bad Case 是评测资产的重要来源。

1.12.5 把 AI 评测当成模型跑分

企业 AI 应用的质量来自模型、Prompt、RAG、工具、Agent 编排、业务规则和产品兜底的共同作用。

1.13 本章小结

AI 时代不是传统测试失效，而是只靠传统测试不够。

LLM 与 Agent 打破了传统测试依赖的确定性、可断言性、稳定性、可分解性和可观测性。企业需要从“验证正确性”转向“度量能力边界与风险水位”。

客服 Agent 的例子说明：自动化用例全绿，只能证明系统通过了已知路径；真正的企业级质量，还需要风险场景、指标体系、评测数据、Evaluator、Trace、门禁、线上监控和优化闭环共同支撑。

下一章，我们将进入企业级 AI 评测要解决的具体问题，看看一个评测体系究竟要回答哪些核心命题。