Dify工作流零代码接入数据库：构建自然语言查询AI助手

在业务开发中，我们经常需要将AI能力与现有业务数据结合，比如让AI助手直接查询数据库来回答用户问题。传统做法需要开发者编写大量API接口和SQL逻辑，不仅耗时，而且对非技术用户极不友好。Dify作为一款开源的LLM应用开发平台，其工作流功能为我们提供了一种优雅的解决方案：通过可视化编排，无需编码即可将数据库查询能力无缝接入AI应用，用户甚至可以用自然语言提问。

本文将手把手带你完成Dify工作流接入数据库查询的全过程。从环境准备、数据库连接配置，到工作流节点编排、SQL与自然语言查询的实现，最后还会深入探讨安全、性能等生产级最佳实践。无论你是想快速搭建一个内部数据查询助手，还是为产品增加智能数据对话功能，这篇教程都能提供完整的闭环实操方案。

1. 背景与核心概念：为什么需要Dify工作流查询数据库？

在深入实操之前，我们有必要厘清几个核心概念，理解这项技术能解决什么问题。

Dify 是一个开源的LLM应用开发平台。你可以把它理解为一个“AI应用工厂”，它提供了可视化的界面，让开发者可以通过拖拽组件（工作流）的方式，快速构建基于大语言模型的应用程序，如智能客服、内容生成、数据分析助手等，而无需从零开始处理模型调用、上下文管理、提示词工程等复杂问题。

工作流 是Dify的核心功能之一。它允许你将复杂的AI应用逻辑拆解成一个个独立的“节点”，并通过连线的方式定义数据流向。每个节点负责一项特定任务，例如：调用大模型、查询知识库、执行代码、或者查询数据库。这种可视化编排极大地降低了AI应用开发的门槛和迭代成本。

传统AI查询数据库的痛点：

1. 开发周期长：需要后端开发API，前端开发界面，处理SQL拼接和防注入。
2. 灵活性差：查询逻辑一旦写死，业务变更就需要改代码、重新部署。
3. 使用门槛高：最终用户（如运营、产品经理）必须学习SQL或依赖技术人员。

Dify工作流方案的优势：

1. 零代码/低代码：通过配置即可完成数据库连接和查询逻辑的搭建。
2. 自然语言交互：用户可以直接用“上个月销售额最高的产品是什么？”这样的问题查询，无需关心SQL语法。
3. 灵活可编排：查询结果可以轻松作为输入，传递给后续的AI总结、格式化或通知节点。
4. 集中安全管理：数据库连接凭证、访问权限在Dify平台统一管理，避免在客户端暴露敏感信息。

接下来，我们将从环境准备开始，一步步实现这个功能。

2. 环境准备与版本说明

为了顺利完成本教程，你需要准备好以下环境。请注意，版本号会随时间迭代，本文以当前主流稳定版本为例，重点是演示配置思路和流程，你的实际版本可能略有不同。

2.1 Dify 部署环境

• 部署方式：Dify支持多种部署方式。对于学习和测试，Docker Compose部署是最简单快捷的。生产环境请参考官方文档进行高可用部署。
• Docker & Docker Compose：确保你的服务器或本地开发机已安装Docker Engine (版本20.10+) 和 Docker Compose (版本v2+)。你可以通过 docker --version 和 docker compose version 命令检查。
• 硬件资源：建议至少2核CPU、4GB内存、20GB磁盘空间。运行大模型和数据库会消耗更多资源。
• 网络：服务器需要能访问互联网以下载Docker镜像和模型（如果使用云端模型API则无需在本地部署模型）。

2.2 数据库环境

Dify工作流支持多种数据库，本教程以最常用的 MySQL 8.0 为例。其他如 PostgreSQL、SQL Server等配置流程类似。

• MySQL：版本 5.7 或 8.0。你可以使用本地安装的MySQL，也可以使用云数据库服务（如阿里云RDS、腾讯云CDB）。确保Dify服务器能够通过网络连接到你的数据库地址和端口（默认3306）。
• 示例数据：我们将创建一个简单的 sales 表用于演示。
  SQL 复制

  1

  CREATE DATABASE IF NOT EXISTS dify_demo;

  2

  USE dify_demo;

  3

   

  4

  CREATE TABLE sales (

  5

  id INT AUTO_INCREMENT PRIMARY KEY,

  6

  product_name VARCHAR(100) NOT NULL,

  7

  sale_date DATE NOT NULL,

  8

  amount DECIMAL(10, 2) NOT NULL,

  9

  region VARCHAR(50)

  10

  );

  11

   

  12

  INSERT INTO sales (product_name, sale_date, amount, region) VALUES

  13

  ('笔记本电脑', '2024-03-15', 8999.00, '华东'),

  14

  ('智能手机', '2024-03-20', 3999.00, '华南'),

  15

  ('平板电脑', '2024-03-10', 2999.00, '华北'),

  16

  ('笔记本电脑', '2024-03-25', 9500.00, '华东'),

  17

  ('智能手机', '2024-03-05', 3599.00, '华中');

2.3 大语言模型配置

Dify工作流需要一个大语言模型来理解自然语言并生成SQL或处理查询结果。你可以选择：

• 云端API：OpenAI GPT系列、Anthropic Claude、国内深度求索、智谱AI等。需要准备相应的API Key。
• 本地模型：通过Ollama、vLLM、Xinference等框架部署本地开源模型（如Qwen、Llama、ChatGLM等）。这对数据隐私要求高的场景非常有用。

本文为简化流程，将使用 OpenAI GPT-3.5-turbo 的API作为示例。请确保你的网络环境可以访问OpenAI服务，并准备好有效的API Key。

3. 核心配置与原理拆解

在Dify中，让工作流查询数据库，核心在于两个环节：1. 配置数据库连接；2. 在工作流中使用“工具”节点。下面我们拆解其原理和关键配置项。

3.1 数据库连接配置原理

Dify并非直接在你的服务器上运行SQL，而是通过一个“连接器”与数据库建立安全的连接。配置时，你需要提供：

• 连接类型：MySQL, PostgreSQL, SQL Server等。
• 连接信息：主机地址、端口、数据库名。
• 认证信息：用户名和密码。Dify会加密存储这些凭证。
• SSL：生产环境强烈建议启用SSL加密连接，防止数据在传输中被窃听。

关键点：这个连接是配置在Dify平台层面的，一旦配置好，就可以在所有工作流中复用，实现了连接的统一管理和安全控制。

3.2 SQL查询与自然语言查询的转换原理

这是实现“自然语言提问”的关键，其流程通常如下：

1. 用户输入：用户提问：“华东地区三月份的销售额是多少？”
2. LLM理解与转换：Dify调用大语言模型，结合你预先提供的数据库表结构信息（Schema），将自然语言问题转换为一条标准的SQL语句。
   • 例如，转换为：SELECT SUM(amount) FROM sales WHERE region = ‘华东’ AND MONTH(sale_date) = 3;
3. 执行与安全校验：Dify在后台执行这条生成的SQL。高级配置下，可以设置允许执行的SQL模式（如仅允许SELECT，禁止DROP, DELETE等），这是一个重要的安全屏障。
4. 结果获取与格式化：获取数据库返回的原始数据（如一行一列的数字：12599.00）。
5. LLM结果解读：再次调用大语言模型，将原始数据格式化为人类友好的回答。
   • 例如，生成：“华东地区三月份的销售总额为 12,599.00 元。”

这个过程可以在一个精心设计的工作流中自动完成。接下来，我们就开始实战。

4. 完整实战案例：构建智能销售数据查询助手

假设我们已经有一个运行起来的Dify服务（访问地址如 http://localhost:3000），并且完成了初始管理员账号设置。

4.1 第一步：在Dify中配置数据库连接

1. 登录Dify控制台，进入 “设置” -> “数据源” 页面。
2. 点击 “添加数据源”，选择 “数据库” 类型。
3. 填写数据库连接信息：
   • 类型：MySQL
   • 主机：填写你的数据库服务器地址（本地可用 127.0.0.1 或 host.docker.internal 如果Dify用Docker运行）
   • 端口：3306
   • 用户名/密码：你的数据库账号密码
   • 数据库名称：dify_demo (我们之前创建的库)
   • SSL：测试环境可先关闭。生产环境务必开启并配置CA证书。
4. 点击 “测试连接”，确保显示“连接成功”。
5. 连接成功后，点击 “保存”。系统会提示你为这个连接命名，例如 销售数据库。

关键提示：如果Dify通过Docker部署，而数据库在宿主机本地，使用 localhost 可能无法连通，因为Docker容器内的 localhost 指向容器自身。此时应使用宿主机对Docker网络的IP，或使用特殊的DNS名称 host.docker.internal (Docker Desktop支持)。

4.2 第二步：创建并配置工作流

1. 进入 “工作流” 页面，点击 “创建空白工作流”，命名为 销售数据查询助手。
2. 我们将从左侧的节点库中，拖拽需要的节点到画布上进行编排。一个典型的自然语言查询数据库工作流包含以下节点：
   • 开始节点：接收用户问题。
   • LLM节点（用于生成SQL）：调用大模型，将问题转为SQL。
   • 工具节点（数据库查询）：执行上一步生成的SQL。
   • LLM节点（用于格式化答案）：将查询结果转为自然语言回答。
   • 结束节点：输出最终答案。

4.3 第三步：编排工作流节点

我们按顺序配置每个节点。

节点1：开始

• 无需特殊配置，它代表工作流的输入入口。

节点2：LLM（生成SQL）

1. 拖入一个 “LLM” 节点，将其与 “开始” 节点连接。
2. 在右侧面板配置该LLM：
   • 模型：选择你已配置好的模型，如 gpt-3.5-turbo。
   • 提示词：这是核心！你需要编写一个“系统提示词”来指导LLM如何生成SQL。
   TEXT 复制

   1

   你是一个专业的SQL专家。请根据用户关于销售数据的问题，生成一条标准的MySQL查询语句。

   2

   数据库表结构如下：

   3

   表名：sales

   4

   字段：

   5

   - id (整数，主键)

   6

   - product_name (字符串，产品名称)

   7

   - sale_date (日期，销售日期)

   8

   - amount (小数，销售金额)

   9

   - region (字符串，销售区域)

   10

    

   11

   请遵守以下规则：

   12

   1. 只生成SQL语句，不要有任何额外的解释或说明。

   13

   2. 使用合法的MySQL语法。

   14

   3. 如果问题中涉及“本月”、“上周”等时间，请使用CURDATE()、DATE_SUB等函数进行换算。

   15

   4. 如果问题模糊，优先查询所有数据（SELECT * FROM sales LIMIT 10）。

   16

    

   17

   用户问题：{{#start.input#}}
   • 变量：{{#start.input#}} 是一个变量，它会自动绑定到“开始”节点接收到的用户输入上。
   • 输出变量：将本节点的输出变量名设置为 generated_sql，供后续节点使用。

节点3：工具（数据库查询）

1. 拖入一个 “工具” 节点，将其与上一个LLM节点连接。
2. 在右侧面板，点击 “添加工具”，选择我们之前配置好的 销售数据库 连接。
3. 在 “SQL查询” 输入框中，不要直接写SQL，而是通过变量引用上一步生成的SQL：{{#generated_sql#}}。
4. 此节点的输出（查询结果）会自动存储为一个变量，如 query_result。

节点4：LLM（格式化答案）

1. 再拖入一个 “LLM” 节点，连接到“工具”节点之后。
2. 配置模型（可与第一个相同）。
3. 配置提示词：
   TEXT 复制

   1

   你是一个友好的数据分析助手。请根据提供的SQL查询结果，用清晰、易懂的自然语言回答用户的原始问题。

   2

    

   3

   用户原始问题是：{{#start.input#}}

   4

   执行查询后得到的结果数据是：{{#query_result#}}

   5

    

   6

   请直接给出答案，如果结果是数字，请加上合适的单位（如“元”）。如果结果是一个列表，请简要概括。
4. 此节点的输出就是最终答案。

节点5：结束

1. 拖入 “结束” 节点，连接上一个LLM节点。
2. 在右侧面板，将 “输出” 设置为 {{#LLM_2.output#}}（假设第二个LLM节点的变量名是 LLM_2.output），这样工作流的最终输出就是格式化后的答案。

至此，一个完整的工作流就编排好了。画布上的连线应该清晰展示数据流向：开始 -> LLM(生成SQL) -> 工具(执行查询) -> LLM(格式化) -> 结束。

4.4 第四步：运行与验证

1. 点击画布右上角的 “保存” 按钮。
2. 然后点击 “运行” 按钮，会弹出测试窗口。
3. 在测试窗口的输入框中，尝试输入不同的自然语言问题：
   • 测试1：“列出所有销售记录。”
     • 预期：LLM应生成 SELECT * FROM sales;，并返回格式化的5条记录列表。
   • 测试2：“华东地区的总销售额是多少？”
     • 预期：LLM应生成 SELECT SUM(amount) FROM sales WHERE region = ‘华东’;，返回结果应为 18499.00，格式化后输出“华东地区的总销售额是 18,499.00 元。”
   • 测试3：“三月份销售额最高的产品是什么？”
     • 预期：LLM可能生成 SELECT product_name, SUM(amount) FROM sales WHERE MONTH(sale_date)=3 GROUP BY product_name ORDER BY SUM(amount) DESC LIMIT 1;，最终回答“三月份销售额最高的产品是笔记本电脑。”

观察每个节点的运行状态和中间变量（如生成的SQL），确保流程按预期执行。如果出错，根据错误信息排查，常见问题见下一章节。

4.5 第五步：发布为应用

工作流测试无误后，就可以发布成一个独立的AI应用供他人使用。

1. 在工作流编辑页面，点击右上角 “发布”。
2. 填写应用名称、图标、描述等信息。
3. 发布后，你会获得一个独立的Web应用链接和API接口。你可以将这个链接分享给团队成员，他们就可以通过网页或API直接向这个“智能助手”提问销售数据了。

5. 常见问题与排查思路

在实际配置和运行中，你可能会遇到以下问题。这里提供一份排查清单。

6. 最佳实践与工程建议

将数据库查询接入AI工作流非常强大，但若想用于生产环境，必须考虑安全、性能和可维护性。

6.1 安全第一：严防SQL注入与数据泄露

• 最小权限原则：为Dify创建的数据库用户分配最小必要权限。对于只读查询场景，只授予 SELECT 权限，绝不能授予 DROP, DELETE, UPDATE, ALTER 等权限。
  SQL 复制

  1

  CREATE USER ‘dify_query’@‘%’ IDENTIFIED BY ‘StrongPassword!’;

  2

  GRANT SELECT ON dify_demo.* TO ‘dify_query’@‘%’;

  3

  FLUSH PRIVILEGES;
• 限制查询范围：在Dify的数据源配置中，可以设置“允许的数据库”和“允许的表”。尽量将连接限制在特定的数据库和表上，避免LLM意外查询或泄露其他敏感数据。
• 审核生成的SQL：对于高安全要求场景，可以在工作流中增加一个“人工审核”节点，或者先让LLM生成的SQL在一个“沙盒”环境（如只包含测试数据的镜像库）中执行，确认无误后再查询生产库（这需要更复杂的工作流设计）。
• 启用SSL加密：生产环境务必启用数据库的SSL连接，并在Dify中正确配置CA证书，保证数据传输安全。
• 输入过滤与日志：对用户输入进行基础的关键词过滤（虽然LLM本身有一定抗注入能力，但非绝对），并完整记录生成的SQL和执行结果日志，便于审计和追溯。

6.2 性能优化：提升查询与响应速度

• 数据库索引：针对高频查询条件（如 sale_date, product_name, region）建立索引，这是提升查询性能最有效的手段。
• 查询超时设置：在Dify的工具节点或数据库连接配置中，设置合理的查询超时时间（如30秒），避免慢查询拖垮整个工作流。
• 分页查询：如果预期结果集很大，应在提示词中指导LLM生成带 LIMIT 子句的SQL。或者，在工作流中设计分页逻辑，先查询数量，再分批获取数据。
• LLM上下文优化：提供给LLM的表结构信息应尽可能简洁。如果表很多，不要一次性提供所有Schema，而是通过更智能的方式（如先让LLM选择表名）动态加载，以减少Token消耗和模型负担。
• 结果缓存：对于重复性高、实时性要求不高的查询（如“昨日销售总额”），可以考虑在工作流中引入缓存节点，将结果缓存一段时间（如Redis），下次相同查询直接返回缓存结果。

6.3 提示词工程：让LLM更可靠

• 提供清晰的示例：在系统提示词中，给出1-2个“用户问题 -> 标准SQL”的示例，能极大提高LLM转换的准确率。
  TEXT 复制

  1

  示例：

  2

  用户问题：”今年第一季度每个区域的销售额是多少？“

  3

  生成SQL：SELECT region, SUM(amount) FROM sales WHERE sale_date >= ‘2024-01-01’ AND sale_date < ‘2024-04-01’ GROUP BY region;
• 指定日期处理逻辑：时间问题是自然语言查询的难点。明确告诉LLM你的“业务当前日期”是什么（例如“当前日期是2024-03-27”），并给出处理“上周”、“本月”、“去年同期”的SQL函数范例。
• 处理模糊查询：当用户问题非常模糊时（如“看看数据”），定义好默认行为，例如返回最近10条记录或要求用户澄清。
• 迭代优化：提示词不是一蹴而就的。持续收集测试中LLM生成错误的案例，分析原因，并反过来优化你的提示词。

6.4 架构与可维护性

• 连接池管理：Dify后台应已管理数据库连接池。确保你的数据库服务器配置了足够的最大连接数，以应对并发查询。
• 工作流版本化：Dify支持工作流版本管理。每次对生产环境使用的工作流进行修改时，先创建新版本进行测试，稳定后再切换，实现平滑升级和快速回滚。
• 监控与告警：监控工作流的执行成功率、平均耗时、数据库查询耗时等指标。设置告警，当错误率或延迟超过阈值时及时通知负责人。
• 文档化：为每个工作流编写清晰的文档，说明其功能、使用的数据源、涉及的敏感表、以及提示词的设计思路。这对于团队协作和后续维护至关重要。

通过以上步骤，你不仅能够快速搭建一个可用的数据库查询助手，更能构建一个安全、高效、可维护的生产级智能数据查询应用。Dify工作流将复杂的后端开发、SQL编写和AI集成过程，简化为可视化的配置与编排，让开发者能更专注于业务逻辑和创新。