本页内容
本页内容
自动化
自动化如何工作
网关调度程序如何运行作业、在运行之间保留什么以及重复的请求如何成为存储的调度。 Automations 指南的一部分。
自动化如何工作
- 自动化在 Gateway 进程内部运行，而不是在模型内部运行。Gateway 必须处于运行状态，计划任务才会触发。
- 任务定义、运行时状态和运行历史会持久化在 OpenClaw 的共享 SQLite 状态数据库中，因此重启不会丢失计划任务。
- 自动化运行记录在 cron 运行历史记录中。
- Agent、命令和脚本作业将其结果写入接收它的聊天或主题，包括不创建对话的作业。不同的传递目标得到结果而不是创建聊天；如果没有外部路由，则创建会话会接收它。执行上下文保持独立。请参见 自动化交付 。
- 一次性作业 （
--at） 在成功完成后自动删除：已确认交付、未请求、有意抑制或明确尽力而为。失败或未知的所需交付将保留禁用的作业以供检查，而无需重放有效负载。通过--keep-after-run也能保住成功的工作。 - 每次运行挂钟预算：设置时为
--timeout-seconds。否则，isolated/detached 代理轮转作业受到调度程序自己的 60 分钟看门狗的限制；命令作业默认为 10 分钟，脚本负载默认为 5 分钟。此调度程序截止时间与每个模型尝试预算无关（agents.defaults.timeoutSeconds，默认 48 小时）：启动回退不会重置它。 - 在网关启动时，过期的代理轮换作业和等待检测信号的作业将被重新安排，而不是立即重播，从而使 model/tool 的执行不受调度程序启动的影响。这包括心跳监视器、迁移的心跳任务以及立即唤醒的主会话系统事件。启动追赶延迟在标签或有效负载内容协调和另一次重启后仍然存在；更改计划会启动新的计划决策。
- 在成功或跳过的计划运行期间传递的 Cron 槽在重新启动时不会重播。该轮比赛结束后错过的位置仍然有资格追赶。强制运行仍然保留其预定发生的情况。
- 当正在运行的网关在截止日期后唤醒时，cron 工作线程会使用其存储的截止日期和运行请求合并错过的计时器滴答声。 Worker拥有调度、队列容量和持久结果；网关启动已提交的请求并在关闭期间加入工作线程。
- 如果您从系统 cron 或其他外部调度程序驱动
openclaw agent，请用硬杀升级来包装它，即使 CLI 已经处理SIGTERM/SIGINT. 网关支持的运行要求网关中止接受的运行；--local运行时得到相同的中止信号。对于 GNUtimeout，优先选择timeout -k 60 600 openclaw agent ...而不是普通的timeout 600 ...— 如果过程无法及时排出，则-k值是后挡板。对于 systemd 设备，在最终终止之前使用带有宽限窗口 （TimeoutStopSec） 的SIGTERM停止信号。在原始网关运行仍处于活动状态时重复使用--run-id会将重复项报告为正在运行，而不是开始第二次运行。
隔离运行强化
- Scheduled 运行有自己的执行生命周期，从准入到结果持久化和清理。计时器滴答、启动追赶和事件源观察程序不会继承创建或更新它们的会话的请求状态。手动运行保留其调用者权限。
- Isolated 在完成时为其
cron:<jobId>会话运行尽力而为的密切跟踪浏览器 tabs/processes，并通过主会话和自定义会话运行使用的相同共享拆卸路径处置为作业创建的任何捆绑 MCP 运行时实例。清理失败将被忽略，因此运行结果仍然获胜。 - 当后代子代理正在运行或其完成交付处于挂起状态（包括保留扫描期间）时，A 运行的连续会话保持可用，因此清理无法搁浅其结果。
- 具有有限自动化自清理授权的隔离运行可以读取调度器状态、仅包含自身任务的经过自我筛选的列表，以及该任务的运行历史，并且只能移除自身任务。
- Isolated 运行防范过时的确认回复：如果第一个结果只是临时状态更新（
on it、pulling everything together和类似提示）并且没有后代子代理仍负责最终答案，则 OpenClaw 会在交付前重新提示一次实际结果。运行总数包括两个已完成的提示，按各自的模型定价；会话上下文的使用仍然反映最终的模型请求。 - 结构化执行拒绝元数据（包括节点主机
UNAVAILABLE包装器，其嵌套错误以SYSTEM_RUN_DENIED或INVALID_REQUEST开头）被识别，因此被阻止的命令不会被报告为绿色运行，而普通的助理散文不会被误认为是拒绝。 - 即使没有回复有效负载，Run 级代理故障也会被视为作业错误，因此 model/provider 故障会增加错误计数器并触发故障通知，而不是将作业清除为成功。
- 当任务达到
timeoutSeconds时，调度器会中止运行，并为其提供一个短暂的清理窗口。如果运行未能排空，Gateway 所有的清理机制会在调度器记录超时之前，强制清除该运行的会话所有权，从而避免排队的聊天工作被卡在过时的处理中会话之后。 - Setup/startup 停止会获得特定于阶段的超时（例如
cron: isolated agent setup timed out before runner start或cron: isolated agent run stalled before execution start (last phase: context-engine)）。这些看门狗甚至在外部 CLI 进程启动之前就覆盖了嵌入式和 CLI- 支持的提供商，并且其上限独立于长timeoutSeconds值，因此冷 start/auth/context 故障很快就会出现。
运行对账
Cron 拥有自己运行的恢复和历史记录；空的客户端进程并不表明网关运行已停止。
cron 工作线程记录执行和初次交付结果以及作业状态和历史记录。运行后通知随后发生；通知失败无法撤消记录的结果。
重新启动恢复将记录的终端结果与确切的运行标识进行匹配，并恢复它，而无需再次运行有效负载或交付。如果没有记录的最终结果，则活动运行会因交付 Unknown 而中断。被中断的预定单次射击将保持禁用状态；在手动重试之前检查其历史记录和收件人。早期的手动运行会保留其单独的计划发生，即使它在开始之前等待超过了截止日期。中断的手动运行仍然失败，不会重试。重复性作业将在未来的调度中继续。单独重新安排的一次性事件会保留其新发生的情况。这可以避免在崩溃后重播不确定的命令、脚本、工具或交付效果，但代价是可能会错过崩溃前标记为活动的事件。
排队的定时请求可以在重新启动后恢复。暂时有效负载丢失的排队手动或事件请求会记录跳过的结果，而不是重建有效负载。赶上限制和延误仍然影响着逾期的日程安排。仅当完成为 succeeded 时，最终结果为 deleteAfterRun 才会删除作业。
如果保存了已完成运行的历史记录，但其作业更新失败，则稍后确认的计划或节奏编辑将通过恢复保留其下一次检查。恢复保留完整的历史记录并解决旧的运行，而无需再次执行其有效负载。保存未更改的计划不会改变恢复已完成运行的方式。
中断的运行在运行历史记录中显示为失败。再次恢复相同的中断不会添加另一个历史条目。
将重复性工作提升为自动化
大多数自动化应该从代理已经完成的工作开始。当您多次要求基本相同的工作时，代理会提出将其转换为时间表，而不是仅再次运行一次。升级优于从头开始构建作业，因为提案继承了您已经阅读过的运行：您在输出开始按计划到达之前就知道输出是什么样子。
没有重复检测引擎，也没有新存储的历史记录。代理会识别对话本身的重复，并在提出新作业之前检查 automations(action: "list") 是否存在现有作业，因此您已创建的例程不会重复。驱动这一点的提示是由自动化工具控制的，因此没有它的代理永远不会提供他们无法创建的例程。
在创建任何内容之前，确认会用简单的文字重申时间表和任务，例如：“每个工作日 07：00 Europe/Vienna，我总结隔夜更新并将其发布在这里。”确认这句话，不是 cron 表达式。
智能体确认后：
- 创建作业，默认交付到您请求的对话：其通道和线程，或者没有外部路由时的对话提交。
- 立即在
force模式下与run一起运行一次，作为可见测试，传递到同一对话，因此您可以在第一次计划发生之前看到真实的输出。 - 删除作业并告诉您测试是否失败。
该作业被创建为 enabled，而不是禁用待批准，这是一个有意的安全选择。调度程序监督已启用的作业：失败的作业会发出故障通知，并在重复错误后自动禁用，并记录原因并通知所有者。没有任何人监督残疾人的工作。一个等待永远不会到达的确认的作业对于每个警卫来说都是不可见的，对默认的 automations list 是隐藏的，并且永远不会解雇或解释自己 - 一个无声的无结果，这是比运行并明显抱怨的作业更糟糕的失败。
您的确认仍然会影响创建，因此不会在您背后安排任何内容，并且测试运行是实际交付的真实运行，而不是渲染的预览：您批准的内容正是计划将产生的内容。