如何利用 Dify 的条件分支节点实现多级意图识别的自动化工作流

直接把所有意图识别都塞进一个 LLM 节点，很容易导致模型在面对模糊指令时产生“幻觉”或者由于上下文太长而丢失精度。我在构建一个企业级客服助手时发现，最稳妥的方案是利用 Dify 的条件分支（Condition Node）构建一个类似决策树的过滤机制。

核心逻辑是：先用一个轻量级的 LLM 节点做“粗筛”，将意图分类为 A、B、C 三类，然后通过条件分支将流量导向不同的专业处理链路。

具体操作步骤：

1. 意图粗筛节点
创建一个 LLM 节点，Prompt 必须极其严苛，要求它只输出预定义的标签。

你是一个意图分发员。请分析用户输入，仅从以下标签中选择一个输出：
- [BILLING]: 涉及账单、支付、退款
- [TECH]: 涉及 Bug、API 调用、配置问题
- [GENERAL]: 闲聊或不明确的请求
禁止输出任何解释，只输出标签。

2. 配置条件分支（Condition Node）
在粗筛节点之后接一个条件分支节点。配置规则如下：
- 变量： 选择上一个 LLM 节点的 text 输出
- 操作符： 包含 (Contains)
- 值： [BILLING] → 连线至“账单处理工作流”
- 操作符： 包含 (Contains)
- 值： [TECH] → 连线至“技术文档检索工作流”
- 默认分支 (Else)： → 连线至“通用回复节点”

3. 多级嵌套实现精细化
如果 [TECH] 内部还分“前端”和“后端”，就在该分支后再接一个同样的【LLM 粗筛 → 条件分支】组合。这种级联结构能显著降低单个节点的 Token 压力，且每一步的 Prompt 都可以针对性优化。

踩过的坑与避雷指南：

- 空值崩溃： 如果 LLM 因为某些原因输出了空字符串或没按格式输出，条件分支会直接走 Else 路径。建议在粗筛 Prompt 里加上 如果无法判断，请强制输出 [GENERAL]。
- 标签冲突： 尽量不要用太短的词作为标签（比如用 "Pay" 而不是 "[BILLING]"），因为用户输入中可能刚好包含这个词，导致条件分支误判。建议使用带方括号的唯一标识符。
- 性能损耗： 每多一级分支就多一次 LLM 调用，响应延迟会增加。对于简单的意图，建议在第一个节点用 JSON 格式一次性输出所有层级的标签，然后通过多个条件分支并行判断，而不是串行嵌套。

效率提升点：
这种结构最大的好处是方便 Debug。当用户反馈识别错误时，我可以一眼看出是在哪个分支节点分错了，直接修改该层级的 Prompt 即可，不需要为了修复一个小问题而重写整个巨大的 System Prompt。