Rule Agent 入門與設定指南

這是一份關於 Rule Agent 的使用指南。您將透過這份文件了解 Rule Agent 適合解決哪些問題，並完成從建立、測試到啟用的第一條流程設定。Rule Agent 自動化可以取代並簡化既有的人工流程，例如新增標籤以及將對話指派給最合適的客服。這讓客服成員能夠專注於當前的對話與任務，同時減少處理日常任務所花費的時間。

首次使用請依照本文順序操作；若需了解某個節點，可直接查閱《Rule Agent 節點參考》。

概覽：Rule Agent 是什麼

Rule Agent 是整合不同 Flow 的自動化處理 Agent，而 Flow 是一套圍繞真實對話持續運行的自動化流程能力。

它不是一條「命中後立即結束」的傳統自動化規則，而是一條可以：

• 由觸發器 Trigger 啟動
• 以對話為載體持續推進
• 在流程中多次判斷與分流
• 等待使用者行為或等待逾時
• 根據結果繼續執行後續步驟

您可以把它理解為一張可設定的對話流程圖：
當某位使用者或某段對話符合進入條件後，Flow 會從起點開始，依節點一步步向下執行，直到達成目標或流程結束。

Flow 與傳統自動化規則的差異

選擇合適的情境

當您的業務不是「一次命中、一次執行」就能完成時，就更適合使用 Flow。

常見適用情境：

• 新訪客歡迎與分流
• 依國家、來源或標籤走不同接待路徑
• 訪客未回覆或客服未接手時，自動催回或升級
• 對話結束後延遲發起滿意度回收
• 透過 A/B 分流測試不同文案或轉換路徑
• AI 接待異常時自動轉人工並補發說明訊息
• 需要在流程中呼叫外部系統、寫回變數或同步資料

開始之前：理解核心概念

Flow

Flow 是一條可編輯、可測試、可啟用或停用的自動化流程。

Trigger（觸發事件）

Trigger 是流程入口，決定：

• 何種情況下開始
• 誰可以進入
• 多久可以進入一次

Node（節點）

Node 是流程中的最小功能單元。
例如發送訊息、條件分支、等待回覆、指派客服、更新資料，都是節點。

Exit（出口）

Exit 是節點的輸出路徑。
不同節點可以有不同出口，例如：

• 預設繼續
• 條件分支
• 成功／失敗
• 已發生／逾時
• 按鈕分支／未點擊

Audience（受眾）

Audience 是受眾範圍，用來限制這條 Flow 面向哪些客戶或對話。

Goal（目標事件）

Goal 是目標事件，用來衡量這條 Flow 是否達成業務目標。
例如首條訊息送達、獲得回覆、完成評價、實現轉換等。

建立並發布第一條 Flow

1. 選擇開始方式

您可以用兩種方式開始：

• 從空白畫布新建

• 從情境範本開始

如果是第一次設定，建議優先選擇範本，再將範本中的參數替換為自己的業務內容。

2. 設定事件觸發

先明確這條 Flow 是由什麼事件啟動。

常見入口包括：

• 訪客發送訊息
• 對話建立
• 指定事件發生
• 等待逾時
• AI 或系統事件

設定觸發器時，建議同時確認：

• 目標渠道
• 目標受眾

進入條件：符合目前設定的任一事件，且渠道和受眾均為指定目標時。

3. 編排流程節點

在畫布中依照業務順序搭建節點。節點類型分為判斷與控制、訊息、行動三大類。點擊節點後，右側會開啟設定區域。
這裡是每個節點填寫參數、設定分支與查看摘要的位置。

常見搭建思路：

1. 進入類節點定義入口
2. 判斷與控制類節點決定路徑與節奏
3. 訊息類節點負責對外觸達或收集回饋
4. 行動類節點負責修改資料、指派客服、同步外部系統

4. 設定流程層級規則

除了節點本身外，還需要設定流程層級資訊，例如：

• 流程名稱
• 啟用狀態
• 結束規則
• 去重設定
• 進入頻率

5. 測試 Flow

Flow 的測試能力非常重要。在正式發布之前，我們提供測試功能。選擇測試後，您可以在下方的對話視窗中模擬驗證事件是如何觸發並執行 Flow 的流程；左側的模擬控制視窗提供條件選項，右側對話視窗則可查看執行結果。

建議在啟用前至少驗證以下內容：

• 觸發器是否能正確命中
• 條件分支是否依預期執行
• 等待與逾時出口是否正確
• 文案、按鈕、連結是否正確
• 資料更新、指派與外部呼叫是否合理

6. 啟用並觀察結果

上線後建議持續關注：

• 是否有足夠的命中量
• 實際路徑是否符合預期
• 是否有節點經常失敗或被跳過
• 目標事件是否真的有提升

7. 管理 Flow

列表頁是 Flow 的管理入口，適合用來：

• 查看全部 Flow
• 依狀態篩選
• 搜尋指定流程
• 從範本新建
• 設定運行模式：區分獨占匹配與並行匹配模式。獨占模式下，同一進入事件只會進入排序最前且命中的流程；並行模式下，同一事件可以進入多個命中的流程。

Flow 如何運行

從使用者視角來看，一條 Flow 通常會依照以下順序運行：

1. 某個觸發條件發生
2. 系統判斷這段對話是否可以進入該 Flow
3. Flow 從起始節點開始執行
4. 過程中可能發送訊息、判斷條件、更新資料、呼叫外部系統
5. 遇到等待節點時，流程會暫停
6. 當等待的行為發生或逾時後，流程繼續往下執行
7. 達成目標、走到終點或命中結束路徑後，流程結束

理解這一點很重要：
Flow 不是一次把所有邏輯計算完成，而是在真實對話的脈絡中逐步推進。

最佳實務與限制

先定義目標，再設定流程

不要先堆疊節點。
更穩妥的方式是先想清楚：

• 這條 Flow 要解決什麼問題
• 希望使用者走到哪裡
• 哪些事件代表成功

先確認受眾與進入頻率

如果受眾範圍過寬、進入頻率過高，容易造成重複打擾。
建議優先確認：

• 哪些使用者可以進入
• 同一使用者多久可進入一次
• 同一段對話是否允許重複進入

為按鈕分支設定兜底路徑

如果訊息節點使用分支按鈕，除了點擊後的路徑，還要考慮：

• 使用者不點擊怎麼辦
• 多久算未點擊
• 未點擊後是結束、提醒，還是轉入其他路徑

等待節點必須考慮逾時

無論是等待回覆、等待點擊還是等待事件，通常都建議設定逾時出口。
否則流程很容易停在中間，無法繼續推進。

多通道能力可能不同

同一條 Flow 若面向多個通道，不同通道的訊息能力可能不完全一致，例如：

• 附件類型不同
• 富媒體展示方式不同
• 按鈕互動能力不同
• 文案長度或檔案限制不同

因此在設定訊息節點時，要結合目標通道確認是否全部適用。

指派動作必須符合 Channel 規則

指派客服、指派團隊、指派 AI 時，需要符合系統原本的指派範圍與業務規則。
如果目標不在目前對話可指派範圍內，流程可能無法依預期完成承接。

區分 Webhook 與 API 呼叫

• Webhook 更適合將目前事件或流程資訊推送給外部系統
• API 呼叫更適合向外部系統取資料，再將結果用於後續判斷

不要混用這兩類節點。

上線前優先測試 4 類路徑

• 預設主路徑
• 失敗路徑
• 逾時路徑
• 使用者未操作路徑

排查與常見問題

為什麼 Flow 沒有觸發？

請優先檢查：

• 觸發事件是否真的發生
• 目前使用者是否屬於目標受眾
• 渠道是否在範圍內
• 進入頻率是否擋住了重複進入
• 是否被其他 Flow 的治理規則攔住

為什麼走了另一條分支？

通常是因為：

• 目前對話屬性與您預想的不一致
• 條件順序不同
• 命中了兜底分支
• 外部結果或變數值與測試預期不同

按鈕未點擊會怎樣？

如果訊息節點設定了「未點擊」時間視窗，逾時後流程會依未點擊路徑繼續。

一條 Flow 可以跨很長時間運行嗎？

可以，但流程越長，就越要重視：

• 進入頻率
• 逾時設定
• 目標事件
• 與其他 Flow 的衝突治理

什麼時候應該拆成兩條 Flow？

當兩個業務目標不同、面向族群不同、治理規則不同，或需要明顯不同的流程節奏時，通常更適合拆開。

什麼時候不建議把邏輯都塞進一條 Flow？

如果一條 Flow 同時承擔歡迎、轉換、售後、滿意度回收等多個目標，通常會讓後續維護與測試都變得更複雜。
建議圍繞單一業務目標來搭建流程。