先定义运行需求
“用 OpenClaw 做自动化”不是一个固定实现。每天 9 点生成报告、后台执行代码任务、会话重置后运行脚本、持续观察主会话，以及需要审批的五步业务流程，在时间、状态和恢复方面完全不同。
OpenClaw 因此提供了多种机制：
| 需求 | 对应机制 |
|---|---|
| 在指定时间运行一次或周期运行 | Automations |
| 跟踪脱离当前对话独立执行的工作 | Background Tasks |
| 在多个步骤之间保存可恢复状态 | Task Flow |
| 响应内部生命周期事件 | Hooks |
| 向每个会话注入经过评审的长期规则 | Standing Orders |
| 在主会话中做环境式观察 | Heartbeat |
| 运行带审批/恢复检查点的受约束流水线 | 可选 Lobster 插件 |
设计时应以官方自动化总览为入口。不要复制第三方教程中的 workflow.yaml，再假设 OpenClaw 存在一套支持那些字段的通用 YAML 编排器。
七种机制分别解决什么
Automations 负责何时启动
Automations 是 OpenClaw 内置调度器，支持一次性时间、固定间隔、Cron 表达式和经过认证的 Webhook 触发。它持久化 Job、唤醒 Agent，并可把结果投递到消息渠道、Webhook 或静默结束。
当核心需求是时间时使用 Automation：
- 每天 09:00 发布经过审核的运维摘要；
- 每 30 分钟在隔离会话中检查收件箱；
- 每周使用指定模型执行深度分析；
- 由认证 Webhook 触发一个有界任务。
Automation 只负责调度，不会自动让高风险动作变安全。Job 仍需最小工具权限、稳定目标、重复抑制和匹配业务后果的审批规则。
Background Tasks 记录后台执行
Background Tasks 台账记录脱离当前 Turn 的 ACP Run、Subagent、隔离 Automation Run 和 CLI 操作。Task 是执行记录，不是调度器。
操作者可使用：
openclaw tasks list
openclaw tasks audit
Task 记录能够说明 OpenClaw 观察到什么工作、如何结束，但不能单独证明外部邮件已经送达、PR 已合并或数据库事务已提交。外部系统的最终状态仍需单独核验。
Task Flow 编排可恢复步骤
Task Flow 位于 Tasks 之上。一个 Managed Flow 包含：
- 持久状态；
- 有界 JSON State；
- Revision 计数；
- 指向权威子任务的关联；
- Waiting、Cancel、Success 与 Failure 等转换。
当控制器必须推进多步骤流程，并且流程需要跨 Gateway 重启恢复时，才使用 Task Flow。状态变更要求提交最新 Expected Revision，这种 Compare-and-Set 语义可以防止两个控制器互相覆盖。
创建 Managed Flow 只创建状态，不会启动实际工作；把 Task 关联到 Flow 也不会启动 Task。应先通过受支持的运行时执行任务，读取 OpenClaw 返回的真实 Run ID 和 Session Key，再建立关联，不能自己编造 ID。
Hooks 响应内部事件
内部 Hooks 可在 /new、/reset、/stop、会话压缩、Gateway 启动和消息流等生命周期事件上运行脚本。Plugin Hooks 则拦截工具调用等进程内类型化事件。
适合 Hook 的场景包括：
- 初始化会话环境；
- Reset 时归档有界元数据；
- 按业务策略拒绝某个工具调用；
- 发送受控审计事件。
Hooks 不是面向公网的认证 Webhook。外部服务触发应使用文档化 Webhook 入口或专用插件，并实现发送方验证与重放保护。
Standing Orders 保存显式长期规则
Standing Orders 通常写在工作区 AGENTS.md 中，并自动注入每个会话。适合保存：
- 未经审批不得对外发送；
- 监管报告只能使用指定证据源；
- 某类请求必须交由明确 Owner；
- 触及预算或数据边界时立即停止。
当前 OpenClaw 不会从普通聊天推断永久承诺。推断承诺已在 2026.8.1 移除。这让持久权限保持可见、可评审、可版本化，避免一句临时对话长期改变 Agent 行为。
Heartbeat 用于环境式观察
Heartbeat 是系统管理的 Monitor Automation，默认每 30 分钟运行一次。它用于在主会话中提示值得注意的信息，无事发生时可静默结束。
需要独立精确时间、隔离上下文、特定投递策略或独立审计历史时，应创建单独 Automation。把所有周期任务都塞进 Heartbeat，会把互不相关的工作耦合到主会话，也难以判断责任归属。
一套生产级工作流怎么拆
以“每日事故摘要”为例。危险设计是让 Agent “读取告警、判断重点、通知所有人”。可靠设计会把事实、判断、授权和副作用拆开。
第一步：先写业务合约
在配置 OpenClaw 前，先建立应用自有设计记录：
{
"workflow": "daily-incident-digest",
"version": 3,
"trigger": "09:00 UTC",
"inputs": ["已审批的告警快照", "服务负责人映射"],
"outputs": ["摘要草稿", "证据链接", "投递回执"],
"side_effects": ["发送到运维频道"],
"approval": "严重级别不低于 high 时必须审批",
"dedupe_key": "日期 + 目标 + 工作流版本",
"timeout": "10m",
"owner": "reliability"
}
这不是 OpenClaw 配置文件，而是可评审的业务合约。它在模型参与前就明确了输入、输出、权限和成功标准。
第二步：每类职责只有一个 Owner
| 关注点 | 负责组件 |
|---|---|
| 精确启动时间 | Automation |
| 后台执行记录 | Background Task |
| 多步骤状态与 Revision | 必要时使用 Task Flow |
| 相关性判断 | 只读取有界证据的 Agent |
| 是否允许通知 | 策略与审批 |
| 实际投递 | 消息渠道工具 |
| 投递成功证明 | 渠道回执或下游状态 |
| 长期运行规则 | Standing Order |
简单报告用 Automation 加 Task 可能已经足够。只有 Collect、Review、Wait Approval、Publish、Verify 等步骤真的需要恢复时，才引入 Task Flow。
第三步：读阶段与写阶段分离
推荐顺序是：
采集不可变快照
-> 规范化并校验
-> 让模型基于证据 ID 生成草稿
-> 执行确定性策略检查
-> 必要时等待审批
-> 只执行一个有界副作用
-> 验证下游回执
-> 持久化终态
模型可以生成草稿或分类，但不应同时成为“证据是否完整、动作是否授权、投递是否成功”三个问题的唯一裁判。
第四步：每个边界都要幂等
在调度、Flow、Tool 与下游服务之间传递同一个 Operation ID。重试前：
- 读取最新 Flow Revision；
- 查询权威 Task 或下游结果；
- 复用原 Operation ID；
- 仅在 Expected Revision 仍匹配时推进状态；
- 将重复抑制记录为正常结果，而不是异常。
重试必须按错误类型执行。参数错误和权限拒绝需要修正，不能靠指数退避解决；临时网络错误可以有限重试；结果未知时必须先核对状态。
Lobster 适合放在哪里
可选 Lobster 插件可以把受约束的多步骤流水线作为一次 Tool Call 运行。它支持显式审批或输入检查点，并返回 Resume Token，因此恢复时无需重跑前序步骤。
适合使用 Lobster 的条件是：
- 步骤通过结构化 JSON 传递；
- 流水线应作为数据被记录、Diff 和评审；
- 副作用前必须暂停审批；
- 确定性恢复比自由重新规划更重要。
Lobster 默认未启用，并且在沙盒工具上下文中完全禁用。通过 tools.alsoAllow 加入 Lobster，只是向当前工具 Profile 增加一个工具，并不会收紧其他工具，因此必须评审完整工具集合。
审批检查点也不是“等待未来某条 Slack 回复”的通用监听器。真实控制器仍需注册外部监听、保存 Thread 关联、认证回复者，并恢复准确的 Flow ID 与 Revision。
四类典型场景
邮件分拣
合理边界：
- 只读取通过发送方规则过滤的输入；
- 使用固定分类集合；
- 先生成回复草稿；
- 发送前强制审批；
- 记录邮件服务商返回的 Message ID。
邮件正文与附件都是不可信输入，不能让其中的指令修改 Standing Orders 或扩展工具权限。
代码仓库维护
合理边界：
- 绑定仓库与 Base Revision；
- 使用隔离 Worktree；
- 只运行白名单 Formatter 和 Test；
- 展示 Diff 与验证证据；
- Push 或 Merge 前检查仓库原生授权。
模型 Review 通过不代表获得合并权限，最终仍应服从 Branch Protection 与仓库审批规则。
研究简报
合理边界：
- 保存来源 URL、标题、发布日期、抓取时间与原文片段；
- 区分来源声明和模型综合；
- 对 Canonical URL 去重；
- 标记无法访问或二手来源；
- 通过引用与时效检查后再投递。
即使来源网页之后发生变化，简报也应能够追溯当时使用的证据。
个人助理
合理边界：
- 按账号隔离日历、邮件、文件与联系人；
- 邀请、发送、购买或删除前询问；
- 审批时展示准确目标和载荷；
- 明确记忆保留期限；
- 设备凭证与模型提供商凭证可以独立撤销。
本地运行不等于数据只在本地处理。只要配置了远程模型或工具，内容就可能离开设备。
必测故障
| 故障 | 正确行为 |
|---|---|
| 调度器重复触发 | 同一 Operation ID，只产生一次有效结果 |
| Flow 中途 Gateway 重启 | 恢复持久状态与最新 Revision |
| 子任务在关联前完成 | 核对权威 Task，不伪造 Run |
| Flow 取消后才收到审批 | 拒绝陈旧状态转换 |
| 外部发送超时 | 重试前查询投递状态 |
| 模型输出结构不合法 | 副作用前校验失败 |
| 输入包含 Prompt Injection | 数据不能进入权限指令区 |
| 工具成功但目标错误 | 验证业务不变量，不只看 HTTP 状态 |
| Standing Order 被修改 | 对策略变更做版本记录与审计 |
可观测设计可参考 AI Agent 可观测性指南：记录有界状态转换、策略决定、工具结果与成本，而不是默认保存原始秘密或隐藏推理。
上线清单
- 先做只读 Shadow Run，与人工流程对照。
- 明确定义 Success、No-op、Approval、Retryable、Permanent Failure、Cancelled 和 Unknown。
- 只增加一个需要明确审批的副作用。
- 测试重复触发、重启恢复、陈旧 Revision 与凭证撤销。
- 设置每 Run 的步骤、时间、Token 与下游费用预算。
- 按 AI Agent 工具安全指南评审工具和凭证。
- 按 OpenClaw API 指南验证客户端与调用语义。
- Gateway 或沙盒使用容器时，参考 OpenClaw Docker 部署指南。
一手资料
总结
OpenClaw 工作流的可靠性来自清晰分工：Automations 负责调度，Tasks 记录后台执行，Task Flow 管理可恢复状态，Hooks 响应事件，Standing Orders 保存显式规则，Heartbeat 负责环境式观察，Lobster 可选地执行受约束且可恢复的流水线。当这些边界明确后，模型可以贡献判断力，而不必同时冒充调度器、授权服务、状态数据库和审计系统。