Vanna 2.0：自然语言转 SQL，企业级重写后有多强？

写个 SQL 查询就要找 DBA、翻文档、拼半天语法——这种体验做数据的人都不陌生。Vanna 一直想解决的就是这个问题：用自然语言问，它帮你转成 SQL。但之前的 0.x 版本更像是个实验品，API 用着别扭，安全基本没有，想上生产得自己补一堆东西。

2.0 版本我盯了几个月，说是完全重写一点不夸张。从底层架构到前端 UI 全部推倒重来，直接面向企业场景设计。

Vanna 是什么？一句话

一个开源的 Text-to-SQL 框架：你输入中文或英文问题，它理解你的数据库结构，生成 SQL 去查询，然后把结果用表格和图表返回给你。支持自然语言追问、多轮对话。最新版 2.0.2，2026 年 2 月发布，MIT 协议，Python 3.9+。

2.0 重写了什么？

从 0.7.9 直接跳到 2.0.0，中间没给过渡版本。这次升级不是小迭代，是架构级重写。

VannaBase 类变成了 Agent。 旧版的核心是 VannaBase，你要继承它、实现一堆方法。新版就是一个 Agent，配好 LLM、工具、用户解析器，完事。代码量少一半，逻辑清晰很多。FastAPI 集成是内建的一等公民，不用自己搭路由。

用户感知（User-Aware）贯穿全栈。 这是 2.0 最大的卖点。你定义一个 User Resolver，把用户的身份和权限组传进去，然后从 LLM 调用到 SQL 执行到结果返回，每个环节都知道「这是谁在操作」。行级安全自动应用——同一个 SQL 查询，管理员看到全部数据，普通员工只能看到自己部门的。对做多租户 SaaS 的团队来说，这个功能太关键了。

内置 Web 组件 + 流式响应。 一个 <vanna-chat> 标签嵌入任意页面，连上 SSE 端点就能用。返回结果是流式的：先展示进度，再出 SQL，然后表格，最后图表+自然语言总结。体验上很像跟 ChatGPT 聊天，但内容全是结构化数据。

迁移麻烦吗？

官方给了 LegacyVannaAdapter，把 0.x 实例包一层就能直接获得新 UI。渐进式迁移，不用一次性全改。不过说实话，如果项目还在 0.x 阶段，直接切 2.0 更省事——API 完全不同，早晚得重写。

不是没有槽点

学习曲线有。 User Resolver、ToolRegistry、Lifecycle Hooks 这些概念对新手来说有点多。文档写得不差，但要消化还是得花时间。

纯英文语境为主。 虽然支持中文输入，但模型理解中文表结构的能力取决于你用的 LLM。如果数据库字段名也是中文，得额外调一下 Prompt。对国内团队不算友好。

版本跳的有点猛。 从 0.7.9 直接跳到 2.0.0，现有用户如果只是简单用 Vanna 查数据，升级成本不小。

依赖有点重。 完整的安装链包括 FastAPI、Pydantic、Plotly、SQLAlchemy 等一堆东西。想轻量嵌入现有项目，得仔细挑 extra 安装选项。

跟同类怎么比

Text-to-SQL 这个赛道不缺工具。LangChain 的 SQL Agent 也能做，但 Vanna 2.0 更专注——不做 RAG、不做聊天机器人，就做一件事：自然语言查数据库。SQLCoder 偏模型层面，Vanna 偏应用框架层面。如果团队需要的是「嵌入现有系统的查数据组件」，Vanna 2.0 比搭 LangChain 那套轻得多。

一句话总结：Vanna 2.0 把一个实验品变成了正经企业工具。如果你有内部数据查询的需求，值得认真看看。

GitHub：https://github.com/vanna-ai/vanna
官方网站：https://vanna.ai

标签：#Vanna #TextToSQL #数据分析 #开源工具 #SQL生成 #企业安全

关注我，每期分享一个帮你省事的强大工具 🛠️