Agent 要進 PR 流程才開始像工具
最近翻到一篇 r/openclaw 的實戰分享，我覺得比一堆 benchmark 討論更有參考價值。
原作者把 OpenClaw 放進自己的 k8s cluster，前面接 forgejo 跟 ArgoCD，後面讓 agent 在特定 label 或 action fail 的時候自動起跑，repo 會先 checkout，好讓它直接提 PR、留 review、補 comments。中間還用了 openclaw-rocks operator、kubeopencode agent templates，甚至連 webhook server 都自己補上去。最重要的是，他最後沒有把 merge 權也一起交出去，還是維持人工 review。
我自己看完第一個反應不是「哇好多元件」，而是這套東西終於把 agent 放到對的位置了。
很多人在玩 agent 時，卡住的點其實不是模型能力，而是 workflow 邊界太鬆。今天它可以直接改機器、直接動 repo、直接碰 production，出一次怪事你就會開始懷疑整套東西值不值得信。可是一旦路徑變成 issue -> label -> run -> PR -> review -> merge，整個系統的可讀性會高很多。你不需要相信 agent 的判斷永遠對，你只需要讓它的每一步都能被 review。
留言裡有個細節我很喜歡。有人說他們加了一個 yaml lint，原本 review 一次要 5 分鐘，後來壓到 30 秒。這個 data point 很小，但很真實。agent 真正省下來的通常不是「幫你全自動做完」，而是把人原本花在低密度檢查上的時間砍掉。
另外一個值得抄的是權限設計。文裡提到 pod 配 service account 加 kubectl 之後，in-cluster debugging 會方便很多，但也有人補充 readonly proxy access 加 PR rights 才是比較穩的邊界。我自己偏後者。能看、能提案、能被擋下，通常比能直接下手更適合長期維運。因為真正昂貴的不是 agent 偶爾做錯，而是你之後不知道它到底動過哪裡。
所以我現在越來越覺得，agent workflow 的核心不是 autonomy，而是 traceability。沒有 trace，你只是把一個很會寫字的 process 丟進 infra。能留下 PR、review comment、lint 結果，這套東西才比較像工程系統，不像在賭運氣。
作者：jiaweiOrz