昨天我們為系統加上了 Retry 與 Fallback 機制，讓系統在遇到短暫錯誤時會自動重試。這聽起來很棒，但其實悄悄引入了一個嚴重的架構災難。

想像一下這個極端但常見的情境：

1. emini 成功完成摘要。
2. Notion 節點成功將摘要寫入資料庫。
3. 但是，最後的 Telegram Bot 節點因為網路瞬斷而發送失敗。
4. n8n 偵測到失敗，於是啟動 Workflow Retry。
5. 結果：Gemini 又花了一次 Token 重新摘要，Notion 又新增了一篇完全一模一樣的文章！

如果失敗三次，你的 Notion 裡就會出現四篇重複的垃圾筆記。這就是缺乏防護機制的重試災難。

要解決這個問題，我們必須引入後端工程中極為重要的一個概念：Idempotency

Idempotency 的意思是：無論你對系統執行一次操作，還是執行一萬次相同的操作，最終系統的狀態都會跟只執行一次一模一樣。

在我們的 AI 知識管家中，這代表我們不能依賴盲目的新增，而是要具備「如果不存在就新增，如果已經存在就覆蓋或略過」的能力。要達成這個目標，我們需要為每一份輸入資料配發一個 Unique Document ID。

這個防護機制發生在準備寫入 Notion 之前。系統必須先辨識資料的身分，再決定寫入動作
要讓 Workflow 具備冪等性，我們分為兩步實作：

Step 1：產生 Unique ID

• 進入你要儲存文章的 Notion 資料庫，新增一個型態為 Text 的欄位，命名為 Doc ID
• 在將資料送進 Notion 檢查之前，先用一個 Edit Fields 節點產生 ID：
  • Name：填入 document_id
  • Type：選擇 String
  • Value：切換為 Expression，填入原始網址變數（例如 {{ $json.url }} 或您存放網址的欄位）。

Step 2：搜尋歷史紀錄 (Notion - Get many 節點)
接上一個 Notion 節點，用來去資料庫翻找有沒有存過這篇文章。

• 在 filter 新增條件，尋找有沒有一樣的 ID
• 注意此節點要將 setting 的 Always output data 開啟，不然無法走下去。

Step 3：判斷是否存在 (IF 節點)

• 在 Get many 後方接上一個 IF 節點，判斷搜尋結果。
• 新增 condition 看前一個節點有沒有資料，有資料代表曾經有一樣的連結
• 若 True，代表資料已存在，在 True 分支接上一個 Telegram 節點，告訴使用者此連結已經摘要過。
• 若 False，就接回我們原本已經接好的 notion create 節點。

結構如上圖

這樣就成功建立了一條 Retry-safe AI Workflow。現在，無論網路多不穩定、系統觸發了多少次自動重試，這篇文章在你的 Notion 資料庫中永遠只會有一份。