昨天寫 Agent Ready 時，我把最後一個檢查項目放在：

Recovery。

但寫完後我發現，這件事其實值得單獨講一篇。

因為我們看 AI Agent Demo 時，通常看到的都是：

User 提出需求
      ↓
Agent 理解
      ↓
呼叫 Tool
      ↓
Task 完成

非常順。

但真正做過產品就知道：

現實世界很少這麼配合。

API 可能 Timeout。

資料可能缺一欄。

第三方服務可能掛掉。

第一個 Action 成功，第二個失敗。

甚至 Agent 做到一半，User 突然說：

「等等，我不要了。」

這時候真正困難的問題才出現：

Agent 做到一半失敗，System 現在到底在哪個 State？

Chatbot 回答錯，跟 Agent 做錯，是兩種不同的 Failure

如果 Chatbot 回答得不好，最常見的結果是：

User 覺得答案不好，再問一次。

但 Agent 不一樣。

因為它可能已經改變真實世界的 State。

假設 User 說：

「幫我安排下週出差。」

Agent 要做：

建立出差申請
      ↓
預訂交通
      ↓
預訂住宿
      ↓
更新行程
      ↓
寄出通知

如果第三步失敗，

前面兩步可能已經真的執行了。

這時候不能只回：

「抱歉，發生錯誤，請稍後再試。」

因為問題不是 Conversation 失敗。

而是：

System 已經進入一個「完成一半」的狀態。

第一件事：先定義 Failure State

以前畫 User Flow，我很習慣畫：

Success
Error

但 Agent Task 往往不是這麼二元。

一個 Multi-step Task 可能出現：

Not Started
    ↓
In Progress
    ↓
Partially Completed
   ↙ ↘
Failed Completed

其中最麻煩的其實是：

Partially Completed。

例如退款 Agent：

✓ 建立退款申請
✓ 更新訂單狀態
✗ Payment API 退款失敗

到底算成功還是失敗？

答案是：

都不是。

它是一個需要被處理的 Intermediate State。

所以 PM 在設計 Agent 時，不能只寫 Happy Path。

還要先問：

Task 可能停在哪些中間狀態？

第二件事：失敗後，到底是 Retry、Rollback，還是 Stop？

不是每個 Error 都應該用同一種方式處理。

我會先把 Recovery 拆成四種：

① Retry｜再試一次

適合暫時性的問題：

API Timeout
Network Error
Service Busy

如果 Action 本身安全，而且重試不會產生副作用，可以 Retry。

但這裡有一個重要問題：

同一個 Action 執行兩次會怎樣？

例如：

send_email()

Retry 一次，User 可能只是收到兩封信。

但如果是：

create_payment()

Retry 就可能變成扣兩次錢。

所以「可以 Retry」本身也是 Product / System Design 的一部分。

② Rollback｜把已經做的事情還原

假設：

建立 Booking ✓
付款 ✗

產品可能選擇取消前面已建立的 Booking。

讓 System 回到執行前的狀態。

但 Rollback 並不是永遠做得到。

寄出去的 Email 收不回來。

已經送出的外部申請可能不能直接撤銷。

所以 PM 需要知道：

哪些 Action 是 Reversible？哪些不是？

這其實會直接影響 Agent 能不能自動執行。

③ Stop｜停在安全的位置

有些時候最好的 Recovery 不是硬做完。

而是：

不要再繼續。

例如 Agent 發現：

資料互相矛盾
Permission 不足
下一步可能造成高風險操作

這時候應該保留目前 State，清楚告訴 User：

完成了什麼
哪一步失敗
什麼還沒執行

而不是為了提高 Task Completion Rate，繼續猜。

④ Escalate｜交給人處理

有些 Failure，AI 自己根本不適合 Recovery。

例如：

退款已建立，但金流狀態異常。

這時候與其讓 Agent 不斷 Retry，不如：

保存 Context
      ↓
建立 Case
      ↓
轉給人工
      ↓
Human 從目前 State 接手

真正好的 Escalation 不是：

「請聯絡客服。」

然後讓 User 從頭講一次。

而是把：

Task、History、Current State、Error、已執行 Action

一起交出去。

第三件事：Agent 必須知道「自己剛剛做過什麼」

這聽起來很基本，但其實非常重要。

如果 Agent 要 Recovery，它至少要知道：

Action 1：成功
Action 2：成功
Action 3：失敗
Action 4：尚未執行

也就是需要保留：

Execution State。

否則 Agent 重新啟動後，可能根本不知道：

「我剛才到底有沒有建立過那筆退款？」

然後再建立一次。

所以真正能執行 Multi-step Task 的 Agent，背後通常不能只有 Conversation History。

還需要一個可以追蹤 Task 的 State：

Task
↓
Plan
↓
Action
↓
Result
↓
Current State

對 PM 來說，這代表 PRD 不能只描述：

Agent 要做哪些事情。

還要描述：

System 怎麼知道事情做到哪裡。

第四件事：不要讓 User 猜現在發生什麼

Agent Failure 還有一個很容易被忽略的 UX 問題：

Status Visibility。

最糟的情況是 Agent 回：

「處理時發生一些問題。」

User 完全不知道：

到底什麼成功了？

有沒有扣款？

訂單建立了嗎？

我要重新操作嗎？

所以 Failure Message 至少應該回答：

✓ 已完成什麼？
✗ 哪一步失敗？
○ 哪些事情尚未執行？
→ 接下來可以怎麼做？

例如：

已建立退款申請，但退款交易尚未成功，因此目前沒有款項退回。

你可以稍後重試，或交由客服處理。

這比一句：

Something went wrong.

有用太多。

Recovery 其實也會反過來決定 Autonomy

昨天 Day 13 寫到：

Answer
↓
Guide
↓
Prepare
↓
Execute with Confirmation
↓
Autonomous

但一個 Agent 能不能往更高 Autonomy 走，我現在會多看一件事：

出了問題，我們收得回來嗎？

如果一個 Action：

容易發現錯誤
容易 Undo
State 清楚
Recovery 成熟

可以考慮給 Agent 更多自主權。

反過來，如果：

錯誤很難發現
不可逆
影響很大
失敗後不知道怎麼恢復

那就算 Model 很準，我也不會急著讓它 Autonomous。

所以 Autonomy 不只取決於：

AI 有多聰明。

還取決於：

System 有多能承受它失敗。

如果今天 Review Agent Failure，我會問這 5 題

1. State
失敗時，System 知道做到哪一步嗎？

2. Retry
這個 Action 可以安全重試嗎？

3. Rollback
已完成的 Action 可以還原嗎？

4. Escalation
AI 解不了時，誰來接手？

5. Visibility
User 知道現在到底發生什麼嗎？

最後可以變成一個 Recovery Flow：

Action Failed
     ↓
Can Retry Safely?
   ↙ ↘
 Yes No
 ↓ ↓
Retry Can Rollback?
           ↙ ↘
         Yes No
          ↓ ↓
      Rollback Stop
                   ↓
             Escalate to Human

Day 14｜好的 Agent，不是不會失敗，而是失敗後不會留下爛攤子

我們很容易用 Happy Path 判斷一個 Agent：

「你看，它真的可以自己完成！」

但真正從 Demo 走向 Production，我覺得更值得看的反而是：

它做不完的時候會發生什麼？

Task 有沒有 State。

Action 能不能安全 Retry。

做錯能不能 Rollback。

不能處理時能不能 Escalate。

User 能不能清楚知道現在發生什麼。

Product Principle

Agent 的可靠，不只是成功時把事情做完，而是失敗時仍然知道 System 在哪裡，以及下一步該怎麼辦。

以前做產品，我們會設計 Error State。

到了 Agent 時代，我覺得還要再往前一步：

不只設計 Error Message，而是設計 Recovery。