图灵奖得主 Stonebraker 又开炮, 但他只说对了一半

前言: 图灵奖得主炮轰半个行业，并断言：“我可能不再建议学计算机”！AI Agent最后全是数据库问题

原文见: https://www.toutiao.com/article/7634436516479894057/

但我不同意: Mike Stonebraker 说对了一半。AI Agent 一旦从“只读助手”走向“可执行系统”，核心确实会回到数据库与事务；但这并不推出“没必要学计算机”，真正被压缩的是低壁垒编码，真正升值的是对状态、一致性、约束与系统责任边界的理解。

下面咱们就来进行深入推演.

旧文真正说了什么

原文大致有六个主张。

1. Postgres 是最好的起点，但不是所有场景的终点。
   基石假设是：数据库的性能上限取决于是否按场景定制，而不是靠一个通用系统包打天下。

2. Google 当年的 MapReduce + eventual consistency 路线被高估了。
   基石假设是：一旦业务进入真实读写世界，事务和一致性不会消失，只会以更昂贵的方式回来。

3. AWS 支持太多数据库，很多只是重复建设。
   基石假设是：数据库品类分化是必要的，但分化不是无限的，市场最终会回到少数真正有性能或模型差异的系统。

4. 今天的 agentic AI 大多仍是“只读系统外包一层 LLM”。
   基石假设是：一旦 Agent 真正拥有写权限，它就不再只是推理问题，而是状态变更问题。

5. text-to-SQL 在公开榜单上看起来接近可用，但在企业环境里仍远未达标。
   基石假设是：真实世界数据库的复杂性，不是多加一点 prompt engineering 就能抹平。

6. 因为 AI 会改写软件生产方式，计算机科学可能不再是增长型行业。
   基石假设是：写代码约等于计算机行业本身，编码效率提升会直接压缩整个学科的长期需求。

把这六点压缩成一句话，旧文真正的结论其实是：

AI 不是在消灭数据库，而是在把所有“看上去像智能”的系统重新拖回状态管理、事务一致性和系统约束这些老问题上。

这个判断很强，也很有洞察力。但原文后半句又进一步滑到了另一个命题：

既然代码越来越容易生成，学计算机可能就不再划算。

问题恰恰出在这一步外推。

旧逻辑的关键漏洞

漏洞一：把“程序员岗位的重组”误写成“计算机学科的衰退”

美国劳工统计局最新 2024-2034 预测并不支持“整个计算机方向不再增长”这个强结论。
Software developers, QA analysts, and testers 总体就业预计增长 15%，软件开发者单项增长 16%；但 computer programmers 这一更偏“纯编码执行”的职业预计下降 6%。这说明被压缩的是更可替代的编码分工，而不是整个计算机相关需求一起塌缩。

也就是说，Stonebraker 看到的是对的现象，但他的职业建议过于粗粒度。

漏洞二：把“Agent 最终是数据库问题”说得太窄

这句话抓住了最硬的一层，但还不够完整。
当 Agent 开始读写现实系统时，确实需要事务、幂等、回滚、一致性、故障恢复；但除此之外，还会立刻碰到权限、审计、可观测性、人机审批、责任归属、跨系统补偿这些问题。数据库是底座，不是全部。

更准确地说，Agent 最终会变成：

状态机问题 + 事务问题 + 权限问题 + 观测问题 + 责任问题

只是其中事务层最接近数据库学派的话语体系，所以最容易被率先看见。

漏洞三：把公开 benchmark 与企业 benchmark 的落差，直接推成“LLM 永远不行”

BEAVER 这篇论文确实很扎实。它直接指出，企业 text-to-SQL 之所以难，不只是模型笨，而是因为企业数据仓库有三个结构性难点：私有数据不在训练语料里、schema 更复杂、查询本身更复杂。论文在真实企业仓库上测得的结果是，现成模型的端到端执行准确率“接近 0”。

但这更像是在说明：

靠一个通用 LLM 端到端裸写企业 SQL 不行

而不是：

所有以 LLM 为核心的结构化查询交互都不行

前者大概率成立，后者则还没有被证明。

漏洞四：把“Google 当年错了”说成“数据库老路最终全胜”

Stonebraker 对 eventual consistency 的批评，后来确实被 Spanner 的路线部分验证。Google 官方资料明确写到，Spanner 提供的是比 eventual consistency 更强的 external consistency，并支持外部一致的分布式事务。

但这并不代表“数据库世界没变”。真正变化的是：

大家不是回到旧数据库，而是把分布式系统、时钟、不确定性、复制协议这些代价一起吃下去，重新造了一层更贵但更强的一致性系统。

也就是说，老问题回来了，但它们是在新规模、新成本、新架构约束下回来的。

如果基石假设崩塌：新假设是什么

旧文后半段默认的基石假设是：

如果代码生成更便宜，那么学计算机的价值就会下降。

这个假设站不住，因为它把“写代码”错当成了“计算机”的本体。

更稳的新假设应该是：

AI 会持续压低“把意图翻译成语法”的成本，但不会压低“为真实世界设计正确状态转移”的成本。

一旦换成这个新假设，结论就完全变了：

未来更值钱的，不是能更快写出函数的人，而是能为 Agent、工作流和数据系统定义状态边界、失败语义、补偿规则、权限模型和验证机制的人。

新观点：AI 时代真正稀缺的不是代码，而是“可验证的状态设计”

1. AI 先替代语法，后暴露状态

今天很多人把 AI 的强弱，理解成“它能不能把自然语言变成代码”。这是第一层。

但一旦系统真正接入支付、库存、订单、权限、工单、审批、交通、医疗这些真实流程，难点立刻上移。
你不再问“模型能不能生成一段函数”，而是问：

• 这次写操作到底有没有提交成功？
• 失败后是重试、补偿，还是回滚？
• 两个 Agent 的并发写入如何避免双花、超卖和脏状态？
• 外部 API 成功、内部数据库失败时，谁负责收拾残局？
• 多步骤工作流跨天中断后，如何从正确位置恢复？

这时，LLM 只是前端智能层，真正决定系统能否上线的是后端状态语义。

2. 所以 Stonebraker 看见的不是“AI 抢走了数据库”，而是“AI 把数据库推回舞台中央”

DBOS 的官方定位就很说明问题。它不是在卖一个更会写 prompt 的工具，而是在卖 durable workflow orchestration，把工作流、队列、Agent 执行、失败恢复、可观测性与数据库状态绑定起来。
这背后的需求信号很明确：行业开始意识到，Agent 不是“答得像人”就够了，而是必须“像系统一样可靠”。

这也是为什么 Stonebraker 会说，Agent 最终都会变成数据库问题。
这话翻译成工程语言，其实就是：

当 AI 从“建议”变成“执行”，系统设计会从 prompt engineering 回落到 transaction engineering。

3. 但这并不意味着“只要学数据库就够了”

如果把新世界理解成“以后都是 SQL 和事务”，那还是理解窄了。

未来高价值工程能力，至少包含五层：

1. 意图层：把模糊目标拆成可执行步骤。
2. 状态层：定义哪些状态可持久化、哪些状态可回滚。
3. 事务层：保证原子性、一致性、幂等、补偿。
4. 治理层：权限、审计、审批、人机协作。
5. 验证层：监控、追踪、重放、故障归因、形式化或半形式化校验。

数据库只覆盖了第 2-3 层的核心部分。
所以更准确的说法不是“AI Agent 最后全是数据库问题”，而是：

AI Agent 最后会收敛成一门以数据库约束为核心的系统工程。

4. 为什么 text-to-SQL 的失败恰好支持这个判断

BEAVER 的结果很关键，因为它说明一件常被忽略的事：

企业软件难，不是因为缺 SQL 语法；而是因为企业世界本身就是高耦合、高上下文、高约束的状态空间。

论文里 BEAVER 只有 93 个查询，但平均每个数据库 105 张表、每个查询平均 4.25 次 join、4.67 次聚合、嵌套深度 1.95，复杂度远高于 Spider 和 Bird。
这意味着企业查询不是“把一句中文翻译成 SQL”这么简单，而是“把一句意图映射到一个私有知识图谱和约束系统里”。

所以 LLM 在企业 SQL 上翻车，并不是偶然 bug，而是暴露了一个更底层的事实：

语义映射如果脱离了真实 schema、真实关系、真实业务上下文，靠语言模型本身是兜不住的。

5. “还该不该学计算机” 的正确改写

如果你把“学计算机”理解成“背 API、刷语法、写 CRUD”，那风险确实在上升。
如果你把“学计算机”理解成下面这些能力，风险反而在下降：

• 抽象现实流程为状态机
• 为多步骤系统设计失败语义
• 让跨系统写操作具备可恢复性
• 识别数据模型、索引、延迟、一致性之间的权衡
• 为自动化系统建立审计和责任边界

这类能力恰好因为 AI 普及而更稀缺，不会更廉价。

逻辑三洽检验

• 自洽: 新观点没有否认 Stonebraker 关于事务、一致性、企业 SQL 困境的判断，只是否认了“因此不再建议学计算机”这一步过度外推。
• 他洽: 它能同时解释四类事实。Spanner 说明大规模系统最终重新拥抱强一致；BEAVER 说明企业语义映射极难；DBOS 说明市场开始为“可恢复工作流”付费；BLS 则说明职业结构在重排，但软件开发整体需求仍增长。
• 续洽: 如果这个新观点成立，那么未来几年最值钱的工具不会只是“更会生成代码”，而会是“更会保证状态正确”的基础设施，例如 durable execution、workflow runtime、事务化 Agent 框架、审计与回放系统。

未来主要观测信号

1. 更多 Agent 框架会把 workflow durability、human-in-the-loop、replay、idempotency 做成默认能力，而不是外挂能力。
2. 企业采购会从“买一个更聪明的模型”转向“买一个可审计、可恢复、可回滚的自动化执行平台”。
3. text-to-SQL 的主流方案会减少“端到端直接生成”，转向“schema 检索 + 结构化规划 + SQL 约束生成 + 执行验证”的多阶段系统。
4. 工程岗位会继续分化。低壁垒编码岗位承压，但系统、数据、平台、安全、可靠性相关岗位继续扩张。
5. 如果未来公开数据显示软件开发整体就业也开始持续转负，而且 durable systems 工具需求没有上升，那本文的新假设就要被修正。

结论

这篇访谈最值得保留的洞察，不是“别学计算机了”，而是下面这句更硬的话：

AI 让“生成代码”变便宜，但让“生成正确状态变更”变得更贵、更难，也更关键。

所以真正应该更新的，不是对计算机的信心，而是对“什么才算计算机核心能力”的定义。

未来的护城河，不会只是会写程序。
未来的护城河，是你能不能把一个会犯错、会中断、会并发、会越权的智能体系统，约束成一个可验证、可恢复、可追责的真实系统。

这件事，恰恰比过去更像计算机科学，而不是更不像。