Day 22 停在一句話：被跳過的動作看得見了，可是誰來叫醒它重試。今天先回頭看一個我早就做好的東西。我有一個單輪即滅入口：起一個全新進程，跑一輪，結束，什麼都不留。從外面看，它很像一種節流手段——不讓 context 長大，用完就丟。Day 16 也確實先把它放在成本這一側講過。Day 10 講過，它的動機不是成本，是排程。那篇只說了結論，這篇要把「排程」兩個字拆開：為什麼叫醒一個 agent 這件事，不能交給 agent 自己。
Claude Code 有一個內建循環。agent 跑完一輪，可以自己決定多久之後再醒來，到點了同一個 session 繼續下一輪。聽起來正好：讓它自己排程，自己重試，我什麼都不用管。
問題出在那個「多久之後」。內建循環的喚醒間隔被夾在 60 秒到 3600 秒之間。最短一分鐘，最長一小時，超出去就被夾回邊界。agent 再怎麼判斷「這件事半天後再看就好」，它能設的最長鬧鐘就是一小時。想讓它睡更久，唯一的辦法是讓它每小時醒一次，確認還沒到時間，再睡回去。每醒一次都是完整的一輪。
這只是表面。更根本的問題是鬧鐘放在哪裡。內建循環的下一次喚醒，是由這個 session 自己排的；session 還活著，它才會醒。換句話說，負責叫醒它的東西，跟需要被叫醒的東西，是同一個。只要這個 session 因為任何理由停了——卡住、被關掉、跑到一半掛掉——下一次喚醒也跟著消失，不會有人發現它沒醒。
我把這個狀況叫做「鬧鐘被鎖在房間裡」。房間裡的人睡死了，鬧鐘響了也沒用；房間塌了，鬧鐘也一起埋掉。Day 22 討論的是沒有人可以問的時候怎麼辦，這裡的處境更糟：連「該醒了」這件事都沒有人知道。
所以我的論點很簡單：agent 的排程不能交給 agent 自己。不是它判斷得不夠好，是它能動用的間隔被夾在一個固定區間裡，而且它的鬧鐘跟它同生共死。要把觸發權拿到外面，就需要一個入口，讓外面的東西每次都能從零叫起一個 agent，跑完就放手。單輪即滅入口就是為這件事做的：間隔由呼叫端決定，入口本身不排程。
先看三種觸發來源各自被什麼約束。
左邊三種來源：互動沒有機制上的上下限，但人要在；內建循環被夾在 60–3600 秒，而且 session 活著才會醒；外部排程的間隔由呼叫端決定。中間是單輪即滅入口，結束時把退出碼、耗時與取鎖等待寫進事件紀錄；有兩種情況在寫紀錄之前就返回。
接著是實際用量。我從事件紀錄把單輪即滅的每一筆重跑一遍。先對帳：用 Day 16 同一個時間窗（截至 09-27 08:08）重跑，仍是 348 筆，退出碼分布、耗時中位數、取鎖等待中位數逐項一致。全期從 2026-09-16 到 10-04 共 806 筆，非 0 退出 17 筆，占 2.11%；其中由排程觸發的 34 筆，其餘 772 筆是人手觸發，包括從互動 session 派出去的、我在終端機直接執行的。
這裡有一個不利的事實要先講：本機會啟動 agent 的外部排程是 0 筆。實際在跑的排程掛在另一台機器上，這一輪我不連過去，設定本身取不到，只能從事件紀錄反推它確實有在觸發。
時間窗 2026-09-27 到 10-04，共 458 筆。左邊是退出碼，中間是實際耗時，右邊是取鎖等待。排程組只有 14 筆，只作描述。
Day 16 畫的是逐日的次數與耗時，這張換一個切法：Day 16 時間窗之後，依觸發來源拆開。這一段 458 筆，非 0 占 1.75%。排程觸發的 14 筆全部以 0 結束；人手觸發的 444 筆裡有 8 筆退出碼是 1，占 1.80%。同窗逾時 0 筆、被砍 0 筆。
兩組的形狀差很多。排程組的實際耗時中位數 1,270.1 秒，人手組 268.5 秒；排程組的取鎖等待全是 0，因為它全部在宿主端直接執行、不進隔離環境，不必排隊取鎖，人手組的取鎖等待中位數是 662.0 毫秒。我的讀法是：排程叫起來的那一輪通常跑得比較久，人手叫起來的多半是零碎的派工；這是判讀，不是統計結論。
最後一個口徑限制，也是這張圖最該被看見的地方。退出碼有兩種在結構上記不到：同名鎖被占用，以及參數錯誤。這兩種情況在寫紀錄之前就返回了，所以紀錄裡它們是 0，意思是「沒有紀錄」，不是「沒有發生」。
把排程拿出 agent 之後，分工變成三層。
第一層是外部排程，只管「什麼時候」。它不懂任務內容，不判斷上一輪成敗，到點就起一個新進程。它的間隔沒有 3600 秒的天花板，也不依賴任何 session 活著。
第二層是單輪即滅入口，管「怎麼跑一輪」。每次都是全新進程，固定帶無人值守模式——Day 22 講過，沒有人可以問的時候，詢問會被改判成拒絕，不會停在那裡等。它有自己的看門狗：跑太久會被逾時中止，以專用退出碼結束；同一個名字的任務還在跑，下一次觸發會直接撞鎖返回，不會疊兩份。全期逾時 3 筆，被砍 0 筆。
第三層是紀錄。只要走到結尾，入口就把退出碼、實際耗時、取鎖等待寫進事件紀錄。agent 不必記得自己跑過幾次，紀錄記得。
這三層各自只認一件事，彼此不需要知道對方的狀態。外部排程不用知道上一輪跑了多久，入口不用知道下一次什麼時候來，紀錄不用知道是誰叫醒的。任何一層停了，另外兩層照樣成立：排程那台機器停了，入口還在，人手照樣叫得起來；某一輪卡死，看門狗會把它結束，下一次觸發照常進來。這是我刻意要的形狀，不是剛好長成這樣。
這樣排，agent 只剩一件事：把眼前這一輪做好。什麼時候醒、醒了之後跑多久、跑完留下什麼，都不由它決定。鬧鐘從房間裡搬到了門外。
排程叫得醒它了，但叫醒只是第一步。
回頭看那張圖：人手觸發那 8 筆退出碼 1，是真的失敗；它們有紀錄，我看得到。可是外部排程不讀紀錄，它只看時鐘。上一輪失敗了，下一次照樣到點觸發，沒有人判斷要不要先修、要不要重試、重試幾次才停。
更麻煩的是那兩種記不到的退出碼。撞鎖返回的那一次，從紀錄看起來就像那個時刻什麼都沒發生。排程以為自己叫過了，入口以為自己沒被叫，中間那一下，誰都沒記。
觸發權拿到外面，解決的是「誰來叫醒它」。沒解決的是：沒人看著的時候，它壞掉了，接下來該由誰、照什麼規則把它扶起來。
明日預告：Day 24｜失敗恢復：沒人看著的任務壞掉之後
iThome鐵人賽
看影片追技術