延續前面幾天搭建的個人專屬AI Agent，今天我們要搞懂Dify工作流中的「容錯」機制：

• 學會設定失敗分支與備援（Fallback）：為LLM節點加上「失敗時重試」次數，並在失敗分支接上備援節點，讓模型出問題時自動換人接手。
• 實測架構衝突分析：輸入實際的開發情境，驗證Agent是否能結合知識庫規範與外部技術，準確找出潛在衝突。

核心操作與流程設計

1. 雙模型降級備援（Fallback）配置

• 主力節點 (LLM 4)：負責主要的綜合比對，設定「失敗時重試3次」
• 備援節點 (LLM_BACKUP)：接在主力節點的「失敗分支」後面。當主力節點重試耗盡仍未成功時，輸入問題會自動流轉到備援節點接手處理
• 輸出節點整合：在最後的「輸出」節點同時接收主力與備援的輸出變數，確保不論走哪條路徑，前端都能順利拿到答案

2. 架構審查提示詞設定
   在提示詞中為 Agent 定義兩項核心審查規則：

• RESTful 命名規範：檢查 API 路由是否夾帶動詞（如 bulk-update），並提供標準的名詞資源替代方案
• SQLAlchemy 2.0 遷移評估：針對版本不兼容的語法進行診斷，要求提供 future=True 的漸進過渡方式

今日成果驗收
我們輸入測試題目進行端到端執行：

測試題目：
我們團隊預計將後端系統的 ORM 從舊版升級至 SQLAlchemy 2.0，同時計劃新增一個批量更新訂單狀態的 API：POST /orders/bulk-update。請根據團隊內部開發規範與 SQLAlchemy 2.0 的技術變更，評估兩者的潛在衝突，並提供符合 RESTful 與漸進升級的具體落地建議。

在這次運行中，主力節點觸發重試失敗後，備援顧問節點順利接管並完成任務，輸出報告重點如下：

• 內部規範現況診斷：指出擬新增的路由 POST /orders/bulk-update 夾帶動詞，違反 RESTful 資源導向原則
• 外部技術特性分析：指出環境無法並存 1.4 與 2.0 版本，且 2.0 廢棄了舊版 bulk_update_mappings。建議在 1.4 啟用 future=True 與 SQLALCHEMY_WARN_20=1 消除相容性警告
• 落地建議與重構寫法：建議 API 路由改為 PATCH /orders；ORM 批次更新改寫為 2.0 原生推薦語法：

from sqlalchemy import update, bindparam

session.execute(
    update(Order)
    .where(Order.id == bindparam("id"))
    .values(status=bindparam("status")),
    [
        {"id": 101, "status": "shipped"},
        {"id": 108, "status": "canceled"}
    ]
)
session.commit()

今日學習心得
今天搞懂了Dify「重試」與「失敗分支」的操作邏輯。以前拉工作流總是一條線到底，只要單一節點連線異常流程就卡住；今天成功讓它在主力模型失敗時自動切換備援，讓個人專屬Agent在面對異常時更加穩定。