把 OpenClaw 當 server 維運：24/7 長跑的實戰架構筆記
Reddit 上有人分享了在 Mac Mini M4 跑 OpenClaw 24/7 好幾個禮拜後整理出來的心得，從 infra 的角度看這篇寫得蠻扎實的。
他遇到的問題跟我在 staging 環境踩到的幾乎一樣：session 永不 idle 導致 context 一直長大、compaction 之後關鍵資訊消失、token 成本默默飆升、然後回應開始變慢。這不是 OpenClaw 的 bug，是把 agent 當 24/7 server 跑時本來就會碰到的事。
他提出的架構我覺得有幾個地方特別值得記：
Memory 要拆開管
不要把所有東西都塞進單一 MEMORY.md，按照 topic 拆成不同檔案。這跟我們做 infra 的邏輯是一樣的——monolith 可以起步，但要長跑就得拆服務。session 久了 context window 會爆，精簡的 memory 結構是防線之一。
daily reset at 4AM
這個我之前沒有系統性地做，他是設一個 4AM 的 cron 每天強制 reset session。有點像是把 agent 當成需要定期重啟的 process 在管。我自己現在是用 systemd watchdog 處理 crash recovery，但主動 reset 這個方向我覺得更穩——不等它壞掉，主動控制生命週期。
compaction 換便宜 model
Compaction 不需要用最強的 model，他用較便宜的 model 來做 context 壓縮，成本差很多。這個我還沒試過，值得實驗一下。在 production 要注意的是 compaction 之後一定要有驗證機制，確認重要的 checkpoint 沒有被砍掉。
外掛 cost tracker
他另外寫了 script 追蹤 token 用量，有點像是自己實作 cost budget。OpenClaw 目前原生不支援 cost budget，這個缺口如果在跑多個 cron 的場景真的會咬人——某個 session 失控了你根本不知道。
整體來說他的架構思路是對的：把 OpenClaw 視為需要 ops 的 workload，而不是「開著就好」的工具。我自己管 40 台 server 的經驗是，任何跑在 production 的東西都需要 observability、health check、以及定義好的 failure mode。OpenClaw 也不例外。
希望之後能看到更多 infra 導向的討論，目前這塊真的太少人分享了。
作者：Bo-Han Chen