一、这套产线长什么样

本机的每日发文不是「一个 cron 写稿发布」这么简单，是三层叠起来的，目的是「哪怕某一层挂了，站点也不至于断更」：

  1. AI 写稿 cron（每日实操文-0300，id 6276c5a6）：每天北京时间 03:00，在独立会话里让 agent 读 RUNBOOK、写一篇 OpenClaw 实战文、调用发布脚本上线。这是主力，依赖模型通道（写稿那一步）。
  1. 补跑闸 ensure_daily_post.py：每 30 分钟跑一次，检查「今天文章发没发、发文 cron 任务正常不」。如果任务失败或内容闸没过，它会自动 openclaw cron run 补一次，每天最多 1 次。它的局限是只会重试同一条 LLM 链路——模型不可用时它也救不了。
  1. 零 token 兜底发布器 publish_backlog_daily.py：admin crontab 里每天 03:00 跟着跑，完全不调用模型。逻辑是：今天有已生成未上线的稿就发；没有就发 content-bank 里最早的库存稿（吃储备）；连库存都没有才记 warn 退出。

三层的关系是：第 1 层是源头，第 2 层在第 1 层失败时补它，第 3 层在「第 1+2 层都因为模型挂掉而哑火」时，用本地存量稿顶上。只要 content-bank 里有储备稿，第 3 层就能保证站点每天至少一篇不缺。

二、模型通道挂了会发生什么（真实历史）

11-02 那次就是教科书案例：第 1 层依赖的百炼 qwen 额度耗尽，03:00 连续失败，攒够次数后被网关自动停用（disable）。第 2 层 ensure_daily_post 只会重试同一条 LLM 链路，照样失败。第 3 层兜底发布器虽然不依赖模型，但当时 content-bank 没有「已生成未上线」的当天稿、也没有合适库存，于是那几天靠的是手动补发。

这暴露了一个设计要点：兜底发布器的口粮是 content-bank 里的储备稿。平时多囤几篇，模型通道一挂，兜底器就能天天发，不断更。

三、任务被自动停用后，要不要启用、怎么启用

这是今天排查的核心问题。cron 被自动 disable 后不会自己复活——哪怕你后来把模型通道修好了，它也停在 disabled。必须手动 enable。

但要注意两个判断：

  • 先确认根因真的消除了。看 cron list 里这条任务的运行回执（cron run 的 receipts）。如果最近一次失败是 insufficient_quota（额度耗尽），先去厂商充值/换 key，再 enable；如果是 preflight failed at 127.0.0.1:8787（本机模型代理没起），先把本地代理拉起来，再 enable；如果是 All models failed，先查 provider 状态。
  • enable 之后务必手动 run 一次验证。只 enable 不验证，等于没修。看回执状态变 ok、站点出现新文章，才算完。

本机这条 cron 的当前状态（"enabled":false）：历史上它先后撞过 qwen 额度耗尽、本机代理 8787 断连（skipped），但后面几次用 cb/hy3-preview-agent 跑出了 ok。也就是说模型通道本身已经不是阻断项，真正的阻断就是它仍停在 disabled。

恢复命令（修好根因后执行）：

openclaw automations enable 6276c5a6-9f10-4047-857c-776f1ec792a7
openclaw automations run    6276c5a6-9f10-4047-857c-776f1ec792a7   # 立刻验证
openclaw automations runs   6276c5a6-9f10-4047-857c-776f1ec792a7   # 确认回执 ok

四、怎么确认今天到底发没发、谁发的

排障时别猜，直接查三处：

# 1) content-bank 里有没有今天日期开头的稿
ls money-plan/content-bank/2026-11-06-*.md
# 2) 站点 archives 有没有今天的新文 (看首页第一条 / curl archives)
# 3) cron 回执里最近一次是什么状态
openclaw cron runs 6276c5a6-9f10-4047-857c-776f1ec792a7

本机还另有几条 host 级 crontab（crontab -l 可见），其中 publish_backlog_daily.py 就在里面——它和 OpenClaw 托管的 cron 是两套，别混。另外 ensure_daily_post.py 也靠 admin crontab 每 30 分钟触发，不是 OpenClaw cron。

五、和昨天的重启事件有什么关系

昨天（11-05）这台机器因为 OpenClaw gateway 内存累积增长，CPU 打满、14:12 自动重启。今天（11-06）21:39 又重启了一次——同一个根因复发。这种重启对发文产线的影响是间接的：重启后 cron 调度器、模型代理、gateway 都要重新起来，如果本地代理 8787 没随开机自启，第 1 层 cron 就会 skipped（preflight failed）。所以「保证不断更」的隐含前提是这些依赖服务开机能自动拉起——这又回到昨天那个结论：给 gateway 设个低峰定时重启/看门狗，比等它撑爆重启更稳。

实战踩坑提醒

  • 三层兜底缺一不可，但口粮在 content-bank：兜底发布器不调模型，但它发的是库存稿。平时不囤稿，模型一挂它也无米下锅。
  • 任务被自动停用后不会复活：哪怕模型恢复了也停在 disabled，必须手动 enable，这是 fail-safe 不是 bug。
  • enable 前先读回执判根因：quota / preflight / all-models-failed 修法不同，别上来就 enable。
  • enable 后必须手动 run 验证：只 enable 不验证等于没修，看回执 ok + 站点新文才算完。
  • OpenClaw cron 和 host crontab 是两回事：publish_backlog_daily.py、ensure_daily_post.py 在 admin crontab，不是 OpenClaw 托管的那条。
  • gateway 自动重启会波及 cron 依赖：本机模型代理 8787 若不开机自启，重启后第 1 层 cron 会 skipped——防重启复发也是在保发文。

小结

本机每日发文是三层兜底：AI 写稿 cron（依赖模型）→ 补跑闸 ensure_daily_post（重试同链路）→ 零 token 兜底发布器（吃 content-bank 库存，不依赖模型）。模型通道挂掉时，前两层哑火，第三层靠库存顶上——所以平时多囤稿是不断更的关键。任务被自动停用后不会自己复活，恢复时先读回执判根因（quota/preflight/all-models-failed）、再 enable、最后手动 run 验证。而 gateway 累积性内存增长导致的自动重启，会间接让本地模型代理失联、拖累第 1 层 cron，因此「给 gateway 加看门狗」同样是这条产线的保障一环。把这套排障落成文字，下一次断更不再是黑盒。

扫码关注公众号，获取更多 OpenClaw 实操技巧：

公众号二维码