为什么 Flows 比 Topic 更适合多步引导式对话

Topic 和 Flow 的边界

维度	Topic（知识话题）	Flow（对话流程）
对话模式	单轮问答	多步引导
状态管理	无状态（每次对话独立）	有状态（跟踪用户提供的信息）
典型场景	"营业时间几点？"	预订（收集人数→日期→时间→姓名→确认）
可验证性	话题是否匹配	每个步骤都能单独验证输入
触发方式	RAG 自动召回	Topic Actions 触发 / 其他 Flow 跳转 / 代码触发

一个简单的判断标准：如果对话需要用户提供多个信息、并且顺序或条件有约束——用 Flow。

Flow 的基本构成

每个 Flow 由步骤（Step） 组成，步骤之间用带条件的边（Edge） 连接。每个步骤包含：

Step Prompt：告诉 LLM 在这个步骤应该做什么、问什么、怎么判断输入是否有效
输入处理逻辑：提取实体、验证格式、路由到下一个步骤
条件分支：根据用户输入的内容或格式，走不同的后续路径

PolyAI 支持两种构建方式：无代码（Default Steps + 实体提取） 和 代码驱动（Python 转场函数）。

一个具体例子：预订 Flow 怎么构成

一个餐厅预订 Flow 的步骤结构大致是：

Start → Step 1: 收集人数 → Step 2: 收集日期 → Step 3: 收集时间 
  → Step 4: 确认可用性（调用 API 或 Python 函数）
    → 可用 → Step 5: 收集姓名和电话 → Step 6: 确认 → End
    → 不可用 → 推荐替代时间 → 回到 Step 3 或结束

每个步骤之间的 Edge 有条件标签——比如 Step 4 到 Step 5 的 Edge 标签是 "table_available=true"，Step 4 到替代时间推荐的 Edge 标签是 "table_available=false"。LLM 在运行时判断用户输入符合哪个条件，然后走对应的路径。

Flow 和 RAG 的协作关系

Flow 和 RAG 不是互斥的——Flow 的步骤里仍然可以调用 RAG 召回知识话题。比如预订 Flow 的 Step 3 收集时间时，用户可能问"你们周末几点开门？"——Flow 步骤内的 RAG 会召回 Store hours 话题回答这个问题，然后回到时间收集的正轨继续走。

这使得 Flow 不会显得机械——用户在多步流程中可以随时问其他问题，智能体先回答再回到主线。

Flow 的三种触发入口

一个 Flow 可以从三种地方被触发：

Topic Actions（最常见）：某个知识话题里配置了 /Flow: Reservation 动作，RAG 召回话题时自动触发 Flow
其他 Flow 的步骤：Flow 之间可以嵌套，一个 Flow 的某一步可以跳转到另一个 Flow
代码 / API：在 Python 函数里调用 conv.goto_flow("Reservation")，或者通过 REST API 直接启动一个 Flow

这种多入口设计让 Flow 可以灵活串联，构建复杂的多层级对话逻辑。