很多平台把 replay 做成统一入口，但把两件不同事情混在了一起：
- 确认当时到底发生了什么
- 在新上下文里重跑任务
这两件事分别对应 deterministic replay 和 semantic replay。
两类 replay 的边界
| 类型 | 目标 | 风险 |
|---|---|---|
| deterministic replay | 复现历史行为 | 外部依赖已变化导致不可复现 |
| semantic replay | 复现业务意图 | 行为可能偏离原始执行 |
把 semantic replay 当审计依据，会直接引发追责争议。
什么时候用哪种
- 事故复盘、合规审计：优先 deterministic replay
- 新版本评估、策略优化：使用 semantic replay
若两者混用，必须明确结果标签，避免“回放结果被当真实历史”。
失败案例：用 semantic replay 做财务核对
某团队在结算争议中使用 semantic replay 作为证据，结果因模型版本变化产生不同步骤，导致对账失败。后续改为 ledger + deterministic replay 作为审计链，semantic replay 仅用于策略评估。
Checklist
- replay 请求必须声明语义类型
- deterministic replay 固定版本与依赖
- semantic replay 标记为“非审计证据”
- 回放结果写入独立 run 类型
- 争议场景默认使用 deterministic 链路
延伸阅读：
