Dify 没有 MySQL 节点？三种方案让 AI 安全查询数据库-代码聚汇网

Dify 没有 MySQL 节点？三种方案让 AI 安全查询数据库

SeigRobotics·2026-09-01·阅读 21 GEO检测（免费）

DifyMySQLLLM应用编排

|难度：普通|阅读约 39 分钟

我接到过一个挺常见的需求：公司内部已经在用 Dify 搭了一套客服问答应用，某天业务方突然提了个新要求——“能不能让机器人直接查一下订单库，回答‘最近 7 天退了多少单’这种问题？”我满口答应，打开 Dify 工作流，准备拖一个“MySQL 节点”，结果翻遍节点列表：LLM、知识检索、代码执行、HTTP 请求、条件分支……偏偏没有数据库查询节点。那一瞬间确实有点懵。

后来我把这条链路彻底跑通了，也踩了不少坑。Dify 本身是一个 LLM 应用编排平台，核心价值是把提示词、知识库、工作流、Agent 串起来；它不是一个数据库客户端，也不可能内置所有数据库能力。要让 Dify 访问 MySQL，本质上是“用 Dify 现有节点去桥接数据库”，而桥接方式不止一种，选型对不对，直接影响后面好不好维护。

这篇文章就把我从“Dify 没有 MySQL 节点”到“AI 能稳定回答数据库问题”的完整过程写出来，包括三种接入方式的取舍、具体的代码和配置、以及我实际踩过的坑。适合正在用 Dify 做应用、需要让它读数据库的开发者参考。

1. 为什么 Dify 没有现成的“MySQL 节点”：三种接法怎么选

1.1 Dify 工作流的边界：它擅长什么，不擅长什么

先说清楚 Dify 的定位。Dify 工作流里最核心的节点就是 LLM 节点、知识检索节点、代码节点、HTTP 请求节点。它擅长的是“理解和表达”——比如理解用户问题、编排多步推理、把结果用自然语言组织出来；它不擅长的是“直接和基础设施打交道”，比如连接数据库、维护连接池、处理 SQL 事务。

不是说 Dify 做不了，而是它刻意把这些能力做成了通用接口，让开发者自己接。这样设计有个好处：你不需要等官方出一个“MySQL 节点”才能用，任何能通过代码或 HTTP 暴露的数据源，理论上都能接进来。坏处就是，第一次上手会有点懵，不知道从哪下手。

我在实际项目里总结了三种常见接法：代码节点直连、HTTP 请求节点调自建 API、自定义工具接入 Agent。三种方式各有适用场景，下面展开细说。

1.2 三种桥接方案的取舍对比

接入方式	实现思路	优点	缺点	适合场景
代码节点直连	在工作流里用 Python + PyMySQL/SQLAlchemy 执行 SQL	路径短、见效快；不需要额外部署服务	沙箱依赖受限；SQL 写在工作流里不好审计；不适合复杂查询	原型验证、内部工具、低频查询
HTTP 请求 + 自建 API	自己写一个只读查询接口，Dify 用 HTTP 节点调用	安全可控；连接池、权限、审计都在 API 层；Dify 只负责传参和展示	多维护一个服务；需要处理 API 鉴权和部署	生产环境、多人使用、对外服务
自定义工具接入 Agent	把查询接口封装成 OpenAPI Schema，让 Agent 自主决定何时调用	体验最自然，AI 能根据用户问题自动选择工具	需要写好工具描述；Agent 可能乱调，控制不好会多消耗 token	需要 Agent 自动决策、高频变化的问题

我一般建议这么选：先想清楚这个查询是“固定动作”还是“开放探索”。如果是固定动作，比如“查近 N 天订单汇总”，代码节点和 HTTP 都行；如果是开放探索，比如用户任意问“上个月哪个商品退款最多”，那就得用 Agent + 工具，让模型动态决定查哪张表、怎么聚合。

1.3 我推荐的落地组合

如果你问我生产环境怎么搭最省心，我的答案是：RAG 相关的内容走知识库，结构化数据查询走 HTTP API，API 由自己的服务提供，Dify 只负责把自然语言翻译成 API 参数。

为什么不是代码节点？因为代码节点跑在 Dify 的沙箱里，依赖库不全、调试不方便、超时限制也多，我在 3.1 节会详细展开。它不是不能用，而是不适合作为长期维护的路径。

这一篇文章会把代码节点和 HTTP 两种路线都走一遍，因为很多人第一步都是从代码节点开始的，哪怕最后要迁移到 HTTP 方案，也得知道中间可能遇到什么问题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 动手前的环境准备：把 Dify 和 MySQL 放进同一个网络

2.1 准备一个测试库和最小权限账号

先别急着写代码，我们把基础环境准备好。你可以用现成的 MySQL 实例，也可以本地用 Docker 起一个。无论如何，我强烈建议不要用 root 账号接入 Dify，而是单独建一个只读账号，最小权限原则在 AI 接入数据库时尤其重要——因为你无法完全预测模型会生成什么 SQL。

sql复制CREATE DATABASE app_db DEFAULT CHARSET utf8mb4;

CREATE USER 'dify_ro'@'%' IDENTIFIED BY 'dify_ro_pass';
GRANT SELECT ON app_db.* TO 'dify_ro'@'%';
FLUSH PRIVILEGES;

USE app_db;

CREATE TABLE orders (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  order_no VARCHAR(32) NOT NULL,
  product_name VARCHAR(128) NOT NULL,
  amount DECIMAL(10,2) NOT NULL,
  status TINYINT NOT NULL DEFAULT 0 COMMENT '0=创建 1=支付 2=退款',
  created_at DATETIME NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO orders (order_no, product_name, amount, status, created_at) VALUES
('20250101001', '机械键盘', 399.00, 1, '2025-01-01 10:23:00'),
('20250101002', '人体工学椅', 1299.00, 1, '2025-01-01 14:01:00'),
('20250102001', '显示器支架', 259.00, 2, '2025-01-02 09:30:00'),
('20250102002', '降噪耳机', 899.00, 1, '2025-01-02 21:15:00'),
('20250103001', '机械键盘', 399.00, 2, '2025-01-03 11:42:00'),
('20250103002', 'USB扩展坞', 199.00, 1, '2025-01-03 16:08:00');

注意建表时统一用 utf8mb4，不然后面遇到 emoji 或者生僻字，很容易出现 Incorrect string value 的报错。这一步是很多人容易忽略的。

如果你用的是 MySQL 8.0，可以在后面测试连接时留意一下认证插件的问题，我专门在 5.2 节记录了这个坑。

2.2 确认容器网络：Dify 容器怎么找到 MySQL

这是新手最容易卡住的地方。你本地连接 MySQL 用 localhost 就行，但 Dify 如果是用 docker compose 部署的，它的代码节点运行在独立的沙箱容器里，这时候 localhost 指向的是容器自己，不是你的宿主机。

分两种情况：

如果 MySQL 也在 Docker 里，并且和 Dify 在同一个自定义网络中，host 可以直接填 MySQL 的服务名或容器名。比如你 docker run --name mysql-server ...，那 Dify 代码节点里就用 host="mysql-server"。
如果 MySQL 跑在宿主机上，Dify 容器访问宿主机要用 172.17.0.1（默认网桥网关地址）或者 host.docker.internal。这个在不同系统上表现不一样，Linux 上 host.docker.internal 可能需要额外配置。

我建议把 MySQL 和 Dify 放进同一个 compose 网络里管理，最省心。检查网络是否互通，最快的办法是直接用代码节点连一下看看报什么错——能通就跳过，不能通就看 5.3 节的排查思路。

2.3 代码节点自测：先跑通 `SELECT 1`

在 Dify 工作流里新建一个代码节点，输入变量先不配，只写一段最简代码：

python复制import pymysql

def main() -> dict:
    conn = pymysql.connect(
        host="mysql-server",
        port=3306,
        user="dify_ro",
        password="dify_ro_pass",
        database="app_db",
        charset="utf8mb4",
        connect_timeout=5,
    )
    try:
        with conn.cursor() as cur:
            cur.execute("SELECT 1")
            result = cur.fetchone()
        return {"result": str(result)}
    finally:
        conn.close()

这里有个关键点：Dify 的代码节点默认不一定预装 pymysql。如果你运行后报 ModuleNotFoundError: No module named 'pymysql'，说明沙箱里没有这个库。先记住这个现象，后面我会专门讲怎么绕过去。

如果网络通、库也装了，这个节点会返回 (1,)。这一步跑通，后面就顺利了。

3. 路线一：代码节点直连 MySQL，跑通第一个“问数据库”的工作流

3.1 理解 Dify 代码节点的运行限制

代码节点是 Dify 里一个非常灵活的节点，本质是一个受限的 Python 运行环境。它灵活在你可以写任意逻辑，受限在：

依赖库不是你想装就能装，需要改沙箱镜像，过程比较繁琐。
节点有执行时间限制，跑长 SQL 或大查询容易超时。
没有内置的连接池，每次调用都新建连接，不适合高频率查询。

理解这些限制之后，你对代码节点的定位就会更清晰：适合做轻量级查询、快速验证原型、或者做一些简单的数据清洗；不适合承载高并发、复杂报表、需要连接池的生产查询。

这也是为什么我一开始就建议生产环境走 HTTP API。但作为入门路径，代码节点仍然值得先走一遍，因为它能帮你快速验证“Dify 能不能连上 MySQL”“SQL 写对了没有”。

3.2 设计一个具体场景：按天数查订单汇总

假设用户会问“最近 7 天订单情况怎么样”，我们需要让 Dify 查出：每天的订单数、销售额，然后交给 LLM 总结。

我的工作流结构是：开始节点 → 代码节点（执行 SQL） → LLM 节点（总结回答） → 结束。这里代码节点只需要两个入参：days（最近多少天）和 min_amount（筛选最小金额）。

在代码节点左侧配置输入变量：

days: Number
min_amount: Number

右侧配置输出变量：

result: String

3.3 代码节点完整代码

python复制import pymysql
import json

def main(days: int, min_amount: float) -> dict:
    conn = pymysql.connect(
        host="mysql-server",
        port=3306,
        user="dify_ro",
        password="dify_ro_pass",
        database="app_db",
        charset="utf8mb4",
        connect_timeout=5,
        read_timeout=10,
        write_timeout=10,
    )
    try:
        with conn.cursor() as cur:
            sql = """
                SELECT DATE_FORMAT(created_at, '%%Y-%%m-%%d') AS day,
                       COUNT(*) AS order_count,
                       SUM(amount) AS total_amount
                FROM orders
                WHERE status = 1
                  AND created_at >= DATE_SUB(NOW(), INTERVAL %s DAY)
                  AND amount >= %s
                GROUP BY DATE_FORMAT(created_at, '%%Y-%%m-%%d')
                ORDER BY day
            """
            cur.execute(sql, (days, min_amount))
            columns = [col[0] for col in cur.description] if cur.description else []
            rows = cur.fetchall()

        result_data = [dict(zip(columns, row)) for row in rows]
        return {"result": json.dumps(result_data, ensure_ascii=False)}
    finally:
        conn.close()

这段代码里有几个细节很关键，我逐个说一下：

第一个细节：为什么 DATE_FORMAT 里面写的是 %%Y-%%m-%%d 而不是 %Y-%m-%d？

因为 cur.execute(sql, (days, min_amount)) 传了参数进去，PyMySQL 会执行 % 格式化。当你 SQL 里同时出现 %s 占位符和 %Y 这样的日期格式化符时，%Y 会被误认为格式化占位符，直接报错。解决办法就是把 %Y 写成 %%Y，转义成字面量 %Y 再传给 MySQL。这是个非常隐蔽的坑，我在这里栽过。

第二个细节：json.dumps(result_data, ensure_ascii=False)。

如果不加 ensure_ascii=False，中文会变成 \u673a\u68b0\u952e\u76d8 这样的转义序列，LLM 虽然也能读，但看着费劲，而且某些模型对转义字符的理解不如直接中文好。加上这个参数后，返回的就是真正的中文字符串。

第三个细节：read_timeout 和 write_timeout。

数据库查询最怕的就是“卡死”。Dify 代码节点本身有超时限制，但如果你在代码层面就设置了连接、读写超时，报错信息会更直观，方便定位是网络问题还是 SQL 问题。

3.4 后续 LLM 节点怎么接

代码节点输出的是一个 JSON 字符串，直接丢给 LLM 节点，Prompt 可以这样写：

code复制你是订单数据分析助手。用户的问题是：{{#sys.query#}}

下面是数据库返回的查询结果 JSON：
{{#codeNode.result#}}

请基于以上数据用中文回答，不要编造任何数据。如果结果为空，就明确告诉用户没有查到数据。

这样 LLM 就变成了“结果的翻译器”，它不负责算数，只负责把结构化数据总结成自然语言。这个设计原则很关键——算数交给数据库，说话交给模型，两者各司其职。

3.5 代码节点方案的边界

我在这个方案跑通之后，一开始还挺高兴，后来很快就发现几个问题：

每次执行都会新建数据库连接，没有连接池，并发一高 MySQL 那边会出现大量 TIME_WAIT。
如果哪段 SQL 写得有问题，Dify 工作流的报错信息不够直观，调试成本高。
数据库账号密码明文写在工作流里，团队协作时不好管理权限。

所以这个方案我最终只用于内部原型和小流量工具。如果你的场景也是“先看看效果”，用它完全没问题；如果你要做生产服务，继续看下面的 HTTP 方案。

4. 路线二：HTTP 请求 + 自建查询 API，生产环境更稳的接法

4.1 为什么生产环境我不建议全部依赖代码节点

核心原因是职责边界。Dify 是用来编排 AI 应用的，数据库访问是基础设施逻辑。基础设施逻辑应该收敛在专门的 API 服务里，好处是：

连接池可以在 API 服务里统一定义，不用每次新建连接。
SQL 逻辑集中在代码仓库里，可以走 review、走版本管理。
权限控制、参数校验、API Key 鉴权都在 API 层完成。
Dify 工作流只负责“传参”和“展示结果”，出了问题不容易互相甩锅。

很多人担心“自建 API 是不是很复杂”，其实一个只读查询接口非常简单，用 FastAPI 几十行就搞定。

4.2 用 FastAPI 封装一个只读查询接口

我写了一个最小可用的只读接口，返回订单汇总：

python复制from fastapi import FastAPI, Query
import pymysql
import os

app = FastAPI()

DB_CONFIG = dict(
    host=os.getenv("MYSQL_HOST", "127.0.0.1"),
    port=int(os.getenv("MYSQL_PORT", "3306")),
    user=os.getenv("MYSQL_USER", "dify_ro"),
    password=os.getenv("MYSQL_PASSWORD", "dify_ro_pass"),
    database=os.getenv("MYSQL_DB", "app_db"),
    charset="utf8mb4",
    cursorclass=pymysql.cursors.DictCursor,
)

@app.get("/orders/summary")
def orders_summary(
    days: int = Query(7, ge=1, le=90),
    min_amount: float = Query(0, ge=0),
):
    with pymysql.connect(**DB_CONFIG) as conn:
        with conn.cursor() as cur:
            cur.execute(
                """
                SELECT DATE_FORMAT(created_at, '%%Y-%%m-%%d') AS day,
                       COUNT(*) AS order_count,
                       SUM(amount) AS total_amount
                FROM orders
                WHERE status = 1
                  AND created_at >= DATE_SUB(NOW(), INTERVAL %s DAY)
                  AND amount >= %s
                GROUP BY DATE_FORMAT(created_at, '%%Y-%%m-%%d')
                ORDER BY day
                """,
                (days, min_amount),
            )
            rows = cur.fetchall()

    return {"ok": True, "data": rows}

这里我用了 pymysql.cursors.DictCursor，查询结果直接就是字典列表，不用再手动转格式。Query(ge=1, le=90) 限制了 days 参数的范围，防止有人传一个 999999 把数据库查崩。

注意这里同样也有 %%Y 的问题，因为 cur.execute 传了参数。只要你用 PyMySQL 并且传了参数，SQL 里的字面 % 都需要写成 %%。

开发环境可以用 uvicorn orders_api:app --host 0.0.0.0 --port 8000 --reload 跑起来。生产环境至少要加一个 API Key 鉴权，比如在 Header 里校验 X-API-Key，Dify 的 HTTP 请求节点支持自定义 Header，这个不难。

4.3 在 Dify 里配置 HTTP 请求节点

在 Dify 工作流里新增 HTTP 请求节点，配置如下：

方法：GET
URL：http://你的API地址:8000/orders/summary?days={{#days#}}&min_amount={{#min_amount#}}
Headers：Authorization: Bearer your_api_key
输出：解析返回的 JSON，取 data 字段

这样 Dify 里的参数是显式传过去的，调用链路上有日志、有限流、有权限校验，比代码节点里塞 SQL 安全得多。

4.4 把 API 封装成 Agent 工具，让 AI 自主调用

如果你想让 Agent“自己决定什么时候查数据库”，可以再进一步，把上面的 API 封装成 Dify 自定义工具。在 Dify 的“工具 → 自定义工具”里粘贴 OpenAPI Schema：

yaml复制openapi: 3.0.0
info:
  title: OrderQuery
  version: 1.0.0
paths:
  /orders/summary:
    get:
      operationId: getOrderSummary
      summary: 查询指定天数内的订单汇总数据
      parameters:
        - name: days
          in: query
          required: false
          schema:
            type: integer
            default: 7
        - name: min_amount
          in: query
          required: false
          schema:
            type: number
            default: 0
      responses:
        '200':
          description: 订单汇总

封装之后，Agent 在对话中如果判断用户想问数据，就会自动调用这个工具。关键在于 summary 字段要写清楚“这个工具是干什么的、什么时候用”，模型是靠这个描述来决定是否调用工具的。描述写得太含糊，Agent 可能根本不知道有这回事。

5. 常见坑与排查记录：从连不上到查得慢

5.1 ModuleNotFoundError: No module named 'pymysql'

这是代码节点方案最经典的问题。Dify 的沙箱环境并不包含所有第三方库，pymysql 不一定默认安装。解决思路有两个：

第一，换 HTTP 方案，把数据库连接逻辑放到你自己的服务里，这是最省事的。

第二，如果你确实想在代码节点里用，需要自己构建带 pymysql 的沙箱镜像，并修改 Dify 的 docker-compose 配置。这个操作比较繁琐，而且升级 Dify 时容易丢配置，我不太建议，除非你有很强的理由非在沙箱里写 SQL。

5.2 Authentication plugin 'caching_sha2_password' cannot be loaded

MySQL 8.0 默认的认证插件改成了 caching_sha2_password，一些老版本的客户端驱动不支持，连接时会直接报错。开发环境下最快的解决办法是把用户改成 mysql_native_password：

sql复制ALTER USER 'dify_ro'@'%' IDENTIFIED WITH mysql_native_password BY 'dify_ro_pass';
FLUSH PRIVILEGES;

但注意，MySQL 8.4 开始默认禁用了 mysql_native_password，如果你用的是更高版本，需要显式启用该插件，或者在连接时确保驱动支持 caching_sha2_password。PyMySQL 新版是高版本支持的，不过在不同网络环境下 RSA 公钥传输又可能出幺蛾子。所以我的实际建议是：开发环境可以改成 mysql_native_password，生产环境优先换成支持新插件的驱动，比如 mysql-connector-python 或更新版本的 PyMySQL，并在连接参数里配置 ssl_disabled=False 或 RSA key 相关选项。

这个坑很隐蔽，因为本地用 Navicat 连得好好的，一到 Dify 沙箱就报错。看到 caching_sha2_password 字样时，第一反应就去看驱动版本和认证插件。

5.3 连不上数据库：容器网络、主机名、防火墙三板斧

代码节点报 timeout 或者 Unknown MySQL server host 时，按顺序排查：

主机名对不对。Docker 容器之间要用服务名或容器名，不要用 localhost。
用户授权对不对。MySQL 用户除了密码，还绑定了 host。'dify_ro'@'%' 表示任何主机都能连，'dify_ro'@'localhost' 就只有本地能连。
宿主防火墙。如果你的 MySQL 暴露在宿主机上，3306 端口是否被防火墙拦了？可以用 telnet 宿主机IP 3306 测一下。

我遇到过一种情况：代码节点里连不通，但在宿主机上用命令行能连通。最后发现是容器网络和宿主机网络隔离导致的，Docker 容器访问宿主机要走 172.17.0.1 而不是 127.0.0.1。

5.4 中文乱码、emoji 报错，十有八九是字符集问题

之前说过，建库建表统一用 utf8mb4，连接参数也要加 charset="utf8mb4"。这两个地方只要有一个是 utf8 或者 latin1，就可能出现乱码或者 Incorrect string value 报错。

另外，从数据库取回中文数据后，如果 json.dumps 不设置 ensure_ascii=False，中文会变成 \uXXXX 形式。LLM 虽然识字，但这种转义会让部分模型理解质量下降。所以两个地方都要处理：数据库连接用 utf8mb4，返回 JSON 时用 ensure_ascii=False。

5.5 查询结果太大，LLM 上下文装不下

这是 AI + 数据库架构里最常被低估的问题。数据库可以返回几千行，但 LLM 上下文窗口有限，你不可能把几千行原始数据都塞进 Prompt。

我的做法是三层控制：

在 SQL 层就聚合，能用 GROUP BY 就不要返回明细。
在 API 层加 LIMIT，限制返回行数上限。
在 LLM Prompt 里明确要求“只总结数据，不要逐行罗列”。

如果确实需要查看明细，就改成“先查汇总，再按需下钻”，让用户先看到概览，再决定是否查看具体订单。

5.6 代码节点超时：数据库和 AI 编排要解耦

Dify 代码节点有执行时长限制，不适合在节点里跑大查询。SQL 执行超过节点上限就会直接失败。这也是我坚持生产环境用 HTTP API 的原因之一——API 可以配合异步任务、缓存、队列来应对慢查询，代码节点做不到。

如果你确实遇到了超时，先检查 SQL 有没有走索引，EXPLAIN 看一下执行计划。再不行就考虑把耗时统计和结果缓存起来，高频问题不要每次都查数据库。我在第六节的案例里会提到一个 Redis 缓存的思路。

6. 一个完整案例：让 AI 回答“近 7 天订单概况”

6.1 需求拆解：从自然语言到 SQL 再到回答

用户输入“最近 7 天订单怎么样”，拆解后实际要做三件事：

确认时间范围：最近 7 天。
查询数据库：聚合出订单数、销售额、日均单量。
组织答案：用自然语言告诉用户整体情况。

在 Dify 里我把这三步对应成三个节点：参数提取（LLM） → HTTP 请求节点（查数据） → LLM 总结节点。

不要试图让 LLM 直接生成 SQL 然后执行，那样太危险。正确姿势是让 LLM 做“参数提取”，只提取 days、start_date、end_date 这些结构化参数，SQL 还是我们提前写死的模板。这样既灵活又安全。

6.2 工作流编排和 Prompt 设计

参数提取节点的 Prompt：

code复制从用户的提问中提取查询参数。可以提取的参数有：
- days: 最近多少天，整数，默认 7
- min_amount: 最小订单金额，数字，默认 0
只输出 JSON，不要输出其他内容。用户问题：{{#sys.query#}}

HTTP 节点拿到参数后查数据库，返回 JSON。最后总结节点的 Prompt：

code复制你是数据分析助手。用户的问题是：{{#sys.query#}}

数据库返回的结果如下：
{{#httpNode.body.data#}}

请用中文总结，包括：
1. 总订单数
2. 总销售额
3. 日均订单量
4. 如果有明显趋势，也一并说明

要求：只使用数据中真实存在的内容，不要编造。

这样跑一轮，AI 的输出类似：“最近 7 天共有 5 笔已支付订单，总销售额 3155 元，日均约 0.7 单。1 月 1 日销售额最高，达到 1698 元……”

6.3 上线之后我做的三件事

第一件事是加缓存。客服机器人问的问题高度重复，尤其是“最近 7 天”“今天销量多少”这类，每次都查数据库没必要。我用 Redis 给高频查询加了 5 分钟缓存，数据库压力瞬间降了一大截。

第二件事是做数据权限隔离。不同业务线不应该都能看到全量订单，数据库账号只给对应库表的 SELECT 权限，API 层再按业务线过滤。这个在 AI 场景下尤其重要，因为模型不会天生判断“这个问题我能不能问”。

第三件事是开慢查询日志。AI 查询不像人工查询那么有规律，你根本不知道模型会生成什么参数。开慢查询日志后，哪天发现有人问了一个特别离谱的问题导致数据库卡顿，你能快速定位是哪条 SQL。

这一套搭建下来，我的体会是：Dify 是 AI 应用的编排层，它聪明地处理“理解和表达”，但数据访问这类脏活累活，应该放到专门的、可控的服务里。让数据库做数据库该做的事，让 LLM 做 LLM 该做的事，两边边界清楚，系统才会稳。我后来又在同一个 API 上加了退款分析、商品排行等几个接口，Dify 侧没有改任何代码，只是多配置了几个工具——这就是把数据访问独立出来的好处：AI 应用可以随时换，数据服务始终稳定。