每个月，X 上都会流传一个让人后背发凉的故事：某个开发者让 AI Agent 帮忙搭个东西，Agent 反手冲进数据库，把生产环境的文件删了个精光。 Replit 出过这事，其他平台也出过。
人们一边惊呼“AI 太危险了”，一边继续把生产库的密码交给 Agent。但在数据库圈子里，这件事的荒谬之处在于，这些灾难本可以避免，因为防止人类干蠢事的机制，几十年前就已经存在了。
卡内基梅隆大学的 Andy Pavlo 教授，是数据库领域最接近“神”的存在之一，他的课程教会了整整一代工程师，也顺带喂饱了今天的 AI 模型。最近他以数据库研究副总裁的身份加入一家实时分析数据库公司 ClickHouse，核心产品是一个列式 OLAP（联机分析处理）数据库管理系统。
日前，Andy Pavlo 在 The MAD Podcast 播客中，与主持人 Matt Turck 一起，讲清了 Agent 时代数据库正在发生的四重变化：从向量数据库的退潮，到 Agent 删库的护栏问题，再到 AI 能否从零构建数据库、自动驾驶数据库的十年历程。本文基于该播客视频整理，经 InfoQ 编辑。
太长不看版 Q：Agent 删库这事为什么老发生？ A： Agent 删库不是新问题，是旧问题被重新暴露，权限和管控手段几十年前就有，只是大家急着让 Agent“能干活”，忘了先问“它干错了怎么办”。
Q：该怎么给 Agent 加护栏？ A： 把它当成一个刚会走路的小孩，你不会不装楼梯护栏、不封插座就让他满屋跑。
给 Agent 设好权限，让它根本进不去生产库、删不掉不该删的表，再配合分支造沙箱环境。别想着坐在旁边一个个点“批准”，那样你没法同时给几百个 Agent 当保姆。
Q：向量数据库还值得投资吗？ A： 护城河并不深，说到底它只是一个索引。
一年内所有数据库厂商都有了向量能力，从差异化优势变成了入场门槛。但不会消失，会朝两个方向演化：要么变成 Postgres 那样的通用系统，要么像 Elasticsearch 一样做独立附加组件。
Q：text-to-SQL 现在靠谱了吗？ A： 现成方案准确率大概 60%。
一家大银行花了几年时间、投入数百万美元构建语义层和上下文层，才把准确率提到 99.5%。所以可行，但前提是你得像那家银行一样有钱有闲。
普通人下载个现成工具，达不到那个水平。 Q：AI 真能从零构建一个数据库吗？
A： 能。 CMU 的数据库课程项目，一年前 Agent 还做不全，Opus 4 发布后闸门打开，几乎不需要提示就能全部做完。
而且超过 60% 的开源数据库已经出现了 Agent 参与的 commit，AI 已经在构建了。 Q：LLM 调数据库参数，比传统自动调优强在哪？
A： 传统模型要训练几个小时甚至更久，还得有足够训练数据，才能产出“纯净最优”配置。 LLM 15 分钟就能给出“足够好”的结果，做到大概 85% 的程度。
而“足够好”对绝大多数人来说就是真的好，毕竟很多人跑的就是亚马逊开箱即用配置，那玩意儿简直糟透了。 Q：数据库市场是不是停滞了？
A： 如果拿 AI 当参照系，所有东西都像停滞。但关系模型不会消失，就像你不会发明新算术取代 1+1=2。
SQL 可能变成新的汇编语言，但底层逻辑不变。真正重要的往往是数据库之上的那层脚手架：UI、开发者体验、数据摄入、互操作性，Snowflake 成功的一部分原因就是把这些周边做得特别好。
Agent 频频删库，如何防护？ Matt：两年前，数据库和 AI 的话题就出现过，那时候是向量数据库的时代，整个理念是你需要做 RAG，结合聊天机器人搜索。
显然，我们现在处于 Agent 时代。这有什么不同？
Andy： 从“AI 与数据库”成为时代热词的角度看，大概两年前确实是 RAG 和向量数据库冒出来的时候。但向量数据库本身，很多其实从 2016 年就存在了。
只是到了现在，它们的用途才变得显而易见，你可以用它们来增强和改进 Agent 做的事情。向量数据库市场很有意思，它们很早就进入这个领域，真正在推动的是一个理念：你希望对向量或 embedding 做近似相似度搜索，而不是传统数据库系统做的精确搜索。
当你处理自然语言时，这一点尤其有用，因为你要找的东西，语义上可能没法精确定义。比如“给我找出纽约市所有关于某种活动的专辑”，你很难精确描述那到底是什么。
所以当聊天机器人爆发、所有人都意识到这项技术存在的时候，向量数据库正好站在了正确的位置、正确的时间。但护城河，并没有那么大。
因为说到底，它只是一个索引。一年之内，几乎每一家数据库厂商都有了自家的向量索引，现在这已经成了标配。
这不代表向量数据库在某些事情上不能比传统数据系统做得更好，只是现在大家都有了那个基础功能。所以你仍然会用向量搜索来增强和改进聊天机器人、Agent，只是你不再需要一个专门的、只能做这件事的数据库了。
Matt：大概一年前，Databricks 收购 Neon 的时候，有一个数据：Agent 创建 Neon 数据库的比例从 30% 涨到了 80%。什么叫“Agent 创建一个数据库”？
为什么 Agent 需要一个数据库？ Andy： 我觉得那个数据说的主要是 Agent 创建的分支（branching），分支就是当你有一个数据库，你想给它做一个写时复制的快照，让它在逻辑上看起来像两个独立的数据库。
为什么要这么做？你有一个跑着业务和应用的 production 数据库，也就是你的 system of record，所有的变更都往里面写。
但你又想让一个人类开发者或者一个 Agent 去尝试新东西、改应用，而且希望他们是在真实的数据库上操作。传统做法是复制一份数据库，或者用一个更小的样本版本，因为完整复制太贵了。
所以你搞一个 staging 或者 development 数据库，改完之后再往 production 上应用，然后祈祷放大到真实规模时一切正常。分支让你做的，是对真实数据库做一个快照，你所有的改动都进快照，不影响 production。
等你对 schema 或者应用代码改动满意了，再把它上线到 production，很多时候这些分支是 GitHub Actions 里跑 PR、跑测试时创建的。 Matt： 那再往更简单的层面说，Agent 需要创建一个数据库，是因为 Agent 会对世界采取行动。
如果你让一个 Agent 去创建一个应用，应用归根结底还是需要一个数据库。 Andy： 你给 Coding Agent 一个 prompt，说“这个应用要做这个那个”，它就会立刻创建一个数据库。
大多数被创建的分支，或者说新数据库，都是为了开发这件事。不过确实，Agent 现在确实能创建数据库了。
换个说法，你也能让它们删数据库。人们经常因此惹上麻烦，因为它在做不该做的事。
Matt： 每年都会出一次很有意思的事故，还在 X 上被传得挺广。 SaaStr 创始人 Jason Lemkin 想用 Replit 搭点东西，结果 Replit 的 Agent 冲进数据库，删了一大堆文件。
后来 Replit 也做了相应的调整。显然，现在这一切都还是蛮荒西部（译者注：规则不完善、约束不足、大家随意尝试、容易出乱子的状态）。
Andy： 我们其实早就有能力防止人们干那些不该干的蠢事，控制手段一直存在。只是每个人都想重新发明轮子，然后人们只能用惨痛的方式，去重新学会过去早就做过的事。
Matt：在 Agent 的世界里，数据库到底需要有哪些目前还不存在的东西？ Andy： 护栏。
你可以这么想，你家里新添了一个蹒跚学步的小孩，你不可能不装护栏，就让他往楼梯底下摔，或者把手指头捅进插座里。对待这些 Agent 也是同一个道理，你得把它们当成幼儿来看。
当然它们比幼儿要精密一些，但你不能让它们在生产库上撒野、想干嘛干嘛。你当然可以坐在旁边盯着，一个劲儿地“批准、批准、批准”，就像在 Claude Code 里那样。
但问题是，这样一来你就没法扩展了。所以正确的做法是设置好权限和管控，让它们根本进不去生产库、删不掉不该删的表。
反过来也一样，它们不该读的东西，你也不该让它们随便读。只要你把护栏设对了，再配合分支或者别的什么手段，给它们造出沙箱环境，那些灾难就能避免。
你现在每个月都能看到一条新闻，某某因为 Agent 删了不该删的东西，把生产库搞没了。其实只要护栏到位，这些事本可以不会发生。
Matt：那这些护栏，跟现在给人类用的是同一套吗？ Andy： 这就是个更大的问题了，Agent 现在的行为方式，除了能 7×24 小时连轴转之外，跟人类到底有没有本质区别？
我还没看到任何证据表明，它们开发软件的方式、或者产生不准确数据的方式，跟人类有什么不同。归根结底，数据系统暴露出来的能力就那么多，你能碰到的就是那套 API。
所以只要你能约束住人类对这些 API 的使用，你就能用同样的方式约束 Agent。护栏能做到多精细，取决于你在用什么产品。
我很喜欢开源数据库，但那些企业级的商业传统数据库，它们早就替你把这件事做完了，过去几十年为人类用户积累了大量保护机制，现在只要把这些机制同样暴露给 Agent 就行了。数据库流量的四个时代 Matt：你刚才提到了量和扩展性，如果未来有几十亿个 Agent 在采取行动、跟数据库打交道，这会不会改变一切？
Andy： 现在下结论还太早。量当然是个问题，因为 Agent 是 7×24 小时在跑的，人做不到这一点，但数据库历史上其实已经见过类似的量级跃迁了。
第一个时代，大概是 70 到 80 年代，数据库本身刚刚诞生。你终于可以把信息放进去、跑事务、为组织存储东西了，在那之前，一切都还是纸笔。
那个时代数据库流量确实有一个明显的增长，但主要是人在工作场景里跟数据库交互，因为没人会回家还去用数据库，80 年代家里也不一定有一台电脑。第二个时代，是 90 年代到 2000 年代初，互联网来了。
每个人都能通过网站、通过家里的网络跟数据库交互，流量又出现了一次跃升。第三个时代，是手机。
现在每个人在任何时刻都有各种 app 在跑，可以跟网站交互，从数据库里读数据、写数据。现在，Agent 就是这个故事的下一个章节，每个人不仅有一部手机，还可能有几百个 Agent 在替他行动，去读、去写数据库里的数据。
说到底，你的应用背后永远是一个数据库，应用要读写数据，最终都会落到数据库上。但我不觉得我们已经到了那一步，因为显然不是每个人现在都有几百个 Agent 在 7×24 小时地跑。
有意思的地方在于：当一个人用手机、笔记本、网站或应用跟数据库交互时，他其实只在自己醒着的时候做这件事，而且一次只能做一件事。我没法一手拿手机、一手拿笔记本同时操作，人的能力是有限的。
但你可以想象一个世界，这些 Agent 就是 7×24 小时一直在跑，像人一样去交互，那量级的增长会相当显著。而且，你可能会问，Agent 跟现在的 IoT 设备、手机有什么本质区别？
IoT 设备只是不停地流式插入测量数据，手机 app 通常是在读数据。但你可以想象 Agent 做的是更复杂的操作，是读和写的组合，这让流量变得更有意思。
所以我认为，未来打到数据库上的查询量可能会出现 10 到 100 倍的增长。我还不确定的一点是：Agent 交互的复杂程度，到底是比人现在能做的更复杂，还是更简单？
有人说，Agent 生成的查询、生成的 SQL 其实更浅，因为它可能只是一次读一两张表，看看里面有什么；而人用 dashboard 或者 BI 工具比如 Tableau、MicroStrategy 的时候，可能会做跨多张表的非常复杂的 join。我目前还不知道 Agent 到底到了那个水平，还是只是用更简单的方式去读数据库里的数据。
Agent 会改变一切吗？我认为会。
至少在量上，现在肯定是，而且还会继续增长。当然，Agent 跑起来之后还会生成自己的遥测数据，你得把这些也存下来、理解它，这是另一个挑战。
但至于它们的行为模式到底有多不一样，这还有待观察。 Matt：现在有一个概念叫 Agent Memory，看起来正在成为一个战场。
一边是文件系统，另一边是数据库。你怎么看？
Andy： 文件系统就是一个数据库。说到底问题是：你想提供给 Agent 的输入或上下文，形式到底是什么？
据我所知，现在全都是人类可读的文本。那么这段人类可读的文本，究竟是来自你目录里的一堆 JSON 文件，还是从某个数据库系统里抽取出来、再转换成正确的输入形式，其实并不重要。
当你使用一个数据系统时，显然能获得一些优势和安全保证，它能保护数据。 SQLite 在这方面就非常有名，你为什么要用一个文件系统，自己去操心写入是否正确、是否安全、能不能做多次修改再提交，而不是直接用 SQLite 把它做对呢？
所以归根结底，所有人都应该把所有东西放进数据库系统里。甚至有些文件系统，比如 WinFS，在底层其实就是一个数据库系统。
Matt：多 Agent、子 Agent、Agent 集群的世界，是不是更需要数据库？ Andy： 如果你需要在多台机器或多个 Agent 实例之间共享状态，不管它们是不是跑在同一台机器上，数据库管理系统提供的正是这种能力：你可以有多个读者去读取共享状态。
我还没见过哪种场景，Agent 在查询记忆时会把过滤条件下推到数据库里，通常这些都是作为上下文提供的。这又回到 RAG 或向量数据库那套东西：你根据已经查到的内容，去对照你的记忆，来提供上下文。
所以从我的理解来看，输入给上下文的 API 就是人类可读的文本，它来自文件系统还是数据库系统都无所谓。但数据系统能提供一些文件系统给不了的保证和便利，跨多个 Agent 的共享状态就是其中之一。
AI 推荐数据库：新型 SEO Matt：那你有没有观察到 Agent 世界正在收敛到某种特定类型的数据库？ Andy： 无论是把它用作记忆，还是让 Agent 在构建应用时去选择某一个数据系统而不是另一个，也许更多是后者。
模型是吃人们写的东西训练出来的，所以如果我现在说我要构建一个新应用，大概率它推荐的会是 Postgres，因为这就是预训练语料里的东西。已经有两家数据库公司来问我，怎么才能让自己的数据库被 Agent 优先推荐，而不是 Postgres。
我当时就说，第一，这不是我干的活；第二，去找那些做模型的人，他们显然对这件事有影响力。这本质上就是 SEO，你怎么让 Agent 学会“我该用 X 数据库而不是 Postgres”。
Matt： 我怀疑逻辑是这样的：你的文章被搜索引擎高度索引，那么向搜索引擎“推销”你，就成了一种向模型“推销”你的方式。 Andy： 我不是想炫耀，但我确实遇到一个问题：当我问关于数据库的问题时，它会把我自己的内容引用回给我自己，因为我所有的课程材料都在网上。
但问题是，这其实并不好。比如我在教数据库课的时候，我会说，我想了解那些做某种索引的数据系统之类的。
然后我现在必须得说：我已经知道哪些系统做这件事了，给我看看那些不这么做的。然后我还得加一句：别引用任何我写的东西。
还有一个麻烦是，我们所有的课程材料都是开源的，任何人都能拿去用。所以模型会说：行吧，那我不引用卡内基梅隆大学了，我引用另一所大学。
但那其实是我的幻灯片被另一门课重新使用了。所以我得变得非常具体，才能说清楚哪些东西不要返回给我。
关于 OLTP，我有一阵子没试过了，但通常它会吐回来一句“你应该用 Postgres”，除非你说得非常具体，比如“我要跑在嵌入式设备上”，那它才会说用 DuckDB 或者 SQLite 之类的；或者你说“我只关心键值”，它可能会回来说用 RocksDB。然后它可能会接着推荐：你想要托管版本还是自己部署？
对于 OLAP，我倒是很好奇会不会有某种排名。它肯定会先给一个答案，然后你可能得进一步细化，说“我的工作负载长这样，我的数据长这样”，然后它才能给出更细致的回答。
我大概有一年没试过了，但我以前确实见过它说：你有钱吗？有。
那你可以用 Snowflake 或者 Databricks；没钱，那你可以用 DuckDB；你想本地部署吗？那你可以用 ClickHouse，诸如此类。
Matt：这里可能还涉及一个上下文层、本体论（ontology）的概念，它似乎正在把大家推向图数据库。这些到底有没有道理？
Andy： 我不认为你需要图数据库。我还没见过任何基准测试能证明原生图数据库能胜过关系型数据库系统，前提是那些关系系统在 SQL 或 API 里具备了正确的构造，让你可以在服务端完成图遍历，而不是来回往返。
上下文层该用什么，取决于你的需求，你有多少个 Agent、是否在多个 Agent 之间共享状态。对很多这类场景来说，Postgres 往往应该是首选，尤其是做 OLTP 的时候。
如果你做的是分析型负载，那就是另一回事了。 MCP 与 Text-to-SQL 的突破 Matt：过去一年左右，好像每家数据库厂商都在自己的产品里加了 MCP server。
你怎么看这件事？一两年前有过一波 text-to-SQL 的热潮，所有人都想让 LLM 直接在数据库上跑，尤其是做分析场景，但那一波好像没成。
我们现在到了那个临界点了吗？ Andy： Text-to-SQL，也就是自然语言转 SQL，这件事人们从 70 年代就开始尝试了。
每隔一段时间，自然语言处理领域就会出现某种突破，大家就说“这下终于能成了”，但一直没成，直到 LLM 出现。不过我对学术界和各种框架的研究论文一直持怀疑态度，因为它们的 benchmark 往往就是 Spider 那几个众所周知的测试集，而这些模型根本就是在这些 benchmark 上训练过的，那它当然能背出正确答案。
我昨天刚跟一家非常大的银行的人聊过，他们说现在已经有了 text-to-SQL 接口。最初的实现用的是市面上的现成方案，后来他们在内部做了一些改进，但准确率大概只有 60%，这跟我之前在其他报告里看到的数字差不多。
但他们说，通过构建更丰富的语义层和上下文层，花了几年时间、投入了数百万美元，现在已经把准确率提升到 99.5%，这简直离谱。我认为如果你愿意投入时间去构建正确的语义层和所需的上下文信息，让 Agent 有足够的信息从你提出的问题推导出正确的 SQL 查询，这在今天已经是可行的了。
但再说一遍，那是一家钱多到花不完的大银行，他们才做到了这一点。如果你现在随便下载一个现成的工具，一个普通人会发现这些工具根本达不到那种准确率水平。
至于 MCP，我理解他们为什么做这个。它出自 Anthropic，然后所有人很快就把它采纳为标准了。
每隔一段时间 Hacker News 上就会有人发帖说“MCP 已死”之类的，但我不觉得它会消失。它本质上就是一个 REST 接口，一种标准化的方式，用来描述 Agent 想从你的数据系统里请求什么。
接收 MCP 请求的数据系统，它的工作就是把请求转换成正确的 API 调用去取数据。对数据库系统来说，就是生成 SQL 查询去拿数据。
但通常它只是对你传入的内容做严格翻译，而不是去试图推导 MCP 请求的语义含义，因为 MCP 请求本身必须定义得足够明确。我对 MCP 没有任何意见，因为它让你更多地使用数据，而不是搞一些自研的土办法。
它能改进吗？我觉得它效率不高，因为你是通过网络发送人类可读的文本去检索数据。
用二进制协议显然有更好的做法，但归根结底，它够用了，而且看起来已经成了所有人都在用的标准。 Matt：那安全层是不是应该由你之前提到的那个层面来负责？
Andy： 对。但这跟请求来自传统应用客户端用 JDBC 或 ODBC 发来的 SQL 没什么区别，不管是走这些数据系统的网络协议或终端，还是走 MCP 的 REST 请求，本质上都一样：好，我收到了这个请求，我需要搞清楚是谁在请求、想做什么、以及应不应该允许。
所以，我们之前聊的那些防护措施，不管是 SQL 进来的还是 MCP 进来的，是同一套东西。 Matt：那我们把讨论翻个面，从“数据库作为 Agent 的记忆层或执行层”，转到“AI 能为数据库做什么”。
显然我们活在一个 AI 几乎能写任何代码的世界里。这对数据库也成立吗？
Andy： 成立。我在卡内基梅隆大学（CMU）教一门关于数据库系统的课程。
我们的项目是这样的：给你一个数据库系统的脚手架，然后你得去实现索引、查询引擎之类的部分。一年前，Agent 还只能做一部分，做不全。
后来 Anthropic 发了 Opus 4，闸门一下就打开了，Agent 基本上能把我们所有的作业都做出来，而且几乎不需要什么提示，因为训练数据太多了。我们所有的项目都是开源的，有海量的训练数据供它学习怎么实现这些东西。
我认为现在 Agent 基本上能实现任何你想构建的数据库系统，当然，你得用正确的方式去提示它，得手把手带着它，确保它先产出正确的设计，再基于你要的设计去生成实现。 Matt：但我作为风险投资人构建数据库的经验是，这是一段长达十年的痛苦旅程，头三年几乎什么都没发生，然后世界上最聪明的一批人聚在一起，去解决每一个当时看起来都不可逾越的问题。
现在你说它能构建整个东西？ Andy： 数据系统领域有句老话：构建一个数据系统要花十年，但前 90% 你三年就能做完，剩下那 10% 要再花七年。
所以我认为，只要有足够的 token，再加上足够的指导，人们可以 Vibe Coding 出整个数据库系统。我有一个自己特别喜欢的副业项目，叫 database of databases，网址是 dbdb.io。
我们做的一件事，就是把我知道的每一个数据系统都记录在案。对那些开源的，我们每天晚上都会把 GitHub 上最新的 commit 全部拉下来，然后追踪哪些 commit 实际上是被 Claude 或者 Codex 这类工具参与“署名”的。
很多人会把这个功能关掉，你没法百分之百确定某段代码到底是不是 AI 生成的，但大多数人不会去关它。而到现在，我认为超过 60% 的开源数据库系统，已经出现了来自 Agent 的 commit。
自动驾驶数据库之路 Matt：写代码这件事能自动化，那么运行数据库本身呢？你十年前就在做“自动驾驶数据库”这个概念了，那是个大项目。
能不能带我们走一遍这段旅程，当年不可能、而今天变成可能的东西，到底是什么？ Andy： 我到卡内基梅隆大学之后做的第一件事，就是头几年到处去走访企业，看他们在数据库上到底遇到什么麻烦。
结果我发现，反复出现的主题惊人地一致：运行、维护、优化这些系统，本身就是一个巨大的挣扎。从 1970 年代关系模型被发明出来开始，人们就一直在尝试做自动调优：索引、分区键、分片键、各种调优旋钮，全都试过。
微软研究院在 2000 年代初还搞过一个叫 Auto Admin 的项目，做了一堆工具来自动管理和优化数据系统。为什么这件事这么难？
因为一个数据库的配置组合有成千上万种。比如我要给表建哪些索引来加速查询，可索引建多了，写入就变慢，磁盘空间也会被吃光。
还有控制运行时行为的各种旋钮，多少内存分给某个内存池、多少分给索引。这已经超出了任何单个人类推理能力的边界，更何况如果你面对的是成千上万个数据库，靠人去管根本不可能。
所以我们花了不少时间去研究怎么用机器学习来构建自动化工具。我们其实有两条研究路线，第一条是“黑盒”视角：不动数据库内部，只用它暴露出来的 API，看能对已有的 MySQL、Postgres、Oracle 做多少自动优化。
第二条是“从零重建”：假设这个数据库天生就是被机器学习工具、也就是今天说的 Agent 来控制的，那系统的设计是不是应该略有不同？我们从优化 MySQL 里学到的很多东西，最后都被塞进了自己造的系统里。
当时做自动化工具最头疼的，是拿不到足够多的生产数据库数据，也没法把在一个部署上学到的东西迁移到另一个部署上。大多数人手上有两套环境：一套 staging 或者开发环境，一套生产库。
你显然不敢在生产库上乱试，万一试出个性能退化，业务就挂了。所以你会先在 staging 上验证，再往生产上搬。
但问题是，staging 和生产永远不是同一套硬件，也永远不是同一种负载。这就是我们长期面对的核心难题：喂给模型、让它能在生产库上做出好决策的训练数据，永远不够。
然后 LLM 出现了，它彻底改变了这个问题的解法。因为 LLM 本质上是被互联网上所有关于怎么调数据库的博客文章、文档、最佳实践指南训练出来的。
在研究层面我们发现，LLM 能帮你把调优这件事做到大概 85% 的程度，当然，总还有些奇奇怪怪的边角案例需要定制化算法去处理。 Matt：那是不是意味着，数据库已经可以很大程度上自我调优、自我优化了？
Andy： 答案是肯定的，但这取决于你到底想要多大的提升。 LLM 能帮你走到 80% 到 85% 的位置，那是不是永远还有更多性能可以榨出来？
是的。有些人永远会在意那些边角的东西，因此我们过去构建的那些自动化方法对他们来说依然很重要。
但对大多数人来说，其实一个让我非常意外的发现是：当年我们做初创公司、试图给 MySQL 做自动调优的时候，有多少人跑的就是亚马逊或者谷歌云平台上的开箱即用配置。他们跟我们说：“我以为亚马逊在帮我们调优啊。
不，他们没有。所以有足够多的人跑在默认配置上，那玩意儿简直糟透了，千万别那么干，而 LLM 恰好可以进来，处理掉一些显而易见的问题，在很短时间内给人带来有意义的改善。
Matt：在一个 Agent 会调用数据库、管理数据库，数据库本身也在走向自驱动的世界里，还有什么工作真正需要对数据库的深度理解？ Andy： 即使你将来不打算成为数据库系统工程师，不去写 ClickHouse、Cockroach 或 Postgres 的内核，你依然应该去了解这些系统的内部原理。
因为每个人都会和数据库系统打交道。如果你理解它们的内部实现、理解一个数据系统在给定查询下试图做什么、不做什么，你在理解整个技术栈时就会处于更有利的位置。
现在还需要上我那门课才能搞懂这些吗？不需要。
Agent 已经把我所有的东西都吞进去了，它们可以把我教的一切原样吐出来。但说到底，无论你是通过传统大学课程学、自学，还是让语言模型教你，只要你理解了数据系统试图做什么，大部分神秘感就消失了。
你会明白为什么查询跑得慢，或者为什么不慢，你在应用层面就处于更好的位置。如果你读的是计算机科学或工程学位，专注于数据系统，我不认为“你要从零开始自己写一个系统”这个时代还会继续存在。
不过，数据库公司仍然在招人来做这些事，因为总得有人理解 Agent 到底在干什么，并且能对它做的事做出判断。 Matt：我们是不是进入了一个数据库管理和部署完全不需要 Human in the Loop 的时代？
Andy： 传统意义上我们熟知的 DBA 角色，我认为会被降级，其中很大一部分可以被自动化。但这不意味着这些岗位会消失，他们只是可以去做更高级的事情，比如数据建模，这永远重要。
Agent 也能做很多建模工作，但你仍然需要有人来判断：这个数据模型是否真正捕捉到了我们组织或业务想在数据库中表达的东西？不过像调参数、选索引这种具体的事，可以交给 Agent 了。
为何在 ClickHouse 设立研究实验室 Matt：你最近加入了 ClickHouse，要创办 ClickHouse Labs。那么，为什么在一家商业公司里办实验室，而不是在学术界做这件事？
Andy： 大学里做研究的本质，现在变得挺艰难的，美国的科研经费已经不是过去那样了。还有一个更大的问题：当一个 Agent 已经能做很多事的时候，招一个博士生到底意味着什么？
当 Agent 能产出东西、能和我这个教授一起写论文的时候，你还需要那么多博士生来做这些事吗？我当然还是觉得教育学生有价值，我也喜欢做这件事，但我不清楚的是，我该怎么筹钱去养那么多我想要的学生。
有一些公司来找过我，问我有没有兴趣离开学校、和他们一起做点有意思的事。但那些邀请总是更像是“你要不要来我们这儿当个工程师”，或者说是我在研究方面想做的事的一个被稀释过的版本。
然后我跟 ClickHouse 的人聊了，那个机会几乎好得不太真实。我说，你们是想让我来做研究？
他们说，对，来做研究。我又说，研究这东西不一定总能出成果，我不知道会发生什么。
他们说，太好了，去做吧。这太疯狂了，因为你知道，他们不是早期创业公司，但也不是上市公司。
通常来说，至少在数据库这个圈子里，公司都是等到已经站稳脚跟之后