DB-GPT 实战笔记：把自然语言变成可执行的 SQL 与分析流水线

DB-GPT 实战笔记：把自然语言变成可执行的 SQL 与分析流水线

【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI + Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT

业务经理问一句"本季度哪个产品类别销售额最高"，传统流程是数据工程师写 SQL、分析师拉数、再做一页报告，全程两三天起步。能不能把这句话直接变成一份带图表的报告，而且全程留痕、可复跑？DB-GPT 就是冲着这个问题来的。

DB-GPT 是一个开源的 Agentic AI 数据分析助手：AI 自主规划任务、自己写 SQL、自己写 Python 代码、在沙箱里执行，最后交付图表、Dashboard 和 HTML 报告。它面向两类人——想让业务人员直接和数据对话的产品团队，以及想基于多智能体 + 工作流搭建 AI + Data 应用的开发者。核心框架位于 packages/dbgpt-core/src/dbgpt/，入门路径看 官方快速开始文档。

问一句话，它自己规划、执行、出报告

最常用的一条链路是 Chat DB。连上数据库后，你不需要告诉它查哪张表、写什么聚合，直接提问就行。

拿"构建销售报表，分析用户的订单，从至少三个维度分析"这句话举例：plan_manager 先把目标拆成 5 个子任务——按产品类别、按用户、按时间三个维度各取数，再算订单转化，最后汇总输出。每个取数任务分派给 Data Scientist 角色独立执行，Reporter 负责把结果格式化成报表。整个过程以步骤清单形式展开，哪一步查了什么数、生成了什么图，全部可见可回溯。

底层走的是 Text2SQL 链路：自然语言 → Schema 关联 → SQL 生成 → 执行 → 结果格式化。官方文档明确建议表名、字段名要起得"人类可读"并加上注释，这一步做扎实了，生成 SQL 的准确率会有明显提升（数据源文档）。

把关系库、数仓、图数据库放进同一块管理面板

企业里很少有只有一张库的：MySQL 存业务、ClickHouse 存分析、Neo4j 或 TuGraph 存关系。DB-GPT 在 Web 界面的 Database 页签下提供统一的数据源管理。

面板里能看到 TuGraph、Neo4j、Spark、ClickHouse、DuckDB、Hive、MSSQL、MySQL、Oracle、PostgreSQL、StarRocks、MongoDB、OceanBase 等二十来个连接器，每个都是独立插件，动态加载，新增数据源不用改主程序。连接信息在表单里填写、测通即保存；数据源也可以走 TOML 配置或 REST API 管理。会话入口是统一的——接的是哪个源，只是"数据库对话"里选一下的事。

把一次性问答变成可复跑的工作流

问一次是 demo，按周跑才是生产力。DB-GPT 里的工作流引擎叫 AWEL（Agentic Workflow Expression Language），分 Operator、AgentFream、DSL 三层，把 LLM 应用里"取数、向量、Prompt、模型调用"这些动作拆成标准算子，再拼成 DAG。

Web 界面里是一张画布，拖节点连边就能编排"HTTP 触发 → 解析请求 → LLM 生成 → 多 Agent 协作"的流程，存下来即可反复执行，也能直接暴露成接口给别的系统调用。写 Python 的话，一个最小 DAG 长这样：

with DAG("simple_rag_example") as dag: trigger = HttpTrigger("/examples/simple_rag", methods="POST") parse = RequestParseOperator() chat = BaseChatOperator() output = MapOperator(lambda out: out.to_dict()["text"]) trigger >> parse >> chat >> output

官方示例在 examples/awel/simple_rag_summary_example.py，照着改就能上手。

30 分钟内跑起来：一条命令装、一个 toml 配、一个端口收

不折腾 GPU 的话，走 API 代理是最快路径。全程只需要 Python 3.10+ 和 uv：

git clone https://gitcode.com/GitHub_Trending/db/DB-GPT.git cd DB-GPT uv sync --all-packages --extra base --extra proxy_openai \ --extra rag --extra storage_chromadb

然后改configs/dbgpt-proxy-openai.toml，把 key 填进去：

[[models.llms]] name = "chatgpt_proxyllm" provider = "proxy/openai" api_key = "your-openai-api-key"

启动并验证：

uv run dbgpt start webserver --config configs/dbgpt-proxy-openai.toml # 打开 http://localhost:5670，能进对话页就算成功

两个常见坑：一是 embedding 默认配置里如果要换成 HuggingFace 的模型，装依赖时得补上--extra hf --extra cpu，否则启动直接 import 报错；二是走本地模型（Ollama）时，先确认 Ollama 本身在跑，不然就是干等超时。不想碰源码也可以直接docker pull eosphorosai/dbgpt-openai:latest，环境变量塞进 API Key 就能起，详见 Docker 部署文档。

能力边界：适合什么，不适合什么

先说适合：数据不出内网的本机/集群部署（Ollama、vLLM 都能接）、快速搭 AI + Data 的团队工具、需要复跑和交付的固定分析流程。它的差异化在于不只是"NL2SQL 出个结果表"，而是多智能体规划 + 工作流编排 + 技能（Skills）机制的平台，沙箱模块 支持 Docker 隔离执行 AI 生成的代码，生产环境建议开启。

再说边界：

• 它不是 BI 工具替代品。图表是自动生成的，Dashboard 样式没有 FineBI、Superset 那级的手工调参空间，深度定制报表还是交给 BI 栈
• Text2SQL 准确率上限由模型决定，复杂多表关联、模糊口径的问题，建议人检查生成的 SQL 再放行
• 默认元数据存储是 SQLite，多用户生产环境要切 MySQL/PostgreSQL
• 平台概念（App、AWEL、Agent、Skill）比普通 NL2SQL 工具多，团队上手前值得花半天读一遍 Agent 框架文档

回到开头那个问题：本季度销售 Top 类别，DB-GPT 的答案不是"帮你写 SQL"，而是一份能直接发的带图报告。想验证它值不值得进你的技术栈，最直接的办法是 clone 下来，接上你手头任何一个 SQLite 或 MySQL 库，对着真实的表问一句业务问题，看它的 SQL 靠不靠谱。源码在 packages/dbgpt-core/src/dbgpt/，完整文档入口见 docs/docs/getting-started/quick-start.md。

【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI + Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT