Vanna.ai

Vanna 从「RAG 框架做 SQL 生成」一路演进到 2.0 的完整 SQL 智能体，官网定位是「构建用户真正能用的智能体」（Build Agents Your Users Can Actually Use），并宣称是「The fastest SQL Agent」。它要达成的目标很朴素：让组织中无论 SQL 水平如何的用户，都能用自然语言查询公司的各业务系统（systems of record），把时间从写 SQL 转移到分析洞察上——官方引用产品负责人的话：用 AI 与数据库对话，是为了「不管 SQL 熟练度如何，都能赋能全组织用户以自然语言与数据库交互，让数据对每个人都更可及」。

核心能力

• 自然语言查库：用户不写 SQL 也能与数据库交互，覆盖公司各业务系统（systems of record），降低取数门槛；框架层面可自由选择 LLM Provider 与数据库（Choose Your Stack）。
• 用户级权限执行：官方强调 User-scoped execution，按用户范围执行查询，这是企业内开放查数的前提，避免越权取数。
• 多数据库与多轮对话：官方明确列出 Open Source、Multi-database、Multi-turn、Access controlled 四大特性，支持多种数据库，并支持追问式多轮交互；落地前先确认目标库类型在官方支持列表内。
• 内置 UI 组件与配额管理：提供现成的界面组件（rich UI components），不必从零做前端；内置用量配额管理，避免少数用户吃满资源，也方便按部门核算用量。
• 云与自托管：提供 Cloud 与 Self Host 两种形态，开源且支持自部署，可在 LLM Provider 与数据库之间自由选择技术栈。

适合谁

想让业务人员自助取数的数据团队；要构建面向内部或客户的 Text-to-SQL 产品的开发者；以及需要在云服务与自托管之间按合规要求选择的组织。对数据团队而言，它把「接需求、写 SQL、交付数据」的重复劳动，变成维护好元数据与验证集即可；对产品团队而言，现成 UI 组件能显著缩短从原型到上线的距离。

注意事项

• Text-to-SQL 的准确率高度依赖库表结构与数据质量，复杂业务逻辑需要打磨元数据与提示词。
• 放开访问前务必做好权限隔离：先用只读账号与有限库表试点，确认权限执行与生成准确率达标后再扩大范围。
• 自托管需要自己准备模型与算力，不同 LLM Provider 的表现差异明显。
• 生成结果涉及敏感数据时，注意查询日志的合规留存与脱敏。
• 官方宣传语（如「最快」）以官网为准，真实性能取决于所选模型与网络环境，建议用自己的数据实测。
• 云端版本会把查询与数据经第三方处理，敏感库请优先考虑自托管。

使用建议

官方给出的价值判断很实在——用 AI 查库的意义在于把时间从写 SQL 转移到分析洞察上。落地时先圈定核心业务库表与高频问题，建立验证集评估准确率，再逐步开放给业务方；同时让权限与配额先于功能上线。团队内先培养一小批「超级用户」，把高频问题沉淀成验证集，再逐步扩散到全员。