一次崩溃重启之后，那些"做了一半"的会话、子代理和后台任务，凭什么还能被认领回来？
报告概览
本期拆的是 OpenClaw 的重启恢复机制。网关进程消失之后，中断的会话轮次、子代理运行与后台任务各自走哪条路回来。
这从来不是一个"重启成功"的开关，而是一套带预算、带安全阀、带归属规则的认领流程。谁被救、谁被放弃、谁必须换人来救，都有明确判据。
值得写的原因是节奏。整个 9 月 OpenClaw 连续六个版本都在补同一件事，主线一贯，说明这是平台级硬骨头而非补丁清单。
报告的四个部分：中断如何被识别、三类工作各自归谁、预算与安全阀怎么设、以及哪些东西官方明确不救。
一、为什么是现在
判断一个 Agent 平台是否成熟，先看它崩了之后会怎样。
早期的 Agent 平台只回答一个问题：这一轮能不能跑完。跑不完，工作就丢了。用户重发一遍，模型重做一遍，成本翻倍，中间还可能重复执行了副作用。
9 月的 OpenClaw 把这条线往前推了一大步。9.1 让更新失败有回退路径，9.2 让回复活过网关重启，9.5 留住被重启打断的排队消息。
到 9.6，主会话续跑、子代理进度与滞留会话回收才一起收口。一条主线贯穿六个版本，说明恢复是这一代的平台级命题。
规模也对得上。2026.9.6 收了 2,614 个 PR、350 位贡献者；对照 9.3 的 1,844 个 PR，投入在加速而不是收尾。
行业坐标因此清晰：Agent 平台的竞争焦点，正从"单轮能力"转向"跨进程的连续性"。谁能把中断变成可结算的事件，谁就能让 Agent 真正跑在无人看管的服务器上。
同期 Hermes 的取舍相反——它的定时任务明确承诺至多一次、绝不重放。两条路线各有代价，后文对照表里展开。
⚙️ 二、技术方案
中断是怎么被发现的
恢复的第一步不是续跑，而是知道"有东西断了"。OpenClaw 用三处标记覆盖三种死法。
第一处在准入环节。一个轮次被接受时，网关会在同一个数据库事务里写下投递认领记录。事务提交意味着这活我接了，进程再死也留痕。
第二处在优雅关闭。排空阶段给每个活跃 run 盖上恢复标记，然后才中止它。标记先于中止，保证不会出现"停了但没人知道"。
第三处在启动扫描。新进程会找出仍自称运行中、但已无归属进程的会话，顺带清理过期的转写锁。
三处合起来的效果是：无论崩溃、更新还是信号，中断都会落到一份可枚举的清单上。
恢复的三种归宿
清单上的每一项只有三种结果。
第一种是续跑。启动后约十秒的观察窗内，网关用一条合成的系统消息要求 agent 从现有转写继续。原文措辞很直白：上一轮被网关重启打断，请接着现有记录往下走。
第二种是定稿。记录的"中断时刻"已超过两小时的任务不再继续，直接收尾。注意判的是中断时长，不是任务总时长——一个跑了很久但刚刚被打断的任务仍然合格。
第三种是墓碑化。多次重试仍失败的会话被永久标记，防止恢复变成死循环。此后该会话再收到渠道消息会被拒绝，只能新建或重置。
预算与安全阀
自动续跑不是无限重试。每个中断周期配三次计费派发额度，跨重启保留。
机制的细节在于计费时点：先扣再试，明确拒绝时退款，结果不确定则保留扣费。额度耗尽即进入墓碑态，不允许靠重启把额度刷新回来。
启动对账另有自己的一套退避：瞬时失败最多重试三次，间隔从一秒起、上限三十秒。这套重试与上面三次派发是两个独立计数器，不要混为一谈。
网关还有一层进程级安全阀。五分钟内出现三次不干净启动，崩溃环路断路器会抑制通道插件自启，但控制面照常起来，方便人工介入。
子代理不自动重启
子代理的恢复规则在 2026.9.6 变了，值得单列。
它的运行记录存在共享数据库里，注册表能活过进程，中断的运行会被恢复。但恢复之后，是否继续这条子代理，交给主导对话的那个 agent 决定，不再自动重新拉起。
理由写在文档里：先确认旧工作确实停了，再判断某个动作是否已经生效，然后才决定重复还是替换。
孤儿恢复另有一个独立上限，本机实现是两次，触发后标记为卡死并记录原因。
后台任务与投递队列
后台任务在启动时对账：已完成的结果被取回，归属进程消失的运行在宽限期后标记为丢失，而不是永久挂起。
出站投递队列则在重启后排空或重试。重试预算耗尽时回收过期的生产者托管权；失败的投递不能再发，但会保留结算所需的信息，结算完成后才丢弃载荷。
还有一处细节防重复：只有可复用或崩溃归属不明的记录会留下最小凭据，用来阻止同一条消息被投递两次。
崩溃之外的两种中断：时钟与休眠
恢复机制不只服务崩溃，还要处理两类"进程还活着但时间错了"的情况。
主机休眠或虚拟机挂起后，网关会在约三十秒内识别出这次冻结。它会等已跟踪的工作空闲下来，再重连渠道并刷新缓存里的健康与在线状态。
一套配合机制是休眠租约：本地应用在宿主睡眠前先申请一个短租约，唤醒后交回。远端网关不随应用主机睡眠而挂起。
时钟跳变是另一条线。网关把恢复与清理的计时换成抗时钟变化的预算，避免一次时间校正把等待窗口拉长或提前触发。数据库锁释放后，会话清理也能接着往下走。
什么明确不救
文档里有一节"不会恢复的东西"，写得很干脆。
网关终端随进程结束。操作者自己的终端和 agent 开的终端都不救，因为它们只活在进程内。
排空窗口内新到的消息被显式拒绝，而不是悄悄塞进一个正在死掉的进程。这一条比"尽量不丢"更诚实。
会话层面也有排除项：子代理会话归子代理恢复管，定时会话由调度器按计划重跑，ACP 管理的会话归连接的 IDE 或客户端。它们都不进入主会话恢复。
还有一条容易忽略的运维边界：降级不等于回滚。旧版本可能读得动新格式数据，却在重写会话记录时丢掉确认过的通知，甚至损坏被扩展过的保留历史。
正确顺序是先做兼容的更新前备份，把备份恢复到独立的状态目录，再运行旧版本。若网关启动时遇到更新过的库结构，它会以退出码 78 退出，并停放受管的启动代理，防止无限重启。
️ 恢复路径总览
先看总览：中断被三处标记捕获，再由时长与预算两个判据分派到三种归宿。
三类工作的归属
再看归属：不是所有东西都由网关自己救。主会话、子代理、后台任务、投递队列各有一个 owner，终端则谁也不管。
重启后各类状态的存活矩阵
状态
存放位置
重启后行为
对话历史
每 agent 的 SQLite
不受影响，会话从已存转写继续
中断的主会话轮次
会话行与转写
启动后数秒自动续跑或对账
子代理运行
共享状态库
注册表随启动恢复，中断运行被续跑
后台任务
共享状态库
启动对账，孤儿恢复或标记丢失
出站投递队列
投递队列表
重启后排空，未送达回复重试
定时任务
定时存储
计划保留，调度器启动后重新武装
重启续跑通知
重启哨兵
向请求重启的那个会话派发一次性后续
网关终端 PTY
进程内存
随旧进程结束，不恢复
三种归宿的判据对照
归宿
触发条件
计费与重试
人工介入
自动续跑
中断在窗口内、额度未耗尽
每个周期三次计费派发额度，先扣后退
通常无需
定稿收尾
记录的中断时刻已过两小时
不再消耗额度
无需
墓碑化
反复恢复失败或额度耗尽
停止自动尝试
必须检查或替换会话
OpenClaw 与 Hermes 的恢复哲学对照
维度
OpenClaw
Hermes
中断的模型轮次
自动续跑，带计费派发预算
提升为待续接状态，等用户下一条消息触发
定时任务
调度器按计划重跑
至多一次，从不重放整段积压
渠道历史
保留并跨重启、跨重置存活
依赖会话库持久化
未完成工作的定位
可结算的债务，主动认领
明确不安排自动重试
共同点
都拒绝让不确定的副作用被静默重放
同
️ 实践建议
1. 把"恢复"当运维对象而不是运气：部署后至少制造一次强制重启，确认中断的轮次确实出现在恢复日志里。
2. 监控两个恢复指标而不只是健康检查。启动成功不代表任一被打断的工作真的完成了。
3. 涉及副作用的工具调用要自带幂等键。恢复能保证不丢，但"重复一次是否安全"仍由工具自己负责。
4. 两小时这条线要算进运维节奏。长时间无人看管的任务被中断后可能直接定稿，别等到第二天才发现。
5. 子代理恢复要人工兜底：既然 9.6 起不再自动重启，主导 agent 的判定就成了单点，重要批量任务应加一层外部校验。
6. 降级前先恢复升级前的备份。旧版本跑新格式数据存在损坏保留历史的风险，且不一定会拒绝启动。
趋势判断
第一，恢复会从平台功能变成平台契约。当下的判据是"什么时候不该救"，这类负面契约一旦写进文档，就会像幂等语义一样被下游依赖。
第二，计费式重试预算会扩散到更多资源。用"先扣后退"约束自动重试，比单纯限次更能反映真实成本，这类预算模型有理由被记忆写入、模型调用等环节借鉴。
第三，人工介入点会被压缩但不会被取消。墓碑态说明系统最终仍需要一个"人来确认"的动作，短期内自动化只能减少触发频率，不能替代这一步。
独立判断
这一轮恢复机制真正的创新点，不是"能续跑"，而是把中断定义为一种有额度的债务。
传统做法把重试当免费的重发，代价是日志里堆满"其实没成功"的成功。OpenClaw 把尝试变成先扣费的资产，等价于承认重试有成本、有上限、有失败的会计处理。
这解释了为什么反复失败的会话必须墓碑化而不是继续试——在债务模型里，无限重试本身就是一种坏账。
可证伪的预测：如果这套模型是对的，未来半年内 OpenClaw 应当会把这套"预算 + 墓碑"模式推广到至少一个恢复以外的场景，最可能的候选是记忆写入或模型故障转移。若半年内仍然只在重启恢复里出现这一次，说明它更像局部补丁而非通用范式。