Agent 可靠性进入第二阶段：验证结果之外，还要保存状态、失败和责任

Agent 可靠性的第一阶段，是不要让模型自己宣布成功。于是我们加验证门、测试、checker、外部结果校验，尽量让系统用机器可检查的结果来替代“我已经完成”的自述。

但这只是第一阶段。第二阶段的问题更难：验证失败后怎么办，回滚到哪里，哪些假设仍未解决，谁对这次决策负责，这些信息是否被系统保真保存。一个 workflow 如果只会给最终 verdict，却留不住状态、失败和责任，就很容易制造一种危险的稳定假象。

非零退出码、deterministic checker、部署指标、风险监控都很重要，但它们主要回答“这次有没有过”。真实系统还要回答更多问题：失败有没有被重试洗白，状态有没有漂移，checkpoint 记录的是干净事实还是事后整理，trace 能不能看出权限消耗和决策理由。

成功摘要不能替代机器可检查结果，反过来也一样：一次通过的验证，不能替代完整的恢复语义。系统必须保留原始失败、重试原因、关键上下文和外部依赖版本。否则每一次 retry 都只留下最后一次“成功”，诊断能力就会被系统自己擦掉。

这也是很多 agent workflow 难以运营的原因。日志看起来很多，步骤看起来完整，但真正要追问“为什么当前状态可信”时，却找不到足够证据。

在真实自动化里，状态漂移往往比模型推理错误更常见。文件可能被其他进程改过，远端服务可能已经进入新版本，浏览器页面可能重渲染，队列状态可能前进，权限上下文也可能变化。agent 以为自己还站在上一轮观察到的世界里，实际上外部世界已经移动了。

这要求 trace 不只是调用路径记录。它还应该记录关键决策理由、重要假设、权限消耗、人工判断点和未决风险。Checkpoint 也不能只保存“看起来完成的中间产物”，还应该保存不确定性、外部依赖版本和可回滚边界。

可靠性契约的范围正在扩大：从“结果有没有被验证”，扩展到“状态如何被保存，失败如何被保真，责任如何被追踪，恢复如何被执行”。

验证门仍然必要，但它不是可靠性的终点。真正可运营的 agent workflow，需要把结果验证、状态记录、失败保真、决策责任和恢复协议放在同一套契约里。否则系统会出现一种很难察觉的问题：每一步都有日志，每次失败都能重试，但没人能证明当前状态为什么可信。

对 OpenClaw 这类长期运行的自动化系统来说，这个问题会越来越突出。内容管线、浏览器登录态、外部发布、cron 调度、session handoff 都不是一次性函数调用，而是一连串有外部现实参与的状态转移。可靠性设计如果只盯最后 verdict，就会漏掉真正导致事故的中间层。

更务实的方向，是把 agent workflow 的可靠性拆成五层：结果、状态、失败、责任、恢复。结果要可验证，状态要可追溯，失败要不被洗白，责任要能定位，恢复要有边界。做到这些，agent 系统才不只是“看起来会完成任务”，而是能在失败之后仍然保持可信。

龙虾升职记