别太高估AI了！图灵奖得主Stonebraker谈LLM、智能体与数据库的未来
先说个最近在圈子里传得挺广的事儿：图灵奖得主、数据库界的老前辈Stonebraker在一次访谈里直接泼了盆冷水，大意是“LLM被高估了，智能体也没那么智能，你们这些人是不是把数据库忘了”。这句话在AI圈和基础设施圈同时炸了锅——搞大模型的人觉得他落伍，搞数据的人觉得他说得太客气了。
我自己的第一反应倒挺平淡，因为做数据系统做久了，大概都会对“万能模型”这类叙事本能地警惕。今天这篇文章不打算替任何一方站台，也不打算复读新闻稿，就想从工程视角认真拆两件事：第一，Stonebraker的批评到底有没有道理，道理在哪；第二，如果他说的是对的，那我们在做AI应用、做智能体、做数据基础设施的时候，到底应该怎么调整姿势。
这篇文章适合正在做LLM应用落地、搞智能体开发、或者维护数据平台的工程师和架构师看。如果你是刚入门的技术同学，也能从中看到一套相对稳妥的AI系统设计思路——毕竟，真正落到生产环境里的AI，拼的不是提示词写得有多花哨，而是“出错的时候系统会不会崩”。
1. 先搞清楚这位图灵奖得主说话的分量
1.1 他凭什么对AI指指点点
Stonebraker这个名字，可能做应用开发的年轻朋友不太熟，但你每天都在用的PostgreSQL，血缘就来自他主导的Ingres项目。后来他还做了Vertica、VoltDB、SciDB，基本上数据库圈子里每一次大的技术转向，他都在场。图灵奖颁给他的时候，官方口径就是“对现代数据库系统的概念与实践做出的奠基性贡献”。
所以他说“你们别高估AI”，不是那种不懂技术的传统行业大佬在发表感言，而是一个手把手把数据库可靠性做到了金融级别的老工程师，站在五十年工程经验的角度，对当前这股AI热潮给出自己的判断。我特别欣赏他的一点是，他很少说“AI没用”这种粗暴的话，他的核心态度一直是：AI很有潜力，但你们现在的用法和预期，离工程可靠还差得远。
回到他最近的那段观点，中心思想大致是：数据库花了五十年，才解决了并发、崩溃恢复、一致性问题，让企业敢把钱和用户数据交给系统；而LLM到现在连“稳定输出”都做不到，却有人想把它们包装成可以全权代理业务的“智能体”，这不合理。
这句话的关键词是“可靠”，不是“能力”。Stonebraker并不否认大模型能写诗、能总结文档、能聊天，他质疑的是另一个层面：你敢不敢把一个必须“说一不二”的业务逻辑，完全交给一个概率模型去执行。
1.2 LLM与数据库：一场不公平的“可靠性比赛”
数据库的可靠是有明确标准的：ACID事务、主从复制、崩溃恢复、权限控制、审计日志。每一条数据的读和写，要么成功，要么回滚，绝不允许出现“中间状态”。你在银行转账，从A账户扣了钱、B账户还没入账的时候系统崩了，数据库必须保证重启后两边都是对的。
LLM呢？同一个问题，同样的提示词，它这次答的和上次答的可能就差十万八千里。它不是坏，它天生就不是一个确定性系统。Stonebraker拿这两样东西放一起比，听起来像欺负人，但实际上是在提醒大家：我们花了五十年才建立起“数据可信”的信任基础，现在一个生成模型跑过来，就能直接在数据库之上发号施令了吗？答案显然是：不能。
但这里有一个很重要的延伸：为什么大家会想把LLM和数据库放在一起？因为用户真正想要的不是“数据库”本身，也不是“大模型”本身，而是“我能用自然语言，安全准确地操作我的数据”。这个需求是真实存在的。所以这不该是一场替代赛，而是一场接力赛——LLM负责理解人的意图，数据库负责保证操作不出错。Stonebraker真正反对的，是把接力赛跑成“LLM一个人全包”。
2. LLM的“不可靠”到底出在哪
2.1 回答流畅不等于事实正确
我在实际项目里遇到过太多次这样的场景：让GPT生成一段SQL，它语法完全正确，表名也对，逻辑也通顺，但查出来的结果跟业务方自己手工算的对不上。后来一查，发现它把“最近30天”翻译成了“DATEDIFF(day, order_date, GETDATE()) <= 30”，看起来没毛病，但业务方那边对“最近30天”的定义是从当月初开始算，压根不是滚动窗口。
这不是一个Bug，这是LLM的阅读理解问题。它读到的“最近30天”是一个自然语言描述，而它要映射到的目标世界里有各种各样的潜规则、隐含约定、边缘条件。这些规则不会写在表结构里，也不会出现在文档里，模型只能猜。问题是，它猜得再合理，对业务来说也是错的。
更麻烦的是，模型的工作机制决定了它对自己的错误“毫无感知”。它不知道哪些内容是它查证过的，哪些是根据上下文概率糊出来的。在聊天场景下这种“自信的胡说”最多让人尴尬一下，但一旦放到数据库操作层面，代价就是真实的数据污染和业务误判。
2.2 生成式系统的本质局限
从数学视角看，LLM每一次生成token的过程，都是在词汇表上做一次条件概率抽样。哪怕你固定了输入，只要温度参数不为0，输出就会有一定随机性。就算把温度设为0，很多模型也只是选择了“最可能”的那条路径，不代表“正确”的那条。
数据库处理的是确定性的数据映射：SELECT之后返回什么，是数据内容决定的，不是概率决定的。LLM没有这种“物理级保证”，它所谓的推理路径更像是一个人在脑子里快速做联想，而不是每一步都经过验证。Stonebraker说“LLM被高估”，本质上就是在说：你不能用概率过程去替代确定性过程的职责。
我见过很多产品设计，上来就是“用户输入一句话，LLM自动改数据库”。这种方案Demo阶段通常惊艳四座，因为演示数据简单、规则少、模型踩不到坑。但一到生产环境，业务规则稍微复杂一点，LLM生成的更新语句就会在某个角落里埋雷。它不是每次都被炸，但只要炸一次，业务人员的信任感就清零了。
2.3 幻觉不是Bug，是特性
很多不懂技术的人听到“幻觉”这个词，以为这是一个能通过优化修掉的缺陷。但实际上，幻觉是生成式模型的一个内禀属性。因为模型根本没有“记忆存储”和“事实数据库”的概念，它的所有知识都体现在参数里。参数是一种压缩过的经验，不是精确的记录。
这就带来一个工程意义上的结论：凡是要求“绝对事实正确”的任务，就不应该让LLM单独承担。不是它不够聪明，而是它的工作方式决定了它“天生会编”。我们需要的是一个外部的、确定性的核查层，去把模型输出里不合法的、不准确的、自相矛盾的部分拦下来。
我团队里现在有一条很死的规矩：LLM只负责提出“建议”，任何涉及入库、下单、改配置的操作，都必须经过数据库层面的约束校验或者人工审批闭环。听起来很保守，但半年跑下来，这条规矩救了我们不止一次。
3. 智能体：被过度包装的“自动执行者”
3.1 所谓智能体，很多只是LLM加了一个循环
“智能体”这个词最近几乎要被用烂了。你问他是什么，他会给你一套听起来很玄的定义：感知、记忆、规划、工具调用、自我反思。但实际上，生产环境里能跑的智能体，百分之八十的架构是同一个：一个LLM做决策，外面套一个“反复调用工具直到任务完成”的循环。
问题就出在这个循环上。当一个智能体要完成一个多步操作时，它需要在自己生成的每一步里都保持正确。如果每步的成功率是90%，五步下来整个任务的成功率就只有59%。看起来每一步都“还行”，到最后失败的概率其实非常高。
这件事用小白的语言解释就是：你让一个人连续帮你办五件事，他每件事都有九成把握办好，但五件事里只要有一件办砸，整件事就算失败，那么综合成功率已经不到六成了。数据库里管这个叫事务的“原子性”——要么别干，要干就全干成。现在的智能体框架，基本没有这个概念。
3.2 没有“事务”和“回滚”的智能体，等于在悬崖边开车
我在前面做智能体项目的时候，遇到过特别典型的事故。一个客服智能体需要先查用户订单，再创建一个退单申请，最后给用户发消息。系统设计得挺完整，但有一次它在创建退单申请成功后、准备发消息之前，遇到了上游接口超时。结果就是：退单默默建好了，但用户没有收到任何通知，跑来投诉说根本没退。
单看每一步，它都“成功”了，但从业务角度看，整个流程处于一个“半完成”状态。这就是标准的缺乏事务性。
真实世界的事务系统是怎么解决这类问题的？靠日志、靠补偿、靠回滚。要么你把这个多步流程放进一个可靠的编排器里，每一步都记录状态，出错了能回滚或补偿；要么你从设计上就避免让智能体直接执行不可逆的关键操作。
所以Stonebraker对智能体的批评，我完全认同：当前大部分智能体产品做的只是“把LLM的调用循环包装了一下”，根本没有底层的事务保障。你在上面跑简单问答还可以，跑真正的业务，心理素质得多强才敢撒手不管。
3.3 记忆、规划与工具的可靠性问题
智能体三大卖点——记忆、规划、工具调用——在工程上其实都还是半成品。
记忆方面，现在主流方案就是向量数据库存对话历史或者业务知识。向量检索有个天然短板：“语义相似”不等于“事实准确”。它可以把一条不相干但措辞相似的历史记录捞出来当依据，然后把整段推理带偏。我见过一个销售智能体，因为向量检索到了一条促销活动的旧消息，把已经下架的优惠信息当作现行政策推荐给了客户，差点造成客诉。
规划方面，LLM生成的“计划”在简单任务里像模像样，但任务一旦涉及分支条件、异常处理，计划就变得非常脆弱。它可能会遗漏一个重要的回滚分支，或者在一个死循环里出不来。你没法把这种脆弱性归咎于某个Bug，因为整个规划能力就是概率性的。
工具调用方面，最经典的坑是“工具参数格式不对”。让LLM调用一个日期处理工具，它在JSON里填了一个“2025/02/30”，工具侧一解析就崩。这不是偶发，是必然，因为LLM并不理解日期合法性，它只负责生成“长得像日期”的字符串。
这些问题的共同根源在于：智能体把“决策”和“执行”合在了一个概率模型里，而工程经验告诉我们，决策可以概率化，执行必须确定化。
4. 数据库仍然是可靠系统的地基
4.1 为什么LLM替代不了数据库
有一个问题经常被问：既然LLM这么能打，我们还需要数据库吗？问出这句话的人，大概率没经历过一次生产事故。数据库解决的不是“能不能算出来”，而是“算错了怎么办、数据没了怎么办、两个人同时改数据怎么办”。
LLM没有存储能力。你让它记住一个亿级用户的交易记录，它连零头都记不住。很多人说“用上下文窗口硬扛”，但你只要算一下token成本，就知道这在工程上根本不成立。数据库的价值不只是存，它还包括索引、查询优化、事务、并发控制、备份恢复、权限体系，这些能力是LLM完全不具备的。
我们做一个极端的假设：如果让LLM直接管理用户余额，当两个并发请求同时来修改同一个账户时，LLM根本不会处理锁和冲突。这不是它不够强，而是它的架构里压根就没设计这一层。
所以Stonebraker说“数据库仍然是未来AI系统的核心”，这句话一点都不夸张。真正合理的架构是：LLM做交互和意图理解，数据库做存储、查询和事务。两者各司其职，而不是让模型去当数据库。
4.2 语义层与Schema：给LLM一个“事实框架”
LLM不认识你的库表，但它知道你Schema里的一堆英文表和字段名，也“看”过很多SQL的例子。这带来一个关键工程实践：与其让LLM裸写SQL，不如给它一个清晰的语义层。
什么是语义层？就是把你数据库里的物理表、字段，翻译成业务可理解的逻辑模型。比如底层是一张user_order_statistics表，语义层可以定义成“用户订单统计”，并写明“统计口径是已支付且未取消的订单”。然后告诉LLM：你只需要在这个语义层上回答用户问题，不要自己去猜口径。
实际效果很明显。加了语义层之后，我这边Text-to-SQL的正确率从大概60%提到了接近85%，而且剩下的错大多是边界条件问题，不再是口径问题。因为模型不再需要“知道”业务规则，它只需要按给定规则做翻译，难度大幅下降。
数据库在这里充当的，就是那个“事实框架”：你允许模型说什么、不允许模型说什么，都由库表结构和语义定义来约束。这是把不可控的生成过程，变成可控映射过程的最有效方式。
4.3 向量数据库与数据的“里子”
向量数据库这两年借着AI东风火得不行，但我想提醒一句：向量检索解决的是“语义召回”问题，不是“事实存储”问题。你可以用向量库做推荐候选、做RAG召回、做内容去重，但如果你的业务底层是一堆需要精确计算的钱、货、库存，向量库只能做前置粗筛，真正的精确计算还是要回到传统数据库。
我见过有人把订单数据也塞进向量库，理由是“这样AI能直接理解”。这个做法非常危险：向量检索的召回结果天然存在误差，如果拿这个结果去做订单状态判断，等于在不确定性之上再叠加不确定性。正确做法是，向量库管“找到可能相关的文档或上下文”，关系型数据库管“事实与事务”，两者配合，谁也不要越位。
从我自己的实操经验看，做RAG类系统时，元数据过滤的作用比很多人想象的大得多。你可以在向量库里给每个文档打上“业务线”“时间范围”“有效状态”三个标签，检索时先过滤再向量匹配。这个技巧能把召回准确率显著提高，成本却几乎为零。
4.4 数据治理：喂给模型的数据，决定了AI的赛道宽度
这个话题和Stonebraker的批评其实一脉相承。他反复强调，AI未来的真正瓶颈不是算法，而是数据基础设施。你喂给LLM的数据如果是脏的、乱序的、口径不统一的，那你做出来的智能体、RAG系统，只会把这些脏东西以更流畅的方式呈现给用户。
我举一个很常见的例子：一家公司有CRM里的客户信息、客服系统里的沟通记录、财务系统里的订单状态，三套系统里的“客户地址”格式完全不同，有的带省市区，有的只有一行文本。把它们不加处理地交给LLM做RAG，模型就会在同一个答复里有时用新地址、有时用旧地址，有时还混着拼写错误。表面上它在认真回答，实际上它只是在忠实地反射数据的混乱。
所以做AI应用，第一条前置工作永远不是选模型、调提示词，而是把数据整理干净。数据库的角色不只是“存”，它还承担着治理：定义字段格式、建立一致性约束、保证维度表与事实表的关系可靠。这些是AI能准确回答问题的“地基”。
5. 实操：搭一个“LLM+数据库”的可靠系统
5.1 核心架构：生成-校验-兜底
聊了这么多理论，落到工程上，我推荐一套我自己反复用的架构，核心原则就六个字：生成、校验、兜底。
生成层就是LLM，负责把用户的自然语言转化为结构化的操作请求，比如SQL查询语句、工具调用参数、订单操作指令。校验层是数据库和规则引擎，负责检查这个请求是否合法、是否符合业务规则、是否触碰权限红线。兜底层是事务和审计，负责在出错时回滚、记录日志、触发人工审批。
这套架构最大的价值是把“创造性的部分”和“确定性的部分”做了隔离。LLM再怎么胡说，到了校验层都会被拦住，而不是直接落库。这不是降低效率，而是保证系统在一个可控的边界内运作。
接下来用一个实际场景演示：用户说“帮我查一下上个月华东区销售额”，系统完整流程应该怎么走。
5.2 用数据库约束给LLM“戴上手铐”
先看第一层：LLM生成请求。这一步我们不做特别复杂的处理，但会要求LLM输出一个结构化的JSON，而不是直接让它写SQL。因为JSON更利于后续校验，而且不容易被SQL注入类的内容干扰。
# 伪代码：LLM生成结构化查询请求 user_input = "帮我查一下上个月华东区销售额" llm_response = llm_generate( system_prompt="你将用户查询转换为JSON查询请求。只允许使用以下维度：区域、时间、金额。" "输出格式：{\"dimensions\": [], \"metrics\": [\"sales_amount\"], \"filters\": []}", user_content=user_input ) # 期望的合理输出: # {"dimensions": ["region","month"], "metrics": ["sales_amount"], "filters": [{"field":"region","op":"=","value":"华东"},{"field":"month","op":"last_month"}]}然后进入校验层。这一步的核心是用数据库的元数据（Schema）来校验LLM输出的字段名是否真的存在，枚举值是否正确。
# 伪代码：数据库元数据校验 from jsonschema import validate query_schema = { "type": "object", "properties": { "dimensions": {"type": "array", "items": {"enum": ["region", "month", "product_category"]}}, "metrics": {"type": "array", "items": {"enum": ["sales_amount", "order_count", "profit"]}}, "filters": {"type": "array"} }, "required": ["dimensions", "metrics", "filters"] } try: validate(instance=llm_response, schema=query_schema) except Exception as e: # 校验失败，触发行人复核或返回重新生成 log_and_review(llm_response, reason="schema validation failed", user_input=user_input) raise BusinessException("查询条件不合法，请重新描述")你可能觉得这是不是太死板了？但实际效果恰恰相反。Schema校验能把LLM输出中80%以上的“幻觉错误”拦截在数据库门外。因为你限制了它只能使用真实存在的字段和枚举值，它的自由发挥空间被大幅压缩，出错的概率也就大幅降低。
5.3 校验通过之后，才交给数据库执行
这一层就是“确定性执行”。我们基于校验通过的JSON，拼装成SQL，然后交给数据库去执行。但注意，这里拼装SQL不是用字符串拼接，而是用参数化查询或者查询构建器，防止注入。查询执行的结果再返回给LLM做最后的自然语言包装。
# 伪代码：将校验后的JSON翻译成SQL并执行 sql = query_builder.build_query( dimensions=llm_response["dimensions"], metrics=llm_response["metrics"], filters=llm_response["filters"] ) # 假设生成的SQL: # SELECT region, month, SUM(sales_amount) AS sales_amount # FROM fact_sales # WHERE region = '华东' AND month = DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month') # GROUP BY region, month result = database.execute(sql) # 执行结果落审计日志 audit_log(user_query=user_input, sql=sql, result_hash=hash(result), created_by="llm_agent")这一步的核心是“可审计”。不管最后结果是正确还是错误，整个过程都有记录，出了问题能回追。数据库在这里不仅仅是一个执行引擎，更是一个审计层。
最后一步是被很多人忽略的“结果解释”。数据库返回的是一个冷冰冰的聚合数字，LLM要做的是把这个数字转成用户能看懂的话，而不是自己重新计算。这里有一个很重要的纪律：LLM只能复述数据库返回的值，绝对不能“根据我理解”额外补充数字。我们给LLM的系统提示里会写明：所有数字必须来自提供的data字段，不得自行推算。
5.4 再加一个“防呆”设计：多模型确认与缓存
如果你对可靠性要求更高，比如是财务对账、大额交易这类场景，可以再做两层加固。
第一层是多模型确认。同一个查询请求，让两个不同的LLM独立生成JSON请求，然后对拍。如果两个模型生成的结构高度一致，可信度会高很多；如果不一致，就触发人工审核。这个做法在Text-to-SQL场景下尤其有用，因为它可以明显过滤掉纯语法性错误。
第二层是查询缓存与限流。同一类问题在短时间内被重复问，没必要每次都重新走一遍LLM生成流程。我们会在数据库侧做一个“查询指纹”表，把标准化后的SQL存下来，命中直接用。这能同时解决成本问题和性能问题。
这两层都不复杂，但能把系统的尾部风险压得很低。我始终觉得，可靠系统不是靠某一个天才设计撑起来的，而是靠一层一层“防呆”累积出来的。
6. 常见问题与避坑技巧实录
6.1 让LLM自己生成SQL，结果“看起来对、实际错”
这是所有做自然语言查数最常遇到的坑。现象很统一：LLM生成的SQL能跑通，结果也是某个数字，但跟业务方口径不符。
我的排查步骤一般是：先查语义层有没有被明确使用，再查它是否遵守了“指标口径”的定义，最后查过滤条件里有没有隐含的时间范围假设。前一阵同事反馈“近一周成交额”查错了，最后发现是LLM把“近一周”翻译成了自然周（周一到周日），而业务方要的是“最近7天滚动”。解决方式就是往语义层里加一个明确描述：“近一周=今天往前推7天，含今天”。
6.2 智能体的记忆混乱，把旧信息当成新结论
智能体带着向量库记忆跑业务，最容易出现的问题就是“记忆污染”。当向量检索召回了一批过期的上下文，模型分不清新旧信息，就会给出混合型错误答案。
我的解决方式是给向量库里的每条记忆加上“时间戳”和“状态”两个元数据字段。检索时先过滤“状态=有效”，再按时间倒序加权。这一步能让明显过期信息带来的错误减少很多。另一个技巧是，在把检索结果提交给LLM之前，先让一个固定的规则脚本把过期内容排到后面，或者直接裁掉，不让模型有机会误读。
6.3 向量检索召回精度不够，RAG答非所问
如果你发现RAG系统答非所问，先别急着调向量模型。先检查数据切分，再检查元数据过滤，最后才考虑换Embedding模型。业界有个大致感受：很多召回质量问题其实出在数据切片上——一个完整的业务段落被切得七零八落，语义自然对不上。
我建议优先把数据按“篇章级”切分，并且允许重叠。这样即使切分点选得不准，重叠部分也能保住上下文完整性。实操下来，这个优化比换向量模型便宜得多，效果却肉眼可见。
6.4 Token成本和延迟失控，智能体越跑越贵
智能体多步推理会不断消耗Token，每多一步规划、多次工具调用，费用就涨一次。很多团队做完Demo才发现，真实流量下根本烧不起钱。
我的建议是三层省钱的思路：第一层，能用规则解决的路由就不要让LLM做；第二层，复杂的工具调用尽量走“一步调用、批量执行”，减少来回对话；第三层，对高频相似查询做结果缓存。这三层做完，成本往往能降一半以上，而且可靠性不降反升。
6.5 数据库直连权限给太高，LLM一跑就是全表扫描
有些团队为了图方便，让LLM直接用高权限账号连生产库，结果一个模糊的查询触发了全表扫描，把线上事务拖垮了。这个是绝对要避免的。
给LLM执行查询的账号，必须遵循“最小权限原则”。只给它只读账号，限制超时时间，限制返回行数，禁止访问敏感字段。这些约束通过数据库的权限体系实现，比在应用层过滤要可靠得多。我自己在做这类系统时，会专门建一个“查询账号”，并用数据库的查询超时参数设置硬性上限，一旦超时就自动中断。
我在这类系统上踩过的坑确实不少，但每一个坑都让我更认同Stonebraker那句“别高估AI”背后真正的含义——不是拒绝新东西，而是用工程纪律去驾驭它。LLM负责把人的意图翻译给机器，数据库负责把机器的执行变回可信的事实，这俩配合得当，你才能得到一个既聪明又可靠的产品。至少到目前为止，所有让我放心交付的场景，靠的都是这个组合。
