ARTICLE · 1301918
用 automations 给 OpenClaw 排定时任务,并在崩了时自愈 — 定时任务管理实战
一、今天发生的事：发文 cron 自己停了
早上看站点，发现 zyker.cn 已经两天没新文章。去翻定时任务的运行记录，才看到那条每天 03:00 的「每日实操文」已经被自动停用了——不是我关的，是网关在它连续失败 N 次之后，自己把它 disable 了。
为什么失败？运行回执里写得很直白：
bailian-cli (qwen3.8-max) returned a billing error —
your API key has run out of credits or has an insufficient balance.也就是：百炼（阿里云 DashScope）那张 qwen 模型的额度耗尽了。网关调模型写稿这一步直接挂掉，每天 03:00 跑一次失败一次，攒够次数触发了 fail-safe 自动停用。表象上你看到的心跳报错是 dashscope has auth issue，但根因不是鉴权失败，是额度（quota）耗尽——这两件事别混，修法完全不同：auth 是 key 错了/过期，quota 是钱花光了。
这件事本身，就是 OpenClaw 定时任务管理最值得写的实战样本。
二、OpenClaw 定时任务怎么配的
一条定时任务在 OpenClaw 里就是一个 automation，本质是一段 cron 表达式 + 一个要执行的动作（agent 回合、消息投递等）。本机的发文任务存这样一段配置（从网关状态库里读到的真实字段）：
{
"id": "6276c5a6-9f10-4047-857c-776f1ec792a7",
"name": "每日实操文-0300",
"enabled": false,
"schedule": { "kind": "cron", "expr": "0 3 * * *", "tz": "Asia/Shanghai" },
"sessionTarget": "isolated",
"wakeMode": "now",
"payload": {
"kind": "agentTurn",
"message": "你是匠。执行 zyker.cn 每日发文产线……"
}
}几个关键点：
schedule.expr是标准 5 段 cron， 0 3 * * *就是每天北京时间 03:00。
tz: Asia/Shanghai很重要——不写的话默认走网关时区，容易在错误的时间触发。
sessionTarget: isolated表示每次跑在独立会话里，不污染你的主聊天上下文。
动作是 agentTurn，也就是每次到点让 agent 自己读 RUNBOOK、写稿、发布一条龙。
常用管理命令（都在 openclaw automations 下，不需要 sudo）：
openclaw automations list # 列出所有定时任务及 enabled 状态
openclaw automations show <id> # 看单条完整配置
openclaw automations runs <id> # 看这条任务的运行历史/回执
openclaw automations run <id> # 立刻手动跑一次（调试用）
openclaw automations enable <id> # 重新启用（被停用后恢复用）
openclaw automations disable <id> # 主动关停三、失败自愈：连续失败为什么会被自动停用
这是今天最该记住的机制：OpenClaw 不会让一个一直失败的定时任务无限重试。攒够连续失败次数后，网关会把它自动 disable，并在回执里标记。好处很明显——
不会因为模型通道挂了就每分钟刷一次错误、白白烧调用；
也不会让你在不知情的情况下，站点的关键产线静默断更几天（至少日志里会有"已停用"的明确信号）；
把"该人工介入"的球交回给你，而不是假装还在正常工作。
但要注意副作用：任务被停用后，它就不会再自己跑了，哪怕你后来把模型额度充上了。必须手动 enable 一次，它才恢复 03:00 的节奏。今天我就是先充额度、再 enable，才让它回到正轨。
顺带说一句排查顺序：先 automations runs <id> 看最近一次回执的错误信息，再 providers list 确认是不是模型通道的问题，最后去对应云厂商控制台看 billing/quota。别一上来就重装或改配置——十次里有八次是额度或 key 的事。
四、怎么把任务救回来
链路恢复是两件事，顺序不能反：
第一步：修模型通道。如果是 quota 耗尽，去百炼/对应厂商控制台充值或换一张有余额的 key，更新到 OpenClaw 的 provider 配置里（key 不要明文贴进聊天，走网关的私密配置入口）。如果是 auth 失败，换正确的 key 或重签发。
第二步：重新启用任务：
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只有回执状态变 ok、站点出现新文章，才算真救回来。当时我还没充值，所以先手动补发了断更的文章，等额度到位再 enable——顺序灵活，但"验证"这一步不能省。
五、不断更的兜底：零 token 发布器
今天最值得记下的，不是"模型挂了"，而是即使模型挂了，站点也不该断更。为此本机还跑着一条不花任何 token 的兜底发布器 publish_backlog_daily.py（在 admin 的 crontab 里，每天 03:00 跟着 AI 任务一起触发）：
它的逻辑很朴素：
今天已经有文章上线 → 跳过，不跟 AI 任务撞车；
content-bank 里有 YYYY-MM-DD-开头但还没上线的稿 → 直接发布（覆盖"AI 写好了、发布步骤失败"）；
都没有 → 发最早一篇"未上线且与站内旧文标题重合度 < 0.5"的存量稿（吃库存）；
连库存都没有 → 只在日志里记一条 warn，不动站点任何文件。
关键点在于它完全不调用 LLM——写稿那一步才是模型依赖的环节，发布这一步纯本地脚本。所以模型通道再怎么挂，只要 content-bank 里还有储备稿，站点就每天有一篇上线。今天的断更其实暴露了一个更早该做的事：往 content-bank 里多囤几篇储备稿，让兜底发布器有粮可吃。
手动触发兜底也很简单：
python3 /home/admin/.openclaw/workspace/scripts/publish_backlog_daily.py --dry-run # 先看会发哪篇
python3 /home/admin/.openclaw/workspace/scripts/publish_backlog_daily.py # 真发实战踩坑提醒
- auth issue 和 quota exhausted 不是一回事
：心跳报 dashscope has auth issue可能是额度耗尽被厂商返回成鉴权错，别上来就换 key，先去控制台看 billing。今天的根因是 quota，不是 key 错了。
- 任务被自动停用后不会自己复活
：哪怕你当天下午充了值，它也停在 disabled，必须 automations enable一次。这是 fail-safe，不是 bug。
- enable 之后务必手动 run 一次验证
：只 enable 不验证，等于没修。看 runs 回执状态变 ok 才算完。
- 模型依赖的环节要配不依赖模型的兜底
：写稿靠 LLM，发布不靠。把"发布"和"写稿"解耦，模型挂了站点只是少新内容，不会整条链路死。
- 储备稿是兜底发布器的口粮
：content-bank 里没存货，兜底器也无米下锅。平时多囤 3-5 篇，断更风险直接归零。
- cron 的 tz 一定要显式写 Asia/Shanghai
：否则按网关默认时区算，03:00 可能跑在你的白天，和人工操作撞车。
小结
OpenClaw 的定时任务（automations）不是"设完就忘"的黑盒：它会因为连续失败自动停用，把介入权交还给你；排查时先看 runs 回执的错误、再查 provider 和 billing；恢复时先修模型通道、再 enable、最后手动 run 验证。而真正让站点"不断更"的，是把写稿（依赖 LLM）和发布（纯本地）解耦，再配一个零 token 的兜底发布器吃库存——模型挂了，只是少点新内容，链路本身死不了。今天这场排障，本质上是一次活生生的定时任务自愈教学。
关注公众号，获取更多 OpenClaw 实操技巧
