生成內容不等於完成任務。Rulestack 公開的一份無人值守代理失敗台帳顯示，72 筆失敗中有 46 筆發生在 git push，另有 24 筆停在外部資料擷取，真正失敗於任務本體的只有 2 筆。換算後，推送階段占已記錄失敗約 64%。這不是「AI 已經可靠」的證明，卻揭露更實際的問題：當代理開始長時間自行運作，可靠度往往取決於模型周邊的交付管線。
事件背景：十三套工作流程共用一個寫入終點
依原始文章自述，這套系統有 13 個以 GitHub Actions 排程執行的工作流程，共承載 18 個 cron 項目，負責呼叫外部平台、產生或發布內容，再把結果提交回 main 分支。失敗台帳會記錄工作名稱、階段、結束碼與時間。原始資料與事故敘述見：https://dev.to/rulestack/we-measured-where-unattended-claude-code-jobs-fail-46-of-72-were-the-git-push-2k51。
這些數字是營運者自行公布的單一案例，並非獨立稽核或跨企業研究；但其事故時間線足以說明一種常見風險：多個執行者可以各自正確，整體狀態仍可能錯誤。
真正的機制：遠端狀態沒有看見已完成的副作用
最具代表性的事故是文章被重複發布。系統把已發布文章的 ID 寫入 Git 追蹤的台帳，作為避免重複執行的冪等鍵。07:46 UTC，本機程序已建立文章並更新台帳，但尚未推送；08:43，排程執行器從遠端取得舊台帳，因此判定文章不存在並再次建立；直到 09:25，本機變更才抵達遠端。長達 99 分鐘，外部平台已發生副作用，排程所依賴的「真實來源」卻仍說它沒有發生。
這裡的合理推論不是 Git 特別不可靠，而是「副作用」與「完成紀錄」缺乏原子性：發布成功和冪等鍵落地是兩次獨立寫入，中間任何中斷、延遲或競爭都會留下不一致窗口。作者最後禁止在 CI 之外執行發布，實質上是把多寫入者收斂成單一寫入者。
GitHub 官方文件也證實底層衝突機制：若遠端分支已有其他提交，可能為避免覆蓋歷史而拒絕非快轉推送，必須先取得並整合遠端變更：https://docs.github.com/en/get-started/using-git/dealing-with-non-fast-forward-errors。
為何現在值得注意
傳統 CI 通常只讀程式碼、執行測試；代理式工作流程則會發布文章、更新佇列、呼叫外部 API，再把新狀態寫回儲存庫。任務跨越的狀態系統越多，「模型完成工作」與「成果可被下一輪正確看見」之間的距離就越長。本文觀點是：無人值守代理的成功率，應以外部副作用經重新讀取確認、狀態持久化且可供後續任務使用為終點，而不是以模型輸出或 API 回傳成功為終點。
實際影響不只是一個紅燈
推送失敗可能讓已完成成果留在隨時會被丟棄的 runner；台帳延遲可能造成重複發布、重複付款或重複通知；單一項目的讀取錯誤若直接中止迴圈，還會把局部異常放大成整批資料空白。原文另記錄一個「全綠但結果錯誤」案例：貼文佇列把同一時間欄位分別解讀為最早可發布時間與固定時段，造成隊首一度落後標示時間 75.7 小時。這提醒我們，沒有錯誤訊息並不等於語意正確。
容易忽略的限制
首先，46／72 的分母是「失敗紀錄」，不是所有執行次數，因此不能解讀成 64% 的代理任務會在推送時失敗。其次，其中 60 筆來自同一個高頻輪詢工作，樣本高度集中；它更能證明執行頻率與寫入競爭的重要性，卻不能直接外推到其他團隊。再者，「push 階段」只是分類，原文沒有逐筆公開 46 次失敗的完整錯誤碼，不能據此斷言每次都是分支衝突，更不能自行補上認證失效等未證實成因。
併發群組也不是無限排隊的魔法。GitHub 官方文件指出，同一群組可限制為同時只有一個執行中項目；但預設僅保留一個等待項目，若要讓多個任務排隊，須使用相應的 queue 設定，且仍有容量限制：https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency。因此，序列化之外仍須監控等待時間、取消數與佇列上限。
對台灣團隊的意義
無論是電商上架、社群排程、資料報表或軟體發布，只要代理會改動外部世界，就應把它當成分散式系統，而不是更聰明的 shell script。最基本的設計包括：限制單一權威寫入者；以可重試、可對帳的識別碼保存副作用；推送失敗時轉存救援分支；最後再保存工作目錄或輸出物。GitHub 官方說明，workflow artifact 可在工作結束後持久保存檔案，適合作為 Git 寫入失敗時的最後一道成果留存：https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts。
後續應觀察的指標
- 端到端成功率：外部動作完成、重新讀取驗證與狀態寫回是否全部成功。
- 推送拒絕率、重試後成功率，以及救援分支或 artifact 啟用次數。
- 同一資源的同時寫入者數、併發群組等待時間與被取消的排程數。
- 已發布項目與台帳、統計快照之間的覆蓋率差異。
- 排程標示時間與實際執行時間的延遲分布，而非只看工作是否顯示綠燈。
這起案例最有價值的地方，不是宣稱模型從未出錯，而是把「代理是否可靠」重新定義為一條完整交付鏈。當成果沒有安全落地、可被驗證並能由下一輪讀取時，再好的模型也只是完成了中間步驟。