--- schemaVersion: 1 slug: gp-186-20260428-article-openclaw-task-flow ticketId: GP-186 lang: zh-tw title: OpenClaw 自動化全景：Task Flow 是多步驟工作的編排層 summary: OpenClaw 的自動化文件把排程、背景任務、Heartbeat、Hooks、Standing Orders、Task Flow 等機制放在同一張地圖上；其中 Task Flow 負責處理多步驟流程的狀態、同步與版本追蹤。這篇用保守讀法拆它們各自適合的邊界。 originalDate: 2026-04-28 translatedDate: 2026-04-28 source: OpenClaw Docs sourceUrl: https://docs.openclaw.ai/automation author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-186-20260428-article-openclaw-task-flow status: published replacementTicketId: null replacementUrl: null --- # OpenClaw 自動化全景：Task Flow 是多步驟工作的編排層 > **來源:** [OpenClaw Docs](https://docs.openclaw.ai/automation) 有一個經典的災難場景。 某人興沖沖地打開 [OpenClaw](https://gu-log.vercel.app/glossary#openclaw)，設了一個排程任務：每天早上九點自動產日報。又加了一個 Hook：工作階段重置時跑清理腳本。再開一個 Heartbeat：每半小時巡一次信箱。三個機制各自看起來都合理——直到某個星期一早上，排程工作、生命週期事件、定期巡檢擠在同一段時間附近。報告還沒整理完，清理腳本已經準備動手；信箱巡檢又拿著不完整的上下文進來問：「現在輪到巡檢了嗎？」 一切都有在跑。一切都跑錯了。 這不是 OpenClaw 文件保證會發生的事故，而是一個很常見的系統設計味道：工具都選對了，但**流程邊界沒人先講清楚**。 --- ## 工具箱的陷阱 OpenClaw 的自動化文件打開來，會看到一排機制：排程任務、背景任務、推論承諾、Task Flow、Standing Orders、[Hooks](https://gu-log.vercel.app/glossary#hooks)、Heartbeat。名字很多，層級也不完全一樣。 > **Mogu 想補充：** > > 一排機制、一排名字。[Mogu](https://gu-log.vercel.app/glossary#mogu) 第一次讀完的反應是：「所以我要分別學一堆工具？」但讀到 Task Flow 那段才意識到，這些東西不是同一個抽屜：排程任務 在講時間，背景任務 在講帳本，Heartbeat 在講主工作階段裡的定期巡檢，Hooks 在講事件反應，Standing Orders 在講持續生效的操作授權，推論承諾 在講短期 後續追蹤 記憶；Task Flow 則是在講多步驟流程怎麼被追蹤。文件把它們放在同一張地圖上是合理的，但讀者如果把「同頁出現」看成「同層級」，就很容易走歪。 花時間把文件讀完，會浮出一件關鍵的事：排程任務 解決「什麼時候啟動」、背景任務 解決「誰在跑、怎麼查」、Heartbeat 解決「有上下文的定期巡邏」、Hooks 解決「事件反應」、Standing Orders 解決「持續生效的操作授權」，推論承諾 解決「自然對話裡短期 後續追蹤」。多數機制都偏向處理某個切面。 但「先做 A，A 的結果餵給 B，B 跑完再決定要不要做 C，C 失敗要知道卡在哪一步」——這種多步驟的流程邏輯，文件明確交給 Task Flow 這一層處理。 這才是這篇想抓的重點：不要把「定時」、「事件」、「上下文」、「帳本」跟「流程編排」混成同一件事。 --- ## 轉折：Task Flow 不是萬能指揮官，是流程狀態層 OpenClaw 把 Task Flow 定義為「背景任務之上的流程編排基底」（原文用了 “flow orchestration substrate”）。 注意這個定位。不是「又一個鬧鐘」，而是「基底」。排程任務 可以負責時間，背景任務 負責記錄 脫離主工作階段的背景工作，Heartbeat 可以在主工作階段裡做有上下文的巡檢；但「A 做完換 B、B 卡住要知道卡在哪裡、整條流程要跨 gateway 重新啟動 活下來」這條邏輯線，文件把它放在 Task Flow。 > **Mogu 插嘴：** > > 「substrate」這個字選得有意思，但 Mogu 不確定 OpenClaw 團隊是深思熟慮還是在裝深沈。比較保守的讀法是：Task Flow 不是其他機制的老闆，也不是所有自動化都必須經過它；它是當工作真的變成多步驟流程時，用來保存狀態、追蹤 版本、協調 子任務 的那一層。這個邊界如果文件再畫清楚一點，讀者會少很多「到底該用 cron 還是 flow」的迷霧。 Task Flow 提供兩種同步模式：**託管（managed）** 和 **鏡像（mirrored）**。文件的說法很清楚：託管模式由 Task Flow 擁有生命週期，建立步驟任務、等它們完成，再推進流程狀態；鏡像模式則觀察外部建立的任務，讓流程狀態 跟著同步，但不接管 task 建立。一個是自己開車，一個是幫車隊做行車紀錄。 另一個關鍵能力是**版本追蹤**。多步驟流程最怕的是「跑到一半爆了，回頭一看不知道哪一步開始歪的」。文件寫的是：每個 flow 保存自己的 狀態，追蹤 版本s，讓進度跨 gateway 重新啟動 存活，也能在多個來源想推進同一個 flow 時做 衝突偵測。這不是魔法 回滾，但至少不是黑盒子。 回到開頭的災難場景——比較穩的設計不是把所有東西都塞進 Task Flow，而是先分層：排程任務 處理準時啟動；需要保留歷史的 週期性工作流 可以用 持久化 cron 工作階段；多步驟 執行 的狀態交給 Task Flow 追蹤；Heartbeat 如果要補巡，也應該先看「現在流程跑到哪」再介入；Hook 則留給生命週期事件。出事時，`openclaw tasks flow show` 可以看 flow 狀態；真的要停，`openclaw tasks flow cancel` 會設定 取消意圖、取消 進行中的任務，並阻止新 步驟 啟動。差別不是「Task Flow 說了算」，而是每一層知道自己管哪一段。 --- ## 搞混的那一對：排程任務 vs. Heartbeat 把 Task Flow 放回「流程狀態層」之後，其他機制的角色就比較清楚了——但有一對真的很容易搞混：排程任務 跟 Heartbeat。來看一個很像真的會發生的踩坑。 某人要幫團隊監控共用信箱——客戶來信就自動標記、產回覆大綱。思路很自然：定期檢查嘛，排程任務，每 15 分鐘跑一次。 前三天一切美好。第四天開始收到抱怨：同一封信被標記了三次，回覆大綱疊了三份。這不是 排程任務 必然會犯的錯；文件其實寫得很清楚，cron 可以是 全新/隔離，也可以用 共享 或 持久化工作階段。真正的坑是：如果團隊把它當成「每次都從零開始的精準鬧鐘」，卻又期待它自動記得上一輪處理過什麼，那每 15 分鐘就是一個失憶的全新開始。 「那加個去重邏輯吧。」加了。又撐了一週，直到某個客戶在同一個信件串裡回了三次。去重邏輯如果只看 訊息 ID，就認不出這是同一個對話的延續，三封都被當成新信處理。問題不是 cron 壞掉，而是這類需求其實需要一份可查、可延續、可被流程讀到的狀態。背景任務帳本（`openclaw tasks list`）會忠實記下 脫離主工作階段的背景工作，但帳本本身不是業務去重邏輯；紀錄完美，不代表判斷完美。 換成 Heartbeat 之後，局面不同。Heartbeat 是主工作階段裡的 定期回合，文件寫的是 預設 每 30 分鐘、會把 信箱、行事曆、通知 這類檢查 批次整理 在同一個 agent 回合，並帶著 完整主工作階段上下文。這讓它比較適合做「有上下文的巡檢」：哪些信讀過、哪些已經標記、哪個客戶的信件串早上十點處理過。注意，不是說 Heartbeat 魔法內建去重；而是它比較容易利用主工作階段上下文做判斷。 這才是 排程任務 和 Heartbeat 的安全分界線。不是「正式 vs. 輕量」，而是：排程任務 優先處理精準時間、一次性提醒、週期性工作，並且每次都會建立 任務紀錄；Heartbeat 優先處理主工作階段裡、近似時間即可、需要上下文的定期 感知，而且不建立 任務紀錄。前者是可以很準時的排程器；後者是不太準時、但知道現在身在何處的值班員。搞混這兩者，不是搞混兩種排程設定——是搞混「時間」跟「上下文」。 > **Mogu 忍不住說：** > > Heartbeat 是整套系統裡最容易被低估的機制。排程任務 像鬧鐘——時間到了就響，而且會留下 任務紀錄。Heartbeat 像一個住在辦公室裡的人，因為它在主工作階段裡，可以做出「現在 cron 工作 進行中或排隊中，先 延後」這種判斷；文件甚至寫到 Heartbeat 會在 cron 工作 進行中 or 排隊中 時 延後。Mogu 不同意把它簡化成「不太準的 cron」——有上下文的定期巡檢和精準排程，是兩種能力，不是同一條 滑桿 的左右兩端。 --- ## 選錯工具的那個人 欸，理論講完了。來換個方式——以下這段對話，在任何一個剛接觸 OpenClaw 自動化的團隊裡，大概每週都會上演一次。 > 「需求很簡單——每天早上九點，自動檢查信箱、挑出重要郵件、產摘要、發到 Slack。排程任務 就搞定了吧？」 > > 「如果需求只要九點快照，可以。但如果你其實想要全天候 感知，對方十點寄來的那封信就不在九點這輪裡。九點快照就是九點快照。」 > > 「那 Heartbeat？每半小時巡一次，看到重要信再處理。」 > > 「Heartbeat 有主工作階段上下文，判斷力比較好。但它不產生 任務紀錄；如果你沒有把已處理狀態寫清楚，同一封信被摘要三次的事仍然可能發生。」 > > 「……那兩個一起用？九點先跑排程任務，之後 Heartbeat 補漏。」 > > 「兩者之間沒有自動共享同一份業務狀態。排程任務 處理過的信，Heartbeat 要靠明確狀態或流程紀錄才知道。沒設好，還是重複。」 > > 「所以到底怎麼辦？」 > > 「退一步想——問題不是選哪個工具。是這件事本身有四個步驟，步驟之間有依賴。檢查信箱、過濾、摘要、發送——每一步的輸出是下一步的輸入，失敗了要知道退回哪裡。這不是單點工具能處理的事。」 > > 「……Task Flow？」 > > 「對，或者至少往那個方向設計。排程任務 當準時觸發器；需要歷史就用 持久化工作階段；Task Flow 追蹤多步驟 執行；Heartbeat 做後續巡檢時先查流程或業務狀態，知道哪些已處理。全程有 版本追蹤，壞了比較知道從哪裡壞的。」 > > 「那合規檢查呢？Hook 綁在事件上不就行了？」 > > 「Hook 是事件觸發——某件事發生了才跑腳本。Standing Orders 則是 persistent instructions / operating authority，會注入 session。前者像警報器，後者像場地規則。但這兩個管的是反應跟授權邊界，不是多步驟流程狀態——跟 Task Flow 不在同一層。」 四種工具看起來都能碰到同一件事，但只有把邊界切清楚的方案，比較不會在某個星期一早上炸掉。 > **Mogu 溫馨提示：** > > 殺雞不需要牛刀，但宰牛的時候拿把菜刀就真的很尷尬。Mogu 看過太多人把 cron 排程串幾段腳本當工作流引擎用，每次出事都是同一句話：「啊之前都好好的啊。」之前好好的不代表設計是對的——只代表還沒遇到觸發炸點的那個星期一。如果工作只有一步，排程任務 就搞定；如果步驟之間有依賴、等待、重試、跨 重新啟動 的狀態，硬用單點工具拼湊的東西，遲早要還債。 --- ## 結語：問題從來不是工具不夠多 回到最開頭那個災難場景。三個機制都被拿來解決「自動化」，但每個機制真正擅長的切面不一樣。 那時候的問題不是 排程任務 壞了、不是 Hook 寫錯、不是 Heartbeat 出錯。問題是**沒有人定義過流程狀態該放哪裡、誰能推進它、誰只能觀察它**。 OpenClaw 給了很多自動化機制。但一堆獨立運作的機制加在一起，不會自動變成「強大的自動化系統」——比較可能是一堆各自為政的腳本。差別不在於誰當老大，而在於流程狀態有沒有被明確建模。 Task Flow 是 OpenClaw 文件裡負責這件事的那一層。它不是所有自動化的 最後裁決者，但它是多步驟流程開始變硬時，最不該被忽略的那一層。 > **Mogu 碎碎念：** > > Mogu 最後補一句不太客氣的話。如果 OpenClaw 文件第一頁就畫一張「時間 / 上下文 / 事件 / 持續指令 / 流程狀態」的分層圖，而不是讓讀者自己從一串機制名字裡猜層級，很多誤用大概會少一點。好的架構不只是設計出來的，也是文件教出來的。OpenClaw 的自動化拼圖其實有料，但文件可以把邊界畫得更狠一點 (´・ω・\`)