AI agent连数据库这件事，我试了一周才敢下结论

LLM生成SQL这条路值得走，但它更适合「交互式查数」场景，不适合当生产系统的默认通道。如果你只想让AI帮你跑几条分析查询，现在就可以试。指望它替代数据分析师，还早。

我是在本地Postgres上搭的测试环境，用MCP把数据库接给agent，然后用自然语言问它「各个城市上个月的订单量」。第一天最直观的感受是：模型必须知道表结构。我一开始没给它看schema，直接问，它生成的SQL里字段名错了一半。后来把建表语句喂进去，准确率明显上来。

有同行在LinkedIn上总结过，LLM生成复杂SQL要靠谱，三个条件缺一不可：知道schema、有样本数据、有护栏。我这边测下来基本吻合。给几条真实数据行做参考，查出来的结果比只给schema时干净得多。因为模型能从样例里推断字段值的格式，不会在日期或枚举值上瞎猜。

第一天卡得最多的地方，是它总忘掉「只读」这个前提。我让它查数据，它偶尔会生成带UPDATE的语句，吓得我赶紧把数据库账号改成只读权限。这也是最值得提醒新手的一点：别让agent用自己的生产账号连库，单独开个只读用户，命都保住了。

第三天开始试不同模型，差距就出来了。我在同一个任务上换了几种模型跑，Claude Sonnet 3.5在理解多表关联时明显稳，GPT-4o偶尔会在JOIN条件上犯迷糊。有个Reddit帖子里也有人问哪家模型做SQL agent最好，评论区吵成一团，但基本共识是：模型能力直接决定SQL质量下限。不挑模型，随便用个小的开源模型顶上去，会怀疑人生。

一周后我回头看，SQL生成只是第一关，查询结果本身才是真正的大坑。AI生成一条正确的SQL，data量大了，返回结果灌爆agent的上下文窗口。这时候你才发现，光在SQL层面解决不了大查询的送达问题。有一篇论文也在说类似的事。在Athena这种大数据系统上，只盯text-to-SQL远远不够，两端都得处理。你不得不在数据库前面加个汇总层，或者限制查询粒度。

我现在的用法是：小数据集的探索性分析，直接让AI查，很快。复杂业务报表，还是老实写SQL。想试的话，建议先准备好三样东西：建表语句、两三条样本数据、只读权限账号。按这个配置，你遇到大部分坑都能绕过去。

---

本文编译自 Hacker News，原文：Choosing the Right Database for AI Agents: LLM Generated SQL | Learn - Predictable Blog
版权归原作者所有，本文为基于公开报道的编译与独立分析。