一、引言：RPA 智能回復的定位

傳統的 API 智能回復（參考主題 4）依賴于企業微信的 Webhook 回調機制，具有速度快、延遲低的優點。

但 RPA 智能回復作為輔助或替代方案，主要用于解決 API 無法觸及的場景：

1. 非 API 場景： 針對沒有開放 API 接口的群類型或功能。
2. 視覺判斷： 需要對圖片、驗證碼或彈窗進行判斷后才能回復（參考主題 5）。
3. UI 復雜交互： 回復內容需要通過復雜的 UI 路徑才能發送（例如，發送特定的截圖或錄屏）。

RPA 智能回復的核心邏輯是： 監聽（Look） $\rightarrow$ 判斷（Decide） $\rightarrow$ 模擬（Act）。

二、核心邏輯一：實時消息流的“監聽”與捕獲

RPA 無法像 API 那樣接收 Webhook 推送，它必須主動去“看”客戶端。

2.1 捕獲新消息的策略

2.2 提取消息內容

一旦檢測到新消息，RPA 必須進入目標群聊，并提取消息的文本內容、發送人和時間戳。

• 定位： 找到最新一條消息的 UI 元素。
• 提取： 使用元素定位符（XPath/ID）獲取其文本內容。
• 去重/排序： RPA 必須記錄上一次處理的最后一條消息的時間戳或內容，以避免對同一條消息進行重復回復。

三、核心邏輯二：智能“判斷”與匹配系統

提取到消息文本后，流程進入判斷模塊，這是智能回復的關鍵。

3.1 關鍵詞匹配與分類

1. 關鍵詞庫： 維護一個結構化的關鍵詞庫，包含關鍵詞、優先級和對應的回復動作。
   • 示例： {"關鍵詞": "價格", "優先級": 1, "回復動作": "發送鏈接卡片 A"}
2. 匹配算法： 使用正則表達或模糊匹配算法來處理用戶的多種表達方式（例如：“多少錢”和“價格”都應匹配到“價格”關鍵詞）。

3.2 意圖識別（高階應用）

對于更復雜的場景，RPA 可以集成本地或云端的 AI 意圖識別服務：

1. API 調用： RPA 將客戶的提問文本通過內部 API 發送給意圖識別模型。
2. 返回意圖： 模型返回客戶的意圖標簽（如 “查詢售后服務” 或 “咨詢產品 A”）。
3. 觸發回復： RPA 根據返回的意圖標簽，觸發相應的回復動作。

3.3 狀態與上下文判斷

在回復前，流程必須判斷當前的上下文狀態，避免不合時宜的回復：

• 判斷發送人： 避免回復給內部員工，只回復外部聯系人。
• 冷卻時間檢查： 檢查該群是否在最近的冷卻期內（例如 10 秒內已回復過），防止機器人刷屏。

四、核心邏輯三：模擬“回復”與操作執行

一旦確定了回復內容和動作，RPA 就開始模擬用戶的操作。

4.1 文本回復的模擬

1. 定位輸入框： 找到群聊底部的消息輸入框。
2. 模擬輸入： 使用鍵盤模擬操作，將準備好的文本內容輸入進去。為了防止被風控（參考主題 38），應在字符間加入微小的隨機延遲。
3. 發送： 定位并模擬點擊“發送”按鈕。

4.2 富媒體（圖片/文件）回復的模擬

RPA 可以模擬發送 API 無法直接處理的本地圖片或文件：

1. 點擊附件按鈕： 模擬點擊“發送文件”或“發送圖片”圖標。
2. 處理系統彈窗： 流程切換到 Windows/Mac 的文件選擇系統彈窗，輸入本地文件的絕對路徑。
3. 確認發送： 模擬點擊“打開”或“確定”完成文件上傳和發送。

五、總結與風險控制

• 核心挑戰： RPA 智能回復最大的瓶頸在于實時性和資源消耗。頻繁的輪詢會占用大量 CPU。
• 實踐建議： RPA 應專注于處理高價值、API 無法解決的復雜交互（如處理驗證碼、特定 UI 彈窗）。對于簡單的關鍵詞文本回復，應優先使用 API Webhook 方案，以確保效率和穩定性。