★ FEATURED ARTICLE 1. 为什么要在 Serverless 上跑 Dify MCP ServerDify 是一个开源的 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 安装与配置 saectlsaectl 的安装方式参考阿里云官方帮助文档“如何安装与配置 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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里先验证通不通再回到 Dify 配置。3. 用 saectl 模板一键部署 Dify 的可复制配置这一节是全文的核心。我会给出一份可以直接复制修改的 YAML 片段以及一键部署脚本的执行方式。你只需要把变量替换成自己的资源信息就能把 Dify 跑起来。3.1 下载模板仓库并理解结构先下载 SAE Dify 模板仓库仓库里包含了 Dify 所有组件所需的 K8S 资源定义大致包括dify-credentialsSecret存数据库、Redis、向量库的账号密码dify-api、dify-worker、dify-web三个核心 Deploymentdify-serviceService暴露 Web 入口dify-pvcPVC挂载 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 ServerMCP 官方 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( debugTrue, routes[ Route(/sse, endpointhandle_sse), Mount(/messages/, appsse.handle_post_message), ], )工具定义部分用装饰器注册list_tools返回工具列表call_tool处理实际调用app.list_tools() async def list_tools() - list[types.Tool]: return [ types.Tool( namefetch, descriptionFetches 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(fUnknown 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 里注册新的 toolDify 侧重新拉取工具列表即可。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/apiKey 用你申请到的凭证Model ID 填具体模型名称。三者缺一鉴权都会失败。6. 把链路固化下来从能跑到好用部署跑通只是起点真正要用于日常开发还需要把配置固化、把监控接上。SAE 提供了无侵入的全链路监控Dify 和 MCP Server 的调用耗时、错误率都能在控制台看到。建议给 MCP Server 的关键工具加上日志埋点记录每次调用的入参和耗时方便后续优化。如果你需要长期跑编码类或 Agent 类任务可以考虑用 Coding Plan 来管理模型调用额度避免频繁切换 Key。接入文档里有完整的配置说明包括 Base URL、鉴权和模型列表。把这些配置写进 Dify 的模型供应商里团队其他人直接复用不用每个人重新配一遍。最后提醒一点MCP Server 暴露的工具要控制好权限尤其是涉及文件操作或数据库查询的工具不要直接连生产库。可以在 MCP Server 里加一层参数校验和权限判断只暴露必要的接口。这样即使 Agent 编排出错也不会造成不可逆的影响。
阅读完成 · 觉得有帮助？
