企业官网建设流程全解析

1. 为什么要在 Dify 里接 SQLBot 的 MCP 数据引擎

如果你正在用 Dify 搭智能体，又希望它能直接回答“上个月华东区退货率是多少”这类问题，而不是每次都手动写 SQL、导 CSV、再贴进对话里，那 SQLBot 的 MCP 数据引擎就是那个值得接进来的部件。SQLBot 负责把自然语言翻译成 SQL 并执行查询，MCP 负责把它的能力以标准工具的形式暴露出来，Dify 则负责编排整个对话流程。三者串起来之后，你的智能体就具备了“自然语言查库”的能力。

这篇内容面向的是已经会用 Dify 拖工作流、但对 MCP 协议还不太熟的开发者。我会把整条链路拆成两种落地方式：一种是工具调用，工作流由你手动搭，稳定可控；另一种是 AI 自动调用，靠提示词让 Agent 自己决定什么时候调mcp_start、什么时候调mcp_question，搭起来快，适合轻量场景。两种方式我都会给出可复制的配置片段、settings.json骨架，以及连通性验证动作，目标是让你一次跑通从 Dify 到 SQLBot 的查询链路。

先说清楚一个容易踩的坑：SQLBot 的 MCP 服务不是无状态的。第一次调用mcp_start会返回access_token和chat_id，后续的mcp_question必须带着这两个值才能继续问数。很多人第一次接的时候只调了mcp_question，结果一直报鉴权失败，就是因为漏了这一步。理解了这一点，后面的配置就顺了。

2. TaoToken 前置：把模型和 Key 准备好

在动 Dify 之前，先把模型侧的事情理清楚。Dify 里的 Agent 节点、代码执行节点都需要一个能稳定调用的模型服务，而 MCP 工具本身也需要一个 API Key 来做授权。我习惯把这两件事放在 TaoToken 上统一处理，省得在多个平台之间来回切。

TaoToken 的定位是给开发者和智能体应用提供模型调用与密钥管理的能力。你可以把它理解成一个“模型接入层”：Dify 通过它拿到对话模型，MCP 服务通过它拿到授权凭证。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api ，注意 API 地址后面不加 UTM 参数，配置的时候别多写。

具体要准备两样东西。第一是模型对话能力，用来驱动 Dify 里的 Agent 和代码节点，入口在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，进去之后创建一个 Key，复制出来备用。第二是 Coding Plan，如果你打算长期跑编码类或 Agent 类任务，用套餐会比按量更划算，入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。创建完 Key 之后，建议先去模型对话页面做一次最小验证，确认 Key 是通的，入口在 https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite 。

这里有个细节值得说：MCP 服务端的settings.json里需要填 API Key，这个 Key 和 Dify 里模型用的 Key 可以是同一个，也可以分开。我建议分开，因为 MCP 服务的调用频率和模型调用频率不一样，分开之后排查问题更清晰。控制台地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，在里面可以查看用量和 Key 状态。

注意：所有 Key 都不要硬编码在前端或公开仓库里。Dify 的工作流配置里引用变量，MCP 的settings.json放在服务端本地，这是最低要求。

3. 可复制配置：MCP 服务端 settings.json 骨架

SQLBot 的 MCP 服务端需要一份配置文件来声明它暴露哪些工具、连哪个数据库、用什么传输方式。下面这份骨架你可以直接拿去改，重点是transport和url两个字段。

{ "sqlbot_mcp": { "url": "http://<YOUR_IP>/mcp", "transport": "sse", "api_key": "<YOUR_TAOTOKEN_API_KEY>", "tools": { "mcp_start": { "description": "初始化会话，返回 access_token 和 chat_id", "params": ["username", "password"] }, "mcp_question": { "description": "基于自然语言提问执行查询", "params": ["chat_id", "question", "token"] } } } }

把<YOUR_IP>换成你部署 SQLBot MCP 服务的实际地址，<YOUR_TAOTOKEN_API_KEY>换成你在 TaoToken 控制台创建的 Key。transport用sse是因为 Dify 的“发现和调用 MCP 工具”组件目前对 SSE 支持最稳，如果你用 streamable HTTP，部分版本会有握手超时的问题。

这份配置在 Dify 里有两个填法：一是直接写在“调用 MCP 工具”组件的 MCP 服务配置框里，二是放在 API Key 授权配置里统一管理。我推荐后者，因为工作流里可能有多个 MCP 调用节点，统一管理改一处就行。配置完之后，Dify 会去拉取工具列表，如果拉不到，先检查url能不能在服务器上curl通。

curl -N http://<YOUR_IP>/mcp

正常的话你会看到 SSE 流保持连接，说明服务端活着。如果返回 404 或连接被拒，那就是地址或端口的问题，跟 Dify 无关，先把这步解决。

4. 方案一：工具调用工作流，手动搭但最稳

工具调用的思路是：你手动把每个节点连起来，用条件分支判断有没有access_token，没有就先调mcp_start拿，有就直接调mcp_question。整条链路清晰，出问题容易定位。

4.1 开始节点与会话变量

在开始组件的输入字段里加两个参数：username、password。然后在工作流的会话变量里加两个：access_token（String 类型）、chat_id（Number 类型）。这两个变量是跨节点传递的关键，尤其是第二次问数的时候，必须复用第一次拿到的 token，否则会重新走一遍mcp_start，既慢又可能触发限流。

4.2 条件分支判断 token 是否为空

加一个条件分支节点，条件写access_token为空。为空走“获取 token”分支，不为空直接走“问数”分支。这个判断是整个工作流的分水岭，也是很多人漏掉的一步——如果不判断，每次都调mcp_start，虽然能跑通，但效率低。

4.3 调用 mcp_start 获取凭证

在“发现和调用 MCP 工具”组件里选“调用 MCP 工具”，工具名称填mcp_start，参数填：

{ "username": "引用变量：开始/username", "password": "引用变量：开始/password" }

MCP 服务配置填第 3 节那份settings.json里的sqlbot_mcp内容。设置里把“MCP 资源作为工具”和“MCP 提示词作为工具”都选true。调用成功后，返回的text里是一段 JSON，包含data.chat_id和data.access_token。

4.4 代码执行节点做 JSON 标准化

加一个代码执行组件，输入变量arg1接上一步的text，Python 代码这样写：

import json def main(arg1: str) -> dict: json_obj = json.loads(arg1) return { "chat_id": json_obj["data"]["chat_id"], "access_token": json_obj["data"]["access_token"] }

输出变量加chat_id（Number）和access_token（String）。这一步的作用是把嵌套的 JSON 拍平，方便后面引用。

4.5 变量赋值节点回写会话变量

用变量赋值组件，把代码执行输出的chat_id和access_token分别赋给会话变量。这一步做完，后面的节点就能通过会话变量拿到凭证了。

4.6 调用 mcp_question 执行问数

再加一个“调用 MCP 工具”组件，工具名称填mcp_question，参数填：

{ "chat_id": "引用会话变量：chat_id", "question": "引用变量：开始/sys.query", "token": "引用会话变量：access_token" }

注意chat_id是 Number 类型，引用时不要加引号；question和token是 String，正常引用即可。设置里第一个选true，第二个选false。最后接一个直接回复组件，把mcp_question的text结果展示出来。

5. 方案二：AI 自动调用，靠提示词让 Agent 自己编排

如果你不想手动连这么多节点，可以用 Agent 的 FunctionCalling 模式，让模型自己决定调用顺序。这种方式搭起来快，但稳定性依赖提示词质量。

5.1 开始节点与 Agent 配置

开始节点同样加username、password。然后加一个 AGENT 组件，Agent 策略选“支持 MCP 工具的 Agent”，模型选 FunctionCalling 模式。MCP 服务配置同上，设置里“MCP 资源作为工具”选true，“MCP 提示词作为工具”选false。最大迭代次数调到 10，记忆窗口调到 20。

5.2 指令提示词模板

指令部分直接抄这份：

# 回答要求： 按需调用 mcp_start 和 mcp_question 工具获取信息回答问题。 mcp_start 账号密码： username: 引用变量：开始/username password: 引用变量：开始/password 工具调用逻辑： 首先调用 mcp_start 工具，获取 access_token 和 chat_id，帮我记住这两个参数， 之后不要重复调用 mcp_start，直接使用即可； 然后再调用 mcp_question 工具，其中 token 和 chat_id 参数是调用 mcp_start 工具返回， question 是用户提问。 # 用户提问： 引用变量：开始/sys.query

这段提示词的关键是“不要重复调用 mcp_start”这句，不加的话模型可能每轮都重新初始化，导致 token 失效。最后接直接回复组件，把 Agent 输出的text展示出来。

6. 验证请求与成功结果

配置完之后，怎么确认链路是通的？我一般分三步验证。

第一步，单独测 MCP 服务端。用curl发一个mcp_start请求，看能不能拿到access_token和chat_id。这一步过了，说明服务端和数据库是通的。

第二步，在 Dify 里跑一次工具调用工作流，输入username、password和一个简单问题，比如“查一下订单总数”。如果直接回复节点输出了数字和 SQL 语句，说明 Dify 到 SQLBot 的链路通了。

第三步，跑一次 AI 自动调用，同样的问题，看 Agent 是不是先调mcp_start再调mcp_question。如果 Agent 跳过了mcp_start直接调mcp_question并报错，那就是提示词里“先调 mcp_start”的约束不够强，把这句话加粗或放到最前面。

成功的标志是：直接回复里能看到查询结果，同时日志里能看到两次 MCP 调用记录，第一次是mcp_start，第二次是mcp_question。

7. 本篇常见错排查

报错一：mcp_question返回 401 或 token invalid。九成是access_token没传对。检查变量赋值节点有没有把代码执行的输出正确回写，以及mcp_question的参数里token是不是引用了会话变量而不是代码执行的临时输出。临时输出在第二次问数时是空的，这就是为什么要用会话变量。

报错二：Dify 拉不到 MCP 工具列表。先确认url在 Dify 服务器上能curl通，再确认transport是sse。如果服务端用的是 streamable HTTP，换成 SSE 再试。另外检查settings.json里的api_key有没有过期。

报错三：Agent 反复调用mcp_start。提示词里明确写“获取后记住，不要重复调用”，并且把mcp_start的账号密码放在指令里而不是让模型自己猜。如果还不行，把最大迭代次数降到 5，逼模型尽快收敛。

报错四：代码执行节点报 JSON 解析失败。说明mcp_start返回的text不是纯 JSON，可能带了额外的前后缀。在 Python 里加一层容错：

import json import re def main(arg1: str) -> dict: match = re.search(r'\{.*\}', arg1, re.DOTALL) json_obj = json.loads(match.group()) return { "chat_id": json_obj["data"]["chat_id"], "access_token": json_obj["data"]["access_token"] }

报错五：问数结果为空但没报错。检查question参数有没有正确引用sys.query，以及数据库里确实有数据。有时候是 SQLBot 的权限配置没放开对应表，去 SQLBot 后台确认一下。

8. 接下来怎么走

如果你只是想让智能体具备查库能力，工具调用方案已经够用了，稳定、可控、好排查。如果你要做的是一套长期运行的 Agent，比如每天自动跑报表、或者嵌入到客服系统里，那建议走 Coding Plan，把模型调用和 MCP 授权统一管理，入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有 MCP 相关的参数说明和示例。Key 管理还是去 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。

最后留一个我踩过的坑：MCP 服务端的settings.json改完之后一定要重启服务，不然 Dify 拉到的还是旧配置。这个坑我排查了半小时才发现，希望你别再踩。