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 同时承担欢迎、转化、售后、满意度回收等多个目标，通常会让后续维护和测试都变复杂。
建议围绕单一业务目标搭建流程。