Rule Agent 入門與設定指南
這是一份關於 Rule Agent 使用方式的指南。您將透過這份文件了解 Rule Agent 適合解決哪些問題，並完成從建立、測試到啟用的第一個流程設定。Rule Agent 自動化可以取代並簡化現有的人工程序，例如新增標籤，以及將對話分配給最合適的客服。這能讓客服成員專注於處理目前的對話與任務，同時減少日常工作所耗費的時間。
首次使用時，請依照本文順序操作；需要了解特定節點時，請直接參閱《Rule Agent 節點參考》。
概覽：Rule Agent 是什麼
Rule Agent 是整合不同 Flow 的自動化處理 Agent，而 Flow 是一套圍繞真實對話持續執行的自動化流程能力。
它不是一條「命中後立即結束」的傳統自動化規則，而是一條可以：
- 由觸發器 Trigger 啟動
- 以對話為載體持續推進
- 在流程中多次判斷與分流
- 等待使用者行為或逾時
- 根據結果繼續執行後續步驟
您可以將它理解成一張可設定的對話流程圖：
當某個使用者或對話符合進入條件後，Flow 會從起點開始，依照節點逐步往下執行，直到達成目標或流程結束。
Flow 與傳統自動化規則的差異
| 比較項目 | 傳統自動化規則 | Flow |
|---|---|---|
| 執行方式 | 命中後立即執行一次 | 建立一條持續執行的流程 |
| 生命週期 | 短暫、即時 | 可跨越時間持續推進 |
| 分支能力 | 通常只判斷一次 | 可在多個節點持續分支 |
| 等待能力 | 較弱 | 支援等待回覆、等待點擊、等待逾時 |
| 測試能力 | 規則層級檢查 | 流程層級測試、路徑追蹤、結果回看 |
| 適用情境 | 新增標籤、變更狀態、發送通知 | 歡迎分流、逾時催回、滿意度回收、AI 備援、轉換實驗 |
選擇合適的情境
當您的業務無法透過「一次命中、一次執行」完成時，會更適合使用 Flow。
常見適用情境：
- 新訪客歡迎與分流
- 依照國家、來源或標籤採用不同的接待路徑
- 訪客未回覆或客服尚未接入時，自動催回或升級
- 對話結束後延遲發起滿意度回收
- 透過 A/B 分流測試不同文案或轉換路徑
- AI 接待異常時自動轉接人工，並補發說明訊息
- 需要在流程中呼叫外部系統、寫回變數或同步資料
開始之前：了解核心概念
Flow
Flow 是一條可編輯、可測試、可啟用與停用的自動化流程。
Trigger（觸發事件）
Trigger 是流程入口，決定：
- 在什麼情況下開始
- 誰可以進入
- 多久可以進入一次
Node（節點）
Node 是流程中的最小功能單位。
例如發送訊息、條件分支、等待回覆、分配客服、更新資料，都是節點。
Exit（出口）
Exit 是節點的輸出路徑。
不同節點可以有不同出口，例如：
- 預設繼續
- 條件分支
- 成功／失敗
- 已發生／逾時
- 按鈕分支／未點擊
Audience（受眾）
Audience 是受眾範圍，用來限制這條 Flow 面向哪些客戶或對話。
Goal（目標事件）
Goal 是目標事件，用來衡量這條 Flow 是否達成業務目標。
例如第一則訊息送達、獲得回覆、完成評價、實現轉換等。
建立並發布第一條 Flow
1. 選擇開始方式
您可以透過兩種方式開始：
- 從空白畫布新建
- 從情境範本開始
如果是第一次設定，建議優先選擇範本，再將範本中的參數替換成自己的業務內容。
2. 設定事件觸發
先確認這條 Flow 由什麼事件啟動。
常見入口包括：
- 訪客發送訊息
- 對話建立
- 指定事件發生
- 等待逾時
- AI 或系統事件
設定觸發器時，建議同時確認：
- 目標通道
- 目標受眾
進入條件：符合目前設定的任一事件，且通道與受眾皆為指定目標時
3. 編排流程節點
在畫布中依照業務順序建構節點。節點類型分為判斷與控制、訊息、動作三大類。點擊節點後，右側會開啟設定區域。
這裡可以填寫每個節點的參數、設定分支並查看摘要。
常見的建構方式：
- 由進入類節點定義入口
- 判斷與控制類節點決定路徑與節奏
- 訊息類節點負責對外觸達或收集回饋
- 動作類節點負責修改資料、分配客服、同步外部系統
4. 設定流程層級規則
除了節點本身之外，還需要設定流程層級資訊，例如：
- 流程名稱
- 啟用狀態
- 退出規則
- 去重設定
- 進入頻率
5. 測試 Flow
Flow 的測試能力非常重要。在正式發布之前，我們提供測試功能。選擇測試後，您可以在下方的對話視窗中模擬驗證事件如何觸發並執行 Flow；左側的模擬控制視窗提供條件選項，右側的對話視窗則可以查看執行結果。
建議在啟用前至少驗證以下內容：
- 觸發器是否能正確命中
- 條件分支是否依照預期執行
- 等待與逾時出口是否正確
- 文案、按鈕、連結是否正確
- 資料更新、分配與外部呼叫是否合理
6. 啟用並觀察結果
上線後建議持續關注：
- 是否有足夠的命中量
- 實際路徑是否符合預期
- 是否有節點經常失敗或被跳過
- 目標事件是否確實有所提升
7. 管理 Flow
列表頁是 Flow 的管理入口，適合用來：
- 查看所有 Flow
- 依狀態篩選
- 搜尋指定流程
- 從範本新建
- 設定執行模式：區分獨佔匹配與平行匹配模式。獨佔模式下，同一個進入事件只會進入排序最前且命中的流程；平行模式下，同一個事件可以進入多個命中的流程。
Flow 如何執行
從使用者的角度來看，一條 Flow 通常會依照以下順序執行：
- 某個觸發條件發生
- 系統判斷這個對話是否可以進入該 Flow
- Flow 從起始節點開始執行
- 過程中可能發送訊息、判斷條件、更新資料、呼叫外部系統
- 遇到等待節點時，流程會暫停
- 當等待的行為發生或逾時後，流程繼續往下執行
- 達成目標、執行至終點或命中結束路徑後，流程結束
理解這一點非常重要：
Flow 不是一次計算完所有邏輯，而是在真實對話情境中逐步推進。
最佳實務與限制
先設定目標，再配置流程
不要一開始就堆疊節點。
更穩妥的方式是先釐清：
- 這條 Flow 要解決什麼問題
- 希望使用者走到哪裡
- 哪些事件代表成功
先確定受眾與進入頻率
如果受眾範圍過廣、進入頻率過高，容易造成重複打擾。
建議優先確認：
- 哪些使用者可以進入
- 同一位使用者多久可以進入一次
- 同一個對話是否允許重複進入
為按鈕分支設定備援路徑
如果訊息節點使用分支按鈕，除了點擊後的路徑之外，還要考慮：
- 使用者不點擊怎麼辦
- 多久算作未點擊
- 未點擊後是結束、提醒，還是轉入其他路徑
等待節點必須考慮逾時
無論是等待回覆、等待點擊或等待事件，通常都建議設定逾時出口。
否則流程容易停在中途，無法繼續推進。
多通道能力可能有所不同
同一個 Flow 如果面向多個通道，不同通道的訊息能力可能不完全一致，例如：
- 附件類型不同
- Rich Media 顯示方式不同
- 按鈕互動能力不同
- 文案長度或檔案限制不同
因此在設定訊息節點時，應配合目標通道確認是否全部適用。
分配動作必須符合 Channel 規則
分配客服、分配團隊、分配 AI 時，需要符合系統原有的分配範圍與業務規則。
如果目標不在目前對話可分配的範圍內，流程可能無法依照預期完成承接。
區分 Webhook 與 API 呼叫
- Webhook 更適合將目前的事件或流程資訊推送給外部系統
- API 呼叫更適合向外部系統取得資料，再將結果用於後續判斷
不要混用這兩類節點。
上線前優先測試 4 類路徑
- 預設主要路徑
- 失敗路徑
- 逾時路徑
- 使用者未操作路徑
排查與常見問題
為什麼 Flow 沒有觸發？
優先檢查：
- 觸發事件是否確實發生
- 目前使用者是否屬於目標受眾
- 通道是否在範圍內
- 進入頻率是否阻擋了重複進入
- 是否受到其他 Flow 的治理規則攔截
為什麼執行了另一條分支？
通常是因為：
- 目前對話屬性與您的預期不一致
- 條件順序不同
- 命中了備援分支
- 外部結果或變數值與測試預期不同
按鈕未點擊會怎樣？
如果訊息節點設定了「未點擊」時間範圍，逾時後流程會依照未點擊路徑繼續執行。
一條 Flow 可以跨越很長時間執行嗎？
可以，但流程越長，越需要重視：
- 進入頻率
- 逾時設定
- 目標事件
- 與其他 Flow 的衝突治理
什麼時候應該拆成兩條 Flow？
當兩個業務目標不同、面向的族群不同、治理規則不同，或需要明顯不同的流程節奏時，通常更適合拆開。
什麼時候不建議將所有邏輯塞進一條 Flow？
如果一條 Flow 同時承擔歡迎、轉換、售後、滿意度回收等多個目標，通常會讓後續維護與測試變得更加複雜。
建議圍繞單一業務目標建構流程。
