很多人尝试给 Agent 接数据库，第一反应往往是拿本地脚本直连，或者找个现成的数据库 MCP 暴露 DDL 和执行接口。Demo 很容易跑通，但一旦进真实场景就会发现：大模型搞不懂缩写和数字枚举、复杂多表联查极易写错、生产账号密码暴露在客户端、甚至一条没有 WHERE 的 SQL 就能引发越权或误改。

要让 Agent 真正安全、稳定地操作企业数据库，核心不在于“连上”，而在于中间必须有一层专为 Agent 设计的数据库语义网关。

一、接入后能干啥？不只是看报表，而是做业务轻应用

传统 ChatBI 往往把 Agent 局限在“只读查数”的被动看板角色。但只要接入方式具备安全可控的写能力，Agent 就能直接演化为具备持久化存储的业务轻应用：

• 深度即席分析：告别固化看板，自然语言直接驱动任意维度的交叉下钻与归因分析。

• 业务操作闭环（CRUD）：结合客户端自带的语音、OCR 等多模态能力，拍张发票自动记账、发条语音录入客情线索、根据指令自动修改订单状态。Agent 从“只读分析师”变成了“能落库干活的业务助理”。

二、Agent 接入数据库，必须守住的三大底座

要实现上述能力，网关层必须提供三个关键支撑：

1. 安全：凭据集中与底层的行级租户隔离

• 凭据不落地：生产库的 IP、端口和账号密码全部集中托管在服务端，客户端和外部 Agent 仅持有一个受限 Token，随时可吊销。

• 操作严格分级：对大模型自由生成的即席查询，强制通过语法解析拦截 DROP、TRUNCATE 等高危操作，并设超时熔断。

• 行级数据物理隔离：绝对不能指望大模型“自觉”加上过滤条件。必须在网关层将当前用户的认证身份（如用户标识）强制注入到执行逻辑中，从底层物理锁死数据范围，彻底杜绝越权看数据或改数据。

2. 业务语义：让 SQL 生成真正准确

真实企业的数据库充满历史包袱：缩写表名、无注释字段、纯数字状态枚举（如 status=1 代表待支付，status=2 代表已履约）。大模型即便推理能力再强，也不可能凭空猜出这些业务“黑话”。

网关必须沉淀业务语义层：把表别名、字段注释、枚举字典映射和专业术语集中维护，并在收到用户提问时，通过倒排检索秒级召回高度关联的上下文注入给大模型，彻底根除猜字段、乱连表的幻觉。

3. 参数化 SQL：复杂场景与高危操作的确定性兜底

大模型的优势是理解模糊意图与提取入参，弱项是处理精密的长链路计算。面对 5~8 张表级联统计或核心增删改，让大模型裸写 SQL 几乎必然翻车。

最可靠的工程解法是参数化 SQL 模板： 由工程师把高频复杂查询和写操作预先封装成带有动态参数的 SQL 模板，暴露为一个确定性的工具函数。大模型只负责理解用户自然语言、提取参数并“填槽”调用。核心 SQL 骨架与执行计划完全由工程把控，既确保了复杂场景的高准确率，又构成了最坚固的安全防线。

三、DatI：最简的工程实践

DatI (Data Intelligence) 就是围绕这套逻辑构建的开源轻量级数据库语义网关：

1. 连接数据库：支持 MySQL、PostgreSQL、ClickHouse、Doris 等主流数据源，服务端统一做连接池与熔断治理；

2. 沉淀语义：低代码维护表/字段别名与枚举映射，系统自动建立语义检索索引；

3. 组合工具：简单查询走预置的受控只读工具，复杂查询和写操作通过参数化 SQL 模板秒变自定义工具；

4. 一键发布为标准 MCP 服务：对外提供标准的 Streamable HTTP MCP 接口。任意 Agent 宿主（如 Cursor、千问、WorkBuddy、Dify）只需填入 URL 和 Token 即可即插即用，零前端开发、零二次部署。

大模型连接数据库，不应该在“直连裸奔”和“重型单体系统”两个极端之间做选择。通过服务端 MCP 网关提供集中安全管控、业务语义注入与参数化 SQL 兜底，才是真正兼顾灵活性与工程确定性的最佳路径。

• 开源地址：https://github.com/yimindev/dati