重新啟動中斷的 AI 工作流程，不重複執行已完成的業務操作

如果 ERP 在 AI 執行程序停止前一刻已儲存生產工單的變更，您的團隊就必須在不重複提交變更的情況下復原流程。能保留進度並查核 ERP 結果的工作流程，可讓員工不必逐步重新梳理執行過程，同時將確實無法判定結果的操作交給負責人處理。AWS 的指引說明了這種做法背後的重試保護機制。

冪等性是指重複執行同一操作，其效果仍維持不變的特性。持久執行會保留已完成步驟的結果；具備冪等性的業務邏輯，則能保護那些因完成狀態尚未記錄就發生中斷，而可能再次執行的操作。AWS 文件說明了兩者的差異。

實際效益是選擇性復原：沿用已確認的結果、重試符合條件的操作，並只調查尚未釐清的工作。FAIS 會以您的企業本體（ontology）為核心建置這套機制，也就是描述業務物件、關係與允許操作的共用模型，並將它連結至工作流程紀錄與 ERP 查核。模型用來界定操作的意義；連接器與復原控制機制則用來確認操作是否確實發生。

自動化如何接續執行，而不重複已完成的工作？

您的復原設計需要來自實際執行業務操作之系統的證據。執行程序成功重新啟動固然有用，但後續該如何處理，取決於 ERP 是否已儲存預期的變更。

AWS Lambda 會傳回檢查點已保存的結果，而不重新執行已完成的步驟；但中斷的步驟可能再次執行。每次重試嘗試所提供的「至少一次」或「至多一次」執行保證，都無法保證整個工作流程中的操作恰好執行一次。Lambda 的檢查點行為與 SDK 的執行語意說明了為何復原機制除了執行程序，也必須涵蓋目標系統的寫入操作。

重新啟動是技術事件；復原則是業務成果。

以可追溯的操作取代人工重建過程

以一家假設的製造商為例，其自動化流程會將已核准的生產工單變更寫入 ERP。若缺乏復原控制機制，重新啟動的執行程序找不到本機成功紀錄，就得由生產規劃人員在任何人重新提交之前，先查明變更是否已完成。

採用所提議的控制機制後，工作流程會在送出前儲存預期變更及其操作識別碼。發生中斷後，連接器會查核 ERP 的權威證據。若找到相符且已完成的操作，執行程序便可記錄目標系統的參照資訊，繼續執行而不再次寫入。若結果不明，則將原始請求與現有證據一併交給生產規劃人員。

改善之處在於縮小調查範圍：生產規劃人員只需檢視尚未釐清的操作，不必重新梳理整次執行過程。生產變更的核准權仍屬於指定的業務角色；復原機制並不授予修改請求內容的權限。

FAIS 會將生產工單、已核准的變更及負責人，連結至這些持久保存的操作紀錄。我們提議的企業本體與工作流程自動化做法，是在您現有的 ERP 投資基礎上建置復原控制機制，而非要求更換 ERP。共用的業務定義可為未來的自動化與 AI 代理提供可重複運用的基礎，但每個連接器的寫入與查詢行為仍須各自經過驗證。

明確訂定重試決策

重新啟動的執行程序應將操作紀錄與目標系統的證據進行核對。測試前，請明確訂定以下決策：

目標系統的證據	復原決策
相符的操作已依預期的請求內容完成	記錄目標系統的參照資訊，繼續執行而不再次寫入。
尚未確認是否完成，但經驗證的目標系統冪等性契約涵蓋此次重試	使用原始鍵值，重試內容未變更的請求。
權威證據確認操作尚未完成，且先前的請求已不可能再提交生效。	透過經核准的寫入邊界與並行保護機制重試。
無法查詢、資料可見性不明，或先前的請求仍未結案	暫停相依工作，並指派負責人。
識別碼對應到不同的請求內容，或紀錄互相衝突	停止自動寫入，並要求核對釐清。

這些提議的邊界遵循 AWS 關於穩定鍵值與交易檢查的指引，以及其對意圖變更與識別碼保留的處理方式。

僅有本機識別碼，無法防止目標系統發生重複寫入。請驗證連接器的查詢一致性、交易可見性、未結案請求的行為、唯一性強制機制與保留期限。只有當這些查核足以確定「查無資料」代表什麼時，空白搜尋結果才足以作為判斷依據。

在一個範圍明確的工作流程中驗證復原能力

從一個會寫入 ERP 的自動化流程開始，在沙箱或隔離的紀錄上測試，並將下游影響控制在限定範圍內。送出前，先持久保存其業務物件、預期變更、操作識別碼、請求內容與負責人；重試時維持相同識別碼，正如 AWS 的權杖模式所要求。

分別在送出前、請求尚未結案時，以及 ERP 已提交生效但本機尚未記錄成功時，中斷執行程序。測試也須納入無法查詢與結果衝突的情況。依據測試前議定的門檻，衡量復原時間、遺漏的工作、重複操作，以及尚未解決的交接案件。

是否實作的判斷，在於這個工作流程能否接續已確認完成的工作，並將不確定之處呈現得足夠清楚，讓負責人能據以處理。在受測條件達到此標準之前，應持續在監督下運作。與 FAIS 討論這個工作流程，可將這項決策連結至您企業實際需要的生產工單模型、連接器行為與自動化控制機制。