很多平台把 replay 做成统一入口，但把两件不同事情混在了一起：
- 确认当时到底发生了什么
- 在新上下文里重跑任务
这两件事分别对应 deterministic replay 和 semantic replay。
如果你只记住一句话：
deterministic replay 用于“还原事实”，semantic replay 用于“验证策略”。
两者服务目标不同，证据效力也不同。
两类 replay 的边界
| 类型 | 目标 | 结果定位 | 主要风险 |
|---|---|---|---|
| deterministic replay | 复现历史行为 | 审计证据 | 外部依赖不可复刻 |
| semantic replay | 复现业务意图 | 评估样本 | 行为与历史偏离 |
把 semantic replay 当审计依据，会在争议场景中直接失去证据可信度。
双轨回放架构建议
建议平台层面明确双轨：
- Audit Replay 通道：冻结 model/prompt/tool/version，尽量复刻历史条件。
- Evaluation Replay 通道：允许替换版本，用于策略与质量评估。
这两个通道必须在 run 类型、日志、报表层彻底隔离。
决策规则：什么时候用哪种
| 任务类型 | 推荐回放 |
|---|---|
| 合规追责 | deterministic replay |
| 客诉仲裁 | deterministic replay |
| 新版本对比 | semantic replay |
| 提示词迭代 | semantic replay |
默认策略应是“争议场景优先 deterministic”。
失败案例：用 semantic replay 做财务核对
某团队在结算争议中使用 semantic replay 作为证据。由于模型版本变化，步骤序列和工具调用次数发生变化，最终和历史账单不一致，财务与工程团队各执一词。
修复动作：
- 结算争议统一切换到 deterministic replay。
- 引入 run ledger 的版本快照字段。
- semantic replay 结果强制标注“非审计证据”。
实施细节：如何提高 deterministic 成功率
- 固定 model route、prompt 版本、tool schema 版本。
- 冻结关键输入快照（上下文切片、策略决策、依赖响应摘要）。
- 对不可复刻依赖使用 recorded stub，并注明证据等级。
没有版本冻结，deterministic replay 只是名字 deterministic。
指标建议
- deterministic replay 可复现率
- semantic replay 质量提升率
- 回放结果与 ledger 一致率
- 回放请求类型分布（审计/评估）
可复现率持续下降，通常意味着版本治理或依赖快照策略正在退化。
证据等级要写清楚
不是所有 replay 结果都具有同等可信度。建议定义证据等级：
| 等级 | 条件 | 可用于 |
|---|---|---|
| A | 固定版本 + recorded dependency + ledger 对齐 | 审计、仲裁 |
| B | 固定版本 + 部分依赖模拟 | 工程复盘 |
| C | 新版本 semantic replay | 策略评估 |
如果团队不定义证据等级，业务方很容易拿 C 级结果去做 A 级决策。
依赖快照不必保存一切
为了 deterministic replay，很多团队误以为要保存完整外部响应。更现实的做法是保存“决策必要摘要”：
- policy decision 的输入与输出
- tool call 的状态码、关键字段、版本
- 外部资源的 hash 或引用 ID
- 人工审批时看到的证据包版本
这样既能控制存储成本，也能保留足够审计价值。
回放测试样例应该进入发布门禁
每次升级 model、prompt 或 tool schema，都应跑一组 replay 样本：
- 历史事故样本
- 高成本 run 样本
- 高风险审批样本
- 高频失败样本
如果这些样本无法稳定复现，说明发布包还没有资格进入更大流量。
Checklist
- replay 请求必须声明语义类型
- deterministic replay 固定版本与依赖
- semantic replay 明确标注非审计证据
- 双轨回放结果写入独立 run 类型
- 争议场景默认 deterministic 链路
- 回放报表区分“事实还原”与“策略评估”
延伸阅读：
