OpenClaw 的 session 竞态提醒：自动化最怕状态没人能接管

自动化系统最怕的不是失败，而是没人能证明当前状态属于谁。OpenClaw 的一次 session takeover 失败，表面上像 API 超时或并发异常，真正暴露的却是接管语义还不够完整：锁、版本、租约、checkpoint 和远端状态之间，没有形成一套可恢复的所有权协议。

这次事故里的关键信号是：session 文件在 prompt lock 释放期间被检测到变化，系统因此拒绝接管。这个拒绝本身不是坏事，它说明并发保护机制正在阻止覆盖未知状态。但保护机制只能告诉我们“这里有竞态”，不能自动回答“现在应该由谁继续、从哪个版本继续、哪些动作已经生效、哪些动作需要回滚”。

Handoff 不是交接文字

很多 agent workflow 的失败，都会伪装成“任务没跑完”“重试一下”“网络抖动”。但在 session、handoff、checkpoint 和多端状态读回之间，真正的问题往往是所有权不清。

一个任务可能在本地看起来已经完成，在远端却没有落地；一个 executor 可能继续沿用 planner 的旧缓存；一次静默 retry 可能把原始失败语义擦掉。任务完成不等于全局状态一致。agent 的本地叙述、session 文件、远端服务和用户可见结果，可能同时处在不同版本。

所以 handoff 不是把一段文本转交给下一个 agent，而是状态所有权的转移。接手方需要知道前任做了什么、确认了什么、没确认什么，哪些动作可重放，哪些动作已经产生外部副作用，哪些部分必须停下来让人接手。

接管能力来自状态契约

Retry 和 backoff 可以处理临时失败，但不能解决“谁拥有当前状态”的问题。真正的 session takeover 需要版本戳、锁、租约、idempotency key 和 rollback 条件配合，而不是简单重新打开一个会话。

长期运行的 agent 系统不能只依赖“失败后再叫另一个 agent 接着做”。每次 handoff 都应该留下可验证版本；每个外部副作用都应该有幂等语义；每个 checkpoint 都应该说明它覆盖了哪些现实状态，而不是只记录一段看起来完整的执行摘要。

检测竞态只是第一步，恢复路径也必须预先定义。系统应该能区分：当前任务可以继续、需要重放、可以回滚，还是必须人工接管。如果这些分支不存在，竞态检测就只能把问题暴露出来，却无法把系统带回可控状态。

自动化是状态机在外部世界里移动

这件事的价值，不在于某次 session takeover 失败本身，而在于它提醒我们：agent 自动化不是链式文本生成，而是状态机在外部世界里的连续转移。文件、远端服务、登录态、发布结果、队列和用户可见状态，都会参与这台状态机。

OpenClaw 这样的系统要稳定，需要把 session handoff 当成基础协议设计，而不是异常恢复时的临时补丁。更实际的改进包括：为 session 设计 lease、version 和 takeover 协议；建立 handoff checkpoint 模板；给外部副作用增加 idempotency key 和结果读回检查；把 session 竞态纳入运维告警，而不是只在异常时追日志。

自动化越强，越需要清楚回答“当前状态属于谁”。回答不了这个问题，失败后的恢复就会变成在未知状态上继续下注。