数据先到位，再「糊上 AGI」：Databricks 两位掌门拆解 Agent 云与数据库重写

核心要点

• Omnigent 统一接口：核心是一层架在所有 harness 之上的通用 API——发送 message/file，接收流式文本与 tool call，外加 cancel/turn 控制；Claude、Codex、OpenAI SDK 全映射到这一接口，省去自建 orchestrator 在各家改 API 时的维护成本。
• 上线即火爆：Omnigent 周六（6/20 前后）才开源，采访当天 GitHub 已约 400 个 merge，约一半来自团队外贡献者，已有人加上 Kubernetes 运行、多家云 sandbox 支持，并接入 Cursor、CLI、anti-gravity 等更多 harness。
• 有状态安全策略：传统「工具允许/禁止」二选一太僵硬，他们做了 contextual/stateful policy——追踪会话状态，若 agent 刚装了一天大的 NPM 包或读了上千份机密文档，再禁止其发布到外网，兼顾安全与可用，并借收购的 Panther 做实时事件处理。
• 成本可按会话封顶：因为策略有状态，可记录单会话花费；Matei 举例一次 debug 让 agent 烧掉 500 美元，现在可对子 agent 设 5 美元上限、超额弹窗询问；Databricks 内部对工程师 token 不限额，但用自家产品分析 trace 找异常。
• LTAP 即「HTAP 做对」：不在查询层强行合并 OLTP 与分析库，而是只统一存储层——Postgres 以列式格式写入开放数据湖，分析侧可零延迟直读，免去脆弱的 CDC（被戏称 continuous data corruption，常让数据工程师凌晨三点被叫醒）。
• 列式转码的关键一跃：从 lakebase（脱胎自 Neon 的存储计算分离）到 LTAP 只差一步——一位工程师未经立项就把数据湖落盘从 Postgres page 改成 parquet 列式，利用存储集群闲置 CPU 转码，数据反而压得更小、写得更快，零性能损耗。
• 用 ML 模型造数据库：dream engine 团队不照搬论文算法，而是建「工厂」——用十年 trace（号称千万亿级数据点，采样）训练一个机器学习模型（非 LLM），按规模/吞吐/延迟/数据分布/distinct 值等上百万特征，在编译期与运行期为每种 query 分派最优算法与数据结构。

章节时间轴

• 0:00 开场与赞助说明 — 抛出核心论点「数据放对地方，糊上 AGI 就出魔法」，并感谢订阅、坚持无广告模式。
• 1:30 Databricks 与 Ali 的成长 — 从伯克利 50 人 meetup 到 10 万人峰会，谈 CEO Ali Ghodsi 高 IQ/EQ 且幽默，是后天苦练而来。
• 3:03 Omnigent 的由来 — 编码 agent 与自研 agent 都撞上「频繁换模型/harness、无法协作分享」的同一问题，于是做统一元 harness。
• 5:23 类比网络协议与开放共享 — 把 Agent 互联类比 IP 协议和 open sharing（如 Walmart 实时共享库存表给供应商）。
• 9:15 架构与开源理由 — runner/server 组件、统一 API 构成「Agent 云」；开源是为了网络效应与生态集成，复用 Spark 的经验。
• 13:06 现代数据栈的兴衰 — 复盘 ingest/transform/visualize 分层与「统一整合」趋势，类比当下 agent 框架过多需收敛。
• 16:10 Sandbox 与规模数据 — 从 Neon 存算分离衍生 sandbox（需本地持久化）；每天起 5000-6000 万虚机、处理 EB 级数据、Neon 起 1300 万库/天。
• 19:13 安全、控制与成本 — 详解 contextual policy、Panther 事件处理、按会话封顶花费，以及 Unity Catalog 治理经验的迁移。
• 28:20 Dream Engine 与 OLTP/OLAP — 拆解数据库两大阵营、CDC 之痛，引出 LTAP「统一存储而非统一引擎」的思路。
• 37:35 创新文化 — 不要立项审批、工程师直接试做；公司刻意少发产品、保持一致性、与首批客户「直呼其名」紧密迭代。
• 44:29 从零重写与 second system — 警惕第二系统综合征，用「数据库工厂 + ML 模型」规避失败，增量发布新 endpoint。
• 53:40 对比 Snowflake — 归因于「开放格式」与「AI/ML 优先」两点差异，谈两家从互为合作伙伴到正面竞争。
• 58:20 Mosaic、模型与数据即护城河 — DBRX、Genie、百倍便宜的文档解析模型、advisor models、RL 微调即服务，呼应 Satya「context is the new oil」。

详细内容

Omnigent：把所有 Agent 抹平成一个接口

Omnigent 的诞生来自两条「收敛的线」。一边是内部编码 agent 基础设施：Databricks 的 dev infra 团队做了个叫 Isaac 的工具，本质是 Claude Code 和 Codex 的封装，能在网页 sandbox、开发机或笔记本上跑；更高阶的工程师还在其上自建带大量 agent 的工作流和 UI。另一边是团队自己造的 agent——研究团队的数据科学 agent Genie、各类内部与客户 agent——全都撞上同样的痛点：每隔几个月就要换模型和 harness；而且若不能分享会话、保留历史、做搜索和协作层，agent 基本「没用」。Matei 一开始把编码 agent 和自定义 agent 放进同一个东西被认为很奇怪，但他坚持「这本质是同一批问题」：你要能交付 agent、（在意安全时）控制它、并让它在不同后端间可移植。

Reynold 的切入角度完全不同。他讲了个很真实的故事：有一周他从早到晚不停 coding，最烦的是得一直开着笔记本——甚至开车去看医生时还把笔记本 tether 到手机上，每到红灯就瞄一眼进度，「感觉回到了编程的黑暗时代」。他当时在做不会自动关闭、能快速获取、且不只跑 agent 还能跑开发的云 sandbox，过程中写了份「环境愿望清单」文档，Matei 说团队几乎把每一条都实现了：能开自己的 shell、tail 日志、甚至 SSH 进去，还内置了 markdown 渲染（让 Reynold 不必再为看 markdown 单独开 Cursor）。

技术核心被两人反复强调：是那层架在所有 harness 之上的通用 API。接口很简单——你能发进去 message 或 file，接收流式文本和 tool call 输出，还能发 cancel/turn 控制信号。难的是把 Claude Code（终端里跑）、Codex、OpenAI SDK 等全部映射到同一接口；每当 Claude 改 API，自建 orchestrator 就得跟着改否则丢消息——这正是 Omnigent 替你维护的价值。在此之上他们才搭了 UI、安全与控制等「app」，但强调它「不试图成为一个 stack」，你完全可以插自己的 UI。开源的理由沿用 Spark 逻辑：有网络效应、能受益于多方协作的层就开源（如各种 connector、library），而像「保证流式作业/lakebase 数据库夜里不丢数据」这类必须有运维团队坐镇的能力则只能是服务。成效立竿见影：周六开源，采访当天已约 400 个 merge、约一半来自外部，新增了 Kubernetes、多云 sandbox 以及 Cursor/CLI/anti-gravity 等 harness 支持。

安全、控制与成本：有状态策略

Matei 花了大量时间和内部用户、安全团队、管理者及客户聊，得出几个判断。首先是安全与可用性的张力：今天多数编码 agent 只能做「这个工具模式允许/禁止」的二元开关，太僵。举例——agent 该不该读机密文档？该不该从 NPM 装新包（可能被投毒）？该不该往公司官网发布内容？单看每一个或许都能允许，但若同时具备「读机密 + 发外网」，就可能被 prompt injection 偷数据外泄。于是他们做了 contextual/stateful policy：追踪会话状态，关键不在「是否允许推送到营销站」，而在「如果它刚做了高风险动作（装了一天大的包、读了上千份机密），那就不行；否则放行」。这样既更安全也更好用。

第二块是低层事件需要「库」来解析。比如内部给 Google Drive 的 MCP server 有 60 个 API 调用，很难分辨哪些会把文档分享到公网。Omnigent 把策略层设计成函数 + 库：有人写库把低层事件映射成高层事件，你再针对高层事件写策略。这也是收购 Panther 的契合点——Panther 在事件处理侧思路类似，基于 Python 而非自创怪语言，偏实时。第三块是成本：因为策略有状态，会话花费也被追踪。Matei 说自己曾让 agent debug 一个问题、它读了一堆日志烧 token 花掉 500 美元；现在他可以「起个子 agent 干这个、上限 5 美元、超了问我」。这背后是 Matei 过去五年架构 Unity Catalog（数据治理层）的经验与 AI 治理的结合;作为 CTO 他既怕「装了奇怪 NPM 包泄露全部代码上头条」，又没时间逐条批准 20 行 bash 脚本，所以追求「尽可能安全又不烦人」。

LTAP / Dream Engine：把数据库从零重写

Reynold 先科普数据库世界的两半：OLTP（事务型，Postgres/MySQL/Oracle，面向行、查一行更新一行）与分析型（OLAP，要算「每店营收」「网站日活」乃至跑 ML 预测）。每个 app 认真起来都得先有 OLTP 数据库（不想丢数据、要事务一致性），但数据一多、分析一复杂，直接在 Postgres 上跑会拖垮库，于是要把数据复制到分析系统。行业标准做法是 CDC（change data capture，读数据库 binlog 重建状态），但它极其脆弱——改个 schema 就可能让管道崩溃，Matei 在 keynote 上问「谁爱自己的 CDC 管道」只有约两人举手，他们戏称其为 continuous data corruption。

十多年前 SingleStore 等提出 HTAP「单库通吃两类负载」的圣杯，但代价是处处妥协：自创小而专有的 API、两边生态都吃不到、两边性能都难比肩。Databricks 的 LTAP 是 HTAP 的文字游戏，主张「HTAP done right」：不在查询层合并，而是只统一存储层——99% 的需求由此满足。具体做法是让 Postgres 以列式格式写入开放数据湖，分析侧就能零延迟直读、无中间管道。关键的工程突破很有戏剧性：在 lakebase（很大程度来自 Neon 团队的存算分离）里数据本是以 Postgres page 行式写盘的，Ali 和 Reynold 长期争论能否改成列式，某天一位工程师没立项就直接 prototype 成功了——他发现存储集群有大量闲置 CPU，可用来做行转列转码（行利于 OLTP，列利于分析），而且转码后数据压缩更好、写 S3 反而更快，零性能损耗。Reynold 坦言起初自己都不太信这套定位对 agent 有用，直到一位澳洲客户告诉他：服务日志出现 SLA 下滑想排查，但 agent 看不到数据库内部、只能看到产品遥测；若能让 agent 理解「到底是谁在下单、在干什么」，它会强大十倍——他这才被自己的 message 说服。Matei 补充：过去出事故时工程师不敢在主库跑大查询怕雪上加霜，LTAP 用独立分析机群解决了这点。

用机器学习「造」数据库引擎

dream engine 的更大野心是承认包括 Databricks 在内、所有有牵引力的分析引擎都已约十年历史，最初瞄准窄场景，十年有机演化后为支持新用例不断打 hack，变成「巨大的一坨」。极少有公司敢推倒重来——还会撞上「第二系统综合征」（first system 成功、second system 因过度野心而失败）。他们招了一批顶级数据库工程师（很多人早过了「第二个系统」），并改变了造引擎的范式：不再读论文拼最新算法（在 70% 负载好看、30% 翻车的风险高），而是先花时间建一个「数据库工厂」。工厂吃下十年的 trace（号称千万亿/quadrillion 级数据点，会采样）训练一个机器学习模型——Reynold 强调是 ML 模型不是 LLM——它能极高保真地预测任意算法/实现在任意 query 类型上的表现，从而在编译期与运行期都挑选最优算法与数据结构。

关键维度包括规模、吞吐、延迟，以及数据分布（稀疏度、重复命中频率、distinct 值数量——后者直接影响聚合时哈希表的内存）。Reynold 举了个「诡异但影响深远」的例子：字符串是纯 ASCII 还是含 Unicode，会决定编码方式；若字符串足够稠密（如只有 256 种取值，类似国家代码），聚合时甚至不用哈希表、直接用数组查找，快得多。模型由此识别出许多反直觉的结论——看似该很好用的往往实际不行——并在运行期分派正确算法。落地策略仍是增量：先发新 endpoint，新引擎设计上要「做到旧引擎的一切且更好」（尤其是几十毫秒的极低延迟负载），按能力逐步铺开，避免「5 年才见隧道尽头」。

文化、客户与战略

两人花不少篇幅讲「创新文化」：列式转码这种对公司极其战略的事，居然没有 kickoff、没有设计文档，就是有人在多次会议争论后直接做了出来。Matei 说只要把环境搭好让人敢这么干就行，Omnigent 也类似——光有文档大家只会空想，做出来让真实用户去 bash 才知道行不行。他们认为公司虽大却有一批「免疫于变慢」的核心人，靠的是招顶尖的人、授权他们、以及领导层「在战壕里」。另一条原则是刻意少发产品、保持一致性——这正是公司最初的理论：不像 AWS 那样要拼 20 个服务，而是一个平台、统一 API/语义、同一份数据，再一次加一个能力（先 Delta Lake 加存储、再加 SQL、再加 ML 平台）。同时强调增量与速度：很多产品几周做成，Matei 对建产品的团队第一个问题永远是「目标客户是谁、你和他直呼其名吗、在发短信吗」。他们也不怕「过拟合」一两个客户（Delta Lake、clean room 当年都是为一两家做的），认为过拟合的下行远小于「想 boil the ocean 结果一个客户都没有」。还谈到 tech 公司与传统企业的差异（治理/安全/合规/采购流程/legacy 系统，以及「我自己也能造」的 DIY 心态）。

谈到对 Snowflake 的胜出，Reynold 归因两点：一是开放——Databricks 从无专有格式，从 Parquet 起步演进到 Delta、Iceberg；二是 AI——2022 年 10 月 ChatGPT 前他们就把自己定位成「机器学习 + 数据」而非纯数据基础设施。Matei 补充两家路径相反：Snowflake 从「管理最有价值的小数据、自有优化存储、服务管理层」起步；Databricks 从大规模批处理与 ingest（Spark 的本行）起步、数据存开放格式（可能更慢但已在外可被下游消费），事实证明从「大而开放」往「快而易用」走更容易。两家一度互列合作伙伴（Databricks 做 ingest/compute、Snowflake 做可视化），后来客户都问「为什么还要另一个、不能直接查你的表」，于是各自侵入对方腹地。

关于模型，Reynold 解释 Mosaic 的故事：Mosaic 早期以快速训练栈和早于 ChatGPT 的开源 LLM 闻名，Databricks 收购后也发过开源模型 DBRX（规模约超 Llama 3）。但他们判断会有大量人发通用模型（无非堆算力和规模），于是转向「拿到聪明模型后怎么让它有用」——第一方 agent Genie（虚拟数据科学家，懂你公司一切数据与 ML 库）。他们仍在训练大量专用模型：一是高频用例下专用模型远胜通用模型，典型如文档/PDF/Word 解析——通用前沿模型（如 Claude Fable）「差不多对但总错一点且超贵」，他们的视觉文档模型把整页转成结构化 JSON，约便宜 100 倍还更好（由一位前 DeepMind、Adept 联创打造）。二是编码 agent 的专用子 agent，呼应 Harvey、Anthropic、UC Berkeley 的「advisor models」论文。Matei 判断模型定制会越来越易：基模更聪明→RL trace 更好，合成数据更易，他们已有用开源模型自我生成训练环境并自训、在某任务上击败 Opus 和 GPT 5.5 的管道；难点只在于何时易到「无需硬核 LLM 研究员、谁都能描述任务即可」。Reynold 收尾呼应 Satya（context is the new oil）：数据越多、配上更好技术，就能在自己领域做更多——这正是 Databricks 凭十年 query 与表布局历史能快速、且有信心造出好引擎的原因，也是他们「先把数据放对地方，再糊上 agent，魔法自来」战略的根基（本届峰会面向安全团队和营销团队各发一款产品即体现此思路）。

金句

我认为很多传统软件都会以这个新范式被重写——就是先把数据放到对的地方，然后糊上一层 AGI，魔法自然就出来了。但没有对的数据，你根本做不到。 —— Reynold Xin 0:00

那感觉就像我们倒退回了编程的黑暗时代。 —— Reynold Xin 7:43

CDC 是最枯燥却又最基础、支撑着现代社会运转的操作之一，但它脆弱到我们开玩笑说应该叫它 continuous data corruption（持续数据损坏）。 —— Reynold Xin 31:25

我们争论了很多次会，从第一性原理争论它到底可不可能，然后某个人就直接做了出来——争论就此结束。 —— Reynold Xin 37:35

数据库压根就不该是一个独立品类。 —— Reynold Xin 52:08

只要数据在那、可被访问，agent 就能搞定;查询语言这事五年前对人类或许是问题，但对 agent 从来不是。 —— Reynold Xin / Matei Zaharia 52:53

提到的书·产品·人物

• Matei Zaharia（人物）：Databricks CTO、Spark 创造者、Unity Catalog 主架构师，本期嘉宾。
• Reynold Xin（人物）：Databricks 联合创始人，本期嘉宾，dream engine/LTAP 的主要推动者之一。
• Ali Ghodsi（人物）：Databricks CEO，被两人盛赞 IQ/EQ/幽默兼备、在多个产品方向上力排众议做出正确选择。
• Omnigent（产品）：本期主角，开源的元 harness / Agent 云，统一各编码 agent 接口并叠加安全与成本控制。
• Isaac（产品）：Databricks 内部 dev infra 团队做的 Claude Code/Codex 封装工具。
• Genie（产品）：Databricks 第一方数据科学 agent，「虚拟数据科学家」。
• LTAP / dream engine / Lakebase（产品）：统一存储层实现 OLTP+分析零延迟直读的数据库重写项目。
• Panther（公司/产品）：Databricks 收购，用于实时事件处理、支撑高层安全策略。
• Neon（公司）：存算分离的 serverless Postgres，其架构被 Databricks 借鉴做 sandbox 与 lakebase；提到创始人 Nikita。
• Snowflake（公司）：主要竞争对手，谈两家开放性与 AI 取向的路径差异;提及其联创博文《Choosing Open Wisely》。
• Spark / Delta Lake / Unity Catalog / DBRX（产品）：Databricks 历史产品，作为开源、增量演进与治理经验的参照。
• Mosaic（公司）：被 Databricks 收购的训练栈与早期开源 LLM 团队;提到 MPT-7B、John 与 Abhi。
• Satya Nadella（人物）：微软 CEO，其「frontier ecosystem / context is the new oil」论被引为呼应。
• Ben Horowitz（人物）：a16z，曾建议 Databricks「别在 1000 亿前卖、公司该值一万亿」。
• TigerBeetle / Chroma / TurboPuffer（产品）：被提及的专用数据库案例（复式记账库、向量库等），印证「窄场景起步再泛化」规律。
• advisor models（论文/概念）：Harvey、Anthropic、UC Berkeley 等的专用子 agent 思路;提到 Parf（在 Adept、Continual Learning 方向）。
• second system syndrome（概念）:警示从零重写易因过度野心失败。

适合谁听

关注数据基础设施、AI agent 平台架构与开源战略的工程师、技术决策者与投资人。