在自動化爬蟲或批次資料抓取的情境中，許多初學者常遇到一個致命問題：每次排程執行，機器人都把系統上百筆資料重抓一遍。這不僅浪費伺服器資源、大幅拉長執行時間，還極易觸發目標網站的反爬蟲阻擋。

今天我們將以全球專利檢索系統 為實戰案例，介紹如何為 RPA 流程導入「歷史水位線比對（Watermark Deduplication）」與「首次執行動態保護（First-Run Throttle）」架構。
一、 架構設計思考：我們想解決什麼？
增量採集（Incremental Scraping）：
專利列表預設按公開日倒序排列（最新在最前）。當機器人由上往下檢查，只要遇到「先前已處理過的案號」，就代表後續全為舊資料，應立即觸發煞車（Break）結束迴圈。

冷啟動保護（Cold Start Throttle）：
在系統剛上線、完全沒有歷史紀錄的第一次執行時，若直接放行會抓取數百筆資料導致流程過長。因此設定「首跑只抓 10 筆建立基準水位線」，第二次起自動解除上限，由舊案號動態煞車接手。

輕量化狀態持久化（State Persistence）：
無需架設大型資料庫，採用輕量的純文字紀錄檔（processed_ids.txt），兼具可維護性與高效能。
二、 核心流程狀態機邏輯

[啟動流程]
   │
   ├─► 讀取 processed_ids.txt 
   │     ├─ 檔案不存在 / 0 筆 ──► 標記 isFirstRun = True (啟動10筆限流)
   │     └─ 檔案存在且有資料  ──► 標記 isFirstRun = False (全動態水位線模式)
   │
   ▼
[TIPONET 檢索並擷取清單表格]
   │
   ▼
[For Each Row 遍歷案件]
   │
   ├─► 案件案號是否存在於 historyIds？
   │     ├─ [YES] ──► 撞到水位線！觸發 Break 煞車結束迴圈 🛑
   │     └─ [NO]  ──► 進入詳細頁採集資料 ➔ 加入 historyIds ➔ 計數器 + 1
   │
   └─► 檢查是否達首跑上限：
         └─ (isFirstRun And newFetchedCount >= 10) ──► 達標煞車 🛑
   │
   ▼
[輸出分流 JSON & 更新寫回 processed_ids.txt]

三、 關鍵程式碼與邏輯解析

• 1. 歷史記憶庫載入與首跑狀態辨識
     在流程進入瀏覽器之前，先透過一行 LINQ 表達式安全載入歷史案號：
• 2. 雙重煞車控制核心（Break 機制）
     在 For Each Row in Data Table 迴圈內，我們結合正則表達式擷取標準專利公開號（如 TW\d+[A-Za-z]），並進行兩層防護判定：
     防護一：水位線煞車（避免重複處理）
     防護二：首跑動態限流（建立基礎水位線），10 筆建立基線因為我不想撈到歷史所有資料。
• 3. 持久化回寫更新
     迴圈結束後，使用 Write Text File 將不重複的案號集合持久化寫入硬碟：

結論:
加入水位線架構後，機器人徹底具備了「記憶力」：
首跑：冷靜採集 10 筆建立基線，不對目標網站造成衝擊。
日常巡邏：每次排程只抓自上次以來的全新專利，撞到舊案號即刻結束，單次執行時間從數分鐘壓縮至數秒鐘。