面试目标：能白板画出至少 3 种工作流模式，并且讲清楚每种模式适合什么场景。
1. 先搞清楚：Dify 的几种应用类型
打开你的 Dify 后台，创建应用时你会看到三种类型：
| 类型 | 说明 | 面试价值 |
|---|---|---|
| 对话型 | 聊天机器人，一问一答 | 低 |
| 文本生成型 | 输入→输出，单次处理 | 中 |
| 工作流型 | 多步骤编排，有分支有循环 | 高 |
面试必问：“工作流和 Agent 有什么区别？”
工作流是确定性的，每一步固定；Agent 是自主性的，自己决定调用什么工具。面试时把这点讲清楚，面试官就会觉得你有深度。
2. 核心节点一览（面试重点）
打开工作流编辑器，左边就是节点面板。这 7 种是你必须掌握的：
| 节点 | 作用 | 面试话术 |
|---|---|---|
| LLM | 调用大模型 | 最基本的，没它不行 |
| 知识检索 | 从知识库里搜 | RAG 的核心 |
| 代码执行 | 跑 Python/JS 代码 | 补足 LLM 的计算短板 |
| HTTP 请求 | 调第三方 API | 打通外部系统 |
| 条件分支 | if/else 逻辑 | 工作流的大脑 |
| 迭代 | 循环处理列表 | 批量处理 |
| 变量聚合 | 合并多路输出 | 并联节点的汇合点 |
| 模板转换 | 转换数据格式 | 数据清洗/重组 |
面试加分：“Dify 的工作流是DAG（有向无环图），所以天然支持并行执行——你可以让知识检索、LLM、HTTP 请求同时跑，最后用变量聚合节点汇总结果。”
3. 动手：3 个实战工作流
你现在就打开 Dify 后台自己搭，我当你的架构师。
🏗️ 实战 1：智能客服 RAG 问答
用户输入 ↓ ┌─────────────┐ │ 知识检索 │ ← 从知识库里搜相关文档 └──────┬──────┘ ↓ ┌─────────────┐ │ LLM 生成 │ ← 结合检索结果 + 用户问题生成回答 └─────────────┘ ↓ 输出面试点：“这个架构解决了 LLM 的幻觉和时效性问题，把知识源和推理过程分离。”
🏗️ 实战 2：内容审核 + 自动回复
用户输入 ↓ ┌─────────────┐ │ LLM 审核 │ ← 判断内容是否合规 └──────┬──────┘ ↓ 条件分支 ├── 违规 → 拒绝回复 + 记录 └── 正常 → ┌─────────────┐ │ LLM 回复 │ └─────────────┘面试点：“条件分支让工作流有了决策能力，这在需要内容安全审核的场景下非常关键。工作流的优势就在这里——每一圈处理都可以被审计和优化。”
🏗️ 实战 3：多工具 Agent（高阶）
用户输入 ↓ ┌─────────────┐ │ 意图识别 │ ← 小模型判断用户想干嘛 └──────┬──────┘ ↓ 条件分支（路由） ├── 查天气 → HTTP 请求（天气 API） ├── 写代码 → 代码执行（Python） └── 一般问答 → LLM 直接回复 ↓ 变量聚合 → 输出面试核弹：“这个架构其实就是 Agent 的雏形。Dify Agent 的底层就是多轮工作流——每轮 Agent 调用相当于在工作流里跑一次工具选择-执行-结果回传的循环。”
4. 变量的作用域（高频考点）
工作流里最坑人也最常考的就是变量作用域：
| 变量类型 | 作用范围 | 示例 |
|---|---|---|
| 系统变量 | 整个会话 | sys.query,sys.dialogue_count |
| 节点变量 | 只在自身节点 | 某个 LLM 的输出 |
| 环境变量 | 整个 App | API Key、配置参数 |
| 会话变量 | 整个对话周期 | 用户名、上下文 |
面试话术：“变量作用域的设计直接决定了工作流的可维护性。我在项目里设定了一个原则：环境变量管配置、会话变量管状态、节点变量管数据流。三层不混用，排查问题的时候直接定位到层。”
5. 课后任务
打开 Dify 后台，搭实战 1（RAG 问答）：
- 创建一个工作流类型应用
- 拖一个知识检索节点（需要先建个知识库，丢一个文本进去）
- 再接个LLM节点，提示词里引用
{{节点名.result}} - 运行测试
下节课预告：第3课：RAG 知识库与检索策略— 这也是面试里问得最多的方向之一
