跳到主要內容
NTPU AI Learn

AI 302 · 模組 5

Retry、Failure Classification 與 Recovery

Agent 失敗時，系統應重試、換方法、交給人，還是直接停止？

開始第一節
  • 時長60 分鐘
  • 難度架構
  • 先備知識建議先完成 AI 301，以及本課程第 1 至 4 單元
已完成 0 / 7
同步我的進度加入梯次後，進度可跨裝置保存，講師也能看到

資訊

加入後，你已完成的模組編號會連同「學員代碼」傳送給講師，講師可以看到你的進度。請使用講師提供的代碼，不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 區分 Failure、Error 與 Exception，並用八類 Failure Taxonomy 分類失敗
  • 說明 Timeout、Retry、Retry Policy、Retry Limit 與 Backoff 概念
  • 辨識何時 Retry 不安全，例如付款、破壞性動作、外部通知與不可逆交易之後
  • 運用 Recovery Decision Model 選擇 Retry、Fallback、Re-plan、Compensation、Escalation 或 Safe Stop
  • 完成活動 5，並產出 Failure & Recovery Policy

Failure 與其類型

9 分鐘

Agent 失敗時，系統該怎麼做？

在單元 4，你設計了在工作往下流動前先檢查的 Gate。現在是另一種情況：某個步驟不只是結果不理想，而是失敗了。可靠的 Harness 不會期待失敗很少發生，而是預先決定每一種失敗要如何處理。

核心問題

Agent 失敗時，系統應重試、換方法、交給人，還是直接停止？

關鍵詞彙
詞彙白話意思
Failure某個步驟沒有達成它應該達成的目標
Error表示出了問題的訊號，例如錯誤碼或錯誤訊息
Exception中斷正常執行的非預期狀況
Recovery失敗之後，系統為了回到安全且有用的狀態所做的事
模擬範例

一個模擬的報告 Agent 呼叫資料工具，沒有得到回應；接著收到欄位缺漏的表格；然後寫出與表格矛盾的摘要。這是三種不同的失敗，每一種都需要不同的處理。

資訊

本單元教的是適用於任何 Agent 框架的概念。框架可以實作這些概念，但設計要先做。

重點: 失敗是預期中的事。請預先決定每一種失敗如何處理，而不是在執行中臨時應變。

9 分鐘

Failure Taxonomy：並非所有失敗都一樣

正確的處理方式取決於失敗的類型。Failure Taxonomy 讓團隊有共同語言，讓 Recovery 的選擇從類型自然導出。

Failure Taxonomy
  1. Transient：短暫的問題，可能自己就會消失
  2. Tool / Network：工具或連線失敗，或逾時
  3. Missing Data：必要的輸入不存在或不完整
  4. Invalid Output：結果格式錯誤或不符預期
  5. Logical / Planning：計畫或推理本身有誤
  6. Permission：Agent 沒有權限做這件事
  7. Safety / Policy：這個動作會違反安全規則或政策
  8. Human Rejection：有人審查後拒絕了這項工作

資訊

圖示的文字版：一個名為 Failure 的節點分成八種類型：Transient、Tool / Network、Missing Data、Invalid Output、Logical / Planning、Permission、Safety / Policy 與 Human Rejection。每一類都在同一層，因此各自可以通往不同的 Recovery 路徑。
各類 Failure 與模擬範例
類型模擬範例
Transient某服務暫時忙碌，稍後就回應了
Tool / Network資料工具在時間限制內沒有回應
Missing Data輸入檔案缺少日期欄位
Invalid Output需要表格時，Agent 卻回傳文字
Logical / Planning計畫把兩個互相依賴的步驟順序排反了
PermissionAgent 嘗試寫入只有讀取權限的資料夾
Safety / Policy草稿會包含政策禁止的個人資料
Human Rejection審查者拒絕了草稿
自我檢測

Agent 嘗試寫入一個只有讀取權限的位置。這屬於哪一類 Failure？

Agent 嘗試寫入一個只有讀取權限的位置。這屬於哪一類 Failure？

重點: 先說出 Failure 的類型。指引正確 Recovery 的是類型，而不只是錯誤訊息。

Timeout、Retry 與其限制

9 分鐘

Timeout、Retry Policy 與 Backoff 概念

有些失敗值得再試一次。Timeout 避免步驟無止境地等待。Retry 是把步驟再執行一次。Retry Policy 是書面規則，規定何時、幾次、多久之內重試，讓重試成為設計決定，而不是反射動作。

Retry 相關概念
概念白話意思
Timeout一個步驟被視為失敗之前，最多可以花的時間
Retry失敗後再執行一次相同的步驟
Retry Limit放棄之前最多嘗試的次數
Backoff（概念）每次嘗試之間等得稍微更久，避免打垮已經吃力的服務
Retry Policy結合哪些失敗可重試、次數上限與等待模式的規則
模擬範例

唯讀資料查詢的 Policy：只對 Transient 或 Tool / Network 失敗重試，最多 3 次，每次等待稍微更久。第三次失敗後，就不再重試，改進入 Recovery 決策。

注意

沒有 Retry Limit，失敗的步驟可能無限循環、浪費力氣，並掩蓋真正的問題。請一定設定上限，並決定達到上限後要做什麼。
自我檢測

Retry Policy 為什麼需要 Retry Limit？

Retry Policy 為什麼需要 Retry Limit？

重點: Retry Policy 說明哪些失敗可以重試、重試幾次，以及採用什麼等待模式。

9 分鐘

Retry 不一定安全

重試讀取通常無害。重試會改變外部世界的動作，則可能把改變重複一次。如果第一次其實成功了，只是確認訊息遺失，重試就會把事情做兩次。

以下動作之後不要盲目 Retry
動作盲目 Retry 可能造成
付款提交同一筆款項被付了兩次
破壞性檔案動作第二次刪除移除了其他東西，或以令人困惑的方式失敗
外部通知收件人收到重複的訊息
不可逆交易無法復原的變更被重複執行

資訊

連結單元 3：Idempotent 的步驟執行兩次會得到相同結果，因此重試是安全的。對於不是 Idempotent 的步驟，在任何重試之前，請先檢查目前狀態、使用 Idempotency Key，或詢問人。
模擬範例

一個模擬 Agent 向客戶名單發送通知，呼叫卻逾時了。訊息有沒有送出去？不知道。安全的做法是先檢查送出了什麼，而不是再送一次。

自我檢測

提交付款的呼叫逾時，而且不確定是否已成功。最安全的下一步是什麼？

提交付款的呼叫逾時，而且不確定是否已成功。最安全的下一步是什麼？

重點: 只重試可以安全重複的事。付款、破壞性動作、通知或不可逆變更之後，請先確認狀態。

Recovery、Escalation、實作與成果

8 分鐘

Recovery Decision Model：Fallback、Re-plan 與 Compensation

當不能重試，或重試次數用完，系統依決策模型往下走。它依序問三個問題。

Recovery Decision Model
  1. 發生 Failure
  2. 可以 Retry 嗎？若可以，套用 Retry Policy
  3. 若不行，有替代路徑嗎？若有，使用 Fallback 或 Re-plan
  4. 若沒有，人可以解決嗎？若可以，Escalate
  5. 若不行，Stop Safely

資訊

圖示的文字版：從 Failure 開始，先問是否可以 Retry。若可以，依 Retry Policy 處理。若不行，問是否有替代路徑。若有，使用 Fallback 或 Re-plan。若沒有，問人是否能解決。若可以，Escalate。若不行，Stop Safely。
Recovery 概念
概念白話意思
Fallback為了同一個目標，改用更簡單或更安全的替代方法
Re-plan因為原本的做法行不通，所以改變計畫本身
Compensation用來抵銷先前已完成步驟的動作，例如無法復原時發出更正

資訊

僅為範例，並非必修：LangGraph 這類 Stateful 框架，可以把 Recovery 表達為感知 State 的 Resume 或替代的 Transition。上述概念適用於任何框架。
自我檢測

Retry Limit 已經用完，而且存在一個較簡單的備用方法。決策模型怎麼說？

Retry Limit 已經用完，而且存在一個較簡單的備用方法。決策模型怎麼說？

重點: 依序問：Retry、替代路徑、人、Safe Stop。Compensation 用來抵銷無法復原的已完成步驟。

8 分鐘

Escalation 與 Safe Stop

Escalation 是把問題交給能做決定的人。Safe Stop 是讓這次執行結束在清楚且不再造成傷害的狀態。兩者都是正確的結果，並不丟臉。能夠安全停止的系統，比總是硬撐下去的系統更值得信任。

Escalation 與 Safe Stop 的比較
結果適用時機必須包含
Escalate人可以解決問題，例如核准權限或補上缺漏資料什麼失敗了、試過什麼、目前狀態，以及對這個人的明確問題
Safe Stop沒有替代方案，且目前沒有人能幫忙，或繼續下去有傷害風險穩定的結束狀態、停在哪裡的紀錄，且不留下被隱藏的半完成變更
模擬範例

一個模擬 Agent 遇到 Safety / Policy 失敗：草稿會含有個人資料。沒有能保留這些資料的 Fallback。系統停止該步驟、保存 State，並告訴負責人原因，而不是試圖繞過規則。

注意

Human、AI、Human：遇到 Safety / Policy 失敗或 Human Rejection，Agent 不得繞過該決定去重試。規則是人定的、決定是人做的，責任仍在人。
自我檢測

審查者拒絕了 Agent 的輸出。Harness 應該怎麼做？

審查者拒絕了 Agent 的輸出。Harness 應該怎麼做？

重點: 帶著清楚摘要 Escalate，或在清楚狀態下 Safe Stop。兩者都不代表設計失敗。

8 分鐘

活動 5：Retry, Recover, Escalate or Stop? 與 Failure & Recovery Policy

選一個模擬的 Agentic Workflow，或用你在前面單元設計的那個。列出它可能失敗的方式、為每個失敗分類，再設計對應的處理。

  1. 列出失敗
    寫下你的 Workflow 中 6 到 8 件可能出錯的事。
  2. 逐一分類
    為每一項從 Failure Taxonomy 挑選一個類型。
  3. 設計 Retry
    對可重試的失敗設定 Retry Limit 與等待模式，並標出不適合重試的步驟。
  4. 加入 Fallback 與 Escalation
    有替代路徑就寫出來，並說明必須由人解決時要詢問誰。
  5. 定義停止條件
    說明何時 Safe Stop，以及它必須留下什麼狀態。

注意

隱私提醒：請使用模擬或已公開的資訊。請勿輸入公司機密、客戶個人資料或未經授權的敏感資訊。

資訊

成果：Failure & Recovery Policy。它列出每個失敗的類型、Retry Policy、Fallback、Escalation 與停止條件。請保留，用於你的 Agent Harness & Reliability Canvas。
  • 前往 AI 302 實作：在「Retry, Recover, Escalate or Stop?」活動中，分類失敗並設計處理方式。
  • 繼續前往單元 6：下一步：Context 不斷增長時，Agent 如何持續工作？
自我檢測

你的 Policy 有一列是寄信給客戶的步驟。這一列對 Retry 必須怎麼寫？

你的 Policy 有一列是寄信給客戶的步驟。這一列對 Retry 必須怎麼寫？

重點: 為每個失敗分類，只在安全處設定 Retry Limit，加入 Fallback 與 Escalation，並定義 Safe Stop。

另存 PDF

接下來做什麼？