Day 31：把四個代理人串成一條生產線 結尾留下一句話：但今天講的這一切，都是建立在每個環節的 Agent 都正常運作、正常產出這個前提之上的正常路徑。如果某個環節的 Agent 呼叫失敗，或是產出的結果不符合預期格式，這種異常狀況今天還沒有處理，將在下一篇正式揭曉。

今天要正式回答這件事。

風平浪靜講完了，今天要處理萬一

四類 Agent 觸發、同步、介入的編排邏輯，到 Day 31 已經全部定案完畢，審查代理人打回規格層級問題之後，下游要局部保留還是整篇重做，也有了明確判準。但 Day 31 講清楚一件事，這一切都建立在每個環節都正常運作、正常產出這個前提之上。如果哪個環節出了狀況，這件事還沒有答案。今天要正面補上這塊空白。

今天依然是階段七的篇章，延續同一個定調，本階段刻意壓縮為三天，聚焦在串接邏輯、錯誤重試機制、多平台格式轉換與發佈，不重複闡述任何一個 Agent 本身的職責，因為那些已經在階段三到六講完，這三天的任務是把已經存在的四個獨立單元組裝成系統，敘事重心從「單一 Agent 怎麼做」轉為「系統怎麼串」。Day 31 處理的是串接邏輯裡風平浪靜的那一半，今天處理的是同一條敘事線裡萬一出狀況的那一半。

任務範圍也要先畫清楚。本篇只設計生產線內部異常路徑的偵測、重試與中止回報機制，不涉及成品完成之後的多平台格式轉換或發佈流程，那是 Day 33 要處理的問題。今天要走的，僅僅是當任一環節的 Agent 呼叫失敗或產出不符規格時，系統如何偵測並重試或中止。

兩種不一樣的壞掉，叫不到人和叫得到人但答非所問

要判斷該不該重試或中止，得先把「壞掉了」這個籠統的印象拆開。系統收到的異常狀況，其實至少有兩種性質完全不同的類型，若用同一套邏輯處理，只會讓後續的判準失去意義。

第一種是 Agent 呼叫本身失敗，例如逾時、服務無回應。這類失敗的特徵是連產出內容都不存在，系統根本沒有收到任何回應可供檢視。這就像打電話給某個環節，電話響了很久，始終沒有人接聽，對話根本沒有開始。偵測這種失敗不需要檢視內容，只需要判斷是否在合理時間內收到任何回應，收不到回應本身就是失敗的全部證據。

第二種是 Agent 有回應，但產出內容不符合預期格式或規格。例如寫作代理人產出的內容明顯缺漏規格書要求的段落，或審查代理人回傳的結果不符合預期結構。這類失敗的特徵是產出確實存在，電話接通了，對方也開口說話了，但回答的內容答非所問，明顯沒有針對問題回應。偵測這種失敗不能只看有沒有回應，必須拿產出內容對照規格書要求的結構或段落清單，逐項檢查是否有明顯缺漏或格式不符。

這兩種失敗性質不同，一種是完全收不到東西，另一種是收到東西但東西不對。前者要先確認的是線路本身通不通，後者要拿對方回答的內容去對照原本問的問題。這個區分是後續設計重試與中止判準的基礎，不是文字遊戲，因為兩種失敗背後代表的問題成因完全不同，接下來要處理的重試策略也必須分開設計，不能用一套規則打天下。

重試有意義還是白費力氣，暫時性與永久性失敗的判準

偵測到失敗之後，系統不能每次都無條件重試，也不能每次都直接放棄。多數人對失敗的直覺反應是重試不行就一直重試到成功為止，但這個直覺有明顯的盲點，因為有些失敗背後的原因跟輸入內容本身有關，重試多次也不會改變結果，繼續無限重試只是浪費時間與資源，必須設計具體的判準。

這裡的關鍵區分是暫時性失敗與永久性失敗。暫時性失敗指的是逾時、服務暫時無回應這類原因，背後成因與輸入內容本身無關，重試有機會成功。這好比某個環節暫時卡住，好比一時塞車，過一會車流恢復正常，重新出發就能抵達目的地。永久性失敗指的是同一個 Agent 對同樣的輸入反覆產出不符規格的結果，代表問題可能出在輸入本身或規格描述本身有歧義，單純重試不會改變結果。這好比問題出在地址本身寫錯，不管重新出發幾次，路線再怎麼調整都到不了正確地點，這時候該做的是先停下來確認地址本身是不是有問題，不是繼續重新出發。

系統應設計明確的重試次數上限，在上限之內，兩種失敗類型的重試方式也有差異。Agent 呼叫本身失敗這類情況，每次偵測到就直接重試，因為問題出在呼叫過程本身而非輸入內容，直接再次嘗試即可。產出內容不符規格這類情況，重試前可考慮在下一次呼叫時附上前一次不符規格之處作為提示，讓下一次嘗試有機會針對已知的缺漏補正，而不是重複同樣的錯誤。超過重試次數上限之後，系統應明確判定這是永久性失敗，中止該環節的自動重試，轉為上報等待處理，而不是無限重試下去。

設計重試次數上限的目的很清楚，是避免系統在明知重試不會改變結果的情況下持續空轉，把資源與時間浪費在注定失敗的重試上。次數上限本身給出一個明確的停損點，讓系統在合理嘗試之後，把判斷權交還給接下來要處理的機制，而不是無止盡地卡在同一個環節原地打轉。

壞掉的只是一段，還是重試範圍要呼應局部保留的精神

重試的時候，是要重試整個 Agent 的呼叫，還是可以只重試受影響的局部部分，這個設計不能自成一套，必須呼應 Day 31：把四個代理人串成一條生產線 已定案的處置原則。Day 31 的結論是，範圍局限在特定段落單元就局部保留、只重做受影響部分，範圍擴及全篇核心目標或整體結構才考慮較大範圍重新展開。

這個判斷原則本身，Day 31 已經指出直接呼應 Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 病灶對照表裡零容錯結構一項的既定精神，規劃代理人先把創作過程拆分成具備獨立邊界的產出規格與段落單元，審查代理人發現問題時只需精準指向對應段落與角色，不必要求整篇重寫。今天設計重試範圍，延續的正是同一條脈絡，不重新展開這套精神的完整論證，只把它套用到異常處理這個新的情境上。

具體的重試範圍判準，依失敗類型分成三種情況。若失敗是 Agent 呼叫本身失敗，連產出內容都不存在，沒有局部可言，只能重試整次呼叫，因為根本沒有任何已完成的部分可供保留。若失敗是產出內容不符規格，且不符規格之處可以被明確定位到規格書裡的某個段落單元，例如某一節內容缺漏或某個段落格式錯誤，其餘段落單元的產出並未受影響，則只需要針對受影響的段落單元重試，其餘已經正常產出的部分應予保留，不需要把整個 Agent 的產出全部作廢重跑。若不符規格之處涉及整體結構或核心目標本身的偏差，影響範圍擴及多數段落單元，才需要考慮整次重新呼叫。

這裡延續 Day 31 已經使用過的建築物比喻，若某個房間的裝修出了問題需要重做，其他已經完工的房間不需要因此陪著一起打掉重做，只需要針對那個房間重新施工。錯誤重試也是同樣的道理，如果問題只出現在某個段落單元，重試的範圍也應該框定在那個段落單元，其餘已經產出且沒有問題的部分不需要陪著一起重跑一次。

必須明確點出，這正是 Day 31 局部保留精神在異常處理情境下的延伸應用，錯誤處理與正常路徑下的回頭重做，共享同一套依影響範圍大小決定處置範圍的判斷邏輯，而非另立一套互相矛盾的判準。今天新增的是把同一套系統設計哲學，套用到 Agent 呼叫失敗與產出不符規格這個新的異常情境上，不是另立一套獨立於 Day 31 之外的規則。

範圍判準確立之後，還有最後一個問題，中止之後要對誰、用什麼方式回報，才能確保不會有環節悄悄卡死而沒有人知道。中止事件本身，應該被明確標記為一個獨立於一般進度標記之外的異常狀態，這個異常狀態要記錄在所有角色都能查見的共享位置，而不是只停留在失敗當下那個角色自己的內部記錄裡。回報內容應包含哪個環節發生異常、屬於哪一種失敗類型、已經重試過幾次，讓接手處理的人能夠一眼掌握狀況，不需要另外回頭排查。

這好比工廠生產線上某一站的機台反覆故障，操作員排除幾次都沒有效果，這時候不會讓機台一直空轉下去，而是會拉下警示燈或按下警報鈕，讓現場管理人員看到這個警示，過來判斷接下來該怎麼處理。警示燈亮起本身不代表問題已經解決，而是代表這個環節目前系統自己判斷不出該怎麼繼續往下走，需要人來看一眼。這正是呼應系列已經定案的 Human-in-the-loop 精神，系統設計中明確保留人類介入決策的節點，在異常情境下的具體體現，人類判斷保留在系統自己判斷不出該怎麼繼續往下走的節點。

需要強調一件事，今天新增的整套偵測與處置規則，是架在 Day 31 已經建立的狀態旗標與進度標記機制之上運作，不是引入新的角色，也不是改變既定的職責邊界。執行偵測與重試的主體，仍然是既有的四類 Agent 與其呼叫關係本身，沒有另外找一個角色專門負責監控或調度。

生產線跑得動了，但成品還沒有到讀者面前

今天正面回答了 Day 31 留下的伏筆，正常路徑下的編排邏輯講完之後，某個環節的 Agent 呼叫失敗或產出不符規格時系統該怎麼辦，今天有了明確答案。失敗須先區分兩種性質不同的類型，Agent 呼叫本身失敗連產出內容都不存在，產出內容不符規格則是收到東西但東西不對，兩者需要不同的偵測方式。偵測到失敗之後須進一步判斷是暫時性失敗還是永久性失敗，暫時性失敗重試有機會成功，永久性失敗重試多次也不會改變結果，須設計重試次數上限，超過上限後中止自動重試轉為上報等待處理。

重試的範圍也不是不分青紅皂白整個從頭重跑，若問題只影響規格裡的某個段落單元，重試也應只針對受影響的部分，其餘已正常產出的部分予以保留，這正是 Day 31 局部保留精神在異常處理情境下的延伸應用。中止之後也不是讓環節悄悄卡死沒有人知道，須把中止狀態標記在所有角色都能查見的共享位置，並交由人類判斷介入處理，呼應系列既有的 Human-in-the-loop 精神。

到今天為止，整條生產線在正常路徑與異常路徑上都已經有明確的處置方式，成品理論上能夠順利跑完全程。但跑完全程之後，這份成品要怎麼變成讀者最終會看到的樣子，要怎麼適應不同平台各自的格式需求並完成發佈，這件事今天還沒有答案，將在下一篇正式揭曉。