一键部署 Dify + MCP Server：Serverless 架构下高效开发 AI 智能体应用实战-开发者社区

1. 为什么要在 Serverless 上跑 Dify + MCP Server

Dify 是一个开源的 LLM 应用研发平台，能通过可视化拖拽把提示词、知识库、工具调用编排成一个可用的 AI 应用；MCP Server 则是把外部能力（网页抓取、数据库查询、文件操作等）按统一协议暴露出来的服务端。两者结合，等于给智能体装上了标准化的“USB 接口”，需要什么工具就插什么工具。

但真正落地时，麻烦往往不在编排，而在部署。Dify 依赖 PostgreSQL、Redis、向量库、对象存储，还要处理公网入口和弹性伸缩；MCP Server 又要求长连接和稳定的 SSE 通道。传统做法是买几台 ECS 自己装 Docker Compose，流量一上来就得手动扩容，闲下来资源又白白浪费。我试过在本地用 docker-compose 起 Dify，开发阶段够用，一旦要给团队共享或者对外提供服务，运维成本立刻压过来。

Serverless 应用引擎（SAE）解决的正是这个问题：不用管节点，按实际用量计费，支持多可用区部署和自动弹性，还能把 Dify 和 MCP Server 都放在同一个 VPC 内，数据不出内网。本文要交付的是一条完整路径——从 saectl 模板一键部署 Dify，到把 MCP Server 部署为 SAE 应用，再到在 Dify 里配置 MCP 工具并跑通一次真实的工具调用。适合想快速搭建 AI 智能体应用、又不想被运维拖住的开发者。

2. 部署前的前置资源与 saectl 工具准备

在 SAE 上部署 Dify，本质上是用一组 Kubernetes 资源定义把 Dify 的各个组件跑起来。SAE 提供了 saectl 命令行工具来提交这些资源，所以第一步是把工具装好，第二步是把 Dify 依赖的外部资源准备好。

2.1 安装与配置 saectl

saectl 的安装方式参考阿里云官方帮助文档“如何安装与配置 saectl 工具”。安装完成后需要配置访问凭证，通常包括 AccessKey、Region 和 SAE 的命名空间。配置好之后执行saectl version能打印版本号，就说明工具链通了。

这里有个容易踩的坑：saectl 的凭证和 SAE 控制台的账号要一致，否则提交资源时会报权限错误。建议先在控制台创建一个独立的命名空间，比如dify，后续所有资源都放在这个命名空间下，方便清理。

2.2 准备 Dify 依赖的资源

Dify 不是单体应用，它需要以下几类外部依赖，缺一不可：

资源类型	用途	建议
PostgreSQL	存 Dify 的业务数据、应用配置	可用 RDS，也可自建
Redis	缓存与队列	可用 Tair 或自建
向量数据库	知识库检索	推荐 PGVector，与 PostgreSQL 复用实例
NAS 文件存储	存上传的文件、插件包	SAE 挂载 NAS 很方便
NAT 网关	让 VPC 内的应用能访问公网模型 API	必须配置，否则调不通外部模型

这些资源可以提前在控制台创建好，把连接信息记下来。向量库这里我建议直接用 PGVector，因为它就是 PostgreSQL 的一个扩展，能和业务库放在同一个实例里，少维护一套组件。NAS 则用来做持久化挂载，Dify 的storage目录和插件目录都指向 NAS，这样容器重启数据也不会丢。

NAT 网关是最容易被忽略的一项。Dify 调用 OpenAI、通义千问等模型 API 时需要出公网，如果 VPC 没有配置 NAT，请求会直接超时，而且报错信息往往不明显，排查起来很费时间。提前配好 NAT 网关和 SNAT 规则，能省掉后面很多麻烦。

2.3 关于模型接入的说明

Dify 本身不提供模型，它需要你配置模型供应商。如果你希望统一管理模型调用、方便切换不同模型，可以在 Dify 的模型供应商里选择 OpenAI 兼容接口，把 Base URL 指向https://taotoken.net/api，再填入对应的 API Key 和 Model ID。这样 Dify 里的所有应用都走同一个入口，换模型时只改一处配置。模型对话调试可以在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 里先验证通不通，再回到 Dify 配置。

3. 用 saectl 模板一键部署 Dify 的可复制配置

这一节是全文的核心。我会给出一份可以直接复制修改的 YAML 片段，以及一键部署脚本的执行方式。你只需要把变量替换成自己的资源信息，就能把 Dify 跑起来。

3.1 下载模板仓库并理解结构

先下载 SAE Dify 模板仓库，仓库里包含了 Dify 所有组件所需的 K8S 资源定义，大致包括：

dify-credentials：Secret，存数据库、Redis、向量库的账号密码
dify-api、dify-worker、dify-web：三个核心 Deployment
dify-service：Service，暴露 Web 入口
dify-pvc：PVC，挂载 NAS

模板里的变量用${}占位，替换成真实值即可。下面以dify-credentials为例，这是最关键的配置片段：

apiVersion: v1 data: DB_USERNAME: ${pg_database_username} DB_PASSWORD: ${pg_database_password} PGVECTOR_USER: ${vector_database_username} PGVECTOR_PASSWORD: ${vector_database_password} REDIS_USERNAME: ${redis_database_username} REDIS_PASSWORD: ${redis_database_password} kind: Secret metadata: name: dify-credentials namespace: dify type: Opaque

注意namespace要和你 saectl 配置的命名空间一致。data下的值在真实提交时需要用 base64 编码，或者直接用stringData字段写明文，K8S 会自动编码。我建议用stringData，改起来直观，不容易出错。

3.2 替换变量并执行一键部署

把模板里所有${}变量替换完之后，执行仓库里的安装脚本：

chmod +x ./install.sh ./install.sh

脚本会自动按顺序部署上述 K8S 资源，并在部署完成后检查 Pod 状态，最后打印出 Dify 的公网访问地址，格式类似EXTERNAL-IP:PORT。整个过程通常在一分钟内完成。

登录 SAE 控制台，可以看到dify-api、dify-worker、dify-web等应用组件已经创建出来，状态为 Running。如果某个 Pod 一直起不来，优先看它的日志，常见原因是数据库连接信息填错，或者 NAT 没配导致拉取镜像失败。

3.3 用应用中心部署的替代路径

如果你不想用命令行，SAE 应用中心也提供了 Dify 社区版模板。在控制台选择 Dify 社区版，填写参数表单（数据库、Redis、向量库、NAS、NAT 等信息），提交后平台会自动创建并运行部署流水线。这条路径适合不熟悉 K8S 资源的同学，本质和 saectl 模板部署是一样的，只是把 YAML 换成了表单。

两种方式部署完成后，访问方式相同：在浏览器输入控制台打印的EXTERNAL-IP:PORT，就能看到 Dify 的登录页。首次进入需要设置管理员账号。

4. 部署 MCP Server 并在 Dify 中完成工具调用验证

Dify 跑起来只是第一步，真正体现价值的是让它调用 MCP Server 上的工具。这一节我会用一个官方的 Python SDK 示例，把 MCP Server 部署到 SAE，然后在 Dify 里配置并验证调用链路。

4.1 用 Python SDK 写一个 SSE 协议的 MCP Server

MCP 官方 Python SDK 里有一个 simple-tool 示例，实现了 SSE 远端协议，并提供一个网页抓取工具。核心逻辑是：/sse路径负责建立连接，/messages/路径负责消息推送。关键代码结构如下：

from mcp.server.sse import SseServerTransport from starlette.applications import Starlette from starlette.routing import Mount, Route sse = SseServerTransport("/messages/") async def handle_sse(request): async with sse.connect_sse( request.scope, request.receive, request._send ) as streams: await app.run( streams[0], streams[1], app.create_initialization_options() ) starlette_app = Starlette( debug=True, routes=[ Route("/sse", endpoint=handle_sse), Mount("/messages/", app=sse.handle_post_message), ], )

工具定义部分用装饰器注册，list_tools返回工具列表，call_tool处理实际调用：

@app.list_tools() async def list_tools() -> list[types.Tool]: return [ types.Tool( name="fetch", description="Fetches a website and returns its content", inputSchema={ "type": "object", "required": ["url"], "properties": { "url": {"type": "string", "description": "URL to fetch"} }, }, ) ] @app.call_tool() async def fetch_tool(name: str, arguments: dict): if name != "fetch": raise ValueError(f"Unknown tool: {name}") if "url" not in arguments: raise ValueError("Missing required argument 'url'") return await fetch_website(arguments["url"])

把这段代码打包成镜像，推到镜像仓库，然后用 saectl 部署到 SAE。部署时注意暴露一个 CLB 类型的 Service，这样 Dify 才能通过公网或内网地址访问到它。SAE 内置了应用监控和日志，部署完成后在控制台能看到应用处于 Running 状态，日志里会打印服务器运行中的信息。

4.2 在 Dify 中配置 MCP 工具

Dify 官方目前没有原生支持 MCP 协议，需要通过插件形式接入。在 Dify 的插件市场里安装 MCP 工具插件，然后回到工作流界面，创建一个工作流应用，添加 Agent 节点。

Agent 节点配置选择 ReAct 模式，然后在 MCP 服务配置里填写 SAE MCP Server 绑定的 CLB 地址。配置样例：

{ "mcp_server": { "url": "http://8.135.243.229:80/sse", "headers": {}, "timeout": 5, "sse_read_timeout": 300 } }

这里的url要指向 MCP Server 的/sse路径，sse_read_timeout建议设大一点，因为工具调用可能耗时较长。headers如果服务端没有鉴权要求就留空。

4.3 验证调用链路

配置完成后，点击运行，Dify 会以可视化形式展示 Agent 的思考过程。你可以输入一个需要抓取网页的任务，比如“帮我抓取某个页面的标题”，观察 Agent 是否调用了fetch工具。

同时打开 SAE 控制台，查看 MCP Server 应用的输出日志。正常情况下能看到客户端和服务端交互了ListTool和CallTool等方法。如果日志里只有ListTool没有CallTool，说明 Agent 没有真正触发工具调用，需要检查 Agent 的提示词是否明确要求使用工具。

这一步跑通，意味着从 Dify 编排到 MCP Server 执行的完整链路已经打通。后续你要加新工具，只需要在 MCP Server 里注册新的 tool，Dify 侧重新拉取工具列表即可。

5. 部署与调用中的常见报错排查

即使按步骤操作，也难免遇到问题。这一节整理几个高频报错和对应的排查方向，都是实际部署中容易碰到的。

5.1 401 Unauthorized 与模型调用失败

在 Dify 里配置模型供应商后，测试连接时报 401，通常有三种原因：API Key 填错、Base URL 路径不对、或者模型 ID 不存在。如果你用的是 OpenAI 兼容接口，Base URL 一般要带/v1，但具体以供应商文档为准。Model ID 必须和供应商支持的名称完全一致，大小写敏感。

排查时先在模型对话页面单独验证 Key 和模型是否可用，确认没问题再回到 Dify 配置。如果模型对话能通、Dify 里不通，那问题多半在 Dify 的网络出口——检查 VPC 是否配了 NAT 网关，SNAT 规则是否覆盖了 Dify 所在的交换机。

5.2 local proxy failed 与连接超时

这个报错通常出现在 Dify 调用 MCP Server 时。local proxy failed意味着 Dify 无法建立到 MCP Server 的连接。先确认 MCP Server 的 CLB 地址是否可以从 Dify 所在网络访问到。如果两者在同一个 VPC，建议用内网地址而不是公网地址，延迟更低也更安全。

另一个常见原因是 SSE 长连接被中间设备断开。检查sse_read_timeout是否设得太小，以及 CLB 的空闲超时时间是否足够。如果 MCP Server 的日志里看不到任何请求进来，那问题就在网络层，不在应用层。

5.3 reading choices 与响应解析错误

reading choices这类报错一般出现在模型返回格式不符合预期时。Dify 期望的是标准的 OpenAI 格式响应，如果供应商返回的结构不同，解析就会失败。解决方法是确认供应商的接口兼容性，或者在 Dify 的模型配置里调整响应解析方式。

还有一种情况是流式响应被截断。如果模型返回的内容很长，而网关或客户端设置了过短的超时，就会读到一半断开。把超时调大，或者改用非流式模式测试，能帮助定位问题。

5.4 OAuth 与鉴权相关报错

如果 MCP Server 配置了鉴权，而 Dify 侧的headers没有带上正确的凭证，就会报 OAuth 或 401 类错误。检查headers里的 Authorization 字段格式是否正确，Bearer Token 有没有多余空格。如果服务端用的是自定义鉴权头，也要在headers里对应填上。

对于 Claude Code 这类需要 OAuth 的工具，配置时要注意 Base URL、Key、Model ID 三件套必须完整。Base URL 指向https://taotoken.net/api，Key 用你申请到的凭证，Model ID 填具体模型名称。三者缺一，鉴权都会失败。