第 19 周 · Day 5：Dify 上手——把第 13 周的客服 Agent 拖出来

对应手册任务：学习「Dify 上手：工作流编排、知识库、工具接入」，动手用 Dify 复刻第 13 周的「客服 + 知识库问答」Agent，对比与 LangGraph 实现的差异，当日产出「Dify 版 Agent」。本篇只解决一个问题：你 LangGraph 全家桶已经练成，为什么国内 JD 还要把 Dify 和它们并列写？因为它们考察的根本不是同一件事：框架考你会不会「造」，平台考你懂不懂「交付」。今天带着框架功力当尺子，量一遍 Dify 能吃什么活、吃不下什么活，明天选型决策树的地基就是这份测量结果。

今日目标

1. 说得清 Dify 是什么、它在 LLM 应用工具栈里和 LangChain/LangGraph 的定位差别
2. 用 docker compose 在本地起一套 Dify（或走官方云），把工作流编排、知识库、工具接入三件事各走一遍
3. 用 Dify 复刻第 13 周的客服 Agent，输出开发速度、可控性、可维护性、测试评估四维对比报告，特别是把 interrupt 审批流在 Dify 里的实现难度说清楚

概念讲解：为什么代码功力已成，还要回头看低代码

打开国内招聘软件，Agent 岗位的需求描述里有一组高频搭配：熟悉 LangChain/LangGraph 者优先，了解 Dify/Coze 者加分。两个「优先」不在一个层级上。前者筛的是深度开发能力，后者筛的是工具视野：你知不知道业界除了写代码还有另一种交付形态，以及它和代码的边界在哪。

第 7 周你遇到过同款问题。会 docker run 是功力，compose 是把功力变成交付效率；但你从来没把 compose 当容器原理的替代品来学。今天的关系一模一样：LangGraph 是你造 Agent 的功力，Dify 是把最常见的 Agent 管道产品化成一张拖拽画布。

低代码平台的本质，一句话：把某类应用里最高频的 80% 管道固化成节点，换来不开编辑器就能出应用。这个「固化」是双向刀。好消息是你带着框架功力看它，成本极低：画布上每个节点都能翻译回你写过的代码——问题分类器是一次结构化输出加路由，知识检索是 embedding 加向量库加 top-k，工具节点是函数调用，代码节点是沙箱里跑一段脚本。半天出师。坏消息是表达力上限从此锁死在那 80%：节点类型没提供的东西，你拼不出来，或者要用很难看的姿势拼。

所以今天的姿势不是「学一个新框架」，是「用一天时间给一个平台写鉴定报告」。面试官问「你们为什么选 Dify 不自建」或者反过来问，你答得出边界，这关才算过。

核心知识

本节的操作只写到路径级：进哪个页面、选哪个节点、配哪一项。界面细节以你部署版本的官方文档为准——低代码平台的 UI 迭代比框架 API 还快，记路径不记像素。

1. Dify 是什么：把 LLM 应用的常见管道产品化

Dify 是一个开源的 LLM 应用开发平台，可自部署，四个大件：

• 可视化编排：画布上拖节点、连线成流程，对话型应用叫 Chatflow，自动化执行一次的叫 Workflow
• 知识库：上传文档，平台内置切块、向量化、检索，第 14 周你手搓的那条 RAG 管道在这里变成一张表单
• 模型管理：各家模型供应商的 key 统一配置，OpenAI 兼容接口、本地 Ollama 都能接，应用里选模型像点菜
• 发布：画完的应用直接以 WebApp 对外，或包成 API 给自己的前端调

关键认知：Dify 不是「更好的 LangGraph」，它是 LangGraph 生态里最常见那批管道的产品化封装。关系类似 Jenkins 和 shell 脚本：前者把后者的高频用法固化成界面，永远不该也不会替代后者本身。

应用类型里今天选 Chatflow：多轮对话、可挂知识库和工具，正好对上第 13 周客服 Agent 的形态。

2. 本地部署：复用第 7 周的容器功力

官方仓库自带 docker 编排，四条命令：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

起来是一串服务：Nginx 入口、web 前端、api、worker、postgres、redis、向量库、沙箱。第 7 周练出的「看 compose 文件像看电路图」的本事直接复用：depends_on 谁依赖谁先看清楚，再决定机器吃不消时砍谁。默认从 Nginx 走本机 80 端口，浏览器首次访问会让你创建管理员账号。

不想装就上官方云，注册即用，今天的任务在云上一样能做完。两条路随便选，只有一条纪律：部署环节不超过 20 分钟，今天的重点是编排，不是运维。

一条血泪经验

清理环境用 docker compose down 就停手。手滑加 -v 会把数据卷一起删掉，知识库里传的文档、切好的向量、对话记录，说没就没。第 7 周讲卷的时候说过：卷里放的是「删容器也不该死」的数据，低代码平台的所有家当恰恰全在卷里。

3. 概念映射：第 13 周的每个零件在 Dify 里的对应物

复刻之前先列清单，这张映射表是今天的核心产出之一：

你学过的概念	当时的实现	Dify 里的对应	差别要点
Supervisor 意图路由（第 13 周）	LLM 结构化输出 + 条件边	问题分类器节点	同一件事：模型读问题、从预设类别里选一个、走对应分支
RAG 知识库（第 14 周）	手搓切块、embedding、检索	知识库 + 知识检索节点	切块和向量化收进表单默认值，检索参数仍要你自己调
查订单、退款工具	function calling	工具节点：HTTP 请求、自定义工具、内置工具	自定义工具按 OpenAPI schema 导入，新版本也支持直接挂 MCP Server，思想与第 18 周一致
退款审批 interrupt()	图中断 + 人工恢复	没有原生对应	下面单说，这是今天的重头
状态机 State	TypedDict + 边	会话变量	键值能存，但「图的拓扑」本身表达不出来

interrupt 这行必须说透，因为它是两个世界分野最清楚的地方。LangGraph 里 interrupt() 是一等公民：图走到退款节点前挂起，状态持久化，人工批准后从断点原样恢复，这条链路第 13 周你两天就做干净了。Dify 的 Chatflow 是「一次请求跑完」的 DAG，没有「走到一半挂起、等外部事件、再继续」这个语义。想在 Dify 里做审批，只有拆图：前段跑到「生成退款申请」就结束，把申请编号写进会话变量；审批结果作为下一轮用户消息进来，分类器加一个「审批结果回传」类别，走后段流程。能跑。但断点持久化、恢复的原子性、超时回收，LangGraph 白送的三样，这里全要靠变量和分支手工拼，流程一复杂就是用积木搭拱桥。

这不是 Dify 的缺陷，是产品化取舍：80% 的客服场景不需要审批链，需要审批的那 20%，本来就该回代码。

动手任务：Dify 版客服 Agent 一步一步

目标：第 13 周那个「意图路由 + 知识库问答 + 订单工具 + 退款审批」的客服 Agent，在 Dify 里拖出来，并留下对比证据。全程约 60 分钟，每步后面有截图位，产出记录时把截图贴上。

第 1 步：起服务、配模型。 按核心知识第 2 节起本地版或登官方云。进后台第一件事：设置里的「模型供应商」页配好至少一家的 key。这步不做，后面每个节点的模型下拉框都是空的。

[截图位：模型供应商配置页，至少一家显示可用]

第 2 步：建知识库。 顶栏「知识库」进创建，上传第 13 周用过的客服文档（退货政策、配送说明那几份）。平台自动切块、向量化，一路默认到检索设置页为止。记住默认的 top-k 和相似度阈值是多少，先别改——对比报告里要写「默认值是啥、你知不知道它意味着什么」。

[截图位：知识库详情页，文档处理完成后的分段数]

关键认知：第 14 周你调切块大小、overlap、检索策略花了整周时间；Dify 把这些收进高级设置。参数一个没少，只是从你的代码变成了平台的表单。RAG 该有的质量问题一个都不会消失，调试入口反而藏得更深。

第 3 步：建 Chatflow，画意图主干。 「工作室」创建应用，类型选 Chatflow。画布上已有开始节点，往后拖一个「问题分类器」接上。类别设四个：售前咨询、订单查询、退款申请、其他。每个类别拉一条分支线。

[截图位：分类器节点配置页，四个类别]

拖的时候心里过一遍映射表：这就是第 13 周的 Supervisor。类别列表是你当天的路由枚举，分支线是条件边，你手写的路由 prompt 被收进节点的高级设置里，照样能改。

第 4 步：售前分支挂知识检索。 售前咨询分支上拖「知识检索」节点，选中第 2 步的知识库；后面接一个 LLM 节点，提示词里引用检索结果变量，写明「依据知识库回答，答不上来直说」。

[截图位：LLM 节点提示词，检索变量插入的位置]

先试跑一个知识库问题（比如退货期限是多久），答对了再往下。这一步等于把第 14 周整周的手搓 RAG 压缩成两个节点加一段提示词。

第 5 步：订单分支接工具。 订单查询分支拖「HTTP 请求」节点，指向第 13 周写的查订单接口；接口早停了就随便指一个能返回 JSON 的测试端点，后面接 LLM 节点把结果组织成人话。有余力再开「工具」页看看自定义工具：按 OpenAPI schema 导入你自己的 API，新版本还能直接挂 MCP Server——第 18 周你手写的调用侧协议，平台替你包好了。

[截图位：HTTP 节点的 URL 与一次调用的返回示例]

第 6 步：退款分支，亲手撞一次审批墙。 按核心知识第 3 节的拆法做：退款分支先接 LLM 节点生成退款申请话术，把申请编号写进会话变量，结束；再给分类器加第五个类别「审批结果回传」，新分支里读会话变量、走后续流程。做完你会对 interrupt 的实现难度有体感——第 13 周两天做干净的断点、恢复、持久化，这里全靠变量拼装，而且你自己清楚哪里经不起并发。

[截图位：五个类别的分类器 + 会话变量列表]

第 7 步：发布与冒烟。 右上角发布成对话应用，三类典型问题各问一遍：知识库题、订单题、退款题，截图存证。这份跑起来的「Dify 版 Agent」加截图，就是今天的核心产出。

第 8 步：写四维对比报告。 同一个客服 Agent、两种实现，四个维度各写两三句结论加证据：

维度	LangGraph 代码版	Dify 拖拽版
开发速度	第 13 周加第 14 周，约两周	今天下午，约一小时
可控性	状态机任意拓扑，interrupt 一等公民	节点类型限定的 DAG，审批要拆图拼变量
可维护性	git diff、code review、类型检查三件套	DSL 能导出 yaml 进 git，但 diff 满是节点 ID 噪音，review 靠看画布
测试评估	第 16 周的用例集、断言、回归跑批	无单测概念，只有会话日志和人工标注，回归靠手点

第四行是差距最大的一行，报告里单独写一段。第 16 周你建立的评估体系——数据集、断言、自动回归——在 Dify 里基本失配。平台给的替代品是翻会话日志和攒标注样本，流程一改，回归全靠手点三条冒烟问题。这不是你懒，是可测试性本来就是代码的属性，拖拽画布没有对应物。

报告结论别写成「谁好谁坏」，写成边界：这个客服 Agent 若只到今天的功能，Dify 一小时交付、自建两周，选 Dify；一旦审批链要做严、评估要进 CI、流程要长成复杂状态机，回代码。

常见踩坑

坑 1：拿 Dify 当 LangGraph 的替代品练深度。 拖一个月画布，框架功力一分不涨。Dify 的正确打开方式是今天这样：带着映射表去用，每个节点翻译回你已会的代码，一天出师，剩下时间做鉴定。

坑 2：在部署环节恋战。 20 分钟起不了本地版就转官方云，别跟端口、内存较劲。本地版真正的价值是让你把 compose 文件拆开看一遍：一个低代码平台底下要挂 api、worker、向量库、沙箱一整串服务，看懂这个「重」，你对它的定位判断才立体。

坑 3：知识库上传完就宣布 RAG 完成。 第 14 周的教训原样生效：默认切块不一定适合你的文档，top-k 和阈值直接决定召回质量。平台把参数收进默认值，不等于问题消失。拿第 16 周的评估思路抽几条问题人工跑分，你会亲眼看到默认值和调优的差距，这段放进对比报告很加分。

坑 4：把 DSL yaml 提交 git 当成可维护。 能进版本库不等于可 review。yaml 里节点 ID、坐标、自动生成的字段混作一团，diff 基本不可读。团队协作的现实做法：改画布的人自己写一段变更说明，别指望 reviewer 从 yaml 里考古。

坑 5：以为没有 interrupt 是 Dify 的短板。 是取舍。80% 的客服和知识库场景不需要审批链；需要的那 20%，正确的动作是回代码，不是用会话变量硬拼。判断顺序永远是：先问「我的场景在它产品化的那 80% 里吗」，在，用它省时间；不在，回框架，别跟画布较劲。

自测问题

先自己答，再展开对照。答不上来的，回对应小节看一遍。

1. Dify 和 LangGraph 的定位差别是什么？为什么 JD 把它们并列写？

参考答案

Dify 是低代码平台，把 LLM 应用最高频的管道（意图路由、RAG、工具调用、发布）产品化成画布节点，交付快但表达力锁在预设节点内；LangGraph 是代码框架，表达力上限是任意拓扑的状态机。JD 并列因为它们考察不同能力：会不会亲手造，和懂不懂按场景选交付形态。

2. 第 13 周的 Supervisor 在 Dify 里对应什么节点？背后的机制一样吗？

参考答案

问题分类器节点。机制一样：一次 LLM 调用做结构化选择，类别列表等价于路由枚举，分支线等价于条件边，路由 prompt 藏在节点的高级设置里，同样可改。区别只在表达方式：代码变配置。

3. interrupt() 审批流在 Dify 里为什么难做？workaround 是什么，丢了什么？

参考答案

Chatflow 是一次请求跑完的 DAG，没有挂起-恢复语义。workaround 是拆成两段流程，用会话变量存申请编号，给分类器新增审批结果回传分支，下一轮对话触发后段。丢的是 LangGraph 白送的三样：断点状态的持久化、恢复的原子性、超时回收，全要手工拼，流程一复杂就不可维护。

4. 四维对比里，为什么「测试评估」这一维差距最大？

参考答案

可测试性来自可编程接口：第 16 周的体系建立在数据集、断言、CI 跑批上，全是对代码的接口。拖拽画布没有等价物，平台只提供会话日志和人工标注，改一次流程回归全靠手点。所以这一维不是「弱」，是基本失配。

5. 出现什么信号时，该从 Dify 回到 LangGraph？

参考答案

审批或 HITL 链要做严、评估体系要进 CI、流程拓扑超出节点类型能表达的范围、需要对某一层做性能或成本级优化时。反过来，标准问答加知识库加简单工具的交付型场景，Dify 一小时出活更划算。

延伸阅读

• Dify 官方文档，工作流节点、知识库、工具三块对着今天的映射表读，路径级操作以它为准
• Dify GitHub 仓库，docker 目录下的 compose 文件值得像第 7 周那样拆开读，看一个低代码平台的依赖图长什么样
• Day 6 · Coze 与选型，明天用 Coze 搭同类 Bot，把今天的四维对比扩成正式的选型决策树

今天的产出「Dify 版 Agent」和四维对比报告留好。明天换 Coze 把同类 Bot 再搭一遍，你会发现自己要回答的是同一套问题：哪些活它产品化了、哪些活它做不了——今天这份鉴定报告，就是选型决策树的第一根枝干。