1. OpenClaw 自动化任务不触发先分清 cron 与 heartbeat 两条链路OpenClaw 的自动化能力本质上由两条独立的链路支撑一条是 cron 调度器负责在指定时间点唤醒任务另一条是 heartbeat 心跳负责在空闲周期里主动检查有没有待办事项。很多人本地部署完 OpenClaw 之后发现任务该跑的时候没跑心跳日志突然断了第一反应是去翻业务代码其实绝大多数问题都出在这两条链路的配置或状态上跟业务逻辑没关系。这篇内容面向的是已经在本地把 OpenClaw 跑起来、但自动化流程时好时坏的人。如果你还没部署建议先把 gateway 跑通再回来看。下面我会按先看全局状态 → 再查 cron → 再查 heartbeat → 最后核对时区的顺序把每一步的命令、正常输出长什么样、异常特征怎么读全部拆开讲清楚。你可以直接复制命令跟着敲边敲边对照自己的输出。需要先建立一个认知cron 和 heartbeat 是解耦的。cron 到点触发一次任务heartbeat 按间隔轮询一次状态。cron 没触发不代表 heartbeat 坏了heartbeat 被跳过也不代表 cron 停了。排查时一定要分开定位否则很容易在错误的方向上浪费时间。我见过有人因为 heartbeat 日志里出现 skipped就去改 cron 表达式结果越改越乱。另外提醒一句OpenClaw 的很多没反应其实是静默跳过——任务确实被调度了但因为交付模式是 none、或者目标通道没连上所以外部看不到任何消息。这种情况日志里往往有明确原因只是你没去看。所以排查的核心动作只有一个让日志说话。下面所有步骤都围绕这个原则展开。2. TaoToken 前置准备把模型调用链路先打通在深入排查 cron 和 heartbeat 之前有一个容易被忽略的前提OpenClaw 的自动化任务在触发后往往需要调用大模型来完成实际工作比如总结、生成、判断。如果模型调用链路本身是断的你会看到任务触发了但没结果误以为是调度问题。所以建议先把模型接入这一层确认好。我自己的做法是统一走 TaoToken 的 API 网关来管理模型调用这样 Base URL、Key、Model ID 三件套集中配置排查时只需要确认一处。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 这个不加 UTM。注册后在控制台生成 Key地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。拿到 Key 之后OpenClaw 的模型配置通常写在 settings 或环境变量里。以常见的 JSON 配置为例你需要保证三个字段对齐{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的Key, modelId: claude-sonnet-4-5 } }这里有个坑baseUrl 结尾不要多加/v1也不要漏掉协议头。很多人复制的时候带上了多余路径导致请求 404然后误判成 cron 没触发。Model ID 要和你实际想用的模型一致写错了会返回 model not found。如果你用的是 Claude Code 这类工具做编码辅助接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的 Base URL Key Model ID 对照。配置改完记得重启 gateway否则旧配置还在内存里。重启命令一般是openclaw gateway restart openclaw statusopenclaw status输出里如果能看到 gateway 处于 running、模型 provider 显示已加载说明前置链路没问题可以进入下一步排查调度器了。如果这一步就报错先解决模型接入别往下走。3. 可复制配置cron 与 heartbeat 的关键字段怎么写排查之前先把配置写对。OpenClaw 的 cron 和 heartbeat 配置分散在几个地方我整理了一份可以直接抄的片段你对照自己的配置文件改。cron 作业的配置一般长这样注意schedule、timezone、delivery三个字段[[cron.jobs]] id daily-report enabled true schedule 0 9 * * * timezone Asia/Shanghai command report.generate delivery channel channel feishu to ops-groupschedule是标准五段式 cron 表达式timezone不写就默认用网关主机时区。delivery none表示只内部执行不外发如果你期望收到消息却写了 none那就是触发了但没交付的典型原因。channel和to必须和实际通道配置对得上写错了会静默跳过外发。heartbeat 的配置在 agents.defaults 下面[agents.defaults.heartbeat] enabled true interval 30m activeHours 09:00-22:00 activeHours.timezone Asia/Shanghaiinterval不能为 0为 0 等于关闭。activeHours之外的时间心跳会被跳过日志里会写reasonquiet-hours。如果你希望 24 小时都跑就把 activeHours 去掉或者设成00:00-23:59。时区这块单独强调一下因为它是最高频的坑。agents.defaults.userTimezone如果没设置心跳会回退到主机时区cron 不带--tz时也用网关主机时区而 cron 的at计划里如果写了不带时区的 ISO 时间戳会被当成 UTC 处理。这三条规则不一致就会出现我明明设了 9 点结果下午 5 点才跑的现象。建议显式写死activeHours.timezone和 cron 的timezone别依赖默认值。配置改完用openclaw config get逐项确认别只看文件openclaw config get agents.defaults.heartbeat openclaw config get agents.defaults.heartbeat.activeHours openclaw config get agents.defaults.heartbeat.activeHours.timezone openclaw config get agents.defaults.userTimezone || echo agents.defaults.userTimezone not set最后一条如果输出Config path not found: agents.defaults.userTimezone说明这个键没设属于正常提示不是报错心跳会走回退逻辑。4. 验证请求用命令阶梯确认 cron 与 heartbeat 真的在跑配置写对只是第一步接下来要用命令验证运行时状态。我习惯按一个固定阶梯走从全局到局部避免漏项。先看全局openclaw status openclaw gateway status openclaw doctor openclaw channels status --probeopenclaw doctor会做一轮自检把明显的问题直接列出来比如配置缺失、通道未连接。channels status --probe会实际探测通道连通性这一步很关键因为交付失败往往卡在通道上。然后专门查 cronopenclaw cron status openclaw cron list openclaw cron runs --id daily-report --limit 20 openclaw logs --followcron status正常应该报告 scheduler 已启用并且有一个未来的nextWakeAtMs。如果看到cron: scheduler disabled; jobs will not run automatically说明 cron 在配置或环境里被禁用了去检查cron.enabled相关字段。如果看到cron: timer tick failed那是调度器滴答崩溃要翻它前后的堆栈日志。cron runs里每条记录应该是ok或者有明确的跳过原因比如reason: not-due——这表示你手动触发了但作业还没到期加--force才能强制执行。再查 heartbeatopenclaw system heartbeat last openclaw logs --follow正常输出里心跳应该是ran或者跳过原因你能看懂。常见的跳过原因有四个quiet-hours表示超出 activeHoursrequests-in-flight表示主通道忙、心跳被推迟empty-heartbeat-file表示 HEARTBEAT.md 没有可操作内容且没有排队的标记事件alerts-disabled表示可见性设置把外发消息压掉了。这四个都不是故障是设计行为理解清楚就不会误判。验证模型调用是否通可以顺手在模型对话页发一条测试消息地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 能正常返回就说明模型链路没问题问题一定在调度或交付层。5. 本篇常见错排查401、local proxy failed、reading choices 逐个击破排查过程中你会遇到一些具体报错我把最高频的几个列出来对照处理。401 Unauthorized / missing_scope / Forbidden这类是通道认证或模型 Key 的问题。先确认 TaoToken 的 Key 有没有过期、额度是否充足再去openclaw channels status --probe看通道凭据。通道的 token 和模型的 Key 是两套东西别搞混。401 出现在模型调用里就去 api-keys 页面重新生成出现在通道交付里就去通道配置里更新凭据。local proxy failed这个通常出现在网络出口配置上。检查你的 gateway 是否能正常访问外部 APIopenclaw doctor一般会给出提示。如果是本地代理配置问题确认代理地址和端口写对且代理服务本身在运行。注意不要配置来源不明的网络工具用合规的网络环境即可。reading choices 相关报错这多半是模型返回结构不符合预期常见于 Model ID 写错、或者用了不兼容的 provider 格式。回到第 2 节的 JSON 配置确认provider是openai-compatible、baseUrl是https://taotoken.net/api、modelId拼写正确。改完重启 gateway 再试。OAuth 相关报错如果你用的是需要 OAuth 的通道比如某些协作平台token 过期会报这个。重新走一遍授权流程把新的 token 写回配置。OAuth 的 refresh token 也要一并更新只换 access token 过一会儿又会失效。Codex auth.json 相关如果你在用 Codex 类工具认证信息写在 auth.json 里格式错了会直接失败。确保里面同时有 Base URL、Key、Model ID 三件套缺一不可。文件路径要和工具默认读取路径一致放错位置等于没配。CC Switch / Cline MCP 场景这两个工具接入时同样要写全三件套。CC Switch 的配置里 Base URL 填https://taotoken.net/apiKey 填你的 KeyModel ID 填你要用的模型。Cline 的 MCP 配置也是同理三个字段对齐才能通。少任何一个都会表现为连不上或调用失败。排查时养成一个习惯每改一处配置就重启 gateway 并用openclaw logs --follow盯一会儿日志。日志里的时间戳、错误码、堆栈上下文比任何猜测都可靠。6. 长期跑自动化把 Coding Plan 和接入文档用起来如果你只是偶尔跑一两个定时任务上面的排查够用了。但如果你打算长期跑自动化流程比如每天定时生成报告、定时巡检、定时同步数据那建议把模型调用和调度都规划好避免频繁出问题。长期编码和 Agent 类场景可以看 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 适合需要稳定模型供给的自动化任务。接入细节和参数说明都在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到配置问题先翻文档大部分字段含义都有解释。最后给一个实用技巧把openclaw cron status、openclaw system heartbeat last、openclaw channels status --probe这三条命令写成一个巡检脚本每天跑一次输出存到日志文件。这样你不用等到任务失败才发现问题提前就能看到nextWakeAtMs是不是空的、心跳是不是连续 skipped、通道是不是掉线了。自动化系统的稳定性靠的不是出问题后救火而是平时把状态盯住。