1. 为什么要把 Dify 工作流发布成 MCP 工具服务

Dify 的工作流编排能力很强，但默认情况下它只能在 Dify 自己的对话界面里跑。如果你想让 Cherry Studio、Cline、Claude Code 这类支持 MCP 的客户端直接调用你的工作流，就得把工作流"暴露"成一个标准的 MCP 工具服务。这件事的价值在于：你辛苦调好的知识库检索、多步推理、参数化流程，不用在每个客户端里重写一遍，一次发布，处处调用。

MCP（Model Context Protocol）本质上是给大模型客户端定义了一套"怎么发现工具、怎么传参、怎么拿结果"的协议。Dify 通过官方的 MCP Server 插件，把工作流包装成两种形态：一种是 SSE 长连接服务，一种是可流式传输的 HTTP 服务。前者适合常驻连接，后者更适合 Cherry Studio 这种按需调用的客户端。

适合谁看这篇：已经在用 Dify 跑工作流、想把它接进自己常用 AI 客户端的人；正在搭多智能体系统、需要跨平台复用工具的人；以及被"发布后调不通"卡住的同学。我实测下来，最容易翻车的不是 Dify 里的配置，而是 plugin_daemon 的端口没暴露——这个坑后面会重点讲。

整条链路分四段：Dify 里装 MCP Server 插件 → 暴露 plugin_daemon 端口 → 把工作流注册成 MCP 服务 → 在 Cherry Studio 里作为工具调用。模型凭证这块，我建议统一走 TaoToken 的 API 通道管理，这样 Dify 和 Cherry 两边不用各配一套 Key，换模型时只改一处。

2. TaoToken 前置准备：统一 Key 与 API 通道

在动手配 MCP 之前，先把模型凭证这条线理顺。Dify 工作流里如果用到 LLM 节点，它需要调用模型；Cherry Studio 里的助手也需要调用模型。如果两边各自配 Key，管理起来很乱，尤其是你同时用 Claude、GPT、DeepSeek 多个模型的时候。

TaoToken 的做法是给你一个统一的 API 入口和 Key，模型调用都走这个通道。官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api 。你注册后在控制台生成 Key，然后 Dify 和 Cherry 都填同一个 Base URL 和 Key 就行。

具体操作路径：

先去控制台创建 API Key，地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 。生成后复制出来，注意 Key 只显示一次，丢了就得重建。

然后在 Dify 的模型供应商配置里，选择 OpenAI 兼容类型，Base URL 填https://taotoken.net/api，API Key 填你刚生成的。模型名按你实际要用的填，比如claude-sonnet-4-5或gpt-4o这类。Dify 里配置模型供应商的入口在"设置 → 模型供应商"，添加自定义 OpenAI 兼容供应商即可。

Cherry Studio 那边同理，在"设置 → 模型服务"里添加一个 OpenAI 兼容的服务，Base URL 和 Key 填一样的。这样两边共用一套凭证，后面换模型只改这一处。

如果你还没决定用哪些模型，可以先去模型对话页面看看有哪些可用：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 。长期跑编码和 Agent 任务的话，Coding Plan 会更划算，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。

这里有个细节要注意：Dify 的 MCP Server 插件本身不负责模型调用，它只负责把工作流暴露成 HTTP 服务。模型调用还是发生在工作流内部的 LLM 节点里，所以 Dify 的模型供应商配置必须是对的，否则工作流跑不起来，MCP 服务自然也没结果。

配置完成后，建议先在 Dify 里手动跑一次工作流，确认 LLM 节点能正常返回。这一步过了，再往下做 MCP 发布，能省掉很多排查时间。

3. 可复制配置：插件安装与 plugin_daemon 端口暴露

这一节是整篇的核心，配置错了后面全白搭。我按顺序给你可复制的片段。

3.1 安装 MCP Server 插件

进入 Dify 的插件页面，点"探索 Marketplace"，搜索mcp server，找到官方那个 MCP Server 插件点安装。安装过程会拉取镜像，网络慢的话多等一会。

安装完成后，插件会出现在"已安装"列表里。这时候别急着配工作流，先把端口问题解决。

3.2 暴露 plugin_daemon 的 5002 端口

这是最多人踩的坑。Dify 的插件都跑在plugin_daemon这个容器里，MCP Server 把工作流转成 HTTP 服务时，需要借助 plugin_daemon 自身的端口。默认情况下这个端口没对外暴露，所以你在 Cherry 里填了 URL 也连不上。

打开你的docker-compose.yaml，找到plugin_daemon服务，在ports里加上 5002：

plugin_daemon: image: langgenius/dify-plugin-daemon:0.1.2-local restart: always ports: - "${EXPOSE_PLUGIN_DEBUGGING_PORT:-5003}:${PLUGIN_DEBUGGING_PORT:-5003}" - "${PLUGIN_DAEMON_PORT:-5002}:${PLUGIN_DAEMON_PORT:-5002}/tcp" # 新增这一行

改完执行docker compose up -d plugin_daemon重建容器。注意是up -d不是restart，因为端口映射变了，必须重建。

注意：如果你用的是 Dify 官方的一键部署脚本，docker-compose.yaml可能在dify/docker目录下。改之前先备份一份，改错了能回滚。

验证端口是否生效，在宿主机执行：

curl -v http://localhost:5002/health

如果返回 200 或类似健康检查响应，说明端口通了。如果 connection refused，检查容器是否真的重建了，用docker ps看 plugin_daemon 的端口映射列。

3.3 把工作流注册成 MCP 服务

回到 Dify 界面，点右上角的"插件"，找到 MCP Server 点开，右侧会弹出面板。点"+"号添加服务。

在 APP 里选中你要发布的工作流，选择应用类型，然后添加工作流的参数。这里可以设置 Bearer Token 做安全认证，内网环境看业务需求，公网暴露的话强烈建议设一个。

参数定义这块，官方文档没写清楚 description 字段，但实测加上是生效的。比如我的工作流有两个参数category和query，配置如下：

{ "name": "dify_meta", "description": "通过元数据检索知识库", "inputSchema": { "properties": { "category": { "title": "category", "type": "string", "description": "元数据分类" }, "query": { "title": "query", "type": "string", "description": "检索关键词" } }, "required": ["category", "query"], "title": "metaArguments", "type": "object" } }

保存后，面板里会生成两类服务地址：一类以sse结尾（SSE 服务），一类以mcp结尾（可流式传输的 HTTP）。Cherry Studio 用后者。

关键点：使用链接时，必须把 plugin_daemon 的端口加上。比如 Dify 默认跑在 80 端口，但 MCP 服务的实际地址是http://你的IP:5002/...，不是 80。很多人复制了 Dify 显示的 URL 直接用，结果连不上，就是漏了 5002。

4. 验证请求：Cherry Studio 端到端调用

配置完服务端，到 Cherry Studio 里接。

打开 Cherry Studio，进入"设置 → MCP 服务器"，添加一个新的。类型选"可流式传输的 HTTP"（streamable HTTP），URL 填你从 Dify 复制的那条mcp结尾的地址，注意带上 5002 端口。名称随便起，我叫它dify-mcp。

如果 Dify 那边设了 Bearer Token，Cherry 这边在请求头里加上：

{ "Authorization": "Bearer 你的token" }

保存后，点"工具"标签，应该能看到可用的工具列表。如果能看到你工作流里定义的参数，说明配置正常。

然后在助手里，选择 MCP 服务器，勾选dify-mcp。发一条测试消息，比如"帮我检索 category 为 tech 的 query 内容"。Cherry 会调用 MCP 工具，把参数传给 Dify 工作流，工作流跑完把结果返回。

验证成功的标志有两个：一是 Cherry 里能看到工具调用返回的内容；二是回到 Dify 对应工作流的"日志"页面，能看到这次调用记录和日志跟踪。

我实测时遇到一个现象：Cherry 调用返回没数据，但拿同样的条件去 Dify 工作流里手动检索，数据是有的。对比两次调用，唯一区别是用户不同。我一度以为是知识库权限问题，放开了权限还是查不到。这个我暂时作为跟进问题处理，如果你也遇到，可以先检查工作流里知识库节点的用户上下文传递。

提示：Cherry 调用时如果报local proxy failed，多半是 URL 或端口不对，重点检查 5002 有没有带上、容器有没有重建。如果报 401，检查 Bearer Token 是否一致。

5. 本篇常见错排查

这一节按真实报错来，都是我或身边人踩过的。

报错一：local proxy failed或连接超时

最常见。原因九成是 plugin_daemon 的 5002 端口没暴露，或者暴露了但容器没重建。排查步骤：docker ps看 plugin_daemon 的 PORTS 列有没有0.0.0.0:5002->5002/tcp。没有就回去改docker-compose.yaml并docker compose up -d plugin_daemon。有的话，在宿主机curl http://localhost:5002/health测一下。

报错二：401 Unauthorized

Dify 那边设了 Bearer Token，Cherry 这边没填或填错。检查两边的 token 字符串完全一致，注意别多复制了空格。如果 Dify 没设 token，Cherry 这边请求头就别加 Authorization。

报错三：reading choices相关错误

这个通常不是 MCP 层的问题，而是工作流内部 LLM 节点调用模型失败。检查 Dify 的模型供应商配置，Base URL 是不是https://taotoken.net/api，Key 有没有过期，模型名对不对。可以先去模型对话页面确认模型可用。

报错四：工具列表为空

Cherry 里点"工具"看不到任何工具。原因可能是工作流没正确注册，或者参数 schema 格式不对。回 Dify 的 MCP Server 面板，确认服务状态是正常的，参数 JSON 没有语法错误。required数组里的字段必须在properties里有定义。

报错五：OAuth 相关报错

如果你在 Cherry 里选了 OAuth 认证方式，但 Dify 这边只支持 Bearer Token，就会报 OAuth 错误。把认证方式改成 Bearer Token 或 None，别选 OAuth。

关于 Codex auth.json / Cline MCP / CC Switch

如果你同时用 Cline 或 Claude Code，它们的 MCP 配置也是三件套：Base URL、Key、Model ID。Cline 的 MCP 配置在cline_mcp_settings.json，Claude Code 在~/.claude/settings.json或项目级配置里。Codex 的auth.json里配的是模型凭证，和 MCP 是两回事，别混。CC Switch 用来切换不同配置，把 Dify MCP 的地址和 TaoToken 的 Key 分别存成 profile，切换时不用手改。

排查顺序建议：先确认端口通 → 再确认 token 对 → 再确认工作流能手动跑通 → 最后看客户端配置。按这个顺序，基本能定位到问题层。

6. 长期使用建议与接入入口

跑通之后，日常使用有几个点值得注意。

第一，工作流改动后，MCP 服务不用重新发布，Dify 会自动同步。但如果你改了参数 schema，Cherry 那边要重新加载工具列表才能看到新参数。

第二，Bearer Token 建议定期轮换，尤其是公网暴露的场景。轮换后记得同步更新所有客户端的配置。

第三，如果你要接多个客户端（Cherry、Cline、Claude Code），建议把 MCP 服务地址和 Token 记在一个地方，避免每个客户端各配一套对不上。

第四，模型凭证统一走 TaoToken 的 API 通道，Dify 和 Cherry 共用一套 Base URL 和 Key。这样换模型时只改一处，不用每个客户端翻一遍。API Key 管理入口在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。

如果你主要跑编码和 Agent 任务，Coding Plan 的额度模型更适合长期用，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。Claude Code 相关的接入配置可以参考 https://taotoken.net/claude-code?utm_source=taotoken_aicg_blog_end&utm_content=claudecode&utm_campaign=rewrite 。

最后说个实操技巧：Dify 工作流的日志页面是排查 MCP 调用问题的最佳入口。每次 Cherry 调用都会在日志里留记录，能看到传入的参数和返回的结果。如果客户端显示没数据但日志里有返回，那就是客户端解析的问题；如果日志里就没数据，那就是工作流内部的问题。按这个二分法，能快速缩小范围。