1. Dify 工作流接入 MCP 工具链从 SSE 长连接到 Agent 编排的完整链路Dify 里调用 MCP 工具本质上是让大模型在对话过程中动态发现并执行外部能力。MCPModel Context Protocol是一套让模型与工具服务通信的协议SSEServer-Sent Events则是它常用的一种长连接传输方式。你可以在 Dify 的 Chatflow 里挂载一个 MCP SSE 插件把远端工具服务注册进来再让 Agent 节点按需调用。适合谁适合已经用 Dify 搭过工作流、想让大模型真正操作数据库或内部系统的开发者。我试过在自有环境跑通这条链路踩过几个坑下面把可复制的配置和排障过程完整写出来。核心检索词先明确Dify 调用 MCP 工具、SSE 流式接入、Agent 工具编排、超时重试。这四个词贯穿全文。Dify 负责编排MCP 负责工具协议SSE 负责传输Agent 负责决策调用哪个工具。四者缺一不可。先说整体链路。用户在 Dify 对话框输入问题Agent 节点拿到问题后通过 MCP SSE 插件向 MCP 服务端发起工具发现请求服务端返回可用工具列表Agent 根据提示词和工具描述决定调用哪个工具调用结果回传给大模型大模型再生成最终回复。整个过程是流式的SSE 保持长连接工具调用结果逐步返回。这条链路里最容易出问题的地方有三个一是 SSE 端点配置错误导致连接不上二是 Agent 策略选错导致找不到工具方法三是超时设置不合理导致长查询被截断。下面按顺序拆解。2. TaoToken 前置准备API Key 与模型接入配置在 Dify 里跑通 MCP 工具调用前提是有一个稳定可用的大模型 API。TaoToken 提供兼容 OpenAI 接口规范的模型服务你可以把它作为 Dify 的模型供应商接入。这一步不做后面 Agent 节点没有模型可用工具调用无从谈起。先拿 API Key。访问 https://taotoken.net/api-keys 创建密钥复制保存。注意这个 Key 只在创建时显示一次丢了只能重建。拿到 Key 后在 Dify 的模型供应商设置里添加 OpenAI 兼容接口Base URL 填 https://taotoken.net/apiAPI Key 填刚才复制的值。模型 ID 根据你要用的模型填写比如 claude-sonnet-4-20250514 或 gpt-4o 这类支持工具调用的模型。这里有个细节Dify 的模型供应商配置里Base URL 不要带尾部斜杠否则部分版本会拼接出双斜杠导致 404。我实测下来https://taotoken.net/api 这个写法在 Dify 1.x 版本里工作正常。配置完成后在 Dify 的模型列表里应该能看到你添加的模型。点一下测试能返回内容就说明接入成功。如果报 401检查 Key 是否复制完整如果报连接超时检查网络是否能访问该地址。模型接入只是第一步。MCP 工具调用还需要 Dify 安装两个插件Agent 策略支持 MCP 工具和 MCP SSE 工具。这两个插件在 Dify 插件市场里搜索安装即可。安装完成后在插件列表里能看到它们的状态。为什么要两个插件Agent 策略插件负责让 Agent 节点支持 MCP 工具调用MCP SSE 插件负责通过 SSE 协议发现和调用远端工具。两者配合才能完成完整链路。只装一个要么 Agent 不知道怎么调工具要么工具列表出不来。插件安装后建议重启一下 Dify 的 worker 进程确保插件加载生效。有些版本不重启会出现插件已安装但节点里找不到的情况。3. 可复制配置MCP SSE 端点与 Dify Agent 节点参数这一节给可直接复制的配置片段。先看 MCP 服务端的 SSE 端点。假设你用 Python 的 fastmcp 框架起了一个 MCP 服务监听在 9090 端口SSE 路径是 /sse那么服务端代码大致如下from fastmcp import FastMCP mcp FastMCP(mysql_mcp_server_pro) mcp.tool() def query_students(sql: str) - str: 执行学生管理系统的查询语句 # 这里接你的数据库查询逻辑 return 查询结果 if __name__ __main__: mcp.run(transportsse, host0.0.0.0, port9090)启动后SSE 端点就是 http://你的IP:9090/sse。注意这里用 0.0.0.0 监听确保 Dify 所在容器或主机能访问到。如果 Dify 跑在 Docker 里而 MCP 服务跑在宿主机IP 不能写 127.0.0.1要写宿主机的局域网 IP。接下来是 Dify 里 MCP SSE 插件的配置。在插件配置页填入 JSON{ mysql_mcp_server_pro: { url: http://172.16.0.45:9090/sse, headers: {}, timeout: 60, sse_read_timeout: 300 } }多个 MCP 服务可以并列添加{ server_name1: { url: http://127.0.0.1:8000/sse, headers: {}, timeout: 60, sse_read_timeout: 300 }, server_name2: { url: http://127.0.0.1:8001/sse } }timeout 是连接超时sse_read_timeout 是读取超时。长查询场景下sse_read_timeout 建议设大一点比如 300 秒否则大模型还在等工具返回连接就被掐断了。然后是 Dify Chatflow 里的 Agent 节点配置。创建工作流类型选 Chatflow名称随意。删掉默认的 LLM 节点添加一个 Agent 节点。Agent 策略必须选 ReAct (Support MCP Tools)。为什么不用 FunctionCalling我踩过的坑是FunctionCalling 模式下调用 MCP 工具一直提示找不到 call_tool 方法。即使用 fastmcp 框架开发的服务端不需要显式定义 call_toolFunctionCalling 依然报错。换成 ReAct 就正常了。所以这一步别纠结直接选 ReAct。工具列表里点击添加选择「通过 SSE 发现和调用 MCP 工具」。把上面配置的 MCP 服务器加进去。指令提示词必须设置否则 Agent 不知道什么时候该调工具。指令里写清楚业务场景和表结构说明。比如学生管理系统的场景把 teachers、classes、courses、students、scores 五张表的字段和关系写进去。查询变量填 query也就是用户输入。最大迭代次数默认是 3必须设置一个值否则保存不了。这个参数控制工具调用的最大轮次防止无限循环。一般设 3 到 5 够用。最后把 Agent 节点的输出连到直接回复节点变量选 Agent.text。发布预览。4. 验证请求一次端到端 MCP 工具调用实测配置完成后在 Dify 预览界面输入测试问题。比如「哪个老师学生最多」。Agent 会先通过 SSE 发现 MCP 工具拿到工具列表后根据提示词判断需要查询数据库于是调用 MCP 工具执行 SQL拿到结果后再生成自然语言回复。实测下来第一次调用会有几秒延迟因为要建立 SSE 连接并发现工具。后续调用会快一些。如果看到回复里包含具体数据说明链路通了。如果回复是「我无法查询」或者「没有可用工具」说明工具发现失败回到上一节检查 SSE 端点配置。再测一个复杂点的「总成绩最好的是哪个班级」。这个问题需要跨表查询Agent 可能会分多步调用工具先查班级再查成绩再汇总。最大迭代次数设 3 的话刚好够用。如果设 1可能查一半就停了。验证成功的标志Dify 日志里能看到 MCP 工具调用记录Agent 回复内容包含数据库里的真实数据且回复是流式输出的。SSE 长连接在整个过程中保持工具调用结果逐步回传。如果要做更严格的验证可以在 MCP 服务端加日志打印每次工具调用的入参和出参。这样能确认 Dify 确实把请求发到了 MCP 服务而不是模型自己编的答案。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节对照真实报错给排查路径。401 Unauthorized。出现在模型接入阶段说明 TaoToken 的 API Key 不对或没填。检查 Key 是否复制完整Base URL 是否写成 https://taotoken.net/api。如果 Key 没问题检查 Dify 的模型供应商配置里是否选了正确的模型 ID。local proxy failed。出现在 MCP SSE 连接阶段说明 Dify 无法访问你配置的 SSE 地址。常见原因IP 写成了 127.0.0.1 但 Dify 跑在容器里端口没开放MCP 服务没启动。排查方法在 Dify 所在环境里用 curl 访问一下 SSE 地址看能不能通。curl http://172.16.0.45:9090/sse 如果返回事件流数据说明网络通如果 connection refused说明服务没起或端口不对。reading choices 相关报错。通常出现在模型返回格式异常时比如模型不支持工具调用或者返回的 JSON 解析失败。检查你选的模型是否支持 function calling 或 tool use。部分小模型不支持工具调用硬接会报这个错。换成支持工具调用的大模型即可。OAuth 相关报错。如果 MCP 服务端配了鉴权而 Dify 插件配置里没带 headers会报 OAuth 或 403。在 MCP SSE 插件的 JSON 配置里加上 headers 字段{ server_name: { url: http://your-host:9090/sse, headers: { Authorization: Bearer your-token } } }另外如果你用的是 Claude Code 或 Cline 这类客户端接 MCP配置三件套要写全Base URL、Key、Model ID。Base URL 填 https://taotoken.net/apiKey 填你的 TaoToken 密钥Model ID 填具体模型名。缺一个都会报错。还有一个容易忽略的点Dify 的 Agent 节点里工具列表必须选指令必须填最大迭代次数必须设。这三个少一个都保存不了。保存不了的时候看下是不是漏了哪个。6. 长期编码与 Agent 编排把 MCP 工具链接入生产工作流跑通单次调用只是开始。真正要用于生产需要考虑超时重试、错误兜底和工具编排策略。超时重试方面MCP SSE 插件的 timeout 和 sse_read_timeout 要按业务调整。查询类工具如果涉及大表扫描sse_read_timeout 设 300 秒以上。同时在 Agent 指令里加一句「如果工具调用超时请重试一次并告知用户」。这样模型在遇到超时时会自己重试而不是直接失败。错误兜底方面MCP 服务端返回的错误信息要结构化比如返回 JSON 格式的 error 字段。Agent 拿到错误后能判断是重试还是告知用户。如果服务端直接抛异常SSE 连接可能断开Dify 侧看到的就是连接中断。工具编排方面多个 MCP 服务可以同时挂载。比如一个查数据库一个查文件系统一个调内部 API。Agent 根据问题类型自动选择。这时候指令里要写清楚每个工具的适用场景否则模型可能选错工具。长期编码场景下可以把 Dify 工作流发布成 API供其他系统调用。这样你的应用不需要自己实现工具调用逻辑直接调 Dify 的 API 就行。Dify 负责 Agent 编排和 MCP 工具调用你只需要传 query 进去拿回复出来。如果你要更深入的 Agent 编排能力比如多轮工具调用、条件分支、循环可以在 Dify 工作流里加判断节点和循环节点。Agent 节点负责单轮工具调用工作流负责整体编排。两者结合能覆盖大部分场景。最后给一个实用技巧在 MCP 服务端加一个 health 检查工具返回服务状态。Dify 工作流启动时先调这个工具确认 MCP 服务可用再继续。这样能避免用户提问后才发现工具服务挂了。接入文档和 API Key 管理在 https://taotoken.net/doc 和 https://taotoken.net/api-keys。模型对话调试可以用 https://taotoken.net/chat。长期跑编码 Agent 的话Coding Plan 在 https://taotoken.net/coding-plan。配置过程中遇到连接问题优先检查 SSE 端点可达性和 Agent 策略选择这两个是最高频的坑。