OpenClaw 工作流稳定以后，每次改提示词、工具、知识库或 SOP，都可能带来回归问题。新版本修好了一个场景，却把旧场景答坏，这在 Agent 项目里很常见。只靠上线后观察，发现问题通常已经晚了。
回放评测的价值，就是用同一批历史样本反复跑新版本，看看行为有没有变坏。它可以和 失败样本库、变更单、上线验收 放在一起。
样本不要只选理想问题
回放评测最怕样本太干净。真实生产里的问题往往包含缺字段、歧义表达、过期资料、权限拒绝、工具超时和用户追问。只用理想问题测试，分数会很好看，但上线后还是会出事。
更好的样本来源是历史失败、人工接管、客户投诉、回滚记录和高频问题。这些样本才代表系统真正需要扛住的场景。
期望结果要写到行为层
评测不是只看答案像不像。对 Agent 来说，还要看它有没有查正确知识库、有没有调用不该调用的工具、有没有在低置信度时请求人工确认、有没有保留证据。否则回答文字相似，也可能执行路径已经变危险。
这一步可以参考 运行证据包 的字段，把输入、工具轨迹、关键判断和输出结果都纳入评测。
每次变更都要留下版本号
回放评测必须知道自己在比较什么。提示词版本、知识库版本、工具白名单版本、模型路由版本，都应该写进记录。没有版本号，后面只会看到“昨天还好，今天不行”，却不知道到底是哪次改动造成的。
如果团队已经维护 SOP 版本库，可以把回放结果和版本库绑定，形成一条可追踪的变更链。
分数之外要看回归清单
平均分提升不代表可以发布。一个高风险样本从通过变成失败，可能比十个低风险样本略有提升更重要。回放评测要输出回归清单：哪些旧样本变差，变差原因是什么，是否阻止上线。
对退款、外发、权限、删除这类客户可见动作，回归样本的优先级要更高。
总结
OpenClaw 回放评测的核心，是用同一批历史样本反复验证版本变化。样本真实、期望清楚、版本可追踪、回归清单明确，提示词和知识库更新才不会靠运气上线。
