别太高估AI了！图灵奖得主Stonebraker谈LLM、智能体与数据库的未来
原创 编译自 2026-09-28 07:15 广东
他始终坚信：其它数据模型终会被关系模型吸收。
Mike Stonebraker是Ingres和Postgres两大开源数据库的创始人，2014年获得图灵奖。半个世纪以来，他始终站在数据库系统的最前沿，并坚信：其它数据模型最终都会被关系模型所吸收。
但在智能体AI爆发的当下，Mike Stonebraker的这套逻辑是否还成立？LLM和基础模型会成为第一个例外吗？DBOS想用数据库重新定义操作系统，它看到了哪些亚马逊和谷歌没有看到的东西？当AI智能体开始对真实系统执行写操作时，首先会出什么问题？
在这场近80分钟的对话中，Mike Stonebraker逐一回应了这些问题。本次对话还涵盖以下内容：
一、LLM正在打破关系数据库模型吗？
二、为什么Text-to-SQL仍然存在不足
三、AI能理解企业数据吗？
四、用DBOS重新思考云
五、当AI智能体执行写操作时会发生什么？
六、Stonebraker进入计算机科学的道路
七、Oracle如何击败Ingres
八、PostgreSQL为何胜出
九、基于数据库的操作系统
十、Claude如何改变软件开发
十一、AI与技术债务问题
十二、图数据库有未来吗？
十三、谁不配获得图灵奖？
十四、AI、中国与西方科技的未来
以下为这场访谈的中文编译。
一、LLM正在打破关系数据库模型吗？
Q：您之前的观点是：其它数据模型最终都会被关系模型所吸收。然而，现在超级智能时代的数据结构（如端到端可微的压缩知识）与关系模型完全不同。LLM和基础模型是否会成为例外，不再被归入关系模型？
Mike：把这个思路稍微延伸一下，应用到智能体AI上，实际上所有为智能体AI提供数据的数据源都是关系型的。我做过不少相关工作，传统智能体AI无非就是类似Claude或OpenAI的系统。当你要连接两个数据源时，它们会被转成文本，做文本对文本的连接，这丢掉结构，显然是很糟糕的做法。
在我看来，如果你要连接两个表，就应该保持它们为表，进行表对表的连接。如果要连接表和文本，更好的做法是把文本（或者文档）转成表，然后再做表对表的连接。基础模型的一大缺陷就是只处理纯文本，这将来会成为一个很大的弱点。这一切到底会怎么演变，还有待观察。
我们最近在跟德国慕尼黑市交通局合作，做一个Agentic AI的项目。他们那边有四个人全职负责回答市民的问题和投诉。一个非常典型的投诉就是：人行横道的绿灯时间太短，还没走完就变红了。要回答这类问题，他们就得调取下面这些数据来源。
首先，他们需要查阅规则和法规，既包括市级的也包括州级的。那是文本，属于典型的LLM处理范畴。但接着，他们需要调取交叉口的CAD设计图，确定交叉口有多宽。规则和法规里规定了行人步速的假定值。然后他们还要查阅有轨电车的时刻表。
另外，他们需要访问慕尼黑地图，以确定投诉所指的具体是哪个交叉口。因为市民很可能只会说“我家门口的人行横道来不及过”，这本身就是歧义表述，必须借助地图来定位。
最后，如果投诉时间正好在学校上学或放学时段，人行横道的信号时长会相应缩短或延长，以适应学生的需求。所有这些信息都用于判断市民的投诉是否合理。这其中，规则和法规是文本数据，其余全都是各种结构化数据。他们曾尝试使用传统的智能体AI方案，但完全失败了。
二、为什么Text-to-SQL仍然存在不足
Q：现在基础模型的预训练数据可以说跟关系型表格数据毫不沾边。它们看起来就是长串的Unicode纯文本，这几乎就是它们的原生形式，甚至连token都不是数据库token或表token。未来会不会出现这样一种情况：表本身不再是数据结构的基本单元，而一切都会归约到表之下某种抽象层，最终看起来就像BPE或纯文本？基础模型在Text-to-SQL上的能力天花板在哪？
Mike：有四个原因会导致Text-to-SQL效果不佳。
第一，数据仓库从来不在公开领域，它们一直在防火墙后面，所以LLM没办法拿它们训练。这样一来，如果你问类似“Mike Stonebraker在哪个部门”这样的问题，除非刚好某篇新闻报道中有相关公开数据，否则这个信息不会出现在训练集里，你也就得不到答案。
第二，我认为这个是根本原因。Spider、Bird 这类数据集里，表名如employee、department，列名如salary等，命名语义清晰。但像MIT数据仓库，会出现类似_XYZ这类命名，存在非规范命名的字段与表、语义互相重叠、物化视图混杂等现象，我将这类现象称为模式腐化。绝大多数运行数年以上的现有数据仓库，几乎都会出现模式腐化问题，你必须要处理。除非算力成本降到足够低，可以直接基于MIT真实数据仓库开展训练，否则这套思路根本行不通。
第三，MIT数据仓库中还有大量特有的业务数据。举个例子：J‑term是MIT独有的概念，代表一月份为期一个月的教学学期，几乎没有其他机构使用该概念。如果你向大模型询问和J‑term相关的问题，几乎不可能得到有用的答案。
第四，如果你问MIT计算机科学楼的名字（MIT的建筑是没有名称的，它们只有编号），这也是特殊数据的例子。在真实的数据仓库中，四表、五表连接是十分常见的查询，复杂度远高于公开基准数据集里那些学生编写的查询。把以上这些问题叠加在一起，就意味着，Text‑to‑SQL技术距离真正落地可用，还有很长一段时间。
Q：具体是多长？
Mike：那我倒是很好奇，成本要降到什么程度，MIT行政部门才会愿意用内部全部数据训练大模型，生成一份能用的数据字典。这份字典要做到两点：明确每个字段的业务语义，同时完整记录数据血缘。这样一来，遇到由其他字段计算衍生出来的列，就能追溯清楚它的来源。以MIT现有数据仓库的现状来看，恐怕永远都实现不了。
三、AI能理解企业数据吗？
Mike：你不能只是把对应真实数据仓库中四表连接的文本，扔给一个智能体AI就指望得到答案。当然，如果schema结构良好，或者企业内部有非常资深的AI人员，比如像Google那种情况，可能行得通。
但如果是传统企业，我觉得情况远没有想象的那么乐观。实际情况当然不会走向两个极端，但现实是，几乎每家企业都搞过各类AI试点。可真正走到生产环境的，大概只有20%。企业落地这项技术，依旧阻力很大。
Q：听您的描述，这最多也只是训练数据的难题，前沿实验室或许可以做得更好：针对关系数据库领域的高难度任务，改进模型的中间训练、后训练或者强化微调。你提到的这些现实难题，只靠拿数据库任务对前沿模型加大后训练力度，就能解决吗？
Mike：首先，没有多少企业愿意把自己的数据交给OpenAI，所以你必须考虑本地部署模型，也就是开源模型。因此得从这一点出发。其次访问控制是个大麻烦。MIT数仓里存着薪资这类敏感信息，不管什么模型，都必须遵守现有的权限管控规则。还有一堆落地难题常常被忽略，这些才是真正落到现实环境里绕不开的问题。
四、用DBOS重新思考云
Q：三年前您和Mahi Zahara共同创立了DBOS，核心理念是：云已经超出了那个已有33年历史的Linux所能承载的范围，操作系统应该是一个运行在数据库之上的应用，而不是反过来。那么DBOS对云的理解，有哪些是亚马逊和谷歌不具备的？
Mike：当初我们拿着这个项目去找风投，对方直接说，想要取代Linux纯属是白费力气，就算能成功，也要十年的推广时间。但投资人认为，抛开替换Linux不谈，这个项目的底层思路很有价值。我们的核心设想是：操作系统所有关键状态，都交给数据管理系统管理。这样状态可以恢复，还能写出可扩缩调度器，处理各类问题会简单不少。
我们就在研究项目基础上，给DBOS做了一套应用环境，把这套思想延伸到编程语言：所有核心状态存进数据库，整体效果会好很多。风投很看好这个方向，让我们聚焦这一块。
那个时候通用AI开始兴起。在DBOS看来，通用AI就是围绕一个或多个大模型搭建的图状工作流。第一，它是工作流，里面可以有循环、各种复杂逻辑，但它不是单个程序，而是一整套任务。第二，运行时间长，算力开销极大，毕竟大模型本身就很耗算力。于是就出现一类重要应用：既是工作流，又十分消耗算力。
很多做智能体AI的人已经意识到，他们需要持久化工作流。工作流每做完一步就要留存状态；一旦出事，不用从头重来，恢复到已经完成的步骤就够。这就是持久化工作流：故障发生时，可以回退到每一步执行成功后的稳定状态。这正好对应ACID中的D：持久性。
我们希望编程语言直接复用数据库的这套实现思路：状态存入数据库，大部分问题就能解决。当然还有不少复杂细节，所以DBOS现在核心做的就是持久化工作流，重点服务Agentic AI，这也是当下行业很重要的落地场景。
五、当AI智能体执行写操作时会发生什么？
Q：现在的智能体大多是只读的。那么当它开始对外部系统执行写操作时，首先会出什么问题？这个问题的解决方案，你们的领域在四十年前已经完成了多少？
Mike：假设有一套工作流，要给你调薪，调薪是工作流的一个步骤，本身属于一个事务，这个步骤执行完成之后，事务就已经提交。后续流程跑了一阵之后，有人发现加薪幅度太高，希望撤回这个操作，这个时候就需要回滚已经提交过的事务。
更麻烦的是，在调薪提交之后、执行撤销之前，如果有其他人修改过你的薪资，就不能简单物理抹除本次变更，必须做补偿回滚逻辑。数据库领域早在80年代就研究过这类问题，对应的概念就是Saga（长事务补偿）。Saga的核心，就是如何对已经完成提交的事务做补偿回滚。
再看ACID其余特性。隔离性基本不再适用：一旦业务范围超出单条事务，除非把整个大业务封装成一个巨型事务（没人愿意这么做），否则就无法保障隔离性。
接下来是原子性。绝大多数场景下，我们都希望智能体工作流要么完整跑完，要么看上去什么都没发生过。举个例子，有个售卖自行车的网站，后端由智能体AI驱动。客户选中一辆自行车发起购买。整套工作流逻辑如下：
首先核查库存；如果本地无货，就查询备选仓库；库存充足则继续往下走。接着核验客户信用资质，判断是否允许成交。信用核验通过，再执行收款，这又是一笔独立事务。如果客户信用卡无效，就需要做补偿撤销。假设全部环节都顺利，最后执行发货。但如果客户提供的地址无效，无法履约，依旧要撤销整套业务。购买自行车这个业务，理应具备原子性。种种边界条件意味着，工作流要实现原子性，实现难度不小。
六、Stonebraker进入计算机科学的道路
Q：您从小镇少年，一路到普林斯顿大学，再到密歇根大学，之后去往伯克利，如今来到麻省理工学院。作为计算机领域的里程碑式人物，您是什么时候第一次意识到，计算机将会席卷、改变整个世界？
Mike：我进入普林斯顿大学时，选择主修电气工程。很大一部分原因是，我的数学SAT考了800分，英语SAT只有500多分，所以注定要走理科这条路。没有什么特别的理由，我就成了一名工程师。况且我父亲本身就是电气工程师，选这个方向也算顺理成章。
读到大三的时候，计算机将会改变整个世界这件事，其实很明显。不过我并不觉得自己当时多么有先见之明，只是很清楚，想要找份好工作，掌握计算机技能是最好的选择。那时候还没有计算机科学这个专业，所以你可以直接自称计算机专家，然后开始选计算机课程就行了。
还有一个因素是，我毕业的时候刚好赶上征兵和越南战争打得正激烈。当时的选择无非是：去越南、进监狱、去加拿大，或者读研究生。读研几乎是我不用犹豫的决定。
七、Oracle如何击败Ingres
Q：不少人都觉得，您做的Ingres强过Oracle。那个时代的销售套路是什么？市场博弈中，到底是好技术赢，还是别的东西赢？为什么现在Oracle名气远大于您做的Ingres？
Mike：Oracle比Ingres早成立一年。到1984年，也就是双方成立三年的时候，我们的增速超过了Oracle，眼看就要实现反超。但随后发生一件大事：IBM发布了支持SQL的DB2，而Oracle原生就支持SQL。尽管在当时业内所有人看来，QUEL是更优秀的数据子语言，但QUEL的时代就此终结。
之后的12个月里，我们对Ingres做了重大重构，增加SQL支持。可等到改造完成，Oracle已经遥遥领先，大局基本已定。所以，Oracle能够成为行业霸主，你可以把原因归咎于IBM，当然Ingres也算不上彻底消亡。
在我看来，Oracle当时还使用了各类名声很差的销售手段。举个典型例子：80 年代初，引用完整性成为一项关键特性。我们的产品已经实现这个功能，并且对外如实说明功能可用、行为符合设计预期。
反观Oracle，它的手册里确实写了引用完整性的相关文档页，但在页面底部有一行小字脚注：尚未实现。他们就这样混淆 “现已具备” 和 “未来将要实现” 的产品状态，并且靠这套手段得逞。
八、PostgreSQL为何胜出
Q：伯克利当时的规定是校内产出的全部成果都属于公有领域。所以任何人都可以拿到Ingres的磁带源码；PostgreSQL采用的许可协议，允许所有人任意使用代码。之后你就离开了该项目。后来两名研究生给它补上SQL能力，一个志愿者社区接手了这个无人维护的项目。时至今日，Postgres已经是全球使用最广泛的数据库。
您曾评价Postgres是开源软件的典范，它不属于任何一家公司。说实话，把成果无偿开放，这是刻意规划的策略，还是纯属意外？而Postgres的成功，对于AI时代基础设施该由谁掌控这件事，有什么样的启示？
Mike：首先要澄清，将成果开源不是伯克利的规定，而是我个人的决定。那时候我正争取终身教职，我唯一的想法就是让Ingres获得更高知名度。最直接的办法，就是任何人想要源码磁带，我都提供给他们。后来这就成了伯克利的一项传统，大体上就是从Ingres开始的。
而且整件事完全是机缘巧合。你刚才提到的两名学生实现了SQL支持，之后一批和伯克利毫无渊源的志愿者接手了项目。我甚至根本不认识这些人，他们拿到代码，开始维护、迭代，一干就是整整三十年。
最让我觉得不可思议的是，Postgres核心委员会大概有二十位成员。微软、EDB、谷歌等和多诺企业都在为Postgres的维护和功能迭代贡献力量，而这个项目不属于任何一家公司。Postgres如今能占据统治地位，有一部分原因是：Oracle收购了 MySQL，MySQL归入Oracle麾下之后，开发者社区大批出走。
开源本身具备巨大优势。可惜OpenAI和Anthropic并没有秉持这套理念。后续会如何发展我们拭目以待。在我看来，很快就会出现这样的局面：各家基础模型的准确率差距只剩几个百分点。于是很多业务场景下，比拼的就不再单纯是输出效果，而是每一块钱能拿到多少有效输出。
当然Claude代码能力这类领域未必如此，但大量AI场景都会进入这个阶段。一旦走到这一步，开源模型的成本会远远低于闭源模型。比如DeepSeek，它的成本就远低于美国的各大基础模型。后续走向仍有待观察，但我内心是希望开源能够取得最终胜利。
九、基于数据库的操作系统
Q：DBOS刚开始的时候，微软的Longhorn项目，比尔·盖茨当时说要异想天开地重建Windows，经过一番曲折最终演变成了Vista。但我记得最初的概念，其实是要用对象关系数据库，或者围绕对象关系数据库，从零开始重建Windows。结果彻底失败了。您觉得Longhorn出了什么问题？
Mike：我跟当时在场的很多人聊过，他们基本上都说Longhorn这个想法本身是很好的，但微软在执行上搞砸了。他们不断变更规格，不断地加功能，导致功能膨胀，最后变得过于庞大而难以掌控，最终不得不把它砍掉。所以我觉得问题出在管理不善，而不是想法或技术本身有问题。
Q：在我听来，DBOS最早的构想，其实是实现所谓Longhorn梦想：打造一套操作系统，甚至在内核层面，整体构建在关系数据库之上。按照访谈里的叙事，经过多次方向调整、辗转迭代，现在它更多变成一套为Agentic AI打造的、强可靠的关系型持久化执行层，不再执着于用关系数据库去替换内核的大量组件。如果这个解读大体成立，那我们什么时候才能真正见到那个Longhorn式的终极构想落地？
Mike：站在风投的视角，想要取代Linux，推广周期会长达十年。想要去替代现有成熟产品，市场落地周期会极其漫长。除此之外，还要补齐Linux周边全套繁杂的配套：全球各式各样硬件设备，都要有对应的设备驱动，这背后是海量的基础设施工作。
我回想，如果我们当初的定位是保留Linux，做增强版本。对外依旧叫Linux，只是替换掉部分内部核心模块，以此得到一套更优秀的系统。这本该是一条稳妥得多的路线，可惜我们并没有这么做。
十、Claude如何改变软件开发
Q：如今身处超级智能时代，很多曾不可行的宏大项目突然变得可行。比如Linux内核正逐步用Rust重写，这在过去社区难以接受，如今已慢慢普及。而Postgres社区最近也完成了完整的Rust移植版本。既然如此，应该完全有可能让一个资源不多的人发起项目，以关系数据库为核心重写Linux、BSD或其他开源内核，这在过去几乎不可能，原因正是您提到的设备驱动程序和各种内核组件等难题。
Mike：我认为Claude有一个非常厉害的能力：直接丢弃旧代码、整体重写，这已经成为和打补丁、在原有代码上迭代并列的可行方案。所以我觉得所有企业都可以借鉴这个思路：利用这种手段，分步、分模块淘汰遗留旧代码，换成更现代、更容易维护的系统。可以说，Claud催生了一批三年前根本无法落地的软件开发策略。
Q：某种意义上，您是现代关系型数据库的元老级奠基人，还有谁会比您更适合来完成这件事？您有没有想过，再放手搏一次，冲击这个宏大目标？
Mike：如果我真要去做这件事，现在投资DBOS的风投们会跟我拼命。
Q：但您不觉得这其实只是个周末项目，花一点点预算就能做，根本用不着风投的钱吗？
Mike：我觉得做一个原型并让它跑起来，确实可以很快完成。但接下来，你得让它真正好用，除了跑得快还要持续提供支持。所以我认为，这件事真正落地的话还是需要相当规模的风投资金。我现在处于一种利益冲突的尴尬位置。但说实话，我觉得那确实是一件非常值得尝试的事情。
十一、AI与技术债务问题
Q：您还有没有别的希望业界推进的重大目标？还是说数据库驱动操作系统就是你心中唯一的最高理想？
Mike：相比那个终极操作系统，我更希望看到另一件事。我接触到的每家企业，都拖着一块沉重的巨石，也就是遗留代码。最棘手的是其中大量是COBOL代码，已经很难招到能维护它的开发人员。
现实情况往往是：企业收购别家公司，连带接手整套业务系统，维持被收购方原有系统继续运行。没有人愿意投入成本，把新收购的系统和自有系统做深度整合。于是就新增又一个数据孤岛。企业内部到处都是数据孤岛，严重阻碍业务推进。
而智能体AI蕴藏巨大潜力：它不再制造新的孤岛，可以在前期就完成系统整合，逐步消除存量孤岛，而不是继续新增孤岛。企业IT预算里95%都消耗在系统维护上，能留给创新业务的资金所剩无几。遗留系统正在极大拖累各家企业。我非常希望有一天，遗留代码不再成为前进路上巨大的阻碍。
十二、图数据库有未来吗？
Q：您之前提到对已提交事务做补偿回滚。与此同时，图数据库近年来也常被讨论。您怎么看图数据库？它们是否具有关系型数据库无法替代的核心价值？
Mike：Andy Pavlo和我在17年前发表过一篇论文，题为《What Goes Around Comes Around》。文章的核心观点是：2008 年之前出现的各类专用数据模型，本质上都算不上好方案。去年我们又写了续篇《What Goes Around Comes Around …And Around》，发表在《SIGMOD Record》。这篇论文提出：过去17年涌现出来的各类数据模型同样存在缺陷，其中也包括图数据库。
图数据库的问题在于：图完全可以建模成一张边表加一张节点表。基于这套关系表结构执行查询，性能往往优于原生图数据库实现。举个例子，Neo4j 的性能表现其实并不理想。亚马逊也有自研图数据库产品，而它底层恰恰就是采用我刚才说的这套关系表的方式实现。
我认为到目前为止，图数据库一直是被关系数据库压制的一方。唯一可能成立的用例是，当你需要找从节点A到节点B的最短路径时，你会希望借助某种算法。但问题在于，如果你能把那个图用某种专有的数据结构放在主存里表示，那些都是非常复杂的算法。你根本不该用数据库系统，而应该用主存中的精巧表示，配合高度应用特定的算法，这样性能能快两个数量级。图数据库有它真正的适用场景，但至少到现在，我还没看到那个场景在哪里。
十三、谁不配获得图灵奖？
Q：回顾历届图灵奖得主，有没有您觉得不应该获奖的人？有没有被委员会遗漏、本应获奖的人？
Mike：我个人觉得，1979年的获奖者Charlie Bachman是不配拿奖的。当时评选委员会的组成偏向编程语言领域的人，给了他们不成比例的奖项。现在的话有很大的政治因素在左右，大家要讲公平。我认为它已经变得有些政治化了，至于它有多重要，我想它确实表彰了了不起的成就。但问题是，早期容易选，比如Knuth、Minsky这些奠基人。现在难度大得多，因为领域扩大了，参与的人也很多。它对于获奖者来说确实是一个很重要的纪念。
十四、AI、中国与西方科技的未来
Mike：我的看法很简单：美国现在正在被中国赶超，甚至已经在加速发生。所以现在开始学中文，准备面对一个不再由我们主导的世界。
Q：我要反驳一下这个观点。严格来说，除了文化交流、智力启发和心理健康外，现在学外语已经没有什么意义了，AI翻译足够强大。您真认为西方在超级智能时代正在衰落？人们为什么还要费心学中文？
Mike：因为我觉得一个18岁年轻人，在15年后为中国公司工作的可能性相当高，我认为世界上的企业将会由中国主导。
Q：为什么您觉得15年后美国人会去为中国的公司工作？
Mike：中国拥有40所非常优秀的大学，持续输出大量STEM人才，且人口是美国的十倍。再看美国的研究生院，包括MIT在内，尽管没有确切统计数据，但学生构成中亚洲人大概占了一半。以SIGMOD会议论文为例，20年前约80%来自美国，欧洲和亚洲各占10%；而去年，亚洲论文大约占了三分之二，其余来自世界各地。如果将会议论文视为先行指标，美国正在被中国超越。
Q：今年在SIGMOD会场走廊里听到的最流行的语言确实是中文，这一点我接受。但我不认为这能构成15年时间尺度上的终局叙事。AI已经强大到可以让你现在就让写SIGMOD论文，而且写出来的大概也还不错。因此，无论SIGMOD或其他ACM期刊会议论文的署名以中国人还是美国人为主，更合理的预期或许是：15年后这些论文中的绝大多数将由AI撰写。
Mike：到目前为止，主要的进展都来自相对少数的精英，也就是那些非常聪明的人。如果这个精英群体变得不再重要，那么基本上我们就生活在一个由机器掌控的世界里。我可不想活在那个世界里，我庆幸现在自己老了。
作者丨Imagination in Action 编译丨dbaplus社群
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn