Agent 回放评测：用真实轨迹复现问题，而不是只重跑最终 Prompt

只保存用户最后一句 prompt，通常不足以复现 Agent 事故。多步骤任务会受到检索结果、工具返回、缓存命中、权限状态和模型参数的共同影响。某次线上失败可能是因为第二个工具返回了空数组，模型据此走了错误分支；单独重跑首句输入时，系统又拿到不同数据，问题消失了。

什么是可回放的轨迹

一条回放记录应保存任务输入、系统配置版本、模型与工具版本、每次工具调用的结构化请求和脱敏响应、授权决策、时间顺序以及最终状态。重点不是保存所有原始文本，而是保存能影响控制流的事实。敏感字段用稳定替身或哈希替换，确保同一轨迹每次回放仍可得到相同结构。

工具响应要区分“录制值”和“实时值”。离线评测默认使用录制值，避免第三方 API、数据库最新数据或网络波动影响结果。对于需要验证契约兼容性的测试，再单独启用受控集成环境。把两类测试混在一起，会让失败原因难以判断。

模型输出有随机性，因此回放需要固定模型版本、温度、工具列表和提示词版本，并记录随机种子或请求参数。即便如此，也不要假设每个 token 都完全一致。评估应该重点比较工具选择、关键参数、授权结果和最终业务状态，而不是逐字比较解释文本。

对允许多条正确路径的任务，定义可接受轨迹集合。例如先查询订单再查询物流，或者一次并行查询两个系统，都可以通过；但跳过权限检查或直接写入就不可以。这样的断言比单一“golden transcript”更接近真实 Agent 行为。

每次线上事故结束后，建立一个脱敏回放包：触发条件、失败前的上下文、预期保护措施和修复后的断言。不要只把事故写进复盘文档。若问题来自下游返回格式变更，就固定旧响应和新响应各一份；若问题来自工具重试，就固定超时后的状态查询结果。

回放包应有严重级别和失效日期。业务规则变化后，一些旧样本会不再适用，但不能悄悄删除。标记它为什么失效、由哪个新样本替代，才能避免团队为了让分数好看而缩小测试集。

把回放分为提交前的小集、每日完整集和发布前高风险集。小集关注最近改动的工具，完整集覆盖主要工作流，高风险集专门包含支付、权限、数据导出和跨租户场景。记录每个集的耗时、模型成本和不稳定率；不稳定的测试先修测试环境，不能因为偶发失败就忽略。

一套好的回放系统会让工程师在发布前看到“这次改动让哪些历史任务改变了行为”。它把多步骤 Agent 从不可解释的黑箱，变成可以像分布式系统一样进行回归、定位和演练的工程对象。

回放依赖的 fixture 需要像代码一样审查。每个录制响应写明来源系统、录制时间、脱敏规则和适用的工具版本。第三方 API 返回结构变化时，不要覆盖旧 fixture；新增一份并明确旧版本对应的兼容行为。这样才能判断新工具是主动升级，还是无意间破坏了既有 contract。

对于包含时间、随机 ID 或顺序不稳定字段的响应，使用规范化层替换为稳定占位符。规范化层必须在真实录制后运行，而不是手工编造“看起来合理”的响应，否则评测会失去和生产故障的关联。涉及安全事件的回放包应限制访问范围，并确保任何密钥、个人数据和内部地址都已从快照中删除。

回放结果建议保留可读摘要和机器可比较产物两份。摘要帮助 reviewer 快速看出计划变化，结构化产物支持 CI 做字段级断言。发生回归时，链接到具体 trace、工具版本和 fixture hash，工程师才能在几分钟内开始定位，而不是重新猜测当时发生了什么。

当同一轨迹偶发失败时，先比较配置、fixture hash 和工具调用边界，而不是立刻把样本标记为 flaky。真正的随机性应被隔离到可控制的变量；如果无法隔离，就把该场景移到集成测试并标注环境依赖。回放评测只有在失败可解释时，才值得成为发布门槛。

每次发布后也保留一小段真实流量的匿名轨迹用于比对。离线回放通过但线上分布变化时，这些样本能帮助团队快速补齐盲区，而不必等到用户投诉才知道评测集已经落后。