AI 302 · 模組 3
如果流程執行到一半中斷，系統如何安全地繼續，而不是全部重來？
開始第一節在單元 2，你把一次 Run 描述為 State 經過各個 Step 與 Transition 的移動。真實的 Run 常會被中斷：服務重新啟動、達到時間上限、使用者關閉連線。本單元的核心問題是：如果流程執行到一半中斷，系統如何安全地繼續，而不是全部重來？
某系辦的 Workflow 有五個 Step：收集請求、分類、撰寫回覆草稿、寄出回覆、記錄結果。Run 在回覆寄出之後、記錄結果之前中斷。因為什麼都沒有存下來，團隊只好整個 Run 重新啟動。每一封回覆又被寄了第二次，收件者收到重複的信件。
注意
Checkpoint 是在選定的位置為 Run 儲存的紀錄，讓 Run 之後可以從那裡繼續。儲存下來的紀錄就是 Run State 的 Snapshot。把它存在中斷之後仍然存在的地方，稱為 Persistence。可以回到的那個位置，就是 Recovery Point。
文字版說明：Run 在做事與儲存 Snapshot 之間交替。中斷之後，Run 可以回到最近的 Checkpoint，而不是回到起點。Checkpoint 2 位於外部動作之後，所以它記錄了該動作已經發生。
| 項目 | 為什麼要保留 | 範例 |
|---|---|---|
| Execution Identity | 讓系統知道這是哪一次 Run | 每週請求批次的 Run ID |
| 目前的 Step | 讓系統知道從哪裡繼續 | 撰寫草稿，第 12 筆，共 40 筆 |
| Step 的輸出 | 讓已完成的工作不必重做 | 已分類的 40 筆請求 |
| Action Record | 讓系統知道外部已經發生了什麼 | 第 1 到 11 封已寄出，並有確認 |
| 待處理項目 | 讓沒有任何項目被遺漏 | 第 12 到 40 筆尚未撰寫草稿 |
為什麼 Snapshot 除了目前的 Step，還要儲存 Execution Identity 與已完成動作的紀錄？
你可以在每個小動作之後都儲存 State，但這樣成本很高，更重要的是，並不是每個位置都是安全的 Checkpoint。安全的 Checkpoint 是指：回到那裡時，Run 是正確且一致的。以下五個問題可以幫助你判斷。
| 問題 | 檢查什麼 | 範例 |
|---|---|---|
| External Action 是否已經發生？ | 外部世界是否已被改變 | 在這個位置之前已經寄出回覆 |
| 這個 Step 是否可逆？ | 影響是否能被撤銷 | 草稿可以丟棄，寄出的通知無法收回 |
| Replay 會重複某個動作嗎？ | 再執行一次是否會重複影響 | 重播「寄出回覆」會寄兩次 |
| 必須保存哪些 State？ | Run 要正確繼續需要什麼 | 項目清單、輸出、Action Record |
| 什麼證據能確認已完成？ | 如何知道 Step 真的完成 | 寄送確認，而不只是「沒有錯誤」 |
某個 Step 寄出通知，而 Checkpoint 在確認寄出之前就儲存了。為什麼這是不安全的 Checkpoint？
中斷之後，系統可以 Restart 或 Resume。Restart 是從第一個 Step 重新開始。Resume 是使用已儲存的 State，從 Recovery Point 繼續。Resume 能節省工作，但重播 Step 仍可能重複它的 Side Effect。
| 概念 | 意思 | 範例 |
|---|---|---|
| Side Effect | 在 Run 之外造成的改變 | 寄出訊息、更新紀錄 |
| Replay | 中斷後再次執行某個 Step | Resume 時重新執行「寄出回覆」 |
| Idempotency | 同一個動作做兩次的效果與做一次相同 | 第二次把請求標記為「已回覆」沒有任何改變 |
| Duplicate Execution Risk | Replay 重複了非 Idempotent 動作的可能性 | 同一封回覆被寄出第二份 |
| Action Record | 記錄該動作已發生的已儲存紀錄 | 第 7 封已寄出，並有確認 |
本單元把 Idempotency 當作推理 Replay 的概念來教。如果一個動作不是 Idempotent，設計上應該記錄它已發生、在再次執行前先檢查紀錄，或在它前面放一道 Human Gate（單元 4）。
Resume 的 Run 重播了一個寄出回覆的 Step，而該寄送不是 Idempotent。主要的風險是什麼？
Durable Execution 是指系統能撐過中斷，並從已知的有效 State 繼續。它是設計的特性，不是某一個產品的功能。Durable 的設計具備已儲存的 State、清楚的 Execution Identity、安全的 Checkpoint，以及明確定義的 Resume 行為。
文字版說明：執行時，系統在安全的 Checkpoint 儲存 Snapshot。中斷之後，它用 Identity 找到該次 Run、還原最近的有效 Snapshot、檢查哪些動作已被記錄，然後繼續，而不是重新開始。
| 概念 | LangGraph 對應範例 | 說明 |
|---|---|---|
| State | Graph state | 在整個 Run 中傳遞的資料 |
| Step | Node | 一個工作單元 |
| Transition | Edge 或 conditional edge | Run 如何移到下一個 Step |
| Checkpoint | Checkpointer | 儲存 State，讓 Run 可以 Resume |
| Human-in-the-Loop | Interrupt 與 resume 模式 | 暫停等待人，然後繼續 |
| Recovery | State-aware resume 或 alternate transition | 從已儲存的 State 繼續，或改走另一條路徑 |
資訊
在本單元中，框架對應表應該如何使用？
活動 3 稱為 Where Should We Checkpoint？先做範例，再用你自己的 Workflow 練習。請不要在此練習中輸入真實的公司機密、客戶個人資料或任何未經授權的敏感資訊。
| Step | Checkpoint 決定 | 理由 |
|---|---|---|
| 1. 收集請求 | 完成後建立 Checkpoint | 可逆且儲存成本低，之後需要這份清單 |
| 2. 分類請求 | 完成後建立 Checkpoint | 儲存分類結果，避免重做 |
| 3. 撰寫回覆草稿 | 完成後建立 Checkpoint | 草稿可以丟棄，但儲存能避免重工 |
| 4. 寄出回覆 | 不安全的 Replay 點；每次寄出都要記錄並確認 | 重播會寄出重複的信件 |
| 5. 記錄結果 | 完成後建立 Checkpoint，然後結束 | 標記 Run 已完成 |
資訊
在範例中，為什麼 Step 4（寄出回覆）被標為不安全的 Replay 點？
