AI Trace越记越长，为什么测试报告反而越来越说不清？

摘要：用OpenTelemetry语义约定作为共同语言，再把会话、工具、业务与回归证据分层。

OpenTelemetry的语义约定正在为GenAI和MCP等场景定义统一的属性、Span与事件表达，包括模型调用、工具参数、工具类型等。它解决的是“不同组件怎样用共同语言记录”，不是自动告诉团队一次Agent运行究竟该不该通过。

把这个机制放进客服Agent，可以构造一条典型Trace：用户要求取消订单，模型查询订单、调用取消工具、再次查询状态，最后回复成功。日志可能有几百行，延迟与Token都齐全，但如果没有记录工具参数来自哪里、取消前订单属于谁、后台是否真的只产生一次状态变更，测试仍然无法判定。

因此，可观测性是证据采集底座，业务断言才是质量结论。AI测试开发需要把Trace从“工程日志集合”升级为五层证据。

第一层：会话与版本

记录用户目标、会话ID、Agent版本、模型、提示词版本、Skill与工具Schema版本、环境指纹。不要把原始敏感文本无限期保存，可以保留脱敏摘要、数据类别和哈希。没有版本绑定，失败无法回放，线上趋势也无法对应发布。

第二层：决策与工具

每次工具调用记录工具名、参数、参数来源、开始结束时间、结果摘要、错误、重试和是否需要确认。最关键的是“参数来源”：订单号来自用户输入、检索结果、记忆还是模型推断？同一个正确参数，来源不同，可信度也不同。

OpenTelemetry为工具调用提供了统一的字段语言，但参数与调用结果可能包含敏感信息。需要补充说明的是，“参数来源”属于本文建议增加的业务质量字段，并非当前官方约定已经提供的标准属性。

第三层：业务状态

订单从待支付到已取消、退款从未创建到处理中，这些状态不能只藏在自然语言结果里。保存调用前后状态、业务主键、幂等键和不可变规则的判定。对金额只保存必要字段与校验结果，避免Trace成为隐私仓库。

第四层：质量指标必须能追到首错

任务失败不等于每一步都失败。报告要标出第一处偏离：查错订单、参数缺失、工具超时、重试重复、状态补偿失败，还是最终措辞不准确。任务成功率是管理视角；首错分布才指导工程修复。

延迟也要分段。模型思考慢、工具慢、重试多、沙箱启动慢，解决方法完全不同。成本同理，长上下文、重复检索和循环调用需要不同优化。统一Span让数据可比，测试报告负责把指标映射到修复责任。

Trace采样要同时考虑成本与隐私

全量保存所有Prompt、工具结果和文档内容，会快速推高存储成本，也可能把手机号、订单备注和密钥复制到观察平台。更稳妥的是默认记录结构与元数据，对高风险失败在授权范围内保留脱敏片段；原始数据通过受控引用回查，而不是永久嵌入Span。

采样也不能只保留错误。若只看失败Trace，团队无法知道正常路径的参数分布和时延基线；若只采最快成功，又会美化质量。可以保留固定比例的成功、全部红线失败、首次出现的工具组合和发布前后的对照样本。

Trace字段发生变化时要做Schema兼容测试。下游评测器若依赖工具名和参数来源，采集端重命名字段却没有迁移，会让质量指标突然归零。可观测数据本身也是接口，也需要版本、契约和回归。

第五层：失败怎样进入回归

线上失败Trace脱敏后生成一条Evaluation Dataset样本，至少包含输入摘要、前置状态、允许工具、禁止工具、预期副作用、首错类型和修复版本。修复发布时重放；后续模型、提示词或工具Schema变化时继续回归。

不是所有Trace都要长期保留。高风险失败、首次出现的模式和关键发布样本值得沉淀；大量重复成功可以采样和聚合。这样既控制成本，也让数据集不被同类样本淹没。

一份报告应该回答什么

最差的报告是贴一段JSON再写“疑似模型问题”。更好的报告写成：版本B在50条退款回归中出现3次未确认调用；首错均发生在订单查询返回多条候选后；工具参数来源被标为模型推断；未产生实际退款；建议修复为候选不唯一时强制人工确认。它把现象、证据、后果和动作连在一起。

职业能力怎样迁移

会写接口自动化的人已经掌握数据采集与断言；会做链路追踪的人熟悉Span和上下文传播；会做业务测试的人能定义状态与副作用。AI质量工程并不是抛弃这些能力，而是把模型决策、工具调用和业务状态串成一条可判断的证据链。

下一步可以从一条退款链路开始：给五类版本打标，记录参数来源和调用顺序，计算业务状态变化，标记首错，把一次失败转成回归样本。等这条链路能稳定回答“为什么失败、影响什么、如何复现”，再扩展到更多Agent。日志数量不代表质量，能把不确定行为压缩成可行动证据，才是Trace的价值。

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