Flow 的三种触发入口：从 Topic、从其他 Flow、从代码

触发 Flow 的三种途径

Flow 不是凭空出现的——必须有什么东西把对话从 RAG 单轮问答模式切换到多步 Flow 模式。PolyAI 提供了三种入口：

在知识话题（Topic）的 Actions 字段里配置 /Flow: <Flow名称>。当 RAG 系统匹配到这个话题时，自动触发 Flow。

话题：我想预订一个位子
Actions: /Flow: Restaurant Reservations

这是最简单也最推荐的触发方式——Topic 和 Flow 的关系一目了然，维护起来也容易。用户不需要说任何特定关键词，只要 RAG 匹配到话题，Flow 就自动启动。

Flow 不是独立的——一个 Flow 的某个步骤可以跳转到另一个 Flow。这使得 Flow 可以像函数调用一样组合：

主 Flow: "账户查询"
  Step: 收集账号号
  Step: 查 CRM API（Python 转场函数）
  Step: 路由 → 账户有余额 走"充值 Flow" → 账户不存在 走"注册 Flow" → 需要改地址 走"地址修改 Flow"

嵌套 Flow 之间可以传递上下文（比如主 Flow 收集的账号号，子 Flow 可以直接用），也可以各自独立运行。

在 Python 函数或 REST API 里，可以显式调用 conv.goto_flow("Flow 名称") 启动一个 Flow。这个入口适合：

Flow 触发后，对话的"控制权"从 RAG 系统转移到 Flow 引擎——接下来的对话由 Flow 的步骤驱动，RAG 只在步骤内辅助回答用户的杂项问题。

Flow 结束（End Step 或用户主动退出）后，控制权归还 RAG。此时用户可以继续问 FAQ，也可以触发另一个 Flow——Flow 和 RAG 在整个对话生命周期内是动态切换的，不是非此即彼。

真实生产场景里最常见的对话模式是：

这个无缝切换的体验是 PolyAI 比套壳聊天机器人自然得多的关键原因——用户不需要"显式切换模式"，对话是连续的。

如果话题明明配了 /Flow: XXX 但对话里 Flow 没有被触发，常见原因：