GitHub 上星最多的开源 text-to-SQL 项目如今是只读的：Vanna 在 2026 年 3 月 29 日以 23.8k 星归档了仓库，而 Dataherald 自 2024 年 7 月 11 日起没再合过一次提交。仍在发版的那两个——DB-GPT 与 Wren AI，本周都有提交——恰恰是在自然语言问题与生成的 SQL 之间放了一件持久、可评审的产物的那两个。这不是巧合。前沿模型吞掉了 SQL 生成；没有任何东西能替你回答"用户说的『营收』是你那四种定义里的哪一种"，而无论你装的是哪个项目，那一层都归你自己拥有。
先看全局
十八个月前，这四个是显而易见的候选清单；今天它们彼此已经不是同一类东西了。
| 项目 | 许可证 | 状态（2026-09-09） | 它实际是什么 |
|---|---|---|---|
| Wren AI | 按路径 Apache-2.0（docs 为 CC BY 4.0） | 活跃——0.14.0 于 9 月 8 日发布 | 围绕一个带版本的语义层构建的受治理 GenBI 平台 |
| DB-GPT | MIT | 活跃——提交持续到 9 月 8 日 | 一个宽口径的数据智能体框架，SQL 只是它产出的几样东西之一 |
| Vanna | MIT | 2026-03-29 归档，只读 | 一个"训练加检索"的 Python 库，如今转为托管商业产品 |
| Dataherald | Apache-2.0 | 停滞——最后一次提交 2024-07-11 | 面向企业库表、API 优先的自然语言转 SQL 编排 |
请像维护者那样读这张图。Vanna 的 23.8k 真实地量出了 2024 年人们有多想要一条"从问题到查询只要两行"的捷径——它对"2026 年还有没有人会合并你的补丁"一字未言。Dataherald 3.6k 星只对应 262 个 fork，这是"被收藏而非被部署"的典型签名。如果你的候选清单是按星数排出来的，它已经过时两年了。
停下来的那两个，究竟发生了什么
这两个项目都不是以开源项目通常的方式失败的。Vanna 是被有意归档的，README 里摆着一个已完成的 2.0，描述围绕"用户感知型智能体"的彻底重写，带生命周期钩子、LLM 中间件、会话存储与可观测性——而在继续运营的产品是 Vanna Cloud，一个付费托管服务。这是一家公司认定：开源库是分发渠道，托管服务才是生意。这个决定完全正当，而如果你原本把那个仓库当基础设施用，它对你就是致命的：代码是 MIT 的、随你 fork，但 fork 一个 972 次提交的代码库是一份人力承诺，不是一个许可证问题。
Dataherald 是更安静的那种形状。Apache-2.0、四个服务、一套至今仍被对比文章赞许引用的架构——以及一条 main 分支，上面最新的提交是 2024 年 7 月的一次文档改动。二十六个月不是一次停顿；它横跨了任何当代自然语言转 SQL 系统赖以构建的工具调用与结构化输出 API 的整个生命期。你从它这里部署出去的任何东西，都是在拿它从未见过的模型 API 自己养着。
有用的问题不是它们当年谁工程做得更好，而是活下来的那两个有什么是这两个没有的。
被商品化的是生成器，不是含义
在 2023 年，针对一个陌生库表生成语法正确的 SQL 是难的，做得好的项目就有产品。这项能力如今是每一个前沿模型和多数开放权重模型的基线功能；残留的错误几乎从来不是语法。它们是语义上的：查询连对了表、返回了一个数字，而这个数字的含义与被问的不是同一件事——因为 orders.total 含了已取消订单，因为"活跃客户"的定义住在一个没人导出过的 dbt 模型里，因为财务口径的营收剔除了内部往来而销售口径没有。
Wren AI 把这件事直接写进了架构。业务含义、被批准的定义与已验证的示例，被捕获进一份 Modeling Definition Language 清单——模型、列、关系、视图、cube、指标——存在仓库里、纳入版本控制、接受评审。底下的引擎是跑在 Apache DataFusion 上的 Rust，而 MDL 是一份 JSON schema，这比听上去更要紧：你的语义层是一份可携带的文档，而不是一坨你想离开时得逆向工程出来的内部状态。
Vanna 的设计恰恰相反，而且是有意为之：没有语义层、不带产品主张，一个"训练加检索"的循环——你喂给它 DDL、文档和问题–SQL 配对，它在查询时把相关的检索回来。这确实是一个摩擦低得多的起点，也正是它拿到 23.8k 星的原因。它同时是一份累积的语料而不是一份文档——你 diff 不了它，评审者批不了它，而当某个定义变了，你得去猎捕那些仍在教旧定义的陈旧配对。那些知识是真的，但它从来不是一件有人拥有的产物。
DB-GPT 坐在两者之间，回答的是一个更宽的问题。它是一个数据智能体框架——SQL 生成、Python 分析、RAG、报告生成、多模型服务，外加用于编排流程的 AWEL，以及在 DB-GPT-Hub 一条线上做的 Text2SQL 模型微调工作。含义一部分住在 AWEL 流程定义里、一部分住在被检索的知识里，比训练语料可评审，又不如清单权威。如果你想要一个连 Python 和报告一起写了的运行时，这是四者中唯一还提供它的。
真正决定采纳与否的那些细则
三条值得在做许可证评审前知道的具体事实，通常的对比表里一条都没有：
- Wren AI 的许可证是按路径多重授权的，不是按仓库。
core/、sdk/、skills/、examples/与根目录文件是 Apache-2.0；docs/是 CC BY 4.0。仓库里还预置了一份LICENSE-AGPL-3.0，为项目声明"未来可能引入"的模块留位——今天没有任何路径映射到它，但一位法务评审只要 grep 到 "AGPL" 就会停下来，所以要抢在这场对话前头，而不是在第三周才发现它。 - 仓库合并是新近发生的。
Canner/wren-engine于 2026 年 5 月并入Canner/WrenAI的core/目录，旧仓库已冻结。任何早于此的教程、Docker compose 文件或 issue 讨论，指向的都是一个不复存在的目录结构。 - DB-GPT 的广度同时也是它的集成面。多模型服务、RAG、智能体、AWEL 与微调装在一个项目里，意味着要钉住的活动部件更多；而它近期的提交日志正是你会预期的样子——连接器修复、流程兼容性修复、新增供应商。这既是关于维护的健康信号，也是关于表面积的诚实信号。
还有一点对四者一律成立：没有一个会替你供上语义层。Wren AI 给了你一种好格式和一套评审流程去做它；DB-GPT 给了你几个可以放它的位置；另外两个给的是一种隐式累积它的办法。撰写才是那份工作，它要一个数据团队干上几周，而它是这一整套技术栈里唯一在两代模型之后仍然值钱的部分。跳过它的团队，得到的是一个把五个问题回答得漂亮、然后给 CFO 端出一个自信的错数字的 demo——而这正是数据与分析智能体整页围着组织的那个失败模式。
什么时候选哪个
| 场景 | 选 Wren AI，如果…… | 选 DB-GPT，如果…… | 都别选，如果…… |
|---|---|---|---|
| 面向业务人员的自助 BI | 你愿意把 MDL 当作数据团队的产物来撰写与评审 | 你要从一个运行时里同时拿到图表、Python 与报告 | 指标定义还没有人负责——先把这件事解决 |
| 把查数据当作众多工具之一的智能体 | 你想让语义层通过 MCP 被调用，智能体的其余部分放在别处 | 你想把整个数据智能体装进一个编排框架里 | 一个数仓、十个已知问题——写十个视图就好 |
| 受监管或需审计的报表 | "经过评审、纳入版本控制的定义"本身就是要求 | 你能钉住流程、把 AWEL 当作受评审的配置 | 答案必须逐字节可复现——那就把 SQL 生成一次然后固化发布 |
| 你已经在生产里跑 Vanna 0.x | 迁移能给你累积下来的知识买到一层可评审 | 迁移能买到你此前没有的广度 | Vanna Cloud 可以接受——托管产品才是被维护的那条路 |
在你的评估里最该出力的是最后一列。一个数仓加一组稳定的问题，用视图和一块看板就答完了，运营成本只是零头，而且完全没有语义歧义。text-to-SQL 值回它的复杂度，是在问题空间真的开放、库表真的庞大的时候——而在有人把列的含义写下来之前，它一分钱也不值。
常见问题
Vanna 死了吗？
开源仓库自 2026 年 3 月 29 日起归档、只读，停在 23.8k 星，MIT 许可。公司以付费托管产品 Vanna Cloud 继续经营，README 里记录了 2.0 重写以及从 0.x 迁移的路径。所以：作为一个受维护的依赖，这个库已经结束；作为产品，没有。
2026 年还该用 Dataherald 吗？
只当参考架构用。main 上最新的提交来自 2024 年 7 月 11 日，早于任何当代实现所依赖的工具调用与结构化输出 API。Apache-2.0 意味着你可以随意 fork；代价是它从此归你养。
MDL 是什么，为什么它要紧？
Modeling Definition Language 是 Wren AI 的语义清单——模型、列、关系、视图、cube 与指标，表达为一份 JSON schema 并纳入版本控制。它要紧，是因为它把业务含义变成一份可以在 pull request 里评审、也可以带去另一个工具的文档，而不是一坨在向量库内部累积起来的状态。
现代 LLM 是不是让 text-to-SQL 工具变得多余了？
它们让"生成 SQL"这一段接近解决，却没让部署这一段轻松半分。剩下的是大规模下的库表选择、安全的只读执行、对返回数字的核验，以及那种任何模型都无法仅凭 schema 完成的语义消歧。这些才是这些项目今天存在的理由。
哪一个离开的代价最低？
Wren AI，理由很具体：它的语义层是一份可携带的 JSON 清单，而不是内部状态。你把读它的那个工具卸载之后，你的 MDL 依然是有意义的；一份累积起来的问题–SQL 训练语料做不到这一点。
延伸阅读
本站相关：
- 数据与分析智能体——库表接地、只读执行，以及把弃答的分数打得比自信错答更高。
- 面向 RAG 的查询理解——决定这次检索原本有没有可能奏效的那一步消歧。
- 结构化输出——受约束的生成为什么把难点从语法上挪走了。
- 工具设计原则——从模型那一侧看，一个好的"查数仓"工具长什么样。
- 幻觉与接地——那个自信的错数字，以及接地为什么让它变得容易被抓。