摘要

面向多轮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、任务版本、工具名称、输入输出摘要、开始结束时间、错误类别和状态快照引用。敏感字段需脱敏。

一条可复用的排查路线

第一步，确认任务和系统版本是否一致：Agent版本、提示词、工具Schema、网页构建版本、数据集快照都要可追溯。第二步，沿Trace从根Span看每次模型决定，找到第一次偏离预期的不变量，而不是先看最后错误。第三步，核对工具真实输入与返回，排除接口成功但业务状态没变化。第四步，对比动作前后的环境快照。第五步，重放同一任务，确认问题稳定出现或记录波动范围。

如果轨迹中模型选择了正确工具、参数也正确，但工具返回旧状态，优先检查环境一致性和缓存；若工具结果正确而下一轮模型忽略它，关注上下文拼接和窗口截断；如果工具被拒绝，确认权限配置是否预期；若最终断言失败但所有操作都符合规则，可能是验收标准不完整。这个排查顺序能避免把所有失败都归因于模型。

回归时应比较不变量，而不是逐字一致

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

例子：退款Agent可先查订单再查支付，也可能反过来，只要两项信息都齐全且状态满足条件；但不得在查到“已退款”后再次调用退款接口。测试集应记录允许路径集合和关键禁止路径。若流程变化超出集合，不一定立即阻断，但应进入人工复核并比较业务副作用。

如何建一个最小Trace实验

用一个模拟Agent执行“查询订单—确认是否可退款—生成退款草稿”的三步任务。每次运行保存JSONL事件：模型决策、工具参数、工具响应、环境状态摘要、断言结果。给每条事件稳定的run_id和span_id。故意注入三种故障：工具超时、工具返回过期数据、模型忽略拒绝信号。检查Trace能否指出首个偏离点，且日志不包含真实手机号、支付凭证和密钥。

典型错误是只在日志中记录“调用refund成功”，不记录订单状态版本、幂等键和授权人。这会让测试误以为操作合法。修复时补上可关联的业务状态引用，并把“操作是否获准”与“接口是否成功”分开断言。其次，避免将整段提示词和原始用户隐私内容永久写入日志；可以存脱敏后的输入摘要和受控访问的原始样本引用。

当同一任务的输出措辞变化很大时，建议优先比较状态和动作，而不是逐字比较对话。可以将事件规范化为“检索请求、检索结果标识、权限判断、业务动作、终态断言”几类，再与允许的状态迁移对照。模型可以换一种说法，但不应跳过授权、重复提交或把失败状态报告成成功。这样既保留语义变化的空间，也让回归断言稳定地落在业务不变量上。

结论

Trace不是为了把系统日志堆得更长，而是让每次Agent任务能被定位、解释和复现。测试报告至少要回答：它接收了什么、执行了什么、环境如何变化、哪条规则判定失败。将最终答案、工具调用和状态证据连起来，测试工程师才能把“模型偶尔不稳定”拆成具体的可修复问题。