讓 AI agent 自動跑之前，先寫好它什麼時候該停
每天凌晨三點，agent 自動檢查 main branch 失敗的測試，嘗試修復，然後開一個 draft PR。
這個 workflow 聽起來很合理。它沒有直接部署、沒有繞過 review，也不是叫模型「改善整個專案」。只是把一件重複又惱人的維護工作交給背景程序。
直到它連續三天開出沒有人敢 merge 的 PR。
第一天你覺得至少它有努力。第二天你開始懷疑它是不是在同一個錯誤附近打轉。第三天，團隊多了一個新的例行工作：每天早上看 agent 昨晚又留下什麼東西。
這就是 scheduled agent 最容易被低估的地方。當 agent 還在聊天窗裡，人至少知道自己正在委派任務。當它進入排程、issue trigger 或 repo event，它就變成一個會消耗資源、使用工具、修改 repo、製造 review queue 的背景工作者。
這時第一個規格不是 prompt，而是停止條件。
## 自動啟動以前，先縮小觸發條件
GitHub Copilot cloud agent automations 已經把這個方向講得很清楚：agent 可以依 schedule 或 repository events 執行，像是 issue triage、夜間測試修復、release notes PR。這不是科幻功能。它只是開發工具很自然會走到的下一步。
問題不在於這些工作該不該自動化。很多都該。問題是「每天跑一次」通常太粗。
一個比較好的觸發條件，應該同時回答幾件事：
- 什麼狀態下才啟動？
- 這次只處理哪一類任務？
- 它最多能碰哪些檔案或 issue？
- 產出不符合什麼條件時，必須放棄？
例如「每天凌晨修測試」聽起來明確，其實範圍很大。是修單一 flaky test、修型別錯誤、還是允許改產品邏輯？是只能碰測試檔，還是能改 production code？如果 CI 本來就有多個失敗點，它要挑哪一個？
小團隊導入 agent automation 時，最好從低風險、可驗證、結果格式穩定的任務開始。Issue 標籤、release notes 草稿、固定格式的相依套件更新、單一測試失敗的修復嘗試，都比「整理 backlog」或「改善 code quality」適合放進排程。
原因不是 agent 做不了比較大的事。真正麻煩的是背景執行的失敗成本比較陰：人沒有看著它走歪，只會在隔天收到一包需要解釋的結果。
## 工具權限要跟任務綁在一起
Scheduled agent 的工具清單本身就是產品邊界。
能開 PR，不代表能改 issue。能讀 repo，不代表能碰 release 設定。能修改 code，不代表能更新 production secret 或部署設定。這些聽起來像權限管理，但對小團隊來說，更實際的說法是：每個 automation 都應該像一個很窄的背景 job。
如果任務是產生 release notes，它可能需要讀 merged PR、讀 commit message、開一個草稿 PR 或 issue comment。它不需要改測試，不需要調整 package lock，不需要重新整理整個 docs 目錄。
如果任務是處理 failing test，它也不一定需要碰所有地方。第一版可以只允許它針對單一失敗測試建立修復 PR；一旦 diff 超過某個範圍，就停下來留下 note，而不是繼續猜。
這裡最危險的地方，是工具和任務沒有綁定。Prompt 裡寫「請小心」不夠。真正有用的是讓它根本不能把一個 release-notes job 變成 refactor job。
## 停止條件不是 timeout 而已
很多人談 background agent，第一個想到的是 timeout。跑太久就停，這當然需要，但它只是最粗的一條線。
實務上，agent 應該在更多情況下停下來：
- 同一類錯誤重試超過次數。
- 測試結果沒有變好，或新的失敗變多。
- diff 超出指定目錄或檔案類型。
- 它找不到能證明任務完成的證據。
- 產出的 PR 太大，reviewer 無法合理檢查。
- 當天 review queue 已經滿。
- 它需要的外部資訊不可讀，或來源互相矛盾。
這些停止點看起來瑣碎，但它們決定 agent 是幫手還是新的值班負擔。
我最不信任的 scheduled workflow，是那種失敗後只會「再試一次」的設計。Agent 最會消耗資源的時刻，常常不是它第一次做錯，而是它在錯誤方向上持續探索。沒有停止條件，token、credit 和人的注意力會一起被燒掉。
GitHub 最近一連串 Copilot 相關更新，從 usage metrics、budget controls、managed settings 到 telemetry 和 session limits，其實透露了同一件事：agent 能不能跑，已經不是唯一問題。團隊還要知道它跑了多少、花了多少、在哪裡卡住，以及什麼時候該被限速。
費用上限也要被當成產品規格，而不是月結帳單上的細節。
## 產物要能被 review，不只是能被產生
一個好的 agent PR，不該只丟出 diff。
它至少要說清楚幾件事：它為什麼啟動、嘗試了什麼、改了什麼、跑過哪些檢查、哪些檢查失敗、哪些假設需要人確認。若它停下來，也要留下下一步建議：繼續、縮小任務，還是交給人。
這不是在追求漂亮報告。它是在保護 reviewer。
開發者社群對 autonomous agent 的焦慮，很多時候不是反 AI。大家真正反感的，是沒有邊界的委派。任務越模糊，產物越大，reviewer 越容易陷入一種尷尬狀態：好像省下了 coding time，卻多了一堆不知道該不該相信的輸出。
Review debt 比 technical debt 更煩的一點，是它會偽裝成「已經有人做了」。PR 開在那裡，issue 被留言了，測試也跑過一部分。可是沒有人知道它是不是真的接近完成。
所以 scheduled agent 的 artifact gate 要比平常更明確。它可以開 draft PR，但必須附上檢查證據。它可以改 issue 狀態，但要留下原因。它可以建議 release notes，但不能把不確定的變更寫成已確認事實。
背景執行沒有免掉 review，只是把人介入的時間點往後移。既然往後移，交接格式就更重要。
## 小團隊先寫一頁 runbook 就夠了
這件事不需要一開始就變成企業治理專案。
如果你只是想把第一個 agent automation 放進 repo，先寫一頁 runbook 就好。內容可以很樸素：
- 何時啟動？
- 哪些 trigger 不啟動？
- 它能讀什麼、改什麼、不能碰什麼？
- 最多跑多久、最多重試幾次、最多花多少額度？
- 什麼情況下必須停下來？
- 它可以開 PR、留言，還是只能留下草稿？
- 誰負責看結果？
- 失敗後要留下什麼 note？
這些問題不會讓 agent 變聰明，卻會讓團隊比較容易拒絕它。
這很重要。好的自動化不可能每次都成功，但失敗時應該可以被看見、被拒絕、被接手。Scheduled agent 尤其如此，因為它最有價值的地方，也是它最危險的地方：它會在沒有人盯著的時候工作。
OpenAI 對 agent work 的分析提到，使用者正在把更長時間、更平行的任務交給 Codex。這個方向大概不會退回去。工具會繼續補上 automation controls、metrics、budget、telemetry，因為只要 agent 開始背景化，團隊就需要營運它，而不是只使用它。
我對 scheduled agent 的態度不是悲觀。相反地，我覺得它會變成小團隊很實用的一層自動化。只是它不該被想像成一個比較聰明的 autocomplete。
它比較像一個背景工作者。會消耗資源，會留下產物，會做錯判斷，也需要交接。
讓 agent 自動跑之前，先寫好它什麼時候該停。這不是保守，是讓自動化真的能進入日常工作的最低條件。
## Source notes
- [Schedule and automate tasks with Copilot cloud agent](github.blog/changelo...)
- [GitHub Copilot changelog](github.blog/changelo...)
- [How agents are transforming work](openai.com/index/how...)
- [Are agents actually useful for complex tasks?](www.reddit.com/r/Cla...)