当几十亿个AI智能体冲向你的数据库

关联

人物 Andy Pavlo · Matt Turk

公司 ClickHouse · Databricks · Neon · Postgres · Snowflake · TurboPuffer · Replit · Neo4j · SQLite · NVIDIA · Oracle · DuckDB · Anthropic

概念 智能体 · 护栏 · 沙箱 · 分支 · 向量数据库 · 向量搜索 · RAG · text to SQL · 语义层 · MCP · 图数据库 · GPU 数据库 · HTAP · LLM · 关系模型 · 智能体记忆 · DBA

Andy Pavlo 是 Carnegie Mellon 大学的教授，他的数据库课程免费放在网上，教出了一代工程师——顺带也把 AI 模型教了出来。他最近离开学界，加入 ClickHouse 创办 ClickHouse Labs。

这次他和主持人 Matt Turk 聊了一个很实际的问题：当智能体开始创建、读写、甚至删除数据库时，这个世界会发生什么？

智能体为什么需要自己建数据库？

两年前大家谈“数据库 + AI”,想的还是向量数据库和检索增强。

但风向变了:Databricks 收购 Neon 时披露，智能体创建的数据库分支已占了绝大多数。

分支是什么？简单说，就是给生产数据库拍一个快照，让开发者(现在是智能体)在副本上随便折腾，验证没问题再上线。

现在公司让编程智能体写新功能，智能体需要沙箱试错，分支需求自然暴涨。

更根本的是，智能体会对世界采取行动。你让它做一个应用，应用背后终究是一个数据库，所以它就得建一个。

“每个月都有人丢掉生产数据库”

智能体也会删库。播客里提到一个公开案例：有人用 Replit 的智能体开发，结果智能体进数据库删了大量文件。

Andy 的态度很不客气：这是“不懂数据库历史的西部荒野”。他把智能体比作幼儿：你不能让幼儿不装护栏就在楼梯上乱跑。

要不了人盯着一个个点批准，否则无法扩展到几百个智能体同时干活。

他并不认为智能体需要全新的护栏：数据库暴露的接口就那么多，能约束人类就能约束智能体。

流量会涨多少？可能 10 到 100 倍

人类用手机每小时只能做一件事，智能体却可以 24 小时运转。

Andy 把数据库的历史分成四波：办公室电脑、互联网、手机，现在是智能体。 每一波都带来流量暴涨，这一波可能让查询量增加 10 到 100 倍。

但有个悬而未决的问题：智能体的查询是更浅还是更深？

有人的观察是，智能体往往一次只读一两个表，反而比人类在 Tableau 里做复杂连接更简单。Andy 说他正在研究这个问题。

文件系统也是数据库？

关于智能体记忆该用文件系统还是数据库，Andy 的回答干脆利落：文件系统就是数据库，一切都是数据库。

他女儿三岁时，父女俩每天在本子上记温度，然后合上本子“提交”，那也是数据库。

区别在保障。数据库系统能提供安全性和多智能体之间的共享状态，这是普通文件做不到的。

他的结论：所有东西都应该放进数据库系统。

让智能体选数据库？先搞定“新 SEO”

有个有趣的细节：两家数据库公司找过 Andy,问怎么让智能体推荐自家产品而不是 Postgres。

他拒绝了——这本质上是一种针对模型的搜索引擎优化。

因为模型是用网上的人类文字训练的，所以如今你让智能体从零建应用，十有八九会推荐 Postgres。

Andy 自己的烦恼恰好相反：他问数据库问题，模型引用回来的是他自己的课件。

他甚至得专门声明“不要引用 Andy Pavlo 或 Carnegie Mellon”,结果模型转头引用了另一所大学——用的还是他的课件。

自然语言转 SQL,终于能用了？

从 70 年代起就有人做“说人话生成 SQL”,一直没成。

现在有转机：一家大银行告诉 Andy,现成工具的准确率只有 60%,但投入多年时间和数百万美元构建丰富的语义层后，做到了 99.5%。

当然，这是“有无限钱的银行”才玩得起的。普通人下载开箱即用的工具，达不到这个水平。

AI 能写出整个数据库吗？

能。一年前，智能体还做不完 Carnegie Mellon 的数据库课程项目；Anthropic 发布 Opus 4 之后，智能体几乎不用提示就能完成全部作业。

数据库圈有句老话：做一个数据库要 10 年，前 3 年做 90%,后 7 年磨剩下的 10%。但现在，只要引导得当，可以“氛围编程”出一个数据库系统。

数据也印证了这点：

Andy 维护着一个“数据库的数据库”网站，每晚抓取开源数据库的提交记录，发现超过 60% 的开源数据库系统有来自智能体的提交。

数据库自身的调优也在被 AI 接管。他之前创业做自动调优，最大瓶颈是缺训练数据；

大模型出现后，靠网上浩瀚的调优文章就能达到 85% 的效果，15 分钟出结果，而自训练模型要几小时。

他还发现，大量用户的数据库一直跑在云厂商的出厂默认配置上——AI 来摘这些低垂的果实，收益立竿见影。

为什么他去了 ClickHouse

美国大学的科研经费不如从前，而 ClickHouse 允许他做真正的、可能失败的纯研究——这在此前接触的公司里从没出现过。

他形容这次合作像说唱组合 Run the Jewels:两个各自成名的人凑在一起，就像第一次把花生酱和果酱抹在一起。

顺带一提，2016 年 ClickHouse 刚发布时，Andy一度怀疑它是假的：列式存储、向量化执行、压缩，一个开源系统凭空全都会，太好了不像真的。

后来证明是真的，而那套架构如今已是行业标配。

图数据库和向量数据库，还值得看好吗？

Andy 对图数据库火力全开。

他打赌：如果 2030 年图数据库市场超过关系型数据库，他就穿上“我爱图数据库”的T恤当证件照，用到去世那天。 他的依据是：

图遍历本质上是表的自连接，SQL 标准在 2023 年已加入属性图查询，在服务器端做遍历，关系型数据库完全可以跑赢专门的图数据库。

向量数据库不会消失，但护城河不大——当年一年之内所有数据库厂商都加上了向量索引。

活得好的路径有两条：变成像 Postgres 那样的通用系统，或者像 Elasticsearch 那样做旁挂的专门系统。他点名 TurboPuffer 是目前做得最好的那家。

本集带走

• 智能体可能带来 10 到 100 倍的数据库查询量增长，但它们的查询模式是否与人类不同，尚无定论。
• 自然语言转 SQL 需要重金打造语义层才能达到 99.5% 的准确率；超过 60% 的开源数据库已含有智能体写的代码。
• 图数据库被 Andy 看衰：SQL 新标准已支持图查询，专用图数据库没有性能优势；向量数据库则需转型求存。
• 数据库的底层架构不会推倒重来，竞争的胜负手在周边：开发体验、数据接入、可观测性这些“脚手架”上的东西。

每个月都有故事说某个智能体删了点东西，导致别人丢了生产数据库。
Every month there’s a story where someone lost their production database because the agent deleted something.
—— Andy Pavlo · [00:03]

但是比如说护城河，如果你愿意这么叫的话，并没有那么大，因为归根结底，它只是一个索引。
But like the moat, if you will, wasn’t that big because at the end of the day, it’s just an index.
—— Andy Pavlo · [03:31]

而在一年之内，几乎每一个数据库厂商都有了他们自己的向量索引。现在这已经变成了某种意义上的标准入场筹码。
And within a year, pretty much every single database vendor had their own vector index. And now it’s become sort of standard table stakes.
—— Andy Pavlo · [03:35]

多年来，我们一直有能力确保人们不做不该做的事，比如那些蠢事，像删掉一张表或者删除记录。这些控制手段是存在的，只是每个人都想重新发明轮子，然后人们就吃了苦头，才学会去做那些过去早就做过的事。
For years, we’ve had the capabilities to make sure people don’t do things they shouldn’t be doing, like stupid things like dropping a table or deleting records. Those controls exist, it’s just everyone wants to re-event the wheel and people learn the hard way of just doing what’s already been done in the past.
—— Andy Pavlo · [08:03]

人们会偷懒，整个公司、整个组织用同一个密码，然后又把同一个密码给了智能体，之后还纳闷为什么智能体开始做不该做的事。
People get lazy, they use the same password across entire company, organization, and then they give the same password to the agent and now wonder why the agent started doing things they shouldn’t do.
—— Andy Pavlo · [09:31]

所以我认为将会潜在地有 10 到 100 倍的流量增长，体现在将冲击数据库的查询数量上。
So I think there’s going to be potentially a 10 to 100x increase in volume in the number of queries that are going to hit up against databases.
—— Andy Pavlo · [13:51]

所以说到底，每个人都应该把所有东西放进数据库系统里。
So at the end of the day, everybody should be putting everything in a database system.
—— Andy Pavlo · [16:47]

我要说的是，我不能说是谁，有两家数据库公司问过我，怎么让智能体在推荐时优先推荐他们的数据库而不是 Postgres。
And I will say, I can’t say who, I’ve had two database companies ask me how to get their database to be recommended first by an agent over Postgres.
—— Andy Pavlo · [18:58]

这基本上就像 SEO。怎么让智能体学会，嘿，我应该用我的数据库 X 而不是 Postgres。
It’s basically like SEO. How do you get the agent to learn like, hey, I should use my database X instead of Postgres.
—— Andy Pavlo · [19:20]

我还没见过任何基准测试表明图数据库——原生图数据库——能在那些关系型数据库系统拥有正确的 SQL 或 API 构造、从而让你完全在服务器端做图遍历、不用来回往返的情况下，胜过关系型数据库系统。
I have not seen any benchmarks that show graph databases, the native graph databases, outperform the relational databases systems when those related systems have the right constructs in SQL or the API so that you can do graph traversal all on the server side and not go back and forth.
—— Andy Pavlo · [22:23]

是的，数据库系统领域有句老话：需要十年，但它是一个系统。你可以在三年里构建出前 90%，然后剩下的 10% 要花接下来七年。
Yeah, the old adage from database systems is that it takes 10 years, but it’s a system. You can build the first 90% in three years and then the remaining 10% takes the next seven years.
—— Andy Pavlo · [29:34]

我们的模型通常需要训练好几个小时——前提是你有足够的训练数据——才能产生最完美的最优配置，但 LLM 只要 15 分钟就能进来，产出一个足够好的东西，而对大多数人来说这就够了。
Our models oftentimes would take hours and hours to train, assuming you had enough training data, to produce the pristine optimal configuration, but the elements can come in just like in 15 minutes, produce something that was good enough, and that’s good enough for most people.
—— Andy Pavlo · [34:31]

超过 60% 的开源数据库系统的提交来自智能体。
Over 60% of the open source database systems have commits coming from agents.
—— Andy Pavlo · [30:37]