OpenClaw 工作流稳定跑了一段时间后，最危险的改动往往不是大版本重构，而是一次看似很小的提示词修改、工具权限调整或校验规则更新。改完当下看起来没问题，过几天才发现某类任务开始漏字段、误提醒或成本变高。
回放测试就是为了解决这个问题。它用过去真实跑过的任务，在不写入生产系统的前提下重新跑一遍新版本，然后对比旧结果和新结果。它可以接上 Agent 变更管理、工具输出校验 和 运行日志。
先准备历史任务集
回放测试不能只挑最顺利的任务。历史任务集里要有正常任务、边界任务、失败任务和人工接管任务。这样才能看出新版本是否只在简单场景表现好，一遇到异常就跑偏。
每条历史任务至少要保存任务输入、上下文来源、工具返回、旧版输出、人工修改记录和最终业务结果。没有这些字段，回放只能重跑，不能判断新旧差异是否有意义。
回放时默认只读
回放测试必须和生产写入隔离。即使历史任务里包含 CRM 更新、邮件发送、权限修改，也只能模拟调用或写入测试环境。否则测试本身就可能造成重复发送和重复写入。
这和 OpenClaw 只读模式 一样，先观察差异，再决定是否放开写入。回放阶段的目标是发现风险，不是证明自己一定能上线。
对比报告要看业务差异
回放测试不要只看文字相似度。更有价值的是业务字段差异：是否漏掉风险信号，是否多开了权限，是否改变了负责人建议，是否把未确认问题写成确定结论，是否增加了工具调用成本。
对比报告可以分成三类：明显改善、无明显变化、需要人工复核。不要追求所有差异都自动判断，关键是把需要人看的地方挑出来。
通过后再灰度发布
回放测试通过，不等于马上全量上线。建议先选低风险任务灰度运行一段时间，观察错误率、人工修改率、工具调用成本和用户反馈。稳定以后再扩大范围。
如果灰度中发现问题，要能回到旧版本。这里可以接上 恢复演练 和 熔断暂停机制，避免新版本在生产里持续放大错误。
总结
OpenClaw 回放测试的核心，是用历史任务提前暴露回归风险。提示词、工具权限、校验规则和模型配置每次变更，都应该先经过只读回放、差异对比、人工复核和灰度发布，再进入正式流程。
