AI神功 KNOWLEDGE BASE
神兵利器:AI 工具实操·第 34 关 / 36 约 6 分钟

TOOLS / 8 BOOKS / 06 · ENGINE v1

Dify 可视化 AI 工作流

本册:DAG 工作流与 Agent 的边界

约 6 分钟·免费阅读·整理自 AI 现代必修课 · Dify 可视化 AI 工作流·来源精读 ↓·直接做题 ↓

30 SECONDS / 30 秒看懂

这一册只解决一件事:能用确定性 DAG 工作流解决的任务,不要交给自由 Agent 随机决策。

  • Workflow 控制权在人,Agent 控制权在模型
  • DAG 把任务拆成节点,连线决定顺序,变量池传递数据
  • 节点分治让每一步只做一件窄而确定的事

3 MINUTES / 3 分钟拆解

先看来源里的例子:PDF 本册核心例子(来源)

输入
多语种论文精读:识别语言→提取公式/表格→检索背景→翻译→术语检查→排版。

发生了什么

把六步塞进一个大 Prompt,注意力被分散,第 2 步偏了后面全错;拆成 DAG 六个节点,每步用最合适的模型或代码。

输出

来源结论:DAG 工作流把稳定性从约 60% 拉到 99%,且延迟、Token 成本可预测。

术语拆开

DAG
有向无环图,节点按依赖顺序执行。
Variable Pool
节点间传递输出变量的全局池。
Workflow vs Agent
人定流程 vs 模型自主决策。

为什么有效

来源引用 Anthropic《Building Effective Agents》:固定流程用工作流,开放目标才用 Agent;混用会让成本和稳定性失控。

结构长什么样

Start → 分类/分支 → 检索/翻译/校验节点 → 变量池 → 输出

为什么“6 步全塞进一个大 Prompt”比 DAG 更容易出错?

SOURCE READING / 来源精读

本册讲 Dify 的 DAG 工作流、节点分治、变量池与父子分段检索,以及 Workflow/Agent 的工程边界。

逐点读懂

  1. 固定流程用 DAG,避免自主路由跑偏
  2. 节点分治与变量池让流程可观测
  3. Workflow 与 Agent 是两种不同工程范式

怎么对应本关练习

先用 30 秒看懂抓四层结构,再读本册的‘顿悟时刻/原理/动手实验’,最后做课后自测;答案在下方。

例子在哪

本册的动手实验与课后自测都在原文;参考答案见本页下方。

DAG 工作流与 Agent 的边界

SOURCESPDF 本册(用户提供)

【第二辑:神兵利器篇 · 课题 06 / 08】AI 现代必修课 · 前沿工具深讲与动手实验讲义

利器06:可视化 AI 工作流编排——Dify 从零搭建多步确定性流水线理解“自主智能体(Agent)”与“确定性工作流(Workflow)”的工程边界:掌握 DAG 节点分治、变量池传递与父子分段检索核心知识参考:langgenius/dify (Open-Source LLM App Development Platform) 与 Anthropic: Workflows vs Agents Architecture

一、顿悟时刻:哦,原来为什么复杂任务不能只靠一个大 Prompt,而要用 DAG 工作

流分治!在学完前面的提示词工程和智能体原理后,很多同学会问一个极其深刻的问题:“既然现在的模型这么聪明,我为什么还要用 Dify(或 Coze 扣子)在画布上把节点连来连去?

我直接写一个 2,000 字的大 Prompt 让模型一口气干完不行吗?” 在 Anthropic 著名的工程综述《Building Effective Agents》中,给出了最透彻的答案。

我们先用 3 分钟看懂背后的工程逻辑。

真相一:“单次大锅饭 Prompt” vs “DAG(有向无环图)工位流水线”的准确率代差假设你想做一个“多语种学术论文精读器”:需要先识别输入语言 → 提取论文里的数学公式与实验表格 → 去本地知识库检索相关背景术语 → 翻译为中文 → 检查翻译中是否有术语不一致 → 输出排版好的 Markdown。

如果你把这 6 步全写进同一个 Prompt,相当于让同一个人在同一秒钟既当翻译、又当审校、又当图书管理员、又当排版工——注意力权重被严重分散,只要中间第 2 步稍微偏一点,后面全盘皆输!

而 Dify 工作流(Workflow)的本质是“有向无环图(DAG)流水线分治”:它把这 6 步拆成画布上 6 个首尾相连的独立节点(工位)。

1 号工位可以用极快的小模型只干“意图分类”;2 号工位专门执行“知识库检索”;3 号工位调用深度推理模型只干“核心翻译”;4 号工位用一段确定性的 Python 代码检查格式。

因为每个工位上的模型每次只专注干一件极窄、极确定的事,整体系统的稳定性和可控性直接从 60% 跃升至 99%!真相二:节点之间是怎么“交接工作”的?

揭秘工作流的“全局状态变量池(Variable Pool)” 很多初学者第一次打开 Dify 画布,看着满屏的连线发怵:“上游节点算出来的结果,下游节点怎么拿过来?

” 其实底层机制非常干净:Dify 在每次运行工作流时,都会在内存里创建一个“全局透明文件夹(Variable Pool)”。

每当上游某一个节点运行结束,它就会把自己的输出贴上名为 {{节点名.输出变量名}} 的标签放进这个文件夹里。

你在下游任何一个节点的提示词框里,只需要敲下键盘上的斜杠 / 或左花括号 {,就能弹出菜单直接点选前面任意节点的输出变量!

“连线决定谁先跑谁后跑,{{变量}}决定数据怎么往后传”——看懂这十二个字,你就通晓了所有可视化工作流平台的设计精髓!

架构模式确定性工作流(Workflow,如 Dify 画布) 自主智能体(Autonomous Agent,如 Claude Code) 控制权归属人类预定义路径(Code/Graph-Driven): 走哪几步、分支怎么跳转完全由画布连线锁死。

模型动态自主决策(Model-Driven):调什么工具、循环几次由大模型根据观察结果实时决定。核心优势与代价延迟可控、Token 成本固定、可预测性极高,适合流程固定的高频标准任务。

灵活性极强,能应对开放式未知难题,但耗时与 Token 消耗不可控。

二、核心操作深讲:Dify 部署、六大核心节点与“父子分段”知识库

1. Docker Compose 本地一键启动与跨容器模型挂载

你可以使用 Dify 官方云端版直接体验 , 也可以通过 Docker 在本地电脑 5 分钟启动开源社区版 (langgenius/dify): git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d # 启动后浏览器访问 http://localhost/install 初始化管理员账号

【跨容器通信核心要点】:在 Dify【设置 → 模型供应商】中,既可以填入 DeepSeek / OpenAI / Anthropic 的云

端 API Key,也可以挂载本机运行的 Ollama。

注意:由于 Dify 运行在 Docker 容器内,连接宿主机 11434 端口时绝不能填 http://127.0.0.1:11434 ( 这会指向容器自身 ), 必须填写宿主机网桥地址 http://host.docker.internal:11434!

2. 拼出 95% 应用的六大核心节点积木

  • 1 开始节点(Start)与应用类型选择:需要先分清 Chatflow(对话流,内置多轮对话 Memory 缓冲池, 适合交互式问答助手) 与 Workflow(工作流,单次无状态输入、批量结构化加工输出,适合自动化处理管线)。
  • 2 问题分类器(Question Classifier)与条件分支(IF/Else):利用轻量快速模型判断用戶输入意图(如分为“概念原理解析”、“代码排错”、“文献检索”三类),自动路由到不同的专属下游分支。
  • 3 知识检索节点(Knowledge Retrieval)与“父子分段”秘籍:在创建 Dify 知识库时,强烈建议开启 “父子分段(Parent-Child Chunking)” 模式——将子段设为 250〜300 字(用于高精度向量瞄准),将父段设为整节/整段 1200 字(命中子段后自动把整个父段完整抽出来喂给大模型),并开启混合检索(向量 + 全文检索)与 Rerank 重排序,彻底解决《内功05》讲到的“切太碎丢上下文、切太大搜不准”的两难困境!
  • 4 参数提取器(Parameter Extractor)与代码执行(Code):利用大模型从自然语言中提取结构化参数, 再交由隔离沙盒中的 Python3 / JavaScript 代码节点做 100% 确定性的清洗与数学运算。

三、动手实验(Hands-on Lab):亲手搭建一条“多步分流与自检”工作流

实验 1:搭建 5 节点《智能学习笔记结构化提炼与自测题生成流水线》

1. 在 Dify 中新建一个 Workflow(工作流) 应用,在开始节点定义一个长文本输入变量 raw_note。

2. 连接第 2 个节点 LLM(概念提炼工位):选用高速模型(如 DeepSeek-V4.1-Flash),输入 {{#start.raw_note#}},

只负责提炼出核心概念定义表。

3. 并联第 3 个节点 LLM(出题考官工位):选用深度推理模型(如 DeepSeek-V4-Pro / R1),输入同一份

{{#start.raw_note#}},专门负责设计 3 道反直觉自测思考题与解析。

4. 连接第 4 个节点模板转换(Template / Jinja2):将第 2 节点的概念表与第 3 节点的自测题拼接为一份排版整

洁的完整复习讲义,由结束节点输出。

5. 点击右上角运行按钮,点开每个节点的执行详情,亲眼观察数据是如何在全局状态变量池中一步步流转并并

行加速的!

四、课后自测习题与详细解析(5 关 50 分 · 检验你的工作流编排内功)

【课后自测题(请先独立思考作答,再对照下方解析)】

1. 第 1 题(工程范式取舍:Workflow vs Agent · 10 分):为什么当你的业务流程具有明确、固定的步骤

(例如“先提取网页正文 → 再总结核心论点 → 再翻译为双语对照”)时,使用 Dify 的 DAG 工作流 (Workflow)比让一个纯自主 Agent 自己决定怎么干更科学?

2. 第 2 题(Chatflow 与 Workflow 选型 · 10 分):你在 Dify 中准备创建两个项目:项目 A 是一个供订阅者

连续追问课程难点、需要记住前 5 轮上下文的伴学机器人;项目 B 是一个输入一篇英文长文本、直接输出结构化 JSON 摘要的后台接口。请问 A 和 B 分别应选择哪种应用类型?核心区别在哪?

3. 第 3 题(父子分段机制深度理解 · 10 分):在 Dify 知识库中开启“父子分段(Parent-Child Chunking)”

时,为什么说它实现了“小块精准瞄准,大块完整喂⻝”?请说明在检索阶段和生成阶段分别使用的是父段还是子段。

4. 第 4 题(代码节点 JSON 解析排错 · 10 分):在工作流中,上游 LLM 节点输出了一段 JSON 字符串,下游

紧跟着一个 Python 代码执行节点使用 json.loads(arg1) 解析它,结果偶发报错 JSONDecodeError,查看日志发现模型输出首尾带了 `json ... ` 标记。请问在 Dify 中有哪两种标准解决方案?

5. 第 5 题(长耗时工作流网关超时防护 · 10 分):当你通过 API 调用一个包含多个深度推理节点、总耗时达

50 秒的 Dify 工作流时,为什么请求体中的 response_mode 应该设置为 `"streaming" 而不是 "blocking"`?

PRACTICE / 本关练习 · 本地规则 + 覆盖检查

本册课后自测与实验

本地检查在你的浏览器里完成,不上传。覆盖检查需要先登录(免费注册),并把这段答案发送到服务器计算一次,算完即弃、不存档,需你点同意;只核对本关评分项覆盖的方向,不在评分项里的题目不会被检查。

0 字未保存

评分项

评分项加载中…

结构分 — / 50 分

查看参考答案与得分点 先自己写,再打开+

参考答案与解析

1. 第 1 题解析:因为固定流程任务不需要模型在“下一步该调哪个工具”上耗费额外的推理 Token 和试错轮

次。使用 DAG 工作流将步骤固化后,不仅消除了路由跑偏与死循环⻛险,还能让无依赖的分支节点并行执行(Parallel Execution),并针对不同难度工位分别指定最匹配的模型(快模型配简单工位、推理模型配核心工位),实现精度、速度与成本的最优解。(答出消除路由不确定性、支持并行与按工位选模型得 10 分)

2. 第 2 题解析:项目 A 应选择 Chatflow(对话流),项目 B 应选择 Workflow(工作流)。核心区别在于:只

有 Chatflow 内置了会话状态与多轮对话记忆缓冲池(Memory Window),支持根据历史对话改写当前查询;而 Workflow 是无状态的单次批处理管线。(准确区分有状态多轮记忆与无状态批处理得 10 分)

3. 第 3 题解析:在向量检索匹配阶段,系统使用的是颗粒度很细的【子段(Child Chunk,如 250 字)】,因为

短文本语义集中、向量不会被无关句子稀释,命中率极高;一旦某个子段被命中,在提取上下文喂给生成模型阶段,系统会自动通过指针将该子段所属的完整【父段(Parent Chunk,如 1200 字整节内容)】提取出来交给大模型,从而彻底避免断章取义!(准确答出检索用子段、召回生成用父段得 10 分)

4. 第 4 题解析:两种标准解法:1 开启 LLM 节点的 JSON Schema 结构化输出功能或改用专门的参数提取器

(Parameter Extractor) 节点,直接输出原生结构化对象;2 在 Python 代码节点内增加一行正则清洗兜底:先执行 `clean = re.sub(r"^``(?:json)?|``$", "", arg1.strip(), flags=re.M).strip() 剥离代码块外壳,再执行 json.loads(clean)`。(两种方案各 5 分)

5. 第 5 题解析:在 `"blocking"`(阻塞等待)模式下,HTTP 连接必须保持静默等待整整 50 秒直到最后一个

节点跑完才返回字节,极易触发反向代理(如 Nginx 或云网关)默认的 30/60 秒超时断开(504 Gateway Timeout);而设为 `"streaming"`(SSE 流式推送模式)后,每个节点完成时都会实时向客戶端推送事件流,既保持连接活跃永不超时,又能实时展示每个工位的执行进度。(答出防 504 网关超时与实时节点事件流得 10 分)

网页永久免费。完整 PDF 会按顺序发给留邮箱的读者,不转售、不群发广告。

留邮箱,获取完整 PDF ↗
← 上一关 下一关 →