跑了三週 OpenClaw 才搞清楚的幾件事
剛開始在 staging 環境裝 OpenClaw 的時候，前幾天其實蠻痛苦的。不是裝不起來，而是跑起來之後一直在燒 tokens、行為也不穩定，我花了很多時間排查，最後才慢慢弄明白幾個關鍵。
第一個坑：所有任務都掛同一個高成本模型
一開始我的想法很直接——既然要做到穩，就用最好的模型。結果跑了一週，費用帳單一出來我嚇到了。差不多快三倍的預算全部燒在一些根本不需要這麼強的任務上，比如「檢查某個 service 有沒有在跑」「把 log 抓出來格式化一下」。
後來改成分層路由：輕量的監控、格式轉換、簡單判斷走小模型；需要推理的才送到 Sonnet。這樣調整之後，一樣的任務量，費用降到原本的三分之一左右。
Infra 這邊的任務其實很適合分層，因為大部分操作都是有明確 output 的，判斷標準清楚，不需要複雜的語言理解。
第二個坑：agent 不會自己穩定，你得幫它設邊界
預設的 agent 在 production 跑起來之後，我發現它會有奇怪的行為——偶爾會在同一個任務上反覆 retry、context 一長就開始「忘事」、有時候明明任務沒有問題但會額外跑一些不在指令範圍內的動作。
真正讓它穩定的方式是在 AGENTS.md 裡寫明確規則。我的作法是：
- 明確列出「這個 agent 只做哪些事，其他一律不動」
- 加 anti-loop 指令：同一個操作如果三次回傳一樣結果，停下來回報，不要繼續
- 每次執行前做一次簡單的前置驗證（確認 target service 存在、port 是否可連）
這幾條加下去之後，行為穩很多。
第三個坑：一次接太多整合
剛裝好的時候手癢，想說反正都接了，順便把 email alert、Slack 通知、log 抓取、cron 排程全部一起弄。結果就是出問題的時候根本不知道從哪裡排查，一個整合的異常可能連帶影響另外兩個流程。
後來重新來過，先把最單純的那條跑穩（disk usage 監控 + alert），確認邏輯沒問題、rollback 的方式也清楚之後，才慢慢加下一條。這樣後來有問題的時候，至少能快速 isolate。
現在我們 staging 環境跑的是 Ubuntu 22.04 LTS（還沒升 24.04），每條 OpenClaw 的任務都用獨立的 systemd service unit 管理，設有 Restart=on-failure 和 MemoryMax。這樣就算某個任務 OOM 或卡住，不會影響其他流程，restart 也是自動的。
第四個坑：context 長了之後 agent 會忘事
OpenClaw 的 context 壓縮機制在長期跑的任務上偶爾會出問題。我碰過幾次是這樣：agent 在第 1-2 週跑得很好，到了第三、四週開始對某些設定「失憶」——明明在 AGENTS.md 裡有寫，但它就是沒 follow。
後來理解這是 context window 壓縮的副作用，解法是把重要的決策跟設定寫進 workspace 的文件裡、用決策日誌（DECISIONS.md）記錄關鍵配置，不要只靠 system prompt 記住所有事。每次新的 session 讓它讀一下這些文件，行為就會恢復一致。
大概就這幾個，踩完之後整體穩定很多。現在主要在想怎麼把這套推廣到 production——主管對「AI 自動跑 cron task」這件事還是有點保留，在想怎麼呈現才能讓他比較放心。
作者：Bo-Han Chen