本文转载于Zilliz CTO 栾小凡知乎回答《写在Data + AI Summit 2026 之后》： https://www.zhihu.com/question/25529315/answer/2055545998664012216

看完今年的 Databricks Summit，我记下了一些还不算成熟的想法。关于一个我反复琢磨的问题：当 AI 真正走进生产，数据这一层会变成什么样。先说一个我比较确定的判断，再说几个我自己也还在想的地方。

先说结论：会被重新定价的，是数据这一层

说实话，这次 Summit 给我最大的感受，不是 Databricks 又发了多少东西，而是它让我更确定了一件事：AI 这一轮，算法、算力、数据这三样里，数据是被定价得最慢的那一个。

算法在公开地快速迭代，算力被和云厂商重估，这些都看得见。数据这一层最慢——不是因为它不重要，恰恰是因为它最难。企业的数据是脏的、散的，权限缠成一团，业务语义对不上，所谓"实时"基本就是一个夜里跑的定时任务。这种活又苦又慢，还不好讲故事。

其实就在前不久，我还在和一些做模型的朋友聊——包括 OpenAI、这条线上的人。聊到最后，话题几乎都会绕回同一个地方：模型在趋同，算力能用钱买到，到头来真正还算得上护城河的，只剩数据。这句话，我越想越认同。

而且这不是只有应用层才头疼的事。哪怕在模型公司内部，真正决定模型质量的，到头来还是那条数据 pipeline——一次训练动辄要先花好几天准备数据，这个环节的容错率低得吓人：上游一个字段脏了、一批样本配错了，几天的算力和等待就这么打了水漂，等你发现，loss 早跑歪了。

到了 agent 这边，问题其实是同一个，只是换了张脸。AI 一旦往生产里走，最先卡住你的，几乎都不是模型不够聪明，而是数据——这条没权限、那条已经过期、上游数据源昨晚又悄悄脏了。前阵子我就眼看着一个很强的团队，整整一周不是栽在模型上，而是栽在一条悄悄过期了六个小时的上下文管线上——agent 一直信心十足地回答着"昨天"的问题，连他们自己一开始都没看出哪里不对。这才是真正的失败模式：不是模型笨，是它拿到的上下文是过期的、不可信的、查一次很贵、出了错还查不到是哪一步。所以我越来越相信，接下来被重新定价的，会是数据这一层。

算法和算力已经被市场抬起来了；数据还是那根最矮的柱子——而它，是下一个要被抬起来的

方向上，Databricks 这次没看错

我对很多"AI 数据平台"是有保留的，因为太多是先有故事、技术后补。但这次我愿意认真看，有两个挺朴素的理由。

一个是，它的创始人到现在还站在台上，讲执行引擎、讲事务、讲实时分析这些最底层的管道。说句心里话，这点我是真欣赏——一家做到这个体量的公司，founder 还在第一线 care 引擎怎么跑得更快，还保留着那种对产品的工程直觉，这不是销售驱动的公司能装出来的。我们自己也是一拨 engineering-driven、信奉 hands-on 的人，所以特别能体会：真正的技术 sense 和"一直在一线做事"，是会从产品的每个细节里透出来的，骗不了人。

另一个，其实是它的客户。这次在 Databricks Summit 上和不少用户聊下来，我最大的感受是：这拨人对 AI 的理解明显更深，也更激进——他们是真在把 AI 往生产环境里推，而不是停在 demo。正因为往前冲，撞到的坑也格外真实：业务状态要被 agent 读写、实时分析不想再为"搬数据"买单、数据管线得自己跑起来、agent 的行为要能被治理。而 Lakebase、//RT、数据 agent 这几样，恰好就是冲着这些坑去的解药。把事务搬上湖、把实时分析拉回湖里（官方数字 10ms、12000 QPS）、把管线自动化，再到把治理从"谁能看这份数据"推到"一个 agent 这一次被允许做什么"——我对着用户真实的痛点一条条看下来，方向上挑不出毛病。它是真懂了 agent 的危险到底在哪。

所以这篇不是要唱反调。恰恰相反，Databricks 证明的，是大家看到的其实是同一个未来：数据库正在从"存储和查询"，慢慢长成"事实、状态、语义、治理和行动"的统一底座。

但有一块大陆，它还没画完

方向对，不等于到顶。我想诚实地说三个我觉得还不够的地方。但先讲清楚：这些不是说它做错了，而是它的路径里，带着历史。

第一，是聪明的入口，但不一定是终局。 选 Postgres 做底座很聪明：开发者熟、迁移阻力低。但"让人愿意用"和"架构最终该长成什么样"，是两件事。AI 时代的事务、memory、向量、多模态，如果永远靠在一个传统关系库外面缝缝补补——这就是我打问号的地方。

还有一层更结构性的担心。Postgres从来就不是云原生架构，也不是 agent 原生的——它既没有原生的分布式和横向扩展，也没有 agent 真正需要的那套东西：瞬时 branching、agent 级的多租户、memory、trace；这些和分布式一样，都得在外面硬接。把它搬到对象存储上，并不会让这些问题消失。对象存储便宜、可靠，但它慢：要把这个延迟藏起来，你需要一层又快又稳的缓存，而一层在真实事务负载下还能保持正确和稳定的缓存，是这行里真正难啃的问题之一。所以我看 Lakebase，最老实的疑问不是它在分析上 demo 得好不好，而是它能不能在生产里、在规模上，扛住一个真正的 OLTP 负载——而不是让那层缓存，变成半夜三点把人叫醒的那个东西。这一点，我还是怀疑的。

第二，多模态还没真正进版图。 它那张很漂亮的地图，OLTP、数仓、实时分析、数据科学都插上了旗。但 AI 应用真正吃进去的，是文本、图片、音频、视频、embedding、行为日志、agent trace——这些在图上，还是一块没上色的空白。

第三，也是我感受最深的：它产品的默认用户，还是人，不是 agent。 dashboard、自然语言问数、Excel，都是给人用的。可 agent 用数据库的方式完全不一样——它在一个循环里高频地取上下文、做决策、调工具、把结果写回去，而且每一步都得能被审计。

Governance—— Databricks Data + AI Summit 2026。当数据库的用户是 agent，画面就长这样：每一次 prompt、工具调用、命中的策略，都被记录、打上时间戳、被盯着——这里是一串实时刷新的 PII 事件（在 LLM 端点里被拦下）。当 agent 成了负载本身，"可审计"就不再是事后再补的一个功能。

这件事我想了很久，最后落到一句话上：过去数据库回答的是"这条 SQL 怎么跑得更快"；以后它要回答的是"一个 agent 在做决策时，怎么拿到最新、最可信、最便宜、可审计的上下文"。这是两道不一样的题。而且，还不只是"上下文"——更深一层，数据系统本身要从一个"情报系统"（你来问，它给你答案）进化成一个"操作系统"（agent 在它上面取数据、做决策、调工具、写回状态，跑完整个循环）。

那么，"AI 原生"到底是什么意思

老实讲，这个问题我也还在摸索，没有标准答案。但如果真从agent 的负载倒推，我觉得它至少得做到这六件事。（其中有几条，是我和一些在一线做东西的朋友聊出来的。）

多模态原生文本、图片、音频、视频、embedding、日志、trace 是同一种东西，活在同一个系统里——不是一个关系内核外面挂一个向量列、旁边再放一个对象桶。融合要发生在查询里，而不是靠管线在系统之间缝。

弹性，按负载定价先从 agent 真实的样子出发：突发、不可预测——这一秒安静，下一秒就开始猛敲。数据湖——对象存储——是基石：便宜、近乎无限、和算力解耦。规则很简单：不搜，就不花钱；闲下来就缩到零。 存储是个零头，你为查询付费，不为整个语料付费。

agent 级别的多租户租户的单位，已经不是几千万个人类用户——而是几亿、甚至几十亿个 agent，每个都带着自己那一小块、短命、隔离的状态。一个假设只有几千个大租户的设计，扛不住几亿个又小又不停翻搅的租户。

快速回滚与 branchingagent 一定会写错东西。所以版本能力不是锦上添花——你需要 git 式的分支和数据的瞬时回滚：给每一次 agent run fork 一个分支，用完就扔；或者几秒内把整个库回到一个已知良好的点。

完整的 trace 与可确定性回放agent 总会干蠢事——而且一定会——这时第一个问题永远是"它当时到底看到了什么？"这意味着要记下每一次检索、rerank、工具调用和写入，并且能把决策那一刻的上下文一模一样地回放出来。对 agent 来说，可审计和可调试，其实是同一件事。

细粒度的权限——管的是"行动"，不只是"行" 授权要从"谁能读这张表"，扩到"这个 agent 在这一步，能取什么、能调什么、能写什么——以及为此能花多少钱"。难题搬到了写路径上，搬到了运行时，在行动发生的那一刻去强制执行。

还有一个由"agent 级多租户"自然推出的结论：运维必须是自动驾驶的。 在几亿租户的尺度上，没有人能去照看任何东西——建索引、compaction、故障恢复都得自动完成，否则这个规模就是空谈。

弹性，是从负载倒推出来的：突发的 agent 流量、能缩到零的算力、作为基石的数据湖

还有一件事——关于交互界面本身

我越来越觉得，SQL 正在悄悄变成一个陷阱。它在分析师时代是完全正确的界面，但对 Databricks、Snowflake 这样的公司，它正在固化成一种路径依赖——整套产品形态、整个用户群，都是围着"会写查询的人"建起来的。终局不是一个更好用的 SQL 编辑器，也不是在它前面贴一个聊天机器人。终局是一个headless、自然语言原生的数据库：你用大白话说出你要什么，系统直接回答你。这才是真正把受众从几千个分析师，扩到整栋楼里每一个人的东西。

但有一点我要把旗子插在这儿：这不应该是又一个站在数据库前面的 agent。自然语言必须是数据库自己的原生界面——是引擎的一部分，而不是架在上面的一个 app。你一旦把它做成一个独立的 agent，就又悄悄把你本想去掉的那道缝塞了回来：一次翻译、一个过期窗口、一个治理缺口。数据库应该自己听懂这个问题。

这些东西单拎出来，没一个是新鲜词。难的是把它们做成一个系统，而且在真实负载下长期不塌。能 demo，和能在生产里长期跑，始终是两件事——这话对 Databricks，对我们，对所有人，都一样。

最后，几句我也没那么确定的话

我没有一个干净的结论——那就用我最确定的那件事收尾吧。在一个跑得这么快的时代，很多旧的护城河正在以超出预期的速度排空：一种私有的查询方言、过去用来锁住客户的迁移成本、一套你的分析师从小用到大的 UI，甚至"我手里攥着数据"这个安静的优势。开放表格式、自然语言界面，还有那些眼睛都不眨就换工具的 agent，正在把这些一点点溶解掉。

剩下的——我还真正相信的唯一一条护城河——是那种不性感、近乎执拗的本事：疯狂地、长期地为用户创造价值。 而这一点，远比这周发布的任何一个产品都更让我觉得：Databricks 真有机会，成为数据领域里下一家万亿美元公司。不是因为它发得最多，而是因为它一次次走回那个对的问题。

The Known Data Realm· Databricks Data + AI Summit 2026 现场。它画出了一张很大的版图，画得很好。但你顺着看到右下角会发现——那片海，还在等人插旗。

一张画完的地图，并不意味着旅程的结束。往长了看，事情大概没那么复杂：便宜赢过昂贵，可靠赢过不可靠，谨慎赢过粗心，耐心赢过急躁。

AI 时代的数据库，还远没到终局——而对今天每一个走在这条路上的人来说，这是最好的消息。

James Luan · 写于 Databricks Data + AI Summit 2026 之后

参考：Databricks 官方 keynote 与发布 · theCUBE Research · Bessemer “Data 3.0”