如果你和我一样一开始把OpenClaw当成了一个“你问一句、它答一句”的命令行AI助手那定时任务可能是你第一次觉得这玩意儿真的能顶一个人用的转折点。我最初折腾OpenClaw定时任务想要的效果特别朴素每天早上8点手机自动收到一条消息告诉我今天有哪些会、出门要不要带伞、路上大概堵不堵。当时翻了不少资料、试了好几版配置才发现这东西的坑不在“会不会写cron表达式”而在于对定时任务运行机制的理解。这篇就围绕OpenClaw定时任务的配置展开把配置入口、核心字段、典型场景、排查思路一次说清楚给正在部署OpenClaw或者已经跑起来但任务不触发的朋友做个参考。1. 定时任务在OpenClaw中到底怎么运作的1.1 普通对话与定时任务两种完全不同的执行模型先说一个很多人没意识到的问题OpenClaw的定时任务和你在对话框里让它干活本质上不是一回事。普通对话是“人在回路”的你发一句指令模型生成回答你继续追问上下文一路累积遇到需要授权的动作它会现场问你。整个过程有你在旁边盯着出错了随时打断纠正。这种模式对模型的要求其实不高因为人本身就是最大的兜底。定时任务完全反过来时间一到调度器把一段预设好的文本丢给agentagent在没有人在场的环境下从头开始执行。没有上下文、没有交互确认、没有“等等我改一下指令”的机会。你配置任务时写的每一句话就是它当时唯一的行动纲领。我说句不好听的很多人的定时任务不生效不是配置语法错了而是把定时任务当成了“到点自动帮你打开一个聊天窗口然后等着你”实际上它是“到点替你把某件事干完”。打个比方。普通对话是领导当面交办“下午把这份合同看一眼有问题提醒我。”定时任务是领导留下一张便签“每周五下午5点把本周项目进度汇总一下按模板生成周报放到指定目录再把链接发给群里。”便签上没有的信息就是默认让你自己看着办。所以配置定时任务的第一原则是把prompt当成一份完整的便签来写。时间、场景、输出格式、操作边界、异常处理全都要写在里面。我后面给场景示例时会具体演示怎么写。1.2 提醒型任务与执行型任务别混为一谈OpenClaw的定时任务大体可以分为两类配置思路完全不同。提醒型任务最简单本质就是“到点发一条消息”。比如“每天早上8点提醒我吃维生素”“每小时提醒我站起来活动”。这类任务只调一次模型生成一段文字推送到你指定的渠道终端、网页、手机companion、Telegram等就结束了。成本低、失败率高不到哪去、排查也容易。执行型任务则是“到点跑一个多步骤工作流”。比如定时读取某个目录的日志文件、做汇总分析、生成Markdown、保存到一个新文件、再把消息推给你。这类任务会触发OpenClaw去调用工具、读写文件系统、调用外部API链路长、权限要求多、模型消耗也大得多。我实际使用中的体会是执行型任务最容易卡住的地方不是执行本身而是它执行到一半需要你确认。OpenClaw默认在很多场景下会谨慎一点拿不准就问用户。可定时任务触发的时候你大概率不在电脑前它一问任务就挂在那儿了后面排队的任务也跟着堵。解决办法是在prompt里明确写清楚边界比如“遇到磁盘不足不要问我跳过并记录原因”“如果某条日志解析失败单独列出来不要中断整个任务”。把自主完成度和容错策略提前交代好你的执行型任务才算真正完工。1.3 三种配置入口怎么选OpenClaw的定时任务配置入口我实际接触下来主要有三种配置方式适用场景灵活度适合人群面板/Automation里自然语言创建快速添加“每天早上8点提醒我……”这类简单任务中自动生成表达式刚上手、不想记字段的人配置文件手动编辑多步骤执行型任务、需要精确控制字段高所有参数都暴露部署过一段时间、追求可控的人对话里直接让OpenClaw“记住一个定时任务”临时任务低可追溯性差应急场景我的建议是组合使用简单提醒型任务直接用自然语言创建让OpenClaw自己解析时间和任务内容复杂执行型任务一定回到配置文件手写因为面板上能暴露的字段有限很多时候你想设置模型、超时时间、错误重试次数面板上没有只能改配置。顺带说一句如果你用过Spring Boot的Scheduled注解或者XXL-Job这类框架对OpenClaw的定时任务会很好理解但别用老思路去套。传统定时任务到点执行的是你写好的代码逻辑OpenClaw到点执行的是“一段自然语言agent的自由发挥”。前者的输出是可预期的后者每次执行结果都会有浮动。这是它灵活的地方也是你需要做更多兜底设计的地方。2. 配置文件里的定时任务字段与语法详解2.1 先找到你的配置文件在哪不同安装方式下配置文件的路径差异很大这可能是很多人第一步就懵的原因。我本机用二进制方式部署配置目录在用户目录下的.openclaw文件夹里用Docker部署的朋友则是把宿主机的某个目录挂载进容器也有人在/etc/openclaw下找。如果你不确定位置直接两个命令定位# 找到可能的配置目录 find ~ -maxdepth 4 -iname *openclaw* -type d 2/dev/null # 在疑似目录里搜索定时任务关键字 grep -ril schedule ~/.openclaw/ 2/dev/null搜到文件后先别急着改把整个文件备份一份。这个习惯能救你很多次——我有一次改坏配置整个agent启动都失败了后来是靠备份回滚的。2.2 核心字段逐个拆解下面这份配置是我当前部署版本上实际使用的结构如果你手里的版本字段名不完全一样别慌逻辑是共通的scheduled_tasks: - id: morning_briefing enabled: true schedule: 0 8 * * * timezone: Asia/Shanghai prompt: | 现在是早上8点。请生成一份简短晨报包含 1. 本日待办事项从 ~/work/todo.md 读取 2. 当前天气概况 3. 今日最重要的1条新闻 全文字数控制在120字以内用三段短消息发送。 channel: companion on_error: notify retries: 2 timeout: 180各字段用途id任务唯一标识。日志里定位靠它别随便填建议用有意义的英文名。enabled总开关。临时停用任务时改这个字段比删配置安全。schedulecron表达式决定什么时候触发。写法见2.3。timezone时区。强烈建议显式指定不要依赖系统默认。prompt任务的核心指令。就是上一章说的“便签”写多详细都不过分。channel结果推送到哪。常见值有terminal终端直接显示、companion手机App、telegram机器人、webhookHTTP回调。on_error任务报错时怎么处理常见策略有静默、通知管理员、重试。retries失败重试次数。注意如果任务本身没问题、只是网络抖动重试很管用如果任务逻辑有错重试只会重复烧token。timeout单次执行超时上限。执行型任务尤其要设防止agent卡在一个环节上无限等待。这里特别提醒一点prompt字段里不要写“随便”“尽快”这种模糊词。你要的是可预期的输出就把句式、条数、来源、保存位置全部钉死。我自己写过一条偷懒的晨报任务没限定字数结果某天模型发挥起来写了600多字长文直接刷屏。从那以后我所有任务prompt里都会带上格式约束。2.3 cron表达式写法与常用组合OpenClaw的cron表达式沿用的还是标准cron那套支持5段分 时 日 月 周。如果你的版本支持秒级前面会多一段但绝大多数的定时任务用不到秒级别给自己找麻烦。常用表达式我整理了一张表可以直接抄需求表达式每天早上8点0 8 * * *每个工作日8点0 8 * * 1-5每周一18:3030 18 * * 1每小时整点0 * * * *每15分钟*/15 * * * *每月1号9点0 9 1 * *周末晚上10点0 22 * * 6,0写表达式最容易错的有两处一是周和日同时指定时cron的行为在不同实现里有差异OpenClaw内部和其他工具可能不完全一致所以月/周尽量不要同时写二是“0 8”和“8 0”千万别搞反——前者是8点0分后者是凌晨0点8分我见过有人配错之后每天凌晨收到任务通知还以为是系统抽风。如果你跟我一样不喜欢记表达式可以直接在面板里用自然语言描述比如“每个工作日下午六点”OpenClaw会自动翻译成cron。但翻译结果未必是你心里想的那个所以务必生成后检查一眼特别是“工作日”和“周末”的边界。2.4 验证任务是否真的会触发配置写完先别急着等第二天早上验证太慢了。我的做法是临时把schedule改成一个几分钟后的时间比如当前时间是14:23就设23 14 * * *等它跑一次确认输出正常后再改回正式时间。这个方法看着土但能一次性验证三件事cron表达式是否正确、prompt是否会被正常解析、channel是否真的能推送出去。等你用熟了甚至可以把这个临时验证过程也做成一个定时任务脚本省得每次手动改。3. 三个高频实战场景从0到13.1 场景一每天早上8点的天气待办推送这是大多数人入门定时任务的第一个需求。先说实话天气和待办这种数据目前很多部署方案里OpenClaw可以直接联网获取但能不能拿到你日历里的日程取决于你给它配了多少权限。我给一个可以直接参考的配置scheduled_tasks: - id: morning_briefing enabled: true schedule: 0 8 * * * timezone: Asia/Shanghai prompt: | 你是我的晨间助理。请按以下步骤执行 1. 读取 ~/work/todo.md 中今天日期对应的待办事项 2. 查询本城市今天的天气重点关注降水概率和温度 3. 生成三段式晨报今日待办 / 天气提醒 / 一句话新闻 要求总字数不超过150字待办条数不超过5条语气简洁直接不要开场白。 channel: companion这里有个很关键的细节为什么在prompt里写“今天的待办”而不是“所有待办”因为模型的上下文窗口虽然大但让它自己判断“哪些是今天的”很容易误判。你把筛选逻辑写死它就按你的逻辑来准确性会高很多。这类任务属于低成本高收益型几乎每天都能用很适合作为你的第一个自建定时任务。3.2 场景二每周五自动生成周报草稿这个任务比晨报复杂一个量级属于典型的执行型任务。它需要读文件、分析内容、再写一个新文件OpenClaw要具备文件系统的读写权限。如果你在配置文件里没有相关授权任务跑到读写那一步就会停下来。我参考的配置结构如下scheduled_tasks: - id: weekly_report enabled: true schedule: 30 17 * * 5 timezone: Asia/Shanghai prompt: | 读取 ~/work/logs/ 目录下本周所有 .md 日志文件 按周报模板生成新文件~/work/reports/本周周报.md。 模板要求 - 按日期倒序列出本周完成的重点事项 - 每个事项标明状态已完成 / 进行中 / 阻塞 - 阻塞事项单独列出并给出你推测的阻塞原因 - 最后用3句话总结本周进展 生成完成后在终端输出文件绝对路径即可。 channel: webhook timeout: 600写这个任务时我踩过一个坑prompt里没告诉它“周报模板”长什么样结果它自己发挥生成的格式跟公司要求完全不一致。后来我在任务配置旁放了一个weekly_report_template.mdprompt里明确写着“严格按照该模板文件格式输出”。让agent对着模板做比自己描述模板可靠得多。另外注意我给它设了timeout: 600。执行型任务要读日志、思考、写文件可能要好几分钟默认的超时时间往往不够。别怕等待定时任务不是要它秒回而是要它把事情做完整。如果任务经常超时先看看是不是prompt里让它做的事太多比如同时读了几十个大文件这时候该砍需求而不是继续加长超时。3.3 场景三定时巡检“只在异常时说话”这个场景很有意思也是我目前用得最舒服的一个。定时任务不一定要每次都发消息很多时候我们希望它“安静地盯着出事才喊人”。实现思路很简单在prompt里告诉它“如果一切正常只回复ok不要推送只有当异常出现时才输出详细告警信息”。另外OpenClaw的channel配置通常支持“空输出不推送”配合prompt里的静默指令就能做到无异常时不打扰你。举个例子定时检查一台服务器上的服务是否存活scheduled_tasks: - id: service_watchdog enabled: true schedule: */10 * * * * timezone: Asia/Shanghai prompt: | 依次对配置文件中列出的3个服务地址执行健康检查。 全部服务返回正常时仅回复ok不需要推送。 只要出现任一异常输出以下内容 - 哪个服务挂了 - HTTP状态码或错误信息 - 你推测的1条最可能原因 - 建议执行的修复命令 异常信息必须在500字以内。 channel: telegram这类巡检任务的成本控制很重要。每10分钟跑一次如果每次都调大模型一天就是144次调用token消耗很可观。我建议这种纯检查类任务尽量拆成两步先用脚本做健康检查只有检测到异常时才把结果交给OpenClaw生成分析。也就是把OpenClaw定位成“异常分析器”而不是“探测器的替代品”。定时任务的调度器本身只是触发工具真正干粗活的可以是shell脚本OpenClaw只处理需要智能的环节。4. 定时任务不触发、重复触发怎么办排查链路4.1 第一板斧确认调度进程真的活着定时任务不触发大多数人第一反应是改配置但实际有相当高的比例是另一个原因跑OpenClaw的进程根本没起来或者起来之后崩了。OpenClaw的定时任务不是系统级cron它依赖主进程内部的调度器。你用systemd跑的就查服务状态用pm2跑的就查进程列表什么也没挂、只是开了个终端窗口跑openclaw serve的话窗口一关任务就没了。这可能是“我明明配了定时任务但它就是不动”的最高频原因。# systemd方式 systemctl status openclaw # pm2方式 pm2 list # 直接看进程 ps aux | grep -i openclaw如果你是在Windows上用WSL跑OpenClaw尤其要注意后台进程的存活问题。WSL里的进程不会像Windows服务那样开机自启我见过有人每次重启电脑后定时任务就消失后来给WSL配了开机自动执行脚本才解决。你可以把启动命令写进.bashrc、系统计划任务或者其他自启机制里确保宿主机一开机OpenClaw的进程就自动拉起来。热词里提到的“openclaw无法安全验证sl2环境请在PowerShell中运行wsl --status”这个提示本质上是WSL环境本身出了问题不是OpenClaw的锅。遇到就先在PowerShell里跑wsl --status和wsl --update确认默认版本是2、内核没有过期把底层环境弄干净了再回头看定时任务。4.2 时区错乱Docker、WSL、云服务器的三重坑你配了“每天早上8点”结果任务在下午4点跑了典型的时区问题。不同部署环境默认时区不太一样本机Linux一般是系统时区Docker容器默认是UTC云服务器你一租到手大概率也是UTCWSL会跟Windows同步但偶尔也会出偏差。解决方案很粗暴**在任务配置里显式写timezone字段不要依赖系统默认时区。**我在第2章的示例配置里全部带上了timezone: Asia/Shanghai就是为了一劳永逸。如果是Docker部署除了配置字段还可以把宿主机的时区文件挂进容器docker run -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro ...配好之后用这两个命令验证宿主和容器环境一致date -R timedatectl # Linux本机查看时区经验判断只要是“你以为的8点”和“实际的8点”差整8小时九成是UTC和北京时间的问题差1小时左右可能是夏令时或时区文件配置错乱。先在系统层面把时间对齐再谈任务配置不然改什么都白搭。4.3 重复触发同一个任务跑了两遍另一个常见现象是任务没有不跑而是跑得太多——每次都执行两遍。遇到这个先摸一下自己的配置来源是不是在面板上创建过又在配置文件里手动加了一遍两处有没有使用相同的任务id如果id相同调度器可能不会去重导致两个入口各自触发一次。我的教训是在Web UI里创建了任务后又去配置文件里加了一模一样的日志里同一时刻出现了两条相同id的执行记录推送消息也收了两遍。这类问题不算严重但很影响体验。更隐蔽的重复触发来自“重启补偿”OpenClaw重启时如果检测到上次有任务没有执行完某些版本会增加一次补偿执行。如果你正好赶在任务执行中重启了服务跑完之后它可能再补跑一次。严格来说这是特性不是bug但体验上就是重复了。日常防重复其实有两个土办法第一同一任务只维护一个配置入口要么面板要么配置文件别两边都碰第二任务内部实现幂等比如每周报这种任务把文件名带上日期本周周报-2025-06-06.md即使重复跑也只是覆盖同一个文件而不是产生两份伤害就可控了。4.4 从日志看执行链路三步定位卡点当任务既没触发、也没报错时直接看日志是最有效的手段。日志位置同样看部署方式常见的有~/.openclaw/logs/openclaw.log、journalctl -u openclaw、Docker的docker logs。我在排查时习惯把一条定时任务的完整生命周期拆成三段看调度有没有触发搜任务id看有没有“executing task”之类的记录。如果根本没有说明调度层面就没跑起来问题出在cron表达式、进程存活、时区上。模型有没有被调用搜LLM调用记录看prompt是否被正确发送、模型返回是否正常。如果调度记录有、模型调用没有可能卡在工具权限或前置步骤上。消息有没有推送出去搜channel的推送记录看最后一步成功与否。很多任务其实执行完了只是推送失败看起来像没跑。日志排查命令示例tail -f ~/.openclaw/logs/openclaw.log | grep morning_briefing journalctl -u openclaw -f | grep service_watchdog一次排查下来绝大多数问题都能在这三步里定位到。如果三步记录全都正常但你还是没收到消息那基本可以断定是channel配置本身的问题比如手机companion没在线、telegram机器人token失效、webhook地址填错。5. 进阶让定时任务与外部系统真正协同5.1 把结果送进业务系统webhook与机器人OpenClaw内置的channel覆盖了个人场景但如果你要让定时任务的结果进入工作流比如同步给团队群、写入内部系统最通用的方式还是webhook。配置思路不复杂把channel设为webhook在配置里指定webhook_urlOpenClaw执行完任务后会把结果以POST请求发出去。国内团队常用的企业微信机器人、钉钉机器人其实都支持webhook收消息把这个地址填进去就能把OpenClaw的定时产出送到工作群里。channel: webhook webhook_url: https://你的服务地址/hooks/xxx这里提醒一句安全事项webhook地址本质上是凭据不要直接明文写死在配置里建议用环境变量引用。我就是有一次把配置仓库当公开仓库传上去webhook地址泄露被陌生人刷了好多条消息。从那以后凡是涉及URL、token的配置一律走环境变量。如果你需要把任务执行结果存成结构化数据供其他系统读取可以让prompt要求agent把结果同时写成一个JSON文件再配合文件监听工具等于给外部系统开了一个数据接口。这个用法在需要数据沉淀的场景很实用比单纯发一条消息强得多。5.2 不只是定时还能被外部反向触发OpenClaw的定时任务本质是“时间到了调度器叫agent干活”但进阶一点你会发现只要外部能把HTTP请求打进来它也能当做一个“随时可调的agent执行器”。做法是在配置文件里暴露一个本地HTTP接口外部脚本、监控系统、甚至是家里的智能家居网关都可以在特定事件发生时请求这个接口让OpenClaw去执行预设的任务。比如公司服务器监控系统检测到磁盘超过90%时通过接口触发OpenClaw生成一份故障分析并推送给你。这类场景我们称之为“条件触发”比单纯定时更聪明。搭配思路是这样定时任务负责“固定节奏的巡检和整理”HTTP接口负责“突发事件的响应分析”两者共用同一套prompt模板配置成本并没有增加多少但OpenClaw能覆盖的自动化场景会大一圈。5.3 关联本地模型把高频任务的成本打下来定时任务天天跑如果全用强模型费用会比较可观特别是巡检、晨报这类高频任务。热词里提到的qwen2.5-3b关联到OpenClaw我实际配置过本地跑一个小参数模型处理简单任务完全够用速度还快。这里要理解OpenClaw的模型路由逻辑不同任务可以指定不同模型。配置里加一个model字段就行scheduled_tasks: - id: simple_reminder schedule: */30 * * * * model: qwen2.5-3b ... - id: weekly_report schedule: 30 17 * * 5 model: claude-sonnet ...我自己的分配原则是判断类、格式转换类、简单总结类用本地模型需要高质量写作、复杂推理、涉及多步决策的任务才用外部强模型。这样一来每天高频跑的任务几乎不花钱周报这种低频任务花点钱也无所谓。配置完之后记得在日志里看一眼实际走的是哪个模型本地模型有时会因为Ollama服务没启动而静默回退到默认模型不查日志不易发现账单倒是会很诚实。5.4 定时任务和知识库联动把“碎片输出”沉淀成笔记OpenClaw可以读取指定目录下的文件这就让它天然能做“自动笔记整理”的活儿。OBSIDIAN用户尤其适合这个玩法定时任务把零散消息、网页剪藏、聊天记录按规则整理成带元数据的笔记写进你的vault目录时间长了你就有一个自动积累的知识库。配置核心就两点第一OpenClaw对vault目录要有读写权限第二prompt里明确规定笔记的保存路径和格式模板比如“标题带上日期正文分‘要点/链接/待办’三节”。这类任务适合放在凌晨低峰期跑顺手把当天积累的碎片归集好早上起来vault里已经有了整理结果。说实话这是我觉得OpenClaw定时任务里最“值”的玩法之一因为它把AI的产出从“即时消费”变成了“长期资产”。在我实际部署里这个任务不是每天固定时间跑而是每周一、三、五凌晨2点跑一次避免每天跑产生太多无差别笔记。整理频率太高的结果往往是知识库里塞满了同一类内容反而更难检索。6. 最后分享几点我踩出来的经验玩了这段时间OpenClaw定时任务我觉得最值得记住的一件小事是定时任务最先要解决的根本不是cron语法而是“承载它的进程是不是一直活着”。很多人配置检查了半天最后发现只是进程没挂好这个方向别搞反。第二时区一定要显式配置。我一开始也是图省事没写timezone结果Docker部署后所有任务都慢8小时排查了很久才反应过来。每个任务的配置里加上一行timezone顺手的事能省很多无谓的折腾。第三执行型任务的prompt里必须写“遇到异常怎么办”否则它很可能会停下来等你回答。定时任务触发时你可能在睡觉、在开会、在路上它等不到人就会挂起。提前把容错策略写进去任务才算真正闭环。最后分享一个我自己用得很顺的小技巧任何正式任务的prompt我都会先放在普通对话里手动触发一遍。把prompt原样发一次看输出格式、长度、语气是否满意再挂到定时任务上。别小看这一步它能帮你过滤掉大部分“任务写的时候觉得很清楚、跑起来才发现指令有歧义”的情况。等你在日志里看到任务到点执行、消息准时送达的那一刻才会真正觉得OpenClaw不再是个玩具。