Agent 会话回放的目标不是重播一场聊天，而是解释一项工作为什么这样处理、实际做了什么、最终是否完成。用户看到的是对话，运营人员需要的是任务证据链，这两者不能混为一谈。
一条完整回放要有九段
- 触发：谁在什么时间，以什么事件或请求发起任务。
- 业务对象：关联的客户、订单、项目、合同或工单 ID。
- 读取：访问了哪些知识与系统记录，数据截止到什么时间。
- 判断：采用了哪条规则，缺失或冲突信息是什么。
- 计划：准备执行哪些步骤，哪些步骤需要等待或人审。
- 动作：调用了什么工具，作用对象和允许字段是什么。
- 确认：谁批准、驳回或修改了关键动作。
- 回读：重新从目标系统取得什么状态与回执。
- 终态：任务完成、挂起、转人工还是失败，下一责任人是谁。
只要缺少业务对象和回读，回放就很容易变成“模型说自己做完了”的自述。
前台看业务步骤，后台看技术证据
业务人员不应被 request ID、JSON 和模型参数淹没。前台可以按“读取资料—核对规则—等待确认—更新系统—复查结果”展示，并为每一步保留一句结果。运营后台再展开知识版本、工具参数、错误码、耗时、Token 和原始回执。
| 角色 | 默认需要看到 | 不必默认展开 |
|---|---|---|
| 业务 Owner | 对象、规则、结果、待处理项 | 原始模型消息 |
| 一线人员 | 需要确认的动作与影响 | 全部调用日志 |
| Agent 运营 | 决策摘要、异常、版本、评测 | 与任务无关的系统日志 |
| IT/管理员 | 连接、权限、错误码、写入回执 | 业务长篇解释 |
这样既保留证据，也避免让每个人都面对同一面“日志墙”。
回放必须能从结果反查过程
实际排查往往不是从会话开始，而是从一张错单、一条异常付款或一封错误邮件开始。因此业务对象应保存任务 ID，任务记录也应保存业务对象 ID，支持双向跳转。否则出了问题，只能靠时间和关键词猜是哪一次执行。
对长任务，还要记录检查点、租约、外部等待和恢复次数。会话断开不等于任务结束，详见Agent 长任务怎么持续运行。
用三种问题验收回放
- 业务人员能否在一分钟内判断工作是否完成？
- 运营人员能否定位错误来自知识、规则、模型、连接、权限还是外部等待？
- 审计人员能否确认敏感动作由谁授权、写了什么、结果是什么？
三问都能回答，回放才不是装饰功能。需要把回放、指标与企业系统做成统一运营面，可从企业 AI 管理后台和企业 AI 落地工程继续梳理。
回放里的证据要能长期复现
只保存一个会变化的网页链接或知识库地址，半年后可能已经指向新版内容。关键任务应记录当时采用的来源版本、摘要指纹、业务记录 ID 和回执；敏感原文可以继续留在原系统，回放保存受权限保护的引用。这样既避免复制大量隐私数据，也能证明当时依据的确切版本。
工具动作要保留经过脱敏的关键参数和响应，而不是只写“调用 CRM 成功”。例如更新了哪个客户、允许修改哪些字段、写入前旧值是什么、写入后回读什么。对于对外发送、金额和权限动作，还要关联批准记录。
回放不等于无限保存
不同任务的保留期可以不同：一般问答、内部操作、合同与财务动作的审计价值不一样。平台应支持按组织政策设置保留期、导出、法律保留和到期处理；删除原始内容后，统计指标也要避免继续泄露敏感信息。
同时限制谁能看回放。直属负责人未必有权查看员工全部个人会话，平台管理员也不应默认读取客户业务内容。访问回放本身要进入审计。
用故障演练检验真实性
验收时主动制造三种情况：工具超时后结果未知、人工驳回后重新提交、知识版本在任务中途更新。回放应清楚展示系统没有重复写入、驳回意见怎样影响后续步骤、运行中任务仍采用哪个版本。能经得住这些演练，才具备事故复盘价值。
