在 OpenClaw 裡硬做流程邏輯，是把問題留給 runtime
我也踩過這個坑。
去年 Q4 我們有個 use case：每週從幾個 data source pull report，跑一些 transformation，輸出摘要給 stakeholder。聽起來很簡單，但我在 OpenClaw 裡試著把整個流程 orchestrate 起來，前兩週簡直是噩夢。同樣的 prompt、同樣的 data，輸出每次都不一樣。有時候欄位順序不對，有時候 edge case 根本沒處理，debug 起來又沒有 stacktrace 可以看。
後來看到有人分享類似的心路歷程——以前在 OpenClaw 裡兜流程很挫折，改成 Codex build + OpenClaw execute 之後才真正穩下來。我完全理解那個轉折。
問題不是工具，是你把它用在錯的 layer
OpenClaw 是 execution layer，不是 logic layer。這個區別聽起來很基本，但真的很多人一開始都搞混了，我也不例外。
Logic layer 是你的 business rules：輸入什麼、怎麼 transform、什麼算成功、什麼算失敗。這些東西要確定性的、可測試的、版本控制的。
Execution layer 是 trigger、orchestrate、deliver。你告訴它「跑這個腳本，成功了通知我，失敗了告訴我哪裡壞了」。
把 logic 放進 execution layer，等於你在 runtime 才決定 business rules 是什麼。一旦出問題，你根本不知道是 logic 錯了還是 execution 的問題——兩個 concern 纏在一起，debug 沒有起點。
先用 Codex 把腳本打磨成可重複的東西
改成這個架構之後，我的工作流程大概是這樣：
先在 Codex 裡把腳本弄清楚。給它明確的 input schema（比如 JSON 格式的 raw data）、明確的 output schema（你要的摘要格式）、edge case list（空值怎麼處理、時區問題怎麼 normalize）。然後跑測試，確認同樣的 input 每次都給你一樣的 output。
這個過程可能要幾個 iteration，但時間值得花。你在買確定性。
腳本穩了之後，OpenClaw 只需要知道：什麼時候跑、input 從哪裡來、output 送去哪裡、出錯了叫誰。這些都是確定性的問題，不需要讓 LLM 在執行的時候動態決定。
可驗證輸出是這整件事的 prerequisite
這個架構有一個前提：你的 output 必須是可驗證的。
什麼叫可驗證？就是你能寫一個 assertion 說「輸出裡一定有 X 欄位」「數字加總一定在 Y 範圍內」「如果輸出是空的，那是 expected 還是 error」。
我們的 report 腳本裡有一個很陽春的 sanity check：
assert len(output["summaries"]) > 0, "Empty summaries - check data source"
assert all(s["date"] for s in output["summaries"]), "Missing date field"
這兩行讓我們省了很多 debug 時間。出問題的時候馬上知道是 upstream data 的問題、transformation logic 的問題，還是 OpenClaw 那邊 trigger 沒有正確 pass input。三個 layer 清楚分開，問題才有辦法 isolate。
沒有可驗證輸出的 automation，監控起來基本上是靠運氣。
邊界設計清楚，maintenance cost 才會掉
把 logic 和 execution 分開之後，邊界就很清楚了：
- OpenClaw 那邊：trigger 條件、input 來源、output 目的地、error notification
- Codex / 腳本那邊：business logic、transformation、validation、edge case handling
這個 separation of concerns 在 enterprise 場景特別重要。你的 logic 可能要過 compliance review，可能要 audit trail，可能要讓非技術的 stakeholder 也能看懂「這個腳本在做什麼」。如果 logic 全部藏在 prompt 裡，沒辦法 review，也沒辦法測試。
從 ROI 的角度：我們切換架構大概花了兩個 sp
rint（重寫腳本 + 重新設定 OpenClaw flows），但之後 maintenance cost 掉了大概 60%。以前每週都有一兩個 case 需要手動介入，現在幾乎不用。
這個 approach 對已經有實作基礎的團隊比較 make sense。還在 prototype 階段的話，直接在 OpenClaw 裡快速試也無所謂。但要進 production、跑 recurring workflow、讓其他人依賴你的輸出——這個架構切換值得認真考慮。
作者：Vivian L