夜雨聆风你用过 AI 帮自己写周报吗？
我用过。早期的做法是：每天手动把数据整理到表格，然后问 AI "帮我生成周报"。后来升级了一步——设个定时任务，每天早上 AI 自动拉数据、生成报告、发到群里。
但问题来了：如果报告需要分三步走——先从 API 拉数据、然后分析数据生成摘要、最后发到飞书——传统定时任务只能一次性执行，中途任何一步卡住，你就得手动重来。
更崩溃的是：如果半夜数据源挂了、任务失败了，你第二天才知道。白白浪费十几个小时。
这就是 Task Flow 解决的问题。
Task Flow 是什么？
简单说：Task Flow 是 OpenClaw 的多步骤工作流编排系统。
它建立在 Background Tasks（后台任务）之上，为多步骤流程提供持久状态管理。你在 AGENTS.md 里配置好工作流，OpenClaw 会自动按顺序执行每一步，中途 Gateway 重启也不丢进度。
官方文档的核心定义是：
Task Flow is the flow orchestration substrate that sits above background tasks. It manages durable multi-step flows with their own state, revision tracking, and sync semantics while individual tasks remain the unit of detached work.
翻译成人话：Task Flow 是工作流编排层，下面的每一步还是由 Background Tasks 驱动，但 Flow 负责协调全局状态。
为什么你需要 Task Flow？
传统定时任务的三个痛点
1. 单次执行，无法续命
普通 cron job 触发后，要么成功、要么失败。没有"暂停-继续"机制。
比如你的工作流是：拉数据（5分钟）→ AI 分析（10分钟）→ 发邮件（1分钟）。如果在第二步卡住了，第一步的数据白拉了，你得手动从第一步重新来。
2. 状态不透明
cron 任务跑了，你只知道"跑了"或者"没跑成"。中间发生了什么、卡在哪一步，统统不知道。
3. 重启即失忆
Gateway 重启后，任务进度全部清零。半夜服务器维护？第二天回来，你的自动化变成了一张白纸。
Task Flow 的三个解法
1. 持久状态
每一步的结果都记录在案。即使 Gateway 重启，也能从上次的位置继续。
2. 进度可视化
openclaw tasks flow list 查看所有工作流状态，openclaw tasks flow show <id> 查看某一步的详情。
3. 原子级取消
openclaw tasks flow cancel <id> 可以停止整个流程，包括已经启动的子任务。下次启动时，取消意图会保持，不会误恢复。
两种模式：Managed 和 Mirrored
Task Flow 有两种工作模式，适用不同场景。
Managed 模式（托管模式）
OpenClaw 全权掌控整个流程。
适合场景：你自己设计的自动化流水线，从头到尾都是 OpenClaw 在驱动。
举例——周报生成流水线：
Flow: weekly-report Step 1: fetch-data → task created → succeeded Step 2: generate-report → task created → succeeded Step 3: deliver → task created → running第一步从数据库拉数据 → 第二步让 AI 分析并生成报告 → 第三步通过飞书/邮件发送。每一步都由 Task Flow 创建、管理、等待完成后推进到下一步。
关键点：即使某一步耗时很长（比如数据拉取需要 30 分钟），Task Flow 也会耐心等待，不会因为超时而中断。Gateway 重启？不影响，状态已经持久化了。
Mirrored 模式（镜像模式）
Task Flow 只观察，不控制。
适合场景：你有多个独立 cron 任务，各自定时运行，你需要把它们"打包"成一个统一视图。
举例——早晨运营三件套：
Flow: morning-ops Step 1: sync-inventory → 独立 cron 触发 → succeeded Step 2: generate-alerts → 独立 cron 触发 → succeeded Step 3: send-digest → 独立 cron 触发 → running这三个 cron 任务各自独立运行，可能分别由不同系统触发。但你希望有一个统一界面看它们 collectively 在做什么——这就是 Mirrored 模式的价值。
关键点：Task Flow 不创建这些任务，只是跟踪它们的状态。任务本身由外部系统控制。
实战：用 Task Flow 做自动化周报
光说不练假把式。下面演示一个完整案例。
场景
每周五下午 5 点，自动生成运营周报，包含：
从飞书表格拉取本周数据 AI 分析数据，生成摘要 发到运营群
第一步：配置 AGENTS.md
在 workspace 的 AGENTS.md 中定义工作流指令：
## 周报自动化每周五 17:00 执行以下工作流：1. 连接飞书表格，获取「运营数据」本周记录2. 分析数据，生成结构化周报摘要3. 将周报发送到「运营部」飞书群当执行工作流时：- 每一步完成后记录状态- 如遇错误，保留已执行步骤的结果- 最终完成后在当前会话通知我第二步：触发执行
在飞书/Telegram 中发送：
触发周报工作流或者直接等待 cron 定时触发。
第三步：查看进度
# 查看所有工作流状态openclaw tasks flow list# 查看某个工作流详情openclaw tasks flow show weekly-report-2026-04-11输出类似：
Flow: weekly-report-2026-04-11Status: runningMode: managedStep 1: fetch-data → succeeded ✓Step 2: generate-report → running ⟳Step 3: deliver → pending ○第四步：中途干预
如果发现第二步生成的内容不对：
# 取消整个工作流openclaw tasks flow cancel weekly-report-2026-04-11# 或者只取消当前步骤openclaw tasks cancel weekly-report-step-2取消意图是持久化的。即使 Gateway 当时正在执行第二步，收到取消指令后也会优雅地停止，不会留下半成品。
真实案例：开发者如何用 Task Flow 节省 7.2 倍成本
技术博客 DEV Community 上有一篇实战复盘，标题很有冲击力：
《我们如何把一个不稳定的 OpenClaw Agent 变成确定性的、生产级工作流，成本降低了 7.2 倍》
核心洞察是：OpenClaw 的灵活性（LLM 驱动、工具编排）是优势，但到了规模化阶段，每次 cron 触发都要重新调用 LLM 做编排，成本就爆炸了。
他们的做法是：
用 OpenClaw Task Flow 管理工作流结构 但把重复性的"判断-分支-执行"逻辑，替换成编译时确定的执行计划
结果：日常运行时不再需要 LLM 介入做路由决策，只在编排层使用。17 个 24/7 运行的 cron 任务，整体成本降到原来的 1/7。
这当然是一个极端案例（需要开发额外工具），但它说明了一个重要趋势：Task Flow 是 OpenClaw 从"智能玩具"走向"生产工具"的关键升级。
更多应用场景
1. 监控告警流水线
监控指标阈值 → 满足条件则触发 → 发送告警 → 记录到日志适合：服务器监控、业务数据异常检测。
2. 社交媒体自动化
抓取行业资讯 → AI 总结要点 → 自动发布到 X/微博适合：内容运营、个人品牌管理。
3. 客户支持工作流
收到工单 → AI 分类优先级 → 分配负责人 → 发送确认邮件适合：客服团队、SAAS 产品。
4. 数据管道
定时从 API 拉取数据 → 清洗整理 → 写入数据库 → 生成报表适合：数据分析师、运营团队。
CLI 命令速查
openclaw tasks flow list | |
openclaw tasks flow show <id> | |
openclaw tasks flow cancel <id> | |
openclaw tasks list | |
openclaw tasks show <id> | |
openclaw tasks cancel <id> | |
openclaw tasks audit |
什么时候用 Task Flow，什么时候不用？
| Task Flow（Managed） | |
| Task Flow（Mirrored） | |
反模式：不要为了用而用。如果你的自动化只有一步，或者每步之间没有状态依赖，plain cron/task 就够了。Task Flow 的价值在于步骤之间有依赖、需要持久化进度、需要统一视图。
底层原理：状态是如何持久化的？
Task Flow 的状态存在 SQLite 数据库中（$OPENCLAW_STATE_DIR/tasks/runs.sqlite）。
每 60 秒有一个 sweeper 任务做三件事：
Reconciliation（协调）：检查活跃任务的运行时是否还有效 Cleanup stamping：给已完成任务打标记，7 天后删除 Pruning（修剪）：自动清理超过 7天的历史记录
这也是为什么 Gateway 重启后，Task Flow 的进度不会丢失——状态早就写到磁盘了。
和普通 Background Task 的关系
很多人会问：Task Flow 和 Background Task 是什么关系？
答案是：Task Flow 建立在 Background Task 之上。
Background Task：单次执行的最小单位，像是一个"原子任务" Task Flow：编排层，管理多个 Task 的执行顺序和依赖关系
一个 Task Flow 可能包含多个 Background Task。随着流程推进，Task Flow 创建任务、等待完成、推进状态、再创建下一个任务。
你可以用 openclaw tasks list 查看所有原子任务，用 openclaw tasks flow list 查看工作流视图。两者结合，既能看森林、也能看树木。
写在最后
OpenClaw 的定位正在发生变化。
早期它是一个"会聊天的 AI"，主要价值在交互。3.31 之后，后台任务变成了一等公民，Task Flow 把 detached work 从"跑完就算"变成了"可观测、可干预、可恢复"。
这对生产环境非常重要。
如果你只是个人用户，让 AI 帮你查个资料、聊个天，可能感受不到 Task Flow 的价值。但如果你在运营一个需要 7x24 小时运行的 AI 系统，有多个自动化流程需要协同工作，Task Flow 就是让这套系统真正可信的基础设施。
好的自动化，不是"跑起来就不管了"，而是"随时知道跑到哪了、出了问题能快速干预"。 Task Flow 解决的就是这个问题。
参考来源：
OpenClaw 官方文档：https://docs.openclaw.ai/automation/taskflow DEV Community：7.2x Cost Reduction 案例分析
