投入三個月才搞懂的事：OpenClaw 在長任務下為什麼這麼脆
說一個我花了很長時間才承認的事情。
我在 OpenClaw 上投入了大量時間，把公司的一堆 workflow 都串進去了——code review、deployment notification、自動 issue 開單，還有一些比較複雜的 multi-step task。短任務跑起來很順，但只要任務稍微長一點、複雜一點，就開始出現一個讓我很頭痛的 pattern：同一類問題反覆出現，然後反覆修，然後又出現。
這不是 bug，是架構層面的問題。
先說我踩過的幾個坑。
Context degradation。長任務跑到後半段，模型對早期決策的「記憶」會開始模糊。我有一個 skill 是自動整理 PR comment 然後跑後續動作，前 10 個 PR 都很準，到第 20 個開始開始出現奇怪的分類錯誤。回頭看 session log 才發現問題：context window 裡早期的 system prompt 被擠掉了，模型在做決策時已經「忘記」了某些 constraint。
修法：把關鍵 constraint 分散到 skill 的各個 action 裡，不要只在最前面定義一次。代價是 skill 變肥，但穩定性好很多。
State drift。我有一個 workflow 是這樣的：跑一個 loop，每次迭代根據上一次的輸出決定下一步。問題是 OpenClaw 本身不維護「真正可靠的狀態」，每次迭代的輸出都有一定的隨機性，累積下來路徑會漂移。10 次迭代後的結果跟預期可能差很遠。
修法：每隔幾個步驟強制把關鍵 state serialize 到外部檔案，下次迭代從檔案讀，不依賴 session memory。加了這個機制之後穩多了，但整個 skill 的複雜度也翻倍。
Error cascade。這個最難處理。一個步驟出錯，OpenClaw 有時候會嘗試自我修復，但修復的方式可能引入新的問題，然後在後續步驟才爆出來。最慘的狀況是你看到的 error 跟真正的 root cause 差了好幾層。
我花了很多時間在 debug 這種 cascaded error，最後的結論是：長 workflow 必須在每個關鍵節點加 explicit validation，不能依賴 OpenClaw 自己判斷「這步有沒有跑對」。
講完問題，說說我現在的 mitigation 策略。
# 我現在長任務 skill 的基本結構
actions:
- step: fetch_data
validate: [not_empty, schema_check]
on_fail: abort_with_log # 失敗就停，不要繼續跑
- step: process
checkpoint: true # 跑完把狀態寫到 state/
max_retries: 2
- step: output
validate: [format_check]
on_fail: fallback_template # 有 fallback，不要空手而回
核心思路：每個步驟都要有 explicit failure handling，不要假設前一步跑對了。這聽起來很基本，但在短任務裡你不會感覺到差異，長任務才會踩到。
另一個策略是任務切分。我現在把超過 10 個步驟的任務強制切成幾個獨立的 sub-skill，每個 sub-skill 自己有 input/output 介面，跑完就結束，下一個從檔案讀上一個的輸出。這樣就算中間某個 sub-skill 出問題，也不會影響其他部分，debug 也容易很多。
說回來，這些問題讓我對 OpenClaw 的評價更務實了。
它現在的狀態很適合做短任務的自動化，或者有人在旁邊盯著的 assisted workflow。拿來跑那種「丟進去、幾小時後來看結果」的完全自動化長任務，目前還不夠穩。
這不是說 OpenClaw 不好，而是它現在的設計重心不在這裡。我已經調整了使用策略：長任務切短、加 checkpoint、每個步驟加 validation。接受這個 limitation 之後，反而用得更順了。
如果你也在跑長任務一直踩坑，可能不是你的 skill 寫得不好，是工具本身現階段的天花板。調整期待，然後找 workaround。
作者：Jesse