Day 24｜失敗恢復：沒人看著的任務壞掉之後

Day 23 停在一句話：沒人看著的時候，它壞掉了，接下來該由誰、照什麼規則把它扶起來。直覺的答案是重跑。外包出去的執行失敗了，自動再派一次；再不行，就改回本機自己做，總有一條路能把任務做完。我的規則剛好相反：外包執行一失敗，我不重跑、不換寫法、不改回本機，而是把整個 session 的派工權鎖死，本輪剩下的外包單元全部暫停，等我親手解鎖。在一個要讓它沒人看著也能跑的系統裡，這是一個刻意讓自己停擺的設計。這篇講我為什麼這樣選。

事故：失敗不多，但每一種都撞同一面牆

先看失敗有多少。這裡只算送進隔離環境的外包執行，跟 Day 23 的全期總數口徑不同：從 2026-09-16 22:24 到 2026-10-04 10:44 共 757 次，成功 743 次，失敗 14 次；同名任務已在跑而直接返回的不算失敗。另有 1 筆是等帳號鎖等到逾時，只出現在失敗紀錄裡，沒有退出碼，合計 15 個失敗事件。失敗全部發生在兩台執行機中的同一台。

失敗率不到百分之二，看起來不需要什麼恢復機制。但把 15 個事件逐筆攤開，畫面就不一樣了。

逾時 3 筆，全是我刻意把逾時設成 5 秒、20 秒的測試探針，正式單元的逾時是 0 筆。另有 2 筆發生在失敗即鎖定上線之前：一筆在 2026-09-16，一筆在 09-17，鎖定機制當天稍晚才上線；這兩筆後來怎麼收斂，紀錄取不到。

剩下 10 筆是鎖定機制上線後正式單元的失敗：執行環境版本不符、模型端安全機制拒答、額度用盡、等帳號鎖逾時。額度用盡那次是同一批 5 個單元一起倒下。

除了拒答，這幾種失敗有一個共通點：問題不在任務本身，在執行它的那個帳號或環境。版本不符，重跑一百次還是不符；額度用盡，重跑只是把下一個單元也送進同一面牆。自動重試在這裡不是恢復，是把一個失敗複製成一串失敗。

那改回本機呢？任務確實做得完。可是外包之所以送進隔離環境，是因為我不想讓它在宿主上跑。失敗之後默默搬回宿主，等於邊界在沒人看著的時候自己退了一步，而且事後從結果看不出來它退過。

所以我把問題換了一個問法。無人值守的可用性，不是看失敗率有多低，而是看失敗之後有沒有一條不需要人的收斂路徑。這條路不一定要通往「修好」，也可以通往「停在一個不會繼續變壞的狀態」。我選的是後者：停下來，鎖住。

證據：鎖了四次，四次都是我解的

左邊是 15 個失敗事件依類別拆開：重試類只有 3 筆逾時探針（斜線那列是另一口徑，不計入），降級 0，鎖定涵蓋 8 筆失敗，另有 2 筆標記不重派、2 筆在機制上線前。右邊是 4 次落鎖到人工解鎖的間隔，4 次全由人工解鎖。時間窗 2026-09-16 到 10-04。

這張圖直接回答開頭的矛盾。鎖定是實際被走過的路：落鎖 4 次，涵蓋 8 筆失敗，人工解鎖 4 次。降級那一列是 0：15 個事件的後續不是外包重派，就是沒有重派，沒有一筆改回本機。這不是運氣，是規則禁止的路徑。

四次鎖從失敗到解鎖，分別隔了 6 分、3 分、2 小時 16 分、12 小時 57 分。這裡有一個口徑限制要先講：失敗與解鎖是按時間順序配對，只有 1 次能以 session 對上，其餘 3 次是推定。鎖住期間被擋下的派工紀錄是 0 筆；我的讀法是，鎖住之後多半沒有新的派工嘗試，代價主要是等待時間，但紀錄 0 筆不等於沒有嘗試，這是推定。

2026-09-27 那筆安全機制拒答值得單獨講。它當時照一般失敗落鎖，按時間配對是 3 分後解鎖，之後另開單元重派成功。之後我把拒答改成豁免落鎖，所以 10-03 的 2 筆拒答只標錯誤、不鎖，也不重派。同一類失敗，前後走了兩條路；我把前一筆歸在鎖定，因為它當時就是被鎖住的。

另一個口徑的數字只當背景：全派工的稽核紀錄裡，「重試後通過」有 55 列，但它包含本機子 agent、由回報內容判定，跟這 15 個外包失敗事件不是同一把尺。

進場成功 599 次，進場被擋下的筆數取不到，只有成功才留紀錄。檢查通過 556、跳過 4、失敗 0；套用時驗證不過 7、套用失敗 0；成功套用並自動清理 347 次。各段時間窗不同，不能串成漏斗。

失敗不只發生在執行那一刻。執行者寫出來的改動，要經過暫存、檢查、套用三段，才碰得到原始目錄。驗證不過的 7 筆裡 1 筆是探針、6 筆是真實個案，全是新增了不在允許範圍的檔，或缺少改動清單；它們都停在原始目錄外面，暫存原封保留。

解法：讓失敗收斂到一個不會變壞的狀態

規則本身寫得很短。外包回非 0，就視為帳號或環境有問題：不改回本機、不換寫法，本輪剩下的外包單元暫停。鎖落兩份，任一份還在，這個 session 的所有派工都會被擋下；只剩一份照樣擋，並加註不一致。解鎖只能由我親手執行，攔截層對鎖的寫入一律擋下，機器沒辦法自己解開自己。

不是每種失敗都要鎖。逾時、子 agent 被砍、安全機制拒答，這三種豁免落鎖：前兩種是看門狗的正常動作，重跑有意義（本期正式單元兩種都是 0 筆）；拒答重派政策還沒定，所以只標記、不重派。回報不合格可以重派一次，就一次。

改動回收也是同一個想法。五項驗證全在碰原始目錄之前做完，任何一段不過就整批不動；只有最終成功才清理暫存，失敗一律保留現場。驗證不過的改動碰不到原始目錄，暫存也不會被清掉；我回來時看到的，就是它停下那一刻的樣子。

把這些放在一起，失敗之後的每一條路都有終點：重試一次、標記等人、或者鎖住。沒有一條路會在沒人看著的時候越走越遠。可用性在這裡的意思不是任務一定做完，而是系統一定停在一個我回來時看得懂、拿得回來的狀態。

新問題：鎖得住機器，鎖不住判斷

鎖解決的是「壞掉之後不要繼續壞」。它管得住派工權，管得住改動不碰原始目錄，也管得住機器不替自己解鎖。

可是成功套用的那 347 次呢？改動通過了檢查，進了工作目錄，暫存也清掉了。檢查能回答的是「這批改動合不合規矩」：路徑對不對、有沒有多出不該有的檔。它回答不了另一個問題：這批改動到底要不要進版控。

進版控之後，它就不再是一個可以整批丟掉的暫存，而是一筆紀錄；推出去之後，就有人看得見。這一步要不要做、在沒人看著的時候能不能做、做到哪裡為止，不是鎖能決定的。鎖得住機器，鎖不住那個判斷。

明日預告：Day 25｜護欄：允許自動化到哪裡為止