为什么前沿生态系统必须开放——Matei Zaharia、Reynold Xin｜DatabricksWhy the Frontier Ecosystem must be Open — Matei Zaharia and Reynold Xin, Databricks

播出信息

• 日期：2026-06-24
• 节目：Latent Space
• 主持人：Swyx
• 嘉宾：
• Matei Zaharia：Databricks 联合创始人；节目中提到他领导研究团队，并在过去五年投入大量时间设计 Databricks 的数据治理层 Unity Catalog。
• Reynold Xin：Databricks 联合创始人。
• 场合：Databricks Data + AI Summit 期间的现场对谈。
• 核心议题：Omnigent 智能体基础设施、云端沙箱、统一 Agent API、开源策略、上下文安全策略、成本控制、Lakebase 与数据库架构、Databricks 和 Snowflake 的路线差异、Mosaic/DBRX/Genie、专用模型、强化学习微调，以及“数据加智能体”如何改写传统软件。
• 全集时长：约 4132 秒，即约 68 分 52 秒。
• 转写完整性说明：用户提供的英文材料在约 24:46 至 52:47 之间标注了“中段省略”。因此，本文可以列出该区间已有的官方话题锚点，但不会臆造被省略部分的具体发言、技术细节或数字。

背景

Databricks 最初围绕 Apache Spark 及大规模数据处理发展。节目开场回顾称，团队第一次在伯克利举办的峰会只是一个约 50 人的小型聚会，主要内容是用教程教人使用 Spark；本次峰会被主持人描述为全球约 100,000 人参与、约 30,000 人线下出席。这一变化构成整场访谈的基本背景：Databricks 已经从围绕单一开源计算引擎的社区，扩展为横跨数据、机器学习、数据库、治理和智能体基础设施的平台。

峰会上提到的产品与项目包括 Omnigent、LTAP、Dream Engine、Genie、CustomerLake、Panther、Open Sharing 和 Unity AI Gateway。主持人认为，其中 Omnigent 与 LTAP/Dream Engine 是两位嘉宾正在推动的、最具差异化的方向。完整转写中段虽然缺失，但现有内容表明，这些项目被统一放在一条主线上讨论：数据必须以开放、低成本且可治理的形式存在；智能体则需要统一运行接口、持久会话、协作环境、安全策略和预算控制，才能从个人演示进入企业生产环境。

另一个背景是 Databricks 与 Snowflake 的长期路线差异。嘉宾把 Databricks 的起点概括为开放格式、大规模摄取和上游计算，把 Snowflake 的早期重点概括为管理高价值数据、用自有存储与引擎优化查询体验。随着双方产品范围扩大，原本可以合作的上下游系统逐渐进入彼此的市场。

总结分析

整场对谈的主线不是“再做一个智能体框架”，而是为不断变化的模型、harness、工具和计算环境建立一个稳定的开放层。Matei 从 Databricks 内部经验出发：高级工程师已在 Claude Code、Codex 等工具上构建多智能体流程，但每个团队都重复开发界面、会话管理和协作服务器；模型接口又会持续变化，导致应用难以迁移。Omnigent 因而试图把不同 harness 映射到统一的会话 API，并补上历史记录、搜索、文件传递、流式事件、工具调用、远程 shell、持久沙箱和安全共享。开放源码并非单纯的品牌姿态，而是为了吸收连接器、Kubernetes、云沙箱和新 harness 等生态贡献。

第二条主线是企业智能体的控制面。传统“允许或禁止某个工具”的静态授权过于粗糙：读取机密文档、安装 npm 包、发布网站内容单独看可能都有合理场景，但同一会话先读取敏感材料、再执行高风险外发操作，就可能形成数据泄漏链。Omnigent 因此强调有状态、上下文化策略，同时按会话追踪支出，让用户可以把任务预算限制在 5 美元并在超额前请求批准。这里体现了 Matei 从 Unity Catalog 数据治理延伸到 AI 治理的思路。

第三条主线是开放数据架构与 AI 的结合。Reynold 认为 Databricks 相对 Snowflake 的关键差异，一是从 Parquet、Delta 到 Iceberg 的开放生态，二是公司从早期就把机器学习与数据放在同一平台叙事中。模型层面，Databricks 没有把主要赌注放在通用前沿模型军备竞赛，而是转向 Genie、文档解析模型、advisor model、RL 微调和 AI Runtime 等可落地能力。最终判断是：通用模型的推理能力已足够强，真正限制企业软件重写的往往是数据是否就位、上下文是否可用，以及安全和治理是否允许智能体采取行动。

节目结构 / 议程

1. 从 50 人 Spark 聚会到全球 Data + AI Summit — 00:00 🎧 · ▶️
2. Omnigent：把编码 Agent 与定制 Agent 放进同一基础设施 — 02:22 🎧 · ▶️
3. Agent Cloud：会话不能再依赖一台始终开机的笔记本 — 08:39 🎧 · ▶️
4. 统一 API 与开源：稳定层应该位于多种 harness 之上 — 16:52 🎧 · ▶️
5. 上下文安全：不是简单的 allow/deny，而是判断行为链 — 18:03 🎧 · ▶️
6. 安全与费用是同一个控制面的两类状态 — 27:34 🎧 · ▶️
7. LTAP、Lakebase 与 Dream Engine：中段材料缺失下能确认的边界 — 36:47 🎧 · ▶️
8. Databricks 与 Snowflake：先开放、先做大规模，再向高性能查询扩张 — 51:02 🎧 · ▶️
9. Mosaic 与 DBRX：不把主要资源押在通用前沿模型竞赛 — 57:48 🎧 · ▶️
10. 专用模型、advisor models 与 RL：更小的任务边界可能带来更高性价比 — 01:03:11 🎧 · ▶️
11. 数据与上下文是长期资产，Agent 可能成为传统软件的新交互层 — 01:06:15 🎧 · ▶️

分节详解

1) 从 50 人 Spark 聚会到全球 Data + AI Summit — 00:00 🎧 · ▶️

💬 他们说了什么： Databricks 的第一次峰会是在伯克利举行的约 50 人小型 meetup，团队当时主要通过教程教参与者使用 Spark。主持人称，本次峰会的 headline number 已达到全球约 100,000 人、线下约 30,000 人，Matei 用“Amazing”回应这种增长。谈到 Databricks CEO Ali Ghodsi，Matei 表示，在联合创始人群体中，当初就比较明确 Ali 最适合承担 CEO 角色。Matei 说 Ali 会主动研究公司扩张所需的财务、销售等主题，即使无法直接雇到某位专家，也会先与专家交谈并学到足够多。Reynold 将 Ali 描述为兼具高 IQ 和高 EQ，但强调今天的 Ali 与十年前不同，其能力背后投入了大量工作。主持人还特别提到 Ali 能对数据仓库、安全等严肃主题开玩笑，使其公开表达更有吸引力。

💡 为什么重要： 这段开场把 Databricks 的发展放在“社区—开源项目—大型平台公司”的连续路径上，而不是把当前 AI 产品视为突然转型。Ali 的案例也说明，创始团队中的职责并非完全由早期技术能力决定，经营、沟通与学习能力可以在十年尺度内持续形成。

⚡ 争议点： 全球 100,000 人与线下 30,000 人是主持人口中的“headline number”，转写未说明统计口径。关于 Ali 是“最佳 CEO 人选”的判断来自联合创始人内部评价，属于主观回顾。

2) Omnigent：把编码 Agent 与定制 Agent 放进同一基础设施 — 02:22 🎧 · ▶️

💬
Matei 说 Omnigent 源自几条同时汇合的需求线索。Databricks 内部开发基础设施团队构建了名为 Isaac 的工具，它包装 Claude Code 与 Codex，让工程师既能在网页沙箱中使用，也能在开发机或笔记本上运行。更高级的工程师开始围绕这些工具建立多智能体工作流，并自行开发界面。Matei 所领导的研究团队则在构建数据科学智能体 Genie，公司内部还有其他智能体，客户也在开发自己的智能体。这些系统每隔几个月就可能需要更换模型或 harness，同时还需要共享会话、历史记录、搜索与协作能力。最初有人质疑为何要把编码智能体与定制业务智能体放进同一个系统，Matei 的回答是：两者面对的是相同的交付、控制、迁移与协作问题。团队先做实验性原型，确认可行后再把它建设成正式系统。

💡
Omnigent 的产品假设是，Agent 的稳定抽象并不是某个模型，而是会话、事件、工具调用、状态和协作层。只要模型与 harness 仍高速变化，把应用直接锁定到单一实现就会持续产生迁移成本。

⚡
转写主要提供 Databricks 内部观察，没有给出外部用户规模、基准测试或生产可靠性指标。“编码 Agent 与业务 Agent 本质相同”是架构层判断，不代表两者在权限、评估和失败成本上完全一致。

3) Agent Cloud：会话不能再依赖一台始终开机的笔记本 — 08:39 🎧 · ▶️

💬
Reynold 回忆自己曾从早到晚持续使用 Claude 与 Codex 编程，最让他烦恼的问题之一是必须让笔记本一直开着。他甚至在前往医生预约的途中用手机给笔记本提供网络，并在红灯时查看任务运行情况；他认为这像是退回了编程的“黑暗时代”。他由此提出云端沙箱应快速启动、不会随本地设备关闭，并能同时支持智能体会话与普通开发工作。Matei 的早期原型只有与 Agent 对话的能力，Reynold 明确要求加入自己的 shell，以便列目录、查看文件和 tail 日志，后来这些功能被加入。Reynold 还说自己保留 Cursor 的一个原因是渲染 Markdown，因此也要求系统直接展示和渲染 Markdown 文件。Matei 补充，很多工程师都能做出适合自己的 vibe coding 环境，但缺少协作服务器后，团队其他成员便无法安全复用。

💡
Agent 的价值不只来自推理能力，还来自任务是否可以脱离个人终端持续运行，以及其他人能否安全地接管、检查和复用会话。云端沙箱由此从“可选部署方式”变成 Agent 开发体验的一部分。

⚡
驾车途中查看笔记本的叙述涉及明显的驾驶安全风险，不应被当作推荐工作方式。个人痛点能够启发产品，但不能单独证明所有企业用户都需要相同交互模式。

4) 统一 API 与开源：稳定层应该位于多种 harness 之上 — 16:52 🎧 · ▶️

💬
Omnigent 被描述为包含 runner、server 与统一 API 的开放平台，可以接入不同持久化层和计算层，主持人将它概括为一个“agent cloud”。Matei 认为它提供的是托管、协作型 Agent 所需的最小组件，同时允许开发者从一个可定制应用开始，而不是每个团队重新搭建界面和服务器。Databricks 内部一度出现约 五六个不同团队分别构建的 Agent 框架，它们完成的功能大致相同。统一 API 把 Claude Code、Codex、Pi、OpenAI SDK 等不同实现映射为共同接口：向会话发送消息或文件，接收流式文本与工具调用事件，并可以取消当前 turn。Matei 认为，维护这种映射层很有价值，因为上游 API 一旦变化，自建编排器就可能丢失消息或需要紧急调整。项目开放源码后不久便收到 Kubernetes、云沙箱、Cursor CLI、Antigravity 等方向的生态集成；转写中还提到“400 merge already?”，随后估计约一半并非来自 Databricks 团队，但表述存在口语歧义。

💡
共同接口可以把应用层与模型供应商、终端工具和执行环境解耦，降低迁移及维护成本。开源的关键收益则是网络效应：Databricks 不必独自完成面向所有数据库、文件格式、沙箱与 Agent harness 的连接器。

⚡
“约 400 个 merge”没有清晰说明是合并提交、PR 还是其他统计，必须谨慎引用。统一 API 也可能只覆盖不同 Agent 系统的公共子集，转写没有讨论是否会损失供应商特有能力。

5) 上下文安全：不是简单的 allow/deny，而是判断行为链 — 18:03 🎧 · ▶️

💬
Matei 在与内部开发者、安全团队、管理者及客户交流后，发现 Agent 安全中存在明显的可用性与安全性冲突。许多编码 Agent 只有按工具模式允许或禁止的静态规则，但真实任务往往不能用简单的是或否处理。读取机密文档、从 npm 安装包、向公司网站发布内容，各自都可能有合理用途；危险之处在于同一会话先接触敏感数据，再受到 prompt injection 或执行外发操作。Omnigent 因而采用有状态的 contextual policies：系统持续追踪会话状态，如果 Agent 安装过风险包，或读取了约 1,000 份机密文档，后续发布动作便可以被阻止。Matei 还举例称，Databricks 内部 Google Drive MCP server 有 60 个 API 调用，因此需要把底层事件解析成更高层语义，再由策略判断哪些调用会把文档分享到互联网。策略可以拦截事件，并选择阻止、要求用户批准或放行，同时更新状态。

💡
企业安全的核心不只是“某个工具有没有权限”，而是多个本身合理的动作组合后是否形成危险路径。有状态策略把权限模型从静态访问控制推进到会话级行为控制，更适合长时间、自主执行的智能体。

⚡
系统仍需准确识别“风险包”“机密文档”和“对外发布”等高层事件；误分类可能导致泄漏或过度拦截。转写没有提供对抗 prompt injection 的实测结果，也没有证明该策略能覆盖所有跨工具攻击链。

6) 安全与费用是同一个控制面的两类状态 — 27:34 🎧 · ▶️

💬
Matei 表示，有一次他让 Agent 调试问题，Agent 因读取大量日志、消耗大量 token，最终花费了 500 美元。Omnigent 可以按会话追踪支出，因此用户能够启动任务时把预算上限设为 5 美元，超过后再询问是否继续。对 Databricks 而言，安全是云提供商最关键的事项，当前对 token 使用本身没有同等程度的担忧。公司内部工程师使用额度被描述为“无限”，但 Databricks 会分析运行 traces，并由团队寻找异常行为和优化机会。通过分析 traces，团队还会比较不同模型在 Rust、TypeScript 等任务上的相对表现，不过 Matei 特别限定为“至少在我们的代码库中”。他又举例说，一些咨询公司拥有约 100,000 名为客户编程的员工，如果每人每月额外花费 1,000 美元，整体成本会非常难以承受。

💡
预算控制与安全控制都依赖相同基础能力：识别会话、累计状态、拦截下一步行动，并在阈值处请求批准。对大规模组织而言，单用户看来可接受的 Agent 花费会在员工数量放大后变成显著经营问题。

⚡
咨询公司 100,000 名员工、每人额外 1,000 美元是说明规模效应的假设性例子，不是实际客户账单。该节标题沿用已有时间锚点，但用户提供的转写在 24:46 后出现中段缺失，因此不能据此补写 LTAP 的原始发言。

7) LTAP、Lakebase 与 Dream Engine：中段材料缺失下能确认的边界 — 36:47 🎧 · ▶️

💬
已有时间提示显示，中段依次讨论了 LTAP and the Database Dream、CDC, HTAP, and Why Data Pipelines Break、Lakebase, Parquet, and Live Data for Agents、Databricks 的快速原型文化，以及 Dream Engine 对数据库栈的重写。现有可见转写还说明，Databricks 的沙箱方案之所以能快速构建，是因为团队发现可以沿用 Lakebase/Neon 相关架构，再移除数据库部分。Matei 指出，编码沙箱与 Neon 式计算存储分离并不完全相同，因为开发环境需要本地持久性，以保存源码、依赖、库和构建产物。Databricks 内部开发环境可能包含“数十 GB”源码和产物，用户会希望下一次启动时它们仍然存在。后文还显示 Databricks 把 Parquet、Delta、Iceberg 视为开放数据生态的一部分，并把开放格式作为长期基础。除此之外，由于中段逐字稿被省略，无法可靠复原 LTAP、CDC、HTAP、Lakebase 与 Dream Engine 的具体定义和论证。

💡
这里最明确的架构信号是：数据库、沙箱和 Agent 运行环境共享计算调度、存储与生命周期管理等基础问题，但不同工作负载仍对本地持久性提出不同要求。开放数据格式则试图让上层查询引擎和智能体可替换，而不把企业数据锁死在单一执行系统内。

⚡
仅凭章节标题不能推断 LTAP、Dream Engine 的完整技术机制或性能优势。任何关于 CDC 管道为何失效、HTAP 如何实现及 Lakebase 如何服务实时 Agent 的进一步细节，都需要查阅未省略的原始音频或完整英文稿。

8) Databricks 与 Snowflake：先开放、先做大规模，再向高性能查询扩张 — 51:02 🎧 · ▶️

💬
Reynold 认为两家公司的最大根本差异之一是开放性：Databricks 没有从专有数据格式起步，而是从 Parquet 开放生态发展到 Delta、Iceberg 等格式。第二个差异是 AI；在 ChatGPT 于 2022 年 10 月出现之前，Databricks 就一直把自身定位为“机器学习加数据”，而不只是数据基础设施。Matei 将 Snowflake 的早期路线概括为管理最有价值的数据，用与引擎协同优化的自有存储，优先服务管理者、财务人员等查看的较小数据范围，并追求极快查询。Databricks 则从 Spark 所擅长的大规模摄取、JSON 日志及类似 MapReduce 的批量处理出发，把数据保存在开放格式中。Matei 的总结是“start open and start large”：先开放、先处理大规模与上游问题，再向快速 SQL、可视化和业务用户体验扩张。双方曾互相列为合作伙伴，让 Databricks 负责摄取与计算、Snowflake 负责表服务和快速可视化，但客户不断追问为何不能直接查询 Databricks 表，最终推动双方进入对方领域。

💡
这不是简单的产品功能对比，而是“开放上游基础”与“专有优化系统”两种起点的竞争。Matei 认为，从低成本、大规模、开放的数据层向高性能服务扩张，比从封闭的高性能查询向全公司统一数据基础扩张更容易。

⚡
这是 Databricks 创始人对竞争格局的解释，天然带有立场；Snowflake 的观点并未在节目中直接呈现。主持人称 Databricks 已“客观上超过”Snowflake，但转写没有提供收入、客户、估值或性能数据支持该判断。

9) Mosaic 与 DBRX：不把主要资源押在通用前沿模型竞赛 — 57:48 🎧 · ▶️

💬
Matei 回顾称，Mosaic 早期因发布开源 LLM 而广为人知，但它更早的工作是优化训练系统，并曾拥有速度领先的图像模型训练栈。Mosaic 在 ChatGPT 之前就转向 LLM，推出了较早的一批开源语言模型。Databricks 后来发布了开源模型 DBRX，规模被描述为达到“高于 Llama 3 scale”，但公司决定不把重点放在单纯通过更多算力扩展通用模型。其战略重心转向：已经拥有聪明的基础模型后，如何让模型在企业任务中真正有用。第一方 Agent Genie 被描述为虚拟数据科学家，目标是理解公司内部数据、机器学习库、数据工具和网络信息，并回答业务问题。系统既可使用外部模型，也可使用经过微调的定制组件；Databricks 仍在持续采购 GPU 并进行模型训练。

💡
这一选择把竞争焦点从“谁训练出最大的通用模型”转向“谁能把数据、工具、评估和专用组件组织为可靠系统”。对 Databricks 而言，数据平台本身可能比单一基础模型更持久。

⚡
“高于 Llama 3 scale”没有明确参数量、训练 token 或具体比较版本。Genie 被比作“已经了解公司一切的虚拟数据科学家”是产品愿景，不等于它已达到人类数据科学家的全面能力。

10) 专用模型、advisor models 与 RL：更小的任务边界可能带来更高性价比 — 01:03:11 🎧 · ▶️

💬
Matei 认为，高调用量任务中，专用模型可能明显优于通用模型。他以 PDF、Word 等文档解析为例：把页面交给 Claude 等前沿模型处理，结果可能“几乎正确”但仍有错误，而且图像输入会消耗大量 token。Databricks 团队开发了一个文档视觉模型，把页面转成包含各组件的 JSON；Matei 称它大约比前沿模型便宜 100 倍，同时效果更好。公司也在研究用于编码 Agent 局部环节的专用 Agent，以及 advisor models；Matei 提到其伯克利学生 Parth 写过题为《Advisor Models》的论文。Matei 判断，基础模型越聪明，就越能生成更好的强化学习 traces；RL 又可以从系统自己的历史 traces 中学习，合成数据生成也在变得更容易。他还称，团队存在使用开源模型生成训练环境、再训练自身的管线，并在某项任务上超过 Opus 与 GPT 5.5，但转写没有给出任务名、评估集或具体分数。

💡
专用模型的经济性可能决定 Agent 能否进入高频生产流程：即使通用模型足够聪明，成本、延迟和结构化输出稳定性仍可能不合格。统一接口又让专用模型可以作为系统组件被替换、组合和共同训练。

⚡
“便宜约 100 倍且更好”缺少测试配置、文档类型、质量指标和价格基准，需要独立验证。超过 Opus 与 GPT 5.5 的说法只限定于“一个任务”，不能外推为通用能力领先。

11) 数据与上下文是长期资产，Agent 可能成为传统软件的新交互层 — 01:06:15 🎧 · ▶️

💬
主持人引用 Satya 关于 frontier ecosystem、token 与上下文的讨论，询问 Databricks 如何理解“context is the new oil”式判断。Matei 表示，随着处理技术进步，企业原有数据会变得更有价值；这不只发生在 AI 时代，智能电表、汽车传感器和摄像头同样说明新技术会让既有数据产生新的决策价值。Agent 可以主动发现产品功能异常，例如观察到用户不再上传文件，因为上传过程持续报错，而不必等待客户投诉。Databricks 还可利用历史查询、表布局和运行表现构建新引擎，并对新引擎效果形成信心。Reynold 的核心判断是，只要把数据放在正确的位置，当前通用模型和 Agent 已具有相当不错的推理能力，许多传统软件会被重写为“准备数据，再在上面放一个 Agent”。Databricks 在峰会上分别面向安全团队和营销团队发布了两个产品，背后的共同方法都是先把数据汇集好，再让 Agent 在上层工作。

💡
这将企业 AI 的瓶颈从纯模型能力转向数据位置、数据质量、权限与可执行上下文。若这一判断成立，未来应用的差异化不一定来自独占基础模型，而可能来自谁能安全地组织数据并让 Agent 持续采取行动。

⚡
Ali 所说“AGI is already here”是极具争议的定义性判断，节目没有给出 AGI 标准。把传统软件概括为“数据加一个 Agent”可能低估确定性业务规则、审计、事务一致性、交互设计和责任归属的重要性。

人物与机构

• Matei Zaharia：Databricks 联合创始人；领导研究团队；参与 Genie、Omnigent 等项目；过去五年大量投入 Unity Catalog 架构工作；同时是 UC Berkeley 学生 Parth 的导师之一。
• Reynold Xin：Databricks 联合创始人；在节目中讨论计算规模、数据库战略、公司文化和“数据加 Agent”路线。
• Swyx：Latent Space 主持人；负责提出 Omnigent、Snowflake、Mosaic、模型战略与上下文价值等问题。
• Ali Ghodsi：Databricks CEO、联合创始人；被评价为兼具 IQ、EQ、技术执着、执行力与商业能力。
• Nikita：节目称其来自 Neon；与 serverless Postgres、计算存储分离、数据库快速启动及分支实验相关。
• Sam Nigon：主持人在查看 Omnigent 项目合并情况时提及，但转写未进一步介绍身份。
• Parth：UC Berkeley 学生；Matei 称自己是其导师之一；写过《Advisor Models》论文，并从事 continual learning benchmark 相关工作。
• Satya：主持人称自己在 Microsoft Build 采访过他，并讨论其关于 frontier ecosystem、上下文及模型定制的文章；转写未给出全名。
• Ben Horowitz：被描述为 Databricks 的重要支持者；转写回忆他曾认为公司目标不应只是 100 亿美元，而应有达到 1 万亿美元价值的潜力。
• Databricks：数据与 AI 平台公司，也是本次 Data + AI Summit 主办方。
• Mosaic：被 Databricks 收购的模型与训练系统团队，曾发布较早的开源 LLM。
• Neon：与 serverless Postgres、计算存储分离、数据库分支和快速启动相关。
• Snowflake：Databricks 的主要竞争者，也曾是可组合方案中的合作伙伴。
• Panther：Matei 称其事件处理思路与策略层相关，并强调 Python，而不是特殊自定义语言。
• Unity Catalog：Databricks 的数据治理层；Reynold 将 Matei 的 Agent 治理思路与其 Unity Catalog 经验联系起来。

金句（中英对照）

“Start open and start large.” “从开放开始，也从大规模开始。”

这是 Matei 对 Databricks 与 Snowflake 不同起点的最简洁概括：先承担上游摄取、批处理和低成本开放存储，再向高性能服务扩张。

“The agent is completely useless if you can’t share sessions with someone and have history and have search.” “如果你不能与别人共享会话、保留历史并进行搜索，这个智能体基本上就毫无用处。”

强调 Agent 产品化不仅取决于模型，还取决于协作与状态基础设施。

“Which one’s gonna win in the long run?” “长期来看，哪一个会赢？”

Matei 用这个反问解释为何具有集成网络效应的 Agent 层应开放源码。

“Should my agent be able to do both?” “我的智能体是否应该能同时做这两件事？”

关键不在某项权限是否合理，而在读取机密信息与执行外发动作能否被组合起来。

“I can literally say, ‘Launch an agent to do this and cap it to spending $5.’” “我可以直接说：启动一个智能体做这件事，并把支出上限设为 5 美元。”

展示按会话追踪状态如何同时服务成本治理。

“For us, security is absolutely critical as a cloud provider.” “对我们这个云提供商而言，安全绝对是关键事项。”

说明 Databricks 对安全与 token 成本的优先级排序。

“We never felt, ‘Hey, we’re just a data infrastructure platform.’” “我们从未觉得自己只是一家数据基础设施平台。”

Reynold 用它解释 Databricks 在 ChatGPT 之前就持续绑定机器学习与数据。

“How do you make it useful?” “怎样才能让它真正有用？”

代表 Databricks 从通用模型竞赛转向专用模型、Genie 与系统工程的核心问题。

“Once you can get the data in the right place, the AI models are becoming pretty good.” “一旦你能把数据放到正确的位置，AI 模型本身已经变得相当不错。”

Reynold 把企业 AI 的主要瓶颈指向数据准备和上下文。

“Just get the data to be there, and then just slap some agent on top. Magic will come out.” “只要先让数据到位，再在上面放一个智能体，魔法就会出现。”

这是全场最激进的软件重写判断，同时也最需要对适用边界保持警惕。

洞见与延伸背景

1. Agent 平台真正需要标准化的是会话事件，而不是模型名称

转写给出的统一 API 很克制：消息、文件、流式文本、工具调用与取消 turn。它没有试图把所有 Agent 内部逻辑统一成单一框架，而是选择维护各种 harness 到共同事件模型的映射。这种设计意图是让上层 UI、协作系统、安全控制和产品功能不必随着模型供应商接口一起重写。

2. 开源与商业服务并不矛盾

Matei 区分了适合开源的网络效应层与必须作为服务运营的基础设施层。连接器、接口与集成可以通过开放生态扩展；但确保流式任务或 Lakebase 数据库不会在夜间丢失数据，需要持续值守的运营团队，无法只靠发布代码完成。Databricks 想开放“构建在上面的层”，同时在托管基础设施上形成商业能力。

3. Contextual policy 是从对象权限转向因果链治理

传统权限系统通常判断某个主体能否访问某个对象。Matei 描述的上下文策略则要考虑会话此前做过什么：是否安装过风险包、是否读取大量机密文件、是否准备向公网发布。这说明 Agent 治理对象不再只是单次 API 请求，而是一条可能跨模型、工具和数据源的行为序列。

4. 数据库公司天然也是计算调度公司

节目用 Neon/Lakebase 架构解释沙箱为何能快速出现：能够按需启动数据库计算的系统，也已经拥有快速创建、调度和回收计算环境的能力。移除数据库后，部分能力可以转化为 Agent 沙箱；但开发沙箱需要本地持久磁盘，因此不能机械复制纯粹的计算存储分离架构。

5. 训练与运行会通过 traces 形成闭环

Databricks 不仅观察 Agent traces 以控制异常支出，还从中比较不同模型在 Rust、TypeScript 等任务上的表现。Matei 又把 RL 描述为从自身历史 traces 学习。由此形成一条闭环：运行产生轨迹，轨迹用于分析和评估，再生成训练数据，训练后的组件重新进入运行系统。

6. 开放数据的战略意义大于文件格式本身

嘉宾并不只把开放格式当成便于导出的技术选项，而把它视为企业架构的长期基础。Matei 的理由是，经营数十年的企业已经经历过 Oracle 等系统的锁定，CTO 在设计未来架构时会倾向选择开放基础，并尽量减少公司内部管理数据的方式数量。

为遵守“只使用转写中出现的事实与数字”的要求，本文不额外引入 Omnigent、LTAP、HTAP、Lakebase、Delta、Iceberg、DBRX、Snowflake 或 Neon 的外部资料。尤其是原稿省略的 24:46—52:47 区间，只保留用户提供的章节锚点与后文可以交叉确认的内容，不对技术机制进行外推。

争议与需核实

1. Omnigent 的拼写与正式名称。 转写中同时出现“Omnigent”“Omnigentt”等形式，需要以正式项目页面为准。

2. “400 merge already?”的统计含义。 可能指已合并 PR、提交或其他项目活动；转写语句不完整，不能直接视为精确的外部贡献数。

3. 峰会 100,000 人、线下 30,000 人。 这是主持人给出的 headline number，需核实是否包含直播观看、注册、合作活动或累计参与者。

4. 每天启动 5,000 万至 6,000 万台虚拟机。 需要确认“launch”统计的是独立 VM 实例、短生命周期任务、容器化计算单位还是其他抽象。

5. Neon 每天启动 1,300 万个数据库。 需要确认是数据库实例、分支、计算端点还是启动事件，以及是否包含 Agent 自动实验产生的短时资源。

6. 文档视觉模型“便宜 100 倍且更好”。 未提供模型名称、数据集、质量指标、前沿模型版本、价格口径与延迟指标，不能视为普遍结论。

7. 开源自训练管线超过 Opus 与 GPT 5.5。 没有披露具体任务和评估方法，只能理解为某一特定任务上的内部结果。

8. “AGI is already here”。 这是 Ali 的观点性说法，转写未提供 AGI 定义、评估标准或能力边界。

9. Databricks 已“客观超过”Snowflake。 主持人没有提供财务、客户、工作负载规模或产品性能证据，不能当作已被本期证明的事实。

10. 中段数据库论述不完整。 LTAP、CDC、HTAP、Lakebase、Parquet、Dream Engine、向量数据库和查询引擎的主要讨论位于缺失区间。若要评估其原创性、性能或与现有数据库范式的关系，必须回听原始音频。

11. Ben Horowitz 的估值表述。 “不应以 100 亿美元出售、应价值 1 万亿美元”是节目中的口头转述，不是正式估值文件或投资建议。

12. “数据到位，再放一个 Agent 就会产生魔法”。 这是方向性概括，不能替代对事务一致性、责任边界、错误恢复、审计与人类审批的逐项设计。

行动建议

对 Agent 平台工程团队

1. 把模型和 harness 视为可替换依赖，优先定义稳定的会话事件接口：消息、文件、工具调用、流式输出、取消和状态恢复。
2. 不要只提供聊天窗口；同时考虑持久沙箱、shell、日志 tail、文件浏览、Markdown 渲染、历史搜索与多人共享。
3. 记录端到端 traces，并让 traces 同时服务故障分析、模型对比、费用统计、策略判断和后续训练。
4. 避免只做静态 allow/deny 权限；把敏感数据读取、第三方包安装和外部发布组合成会话级风险规则。
5. 为每次会话设置可配置预算，并在接近或超过阈值时暂停任务、解释当前状态并请求人工批准。

对企业安全与治理团队

1. 盘点 MCP server 和工具集合中的真实动作语义，而不是只根据 API 名称授权。
2. 把底层调用映射成“读取机密文档”“对公网分享”“修改生产环境”等高层事件。
3. 重点审查动作链，而不是孤立动作：读取、加工、外发组合后可能产生与单次调用完全不同的风险。
4. 明确哪些状态需要跨 turn、跨工具甚至跨 Agent 保留，避免每个请求都被当作无历史事件。
5. 对自动安装 npm 包、批量读取内部文档及生产发布设置更强的审批和审计机制。

对数据平台负责人

1. 评估数据格式是否允许不同查询引擎、模型和 Agent 工具访问，避免将长期数据资产绑定在单一执行层。
2. 区分适合开放标准化的接口层与必须由运营团队保障的托管服务层。
3. 如果准备引入企业 Agent，先检查数据是否实时、可发现、可授权、可追踪，而不是只比较模型榜单。
4. 保留查询历史、表布局与运行表现，因为这些记录可成为新查询引擎、优化器及专用模型的训练和评估材料。

对模型与应用团队

1. 不要默认所有任务都应调用最大的通用模型；对文档解析、结构化提取和高频编码子任务测试专用模型。
2. 比较模型时同时记录质量、调用成本、延迟和结构化输出稳定性。
3. 用统一接口隔离外部模型，确保模型更换时不必重写整个应用。
4. 在使用 RL 或合成数据前先建立明确 eval，防止系统只在模糊的内部任务上宣称“超过”通用模型。
5. 对任何“便宜 100 倍”“超过 Opus/GPT 5.5”的结论索取任务定义、样本、基线和完整评估口径。

来源

• reused_en_transcript
• latent.space
• 音频
• YouTube