数据库对话智能体 DB-GPT

很多业务方并不是不会看数据，而是不会写 SQL。一句「上个月华东区客单价最高的五个客户是谁」，落到数据库里可能要 join 三张表、正确理解日期口径和订单状态。数据团队要么被重复取数淹没，要么干脆把库锁起来，于是出现两种失败：要么数据死在原地，要么人人拿着高权限账号裸奔。DB-GPT 要拆的就是这个结——把「自然语言 → 可信 SQL → 可读答案」的链路打通，同时让每一次查询都可审计。

它解决的具体问题

• 业务侧反复提需求，取数的排期永远排在最后面。
• 模型直接连库，用高权限账号生成并执行 SQL，误删风险极高。
• 生成的 SQL 看起来能跑，口径却是错的，答案没人敢信。
• 出问题之后无法追溯：谁问了什么、当时生成了什么 SQL、拿到什么结果。

技能如何工作

整个技能围绕四条步骤展开：

1. 理解意图。把口语问题映射到具体的表结构。这一步强烈依赖表结构文档和字段注释，否则模型只能猜字段名，生成的 SQL 基本是废的。
2. 生成 SQL。模型产出查询语句，并且必须附上解释，说明它为什么这样写、用到了哪些表和口径。
3. 执行与校验。SQL 在受限账号下执行，结果再转回自然语言呈现给提问者，而不是甩给用户一段原始 SQL。
4. 可追溯。保留「问题 → SQL → 结果」的完整记录，便于事后审计和复盘。

安全不是附加项，而是前置条件：

• 权限：只读账号，按角色限制可见的表。
• 脱敏：敏感列先遮蔽，再展示结果。
• 审计：记录谁查了什么。

适用边界与注意点

这个技能最适合结构清晰、注释齐全的库表。如果表结构缺失，先补文档再谈 Text2SQL。复杂查询建议保留人工复核通道，所有写操作必须二次确认，并且对行数和权限设置上限保护，避免一条全表扫描把库打挂。

最后，AI 输出需要以官方为准。涉及业务敏感数据时，权限隔离和脱敏不是可选项，关键查询务必走人工复核，并遵守数据合规要求。