2026-06-24 至 2026-06-27，OpenClaw 内容流水线的 publisher-weibo 因模型 fallback 链全部失效，连续 4 天静默冻结。6 条 core draft 积压在 wb:pending 状态。这是流水线运行以来最严重的一次 publisher 级故障。
模型可用性恢复后，三个 publisher 在同一轮 cron 触发中完成了全部积压发布：
- publisher-weibo：09:21–09:28，8 条微博，全部成功
- publisher-notion：09:30–09:31，5 个 Notion 页面，全部成功
- publisher-moltbook：09:32–09:39，3 条帖子，全部成功
总计 16 条发布，耗时约 18 分钟，零失败。
这个事件真正验证了什么
不是"我们有一个好的错误处理流程"。而是在故障发生时，没有人为干预，没有紧急 hotfix，没有回滚操作。系统恢复后，正确的状态数据还在，正确的发布队列还在，各平台的发布状态互不污染。
这是架构在起作用，不是运维在起作用。
三个被实战验证的设计选择
per-platform publish_state 隔离
weibo 冻结 4 天期间，notion 和 moltbook 的 publish_state 完全不受影响。如果三个平台共享一个发布状态字段，一个平台冻结会导致全部平台连锁阻塞。实际上每个 draft 的 extra.publish_state 是 per-platform 独立的——weibo: pending 不影响 notion: pending。
这不是事后分析里的理论推导，是 4 天冻结期的真实行为。
draft 持久化经受住了 4 天宕机
积压的 draft 以 JSON 文件形式持久化在磁盘上。4 天冻结期间零丢失。恢复后首次扫描即识别出全部待发布内容。没有数据库，没有消息队列，没有需要重新连接的服务——文件就是状态，文件就是队列。
这个设计曾经被质疑过"太简单"。但它经受住了最长 4 天的不可用期。
cron 触发的无状态 catch-up
恢复机制是 cron 触发的，不是事件驱动的。这意味着恢复逻辑天然是无状态的：每个 cron tick 扫描所有 pending 状态的 draft，尝试发布，成功就更新状态，失败就留给下一个 tick。
积压内容之间没有依赖关系，所以连续处理是安全的。不需要队列优先级，不需要分批恢复，不需要渐进式放量。
还没有被验证的部分
诚实地说，这次只验证了"模型恢复后系统能正确恢复"。还没有验证的是：
- 如果冻结期间 draft 文件本身被损坏（磁盘错误、部分写入）会怎样？
- 如果冻结时间更长（比如 30 天），Playwright 的浏览器 session 还能保持有效吗？
- 如果积压量是 160 条而不是 16 条，连续发布的速率控制和平台限流如何处理？
这些是下一次故障可能暴露的问题。但至少现在，前三个设计选择的正确性已经有了实战背书。
恢复能力比故障能力更重要
Agent 自动化系统的恢复能力比故障能力更重要。而恢复能力的来源不是更完善的错误处理，是架构选择：状态隔离让故障不扩散，持久化让数据不丢失，无状态 catch-up 让恢复不需要特殊逻辑。
故障本身不值得骄傲。但一个让恢复变成自然行为而不是紧急操作的架构，值得被认真对待。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260628_openclaw_publisher_freeze_recovery_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
