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

生產線跑得完了，但成品還沒有到讀者手上

四類 Agent 觸發、同步、介入的編排邏輯，到 Day 31 全部定案完畢，某個環節呼叫失敗或產出不符規格時該怎麼偵測、怎麼重試、怎麼中止回報，到 Day 32 也全部定案完畢。生產線正常路徑與異常路徑都已經有明確的處置方式，成品理論上能夠順利跑完全程。但成品跑完全程之後，要怎麼變成讀者最終看到的樣子，這件事還沒有答案。今天要正面補上這塊空白。

今天是階段七的收尾篇，也是整個階段七的最後一天，依然延續同一個定調，本階段刻意壓縮為三天，聚焦在串接邏輯、錯誤重試機制、多平台格式轉換與發佈，不重複闡述任何一個 Agent 本身的職責，因為那些已經在階段三到六講完，這三天的任務是把已經存在的四個獨立單元組裝成系統，敘事重心從「單一 Agent 怎麼做」轉為「系統怎麼串」。Day 31 處理的是正常路徑的編排邏輯，Day 32 處理的是異常路徑的錯誤處理機制，今天要處理的是生產線末端成品如何被轉換與發佈的問題。

任務範圍也要先畫清楚。本篇只設計統一格式成品的樣貌、平台格式差異的轉換方向、轉換與發佈的角色歸屬、以及發佈前的確認機制，不涉及實際跑一次生產線的執行過程，也不涉及任何量化驗證結果，那是 Day 34 要處理的問題。

為什麼要先收斂成一份，統一格式成品的樣貌與存在理由

寫作代理人產出文字內容，視覺代理人產出架構圖、資料圖表與封面配圖，審查代理人查核完畢，確認事實正確、去除 AI 腔調、格式排版一致。這三者的產出，最終要收斂成什麼樣的成品，才能進到發佈這一步，這是今天第一個要正面回答的問題。

答案是，這三者的產出最終應該收斂成一份統一格式的完整成品。這份成品具體包含三類內容，第一類是通過審查的正文文字本身，第二類是對應位置的圖表與配圖素材，第三類是文章的結構性中繼資料，也就是延續自 Day 04：規劃代理人的產出介面，認識 Section Spec 既有欄位而來的資訊，例如標題、目標讀者、系列定位這類資訊。這三類內容合在一起，構成一份忠於內容本身、不預設任何特定平台格式的完整版本。

為什麼不讓每個平台各自產出格式，而是先收斂成一份統一格式再轉換，這件事值得正面說清楚。

若不存在這份統一格式，寫作代理人與視覺代理人勢必得為每一個要發佈的平台各自產出一份格式相容的版本，等於讓上游角色承擔原本不屬於自己職責的平台適配工作，也讓同一份內容因為要同時兼顧多種平台格式而彼此牽制。這好比一間工廠若要求生產線末端的每一站直接依照不同零售通路各自的包裝規格分頭包裝，會導致同一批貨物在還沒離開工廠之前就得先拆成好幾種版本各自處理，任何一個包裝規格異動都得回頭驚動生產線前段。反之若生產線先產出一份統一規格的成品，再由末端單一環節依不同通路需求重新包裝出貨，前段生產只需要專心把東西做好，不需要顧慮每個通路各自的包裝細節。

這個設計連結到系列一路強調的單一職責與集中管理的設計哲學。統一格式讓上游各角色只需要專心產出一份忠於內容本身的成品，格式轉換這件事被集中到下游單一環節處理，這正是單一職責原則在生產線末端的延伸體現，也是全域錨點檔案這類集中管理精神的同一種思路，把容易分散、容易在多處各自維護而彼此不一致的東西，收斂到一個地方管理。

同樣的內容，在不同平台上長得不一樣

統一格式成品確立之後，不同平台各自對格式有不同要求，這些差異具體會出現在哪裡，這是今天第二個要正面回答的問題。至少可以整理出三種常見的差異方向。

第一種差異方向，是圖片的插入語法不同。有些平台使用標準 Markdown 圖片語法即可直接顯示，有些平台則要求圖片先上傳至平台自有的圖床，取得專屬語法之後才能正確引用。統一格式裡的圖表若只用相對路徑或本地路徑存放，轉換時須依目標平台規則，置換成該平台可辨識的引用方式。

第二種差異方向，是標題階層的呈現規則不同。有些平台把最高層標題保留給文章標題本身，內文最高只能從次層標題起算，若統一格式裡內文本身就從第一層標題起算，直接搬過去可能導致該平台呈現出重複或混亂的標題階層，轉換時須視目標平台規則統一升降階層。

第三種差異方向，是程式碼區塊的語法高亮標記方式不同。有些平台在程式碼區塊起始處標註語言關鍵字即可自動套用對應語法高亮，但不同平台對關鍵字命名或支援語言範圍的規則不盡相同，甚至有些平台不支援特定語言的高亮，轉換時須對照目標平台支援清單，決定如何標註，或退而求其次採用最接近的替代標註。

可以再補充第四種方向，內部連結在系列中以雙向連結語法指向其他篇章，這種語法多數對外發佈平台並不支援。若目標平台是對外公開網站，這類連結須轉換成可公開存取的完整網址；若目標平台本身就是封閉的個人知識庫環境，則可視情況保留原有語法。

同一張圖放到不同平台，有的地方能直接顯示，有的地方要先搬到平台自己的相簿才能顯示；同一份文字的標題層級，在有些地方看起來井然有序，搬到另一個地方卻可能因為階層對不齊而顯得混亂；同一段程式碼，在有些地方色彩分明容易閱讀，搬到另一個地方卻可能變成一片沒有任何顏色標示的純文字。轉換這個動作要做的，就是讓同一份內容不管搬到哪裡，都能維持住原本要傳達的樣子。

無論處理哪一種格式差異，轉換時都必須遵守同一個原則，轉換動作只能改變外在呈現的語法形式，不能更動內容本身要傳達的意思。若某個目標平台完全不支援某種呈現方式，寧可退化為較樸素但語意不失真的替代呈現，也不能為了遷就平台語法而犧牲或竄改原意。

這件事該交給誰，是某個代理人的延伸，還是生產線本身的下一步

格式轉換與發佈這個動作，究竟該由既有四類 Agent 中的哪一個負責，還是不適合歸屬到任何一個既有角色，這是今天第三個、也是最需要謹慎判斷的問題。

先逐一檢視排除。規劃代理人只負責產出規格，不涉入成品層面的任何轉換工作，可以先排除。寫作代理人與視覺代理人的職責分別是產出文字與產出視覺素材，格式轉換發生在兩者的產出都已經完成、且已經通過審查之後，若把轉換工作硬塞給其中一者，等於讓該角色承擔原本不屬於自己認知任務的平台適配工作，違反系列一路強調的單一職責原則。

審查代理人須特別檢視，因為這是最容易被誤以為適合的選項。讀者很可能直覺認為，審查代理人本來就負責格式排版的查核，格式轉換順理成章應該交給審查代理人做。但依 Day 31 定案的四類 Agent 職責邊界原則，「審查代理人不負責產出任何一段會直接沿用進成品的新內容」，格式轉換動作雖然不是撰寫新內容，但語法置換、連結轉換這類操作，本質上是在生成一份新的、供特定平台使用的檔案版本，若交由審查代理人執行，容易模糊審查代理人只查核不產出的既定邊界。這好比工廠裡負責品管的人員，職責是檢查成品有沒有瑕疵，而不是負責把成品重新包裝成不同通路要的樣子，那是包裝出貨部門的工作。若讓品管人員兼著做包裝出貨的工作，品管這個角色原本純粹核對是否合格的定位就會變得模糊。

逐一檢視過後，格式轉換與發佈這件事並不適合歸屬到既有四類 Agent 之中的任何一個延伸任務。但系列既定原則不得引入第五類常設 Agent，因此須明確給出結論，這件事的正確定位是工作流編排本身的下游流程步驟，不是新增一個角色。格式轉換與發佈是在四類 Agent 各自完成職責、審查代理人查核通過、成品已經收斂為統一格式之後，接續在生產線末端執行的一段轉譯與輸出程序，這段程序處理的是已經定案內容的格式轉譯與投遞，不涉及任何需要認知判斷或內容生成的工作。格式轉換與發佈的性質更接近生產線末端的包裝出貨流程，是流程本身的延伸，不是品管職責的延伸，也不需要為了這段流程另外招募一位新的員工，只是既有的生產線再往後多走一段，而不是生產線裡多了一個新的工作站。

按下發佈鍵之前，要不要有人再看一眼

格式轉換完成之後，是不是應該直接自動執行發佈，還是應該在發佈前保留某種最終確認機制，這是今天第四個要正面回答的問題。

發佈這個動作有一個特殊性質，值得先講清楚。

發佈是整條生產線中唯一一個會把內容真正公開到讀者面前、且公開之後難以完全收回的動作，這個性質與先前生產線內部各環節的中間產出截然不同。

中間產出如果有問題還能回頭修正而不影響任何人，但已經發佈出去的內容一旦被讀者看見，即使事後修正，也已經造成既定事實。

依此性質，須明確給出結論，發佈前應該設計為一個明確的 HITL 節點。

在格式轉換完成、即將執行對外發佈的動作之前，保留一個由人類做最後確認的關卡，確認轉換後的成品呈現正確，沒有因為格式轉換過程而失真或出現非預期的呈現錯誤，確認無誤之後才真正執行發佈。這好比包裹在正式送出貨運之前，即使前面每一道檢查與包裝程序都已經跑過，出貨窗口通常還是會有一位人員在按下出貨確認鍵之前再看一眼，這一眼確保的是這批貨真的要在這個時間點、以這個樣子送到對方手上，不是重新檢查整批貨物有沒有瑕疵，一旦送出就難以完全收回，值得讓人類在最後一刻再確認一次。

這個設計呼應系列已經定案的 Human-in-the-loop 精神，系統設計中明確保留人類介入決策的節點，人類判斷保留在系統自己判斷不出、或後果重大到不適合完全交由系統自行決定的節點，發佈這個對外公開且難以收回的動作，正屬於此類節點。

需要強調一件事，格式轉換與發佈這段下游流程步驟，運作於審查代理人查核通過、成品收斂為統一格式之後，是 Day 31 已建立的編排邏輯與 Day 32 已建立的異常處理機制之後，生產線自然延伸出的最後一段路徑，不是引入新的角色，也不是改變既定的四類 Agent 職責邊界。

小結

今天正面回答了 Day 32 留下的伏筆，成品跑完全程之後要怎麼變成讀者最終會看到的樣子，今天有了明確答案。寫作代理人產出的文字、視覺代理人產出的圖表與封面、審查代理人查核完畢的結果，最終收斂成一份統一格式的成品，這份統一格式的存在，讓上游角色只需專心產出忠於內容本身的成品，不需要各自為每個平台重複產出相容版本，格式轉換被集中到下游單一環節處理，這是系列一路強調的單一職責與集中管理精神在生產線末端的延伸。不同平台各自存在圖片語法、標題階層、程式碼高亮標記、內部連結呈現方式等格式差異，轉換時只能改變外在呈現形式，不能更動內容本身要傳達的意思。格式轉換與發佈這件事逐一檢視過既有四類 Agent 之後，判定都不適合歸屬其中任何一個，也不能引入第五類常設 Agent，因此定位為工作流編排本身的下游流程步驟，是生產線流程往後多走的一段，不是多了一個新角色。發佈這個對外公開且難以收回的動作，設計為一個明確的 Human-in-the-loop 節點，在正式發佈前保留人類做最後確認。

到今天為止，階段七的三天，從正常路徑的編排邏輯，到異常路徑的錯誤處理，再到今天的格式轉換與發佈，已經把規劃、撰寫、視覺、審查四個獨立角色，組裝成一條能夠因應正常與異常狀況、並且能夠適應不同平台發佈的完整生產線，整套人機協同寫作系統在設計層面已經完整成形。

但到目前為止，四個代理人還沒有串起來運作，所有的設計都還停留在紙上談兵的層次，這套系統實際跑起來會是什麼樣子，能不能真的達到當初設計的效果，這件事還沒有被驗證過，將在下一篇正式揭曉。