透过 Dify 集成看 MCP 的优点和局限

最新推荐文章于 2025-05-21 11:08:41 发布

Python_金钱豹

最新推荐文章于 2025-05-21 11:08:41 发布

阅读量680

点赞数 15

文章标签： microsoft 人工智能 ui 机器学习算法 milvus

本文链接：https://blog.csdn.net/Python_cocola/article/details/148081549

版权

最近 MCP 火的一塌糊涂，似乎不拥抱就赶不上时代一样，然而我做了个服务测了下，似乎宣传>应用…

TL;DR

文章有点长，先说结论：

MCP 三个关键词：自动发现、标准化以及解耦合
MCP 是 For Agent 的产物，非 Agent 下似乎没什么用处，比如在工作流中使用
MCP 在应用上类似 Dify/Coze 等的插件，然而成熟度还差一些
或许 MCP 更适合 Cursor/VS Code/Claude Desktop 等本地 IDE 集成的 Agent

有了 MCP 能干什么？

最近公司培训，看到同事用 Cursor 借助 MCP 协议使用 Agent 调用第三方工具做 Red Teaming，觉得好玩于是测试了下（实际上只是看了下代码测了下流程，Cursor 的 Agent 模式是付费项目，我并不想花 20 刀就为“玩一下”）。

工作原理其实很简单：

似乎任何一个 Agent 应用都能干类似的事，MCP 并没有太大价值？

那我们再换一个问题，这次的问题不再是一个查询类问题，而是需要入参才能执行的一个任务。

这时候，你会发现如果要实现这个需求，就需要让 Agent 能知道其可用的工具，以及这些工具如何去使用。以往，我们需要编写一系列工具，在应用侧告诉大模型有哪些工具以及如何去使用，大模型再通过 function call 调用工具获取结果。

而在 MCP 架构下，应用可以自动发现并告诉大模型有哪些工具。

为了实现这个功能，MCP 定义了两个组件：

MCP Server：明面上是服务端，然而更像一个功能汇聚服务…在里面去定义有哪些工具（函数）可以使用，以及参数是什么
MCP Client：和 MCP Server 交互的工具，在上图中内嵌在了 IDE 中

以上面的场景为例，在 Cursor 中可以通过 JSON 添加 MCP Server 配置，内容如下：

{
  "mcpServers": {
    "EnkryptAI-MCP": {
      "command": "uv",
      "args": [
        "--directory",
        "PATH/TO/enkryptai-mcp-server",
        "run",
        "src/mcp_server.py"
      ],
      "env": {
        "ENKRYPTAI_API_KEY": "YOUR ENKRYPTAI API KEY"
      }
    }
  }
}

可以看到，MCP Server 其实就是用 uv（一个 Python 包管理器） run 了一个本地的 python 脚本，而这个脚本的作用就是调用其他的云端 API 服务…

细看的话，和其他代码不一样的地方在于，他调用了 mcp 的库，把函数封注册成工具，这样 Client 来调用时就能自动获取到支持的功能列表。

另外代码中也对函数的输入和输出做了很多标准化的描述。有了这样的规范，可以做到工具只开发一套，兼容 MCP 的应用都可以直接使用，而无需重复造轮子。这也是 MCP 的第二个价值，标准化。

至此，MCP 101 已经过完一半，总结两个关键词：**自动发现；标准化。**Dify 下怎么对接 MCP 服务？在上面的示例中，实际上 MCP Server 是由 MCP Client(Cursor) 来本地启动的，这要求 Client 和 Server 在同一台主机上（两者通过 stdio 通信），为了支持跨主机的通信，MCP 有另一个通信模式叫 SSE（Server-Sent Events）。
SSE 底层跑的还是 HTTP，只是上层有自己的通信规范，可以理解为造了个标准的 API。
再回到标题，如果要让 Dify 对接 MCP Server，其实只需要完成下面两件事：在外部服务器部署支持 SSE 的 MCP Server在 Dify 上安装支持 SSE 的 MCP Client（插件）

MCP Server 配置及启动我参照一个 Weather 的 MCP SSE 项目，用 Github Copilot 将我司的 AI Security API 改成了 SSE 版本的 MCP Server，启动：uv run src/mcp_server.pyINFO: Started server process [4093949]INFO: Waiting for application startup.INFO: Application startup complete.INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)看到状态为 Running 且在监听端口之后，就可以在 Dify 中进行测试啦。

插件安装及配置

在 Dify 1.x 版本下，插件商店搜索 MCP，安装下列插件：

配置 MCP Server，参考配置如下，指一下 MCP Server 的 URL 即可：
{ "PANW-AI-Security": { "url": "http://10.10.50.144:8080/sse" }}配置截图：

调用示例：

从使用上看 MCP 和 Dify 的插件有些类似，但稍微简单点，比如 Agent 可以自动去获取有哪些工具可用，在工具调用失败时还会自动检查当前可用工具有哪些，然后再次进行尝试。MCP 和 Dify Plugin 的对比在写 SSE Server 的时候，发现有些理念和 Dify Plugin 有点类似，但又有些区别，分别用图片和文字描述下。**从功能上来说，最终目的是一样的，让大模型调用外部服务；**从架构上来说，如果要让大模型调用外部组件，插件可以一跳直达外部服务，而使用 MCP 则需要外挂一个 MCP Server 做中转。
如果再复杂一点，假如让 Agent 调用多个服务，这时候你会发现两个很像，只是 MCP 把能力集中在了外部，而在 Dify 下能力集中在插件中。这或许这就是 MCP 的第三个价值：与应用解耦。早期 Dify 的插件内置在发行版中，如果要更新、新增插件需要改动项目文件。Dify 1.0 之后可以把插件“外置”，通过 dify-plugin-daemon 来管理和运行，这实际上是一种解耦，只不过这些插件只适用于 Dify 生态，其他平台不能直接拿来使用。如果使用 MCP 架构，理论上来说一套 MCP Server 可以给多个 AI 平台使用，没有太多的适配成本。另外如果要对服务进行更新，只需要更改 MCP Server 侧的代码即可，应用本身可以不用动。
说完了优点，再说说 MCP “弱”的地方。1. 无处安放的 Key/Token你会发现，在第一个 Cursor 的示例中，调用外部服务的 API Key 直接写在了配置文件的环境变量中，总感觉这类敏感信息需要有个安全的地方存放。在做第二个 Dify SSE 对接的时候，Key 需要直接放在运行代码的地方，也就是 MCP Server 所在位置，查了很多文档，大家要么直接写在环境变量里，要么直接写在代码里…(说到这里，未来应该会有一些 MCP Manager 方案出来做这些事)还有一种形式是放在 Client 侧，以 Header 或者 HTTP 请求参数的形式传递给 MCP Server，然而这部分并没有规范。另外，Client 侧如何妥善保存密钥也是个问题，无论 VS Code/Cursor 还是 Dify 的社区 MCP 插件，都是明文直接放在 JSON 中…相比之下，Dify Plugin 的设计就很好，变量属性为 secret-input 时都会隐蔽保存。2. 认证怎么做？官方的一些示例中，会在 Server 设置一个 Key（如上面所说，无处安放），然后 Client 通过 Header 等形式传输同样的 Key 以达到认证的目的，这未免显得有点粗糙（官方有很多和认证相关的 issue，应该会补齐这部分功能）。而在 Dify 下 Plugin 和 Dify 就是一体的，不需要考虑组件间的信任。3. 安全隐患因架构决定 MCP Server 侧的东西可以是动态的，如果有居心叵测之人修改/增加了 MCP Server 中的函数，模型又自动调用了这些模块，风险自不用我说。（已经有安全团队 Demo 通过 MCP tool 的 description、隐藏的提示词、虚假报错信息等诱导大模型执行特定操作…）相比之下 Dify 的 Plugin 好歹会有官方验证，升级也需要用户干预，虽然不那么自动，但风险相对更小一些。(魔搭社区、smithery 等很多平台已经有成型的 MCP 商店了，有些还集成了安全扫描功能，一定程度上可以解决来源和安全问题)4. MCP Server 管理及运行在当前的实现下，通常一个 MCP Server 对应一个服务商的多个服务，如果一个 Agent 需要使用 20 个服务商的服务，那需要配置 20 个 MCP Server，不同 MCP Server 可能会有不同的依赖环境，不同的配置，不同的认证方式，这些还都是通过 json 文件去定义…不确定官方会不会有一个集中式的管理、运行和接入服务，反正社区是有人在做了。5. 在 Dify 下，仅能用于 Agent，不能应用于工作流。虽说 Agent 是未来 AGI 的方向，但实际在应用时，工作流也有其优势，并不是所有场景都适合用 Agent 实现，而目前在工作流下 MCP 并没什么用。引用一个 Anthropic 《Building effective agents》中的 Checklist：你会发现日常 AI 应用中，很多时候并不需要用到 Agent，用 Agent 效果不一定更好，但 Token 肯定消耗更多(老黄狂喜)：RAG 应用，做个知识检索，贴出结果和参考链接就 OK 了联网检索，工作流+工具+LLM 也能做要多功能，直接做成多个机器人就行了，不同机器人走不同的工作流，不需要 Agent 来判断用户想干什么再去选择不同的工具，用户自己会选…再看目前最亮眼的 Agent 应用，就是类似 Manus 一样的代码开发系统，满足上面的各种说明：节省（程序员）成本；足够复杂，需要自动试错和纠错；只要开放接口，Agent 可以自己去运行慢慢调试…
说到这里，似乎感觉 MCP 就像是 Anthropic 为了自家代码开发 Agent 打造的一样… 开发类 Agent 就是要调用很多工具，而标准化这些工具的调用，很能受益这类 Agent。技术上来说，Dify 等平台其实可以做一个专用于 Workflow 的 MCP Client 插件，自动获取 MCP Server 的参数列表，然后将其变成表单供应用使用，不知道未来会不会有这样的东西出现。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述