Dify Workflow 实战手册：10 个常用模式

Pattern 1：知识库回退（Fallback）#

问题：Top-1 检索分数低于阈值时不要硬答。

做法：「知识检索 → 条件分支」，分数 < 0.5 时返回 "未找到相关信息，已转人工"。

Pattern 2：长会话压缩#

问题：上下文长，token 成本爆炸。

做法：「上下文获取 → LLM 摘要节点 → 把摘要替换原 history」。压缩比一般 5-10x。

Pattern 3：意图识别 + 路由#

问题：售前 / 售后 / 投诉混在一个 Bot 里效果差。

做法：开头先用 LLM 做意图分类（输出 enum），按结果路由到不同分支。

Pattern 4：工具调用并发#

问题：要同时查订单 + 物流 + 优惠券，串行慢。

做法：用「迭代」或「并行」节点同时调用三个 HTTP，等三个都返回再汇总。

Pattern 5：错误重试#

问题：HTTP 工具偶尔 500。

做法：HTTP 节点设置「重试 3 次，指数退避」+ 失败兜底分支返回降级答案。

Pattern 6：限流保护#

问题：促销日访问量爆，下游 ERP 被打爆。

做法：在 Workflow 开头加「频率限制」节点（按 user_id），超过 N 次/分钟直接转排队。

Pattern 7：金额二次确认#

问题：用户问退款金额，AI 不能直接算，必须从订单系统读。

做法：

1. HTTP(订单 API) → 取订单金额
2. LLM → 用「订单金额变量」生成回复
3. Prompt 加：「金额必须使用 `{{order_amount}}`，禁止改写」

Pattern 8：人工 fallback#

问题：AI 答不出 → 不能尴尬卡住。

做法：失败分支调用 Chatwoot API 创建工单 + 把上下文写入备注。

Pattern 9：多轮表单收集#

问题：要收集姓名、邮箱、问题描述，但用户不会一次都给。

做法：用 Conversation App 类型，每轮检查变量是否齐全，缺什么问什么。

Pattern 10：A/B 测试 Prompt#

问题：不知道改 Prompt 是不是真的提升了效果。

做法：用「变量随机分配」节点把 50% 流量走老 Prompt、50% 走新 Prompt，记录 user_id 标签，事后对比 CSAT。

通用经验#

• Workflow 节点尽量原子化，方便单独调试
• 关键变量在「开始」节点声明（不要散落各处）
• 给每个 LLM 节点设独立的 temperature（生成 vs 分类不同）
• 用 Dify 的「调试」面板逐步执行——比看完整日志快