OpenClaw 穩定性的問題，我覺得多數人找錯原因了
最近 Reddit 上有個討論，有人說用了四週 OpenClaw，項目推進很快、記憶表現好，還做了系統安全加固。跑的是本地 Qwen 27B，q4/q6 量化。
留言的焦點大多是「你怎麼能穩」，然後開始爭論 OpenClaw 到底能不能長期用。
我覺得這場討論有點跑偏了。
OpenClaw 能不能穩，跟你有沒有把它當一個系統在設計有直接關係。我用了兩個多月，踩的坑多到可以寫個小書，整理了幾個真的有用的東西。
模型選擇是第一個坑。
很多人把最強的模型塞進每個 task，然後抱怨慢、token 燒很快、有時候飄掉。那個說「穩定跑四週」的作者用 q4/q6 量化跑 27B 本地，這個選擇本身就說明了他在主動管理 cost/quality 的 tradeoff，沒有讓系統替他做預設決定。
我現在的做法是分層：過濾、分類、摘要這類任務用輕量模型；需要推理或生成的，才拉出大模型。這樣下來，整體 token 消耗比之前少了大概 40%，但產出品質幾乎沒掉。
第二個坑是 flow 沒有驗證點。
Agent 很難除錯，因為你看不到它在想什麼。我現在設計 task 的時候會強制加一個簡單的輸出確認，類似這樣：
Task 完成：整理 email 草稿（3 封）
摘要：...
Next：等待 review 後發送
就這樣。多了這個之後，「它飛掉了但我不知道在哪」的情況少了大概 60%。不是因為系統更穩了，是因為我知道它在哪個環節卡住。
維運習慣是最無聊但最重要的一塊。
記憶清理、context 長度監控、開 session 前先確認狀態是不是乾淨的。OpenClaw 長跑壞的原因很多時候是 context 爆掉但你不知道，然後繼續傻傻等輸出。
我現在每次開新 session 都會花大概一分鐘跑一個快速 health check，確認記憶狀態、上次有沒有未結束的 task。很無聊，但省了很多莫名奇妙的除錯時間。
從產品角度來看，那個說「已經穩定跑四週」的人不是運氣特別好。他只是把 AI agent 當成工程系統在維護，而大部分抱怨不穩的人還在把它當成魔法黑盒子在用。三件事：模型分層、加驗證點、固定維運習慣。能做到這三樣，穩定跑不是玄學。
作者：MingTech