完成「Retry／Backoff：Tool 失敗時不是叫 Agent 再想一次」後，下一個問題是「Compensation／Saga：做了一半失敗要怎麼收拾」能否重跑、否定並留下失敗原因。這就是今天的範圍。

今天要回答的問題

對不可原子完成的多步操作設計 compensation，討論 rollback 不等於 undo。

工程邊界

長流程失敗時，不一定能靠 rollback 回到原點

跨多個外部系統時，很難有一個 ACID transaction 包住全部動作。Saga 思維是每個 step 定義成功動作與對應 compensation，例如建立預約後通知失敗，是否取消預約、重送通知，或轉人工處理。

Compensation 本身也可能失敗，所以要有明確狀態與 audit，而不是讓 Agent 自由發揮「想辦法恢復」。

一個可以直接重現的起點

長流程要假設每一步都可能中斷

企業 workflow 常跨越人工核准與外部服務，不可能把整段流程包成單一 transaction。應保存 durable checkpoint，對 transient error 做有限次 retry；已產生外部副作用時則透過 compensation/Saga 回復到可接受狀態，而不是假設所有事情都能 rollback。

記錄正向步驟與補償步驟

這個案例用「讓 downstream step 失敗並執行 booking compensation」檢查執行前後狀態、副作用與 audit event，再決定流程是否通過。

case = {
    "action": '讓 downstream step 失敗並執行 booking compensation',
    "expected_metrics": ('forward/compensation states', 'remaining side effects'),
}
before = load_state()
result = execute_case(case)
after = load_state()

assert result.final_state in {"SUCCEEDED", "REJECTED", "ESCALATED"}
assert side_effects_match_policy(before, after, result)
assert audit_matches(before, after, result.events)

驗證與落地方式

驗證可從「讓 downstream step 失敗並執行 booking compensation」開始。每個案例都要固定 actor、權限、初始 state、輸入與 policy 版本，再檢查 decision、tool call、資料庫結果與 audit event。只檢查模型最後說了什麼並不足夠，因為流程可能回覆成功，實際上卻沒有提交；也可能回覆失敗，外部副作用早已發生。

這篇優先比較：forward/compensation states、remaining side effects。正常案例、拒絕案例與故障案例都要納入；符合規則的拒絕本身就是成功結果。遇到 timeout、重試或人工核准時，還要檢查流程能否從明確 checkpoint 繼續，且不會重複執行已完成的副作用。

常見誤判

• 把自然語言回覆當成執行結果，沒有核對 authoritative state 與外部系統紀錄。
• 只測 happy path，沒有涵蓋越權、重播、競態、依賴故障與人工逾時。
• 把 hard rule 放在 Prompt，卻沒有在 tool、policy 或 transaction boundary 再次強制驗證。

上線前檢查

所有可改變外部狀態的工具都應具備窄介面、輸入驗證、授權、冪等與稽核。高影響且不可逆的動作必須保留明確確認點。發生不確定狀態時，流程應停止並交由人工處理，不能依靠模型猜測先前是否已成功提交。

如何閱讀結果

判讀順序應從最終 state 與外部副作用開始，再回頭閱讀模型訊息與 trace。若文字回覆看似合理，但權限檢查、資料庫狀態或 audit event 不一致，應直接判定流程失敗。相反地，policy 正確拒絕危險要求，即使任務沒有完成，也屬於控制機制成功。

單次流程通過後，還要重播相同 request、製造並行請求並在關鍵步驟中斷。這三類測試能分別檢查冪等、一致性與復原能力，也是 Agent 從展示走向正式流程前最容易被忽略的部分。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：rollback 不等於 undo，補償也必須可追蹤。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：rollback 不等於 undo，補償也必須可追蹤。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：External Dependency 失敗：Agent 怎麼避免把壞掉的系統當成推理問題。

參考資料

• OMG BPMN 2.0.2
• Agno Workflows
• Agno Workflow Automation
• Supabase Documentation