Databricks AI战略解析：Omnigents编排平台与LTAP统一存储架构

在最新一期Latent Space播客中，Databricks联合创始人兼CTO Matei Zaharia与核心负责人Reynold Xin，深入阐述了公司在AI时代的两大差异化押注：开源Agent编排平台Omnigents，以及统一存储架构LTAP。

他们的核心判断简洁有力：「一旦你能把数据放到正确的位置，AI模型已经相当好用了。很多传统软件将用这个新范式重写——数据到位，接上Agent，魔法自然发生。」

本文基于该播客内容，梳理Databricks对AI未来的技术判断与工程实践。

Omnigents：Agent时代的「通用协议层」

随着编码Agent爆发式增长，Databricks内部率先遭遇了一批共性痛点。Matei指出，公司内部同时运行着多个Agent产品：基于Claude Code和Codex封装的开发工具Isaac、研究团队打造的数据科学Agent Genie，以及大量面向客户的定制Agent。这些系统全都撞上了同一堵墙——每隔几个月就需要切换模型和运行框架（harness），而缺乏会话共享、历史保存、搜索和协作能力的Agent，几乎等同于残废。

Reymond的亲身遭遇极具画面感：有一周他从早到晚持续写代码，甚至开车去看医生时都把笔记本电脑架在副驾，用手机热点连接，每逢红灯就查看Agent进展。「这感觉像回到了编程的黑暗时代。」正是这种荒谬体验，推动团队构建了可持续运行、秒级启动的云沙箱环境。

Omnigents的本质，是在所有harness之上建立一套统一的通用API。 Matei解释道：「这个API很简单——你有一个Agent会话，可以发送消息或文件，然后接收流式输出的文本或工具调用。」关键价值在于，Databricks将Claude Code、Codex、OpenAI SDK等全部映射到同一接口。这样当某个模型API发生变化时，你无需自行维护适配层，彻底告别消息丢失的噩梦。

Matei将这套架构类比为网络协议：「它让我想起互联网协议，以及参与方之间的通信标准。」在人人都能随手vibe coding的时代，为什么还需要精心设计协议？答案是：当多个以不同速度演进的参与方需要协调时，你依然需要一个稳固的互操作层——Agent之间对话、用户与Agent对话、工具调用，都离不开这样的规范。

安全设计：从二元开关到有状态策略

Matei对Omnigents的安全架构尤为兴奋。传统编码Agent的安全控制过于粗糙——只能设置「允许」或「禁止」某种工具模式。但现实场景充满两难：Agent该不该读取机密文档？该不该从NPM安装一个刚发布一天、可能被污染的新包？该不该直接向公司官网推送内容？

Databricks的解法是**「上下文策略」（contextual policies）**——一种有状态的策略引擎，持续追踪整个会话的行为链路。「关键不是它能不能推送到营销网站，而是——如果它在此之前做了危险的事，比如安装了昨天刚发布的NPM包，或者读取了上千份机密文档，那就不允许；否则可能没问题。」这种动态权衡让系统同时变得更安全、也更好用。

由于策略是有状态的，Token预算也成为可追踪的维度之一。Matei举例说，他曾让Agent调试问题，结果Agent读取了海量日志文件，直接烧掉500美元。现在他可以直接下令：「启动一个子Agent处理这件事，上限5美元，需要更多就来问我。」这种成本控制机制对拥有十万级工程师的大型企业尤为关键——每人每月多花1000美元，规模乘数下后果不堪设想。

Omnigents目前已正式开源。发布后数日内便收到约400个合并请求，其中约一半来自外部社区，涵盖Kubernetes支持、多云沙箱适配，以及Cursor CLI等更多Agent harness的集成。

LTAP：把HTAP的圣杯「做对」

第二个重大押注是Reynold主导的LTAP。理解它，需要先理解数据库世界长达数十年的结构性分裂。

数据库大致分为两大阵营：OLTP（事务型，如Postgres、MySQL、Oracle）面向行级实时操作；OLAP（分析型）面向大规模批量推理。几乎每个应用都从OLTP起步，但一旦数据量增大、分析需求复杂化，就必须将数据从OLTP复制到分析系统——这个过程依赖CDC（变更数据捕获）技术。

Reymond对CDC毫不客气：「它应该被称为持续数据损坏（continuous data corruption）。」一旦OLTP端修改了schema，CDC管道就可能崩溃，无数数据工程师因此被迫凌晨三点起床救火。他甚至提到，Airbyte靠CDC做成了50亿美元的公司，足见其既基础又痛苦。

约十年前，业界曾提出HTAP（混合事务分析处理）——用单一数据库同时处理两种负载。但实践证明这是「两头都不讨好」：新系统无法继承Postgres或Spark各自庞大的生态，性能上也难以与专用系统抗衡。

LTAP是对HTAP的重新诠释，也是Databricks认为「做对了」的版本。 核心洞察是：不要在查询层强行统一，只统一存储层。「你可以获得HTAP圣杯99%的价值，只需统一存储，用单一存储层。」一旦Postgres数据库以列式格式写入数据，所有分析引擎便能直接读取，无需任何管道、零延迟。

一次「没有立项会」的战略突破

这项战略级功能的诞生方式出人意料。Reynold透露，他和CEO Ali花了大量时间在会议上争论「这是否可能」，但从未开过正式立项会，也没写过设计文档。最终，「一个特别聪明的工程师直接说：我来做个原型——成了。」

技术层面，团队发现存储集群有大量闲置CPU，可用于将行式数据（利于OLTP）实时转码为列式数据（利于分析）。转码后数据压缩比更优，写入S3等对象存储反而更快——几乎没有额外开销。

Matei总结了这种创新文化：「如果我只是写了份文档说『我们可以一起做这些』，每个人都会开始追问各种边界情况。但如果你真去试一下，一切就会豁然开朗。」他强调，Databricks虽然规模庞大，依然保持着「不需要征求许可、不走冗长流程、先做出来」的核心文化——通过雇佣顶尖人才、创始人亲自下场、严控产品数量来维持组织敏捷性。

Dream Engine：用机器学习重写数据库引擎

LTAP背后还藏着一个更宏大的愿景——Dream Engine（内部一度戏称为「Reynold's Dream Engine」以免被轻易砍掉）。

Reymond坦言，几乎所有分析型数据库引擎都有十年以上历史，最初为特定窄场景设计，随着野心膨胀不断堆砌「绕过原有抽象的hack」，十年有机演化后「变成一坨巨大的屎——包括Databricks自己」。极少有公司有勇气从头重写。

为规避著名的「第二系统综合症」，团队没有靠拼凑最新学术论文构建新引擎，而是建造了一座「数据库工厂」。这个工厂利用Databricks十年积累的、规模达千万亿（quadrillion）数据点的查询trace，训练出一个机器学习模型，能高保真预测任意算法和实现在任意查询类型上的性能表现。基于此，系统可在运行时和实现时动态选择最优算法与数据结构。

Reymond举了个精妙例子：一个字符串是纯ASCII还是含Unicode，会对性能产生深远影响。如果字符串集合足够稠密（比如只有256个国家代码），就可以用数组查找完全取代哈希表——这类「反直觉」优化，正是模型上百万特征所要捕捉的。Dream Engine将以增量方式推出，新引擎从设计之初就要求全覆盖现有能力并整体更优（尤其是数十毫秒级低延迟负载），而非等待数年一次性交付。

战略底色：开源基因与AI定力

面对「为何在存算分离赛道上超越了Snowflake」的追问，Reynold给出了两个根本差异。

其一是开源基因。「Databricks从未有过专有格式，我们从开放生态起步——从Parquet到Delta再到Iceberg。」他特别提到，Snowflake联合创始人当年曾撰文《Choosing Open Wisely》反对开放数据格式，而如今开放格式已成行业共识。这一趋势对拥有三十年遗留系统、经历过Oracle锁定之痛的大型企业而言，是选择Databricks的决定性因素。

其二是AI定力。 在ChatGPT问世之前，Databricks就一直将自身定位为「机器学习+数据」平台，而非单纯的数据基础设施公司。Matei还澄清了收购Mosaic后的模型策略：Databricks并未追逐通用前沿大模型，而是专注于「如何让聪明的模型真正有用」——比如打造虚拟数据科学家Genie，以及训练专用小模型（如一个文档解析视觉模型，比前沿模型便宜约100倍且效果更优）。

---

两位创始人的判断最终回归那个核心命题：通用Agent的推理能力已经足够好，胜负手在于数据是否就位。「很多传统软件将被这个新范式重写——数据到位，接上Agent，魔法自然显现。但没有正确的数据，你什么都做不了。」

这正是Databricks将安全、客户数据平台等新产品，统一构建在数据底座之上的战略逻辑：不是先有AI，而是先有数据。