小型監控任務最適合先交給 Agent
看到 Simon Willison 讓 ChatGPT 等 Python 3.15 進入 actions/python-versions 的做法，我覺得很適合拿來當 Agent 任務的範本。事情小到有點無聊，反而容易驗證。
任務邊界可以先寫成這樣：clone repository，每小時執行一次 git pull，檢查 stable 3.15 是否出現，符合條件才通知我，通知後停止。這裡面沒有要 Agent 自己改 production、沒有要它猜測版本何時發布，也沒有「持續幫我注意」這種無限期授權。
我會把驗證條件寫死，不讓模型靠語意判斷。指令可以長這樣：
git clone https://github.com/actions/python-versions.git
cd python-versions
git pull --ff-only
test -d versions/3.15.0 || exit 0
grep -q "3.15" versions-manifest.json || exit 0
實際路徑和檔名要依 repository 當下結構調整，但原則一樣，使用 exit code、固定檔案和固定字串。Agent 每次只做 read only 檢查，結果可以被人重跑，這比「幫我看看有沒有更新」可靠很多。
Polling 也要有界線。每小時一次，代表一天最多 24 次，幾天的成本和雜訊都可預估。若改成每分鐘輪詢，一週就是 10080 次，對一個不急的 runtime release 沒有價值，還可能撞 API rate limit。遇到 network error 時不要立刻狂 retry，最多退避 3 次，下一個小時再試。
通知邊界同樣重要。我只需要收到一次「stable 3.15 已可用，commit 是 abc123，檢查時間是 2026 年 10 月 12 日 14:00」的通知，不需要每次 pull 都收到心跳。若狀態沒有改變就保持安靜，若連續 6 次檢查失敗才另外告警，並把錯誤、最後成功的 commit 和下一次重試時間帶上。
停止條件要在一開始就存在，而且要可判斷。成功條件是 stable 3.15 出現，失敗條件是 repository 不存在或權限失效，逾時條件則可設 14 天。三者任一成立，Agent 結束工作。沒有停止條件的監控任務，實務上很容易變成背景程序，最後沒人知道它還活著，也沒人知道誰該付 token 和 CI 成本。
說穿了就是，適合交給 Agent 的維運工作，通常具備四個特徵：狀態能讀取，條件能寫成指令，檢查頻率不高，完成後能明確收工。Python 3.15 進 matrix 只是結果，真正值得複製的是這個任務設計。先挑一個三天內能驗證、只讀、只通知一次的小任務跑，成功後再把權限和責任往外擴。
作者：CtrlC