一、导读

先给大伙，看看我没有利用mcp模式，在dfiy编排的一个复杂业务

是不是很夸张，需要创建很多流程，调用很多组件，这仅仅只是调用了部分业务接口

• 一个船期查询
• 一个运价查询
• 一个货踪跟踪单号查询

现在我利用mcp模式，简化后的图

ok，话不多说，下文开始，我将介绍mcp，fastapi如何构建mcp，以实际案例进行演示!

go go go 出发喽！

二、什么是MCP？

网上关于MCP的介绍已经非常多了，我这边就长话短说，有兴趣的可以扩展阅读

• dfiy插件市场关于mcp sse ：https://marketplace.dify.ai/plugins/junjiem/mcp_sse
• dify博客文章关于mcp的案例：https://dify.ai/blog/dify-mcp-plugin-hands-on-guide-integrating-zapier-for-effortless-agent-tool-calls
• 国外论坛关于mcp的介绍：https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/

我们先来看一幅图

MCP 提供了一种统一和标准化的方式，将 AI 代理和模型与外部数据和工具集成。它不仅仅是另一个 API；
它是一个强大的连接框架，能够实现智能、动态和上下文丰富的 AI 应用。

🔌MCP的作用，就像手机充电接口从“混乱”到“统一”的演变过程。统一成“AI 界的 USB Type-C”

🚀 最终效果：从“杂乱无章”到“即插即用”

• 用户（开发者）：像用 Type-C 一样，“插上就用”，无需关心底层是哪个 AI 模型或数据源。

• 厂商（AI 提供商）：只要支持 MCP，就能快速融入生态，获得更多用户。

• 生态：从“互相割裂”变成“开放协作”，加速 AI 应用创新。

MCP 采用的是经典的客户端 - 服务器架构，我首先需要介绍几个概念。

• MCP 主机（MCP Hosts）：发起请求的 LLM 应用程序（例如 Claude Desktop、IDE 或 AI 工具）。
• MCP 客户端（MCP Clients）：在主机程序内部，与 MCP server 保持 1:1 的连接。
• MCP 服务器（MCP Servers）：为 MCP client 提供上下文、工具和 prompt 信息。
• 本地资源（Local Resources）：本地计算机中可供 MCP server 安全访问的资源（例如文件、数据库）。
• 远程资源（Remote Resources）：MCP server 可以连接到的远程资源（例如通过 API）。

基于 MCP 官方提供的 Python SDK 中的一个简单 SSE 协议的 MCP Server

https://github.com/modelcontextprotocol/python-sdk/blob/main/examples/servers/simple-tool/mcp_simple_tool/server.py

建议去走一遍这个源码！

三、API与Agent和MCP

维度	API	Agent	MCP
角色	工具	工具使用者	工具间的通信标准
灵活性	固定功能	可自主决策	动态路由和协作
协作性	需手动组合	可调用多工具	标准化多模型交互
类比	厨房菜单	服务员	餐厅工作语言

下面我将用一些形象的例子告诉大伙

1. API（接口）→ 厨房的标准化菜单

• 是什么：预定义的规则，规定如何请求数据或服务（如 REST API）。
• 作用：像餐厅的菜单，告诉顾客（调用者）能点什么菜（功能），但不关心谁点餐、怎么吃。
• 局限：
  • 固定功能（菜单写死，不能临时改菜谱）。
  • 无自主决策能力（厨房不会主动推荐菜品）。
• 例子：
  • 调用天气API获取数据，但无法自动决定是否要带伞。

---

2. Agent（智能代理）→ 服务员 + 厨师长

• 是什么：能自主决策、调用工具、完成目标的AI程序（如AutoGPT）。
• 作用：像服务员，根据你的需求（目标）协调后厨（API）、推荐菜品（决策），甚至调整做法（动态规划）。
• 特点：
  • 自主性：能拆解任务（如先查天气，再推荐穿搭）。
  • 多工具协作：可调用多个API（像让厨房和仓库联动）。
• 局限：
  • 不同Agent之间缺乏统一沟通标准（服务员之间可能说方言）。
• 例子：
  • 旅行Agent自动查机票、酒店、天气，规划行程。

---

3. MCP（模型连接协议）→ 餐厅的通用工作语言

• 是什么：标准化AI模型、工具和数据源之间的通信协议（类似gRPC但更AI友好）。
• 作用：像餐厅规定所有员工用同一种语言交流（无论厨师来自法国还是中国），确保：
  • 模型即插即用：新模型接入像新厨师入职，无需重写菜单。
  • 动态路由：根据需求自动分配任务（忙时让AI-1处理，闲时用AI-2）。
  • 上下文共享：服务员（Agent）知道顾客的过敏史（历史交互）。
• 优势：
  • 解耦：Agent不依赖具体API，只需对接MCP（服务员不用背每个厨师的方言）。
  • 生态统一：避免“API方言战争”（如OpenAI和Anthropic的协议差异）。
• 例子：
  • 通过MCP，一个Agent可同时调用GPT-4（文本）、Stable Diffusion（绘图）、企业内部数据库。

---

好了过于理论的东西，网上也有很多文章，自行搜索吧，这里就不展开讲了

四、案例

现在我将构建一个业务场景，用户输入"上海到洛杉矶船期查询"

1. AI会提取文本内容，获得关键词pol为上海，pod为洛杉矶
2. 携带pol和pod查询，基础资料查询接口
3. 然后携带查询出来的pol_id 跟pod_id 请求船期查询接口

上面流程，包含了语义解析，2个接口连续调用

代码仓库地址：https://github.com/wenwenc9/mcp-ship

1、非MCP模式编排dify

1.1 fastapi接口服务代码（fastapi_api.py）

下面这段代码主要是为了，创建2个post接口

• 编写了一个请求日志打印的组件
• 编写了2个接口《基础资料查询接口》和《船期查询接口》
• 编写了请求和响应schemas

后端接口服务，运行起来的效果如下

1.2 创建dify应用

现在到dify创建一个chatflow应用，直接在导入我代码仓库的 非MCP-船期查询.yml DSL文件就好了，记得里面的服务端IP改成你自己的！

然后按照我下面的图运行观察一下,自己一定要捋一捋发生了什么~~

解析用户语义-> 提取关键参数-> 调用基础资料接口->判断状态码-> 调用船期查询接口

2、MCP模式编排dify

2.1 安装MCP插件

先来到插件市场安装一个插件

创建一个chatflow应用，导入我代码仓库的MCP船期测试.ymlDSL文件 （注意里面的IP地址换成你的）

安装两个工具

那么问题来了，现在将我们的fastapi服务端代码改造成mcp的方式，github有一个项目可以快速帮我们做到

https://github.com/tadata-org/fastapi_mcp

几行代码轻松变成mcp模式，见fastapi_mcp_api.py

现在，启动fastapi服务端，在dify看看效果吧

2.2 启动dify调用mcp服务

在基础资料中只有3个港口

我输入了 上海到洛杉矶，注意，洛杉矶并不存在，看看效果
在这个过程中，使用了Agent ReAct 模式，进行观察，可以看到尽管找不到内容，但是依然能够进行智能回复

Agent ReAct 在我往期文章也有讲到
https://blog.csdn.net/weixin_44238683/article/details/138276724

并且点击ReAct可以看到进行了3轮操作,你可以同时观察fastapi打印日志，可以看到整个过程的处理情况

现在我们将问题替换成 上海到纽约 进行了4轮，从调用sse的MCP服务工具清单，到调用基础资料接口，以及船期接口，都是通过ReAct完成

3、结论

MCP的出现，大大提高了对于工作流垂直业务的创造能力。

举个例子，如果我在fastapi创建了10个业务接口，我在dify进行编排，某天业务接口的请求参数进行了变更
我们要重新更改dify流程，以及重新部署。

现在，我们只需要更改fastapi接口，重新部署fastapi即可，而SSE服务能够自己获得动态的工具清单。

对比维度	MCP	FastAPI 接口
统一性和标准化	- 例子：LLM 可以通过统一的 MCP 接口调用不同开发者开发的数学计算和天气查询功能，无需单独编写代码。 - 优势：提供统一协议，支持标准化的 JSON 消息格式和通用通信协议（如 JSON-RPC、HTTP、WebSocket 等），使 LLM 能无缝对接各种外部工具。	- 例子：LLM 需要为每个 FastAPI 接口（如数学计算和天气查询）单独编写调用代码，因为每个接口的实现细节不同。 - 劣势：每个 API 需要单独开发和维护，不同 API 之间的集成需要编写特定的代码。
开发和维护成本	- 例子：当文件格式从 TXT 改为 JSON 时，只需更新 MCP Server 的实现，LLM 代码无需修改。 - 优势：工具更新通常不影响 LLM 代码，维护成本低；标准化协议使开发效率更高。	- 例子：当文件格式从 TXT 改为 JSON 时，需要同时更新接口实现和 LLM 调用代码。 - 劣势：每次接口更新都需要同步更新调用代码，开发和维护成本高。
双向通信和动态交互	- 例子：LLM 通过 MCP Server 读取文件内容后，动态决定下一步操作（如调用另一个 MCP Server 进行数据分析）。 - 优势：支持双向通信和多轮交互，可实现复杂的任务流程。	- 例子：LLM 调用 FastAPI 接口获取文件内容后，需手动编写逻辑决定下一步操作，无法实现动态交互。 - 劣势：通常是单向的“一问一答”模式，不支持复杂的任务流程。
安全性	- 例子：用户使用 MCP Server 访问本地文件时，需明确授权，MCP 协议确保只有授权操作才能执行。 - 优势：提供标准化的访问控制和用户明确授权，数据源持有者可保留数据控制权。	- 例子：用户使用 FastAPI 接口访问本地文件时，需依赖开发者实现的安全机制，没有统一标准。 - 劣势：安全性依赖于开发者实现，规则不统一。
灵活性和扩展性	- 例子：LLM 可通过动态发现机制无缝调用新开发的 MCP Server（如数据库查询功能），无需修改代码。 - 优势：支持动态添加和移除工具，适用场景广，扩展性强。	- 例子：LLM 需重新编写代码来调用新开发的 FastAPI 接口（如数据库查询功能）。 - 劣势：添加新接口需要重构代码，扩展性差。
AI 优化	- 例子：MCP Server 返回格式化的数据（如天气查询结果的 JSON 对象），直接被 LLM 处理。 - 优势：提供 AI 友好的工具和提示，返回的数据格式更适合 AI 处理。	- 例子：FastAPI 接口返回 HTML 页面或原始数据，LLM 需额外处理才能使用。 - 劣势：返回原始数据，需要额外处理才能被 AI 使用。
实际应用场景	- 例子：LLM 可通过 MCP 完成复杂任务，如读取本地文件、分析内容、调用外部 API 并保存结果到数据库。 - 优势：适合复杂的 AI 工作流，如跨资源协同和多 API 联动。	- 例子：LLM 调用 FastAPI 接口查询天气信息。 - 劣势：更适合单一功能的调用，不支持复杂的任务流程。