Agent上线后才暴露的“软失败”，测试团队怎样提前拦住？

摘要：AWS在2026年10月16日公开了一套面向生产Agent的九阶段评测框架。它真正提醒测试团队的，不是再多接一个评测服务，而是Agent最危险的错误往往不会返回500：答案勉强可用、流程却已经偏航。本文把九阶段方法翻译成一套可执行的风险门禁。

客服Agent调用了订单查询，也给出了退款状态，接口没有异常，用户甚至没有投诉。传统监控会把这次请求标成成功；但完整Trace显示，它先用了旧会话里的订单号，工具超时后又根据历史消息补写了“预计到账时间”。

这个开场不是AWS披露的真实事故，而是把其公开框架列出的生产风险放进退款业务后的技术推演。AWS在10月16日发布的文章中明确提出：生产Agent需要经过用例定义、数据集构建、评估器选择、离线测试、在线监控和反馈回流等九个阶段。对测试工程师而言，最关键的变化是：HTTP成功与文本流畅，已经不足以证明业务正确。

本文不会照抄九个名词，而是回答三个更实用的问题：哪些“软失败”最容易漏；怎样把最终答案、工具轨迹、成本和副作用分开判断；小团队如何用一张风险矩阵和三道发布门禁复制这套闭环。

软失败为什么比报错更危险

报错会触发告警，软失败却会进入正常数据。Agent可能选错工具、参数来自错误上下文、重复执行无副作用查询，最后仍生成一段像样的回答。它也可能事实正确，却付出十倍Token和延迟；或者前八步都合理，最后一步越权执行退款。

传统自动化习惯断言状态码、字段和页面元素，这些检查依然必要，但它们只覆盖“系统是否按接口契约运行”。Agent还多出三层不确定性：模型会解释目标，规划器会选择路径，工具会改变外部世界。因此，一次成功至少要同时满足结果正确、过程受控、成本可接受、失败能停下。

这张表的重点不是多收集日志，而是每类证据必须能回答一个发布问题。如果记录了十万条Trace，却说不清参数从哪里来、工具有没有真正生效，观测数据仍然无法支持放行。

九阶段不是瀑布，而是一条证据链

AWS公开框架可以理解为四个连续问题。第一，业务到底要Agent完成什么；第二，拿什么样本证明；第三，谁来判断以及怎样校准；第四，生产变化怎样回到测试集。九个阶段的价值，是防止团队从“接一个Judge”直接跳到“上线看分数”。

第一步先写关键场景和失败边界。退款查询不是“回答退款进度”，而是确认身份、取得订单、校验归属、读取状态、解释状态、在信息不足时停止。每个动词都能失败，也都应对应证据。

第二步构建分层数据集。金标样本保存不能交换的业务规则；挑战样本覆盖歧义、多轮、省略和对抗输入；故障样本注入超时、空返回、脏数据和权限拒绝；线上样本代表真实表达与长尾。四类样本不能混成一个平均分，否则大量简单问答会把高风险退款失败稀释掉。

第三步组合评估器。订单归属、金额、状态枚举、调用次数适合确定性规则；“有没有完整解释限制”可交给经过校准的模型评审；权限与副作用必须在沙箱里验证真实结果。不要让一个LLM Judge同时裁决所有问题，更不能让它以“总体不错”覆盖红线失败。

第四步把线上失败回流。新模型、工具Schema、提示词和知识库都会改变Agent行为，评测集如果不变，很快只是在重复验证昨天。线上聚类发现的新失败应先由人工确认，再进入候选回归集，绑定触发条件、责任模块和有效版本。

三道门禁比一个总分更可信

第一道是业务红线门禁。越权访问、错误金额、重复写操作、隐私泄露、无证据承诺，只要出现一次就阻断。这些问题不能用“总体95分”抵消。

第二道是能力回归门禁。按场景切片比较当前版本与基线：退款查询、改签、投诉、人工转接分别看，而不是只看全量均值。门禁还应区分“模型能力下降”和“工具链变化”。同一批样本中，如果答案下降但工具路径稳定，优先查提示词或模型；如果错误集中在参数与重试，先查Schema和编排。

第三道是运营预算门禁。把P95时延、平均工具调用数、Token和外部服务成本放进评测报告。一个准确率略升、成本翻倍的版本不一定值得上线；一个回复更短、但把关键人工确认省掉的版本更不能以“体验优化”通过。

三道门禁需要保留原因码，而不只是红绿灯。例如 AUTH_OWNER_MISMATCH、TOOL_RETRY_EXCEEDED、ANSWER_TOOL_CONFLICT。原因码让失败能被路由到权限、工具、提示词或数据团队，避免每次都让测试人员从头读Trace。

把退款推演真正跑起来

最小回归不需要先买平台。给每条用例保存输入、身份、上下文、预期工具、禁止工具、最大调用数、工具桩返回、最终业务状态和预算。运行后输出统一Trace，再执行四类断言。

def check_refund_trace(case, trace):
    assert trace["user_id"] == trace["order_owner"]
    assert trace["write_calls"] == 0
    assert trace["tool_calls"] <= case["max_calls"]
    assert trace["answer_state"] == trace["tool_state"]
    assert trace["stop_reason"] in case["allowed_stops"]

这段代码没有判断文案好不好，它守住可确定的事实。语义完整性另交给评审器，例如“是否明确说明退款仍在处理中”“是否在缺少订单号时主动追问”。评审器先用人工标注的小样本校准，出现分歧时进入复核，而不是强行给出精确到小数点的质量分。

故障注入至少覆盖四组：工具超时、工具返回空值、返回状态冲突、写操作执行后响应丢失。最后一种最容易漏，因为Agent看到超时可能重试，导致重复退款。测试不能只模拟API报错，还要检查外部世界已经发生了什么。

小团队的两周落地法

第一周只选一条高风险旅程，人工审十到二十条Trace，形成失败词典；把最确定的五条红线写成规则。第二周加入两个故障桩、一个经过校准的语义评审器，并在合并请求中运行小样本，在夜间运行全量挑战集。

团队暂时做不到生产实时评测，也可以每天抽样回放。关键是建立版本关系：模型、提示词、工具Schema、知识库和评测集都要有标识。否则发现退化时，只能知道“今天不如昨天”，却无法解释是什么变了。

还要给线上样本设置隐私处理和保留期限。不是所有对话都应进入训练或评测集；测试团队需要与安全、法务约定脱敏、访问和删除规则。质量闭环不能靠无限保存用户数据换来。

这套方法的边界

AWS文章提供的是官方工程框架，不代表所有团队都需要完整的云服务组合，也不证明九个阶段能自动消除模型不确定性。模型评审仍会漂移，人工标注仍有分歧，线上流量也可能包含评测集从未见过的任务。

因此，本文的推断是：框架最值得复制的是“证据连续性”，不是产品清单。真正成熟的Agent测试，不是找一个万能分数，而是让每个高风险结论都能回到样本、Trace、规则和版本。

当测试工程师能说清Agent为什么成功、失败时为何停下、花了多少资源、改变了什么外部状态，质量工作就从验收答案升级为定义可控的业务行为。这才是生产Agent真正需要的兜底。

评测器本身也要接受版本管理

很多团队给模型、提示词和工具标版本，却把评测器当成永远正确的裁判。事实上，规则脚本会因字段变化失效，语义评审器会随模型升级改变尺度，人工Rubric也可能因业务策略调整而过期。一次分数上升，既可能来自Agent变好，也可能来自裁判变松。

因此每次报告应同时记录被测系统版本与评测系统版本。评审器变更时，用一组冻结的校准样本做前后对照：哪些样本从失败变通过，原因是规则修复还是标准放宽；哪些边界出现新分歧；历史趋势是否需要重新解释。关键红线尽量使用确定性断言，不让评审模型更新悄悄改变发布标准。

从一次失败定位到责任模块

面对“退款状态答错”不能立刻归因模型。先看工具是否返回正确事实，再看参数来源、权限结果和回复映射。工具返回错，查数据或服务；参数错，查上下文与Schema；工具对而回复错，查提示词与模型；全部正确但用户仍不满意，再审业务定义和表达标准。

这条排查路线能避免两种浪费：遇到问题就换模型，或者不停扩充提示词。测试报告最好直接给出证据链和候选责任模块，让修复动作可验证。修复后不仅重跑失败样本，还要回归相邻能力，防止“更严格追问订单号”伤害已经由可信上下文提供订单号的正常路径。

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