Agent 操作員手冊：監督看不見的工作

操作自主 AI agent 是一門全新的專業：不是工程、不是管理、不是維運，而是三者兼備的混合體。當 agent 運行時間夠長，監督而非程式碼產出成為瓶頸時，操作員角色便應運而生。五項職責定義了這個角色，一套監督架構付諸實踐，一個介入框架決定何時該採取行動。

沒有人受過這份工作的訓練。沒有大學科系教授這門課，沒有職缺描述能準確定義它。上個月你還在寫Python，下個月你就得管理一個自主系統——它自己寫Python、呼叫 API、修改你的檔案系統，還在你入睡後做出架構決策。Ralph 迴圈在我的基礎建設中催生了這個角色：一段 shell script 以全新的上下文重啟 Claude Code、讀取檔案系統狀態，並在整夜的多次工作階段之間延續進度。每個讓 agent 自主運行的團隊都獨立發現了同樣的角色，因為只要 agent 的運行時間超過單次互動對話，相同的問題就會浮現。

這個角色至今沒有公認的名稱。有些團隊稱之為「AI ops」，有些歸入平台工程，還有些指派給從未寫過 hook 的工程主管。定義模糊是有代價的——錯判角色就會錯配工作。缺乏系統知識的工程主管無法除錯損壞的 agent 狀態；缺乏產品判斷力的平台工程師無法評估 agent 的產出是否符合規格的意圖。操作員角色需要兩者兼備：規格決策（agent 該建置什麼、施加什麼約束）與維運執行（監控工作階段、從失敗中復原、維護基礎建設）。

操作員的五項職責

1. 委派

委派意味著在執行開始前撰寫約束 agent 行為的規格。委派的品質比任何其他因素都更能決定自主產出的品質。

CLAUDE.md 檔案就是一份委派產物。它將專案慣例、禁止模式、必要行為和品質標準編碼成 agent 在工作階段開始時讀取的文件。¹ PRD 是一份委派產物，指定 agent 在報告完成前需驗證的驗收標準。任務描述也是一份委派產物——任務描述的精確程度界定了 agent 的決策空間。

糟糕的委派會導致捷徑螺旋：agent 跳過步驟，因為規格並未將這些步驟列為必要。好的委派會明確列出必要步驟。我的 PRD 包含編號的驗收標準，每項標準都對應一個可觀察的產物（一個檔案路徑、一個測試結果、一個特定行為）。agent 無法在不產出對應產物的情況下將某項標準標記為完成。指定可觀察結果的委派能消除整類幻影完成的問題。

關鍵技能在於知道什麼該明確規範、什麼該留有彈性。過度規範會產出僵化的 agent，遇到意料之外的程式碼時無法應變。規範不足則會讓 agent 做出你未授權的架構決策。這條界線隨信任而移動：經過充分測試、具備完善 hook 的 agent 可以獲得更大的自由度；首次執行整夜工作的新配置則需要更嚴格的約束。

2. 監督

監督意味著追蹤進行中的工作階段、審查差異，並在偏移累積之前加以攔截。

偏移是核心風險。agent 一開始與規格對齊，做了一個看似合理但略有偏差的微觀決策，接下來的決策便建立在這個偏差之上。到了第八次迭代，agent 解決的已經不是你委派的問題了。每個單獨的決策看起來都合理，但累積的軌跡偏離了目標。

我透過兩種機制捕捉偏移。第一，hooks 強制執行硬性邊界：封鎖指令、必要模式、禁止的檔案修改。Hook 能即時攔截違規行為，在 agent 繼續之前就介入。第二，定期的日誌審查能捕捉 hook 無法偵測的軟性偏移：agent 選擇了不必要的複雜方案、建置規格未要求的功能、或最佳化了非瓶頸的程式碼路徑。軟性偏移需要人為判斷，因為沒有任何自動化檢查能判斷 agent 的軌跡是否符合操作員的意圖。

監督難以隨 agent 數量擴展。一個 agent 每晚產出一個工作階段，早晨喝咖啡時就能審完。五個 agent 各跑八次迭代，就會產生四十個上下文視窗的工作量。排定優先順序勢在必行：先審查失敗的，再看觸及關鍵路徑的，最後才是低風險任務中順利完成的。

3. 介入

介入意味著知道何時該停止、重新引導或重啟正在執行任務的 agent。

四種模式需要介入：

Agent 陷入迴圈。同一錯誤在連續迭代中反覆出現，agent 嘗試大同小異的修復。每次迭代消耗完整的上下文視窗，卻毫無進展。介入方式：停止工作階段，手動診斷根本原因，將診斷結果更新至交接文件，然後重啟。

Agent 產出了通過測試但結果錯誤的輸出。程式碼能編譯、測試全綠，但行為不符合規格的意圖。證據閘門能攔截部分情況，但 agent 可能為錯誤行為產出看似合理的辯護。介入方式：撰寫一個捕捉正確行為的失敗測試，然後重啟。

Agent 即將觸及正式環境或外部系統。任何具有不可逆後果的操作（部署到正式環境、發送郵件、修改資料庫、呼叫付費 API）都需要設定閘門。我的 hook 會封鎖具破壞性的 bash 指令和外部網路呼叫。操作員決定開啟哪些閘門、何時開啟。²

Agent 正在前進，但方向錯誤。工作品質尚可，但與目標不一致。介入方式：停止，在交接文件中釐清規格，重啟。不要嘗試在同一對話中途修正方向。agent 已經基於錯誤的詮釋建立了心智模型，在同一上下文視窗中修正路線會產出前後不一致的結果。

不需要介入的模式：agent 正緩慢但穩定地朝正確目標前進。讓它繼續。

4. 復原

復原意味著處理已發生的失敗：損壞的狀態、錯誤的分支、壞掉的建置，以及資料遺失。

Agent 失敗會留下痕跡。一個崩潰的工作階段可能寫入了不完整的檔案、提交到錯誤的分支、在工作目錄留下暫存檔案，或修改了後續工作階段會繼承的設定。復原必須在重啟前逆轉這些痕跡。

我的復原流程：盤點損害（git status、git log、git diff）、保留工作階段日誌作為診斷資料、回復到最後一個驗證過的良好提交、以失敗原因更新交接文件，然後以修正後的約束重啟。除非部分工作明確正確且可獨立切割，否則不要嘗試從失敗的工作階段中搶救。交接文件會跨工作階段傳遞失敗脈絡，確保下一個 agent 不會重蹈覆轍。

最危險的復原情境是看起來像成功的失敗。agent 報告完成、測試通過、建置全綠，但實作存在隱微的錯誤。信心幻象失敗模式產出的正是這種情況。復原需要閱讀程式碼，而非僅看完成報告。

5. 治理

治理意味著制定適用於所有 agent 工作階段的政策、預算、權限和稽核要求。

政策定義 agent 可以和不可以做什麼。我的治理層包括：生成預算（每次整夜運行的最大迭代次數）、成本上限（每次工作階段的最大 API 花費）、允許的 bash 指令白名單、禁止的檔案模式黑名單，以及一組必要的完成標準。³ 每項政策都源自一次具體的失敗。生成預算的存在是因為早期有一次工作階段跑了 47 次迭代卻未收斂。成本上限的存在是因為一次除錯工作階段追逐假線索燒掉了 200 美元的 API 費用。每項政策都是用慘痛教訓換來的傷疤。

權限遵循最小權限原則。產生部落格內容的 agent 不需要內容目錄以外的檔案系統寫入權限。執行測試的 agent 不需要網路存取。我的 hook 在工具呼叫層級強制執行這些邊界，封鎖超出工作階段權限範圍的操作。²

稽核要求完善了治理層。每次工作階段都會產出結構化日誌：執行的指令、修改的檔案、執行的測試、評估的完成標準。七種失敗模式分類法正是從六個月的日誌審查中誕生，將每次需要人為介入的失敗加以歸類。

監督架構

五個基礎建設元件實現五項職責。

Hook 實現自動化監督。Claude Code 的生命週期事件（PreToolUse、PostToolUse、Notification）觸發 shell script，即時執行政策。² 一個封鎖 rm -rf 的 hook 就是編碼為 PreToolUse 檢查的治理政策。一個要求完成前執行測試的 hook 就是編碼為 PostToolUse 檢查的委派約束。我系統中的 95 個 hook 編碼了 95 個關於 agent 能做與不能做什麼的決策，每個都可追溯到它現在所防範的特定失敗。

證據閘門實現結構化驗證。六項標準（遵循模式、最簡方案、邊界情況處理、測試通過、無迴歸、解決問題）必須產出具體的產物，agent 才能將工作標記為完成。⁴ 閘門將監督從「agent 做得好嗎？」（主觀、無法驗證）轉化為「agent 是否為六項標準都提供了證據？」（客觀、可稽核）。完成報告中的每一個模稜兩可的用詞都會觸發重新驗證。

品質迴圈實現迭代精煉。七個步驟（實作、審查、評估、精煉、放大視角、重複、報告）強制 agent 多次審視自己的工作。⁵ 迴圈彌補了單次生成的結構性限制：模型產出的初稿看似合理，但包含只有重新閱讀才能發現的錯誤。品質迴圈強制進行這樣的重新閱讀。

工作階段日誌實現事後稽核。系統以結構化形式擷取每次工具呼叫、檔案修改和完成報告。六個月的工作階段日誌催生了失敗分類法。沒有這些日誌，每次失敗都只會是孤立的軼事。

成本閘門實現預算執行。生成預算限制迭代次數，API 成本上限限制 token 花費。在生成預算內未能收斂的 agent 很可能已經卡住，更多迭代於事無補。預算迫使操作員進行診斷和介入，而非寄望下一次迭代能解決問題。

何時介入、何時放手

介入決策是操作員最關鍵的判斷。過早介入浪費 agent 的工作成果，過晚介入則讓偏移持續累積。以下框架有助於決策。

元原則：根據資訊不對稱來介入，而非根據速度。當你知道 agent 不知道的事情（正確的程式碼路徑、真正的需求、前次工作階段的失敗模式），介入能傳遞這些知識。當 agent 掌握了你所知道的一切，只是在逐步解決問題時，讓它繼續工作。

操作員檢查清單

開始之前

• [ ] 規格已審查：驗收標準具體、可觀察且完整
• [ ] Hook 已啟用：政策 hook 已針對任務類型啟用並測試
• [ ] 預算已設定：生成限制和成本上限已配置
• [ ] 沙箱已確認：agent 無法觸及正式環境、發送外部請求或修改範圍外的檔案
• [ ] 交接文件已更新：若延續前次工作，交接文件已反映最新修正
• [ ] 分支乾淨：工作目錄位於正確分支，無未提交的變更

進行中

• [ ] 依設定間隔檢查日誌（整夜運行時每 2-3 次迭代檢查一次）
• [ ] 驗證軌跡符合規格意圖，而非僅符合規格字面
• [ ] 監控資源使用：token 花費、迭代次數、檔案系統變更
• [ ] 留意權限升級：任務不應需要的存取請求
• [ ] 記錄任何軟性偏移，供工作階段後審查

結束之後

• [ ] 審查所有檔案變更，而非僅看完成報告
• [ ] 獨立執行完整測試套件（不要信任 agent 回報的測試結果）
• [ ] 檢查 agent 未明確修改的鄰近程式碼是否有迴歸
• [ ] 驗證證據閘門：每項標準都有具體產物，而非籠統的保證
• [ ] 以工作階段成果和修正更新交接文件
• [ ] 記錄工作階段：遭遇的失敗模式、觸發的 hook、介入決策
• [ ] 更新治理：若出現新的失敗模式，撰寫 hook 或政策加以防範

操作員即工匠

Agent 操作員角色存在於工程技能與產品判斷力的交匯處。撰寫 hook 需要系統知識，撰寫規格需要產品理解力，審查 agent 產出則兩者缺一不可——既要能評估程式碼是否正確，也要能判斷正確的程式碼是否解決了正確的問題。

對話是錯誤的介面——這句話適用於角色中的維運面向。滾動對話記錄來監督自主工作，超過單一 agent 的單次工作階段就無法擴展。上述監督架構（hook、證據閘門、品質迴圈、工作階段日誌、成本閘門）將監督編碼為基礎建設，彌補了介面的缺口。基礎建設不是取代操作員，而是擴大操作員的觸及範圍。

品味是一套技術系統描述了判斷力的面向。知道該委派什麼、該驗證什麼、該拒絕什麼，需要從經驗中累積的模式辨識。每次工作階段都能教會操作員一些 agent 行為的知識。操作員的技能透過刻意練習、反思，以及將教訓永久編碼的基礎建設而持續複利成長。

暗工廠代表理論上的終點——第五級，無人閱讀程式碼。目前大多數團隊的實踐落在第三或第四級：agent 執行工作，操作員監督並介入。第四級與第五級之間的差距是驗證層。第二級與第四級之間的差距就是操作員。

每個運行自主 agent 的團隊終將發展出操作員。問題在於他們是有意識地發展這個角色（定義明確的職責、基礎建設支援與正式培訓），還是被動地——將工作分配給整夜工作階段失敗時恰好還醒著的人。工藝從此開始發展。