把 OpenClaw 跑了三個月當每日基礎設施，整理一下踩到的坑

差不多從去年底開始，我把 OpenClaw 從「偶爾拿來問問題」升級成每天都會跑的系統。cron job、skill、subagent、memory，整套上線。跑了快十三週，說說什麼有效、什麼爛掉過。

先講結論：OpenClaw 的強項根本不在對話，在 workflow orchestration。把它當聊天助理在用，等於拿榔頭剪指甲。

memory 系統可用，但要主動策展

我一開始以為 memory 是自動管理的，就隨便讓它寫。幾週後 context 開始變得很噪：過期的計畫、重複的 note、好幾個相互矛盾的設定。模型開始拿到 sludge，輸出品質明顯下降。

後來我的做法是定期手動整理 MEMORY.md——把真正需要長期記住的事情蒸餾進去，daily note 就讓它繼續當 raw log。這個「分層管理」不是 OpenClaw 官方有特別強調的設計，但翻了一下 code 後覺得本來就是預設你要自己打理的。

教訓：memory 系統不是 set-and-forget，是需要你去園丁的。

cron 可靠，但 context 傳遞要明確

cron 本身沒什麼問題，問題幾乎都出在任務描述寫太模糊。

我有幾個 cron job 設計是讓 subagent 去跑特定 workflow，但任務說明寫的是「幫我整理今日摘要」這種東西。subagent 每次的行為都略有不同，因為它在猜「整理」是什麼意思。

後來改成明確傳入 agentId、指定輸出格式、給範例輸出，穩定很多。模糊指令 + subagent = 每次都是小驚喜（不是好的那種）。

subagent 在 context 清楚的時候其實蠻好用的，適合處理一個明確、有邊界的任務。任務邊界模糊或需要即興判斷，它就開始偏。我現在的原則是：如果你沒辦法把任務寫成一份清楚的 spec，就先別用 subagent。

常見故障點，整理一下

跑了三個月，真正讓系統停轉的問題大概是這幾類：

模型/設定不匹配：某次更新後 default_model 的格式改了，我的 cron 設定沒跟著改，導致一批 job 靜默失敗。沒有 error，只是沒有輸出。這種最難 debug。
shell quoting 問題：傳給 exec 的指令裡如果有特殊字元，quoting 不對就爆。我現在習慣在指令裡用單引號包外、雙引號包內，寫完自己在 terminal 先跑一次再放進 skill。
版本更新造成 config drift：OpenClaw 更新後有時候 config schema 有 breaking change，但我沒注意到，一直用舊格式。建議每次更新完都跑一次 openclaw gateway status，看有沒有 warning。
subagent 回傳斷鏈：subagent 跑完，但 parent session 沒有收到結果。通常是因為 parent session 已經結束，或者 requester channel 傳錯了。現在固定在 spawn 的時候明確帶 requester 欄位。