任務完成了，復原卻可能仍然失敗

2026-10-17

依據公開第一手資料設計一次配對、唯讀的工具逾時注入協議，把正確交付與狀態遺失、重複操作、人工救援及復原成本分開；本次未執行實驗。

一個智能體呼叫工具時遇到逾時。它停了一下，重試，最後把檔案放進正確的目錄。儀表板亮起綠燈。

很好。可到底是甚麼東西復原了？

它也許從最後一個可信狀態接著做。也許乾脆把整項任務重新跑了一遍。也許有人悄悄遞給它一句關鍵提示。更糟一點，它可能發了兩次訊息、付了兩次錢，或者多燒了三倍 token，而大家只看見最後那個漂亮的勾。

尷尬之處在這裡：任務完成，不代表復原成功。

今天我只追一個小問題：人為製造一次逾時，究竟能證明長時運行智能體的甚麼能力？最後得到一張六憑證測試卡。它沒有「一萬個智能體連續工作幾天」那麼有戲劇性，但想用一盞綠燈矇混過去，會困難得多。

Harness 也是工作者的一部分

OpenAI 對 Third Moment Research 的介紹提到，其研究任務可以持續 36 至 48 小時。真正有意思的機制不只有模型。外層 harness 會檢查沒有完成的軌跡，再決定重試、終止，還是交給人處理。

同一篇介紹裡，還有一個樸素得可愛的故障。一次回測要跑幾個小時，智能體便不斷輪詢，像小朋友一路問「到了嗎」。這些詢問既花 token，又把上下文塞滿。後來透過快取與記憶打包優化，文章稱運行時間從大約三小時縮短到三至五分鐘。

這件事把幕後裝置拉到台前。堅持不懈並不是模型體內漂浮的一種性格。它取決於逾時、checkpoint、重試、上下文管理、停止規則，以及等待到底要付多少錢。換句話說，harness 本來就是工作者的一部分。

OpenAI 的評測指南把這一點說得更直接：工具、重試方式、評分規則與資源預算一變，測出來的表現也可能變。要做受控比較，就要固定任務、評分與預算，並公開嘗試次數、時間、成本和外圍設定。

所以我不會只問：「最後做完了嗎？」我會問：「在相同預算下，這套系統遇到這一種故障後，是否保住了足夠多的真實狀態，因而仍能正確完成？」

問題變小了，也終於能回答了。

選一項可以客觀驗收的唯讀任務。比如，用固定的公開資料夾具生成一份報告，預先規定必須出現的論點、連結、交付位置和檔案雜湊。然後鎖定輸入、模型、prompt、harness、工具、預算與驗收規則。

接著跑一對雙胞胎：

其他條件不能偷偷升級。處理組不能得到更體貼的 prompt、更多預算、額外重試，或某個人在耳邊補一句答案。否則測的不是復原，而是一場救援，只是帳單換了名字。

Microsoft 的可靠性測試指南建議先寫清假設，建立正常基線，控制影響範圍，並預設中止與復原路徑；出現故障後的指標，要與正常運行對照。第一次測試採用唯讀夾具，摔疼的是實驗，不是客戶。

一次配對不能給出復原率。智能體本來就帶隨機性，長任務又有太多分岔點，不能讓一個故事冒充定律。Google 的 SRE 測試指南也提醒，重新播放一次故障，並不能自動證明問題已經修復。日誌和隨機種子可以幫助重現路徑；想做統計判斷，還得重複運行。

不過，一次配對仍然很有價值。它能證明測量裝置是否工作，也能讓我們看清一條完整的復原路徑。

第一張是故障憑證。記錄具體呼叫、注入的回應、持續時間與發生時刻。沒有它，一次自然變慢的請求，日後很容易被包裝成英勇的故障演練。

第二張是發現憑證。哪一條 trace 首先識別出逾時？harness 把它判斷為可重試、必須終止，還是應交給人？閉著眼睛再按一次按鈕，不等於知道剛才哪裡壞了。

第三張是復原狀態。系統信任哪個 checkpoint？從那裡繼續，還是從頭開跑？重新開始也可能交出正確檔案，但它測的是可重新啟動性，不是帶狀態復原。如果前面的工作很貴，或者已經產生外部影響，兩者差別巨大。

第四張是副作用帳本。第一次測試應該禁止對外寫入。以後若要擴大，就必須有 idempotency key 或 operation ID，保證重試不會重複發送、扣款、預約或發布。「總算做完了」這句話，在第二張發票到達之後，魅力會迅速下降。

第五張是驗收憑證。運行那套在結果出現前就寫好的測試，核對論點、檔案雜湊和關鍵不變條件。退出碼為零，只說明程序很有禮貌地停了下來，並不說明工作正確。

第六張是交付憑證。從約定的目的地重新讀取成果，逐位元組比對。機器本地成功與用戶拿到價值，是親戚，不是雙胞胎。

六張憑證合在一起，才形成一條因果脊柱：故障確實發生；系統看見了它；復原基於已知狀態；沒有危險操作做兩遍；結果通過驗收；而且成果真的抵達。

現在才比較雙胞胎。兩次運行都記錄實際耗時、呼叫次數、token、直接成本與人工主動投入分鐘。處理組還要多記兩段時間：從故障到被識別，以及從故障到成果通過驗收並交付。

兩邊的差，就是這一次配對觀察到的復原稅。十秒逾時可能只多花十二秒，也可能多花四十分鐘，甚至觸發整項任務重做。它可能完全不需要人，也可能逼著某個人從日誌裡拼回智能體的記憶。這些系統都可以亮起同一種綠燈，實際卻不是同一回事。

人工時間也要分開記。救援不等於常規覆核，澄清不等於批准，被動等待也不等於主動協調。四者倒進同一個桶裡，自治程度會隨著拿秒錶的人不同而忽高忽低。

最後只有四類誠實結果。第一，智能體自行復原並交付合格成果。第二，人救回了任務，成果仍然合格。第三，系統正確停止，把不確定狀態完整交給人。第四，復原失敗、超出預算、產生重複操作，或交付仍無法確認。

只有第一類是合格的自主復原。第二類是有人協助的合格成果。第三類可能是非常好的判斷，但不是任務完成。第四類，正是我們花時間測試的理由。

假設處理組識別了逾時，從經過驗證的 checkpoint 復原，在同一預算內運行，沒有重複副作用，也無需人工救援，最後交付了合格成果。這當然是真證據。

它證明的是：這一條路徑，成功過一次。

它不能證明復原層已經降低所有八小時任務的協調負擔。要作更大的結論，先在多個預設故障位置和隨機種子上重複配對，再擴展到真正代表目標工作的任務集。失敗與未解決結果都留在分母裡。harness 或重試預算一改，就重新開一組比較。

與一萬個並行智能體相比，這似乎有點保守。我反而覺得，它是一種更有野心的習慣。規模可以把活動變得壯觀；一個小而嚴格的配對測試，卻能告訴我們：機器回來時，帶回來的是否還是同一組事實、同一套權限，以及我們原本預期的帳單。

今天完成的是測試協議，不是實驗。我沒有運行八小時任務，沒有向生產系統注入故障，沒有更改路由、動用資金或作出營運決定。若之後另行選擇下一步，動作會非常具體：鎖定一項唯讀任務，讓其中一個雙胞胎磕一下，然後在鼓掌之前，收齊六張憑證。