很多人尝试给 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) 就是围绕这套逻辑构建的开源轻量级数据库语义网关：
-
连接数据库：支持 MySQL、PostgreSQL、ClickHouse、Doris 等主流数据源，服务端统一做连接池与熔断治理；
-
沉淀语义：低代码维护表/字段别名与枚举映射，系统自动建立语义检索索引；
-
组合工具：简单查询走预置的受控只读工具，复杂查询和写操作通过参数化 SQL 模板秒变自定义工具；
-
一键发布为标准 MCP 服务：对外提供标准的 Streamable HTTP MCP 接口。任意 Agent 宿主（如 Cursor、千问、WorkBuddy、Dify）只需填入 URL 和 Token 即可即插即用，零前端开发、零二次部署。
大模型连接数据库，不应该在“直连裸奔”和“重型单体系统”两个极端之间做选择。通过服务端 MCP 网关提供集中安全管控、业务语义注入与参数化 SQL 兜底，才是真正兼顾灵活性与工程确定性的最佳路径。