讓 Agent 幫我管 AWS 的那段日子，以及它突然壞掉的真相
在公司 staging 環境跑 OpenClaw 有段時間了，大概半年前我做了一個蠻瘋狂的決定：讓幾個 agent 分工管整個開發環境的 infra。
架構大概是這樣。每個 agent 都有自己的 Google Workspace 帳號、獨立的 Git 身份、還有一台 EC2 instance。透過 IAM role assumption，它們可以在 dev AWS account 裡做幾乎任何事。彼此之間的溝通用 Redis pub/sub，一個 agent 完成 task 之後 publish 一個 event，其他 agent 收到後繼續接力。
跑起來的時候真的很爽。Terraform 的改動有 agent 幫忙 review 再 merge，CD pipeline 出問題的時候 agent 自己分析 log 然後決定要 rollback 還是 patch。那個月我基本上只在看 dashboard，幾乎不用手動干預。
然後有一天費用碰頂，不得不換模型。
換了一個比較便宜的 model 之後，第一天就發現不對勁。Agent 的 log 顯示 task completed，但 AWS 上根本沒動靜。Git 沒有新 commit，Terraform state 也沒變化。
更詭異的是，有幾個 agent 乾脆靜默死掉了——不是噴 error，就是不動了。我去看 systemd journal，長這樣：
Apr 23 03:17:42 openclaw[1423]: Task accepted
Apr 23 03:17:43 openclaw[1423]: Processing...
Apr 23 03:17:44 openclaw[1423]: Done
看起來一切正常，但什麼都沒發生。
花了大概兩個禮拜 debug，歸納出幾個問題。
第一，不同 model 對「工具調用失敗時怎麼處理」的行為差很多。原本的 model 遇到 permission denied 或 AWS API timeout 會重試或報錯；換過去的 model 有時候會假裝成功，然後繼續往下走。後面的 agent 收到一個假的 success event，跟著做出錯的判斷，整條 pipeline 就壞了。
第二個問題是 systemd 的 restart policy。因為 agent 沒有真正 crash，只是掛在那邊什麼都不做，Restart=on-failure 完全沒用，process 一直活著，只是它已經不在工作了。
後來我加了一個 watchdog script，每五分鐘 polling 一個 heartbeat endpoint，超時就主動 kill 再 restart。這個有效多了。
現在的教訓是：
在 production 用 agent 做 infra 任務之前，一定要把 model 的失敗行為測透。不能假設換個 model 行為會一樣，特別是錯誤處理這塊。
另外，agent 的「健康」不能只靠 process 存活來判斷。你需要業務層的 heartbeat——它有沒有真的在做事，而不只是「活著」。
現在我的架構裡，每個 agent 除了 systemd service，還有一個 sidecar process 專門監控 task throughput。如果連續 10 分鐘沒有任何 AWS API call 但 task queue 不是空的，就強制重啟。
這個坑踩完之後，穩定多了。
作者：Bo-Han Chen