**01.**动手做一做随便创建一个工作流。添加”代码执行”和”结束”。
并填入代码如下：
保存后进行测试。结果如下图：
提示非常清楚，就是找不到依赖库pandas。
那我们就把库安装上，因为运行时是由sandbox提供的，所以我们找到docker-compose.yaml中sandbox的定义。其中有个卷的映射，
./volumes/sandbox/dependencies:/dependencies
这里就是我们添加依赖的地方。工程目录下docker/volumes/sandbox/dependencies下有一个空文件python-requirements.txt
输入一行"pandas==2.2.3"
重启docker服务，查看docker-sandbox-1的日志，会看到在启动sandbox时，会安装第三方库。
重新运行”工作流”(如果还报错找不到pandas，需要等待一会儿，安装有可能还没有完成，一定要看到sandbox的log里面显示python dependencies installed)。发现已经不再报错找不到pandas，而是提 ...
这两天有网友问，上次的课提到了数据库查询，对一般的人还是有点难度。所以希望大模型也能生成SQL，可以自己去查询数据库的数据。
麦金叔建议他使用文生SQL的模型，网友应该真的去尝试了，只不过还是有问题。那今天麦金叔就来演示一下，如何处理这一需求，并解决查询报错的问题。
**01.**动手做一做今天的任务专题是解决让大模型生成SQL查询语句，并利用数据库工具查询得到结果。
依然用工作流作为测试。添加下图所示节点，依次为”开始”，”LLM”，”参数提取器”，”SQL EXECUTE”和”结束”。
将”开始”节点，添加一个参数”user_promt”。这样在对话时，可以将查询要求填入。
“LLM”节点选择模型为”qwen2.5-72b-instruct”，上下文选择”开始”节点新增的参数”user_promt”，将系统提示词按如下填入：
请直接提供答案，无需解释思考过程。
根据用户输入 上下文
进行SQL的生成，最终结果仅包含SQL语句。
数据库的schema如下：
12345678910111213141516171819CREATE TABLE `doctor` ( `id` int ...
今天我们将要继续企业应用之旅，让Dify自己也变成为MCP服务，成为助手类工具或者现有系统的定制化AI工具服务。
学习完成，你将能让自己的桌面助手工具，集成最近一段时间辛苦创建的Dify应用。这样就可以暂时不去Dify的控制台去使用工作流了。
**01.**准备环节在我们开始之前，有需要安装一个工具。感谢伟大的开源作者们的奉献，这个世界因你们而精彩。
去插件->marketplace，搜一下SSE，看到下图这个插件，就安装一下。
至此，所有今天需要的准备就完成了，恭喜！
**02.**动手做一做找到之前实战的案例：”图片生成”，简单裁剪一下。然后去发布那里，发布为工具。
按照下图所示，输入一个工具调用名称，并且描述写好，最好详细一点，能让大模型理解这个工具到底是干啥的。
此时在Dif有点工作流里，应该就出现这个应用了。
接着开始配置新安装的插件。
进入插件，找到它”MCP Compatible Dify Tools”，点击之后，会出现在页面右边。这时继续点击”API端点”右侧的加号。
就会进入端点配置页。填入端点名称，可以随意输入。然后点击”工具列表”右侧的加号。在弹出” ...
今天我们将要继续企业应用之旅，让Dify变成一个超级中间站，能将开源的大几千MCP服务为我所用。
学习完成，你将会让自己的Dify也拥有更专业的使用MCP的能力。
**01.**准备环节我们之前详细学习了MCP所有关键的内容，是时候来表演了。
不过Dify是一个服务端运行的系统，它不像本地可以为MCP服务去准备运行环境。如果让Dify集成stdio方式的MCP，那改动就有点大了。
但是现存海量的MCP服务，绝大多数都是stdio方式，所以关键一点就是打通这个使用方式上的差异。
因此使用一个叫mcp-proxy的工具，就来的如此的顺理成章。(如果听不懂stdio的话，请复习前面的博文)
大模型的得力干将MCP(5) - 应用场景和发展方向，窥探先机，不容错过
为了不影响本地电脑的环境配置等，我们同样以容器的方式，去运行这个mcp-proxy。
根据它的说明文档，有两个地方需要修改为自己的。
重新打包一下镜像，加入uv运行环境。新建一个mcp-proxy.Dockerfile文件，内容如下：
2.以上述镜像，加入需要代理的MCP服务，我们以mysql_mcp_server为例。新 ...
今天我们将要继续企业应用之旅，让Dify也变成一个简单的BI系统，可以让数据变成有图有真相。
学习完成，你将能举一反三，让数据自己说话。
**01.**动手做一做今天的动手实验，需要有处理数据的代码能力。如果对你来说难度太大，建议收藏慢慢学习。
首先，我们简化核心步骤，把不相干的节点全部删除。掌握了之后，可以集成进前面课程有关数据SQL的部分
既然是和数据相关，那准备的部分必然涉及到数据库。假设我们有一个数据表名为automation，记录了企业中，对订单进行自动化处理的情况。
该表设计的思路是，针对每个订单，都会进行自动化处理，并记录处理结果。并且按业务规则，运行失败时会进行一定次数的重试，以避免因资源等环境问题导致的暂时失败，而影响可以自动化的任务。
记录自动化处理的结果字段为code，0表示不符合自动化处理条件，1表示自动化处理成功，大于1的值表示自动化程序内部的错误。
我们需要按照订单的日期来查询按天统计的订单处理情况。查询语句和结果如下图所示。
有了上述准备之后，开始进行Dify应用开发。
添加”SQL Execute”节点(如果没有，需要安装插件后，进入工具选择， ...
今天我们将要开启企业应用之旅，让Dify真正的在企业中用起来。
学习完成，你将能配置后台的文件存储改为S3或兼容S3的Minio对象存储。
**01.**动手做一做今天的动手实验，与运维相关。如果不感兴趣，可以划走。
首先，需要让Dify知道使用对象存储方式来保存文件。
进入到项目下的docker目录，打开由.env.example文件复制而来的.env文件。找到文件存储配置段，大概在第293行，改动STORAGE_TYPE为S3。
S3除了可以是AWS的S3服务，还可以是兼容S3的对象存储，如Minio等。注意这里，如果对象存储服务是Minio，S3_ENDPOINT需要为实际Minio的API地址，S3_BUCKET_NAME可以改为实际用的桶名，如difyai。而ACCESS_KEY和SECRET_KEY，分别是Minio的用户名和密码，并非像S3使用的KEY。
接着，需要重新启动Dify所有服务。使用命令docker compose restart。
如果测试没有生效，可以reload环境变量文件，或者简单点重启Linux服务器。
上述操作完成之后，接下来就是使用部分。
将C ...
今天我们要学习工作流中对于多路分支进行结果上的合并。
学习完成，你将进一步简化工作流的重复节点，拆分场景后，将其合并到主流程中。
**01.**动手做一做今天的任务基于”医小助”。之前我们先对用户的输入，进行了问题分类。将用户提问，转变为是否为”发热”和”眼科”或者其他的分类之后，再进行处理。
为了提高对问题识别的准确性，我们将进一步使用RAG的方法，对分诊的规范文档的知识进行查询后，再使用LLM进行识别和回答。
但是如果按照之前的工作流，后面会分别接两个相同的”LLM”节点。我们希望对此进行优化，就需要用到今天的主题”变量聚合器”。
因此在”知识检索”和”LLM”节点之间，添加一个新的节点”变量聚合器”。
接着删除第二个”知识检索”和”LLM”节点之间的连线，然后连接第二个”知识检索”和”变量聚合器”节点。最后按下图进行设置
保存后，进行测试。
**02.**补充说明
变量聚合节点是工作流程中的一个关键节点，它负责整合不同分支的输出结果，确保无论哪个分支被执行，其结果都能通过一个统一的变量来引用和访问。这在多分支的情况下非常有用，可将不同分支下相同作用的变量映射为一个输出变 ...
今天我们学习大语言模型的Function Calling的使用。
学习完成，你将初步获得调用工具的能力。本节内容，非常考察动手能力，建议需要反复调试，并理解大语言模型的基础能力知识。
**01.**动手做一做今天的任务需要重开一个对话应用。当条件成熟之后，才能将今日所学集成进之前的AI应用开发中。
将默认生成的3个节点中的第2个删除。并添加”Agent”节点。
接着对该节点做配置，按下图步骤进行设置。
选择完Function Callinging之后，就会出现真实的配置。
首先需要手动选择一个配置的大语言模型。这里需要注意，不是所有的大模型都内在支持Function Calling，所以这就要求我们对大模型基础有一定的了解。比方说这一段时间非常热门的DeepSeek模型，就并没有支持Function Calling。
然后添加大模型调用的工具。这里添加了时间获取和查询天气这两个工具。
“指令”输入框中添加如下内容：
如果用户问到天气问题，你可以使用工具来帮你完成任务。
1. 根据城市和日期查询天气，使用时必须提供城市和日期两个参数，提供参数的方式要满足如下结构：
&# ...
上一节Dify应用实战课，我们继续对新项目，智能医疗分诊助手，进行了分支条件的拆解。
今天我们学习数据库的查询操作。
学习完成，你将掌握如何对数据库中的数据进行获取。
**01.**动手做一做今天的任务基于智能分诊应用”医小助”。在”条件分支”的”case1”后新增一个”SQL查询”节点。
但是，需要先准备一下插件的安装(v1.0.0之后，已经升级需要安装插件)。
插件安装之后，按下图所示进行添加，先点击”工具”，再找到刚才安装的”Database”，展开后选中”SQL Execute”。
第一次使用会让先授权，按下图步骤进行设置。直接点”去授权”，不用管下面的API端点。这个以后有需要再说。
授权之后，如果再用”数据库”工具，就不会再要求进行授权了。授权需要输入的内容如下：
1mysql+pymysql://root:123456@192.168.0.101:3306/hospital
如果用的postgresql或者sqlite，就查询一下插件的说明文档即可。
现在我们就可以填入查询SQL语句了
1SELECT name, title, description FRO ...
本文适用对象：初级水平
目标：对一个结果可能出现多种情况，进行条件分支处理
上一节Dify应用实战课，我们学习了迭代循环处理。而新项目，智能医疗分诊助手，暂停了一期，现在我们继续。
今天我们学习和上节课循环处理类似的方法，分支条件处理。
学习完成，你将掌握如何对一个结果可能存在多种情况时，按不同情况的值，进行不同的处理。
**01.**动手做一做今天的任务基于智能分诊应用”医小助”。在”问题分类器”的”分类2”后新增一个”LLM”节点。
如图所示，添加提示词内容“对
提及的有关视力的部分，进一步进行识别处理，处理结果输出为如下json格式，
1234567{ "type": 0, "result":"","raw":""}如果是咨询近视有关的，将type设置为1；如果是咨询眼睛疾病，将type设置为2；对输入的问题的解释结果，设置为result的值。”
这次我们把大模型的输出格式修改一下，如下图
接着添加”代码”节点，将上一步生成的JSON结果，提取问题 ...
