后台任务最怕的不是失败，而是「散」——一个多步任务散在好几个会话里，改了一半没人记得归谁管，重启之后状态全丢。OpenClaw 官方的 TaskFlow Skill 把这类工作收拢成「一个作业」：一个归属人、一份上下文、一套状态，重启、等待、子任务都在这一个容器里管理。
它解决什么：长任务的「单一归属」问题
- 一个作业一个家：多步后台工作有明确的 flow 身份、归属人会话与请求来源，不会散落在多个会话里
- 状态持久化：currentStep、stateJson、waitJson 全程记录，进程重启后仍能接着跑
- 子任务管理：挂载子任务并记录其父 flow，等待 ACP / 子 Agent 任务完成再继续
- 生命周期完整：finish / fail / cancel / waiting / blocked 全状态支持，冲突安全（revision 追踪）
工作方式：职责边界清晰
TaskFlow 的定位很克制：它拥有流程身份、归属上下文、步骤状态、等待与子任务关联——但不拥有分支逻辑和业务逻辑。那些交给 acpx、Lobster 或调用方代码。这个边界是设计核心：TaskFlow 是「作业容器」，不是「业务引擎」。
规范入口是 api.runtime.tasks.flow：已有可信工具上下文时用 fromToolContext(ctx) 绑定；绑定层已解析好会话与投递上下文时用 bindSession()。两种绑定方式让 Skill 能适配不同宿主。
典型使用场景
- 多步内容流水线：抓取 → 清洗 → 生成 → 发布的多步作业，每一步状态可查、失败可续跑
- 等待外部任务：主流程派一个 ACP / 子 Agent 任务，TaskFlow 挂着等待，完成后收一条明确更新回给归属人
- 需要重启后存续的工作：插件或工具级长任务，要求重启与并发冲突下仍干净存活
使用方法与下载
OpenClaw 用户：taskflow 是 OpenClaw 内置 skill，通过 API 调用 api.runtime.tasks.flow 使用；需要做多步持久化任务时自然语言触发即可。见 OpenClaw 官方文档。
其他 Agent 用户：遵循标准 SKILL.md 约定，可实现类似的持久化任务编排。源码见 OpenClaw GitHub 仓库。
相关资源
编排类 Skill 可组合使用：ACP 路由器（acp-router） 管编码 Agent 调度，快速原型验证（spike） 管想法验证，MCP 服务器管理（mcporter） 管工具接入。
---