AGI 早就来了，缺的从来不是智商：Databricks 数据与 AI 峰会主题演讲全程拆解

一场近三小时、十余位讲者轮番上阵的开幕主题演讲，信息密度极高。本文按演讲原始脉络，把所有重磅发布、产品演示和客户故事完整梳理一遍——从"AGI 是否已经到来"的灵魂拷问，到 Genie 本体论、Raiden 引擎、Lakebase、LTAP 这一连串"王炸"，再到 Greg Brockman 的炉边对话。看完这一篇，你就不用再翻三个小时的回放了。

开场：史上最大规模的数据与 AI 峰会

Databricks 联合创始人兼 CEO Ali Ghodsi一上台就抛出几个数字：本届峰会报名人数刚刚突破 10 万（几天前还只有 9.7 万），覆盖 174 个国家，线下到场 31,309 人，是全球规模最大的数据与 AI 大会。

他特意强调，这场大会的根，始终是开源社区。它的前身是 2013 年的 Spark Summit——如今 Spark 每年下载量已超过 30 亿次。这些年陆续开源的项目还包括 Delta Lake、Iceberg、MLflow、Unity Catalog，而最近 Databricks 全面拥抱了 Postgres：公司贡献了该项目约七分之一的 governor 和超过 6% 的 committer。Ali 直言："我们认为 Postgres 就是数据库的未来。"

此外，联合创始人 Matei在周末刚刚开源了一个叫 Omnigent的项目——一个"元 harness（harness of harnesses）"，后文会再提到。

本届大会的嘉宾阵容也相当豪华：OpenAI 联合创始人 Greg Brockman、Satya Nadella，以及 Anthropic、Cognition、Glean、Decagon、Agno、LlamaIndex、Crew AI 等一众 AI 公司的创始人与 CEO。

三个"让 AI 真正改变世界"的客户故事

在进入产品之前，Ali 先讲了三个他认为"鼓舞人心"的客户案例：

• • Insulet（Omnipod）：一款帮助糖尿病患者的产品，内置血糖监测，结合数据与 AI 个性化地释放胰岛素，帮助患者管理血糖。
• • Tonal：挂在墙上的家庭健身设备。它每年采集约 1000 亿秒的训练数据，为每个用户生成个性化训练与饮食建议，相当于一位私人教练。
• • Merck（TEDDY）：Merck 训练了一个基于 Transformer 的模型，名为 TEDDY（Transformer Enabled Drug Discovery）。它不是预测下一个词，而是预测基因调控网络——判断哪些基因对疾病具有因果关系，从而大幅加速新药研发。该模型在 Databricks 上、由 Databricks 研究团队协助训练，使用了超过 1 亿个细胞的数据。

灵魂拷问：AGI 到底来了没有？

Ali 现场做了个小调查："你认为 AGI 已经到来的，请举手。"结果只有约 5% 举手，90%–95% 的人认为还没到。

接着他亮出一道题：计算分类空间 BG₂ 的约化 12 维 spin 配边类。全场几乎没人会，但他指出——今天所有的前沿智能体都能轻松解出。这道题来自 Humanity's Last Exam（人类的最后考试）基准，全套有 2500 道各类高难题目，而当下的前沿模型已经能解出其中大约一半。

由此 Ali 抛出他的核心观点：AGI 其实早就来了。他甚至回去问了 2009 年和他一起在 UC Berkeley AMP Lab（当年最大的 AI 实验室、Spark 的发源地）的同事们："按我们当年对 AGI 的定义，现在算达到了吗？"答案都是："当然早就超过了。"只不过——目标的门柱（goalposts）一直在往后移。

关键判断：AI 没有"智能"问题，它有的是"上下文"问题。

也就是说，模型已经足够聪明，我们不需要它更聪明。真正的难题在于：AGI 还没有真正渗透进我们的组织。大多数人只是在用聊天机器人问问题、用编程工具写代码，而不是真正拥有几百个能自主工作、互相协作、谈判、提案的智能体。

那么瓶颈在哪？答案是：如何把组织里的全部数据、流程、以及你脑子里的知识，作为上下文喂给 AI。一旦做到这一点，模型就能解决企业里绝大多数任务——这些任务其实不是什么 12 维配边类，而是"从 Salesforce 里取数据、汇总、放到另一个地方"这类事。

横在面前的四道难关

Ali 把整场演讲收敛成必须同时解决的四个问题：

1. 1. 上下文（Context）：怎么把企业各处的数据接进来，做成 "AI-ready" 的形态？这比想象中难得多。
2. 2. 控制（Control）：不能直接把智能体放出去乱跑。他举例：某开源智能体框架发布时，其中超过 10% 的 skill 竟然是恶意的。必须有安全、审计、护栏、身份管理。
3. 3. 成本（Cost）：智能体一旦 24 小时 live 循环地翻数据，成本会失控。Uber CEO 说过，他们一个季度就烧光了全年 AI 预算。成本跑赢营收，公司就会破产或直接关停。
4. 4. 选择 / 不锁定（Choice）：这是最难、也最重要的一条。90% 以上到场企业都有数十年历史，技术栈极其复杂、层层被供应商锁定。我们不希望被任何单一云、单一 SaaS、尤其是单一 AI 模型锁死。

接下来的所有发布，本质上都是在攻这四关。

第一层：让数据为 AI 就绪（Lakeflow）

第一步是把企业各处的数据，搬进一个开放的 Open Lakehouse——跑在任意云之上的开放基础设施。负责这件事的是 Lakeflow。

• • 100+ 连接器：两年前几乎没有连接器，如今已超过 100 个，能接 Salesforce、Workday、NetSuite，也能从 Meta、Google Analytics、各类文档语料里抽数据。
• • ZeroBus（已 GA）：顾名思义，"不再需要消息总线"。无需 Apache Kafka，直接调用 ZeroBus 的 API 灌数据，无论是突发流量还是细碎小行，它都能可靠落入 Open Lake。后续还升级为 100% 兼容 Kafka 协议，吞吐可达 12 GB/秒——把 Kafka producer 的代码指过来即可，落地即开放格式、随取随用，没有数百万小文件的烦恼。
• • Spark Real-Time Mode（RTM）：去年发布的开源框架，让流处理延迟下探到几十毫秒。过去做低延迟流式只能选 Apache Flink，现在很多负载可以直接在开源 Spark 里用 RTM 跑。
• • Lakeflow Designer（已 GA）：可视化、无代码的数据准备工具，体验类似 Alteryx，但由 Genie驱动——你用自然语言说"把这两张表 join 起来"，它就把转换可视化出来，你审核通过即可。底层全是开源 Spark，可查看代码、版本控制、上生产。

Iceberg 还是 Delta？答案是：你不该关心

Ali 请上了 Apache Iceberg 的原始创造者 Ryan Blue（去年被收购的 Tabular 的联合创始人兼 CEO）。Ryan 多年前一场演讲的标题是"你为什么不该关心 Apache Iceberg"，Ali 当场表示赞同——而且 Delta Lake 你也不该关心。没人应该为"格式"操心，应该用合适的工具处理你的全部数据。

进展上：

• • Iceberg V3已 GA，是统一数据层——在 Delta 与 Iceberg 之间共享数据时，不再需要重写任何数据文件，磁盘上的数据布局是一模一样的。
• • 接下来的 Delta 5 + Iceberg V4会带来统一元数据层，目标在今年 Q4 完成规范，届时离"完全统一"只差最后一点元数据。

结论：用 Databricks 时，数据是 Delta 还是 Iceberg，已经不重要了。

Lakehouse 数仓 + 全球最快引擎 Raiden

Databricks 五年前提出的 Lakehouse，主张"最好的数仓就是 Lakehouse"——开放、自己掌控数据、又能跑机器学习负载。过去一年的进展：

• • 新增 110+项传统数仓特性，便于迁移。
• • 大量 SQL AI 函数：直接在 SQL 里调用，做情感分析、实体抽取（如从单元格里提取公司名）、数值预测，且可大规模执行——这是 Lakehouse 上最受欢迎的用法。
• • Lakebridge：自动转换器，把本地或其它云上的现有数仓迁移过来。
• • 过去一年数仓消费量翻倍以上。

更重磅的是新引擎 Raiden（由联合创始人 Reynold Xin介绍）：Databricks 见过的最快引擎，延迟下探到几十毫秒。

Reynold 揭秘：用机器学习"反向"造数据库

Reynold 称 Raiden 是"自 Lakehouse 以来最大的单项创新"。背景是：传统数仓/Lakehouse 大约会在 1 秒处撞墙——并非完全做不到亚秒，而是难以在毫秒级 SLA 下保证稳定不抖动。于是很多企业被迫单独搭一套 serving 栈、复制数据进去，带来运维、性能、治理三重痛苦。图灵奖得主、Postgres 之父 Michael Stonebraker曾有论文《One Size Fits All: An Idea Whose Time Has Come and Gone》，论证"单一引擎通吃所有负载"极难。

彩蛋：Reynold 始终不肯说 Raiden 是什么缩写。Ali 后来"补刀"爆料——它代表 Reynold's Dream Engine。据说团队故意用联合创始人的名字命名项目，因为"以创始人命名的项目，公司就不舍得砍掉了"。

Raiden 的现场实测

• • 一条纽约出租车数据集查询：Lakehouse 约 1 秒；Raiden（即 Lakehouse RT）只要 0.007 秒。
• • 模拟 1000 个并发会话、每个会话约 8 条查询同时打过来：共执行 8000 条查询、6000 QPS，尾延迟仅 37 毫秒。
• • 在延迟 vs. 吞吐基准（TPC-H Q6）上：某竞品最新数仓约 160 QPS 撞墙；其"交互式数仓"（需复制数据到独立仓）约 300 QPS；某著名开源引擎能冲到约 1.5 万 QPS 但随后直接崩溃；Raiden 一路冲到 1.2 万 QPS，尾延迟仍在 1 秒以内。
• • 完整 TPC-H：数据量放大后，交互式数仓因"无法跑超过 5 秒的查询"而无法完成，开源引擎 OOM 崩溃，Raiden 在所有规模因子下全部跑完。
• • 设计合作伙伴实测：能源行业平台 Enverse取得平均 16 倍加速、最长查询缩短近 100 倍；Meta也测得典型查询回到几十毫秒，且无需单独的 serving 系统。

首个落地产品是 Lakehouse RT（RT = Real-Time）：从只读负载起步，提供毫秒级性能与海量并发，直接在数据湖上、由 Unity Catalog 治理、跑同一份 Delta/Iceberg 数据，且定价基本与现有数仓持平，今日起开放 beta。

Lakebase：跑在湖上的 Postgres，且是任务关键级

镜头转向 OLTP 一侧，上台的是 Nikita Shamgunov（曾任 MemSQL / SingleStore CEO，以及被 Databricks 收购的 Neon 的 CEO）。

他的判断很直接：未来一年人类生成的软件量将超过历史总和，而每个应用都需要数据库。下一代应用与智能体对数据库的要求是：

• • 熟悉（Familiar）：开源、流行、可扩展。智能体扫遍了 Stack Overflow、Reddit，越熟悉就越会用——所以选 Postgres，世界上最先进的开源数据库，生态与扩展最丰富。
• • 灵活（Nimble）：serverless、可分支（branchable），方便为智能体快速开出安全的实验环境，且成本可控。
• • 任务关键（Mission Critical）：无限可扩展、快、极其可靠。

但 Postgres 是个存算紧耦合的单体。Databricks 的做法是存算分离、把存储下沉到湖，并为此从零重构存储：

• • 写入与事务一致性 → 引入 safekeepers，实现 Paxos 共识协议，提供低延迟写；
• • 读取 → 引入 page servers，向 Postgres 计算层提供页，实现低延迟读。

这就构成了 Lakebase——跑在湖上的全托管 serverless Postgres：

• • 500 毫秒内开出一个 Postgres，可缩容到零（不用就不花钱，只付便宜的湖存储）；
• • Branching：约 500 毫秒克隆一个数据库，copy-on-write，不真复制数据；
• • Snapshot / Restore：快照后放手让智能体改 schema、改数据，满意就继续、不满意一键回滚；
• • 计算自动按峰谷伸缩（只需设上下限），存储在湖上、无限扩展；
• • 性能：每事务 10 毫秒以内，可达 60 万+ ops/秒（对比某云厂商约 13 万、另一家约 35 万后延迟飙升）；
• • 首个全托管跨云容灾：例如主库在 AWS US-West、副本在 Azure US-East，AWS 宕机时可瞬时切换、业务不中断。

上线一年已有 3500+ 企业客户。

客户故事：MasterCard

MasterCard 的 Federica Cohen上台分享：他们运营覆盖 200+ 国家、数十亿持卡人、每年处理 1500 亿+笔交易，目标是让数据与服务贡献过半营收，并把 80 项服务整合到一个 agentic 平台上。

• • 基于 Lakebase + Unity Catalog 构建可复用架构，打造"虚拟 C-suite"——3 月发布、面向小企业的高管级决策助手，首个上线的是虚拟 CFO（现金流、支付、营运资金决策）。
• • 共享底座让"一个智能体产出的洞察，下一个智能体立刻可用"。
• • 即将推出的 Performance Pulse需支撑数千家发卡行共享平台，多租户隔离是高风险挑战；Lakebase 让数据隔离、数据驻留与安全合规从一开始就内建。
• • 一个让 Nikita "惊掉下巴"的数据：从概念到可规模化的 MVP，仅用 7 周——而 MasterCard 的监管门槛极高。秘诀是把治理与护栏从第一天就建进架构，"不是靠走捷径加速，而是靠一开始就把地基打好、之后可反复复用"。

控制与治理：Unity Catalog 与全新的 Unity AI Gateway

智能体不能放出去乱跑，于是有了多年前启动的 Unity Catalog。它的两个理念：

1. 1. 不止管结构化数据——而是管组织里所有数据与 AI 资产：非结构化文件、PDF、AI 模型，以及这些年新增的 50+ 种资产类型；
2. 2. 不止做访问控制——还要做发现与数据民主化、血缘追踪、成本控制、数据质量。

Unity Catalog 始终免费，且早已开源，最近还在加速开源更多组件。

在共享方面，Databricks 多年前开源了 Delta Sharing；今年进一步推出其超集 Open Sharing——不仅能分享 Delta，也能分享 Iceberg（如今两者同格式），更能分享 AI 资产（智能体、skill、模型），还支持本地部署。

治理新痛点，催生 Unity AI Gateway

过去一年，组织里的智能体、MCP server、skill 文件、各家前沿模型版本、编程工具、co-work 智能体迅速堆积成一团乱麻，带来三大问题：

1. 1. 成本失控——花费暴涨、毫无可见性，不知是谁的智能体、用了哪个模型；
2. 2. 行为不可控——无法保证智能体访问合规数据、无法审计、缺乏输入输出护栏与身份管理；
3. 3. 被锁定——前沿模型的"保鲜期"只有约一个月。Ali 调侃道：去年 11 月 Gemini 出来是最强；今年初 Opus 最强；接着 GPT-5.5 最强；上周 Mythos / Fable 发布、大家都准备切过去，结果又被取消、然后又恢复……来回横跳。所以必须保留随时切换、自由选择的灵活性。

为此，作为 Unity Catalog 的一部分，Databricks 发布了 Unity AI Gateway——一个统一管控所有智能体与 AI 支出的单一控制台：

• • 所有智能体、所有 AI、任意 harness 的统一入口（同样开源、不收费，且 AI Gateway 本身属于 MLflow）；
• • 直接提供前沿模型的 token 额度——你承诺给 Databricks 的预算，可直接用于 OpenAI、Anthropic、Gemini 的模型，且在 AWS / Azure / GCP 任意云上都能用；
• • 全量可观测性与仪表盘，可按组、子组直至个人设预算、设限流，超额即告警或熔断；
• • 统一的安全、合规、审计与身份管理，覆盖 harness、模型、智能体；
• • 可管理任意厂商的 MCP（注册即追踪），且一次认证、全部打通，无需反复授权。

至此，"控制"与"成本"两关基本攻下。

上下文层：Genie Ontology（本体论）——本场最重磅

回到核心命题：AI 不缺智商，缺上下文。今天的智能体是怎么取上下文的？它们在一张巨大的企业文档/资产图上做 live 随机游走：你问"过去两周欧洲的产品营收"，它打开一个文档、发现一个链接、再开一个 MCP server、再读一个文档……如此 live 循环。这带来三大问题：

• • 慢：简单问题也可能跑 10–15 分钟；
• • 贵：让它"重命名个文件"都要花 10 分钟、收 5 美元；
• • 质量差（最致命）：企业资产海量，它只能随机走一小部分子集，准确率堪忧。

为此 Databricks 发布了 Genie Ontology（Genie 本体论）：

• • 它在后台（而非你提问时）连接组织里的全部数据，预先构建一张"最重要知识"的图谱，随时可作为上下文喂给任意智能体；
• • 不止接 Lakehouse / Databricks，还能接 Google Drive、SharePoint、邮件、Google 日历等；
• • 研究团队为此开发了名为 OntoRank的算法——类似当年 Google 的 PageRank，但更难：要处理不同资产类型（源代码 ≠ Google Doc）、还要纳入组织里的人（org chart、谁多频繁访问什么），据此构建本体图谱；
• • 你也可以带上自己的语义：通过 Unity Catalog Semantics引入 Atlan、AtScale、现有 BI 工具或业务术语表，让人工策展与自动构建协同工作。Databricks 自家实例已收集构建了 450 万+条本体片段——这是任何 live 智能体都不可能逐条翻完的。

实测对比（Ken Wong 演示）

Ken 用同一个 prompt（为产品咨询委员会做一份完整客户画像，需打通邮件、Slack、日历、Salesforce、Databricks 消费数据）对比了 5 款主流智能体：

• • 第一款 AI 助手回答极快——快得可疑，声称委员会有"24 个客户"，追问之下竟承认是编的（凭空捏造）；
• • 第二款会搜文档、但拉来的都是一个季度前的陈旧资料；
• • 编程/co-work 类智能体确实认真去连系统拉实时数据，但撞上时间限制、请求继续烧 token、反复迭代，30 分钟后只给出半份报告。

这与 Databricks 研究团队的基准一致：用员工真实问过 Genie 的刁钻问题去考编程智能体，最强的也只有约 50%正确率、且耗时数分钟——对真实数据问题而言基本不可用（等于抛硬币）。

而接入本体论的 Genie表现如何？内部测试显示准确率持续提升 30+ 个百分点、运行时间约为领先智能体的一半，团队相信随着 OntoRank 调优和本体广度扩大还能继续大幅提高。关键在于：Genie 不是在"复述已有文档"，而是基于实时运营数据真正计算出结果，并自动应用底层数据源的权限、做到不泄露。

Genie 智能体家族：让 AI 成为"懂数据的同事"

Genie 1（今日 GA）

Genie 1是一个"懂数据的 AI 同事"，连接你全部数据与应用，让组织里每个人都能拿到洞察、甚至自动执行动作——它和此前用了三年的 Genie 不是一回事：老 Genie 局限于某个领域空间，而 Genie 1 是全组织统一入口，业务用户登录即用，拿不到底层数仓与基础设施（也就不会乱花钱）。

产品经理 Elise Joris现场演示了用 Genie 1 准备一次 OKR 评审：

• • 给它一个模板链接，它自动从 Unity Catalog 术语表里找到相关本体片段（且严格沿用你已有的Unity Catalog 权限）；
• • 抓取 Google 文件、用 MCP 给 Jira 工单留言催进度；
• • 跨 Databricks 与 BigQuery 跑 SQL 取实时真值（而非复述旧文档），按区域拆分指标、给出可视化、亮点/低点/异常；
• • 引用区可查看一切来源（表、外部 catalog、工单、文档、术语表定义），可点进本体片段核实推断（如"engagement 定义为时长超 30 秒的会话"，来自同事 Chung 的移动端 KPI 看板，并带有权威度评分）；
• • 可一键排程每周自动跑、用同事的预测 skill 加预测、通过邮件与 Slack 一键分发；
• • 还能把这段对话变成一个智能体分享给团队；它会随数据保持最新，并能在手机端主动推送（"App 互动量正在飙升"），无需你预先设置——因为 Genie 从你的行为里知道你关心什么。

Ken 回到台上总结 Genie 1 的能力：创建文档（实时计算而非复述）、连接所有系统（含自定义 MCP，统一经 Unity AI Gateway 管理）、后台排程（无需开着电脑）、自定义并共享 skill、一键造领域专属智能体。客户实证：Warner Music Group（同时用于 Databricks 与非 Databricks 数据）、General Motors（把数百个 Genie 智能体投入生产）、Foot Locker（让每位员工都能用数据做决策）。

可用性：今日 GA，集成进 Teams 与 Slack，并上线 iOS / Android；推出 Genie MCP app，让你现有的智能体也能接入 Genie 的精准计算能力；并且每位用户每月赠送价值 10 美元的 token。

Genie Code

面向数据工程与机器学习/数据科学的编程智能体——擅长写管道、做数据工程，也擅长建模、上 GPU 训练、验证模型精度。一个惊人数据：上线仅三个月，60% 的 Lakeflow 管道已由 Genie Code 编写。

Genie Agents

把任意对话变成可分享、可投产的智能体——例如喂给它全部 HR 文档造一个 HR 问答智能体，放进 Slack/Teams；它也能自主工作：每天从 Salesforce 取数、整理后放进 Workday、发报告、与其它智能体协作。

Genie Zero Ops（由 Bilal Aslam 演示）

Bilal 先讲了数据工程的残酷现实：管道架构复杂、版本控制与治理难以全覆盖；团队 50%+ 时间花在运维，每月仍可能有多达 60 小时停机。而数据工程不同于软件工程——失败是静默且永久的，往往一周后才被 CEO 一个愤怒电话发现。要让运维智能体真正干活，它既要读、又要写生产数据来验证修复——没人敢把这种权限交给一个不信任的智能体。

关键洞察：运维智能体必须活在数据平面（data plane）之内——那里有数据、有血缘、也是正确的治理边界。于是有了 Genie Zero Ops，一个把数据与 AI 运维放上自动驾驶的后台 Genie：

• • 检测：为每张表自动训练并持续微调机器学习模型（已有数万个在生产中），原生访问指标/事件/日志；
• • 评估影响：在 Unity Catalog 血缘上做图排序，前后游走判断哪些表/管道重要；
• • 定位根因：一个 supervisor 智能体 + 一队 sub-agent 调研后达成共识；
• • 修复：与 Genie Code 协作，可顺带更新工单；
• • 验证（最难一步）：基于开放 Lakehouse 十年积累，建生产数据的 shallow clone（类似 Lakebase 分支，便宜又快），在隔离环境里验证修复，默认不直接上生产，人在回路。

Genie App Builder

让你用"vibe coding"造自己的数据 / AI 应用（也可用 Lovable、Replit、Vercel 等合作伙伴）。

PepsiCo 客户故事

PepsiCo 全球首席数据与 AI 官 Magesh Bhagavathi（与联合创始人 Arsalan Tavakoli 对谈）：32 万员工、覆盖约 200 国家、每天约 14 亿次 occasion（消费场景）、通过 600 万零售商服务。六年来从 60+ 个数据湖整合到一个跑在 Databricks 上的 Lakehouse，90% 的数据已上平台（称为"企业数据基础"）。

• • 此前做 AI4BI（与数据对话）从 vectorize、RAG 到投产要 3–6 个月，且精度不达标；如今数据约 95% 准确、Genie 让取数即时；
• • 采购场景 Spendwise（$950 亿营收公司的直接/间接支出洞察）上线 Genie 后，头几周就有约 3 万次查询，用户从看报表迅速转向与 Genie 对话；
• • 目标是把 3 万+ 报表收敛成 50+ 个 Genie 控制台，从"洞察→行动→结果"，实现"agentic PepsiCo"、为 32 万员工赋能。

给开发者的 Agent Bricks + 元 harness Omnigent

面向要做底层编程、用各种 harness（Claude Code、Codex、OpenCode 等）的开发者，Databricks 扩展了 Agent Bricks开发平台：

• • 沙箱：让智能体在快速启动、相互隔离的沙箱里运行；
• • 智能体记忆（agent memory）；
• • Omnigent：Matei 周末开源的"元 harness（harness of harnesses）"——能调度并让现有 harness 相互对抗（比如让 Claude Code 与 Codex 较劲），取得比单一 harness 更好的结果。Matei 次日会专门做主题演讲。

软件的未来：Agentic System of Record

Ali 进而抛出一个更宏大的判断。过去二三十年的 SaaS 栈长这样：一个记录系统（数据库/黄金记录）+ 一些可定制但僵硬的工作流 + 一个没人真喜欢、但学会了就不想换的 UI；每个领域（销售、运营、财务）都各有一套。

这两年的变化是：每家 SaaS 厂商都给你配了自家的智能体，说"用我的智能体访问我的数据"。问题是——你的问题从来不会只局限在一个记录系统里，跨系统就立刻变得一团糟，而厂商们彼此竞争、并不愿意好好协作。

那么未来的软件栈/Agentic System of Record 该长什么样？Databricks 认为大概是这样：智能体直接、快速、低成本、安全地访问一个统一的 agentic system of record——底层是一份开放格式的全量数据+ 统一治理与成本控制+ 跨系统的企业上下文。换言之——未来的"记录系统"，就是今天讲的数据与 AI 平台（无论是 Databricks 还是别家，这会是未来的结构）。在此之上是 agentic apps：Databricks Apps是把数据与 AI 民主化到几十万人的方式，也是增长最快的产品，并新增了可交易、可付费购买的应用市场。

Databricks 亲自下场做的两个应用

有些应用数据密集、是 Databricks 的强项，于是它选择自建：

Lakewatch：agentic SIEM（"安全 Lakehouse"）

两个月前发布的 agentic SIEM。传统 SIEM 把数据灌进专有系统极其昂贵，逼得大家在入库前先过滤掉大部分数据——但在自动化智能体发起的大规模攻击面前这行不通（Ali 提到：过去半年 HackerOne 榜首的"黑客"是一个叫 Xbow的 agentic 系统，人们正用 Mythos 之类的模型挖漏洞）。所以应当把全部安全数据廉价地存进开放、安全的 Lakehouse，再在其上跑 Lakewatch 智能体：自动生成检测规则、自动 triage 告警（类似 Zero Ops，但面向 SOC 安全运营中心）、自动威胁狩猎（发现零日攻击即自动加管道处置）。

同时宣布：Databricks 将收购 Panther Labs——一个超前时代、基于 Python的 SIEM（创始人 Jack Naglieri出身 Airbnb SOC 分析师，五年前就坚持"一切应 Pythonic"，恰好契合"今天所有 AI 都想说 Python"）。Panther 带来数百个连接器与 Python 化检测，客户包括 Anthropic、Coinbase、Plaid。

Customer Lake：agentic CDP（Customer 360）

构建在 Lakehouse 上的 agentic 客户数据平台，两个特别的智能体：

• • Profile Agent：用 LLM 自动做身份去重/合并，更精准；
• • Campaign Agent：实现名为 Infinity Campaigns（无限营销）的新概念——过去是把人群切成 ~100 个受众分别营销，现在用便宜的小型蒸馏 LLM 做一对一、持续的个性化触达。

由 Tasso 在后续专场详解。

"已知数据领域"地图 + LakeHouse RT + LTAP

Ali 用一张"数据世界地图"（戏称数据基础设施版《权力的游戏》）来串起全部引擎：

• • 西侧——OLTP 岛：诞生于 80 年代，要求毫秒级、永不宕机、事务可靠（如 ATM 取款），后来还衍生出 KV 存储、向量检索；
• • 右侧——数据仓库：80 年代后出现，回答"所有 ATM 一共交易了多少钱"这类分析问题，必须与 OLTP 隔离、不能拖垮线上；
• • 再往后是 数据科学（预测未来）与 实时分析（低延迟、给智能体/应用/看板）。

要把数据从左侧 OLTP 搬到右侧 OLAP，就催生了复杂、脆弱的数据工程（Bilal 解决的就是这部分）。而如今"智能体大军压境"，数据搬运量暴增，脆弱的基础设施会被风暴掀翻。

Databricks 的统一之路：

1. 1. 当年用 Spark 统一了数据工程 + 数据科学；
2. 2. 五年前用 Lakehouse在一个引擎里统一了数仓 + 数据工程 + 数据科学；
3. 3. 如今用 Raiden / Lakehouse RT把实时分析这座孤岛并入——同格式、同 Unity Catalog 治理，低延迟与大数据处理共用一套底层。

最后一关：LTAP——"做对了的 HTAP"（Reynold 再次登场）

还剩一个大问题：OLTP 与 OLAP 之间仍要靠 CDC 管道搬数据。CDC（Change Data Capture）读 OLTP 的 binlog、把增量搬到分析系统重建状态——极其脆弱，工程师常凌晨 3 点被数据损坏叫醒，以至于内部调侃 CDC = Continuous Data Corruption（持续数据损坏）。所谓 Zero-CDC、Zero-ETL、mirroring 也只是把管道藏起来，底层仍是管道、同样的毛病。而数据库圣杯 HTAP（一个引擎同时通吃事务与分析）作为品类基本失败了：要么专有、生态小，要么两头性能都妥协。

由此，OLTP 数据可直接以列存（Delta/Iceberg）写入湖，分析计算就能直接打在上面。Databricks 给这套存储技术起名 LTAP（Lake Transactional Analytical Processing）：

LTAP 是"做对了的 HTAP"——不靠单一查询引擎，而是统一存储（最关键的一环），让 OLTP 与分析共用一份数据、一份治理，且两侧性能毫不妥协，全部基于开放格式（Postgres、Delta Lake、Iceberg）。

Databricks 还将开源一个把 Postgres 数据直接转 Parquet 列存的底层库（logo 是只可爱的 Parquet 小象），即将上线。用户要做什么改动？什么都不用做——只要开始用 Lakebase，未来几周 LTAP 能力上线后，每张 Lakebase 表都会自动出现在你的 Lakehouse 里，因为底层根本没有管道要维护。

现场演示（Holly）：三种方式跑同一个查询

场景：横跨美洲的银行每天产生数十亿笔交易，要一个智能体在客户离店前实时识别潜在 VIP 并匹配顾问。三种方式对比：

1. 1. 直接在 Lakebase 计算上跑复杂分析查询：很慢、跑了一分多钟，还拖低了 TPS（绿线下滑），有拖垮生产的风险；
2. 2. 用 CDC 复制一份再查：TPS 平稳、13 秒跑完，但数据陈旧 25 秒（换成第三方 Postgres 或 CDF 工具可能延迟到数分钟，还要额外账单与团队）；
3. 3. LTAP 方式：表已自动出现在 Unity Catalog（图标显示既是 Lakebase 表、又对 Delta/Iceberg reader 可见，甚至能在 S3 路径下用开源 Spark 直接查），用实时数仓查询——毫秒级返回、零陈旧、对 TPS 零影响。可以随便扔多少智能体进来；因为近乎瞬时，计算更便宜，又因没有中间工具、运维也更便宜。

一句话：单一记录系统，既服务运营、又服务分析，无需在性能上二选一。

炉边对话：OpenAI 的 Greg Brockman

联合创始人 Patrick Wendell与 Greg Brockman（OpenAI 总裁兼联合创始人）对谈。要点：

• • 角色：Greg 习惯哪里最关键就去哪里——GPT-4 时期他每晚凌晨 2 点在节点间二分查找救火、搭训练框架；如今最重要的问题是把模型连接到真实世界，所以他花大量时间帮团队聚焦产品化、统一智能体的构建方式。
• • 模型节奏："鸭子划水"——表面光滑、水下拼命。GPT-5.3（2 月）、5.4（3 月）、5.5（4 月）近乎月更，每代都是巨大飞跃。背后是把复杂空间拆成预训练、后训练、推理、安全、定价、打包等多层，并打磨出一个越转越快的内部飞轮。指数曲线不会停——这一点企业制定 AI 战略时应当"提前计价"。Databricks 在自身开发流程接入 5.5 后也看到巨大收益。
• • 数据：数据是模型这块"千层蛋糕"的最底层。把数据清洗干净的回报被严重低估；同时要理解用户怎么用ChatGPT（如上传医疗报告获得本拿不到的洞察）。在 agentic 场景里，单读 trace 已不够，需要用模型本身去分析模型的行为——洞察侧如此，安全侧亦然（如 Codex 的审批已能由 AI 层代劳）。Greg 笑称给 Databricks 的需求永远是"更快、更低延迟、更可靠"。
• • 合作：去年 Databricks 与 OpenAI 达成 1 亿美元合作，让客户能把 GPT 系列与企业数据结合；近半年又在 AI Gateway 支持 Codex、让 Genie 可原生在 Codex 中调用。OpenAI 把自己视为"AI 革命引擎里的一颗火花"，要与生态共建；双方已有数千家共同客户。Greg 力荐大家试用 Codex（且 Codex 本身开源），Patrick 称 Databricks 是早期采用者、生产力提升显著、迭代极快。
• • AGI：Greg 认为 AGI 很"私人化"，几乎是一种感觉而非定义；更恰当的框架是把它看作光谱、而非某个时刻。真正的"AGI 时刻"或许是：你有一个能像顶尖人类那样、自主胜任任何任务的助手。当前是"锯齿状智能"——某些方面极强、某些方面受限。OpenAI 坚持让人类居于中心、由人设定目标与掌控。与其纠结"是不是 AGI"，不如问：我们想让 AI 做什么、如何从中受益。

全场发布一览（收尾速记）

最后 Ali 把当天发布归拢成一张图——核心母题始终是：我们有了聪明的智能体，但它们缺上下文；把平台上的全部上下文喂给它们，就能在组织里产生巨大影响。

• • Agentic 数据基础：
• • Lakehouse RT（Raiden 引擎）——超快、毫秒级；
• • Lakebase——跑在湖上的 serverless Postgres，含跨云容灾；
• • LTAP——统一 OLTP 与分析存储，无需管道；
• • Lakeflow——100+ 连接器、ZeroBus、Real-Time Mode、Lakeflow Designer。
• • 上下文层：
• • Genie Ontology——你的企业上下文图谱（OntoRank）；
• • Unity AI Gateway——模型与智能体的统一控制、成本、治理；Open Sharing——开放共享。
• • Agentic Dework（Genie 智能体）：三大主力 Genie 1 / Genie Code / Genie Agents，外加 Genie Zero Ops与 Genie App Builder。
• • 开发者：Agent Bricks（沙箱、智能体记忆）+ 开源 Omnigent（次日 Matei 专场）。
• • 自建应用：安全的 Lakewatch（agentic SIEM，收购 Panther Labs）+ Customer Lake（agentic CDP / Infinity Campaigns）。

收敛成三句话：

1. 1. 选择：任意数据、任意模型、任意云，不被锁定；
2. 2. 治理 + 成本：一个地方管完所有治理与成本控制；
3. 3. 上下文：把企业上下文交付给你的每一个智能体。

一句话总结这场峰会：模型已经够聪明了，胜负手在于你能不能把"上下文 + 治理 + 成本 + 选择"这四件事一次性做对。而 Databricks 这次给出的答案，是把数据、治理、智能体和应用，统统收进同一个"agentic system of record"里。

（注：本文依据主题演讲现场内容整理。）