当用户说“昨天还能用，今天同样的问题就不行了”，你最需要的不是再问一遍，而是能把那次失败 run 原样拉出来看。
这就是 Session Replay 的价值。
它不是简单的对话回放，而是把一次 run 里的输入、策略、工具调用、状态迁移和输出重新串起来，让团队能回答三个问题：
- 模型当时看到了什么
- 系统当时允许它做什么
- 它是在哪一步偏离了预期
建议先看 AI Agent 可观测性与 Tracing 实战、AI Agent 事故响应手册、AI Agent 状态机设计指南 和 AI Agent 评估框架完全指南。
一、为什么只看聊天记录不够
很多 Agent 故障表面看是“回复不对”，但真正的原因常在聊天记录之外：
- 上下文裁剪把关键约束删掉了
- 工具返回不完整，模型却继续推理
- 状态机已经进入错误状态
- policy 层临时放开了某个工具权限
如果 replay 里没有这些层，复盘就只能靠猜。
二、一次可用的 replay 至少要包含什么
| 模块 | 必须记录的内容 |
|---|---|
| 输入层 | 用户输入、系统 prompt、上下文快照 |
| 决策层 | 模型选择了哪些工具、为什么进入该路径 |
| 执行层 | 工具请求、响应、错误码、耗时 |
| 状态层 | run 状态迁移、审批节点、重试记录 |
| 输出层 | 最终输出、被拦截输出、降级输出 |
Replay 的核心不是“全都存”，而是“能重建关键决策链”。
三、典型失败案例：升级后只在长会话里退化
某个客服 Agent 换了新的上下文裁剪策略后，短会话一切正常，但长会话投诉变多。
如果只看最终聊天记录，很难发现问题。
回放后才看到：
- 第 8 轮后，摘要把用户的一条关键约束吞掉了
- 第 10 轮模型开始调用默认工具而不是用户指定工具
- 第 12 轮进入自动执行路径，最终触发错误动作
这类问题没有 replay 基本不可能稳定复现。
四、Replay 最适合解决哪几类问题
- 线上偶发退化
- Prompt 或 policy 版本升级后的行为差异
- 工具 schema 更新后的兼容性问题
- 事故复盘与值班交接
它不只是调试工具，也是评估和治理工具。
五、如何把 replay 用到日常工程里
推荐三个实践：
- 高价值失败 run 自动入库
- 每次 prompt / policy / tool 版本变更后，抽样回放旧 run
- 与 eval dataset 联动，把 replay 样本沉淀成回归测试
这样 replay 才不只是事故时用一次，而会变成持续改进系统的基建。
六、Session Replay 上线清单
- Replay 能还原输入、工具、状态和输出
- 失败 run 会自动采样保存
- 版本升级后能回放历史样本比较差异
- 高风险任务的审批节点可回放
- Replay 样本能沉淀到 eval dataset
