昨天刚升了 4.1，写了一篇说 /tasks出来之后，后台任务终于不再黑箱了。

结果今天一翻 release notes，发现更大的东西在后面。

OpenClaw 4.2 今天正式发了。最值得说的一件事，是这条：

Tasks/Task Flow: restore the core Task Flow substrate with managed-vs-mirrored sync modes, durable flow state/revision tracking, and openclaw flowsinspection/recovery primitives

还有这条：

Tasks/Task Flow: add managed child task spawning plus sticky cancel intent, so external orchestrators can stop scheduling immediately and let parent Task Flows settle to cancelledonce active child tasks finish.

把这三条放在一起，我的感觉是：OpenClaw 终于把"AI 干活"这件事，往"AI 可靠地干活"又推进了一大步。

多步骤自动化，为什么以前总是不靠谱

用过 AI 写自动化脚本的人，大概都踩过这个坑：

你让它做一件事，这件事需要分 5 步。它吭哧吭哧做完了前 3 步，第 4 步出错了。然后你问它"刚才做到哪了"，它说"我再重新来一遍"，然后把前 3 步又做了一遍——要么是忘了，要么是重跑比排查快。

这只是最浅的问题。再往深一层，你会发现 AI 自动化系统的毛病其实是一组结构性问题：

状态不持久。任务跑着跑着，断了电、重启了服务，跑了多久、做完了什么，全丢了。你只能从头再来。

子任务不可控。你让它"去查资料、然后写报告、然后发给我"，它起了 3 个子任务。但你想中途取消，只取消写报告那步，保留查资料的结果——做不到。取消就是全取消，继续就是全部一起跑。

进度不透明。你在 Slack 或 Telegram 里发了一个长任务请求，它回了一句"我开始做了"，然后就沉默了。5 分钟后你不知道它是还在跑、卡住了、还是已经挂了。

编排不可观测。你起了多个子 agent，它们之间有没有互相等、有没有死锁、当前的瓶颈在哪——你看不到，只有等超时了才知道出事了。

这些问题，在单步任务里不是问题。但在真实工作流里，它们会让你从"AI 帮我自动化"退回到"还是我自己盯着吧"。

OpenClaw 4.2 解决的，就是这组问题。

Task Flow：第一次，任务流有了"地基"

4.2 里最核心的新功能，是 Task Flow substrate 回来了。

这不是新概念——OpenClaw 历史上曾经有过 Task Flow，后来某个版本里被重构掉了。这次 4.2 把它恢复了，而且配了一套完整的配套能力。

1. 持久化状态和版本追踪

Flow 现在有了 durable state。任务流中途断电、重启、崩溃，下次恢复时不再从头开始。系统会从上一次 checkpoint 继续跑。

而且每个 Flow 都有 revision tracking。你能看到当前是第几次执行、这次跟上次有什么变化。这对调试来说意义很大——以前任务失败了你只能看日志猜，现在可以直接对比版本 diff。

2. Managed child task spawning

OpenClaw 现在支持一个"父 Flow"派生出"子 Task"，而且子 Task 可以是 managed 模式——父 Flow 知道子 Task 在做什么，也能在子 Task 完成后自动收口。

更重要的：支持 sticky cancel intent。

什么叫 sticky cancel？就是你取消一个父 Flow，系统不会粗暴地把所有子 Task 一起 SIGKILL 了事，而是会先通知所有子 Task"我要停了"，让它们把当前步骤做完或者优雅退出，然后才真正关掉。

这在生产环境里非常重要。你不可能每次取消都让子任务强制退出——有时候它们正在写文件、写数据库、发送通知，必须给它们机会收尾。

3. openclaw flowsinspection/recovery 工具

4.2 加了一套 CLI 检查和恢复工具：

openclaw flows listopenclaw flows status <flow-id>openclaw flows cancel <flow-id>openclaw flows recover <flow-id>

你可以看当前有哪些 Flow 在跑、每个 Flow 进展到哪一步、哪个失败了可以恢复、哪个可以安全取消。

这意味着什么？意味着你终于可以用命令行管住你的 AI 自动化了。

sessions_yield：编排器终于能主动交出控制权

另一个我一直在等的工具：

Agents/subagents: add sessions_yieldso orchestrators can end the current turn immediately, skip queued tool work, and carry a hidden follow-up payload into the next session turn.

用场景说：

你有一个编排 agent，它派出了 3 个子 agent 分别去搜资料、写草稿、发通知。搜资料的 agent 最先回来，写完了。编排 agent 这时候不需要等剩下两个，直接处理资料，然后继续自己的流程——但以前没有 sessions_yield，它只能等所有子 agent 都回来才能继续。

有了 sessions_yield，编排 agent 可以说："我先把这份资料处理了，剩下的子 agent 回来时触发下一轮，我继续。"

这让真正的并行编排第一次变得自然。不是所有子 agent 全部完成后编排器才开始，而是每个子 agent 完成后都可以触发各自的处理流，编排器在每个节点主动决定下一步做什么。

为什么这些改动比新接一个模型更重要

过去一年，每次看 OpenClaw release notes，亮点都是"接了 GPT-5.4"、"接了 Claude Sonnet 4.6"、"支持 Gemini Flash"。

这些当然重要。但如果你认真用 OpenClaw 做日常自动化，你会发现真正卡住你的，往往不是"模型不够聪明"，而是：

• 工作流中途断了怎么办
• 多个任务并行时怎么管状态
• 某个任务失败时怎么只回滚它而不影响其他
• 怎么知道当前系统里有多少任务在跑、跑到哪了

这些问题，模型能力帮不了你。模型只能决定"做得好不好"，解决不了"做得稳不稳"。

4.2 的 Task Flow substrate，做的就是后半段的事。

它不是在让 OpenClaw 更聪明，而是在让它更可靠、更可观测、更可控。

exec 默认改成 YOLO 模式，这事值得注意

4.2 里有一条不太起眼但实际上挺重要的变更：

Exec defaults: make gateway/node host exec default to YOLO mode by requesting security=fullwith ask=off

翻译一下：OpenClaw 现在把"host exec"的默认行为从"每次都要问"改成了"YOLO 模式"——不需要弹窗审批了。

这是一个挺大的安全默认值变更。

对于共享设备、多人使用的场景，这可能是需要注意的变化。如果你想在某些 agent 上保持审批要求，4.2 提供了明确的配置路径让你把 ask 改回来。

建议：看完 release notes 之后，顺手跑一下 openclaw doctor，看看有没有 exec 相关的配置警告。

Provider 路由重构：基础设施在变扎实

4.2 还有一批很大的基础设施变更，埋在 Fixes 里：

• Provider transport policy 集中化：OpenAI、Anthropic、Copilot、图像生成的 HTTP 请求，现在全走同一套 auth/proxy/TLS 路径
• OpenAI-compatible routing 集中化
• Anthropic routing 集中化
• 媒体请求的 base URL 规范化、header 注入规范化

这些变更的共同点是：不是在加新功能，而是在消除技术债。

如果你自己写了自定义 provider 插件，或者在用 OpenAI-compatible 的私有模型端点，4.2 之后它们的行为会更符合预期。

升级建议

强烈建议升：

• 在用 cron 做多步骤自动化
• 有子 agent / 多 agent 编排场景
• OpenClaw 接了飞书做文档协作
• 在用自定义 OpenAI-compatible provider

建议测试后升：

• 机器上 exec 审批策略依赖默认配置
• Windows 环境在使用 OpenClaw exec

可以先观望：

• 只是本地偶尔对话，几乎不跑后台任务
• 4.1 刚装，还没来得及感受 /tasks

升级命令照旧：

openclaw update --yesopenclaw gateway restartopenclaw doctor

升完之后，建议跑一下这些：

# 检查 Task Flow 状态（如果有任务在跑的话）openclaw flows list# 检查 exec 策略有没有冲突openclaw doctor

我的判断

OpenClaw 4.2 是一个"把底层打扎实"的版本，不是一个"让 AI 更聪明"的版本。

但这恰恰是它最值钱的地方。

当一个 AI 工具还处于 demo 期，你只关心"它能不能做到"。

当它进入生产期，你关心的是"它能不能稳定地做到"、"做砸了能不能恢复"、"跑着的时候我能不能看得见"。

4.2 就是在回答后面这三个问题。

Task Flow substrate、child task cancel propagation、sessions_yield、persistent flow state、CLI 编排工具——这些东西单独拿出来，每一条都不炫酷。

但它们组合在一起，意义很清楚：

OpenClaw 在变成一个可以真正托付工作的系统，而不只是可以在你盯着的时候帮你做事的工具。

这个区别，就是 demo 和产品的区别。

你用 OpenClaw 跑多步骤自动化了吗？Task Flow 的 cancel propagation 和持久化状态，你有没有实际场景在用？评论区说说你的体验。