第 8 章 定时任务与自动化：让 AI 替你守夜

⏰ 本章特色：在《OpenClaw 实战指南》的系列章节中，本章系统讲解 OpenClaw 内置的 Automations（自动化） 调度系统。从一句自然语言到完整的定时任务，从最简单的 20 分钟提醒到多步骤的自动化流水线，本章带你掌握"让 AI 按时干活"的全部技能。你负责描述需求，调度器负责准时执行。

本章目录：

1. 自动化的本质与场景

1.1 什么是 Automations

在现代智能体系统中，有些工作不需要你每次手动发起。每天早上推送天气预报、每小时检查服务器状态、每周五生成周报，这些周期性或事件驱动的任务需要一个"无声管家"来默默执行。OpenClaw 内置了一套完整的调度系统，叫做 Automations（自动化）。

简单来说，Automations 是 OpenClaw Gateway 内置的任务调度器。它能够持久化保存任务定义，在指定时间唤醒 AI 执行任务，并将结果发送到你的聊天渠道、Webhook 端点，或者静默完成。整个过程不需要你保持在线，Gateway 进程本身就是调度引擎。

你可以把它理解为 AI 世界的"闹钟 + 执行器"。普通闹钟只能在规定时间响铃提醒你，而 Automations 不仅能按时"响铃"，还能自动完成你交代的任务，把结果直接送到你面前。当你早上打开手机，看到一条"今天有霾，记得戴口罩"的消息，背后就是 Automations 在默默运行。

1.2 Automations 与 Heartbeat 的区别

OpenClaw 有两种周期性执行机制，初学者容易混淆。理解它们的区别，有助于你选择正确的工具。

Heartbeat（心跳） 是一种轻量级的主会话轮询机制。Gateway 定期（通常每 30 分钟）向主会话发送心跳消息，AI 在心跳轮次中可以执行一些简单的检查任务，比如查看未读邮件、检查日历等。心跳的特点是共享主会话上下文、执行时间短、适合批量检查。

Automations 则是独立的调度系统，功能远比心跳丰富。每个 Automation 任务有自己的调度规则、执行环境和交付方式，可以精确定时、独立运行、发送结果到任意渠道。

Automations在内部被称为Cron

简单来说： 如果任务只是"每隔一段时间检查一下有没有新邮件"这类简单周期检查，Heartbeat 就够了。如果需要"每天早上 8 点准时推送天气预报到微信"这种精确定时、独立执行、定向交付的任务，就必须用 Automations。

1.3 典型应用场景

Automations 的应用场景远比想象中丰富。以下是几类最常见的使用场景，帮助你建立对自动化能力的直觉认知。

晨间信息推送。 每天早上自动查询天气、日历、新闻摘要，汇总成一条消息发送到你的聊天渠道。这是最经典也最实用的场景，很多人正是为了这个功能开始使用 OpenClaw。

定时提醒。 "提醒我下午 3 点开会""每周五下午 4 点提醒我提交周报"。一次性提醒和周期性提醒都可以通过 Automations 实现。

后台数据同步。 每隔几小时自动同步数据库、清理缓存、备份文件。这类任务不需要向用户发送结果，属于静默执行的后台任务。

监控告警。 定期检查服务器状态、API 可用性、磁盘空间，发现异常时立即发送告警通知。配合条件触发器（Condition Watcher），可以实现"只在状态变化时告警"的智能监控。

内容生成流水线。 每天自动生成数据报告、社交媒体内容草稿、项目进度总结。AI 在隔离会话中完成内容生成，然后将结果投递到指定渠道。

┌─────────────────────────────────────────────────┐
│            Automations 的典型执行流程              │
│                                                   │
│  Gateway 调度器                                    │
│     │                                             │
│     ├── 检查：当前时间是否匹配调度规则？            │
│     │                                             │
│     ▼                                             │
│  创建会话（isolated/main/current）                 │
│     │                                             │
│     ▼                                             │
│  执行载荷（agentTurn/command/script）              │
│     │                                             │
│     ▼                                             │
│  交付结果（announce/webhook/none）                 │
│     │                                             │
│     ├──→ 聊天渠道（微信、Telegram、Discord）        │
│     ├──→ Webhook 端点                              │
│     └──→ 静默完成                                  │
└─────────────────────────────────────────────────┘

理解了自动化的本质和适用场景后，接下来进入实际操作环节。在创建任何定时任务之前，首先要确保自动化功能已经开启。

2. 开启自动化功能

2.1 启用 Automations

Automations 功能默认处于关闭状态，使用前需要先启用。OpenClaw 使用配置键 cron.enabled 来控制调度器的开关。

通过 CLI 命令启用：

openclaw config set cron.enabled true

或者直接编辑配置文件 openclaw.json，在其中添加：

{
  "cron": {
    "enabled": true
  }
}

这里的 cron 是 OpenClaw 内部对调度系统的统称（沿用了 Unix 系统的传统命名），它涵盖了所有五种调度类型，不仅仅是 cron 表达式。enabled 是布尔值开关，设为 true 即启用整个调度引擎。

2.2 验证调度器状态

启用后，用以下命令确认调度器已经正常运行：

openclaw automations status

或以下命令：

openclaw cron status

正常情况下，你会看到类似这样的输出：

{
  "enabled": true,
  "triggersEnabled": true,
  "storage": "sqlite",
  "sqlitePath": "C:\\Users\\zhang\\.openclaw\\state\\openclaw.sqlite",
  "jobs": 8,
  "nextWakeAtMs": 1791547668264
}

确认状态为 enabled 后，就可以开始创建定时任务了。接下来我们用五个由浅入深的实际案例，逐步掌握五种调度类型。

• 注：cron 和 automations 是等价的，本文统一使用 automations 以保持阅读连贯。

3. 从案例学调度：由浅入深

本节通过五个递进的实战案例，带你掌握 OpenClaw 的五种调度类型。每个案例都比上一个更复杂，但都从实际需求出发。建议你跟着动手操作，看到真实结果后再进入下一个。

3.1 案例一：20 分钟后提醒我喝水（at 一次性提醒）

这是最简单的自动化场景。你正在忙碌，想让自己 20 分钟后休息一下喝杯水。不需要写 cron 表达式，也不需要指定复杂的参数，只要一条命令：

openclaw automations add \
  --name "喝水提醒" \
  --at "20m" \
  --session main \
  --system-event "提醒：该喝水了！站起来活动一下。" \
  --wake now 

逐个参数讲解：

--at 支持的相对时间格式非常直观：

执行后，用 openclaw automations list 可以看到这个任务已经被创建，20 分钟后它会准时触发。执行成功后任务自动删除，不会留下任何残余。

• 注：create 和 add 是等价的，本文统一使用 add 以保持阅读连贯。

指定绝对时间的一次性提醒

如果你想指定一个精确的时间点，比如今天下午 1 点提醒健身：

openclaw automations add \
  --name "健身提醒" \
  --at "2026-10-09T13:00:00" \
  --tz "Asia/Shanghai" \
  --session main \
  --system-event "提醒：健身时间到了，请先热身。" \
  --wake now

这里新增了一个关键参数：

时区陷阱提醒： 这是一个初学者最容易踩的坑。--at "2026-10-09T13:00:00" 不指定时区时，系统会按 UTC 13:00 处理，即北京时间晚上 9 点，而不是下午 1 点。一定要加上 --tz "Asia/Shanghai" 来明确时区。

一次性任务的生命周期

at 类型的任务在执行成功且交付确认后会自动删除。如果执行失败或交付未完成，任务会被保留但标记为禁用状态，等待你检查后手动处理。--delete-after-run 明确要求执行后删除，--keep-after-run 则保留任务以便复查。

3.2 案例二：每天早上 8 点推送天气预报（cron 精确调度）

一次性提醒学会了，接下来是日常最实用的场景：每天早上 8 点自动查询天气并推送给你。

openclaw automations add "0 8 * * *" \
  --name "天气提醒" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "查询北京今天的天气并提供穿衣建议。用中文回复。" \
  --announce \
  --channel telegram \
  --to "-1001234567890"

这条命令引入了几个新概念，逐一讲解：

cron 表达式速查

cron 表达式由 5 个字段组成，分别是分钟、小时、日期、月份、星期：

┌───────────── 分钟 (0-59)
│ ┌───────────── 小时 (0-23)
│ │ ┌───────────── 日期 (1-31)
│ │ │ ┌───────────── 月份 (1-12)
│ │ │ │ ┌───────────── 星期 (0-6, 0=周日)
│ │ │ │ │
* * * * *

常用的 cron 表达式示例：

时区处理规则

cron 表达式的时区处理规则很清晰：

不指定 --tz 时： cron 表达式使用 Gateway 所在主机的本地时区。你写的 0 8 * * * 就是本地时间的早上 8 点，不需要自己换算成 UTC。

指定 --tz 时： cron 表达式按照指定时区的表达式时间计算。例如 --tz "Asia/Shanghai" 确保按北京时间触发。

整点错峰机制

一个有趣的设计细节：当 cron 表达式的分钟为 0 且小时为通配符（如 0 * * * *，即每小时整点执行）时，OpenClaw 会自动加入最多 5 分钟的随机延迟。这样做是为了避免大量任务在同一秒同时触发，造成系统负载尖峰。

如果你需要精确的整点执行（不允许延迟），可以使用 --exact 参数。如果需要自定义延迟窗口，可以使用 --stagger 30s。

3.3 案例三：每隔 4 小时同步数据（every 固定间隔）

有些任务不需要精确到某个时刻，只要保持固定间隔运行即可。比如每隔 4 小时执行一次数据同步：

openclaw automations add \
  --name "数据同步" \
  --every "4h" \
  --session isolated \
  --message "执行数据同步和缓存清理，完成后简要报告结果。" \
  --no-deliver

新增参数说明：

every 与 cron 的关键区别在于计时方式。every 从任务创建时刻开始计时，每次执行后重新计时。而 cron 对齐到指定的时区，在表达式确定的每一个具体时刻触发，与你何时创建任务无关。

举个例子：你在 10:17 创建了一个 --every 1h 的任务，它会在 11:17、12:17、13:17 执行。而 --cron "0 * * * *" 的任务总是在每小时的整点（11:00、12:00、13:00）执行。

选择建议： 需要"每 N 小时/分钟运行一次"且不在乎精确时刻，用 every。需要"每天几点""每周一几点"这种对齐到精确时间的，用 cron。

3.4 案例四：构建完成后通知结果（on-exit 命令退出触发）

on-exit 是一种事件驱动的调度类型，它不基于时间，而是监听一个命令的执行结果。当指定的命令退出时，任务自动触发。非常适合"构建完成后通知结果""测试跑完后生成报告"等场景。

openclaw automations add \
  --name "构建通知" \
  --on-exit "./build.sh" \
  --on-exit-cwd /home/user/project \
  --session isolated \
  --message "构建已完成，请检查构建结果并总结关键信息。" \
  --announce

新增参数说明：

on-exit 任务有一个特殊的生命周期：当命令退出并触发载荷执行后，任务会自动禁用。需要再次监听时，手动重新启用即可。如果新命令在前一次载荷还没执行完时就退出了，新的退出会等待前一次完成后再触发。

3.5 案例五：实时监控日志中的错误（stream 事件流）

stream 是最强大的调度类型，它保持一个长时间运行的命令持续执行，并从该命令的标准输出中实时捕获事件。每当命令输出一行新的文本，调度器就会根据配置决定是否触发任务。

openclaw automations add \
  --name "构建事件监控" \
  --stream-command '["node","scripts/build-events.mjs"]' \
  --stream-mode match \
  --stream-match '^(failed|recovered):' \
  --stream-batch-ms 250 \
  --session isolated \
  --message "分析这些构建事件并采取适当行动。"

新增参数说明：

stream 有两种模式：

line 模式（默认）： 命令输出的每一行都会触发任务。适合输出本身就是事件的场景。

match 模式： 只有匹配正则表达式的行才会触发任务。适合从大量输出中过滤特定事件的场景，例如只关注包含 failed 或 recovered 关键字的行。

批量处理机制： stream 不会为每一行都立即触发任务，而是在 --stream-batch-ms（默认 250ms）的静默期内积累输出，然后一次性触发。这避免了高频输出时的性能问题。

快速失败保护： 如果命令在 60 秒内退出，连续 5 次快速失败后，任务会进入错误状态并停止重启，需要手动重新启用。

3.6 五种调度类型速查表

掌握了五个案例后，用这张表快速回顾：

掌握了"什么时候执行"之后，下一步了解任务"做什么"和"怎么做"。不同的载荷类型决定了任务的执行方式和能力范围，这是自动化系统中最灵活的部分。

4. 任务载荷：四种执行方式

调度规则解决了"什么时候做"，载荷（Payload）则决定了"做什么"和"怎么做"。OpenClaw 提供了四种载荷类型，从简单的系统事件到完整的 AI 对话，从 Shell 命令到无头脚本，覆盖了几乎所有自动化需求。

4.1 载荷类型全景对比

4.2 systemEvent：轻量级系统事件

systemEvent 是最轻量的载荷类型。它不启动 AI 对话，只是将一段文本注入到主会话的事件队列中，等待下一次心跳或用户消息时处理。

openclaw automations add \
  --name "喝水提醒" \
  --every "2h" \
  --session main \
  --system-event "提醒：该喝水了，站起来活动一下。" \
  --wake now

适用场景： 简单的文本提醒、后台状态同步、缓存清理指令。这些任务不需要 AI 理解和推理，只需要在特定时间注入一条消息。

限制： systemEvent 只能在 main 会话中运行，不能在 isolated 会话中使用。它的交付方式也受限于主会话的投递上下文，不能直接发送到其他渠道。

4.3 agentTurn：完整的 AI 对话轮次

agentTurn 是最常用的载荷类型，它模拟用户发送一条消息，触发完整的 AI 对话流程。AI 会像收到用户消息一样，理解意图、调用工具、生成回复，最后将结果交付到指定渠道。

前面案例二"天气提醒"就是一个典型的 agentTurn 任务。再看一个使用高级选项的例子：

openclaw automations add \
  --name "周报" \
  --cron "0 18 * * 5" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "生成本周工作周报，分析项目进展和下周计划。" \
  --model "opus" \
  --thinking high \
  --announce

新增的高级参数：

模型选择的实用建议： 为任务选择合适的模型，而不是默认使用最贵的。日常的天气查询、新闻摘要用轻量模型就够了，又快又便宜。只有深度分析、复杂推理的任务才需要使用高端模型。

4.4 command：直接执行 Shell 命令

command 载荷在 Gateway 主机上直接执行 Shell 命令，不启动 AI 对话。适合执行确定性的脚本、状态探针、数据采集等不需要 AI 推理的任务。

openclaw automations add "*/15 * * * *" \
  --name "队列深度探针" \
  --command "scripts/check-queue.sh" \
  --command-cwd "/srv/app" \
  --announce \
  --channel telegram \
  --to "-1001234567890"

新增参数说明：

command 有两种调用方式：

Shell 模式： --command "your-shell-command" 将命令包装为 sh -lc "your-shell-command" 执行。适合简单的单行命令。

精确 argv 模式： --command-argv '["node","scripts/report.mjs"]' 直接执行指定的程序和参数，不经过 Shell 解析。适合需要精确控制参数的场景。

输出与状态码处理： 命令的 stdout 和 stderr 会被捕获。非空 stdout 优先作为交付内容；如果 stdout 为空而 stderr 非空，则交付 stderr。退出码 0 记录为成功（ok），非零退出码记录为错误（error）。命令输出 NO_REPLY 时会静默完成，不发送任何消息。

# 精确 argv 模式示例
openclaw automations add "0 * * * *" \
  --name "小时报告" \
  --command-argv '["node","scripts/hourly-report.mjs"]' \
  --command-env "NODE_ENV=production" \
  --timeout-seconds 120 \
  --announce

这里 --timeout-seconds 设置任务的超时时间（秒），超时后任务会被强制终止。对于 agent 和 command 载荷都适用。

4.5 script：无头代码模式

script 载荷运行一个 JavaScript 脚本文件，脚本可以使用 OpenClaw 的工具（如 exec、read、web_fetch 等），但不启动对话式 AI 轮次。它介于 command（纯 Shell）和 agentTurn（完整 AI 对话）之间，适合需要调用 OpenClaw 工具但又不需要 AI 推理的复杂自动化。

openclaw automations add "0 * * * *" \
  --name "小时队列检查" \
  --script ./automation/check-queue.js \
  --script-timeout-seconds 300 \
  --script-tool-budget 50 \
  --session isolated \
  --announce

新增参数说明：

脚本可以返回一个对象，包含以下字段：

• notify：交付的文本内容，通过 announce、webhook 或 none 模式投递
• wake："now" 请求立即心跳，"next-heartbeat" 等待下一次心跳
• state：JSON 状态数据（最大 16KB），持久化后传递给下一次运行
• nextCheck：下次检查的间隔（如 "15m"），仅对有 pacing 的任务有效

4.6 运行环境：四种会话执行模式

载荷类型决定了"做什么"，运行环境（sessionTarget）则决定了"在哪里做"。OpenClaw 提供了四种执行模式，每种模式有不同的上下文隔离级别和适用场景。

isolated（隔离会话）： 每次执行创建一个全新的会话，不继承任何历史对话上下文。这是大多数面向用户的自动化任务的推荐模式，因为隔离性最好，不会污染主会话历史。每次运行都是"白纸一张"，AI 只根据载荷中的 message 来执行任务。

main（主会话）： 在主会话中注入事件，可以利用主会话的完整上下文和记忆。但 main 会话只能搭配 systemEvent 载荷，不能搭配 agentTurn。这意味着主会话中的自动化不会触发完整的 AI 对话轮次，只是静默注入一条事件。

current（当前会话）： 任务在独立会话中执行，但会读取创建任务时所在对话的有限历史上下文，执行结果提交回同一个对话。适合需要"记住之前聊了什么"的周期性任务。agentTurn 载荷默认使用 current 模式。

自定义会话（session:xxx）： 使用持久化的命名会话，上下文在多次运行之间积累。适合每日站会摘要、项目进度追踪等需要"记住之前结果"的工作流。

┌─────────────────────────────────────────────────┐
│            四种会话执行模式对比                     │
│                                                   │
│  main（主会话）                                    │
│  ┌──────────────────────────────────────┐         │
│  │  共享上下文 + 记忆                     │         │
│  │  仅支持 systemEvent                   │         │
│  └──────────────────────────────────────┘         │
│                                                   │
│  isolated（隔离会话）                              │
│  ┌──────────────────────────────────────┐         │
│  │  每次全新上下文，互不干扰              │         │
│  │  支持所有载荷类型                      │         │
│  └──────────────────────────────────────┘         │
│                                                   │
│  current（当前会话）                               │
│  ┌──────────────────────────────────────┐         │
│  │  读取创建时对话上下文                  │         │
│  │  结果提交回同一对话                    │         │
│  └──────────────────────────────────────┘         │
│                                                   │
│  session:<id>（自定义会话）                        │
│  ┌──────────────────────────────────────┐         │
│  │  跨次运行积累上下文                    │         │
│  │  适合渐进式工作流                      │         │
│  └──────────────────────────────────────┘         │
└─────────────────────────────────────────────────┘

选择建议： 如果你不确定该选哪种模式，选 isolated 准没错。它是推荐选项，隔离性最好，几乎不会出问题。只有当你确实需要主会话上下文或跨次运行记忆时，才考虑其他模式。

掌握了载荷类型和运行环境后，下一个关键问题是：任务执行完成后，结果如何送到你手中？

5. 交付与通知：结果如何送达

任务执行完成后，结果需要送到正确的地方。针对main会话，已经明确了具体结果位置，就是在main会话中送达。

针对 isolated（隔离）会话，OpenClaw 提供了三种交付模式，以及完善的失败告警机制，确保你不会错过任何重要信息。

不同的会话类型（main vs isolated）拥有完全不同的交付逻辑。

main (主会话) 继承自聊天上下文。任务在哪个聊天窗口创建，结果就自然回复到哪个窗口。
系统自动处理消息发送，显式添加 --announce 反而会导致消息重复发送。

isolated (隔离会话) 无状态、无绑定。每次执行都是全新的上下文，没有默认的“聊天窗口”可以接收结果。
因此必须显式配置。如果不配置交付机制，任务结果将仅保留在系统历史记录中，用户无法收到通知。

总结一下，main 会话的交付是“自动继承”的，而 isolated 会话的交付是“必须指定”的。
本节后续的交付参数配置，均默认以 isolated 会话为应用场景。

5.1 三种交付模式

对于 isolated 会话，任务结果的送达有以下三种路径：

--announce 是隔离会话（isolated） 的兜底投递机制，因为隔离会话没有绑定的聊天目标，必须显式告诉系统“结果往哪发”。

main 会话本身就有明确的聊天绑定关系，系统事件注入后，AI 在该会话内生成的回复会自然流入该会话的输出通道，无需额外的 announce 回退机制。

announce：聊天渠道投递

announce 是最常用的交付模式，是将任务结果会自动发送到指定的聊天渠道。对于 isolated 会话中的 agentTurn 任务，announce 是默认模式。

--announce 是隔离会话（isolated） 的兜底投递机制，当智能体未通过 message 工具主动发送消息时，系统将最终回复推送到 --channel + --to 指定的目标

openclaw automations add "0 8 * * *" \
  --name "天气提醒" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "查询北京今天的天气并提供穿衣建议。用中文回复。" \
  --announce \
  --channel telegram \
  --to "-1001234567890"

渠道与目标参数：

Telegram 论坛话题投递： 如果你的 Telegram 群组开启了论坛模式（Topics），可以使用 --thread-id 投递到特定话题。

Discord/Slack 目标格式： 使用显式前缀指定目标类型，如 channel:C1234567890（频道）或 user:U1234567890（用户私信）。

多渠道环境下的注意事项： 当 Gateway 配置了多个渠道时，isolated 任务必须显式指定 --channel，否则系统不知道该往哪个渠道投递。

webhook：HTTP 端点投递

webhook 模式将任务执行结果以 HTTP POST 请求的形式发送到指定 URL。适合与外部系统集成、触发后续自动化流水线。

openclaw automations add "0 18 * * 1-5" \
  --name "部署摘要" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "将今天的部署情况整理为 JSON 格式。" \
  --webhook "https://bjbook.net/openclaw/cron"

安全提醒： 所有出站 Webhook 都受严格的 SSRF（Server-Side Request Forgery）防护。默认情况下，不允许访问本地回环地址、内网地址和链路本地地址。如果确实需要向本地服务发送 Webhook，需要在配置中显式允许：

{
  "cron": {
    "webhookSsrfPolicy": {
      "allowedHostnames": ["127.0.0.1"]
    }
  }
}

Webhook 认证： 通过 cron.webhookToken 配置令牌，OpenClaw 会在 POST 请求的 Authorization 头中携带 Bearer <token>，接收方可以验证请求来源。

none：静默完成

none 模式不发送任何结果，任务静默完成。适合后台数据同步、缓存清理等不需要用户知道的任务。

openclaw automations add "0 */4 * * *" \
  --name "数据同步" \
  --session isolated \
  --message "执行数据同步和缓存清理。" \
  --no-deliver

5.2 失败告警机制

自动化任务不可能永远顺利运行。网络超时、API 限流、模型故障，各种问题都可能导致任务失败。OpenClaw 提供了完善的失败告警机制，确保你能及时发现问题。

默认告警行为

当一个任务连续 2 次 执行失败，且距离上次告警已超过 1 小时 冷却期时，系统会自动发送失败告警通知。告警内容包括失败原因、运行时间和检查链接。

连续失败且原因相同的多次执行只会形成一次"事件"，不会重复告警。当任务恢复成功后，系统会发送一条恢复通知，并清除事件记录。

┌─────────────────────────────────────────────────┐
│            失败告警生命周期                        │
│                                                   │
│  第 1 次失败 → 记录，不告警                        │
│     │                                             │
│     ▼                                             │
│  第 2 次失败 → 触发告警通知                        │
│     │                                             │
│     ▼                                             │
│  第 3-9 次失败 → 同一事件，不重复告警              │
│     │                                             │
│     ▼                                             │
│  第 10 次连续失败 → 自动禁用任务 + 安全通知        │
│     │                                             │
│     ▼                                             │
│  修复后手动启用 → openclaw automations enable <id> │
└─────────────────────────────────────────────────┘

自动禁用安全网

调度器提供了一个无条件安全兜底：基于时间的周期任务在连续 10 次 执行失败后会被自动禁用。一次成功执行即可重置失败计数。被自动禁用的任务会记录原因（consecutive-failures 或 schedule-errors），并向代理发送包含恢复命令的通知。

被自动禁用的任务不会出现在默认的 openclaw automations list 中（因为默认只显示启用的任务）。使用 --all 参数可以查看所有任务，包括被禁用的：

openclaw automations list --all

恢复被禁用的任务：

openclaw automations enable <jobId>

启用命令会清除记录的失败原因和失败计数，让任务重新开始。

自定义告警配置

你可以通过 failureAlert 相关参数自定义告警行为：

5.3 输出语言控制

自动化任务不会根据渠道、地区或历史消息自动推断回复语言。你需要在任务消息中明确指定语言要求：

openclaw automations edit <jobId> \
  --message "总结今日更新。用中文回复；保持 URL、代码和产品名称不变。"

如果使用模板文件，确保语言指令在渲染后的提示词中，并且占位符（如 {{language}}）在任务运行前被正确填充。如果输出混合了语言，请明确规则，例如："叙述文字用中文，技术术语保持英文。"

了解了交付和告警机制后，接下来进入实战环节：如何创建、管理和监控自动化任务。OpenClaw 提供了对话式管理和 CLI 管理两种方式，满足不同场景的需求。

6. 对话式管理：用自然语言操控任务

对大多数用户来说，最简单的管理方式就是直接在聊天中告诉 OpenClaw。OpenClaw 会自动理解你的意图，调用 automations 工具创建、修改、删除或查看任务。整个过程无需记忆任何命令或参数。

6.1 创建任务

你不需要了解 cron 表达式怎么写，也不需要知道任务的内部结构。只需用自然语言描述你想要的效果：

用户输入：

每天早上 8 点帮我查北京的天气，发给我。

AI 会自动识别出触发时间（每天 8 点）、任务内容（查询天气）、交付方式（发送到当前渠道），然后创建对应的定时任务。

6.2 修改任务

用户输入：

把天气提醒改成每天早上 9 点。

OpenClaw回复：

已改好 ✅

每日天气播报时间已更新为 **每天早上 9:00**（北京时间），明早 9 点微信见 ☀️

AI 会找到对应的任务并修改调度规则。

6.3 暂停与恢复

用户输入：

暂停天气提醒。

用户输入：

恢复天气提醒。

6.4 立即测试

用户输入：

帮我立即执行一下天气提醒，看看效果。

AI 会自动触发一次任务运行，你可以立即看到结果，不需要等到下一个调度时间。

6.5 查看任务列表

用户输入：

帮我看看有哪些定时任务。

输输出内容，当前共有 6 个定时任务：

顺便说一下，刚才手动触发的天气播报已经成功发送到你的微信了 ☀️ 效果没问题！

6.6 查看执行历史

用户输入：

看看天气提醒最近执行得怎么样。

6.7 删除任务

用户输入：

删掉天气提醒任务。

6.8 任务提升（Promotion）机制

OpenClaw 有一个很聪明的设计：当你多次让 AI 做同一件事时，AI 会主动建议把它变成一个定时任务。

例如，你连续三天都让 AI "帮我查一下天气"，第四天 AI 可能会说：

"我注意到你每天都在让我查天气。要不要我帮你设一个每天早上 8 点的自动天气提醒？这样你就不用每天手动问了。"

这个过程叫做"任务提升"（Promoting a repeated job into an automation）。它的价值在于：你已经在之前的对话中看到了任务的实际输出，确认结果符合预期，再把它变成定时任务就更有信心。

AI 在提出建议时，会用自然语言描述任务内容和调度规则，例如："每个工作日上午 7 点（Asia/Shanghai 时区），我总结昨晚的更新并发布到这里。"你需要确认的是这句话，而不是一段 cron 表达式。

确认后，AI 会执行三步操作：

1. 创建任务： 默认投递到你请求的渠道和线程
2. 立即测试运行： 以 force 模式运行一次，你能立即看到真实的输出效果
3. 测试失败则回滚： 如果测试运行失败，AI 会删除任务并告诉你原因

创建后的任务默认是 启用 状态，而不是"等待确认"的禁用状态。这是一个深思熟虑的设计选择：调度器会监督启用的任务，失败时会发出告警并自动处理。而一个被禁用等待确认的任务，对所有的保护机制都是不可见的，它会安静地躺在那里，永远不会执行，也不会解释自己为什么没执行。这种"静默失败"比"运行并报错"更糟糕。

对话式管理的优势： 所有变更实时生效，不需要重启服务。AI 会帮你处理所有细节，你只需要关注"想要什么结果"。当你需要更精细的控制时，下一节的 CLI 命令提供了完整的参数覆盖。

7. CLI 管理：精细化操控

当你需要更精细的控制时，CLI 命令提供了完整的参数覆盖。以下是常用命令的完整参考。

7.1 查看任务

# 列出所有启用的任务
openclaw automations list

# 包含禁用的任务
openclaw automations list --all

# 按 agent 过滤
openclaw automations list --agent ops

# 查看单个任务的完整定义（JSON 格式）
openclaw automations get <jobId>

# 查看单个任务的详细信息（含交付路由解析）
openclaw automations show <jobId>

--json 参数可以获取机器可读的 JSON 输出，适合脚本集成：

openclaw automations list --json
openclaw automations get <jobId> --json

7.2 创建任务

openclaw automations create 和 openclaw automations add 是等价的别名：

# 使用位置参数（先调度表达式，后任务消息）
openclaw automations create "0 7 * * *" \
  "总结昨晚的更新。" \
  --name "晨报" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --announce \
  --channel telegram \
  --to "-1001234567890"

7.3 编辑任务

# 修改任务消息和模型
openclaw automations edit <jobId> \
  --message "更新后的提示内容" \
  --model "opus"

# 清除模型覆盖（恢复默认模型）
openclaw automations edit <jobId> --clear-model

# 清除思维级别覆盖
openclaw automations edit <jobId> --clear-thinking

# 修改调度规则
openclaw automations edit <jobId> --cron "0 9 * * *"

# 修改交付渠道
openclaw automations edit <jobId> \
  --channel telegram \
  --to "-1001234567890"

清除类参数说明：

7.4 启用与禁用

# 禁用任务（保留定义，停止执行）
openclaw automations disable <jobId>

# 启用任务（恢复执行）
openclaw automations enable <jobId>

7.5 手动运行

# 立即执行一次（异步，不等待结果）
openclaw automations run <jobId>

# 立即执行并等待结果（同步模式）
openclaw automations run <jobId> --wait --wait-timeout 10m --poll-interval 2s

# 仅在任务到期时运行
openclaw automations run <jobId> --due

--wait 模式特别适合脚本集成：它会轮询任务运行状态，直到任务完成或超时，只在 completionStatus: "succeeded" 时返回退出码 0。

7.6 查看执行历史

# 查看最近 50 条执行记录
openclaw automations runs <jobId> --limit 50

# 查看某次具体执行的详情
openclaw automations runs <jobId> --run-id <runId>

# 按状态过滤（ok、error、skipped）
openclaw automations runs <jobId> --status error

# 按交付状态过滤
openclaw automations runs <jobId> --delivery-status not-delivered

# 搜索执行摘要和错误信息
openclaw automations runs <jobId> --query "timeout"

执行历史包含丰富的信息：运行 ID、时间戳、执行状态（ok/error/skipped）、完成状态（succeeded/failed/unknown）、耗时、交付结果等。

7.7 删除任务

openclaw automations remove <jobId>

示例：

openclaw automations remove dfe5c959-247d-447a-a337-2c0673031034

jobId通过openclaw automations list --all来查询所有任务，第一列为其jobId

7.8 任务的存储与持久化

所有自动化任务的定义、运行状态和执行历史都持久化存储在 OpenClaw 的共享 SQLite 状态数据库中。这意味着即使 Gateway 重启，任务调度也不会丢失。

任务定义： 每个任务的完整配置（调度规则、载荷、交付方式等）保存在数据库中，修改后即时生效。

运行状态： 下次执行时间、上次执行状态、失败计数等运行时信息也被持久化。Gateway 重启后，调度器会根据保存的状态恢复调度。

执行历史： 每次任务执行的详细日志保留 7 天，每个任务最多保留 2000 条记录。执行历史用于排查问题、分析任务表现和审计。

Gateway 重启时的行为： 重启后，过期的隔离 agentTurn 任务会被重新调度而不是立即回放，避免在渠道连接的窗口期内产生大量模型调用。一次性（at）任务如果在离线期间错过，会在启动时补执行。如果你不希望错过的周期任务被补执行，可以配置 cron.skipMissedJobs: true。

掌握了管理命令后，最后一个关键问题是：如何在实际项目中选择合适的配置组合？下一节将总结最佳实践，帮助你避免常见的坑。

8. 最佳实践与安全防线

自动化任务一旦设置好，就会在后台持续运行。这意味着任何配置错误都可能被反复执行，造成不必要的影响。本节总结了经过实践验证的最佳实践和安全准则。

8.1 会话选型决策树

面对四种运行环境，如何选择最合适的？以下是一个简化的决策思路：

┌─────────────────────────────────────────────┐
│  你的任务需要 AI 对话推理吗？                  │
├──────────────┬──────────────────────────────┤
│  是          │  否                           │
│              │                              │
│  任务需要访问 │  使用 systemEvent              │
│  主会话记忆？ │  + main 会话                  │
├──────┬───────┤                              │
│  是  │  否   │                              │
│      │       │                              │
│ main │isolated│                              │
│(仅   │(推荐) │                              │
│sys   │       │                              │
│Event)│       │                              │
└──────┴───────┴──────────────────────────────┘

简单来说： 大多数情况下选 isolated。需要主会话上下文时用 main（但只能搭配 systemEvent）。需要跨次运行积累上下文时用自定义会话。

8.2 各类场景的推荐配置

面向用户的提醒

这是最常见的场景。推荐使用 isolated 会话 + agentTurn 载荷 + announce 交付的组合：

openclaw automations add "0 8 * * *" \
  --name "天气提醒" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "查询北京今天的天气并提供穿衣建议。用中文回复。" \
  --announce \
  --channel telegram \
  --to "-1001234567890"

为什么用 isolated： 避免任务执行产生的对话混入主会话历史，保持主会话干净。每次运行都是全新上下文，不会受到之前对话的影响。

后台数据同步

不需要向用户发送结果的后台任务，使用 isolated + agentTurn + none 的组合：

openclaw automations add "0 */4 * * *" \
  --name "数据同步" \
  --session isolated \
  --message "执行数据同步和缓存清理，简要报告结果。" \
  --no-deliver

高频监控任务

执行频率较高（如每 5 分钟一次）的任务，务必使用 isolated 模式。如果用 main 会话，高频执行会产生大量会话历史，拖慢系统性能。

对于高频任务，还建议使用轻量模型和 --light-context 参数来降低成本和延迟：

openclaw automations add \
  --name "API 健康检查" \
  --every "5m" \
  --session isolated \
  --message "检查 API 服务是否正常响应。用中文简要报告。" \
  --light-context \
  --no-deliver

需要长期记忆的任务

生成周报、月度总结等需要参考历史数据的任务，使用自定义会话模式：

openclaw automations add "0 18 * * 5" \
  --name "周报生成" \
  --tz "Asia/Shanghai" \
  --session "session:weekly-report" \
  --message "根据本周的工作内容生成周报。用中文回复。" \
  --model "opus" \
  --thinking high \
  --announce

每次执行时，会话会保留之前运行的上下文，AI 可以看到前几周的报告内容，生成更有连续性的总结。

8.3 实用配置建议

先测试再启用

创建任务后，先手动运行一次确认效果，再让它按调度自动运行：

# 创建任务
openclaw automations add "0 8 * * *" ...

# 手动运行测试
openclaw automations run <jobId>

# 检查执行结果
openclaw automations runs <jobId>

如果测试运行结果不理想，可以调整 --message 内容后再次测试，直到满意为止。

定期检查执行历史

养成定期查看执行历史的习惯，确保任务正常执行，及时发现问题：

openclaw automations list
openclaw automations runs <jobId> --limit 10

重点关注：是否有连续失败的记录、执行时间是否异常偏长、交付是否成功。你也可以在 Control UI 的 Automations 页面直观地查看所有任务的健康度。

定期清理无用任务

不再需要的任务及时删除或禁用，保持任务列表整洁：

# 查看所有任务（包括禁用的）
openclaw automations list --all

# 删除不需要的任务
openclaw automations remove <jobId>

# 或者只是暂时禁用
openclaw automations disable <jobId>

模型选择策略

为任务选择合适的模型，而不是一律使用默认模型：

成本会在日积月累中显现。一个每小时执行的任务，即使每次只多花 0.01 元，一个月（30 天）下来就是 0.01 × 24 × 30 = 7.2 元。选择合适的模型，长期来看能节省不少开支。

8.4 安全准则

自动化任务本质上是 AI 在无人监督的情况下执行操作。这种"无人值守"的特性意味着安全防线比交互式对话更为重要。

不要在任务消息中硬编码敏感信息

任务消息会被持久化存储，可能被多个用户查看。不要在消息中包含 API 密钥、密码或其他敏感数据：

# 错误做法
--message "使用 API Key sk-xxx 查询数据"

# 正确做法
# 在 openclaw.json 的 skills.entries 中配置 API Key，
# 任务中只描述任务内容
--message "查询数据库中的最新数据"

限制可用工具

对于不需要完整工具访问权限的任务，使用 --tools 参数限制可用工具集：

# 只允许读取和执行特定脚本
openclaw automations add \
  --tools "exec,read" \
  --message "运行 {baseDir}/scripts/report.sh 并报告结果" \
  ...

这可以防止 AI 在自动化执行中意外调用不相关的工具（如发送消息、修改文件等）。

高风险操作需要充分测试

涉及文件删除、系统修改、数据库写入等高风险操作的任务，务必在正式启用前充分测试：

1. 先用 --no-deliver 创建任务，只观察执行结果不投递
2. 手动运行多次，确认各种情况下的行为都符合预期
3. 确认无误后再启用交付

定期检查运行中的任务

定期审计所有正在运行的自动化任务，确保没有过期或不再需要的任务在后台默默执行：

openclaw automations list --all

特别注意那些被自动禁用的任务，它们可能暗示着某个依赖出了问题。

条件触发器的安全注意事项

条件触发器（Event Triggers）和脚本载荷（Script Payloads）默认以代理的完整工具策略运行，包括 exec 权限。这意味着它们可以在无人值守的情况下执行 Shell 命令。

如果你不需要这些高级功能，可以在配置中全局禁用：

{
  "cron": {
    "triggers": {
      "enabled": false
    }
  }
}

8.5 本章核心知识回顾

8.6 课后练习

1. 基础：用自然语言在聊天中创建一个定时任务，让它每天早上 8 点给你发送天气预报。创建后立即手动运行一次，确认结果。
2. 进阶：使用 CLI 创建一个 --every 1h 的任务，让它每小时检查一次某个网站是否可访问，失败时发送告警。配置 --failure-alert-after 3 让告警在连续 3 次失败后才触发。
3. 高级：创建一个 stream 类型的任务，监控一个日志文件的输出，当出现包含 ERROR 的行时自动触发 AI 分析错误原因并发送报告。
4. 挑战：设计一个完整的自动化工作流，包含三个任务：一个每天早上 7 点收集数据的任务、一个每小时检查数据质量的任务、一个每周五下午 5 点生成周报的任务。三个任务使用不同的模型和运行环境，并通过 --tools 参数限制各自的工具权限。

本章完
本文为《OpenClaw 实战指南》系列第 8 篇。