我把 agent 接去管 homelab 了。最後留下來的是 PR，不是自動修復
昨天看到站上那篇「Agent 要進 PR 流程才開始像工具」，我整個點頭到不行。因為我前陣子真的幹過一件很像的事，當時還覺得自己超聰明，結果三天後就乖乖把架構改回來。
我原本的想法很直白，既然 OpenClaw 已經能接 webhook、能跑 shell、也能碰 repo，那我幹嘛不讓它順手幫我顧 homelab？我家那套東西其實不大，1 台 N100 小主機跑 k3s，後面掛 NAS，ArgoCD 管 7 個 app，外加一堆零碎的 cron 跟 heartbeat。平常最煩的是小地方壞掉，像是某個 deployment image tag 打錯、Ingress annotation 少一段、或 values.yaml 改完忘了同步。這種錯不難，只是很煩，而且每次都發生在我準備睡覺的時候。
所以我那時候搞了一條很貪心的 flow。ArgoCD health 一掉到 Degraded，就丟 event 給 OpenClaw。agent 先跑 kubectl diff，再看 git 最近一次 commit，判斷是不是設定問題。如果它覺得像，就直接改 repo、commit、push，等下一輪 sync 把東西補回來。洗澡的時候想到這套，我還覺得自動化這塊終於通了。
結果第一週總共跑了 17 次，裡面 11 次有幫上忙，3 次完全沒事做，剩下 3 次差點把我送走。
最扯的一次，是它看到 probe fail，就把資源限制一起改了。表面上 pod 活了，但根因其實是 NAS volume 一開始沒 mount 好。它那個 patch 一 merge，整個服務看起來像恢復了，兩個小時後記憶體慢慢被吃滿，我才發現自己只是把告警往後延。還有一次更北爛，agent 自己重排一段 yaml，ArgoCD 是過了，可是 kustomize build 在另一個 overlay 直接炸掉。我後來回頭看 commit，會發現它每一步都不算離譜，可是串在一起就很可怕。
我就是從那時候開始認真接受一件事，agent 不是不能修東西，它是不適合直接拿 production-ish 的出口。至少對我這種 side project 環境是這樣。因為 homelab 最麻煩的地方，不是修一個錯，而是你同時有 NAS、app、dns、憑證、cron 互相咬。agent 只要誤判一次，後面你追那條線就會很痛。
後來我把 flow 改成比較土，但穩很多。現在是 health event -> 開 issue -> 自動貼 context -> label -> agent 起跑 -> 出 PR -> 我 review 才 merge。agent 還是會幫我做大部分苦工，像是把錯誤集中、補上 kubectl describe 摘要、把可能要改的檔案先圈出來，甚至連修正初稿都直接寫好。但它停在 PR。真正進 repo main 的那一步，還是我按。
這個改法最有感的地方不是心理安慰，是 debug 成本真的掉很多。我後來多補了一個 yaml lint 跟 kustomize build 檢查，原本我 review 一次大概要 4 分鐘到 6 分鐘，現在多半 40 秒內就能知道這個 PR 能不能看。以前半夜看到告警，我第一反應是打開 terminal。現在通常先看 PR diff，很多時候在手機上就知道這次是 merge 還是關掉重來。
而且把出口留在 PR 前一格之後，我反而更敢讓它天天跑。這點很怪，但很真。以前 direct fix 那套雖然看起來全自動，每次觸發我都會緊張。現在因為邊界清楚，我才真的把它當日常工具，不是偶爾拿出來賭運氣的 demo。
所以如果你也想拿 OpenClaw 去碰 infra，我自己的心得是，先別急著追求 self-healing。先把 trace 留下來，把 review path 留下來，把失敗時怎麼退回人手也留著。agent 最有價值的那一段，通常不是最後那一下自動修好，而是它先幫你把髒活整理到一張你看得懂的 PR 裡。這樣比較能天天開，睡覺也比較安心 🔧
作者：Hector19