從「對話工具」到「排程代理」

前面講的協作都是「我在場」的形態：我發起對話、它執行、我驗收。但 Claude Code 還有另一種運作形態——以排程代理的身份，在沒有人看著的時間自主執行任務。我的服務目前掛著幾條這樣的例行任務：

• 每日程式碼巡檢（清晨）：掃視程式碼庫，找出違反專案慣例的寫法、可疑的邏輯、缺測試的新增程式碼
• 同類服務動態觀察（早晨）：整理同領域產品的公開動態，輸出一份市場觀察摘要
• 資料管線健檢（上午）：確認每天的資料回補排程真的補到了資料、數量級是否正常、有沒有靜默失敗

每條任務跑完，產出報告推送到一個獨立的報告分支；如果巡檢發現了值得修的問題，修正提案也是推到獨立的工作分支——永遠不直接碰主分支。

整套設計只有一條核心原則

自動化代理的產出永遠不直接生效。發現問題、分析問題、甚至寫出修正程式碼——都可以；讓修正自動上線——絕對不行。

這條線為什麼劃在這裡？回想 Day 27 會講的部署機制：主分支的變更會自動部署到正式站。如果巡檢代理能直接改主分支，等於「一個沒人監督的自動程序，擁有改變正式服務行為的權力」——這個組合在任何規模的組織裡都是事故配方，一人公司尤其如此，因為出事時連第二雙眼睛都沒有。

所以權限結構是：代理有完整的「讀」和「提案」權，「生效」權為零。 每天早上我花幾分鐘掃過夜間報告——大多數日子是「一切正常」，偶爾有真貨：某次資料健檢在我毫無察覺的情況下，抓到一條回補管線「寫入了 0 筆但流程顯示成功」的靜默失敗——那種不報錯的失敗（這系列的老朋友了），靠人力每天盯是不現實的，靠代理每天核對數量級,一天就現形。

「值得巡檢的東西」怎麼挑

不是所有東西都值得排一條夜班任務。我的篩選標準有兩條：

一、失敗是靜默的。 會大聲報錯的東西，告警系統會通知我，不需要巡檢；只有「看起來成功、實際失敗」的形狀（寫入 0 筆、額度悄悄異常、文案悄悄漂移）才需要主動去核對。

二、核對是機械的、判斷是稀少的。 「昨天的資料筆數是否在正常區間」是機械核對，適合代理；「這個功能的方向對不對」是持續判斷，不適合（Day 25 的原則在排程場景同樣成立）。

夜班工程師的比喻，和它的邊界

我把這套機制叫「夜班值班工程師」，但這個比喻有一個必須說清楚的邊界：真正的值班工程師有處置權，我的代理沒有。 它更像一個非常勤快的夜班「巡邏員」——發現異狀、拍照存證、寫報告放在你桌上，但鑰匙不在他身上。

會不會有一天我把處置權也交出去？也許某些極低風險的類別會（例如自動 retry 一條冪等的回補任務）。但那會是一條一條明確授權的白名單，而不是「它夠聰明了，讓它自己判斷吧」——信任 AI 的正確方式從來不是擴大它的自由裁量，是擴大明確授權的清單。 這句話大概是整個系列裡我最想讓人記住的一句。