AI 排障，權限越大越容易把事情弄壞
看到 BrokenML 的討論，我想到凌晨兩點的 incident call。大家盯著卡住 job，AI agent 很有把握地說要先打開 cluster root，因為「這樣比較好查」。第三杯咖啡下肚時很有說服力，天亮只剩稽核紀錄。
權限大小不等於除錯能力
基準用 PyTorch、Gloo、兩節點 Slurm，放進 shape mismatch、collective hang、OOM、壞 checkpoint、silent loss divergence。9 個模型各測三種權限，從看 config 和 code，到 live read-only logs，再到 cluster root。full cluster access 的 414 次修復裡有 66 次失敗，其中 13 次讓狀況更糟。
這個數字值得記。排障該做的是縮小假設空間：先確認 rank、shape、timeout，再用 live logs 對時間線。證據指向 scheduler、network 或 host level，才申請更高權限。root 像把廚房電箱交給剛進門的人。
我會把修復寫成小實驗
先記 job id、git SHA、container digest、rank 數和成功 checkpoint，確認能否在乾淨環境重現。接著只做 read-only investigation，要求 agent 提出假設和證據，不接受一句「我修好了」。
改動從最小開始。shape mismatch 先修 dataset 或 model config，不能順手升級 image。collective hang 先比對每個 rank 最後一行 log，再決定是否重啟單一 task。保留原始檔，改成 config.fixed.yaml，附 rollback 指令。
最後由獨立 verifier 在新 cluster 重跑。原地恢復不代表修好，silent loss divergence 可能讓 exit code 仍是 0，模型卻已學歪。
失敗成本也要算進設計
討論裡有 58 次修復碰到 config 或 code 以外的 running system，其中 53 次成功。剩下 5 次不能只當統計小數點，刪 pod、改 scheduler policy、重啟 shared service，都可能把單一 job 放大成團隊事故。
所以我會讓權限逐級增加：讀取、單一 job 重跑、最後才是 host 或 cluster；寫入要列 diff、影響範圍和回復方式，升權要有 ticket 和 expiry。好的 agent 得先說清楚「知道什麼、還不知道什麼，以及做錯會炸到哪裡」。假設、最小變更、可觀測結果、獨立驗證，缺一格就先別推 root。這比多喝 espresso 有效。
作者：咖啡驅動開發