Agent跑了多轮才答错,测试报告该从哪一步开始看?

摘要
面向多轮Agent的测试,不应只保存最终回答。本文给出Trace最小字段、分段归因与可复现回归方法;以通用工程推演开篇,不声称某家公司真实事故。
浏览器Agent尝试检索商品、打开详情、修改筛选条件,最后却告诉用户“没有结果”。截图只看得到最终页面,测试人员无法判断是检索工具没返回、筛选条件理解错、页面状态未等待,还是Agent在中途丢了上下文。测试多轮Agent时,聊天记录不是完整Trace。本文给出一套最小字段和排查路线,适合将Agent接入客服、知识库、浏览器或内部工具的团队。开场是基于常见Agent机制构造的业务推演,不指向某家企业的真实事故。
为什么最终答案不能解释执行过程
同一个结果可能由不同路径产生:Agent正确调用检索但页面超时;Agent没有调用工具,直接猜答案;Agent调用了错误工具,但恰好返回相似内容。只断言最后一句话会把三种情况压成一个“通过”或“失败”。反过来,严格比较每一步的自然语言也很脆弱,措辞变化并不总意味着行为变化。
可观测性要围绕“哪个动作改变了什么状态”组织。一个Span表示一个可归因的操作,例如模型推理、工具调用、页面加载、数据库查询、评测器判分。Trace把它们关联起来。OpenTelemetry当前GenAI Agent语义约定位于独立的semantic-conventions-genai仓库,文档状态标为Development,定义了Agent、工作流、计划和工具执行等Span及gen_ai.*属性。实际落地时应先采用适用的标准字段;本文表中task_id、业务状态快照、断言结果和授权人等是本文建议的业务扩展,不是规范字段。每个Span可关联运行ID、父Span、任务版本、工具名称、输入输出摘要、开始结束时间、错误类别和状态快照引用。敏感字段需脱敏。
| 字段类别 | 最小字段 | 用来回答的问题 |
|---|---|---|
| 运行身份 | trace_id、run_id、task_id、版本 | 哪次运行、哪份任务配置? |
| 模型调用 | model、prompt版本、结束原因、耗时 | 输出从哪里产生? |
| 工具动作 | tool_name、参数摘要、返回状态 | Agent实际做了什么? |
| 环境状态 | 页面/订单/文件快照引用 | 动作前后状态如何变化? |
| 判定证据 | oracle、assertion、人工复核 | 为什么判定通过或失败? |
| 隐私治理 | 脱敏等级、保留策略 | 日志能否安全保存? |
一条可复用的排查路线
第一步,确认任务和系统版本是否一致:Agent版本、提示词、工具Schema、网页构建版本、数据集快照都要可追溯。第二步,沿Trace从根Span看每次模型决定,找到第一次偏离预期的不变量,而不是先看最后错误。第三步,核对工具真实输入与返回,排除接口成功但业务状态没变化。第四步,对比动作前后的环境快照。第五步,重放同一任务,确认问题稳定出现或记录波动范围。
如果轨迹中模型选择了正确工具、参数也正确,但工具返回旧状态,优先检查环境一致性和缓存;若工具结果正确而下一轮模型忽略它,关注上下文拼接和窗口截断;如果工具被拒绝,确认权限配置是否预期;若最终断言失败但所有操作都符合规则,可能是验收标准不完整。这个排查顺序能避免把所有失败都归因于模型。

回归时应比较不变量,而不是逐字一致
对非确定性系统,逐字比较回答会造成大量无意义告警。可以把回归分成三类:硬性业务不变量必须满足,例如未经确认不能提交;轨迹结构允许一定变化,例如先查缓存或先查数据库,但最终都需校验数据;语言输出按语义和风险评分,必要时再人工复核。

例子:退款Agent可先查订单再查支付,也可能反过来,只要两项信息都齐全且状态满足条件;但不得在查到“已退款”后再次调用退款接口。测试集应记录允许路径集合和关键禁止路径。若流程变化超出集合,不一定立即阻断,但应进入人工复核并比较业务副作用。
如何建一个最小Trace实验
用一个模拟Agent执行“查询订单—确认是否可退款—生成退款草稿”的三步任务。每次运行保存JSONL事件:模型决策、工具参数、工具响应、环境状态摘要、断言结果。给每条事件稳定的run_id和span_id。故意注入三种故障:工具超时、工具返回过期数据、模型忽略拒绝信号。检查Trace能否指出首个偏离点,且日志不包含真实手机号、支付凭证和密钥。
典型错误是只在日志中记录“调用refund成功”,不记录订单状态版本、幂等键和授权人。这会让测试误以为操作合法。修复时补上可关联的业务状态引用,并把“操作是否获准”与“接口是否成功”分开断言。其次,避免将整段提示词和原始用户隐私内容永久写入日志;可以存脱敏后的输入摘要和受控访问的原始样本引用。
当同一任务的输出措辞变化很大时,建议优先比较状态和动作,而不是逐字比较对话。可以将事件规范化为“检索请求、检索结果标识、权限判断、业务动作、终态断言”几类,再与允许的状态迁移对照。模型可以换一种说法,但不应跳过授权、重复提交或把失败状态报告成成功。这样既保留语义变化的空间,也让回归断言稳定地落在业务不变量上。
结论
Trace不是为了把系统日志堆得更长,而是让每次Agent任务能被定位、解释和复现。测试报告至少要回答:它接收了什么、执行了什么、环境如何变化、哪条规则判定失败。将最终答案、工具调用和状态证据连起来,测试工程师才能把“模型偶尔不稳定”拆成具体的可修复问题。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料,主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容,侧重测试实践、工具应用与工程经验整理。
更多推荐

所有评论(0)