今天我们将继续学习，将了解MCP服务的另一种通信方式。当然这两种都是有不同的适用场景的，并非竞争的关系。后面也会说明，其各自的优缺点和场景。
等系列课学习完成，你将能了解什么是MCP，如何开发MCP和如何实际使用它（当然我们会回归到Dify中，配合LLM，更加完善我们的AI应用适用场景）。
**01.**动手准备在我们动手写一个自己的SSE版本的MCP之前，又需要了解协议的一些概念，这样做起来就得心应手了。
Resoures：暴露结构化数据的内容给LLM。
Prompts：提供给LLM应用的可重用Prompt模板。
Tools：提供在服务端给LLM应用特别是Agent使用的工具。
Roots：定义API的接入点和访问路径
Sampling：允许服务器通过客户端请求LLM完成
当然以上不是全部都必须，比如可以只实现Tools功能，那我们同样从TypeScript的SDK开始。
上一课的例子是通过stdio传输数据，即数据是本地机器的进程间通信。适合AI助手工具来软件使用。
而今天我们来尝试实现远程通信。
**02.**动手做一做复制一下上节课的项目，做以下修改：
1234 ...
今天我们将继续学习，基于model context protocol的SDK来开发自己的MCP服务。
等系列课学习完成，你将能了解什么是MCP，如何开发MCP和如何实际使用它（当然我们会回归到Dify中，配合LLM，更加完善我们的AI应用适用场景）。
**01.**动手准备今天就来展开说说开发MCP应用，应该如何做。既然是开发，那就离不开代码了。处理的顺序正好和概念反过来，我们先来实现一个MCP服务端。
同时需要理解两个重要的概念：
1 通信机制MCP协议支持两种主要的通信机制：基于标准输入输出的本地通信和基于SSE(Server-Sent Events)的远程通信。
也就是说MCP服务端，根据和客户端连接时所在的位置不同，分成本地通信和远程通信。
本地通信是通过stdio传输数据，即数据是本地机器的进程间通信。适合AI助手工具等软件使用。
而远程通信则是利用SSE技术，通过HTTP来通信和传输数据。适合于共享MCP服务，在企业内使用或者服务给互联网用户。
2 运行语言和环境一般涉及到开发，必定是要和开发语言有关。但是MCP协议是和语言无关的，也就是说大家可以尽量使用自己熟悉的开发语言 ...
上一节Dify应用实战课，我们学习了如何将数据表生成图，可以更直接的展示数据的意义。
今天我们将暂时将Dify的学习搁置一下。来学习AI工具中重要的一个知识：MCP(Model Context Protocol)。
等系列课学习完成，你将能了解什么是MCP，如何开发MCP和如何实际使用它（当然我们会回归到Dify中，配合LLM，更加完善我们的AI应用适用场景）。
**01.**基础概念MCP(Model Context Protocol)是一种开放协议，它标准化了应用程序如何为LLM提供上下文。
将MCP想象成AI应用程序的USB-C端口。正如USB-C提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP也提供了一种将AI模型连接到不同数据源和工具的标准化方式。
它是去年11月才被Claude公司提出来的，但是不到半年时间，基于MCP的生态就如雨后春笋般涌现。过去以API方式提供服务的传统互联网，迅速拥抱这一变化，大量的MCP服务被开发，开源和提供出来。
要想开发MCP应用，首先需要了解的是其架构和几个重要的概念。
简单的图示中，提到了主机，客户端和服务器。
1 主机MC ...
最近还是有网友问，代码执行节点为啥运行报错，说找不到模块。但自己的Python环境是安装了这些模块的。还有就是按照麦金叔的数据库连接，为啥连不上。今天我们再详细说说。
**01.**库和权限 当你运行代码节点出现如下两种错误的时候，这一篇就是为你准备的。
最简单的方式就是在Dify的沙箱环境进行依赖库的安装和权限设置。
库安装：
工程目录下docker/volumes/sandbox/dependencies下有一个空文件python-requirements.txt，打开文件后
增加一行”pandas==2.2.3”，如果你代码使用了其他第三方库，也像正常pip install或者conda install一样，将使用的库，依次添加即可。
权限修改：
工程目录下docker/volumes/sandbox/conf里面有一个config.yaml文件，找到allowed_syscalls段，把需要的权限加进去。
还是有同学不知道怎么操作，也有不放心权限太大的，麦金叔把所有的code和解释都放这 ...
**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 ...
