摘要用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都要长期保留。高风险失败、首次出现的模式和关键发布样本值得沉淀大量重复成功可以采样和聚合。这样既控制成本也让数据集不被同类样本淹没。一份报告应该回答什么报告读者最关心的问题报告必须给出的证据研发第一处错误发生在哪里首错Span、关键输入输出、工具返回、复现条件产品哪些用户任务受到影响受影响场景、业务状态、用户可见结果、影响范围管理这次发布是否应该继续回归趋势、红线失败、版本差异、门禁结论安全是否产生越权或不可逆副作用权限变化、敏感数据流向、外部动作、补偿结果最差的报告是贴一段JSON再写“疑似模型问题”。更好的报告写成版本B在50条退款回归中出现3次未确认调用首错均发生在订单查询返回多条候选后工具参数来源被标为模型推断未产生实际退款建议修复为候选不唯一时强制人工确认。它把现象、证据、后果和动作连在一起。职业能力怎样迁移会写接口自动化的人已经掌握数据采集与断言会做链路追踪的人熟悉Span和上下文传播会做业务测试的人能定义状态与副作用。AI质量工程并不是抛弃这些能力而是把模型决策、工具调用和业务状态串成一条可判断的证据链。下一步可以从一条退款链路开始给五类版本打标记录参数来源和调用顺序计算业务状态变化标记首错把一次失败转成回归样本。等这条链路能稳定回答“为什么失败、影响什么、如何复现”再扩展到更多Agent。日志数量不代表质量能把不确定行为压缩成可行动证据才是Trace的价值。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。