Day 28｜让智能体与数据库对话智能体的核心不是聊天，而是：从“回答”变成“执行”。让 AI 能读写数据库，就让它真正

在智能体（AI Agent）的所有能力中，“能读会写数据库”是最常被误用、又最容易产生事故的一项功能。它既能让系统真正“动起来”、跨越知识检索与执行之间的鸿沟，也能让系统因为一条未审核的 SQL 而造成破坏性影响。这一章，我们深入解析：

SQL Agent 的架构模型
如何让智能体安全地读写数据库
如何设计 SQL 执行的安全边界
Prompt（系统指令）该怎样写
如何构建企业级 SQL Agent

1. 为什么 SQL Agent 是智能体的重要基石？

数据库是企业系统最核心的“事实源（Source of Truth）”。让 AI 能够读写数据库，带来三个关键能力： ① 让 AI 能直接回答企业数据问题例如：

「给我过去 30 天 GMV 最高的 10 个品牌」

AI 不需要依赖培训、不需要 BI 工具，直接在数据库里查。 ② 让 AI 完成数据操作任务例如：

「把所有未审批且超过 30 天的请假单标记为过期」

这是真正的 “Action” 执行，而不是推理。 ③ 让非技术人员拥有生产级数据操作能力传统流程：

产品 / 运营找数据团队 → 提需求 → 数据开发写 SQL → 等输出

有了 SQL Agent：

运营一句 “查 xx”，AI 自动生成 SQL + 解释 + 执行。

这就是 “AI-native 企业应用” 的基础形态。

2. SQL Agent 的核心架构

一个可靠的 SQL Agent 必须具备以下四层：

┌────────────────────────────────┐
│   L1：理解层（NL → Intent）      │
│   解析用户需求，锁定表/字段。      │
├────────────────────────────────┤
│   L2：规划层（Intent → SQL Plan）│
│   选择查询方式、拼接 SQL 结构。    │
├────────────────────────────────┤
│   L3：生成层（SQL Codegen）      │
│   生成可执行 SQL。               │
├────────────────────────────────┤
│   L4：执行层（Validator → DB）   │
│   安全审核、结果解析与修正回路。    │
└────────────────────────────────┘

其中最关键的是 L4 执行层，因为：SQL 最危险的不是“生成错误”，而是“执行错误”。

3. SQL Agent 的执行路径

Step 1：需求解析（NL → Intent）

模型分析：

用户要查什么？
涉及哪些表？
涉及哪些字段？
是查询、更新还是删除？

例如用户说：

“给我 2024 年按地区拆分的新用户增长情况。”

模型要产出结构化意图：

{
  "task": "query",
  "tables": ["users"],
  "fields": ["created_at", "region"],
  "filters": [{"created_at": "2024"}],
  "group_by": ["region"]
}

Step 2：SQL 规划

模型根据 schema 自动构建查询结构，例如：

SELECT
FROM
JOIN
WHERE
GROUP BY
ORDER BY

自动检查字段是否存在，JOIN 是否正确。

Step 3：SQL 生成

示例生成：

SELECT region, COUNT(*) AS new_users
FROM users
WHERE created_at >= '2024-01-01'
  AND created_at < '2025-01-01'
GROUP BY region
ORDER BY new_users DESC;

Step 4：安全审核（关键）

这一层不能完全交给模型。必须由一个“SQL 安全执行器”判断：

是否包含危险操作（DROP / TRUNCATE / UPDATE ALL / DELETE）
条件是否完整
查询是否会造成全表扫描
影响行数是否过高
执行频率是否超限
是否违反数据分级规则（敏感字段）

审核通过后再交给数据库执行。审核是 SQL Agent 最重要的环节。

4. SQL Agent 的安全体系设计（企业级）

一个负责任的 SQL Agent 必须满足：

① 写操作（UPDATE/DELETE）必须强制人类确认

流程：

用户请求 → AI 生成 SQL → AI 解释风险 → 用户确认 → 执行

例如：

系统安全提示：
你正在执行“更新操作”，预计修改 214 条数据。
这是不可撤销的操作。
请回复“确认执行”以继续。

② 对危险 SQL 进行软阻断

以下指令直接阻断：

DROP DATABASE
DROP TABLE
DELETE without WHERE
UPDATE without WHERE
UPDATE/DELETE where rowcount > 最大阈值

③ 查询限流 / 分页

默认限制：

返回最多 200 行
查询超时 5 秒
自动添加 LIMIT

④ 敏感字段保护

敏感字段如：

phone
email
id_card
salary
password（必须禁止查询）

AI 不能直接输出真实数据，需要脱敏：138****7890

⑤ Schema 权限隔离

给 AI 的 schema 必须是只读（或最小权限）。

5. SQL Agent 的 Prompt 设计（核心）

核心提示词结构：

💡系统指令：

你是一个 SQL 生成器。
目标：
将用户意图转换为 SQL。
限制：
1. 永远必须基于提供的数据库 schema。
2. 禁止编造不存在的表或字段。
3. 默认所有查询必须加 LIMIT 200。
4. 更新/删除操作不得自动执行，必须先生成 SQL 并提示风险。
5. 如果用户要求执行危险操作（DROP/TRUNCATE），你必须拒绝。
6. 返回 SQL 时必须以代码块格式给出。

💡Schema 提供方式：例如提供：

TABLE users {
  id INT PRIMARY KEY
  name TEXT
  region TEXT
  created_at TIMESTAMP
}

6. SQL Agent 的两种主流实现方式

① 大模型“直接生成 SQL”（Direct Generation）

优点：

实现简单
延迟短

缺点：

容易生成不存在字段
没有思考步骤
容错差

② ReAct / Toolformer / Multi-step 规划型 SQL Agent（推荐）

执行流程：

1. 模型先询问数据库 schema
2. 分析字段
3. 再生成 SQL
4. 再自检
5. 再给最终答案

这类 Agent 解耦清晰、错误率显著下降。是 AutoGPT、LangChain、Rewoork、Devin 等真实系统用的路径。

7. SQL Agent 的典型功能示例

以下是一个成熟 SQL Agent 能做到的：

① 数据查询

“查询最近 7 天新增用户数”

② 报表生成（带图表）

“按月统计 2023 年订单金额，画一张折线图” AI：

- 生成 SQL
- 获取结果
- 自动画图
- 返回图表

③ 智能洞察（Insight Agent）

“识别 GMV 异常波动的省份” AI：

分析历史数据
找出突变
给出原因解释

④ 写操作（安全确认）

“把 id=123 的订单改成已发货”
AI：
1. 生成 UPDATE SQL
2. 提示用户风险
3. 用户确认
4. 执行
5. 汇报结果
8. 构建你自己的 SQL Agent（从零到一）

最小可行工程（MVP）包含：

(1) Schema Loader（结构读取器）

从数据库提取表结构
转成 JSON
提供给模型

(2) SQL Generator（SQL 生成器）

支持结构：

SELECT
WHERE
IN
GROUP BY
ORDER
JOIN
LIMIT

(3) SQL Executor（执行器）

超时
行数限制
流量控制
审核规则
敏感字段脱敏

(4) 修正回路（SQL Correction Loop）

当 SQL 执行报错时：

把错误消息回传给模型
模型自动修正
重新执行
给出结果这能减少 80% 的 SQL agent 崩溃情况。

9. 总结：SQL Agent 是“企业级 AI 应用”的入口

智能体的核心不是聊天，而是：从“回答”变成“执行”。让 AI 能读写数据库，就让它真正参与业务、参与运营、参与系统。SQL Agent 是智能体能力体系中的 “Action 基石”。从这里开始，AI 才能成为真正的执行者，而不是咨询顾问。