为何前沿生态系统必须开放 — Matei Zaharia 与 Reynold Xin，Databricks

对，我记得 Reynolds 说过，因为我做的第一个原型只是和你的 agent 聊天，他说，我必须能打开一个 shell，就像我自己的 shell 一样，能列出文件、用 tail 查看文件之类的。

对，它确实有这个功能。

查看我的日志。

嗯，对。

还有一件事，我记得我问过，我还在用 Cursor，唯一目的就是渲染 Markdown 文件。

嗯哼。

对，所以我说，给我一个能查看 Markdown 文件并正确渲染的方式。我就不需要单独的工具了。对。

我觉得你也把这个功能做进去了。对，我们确实做了。对，我们有很多工程师在搭建自己的 Vibe coding 环境，但他们都说，嘿，我给自己做了个很棒的东西，但团队里其他人用不了，因为没有服务器来协作。这就是为什么我们尝试搭建 Omnigen，让你能有一个服务器，并在里面做好安全设置。比如用 Google 登录之类的，然后安全地共享内容。我们也在很多其他 agent 上看到类似情况，人们以为自己原型了一个很棒的 agent，但因为安全团队的原因，它无法连接到一些非常重要的数据。

对，它确实有这些组件来配合工作。很多操作实际上发生在你部署 agent 的那台机器上。所以无论你上面有什么，都能运行。但我觉得，这是你托管协作 agent 并拥有那个服务器所需的最小配置。我们开源它的一个原因是，任何构建 agent 的人都能以此为基础开始，并自定义它。我们在 Databricks 也看到了这种情况。有人做了一个不错的 agent 应用，然后其他团队会问，我能不能直接用你的来跑我的 agent？

对，我记得我们有五六个不同的 agent 框架，每个团队都做了一个。它们做的事情大同小异。

对。所以，开源的一个原因是，如果你认为它是一个能产生网络效应的层，能从多人协作中受益。比如 Spark，我不知道你是否了解，Spark 刚出来时，我们也很注重让你能在上面加库。以前有各种不同的分布式计算引擎，用于机器学习、图计算等。我们说它们都应该成为可组合的库。我们还让添加数据源连接器变得非常容易。然后我们受益，因为我们没时间写连接器去连上千种不同的数据库和文件格式，但我们可以直接用别人做的。当然，他们也从加入这个生态中受益。所以这是其中一个原因。另一种思考方式是，想象一下，如果我们的东西不是开源的，我们有一个 agent 托管服务，但不是开源的。而同时有一个开源版本。长期来看，哪个会赢？因为人们写集成能带来好处，所以会是那个开源的。还有一些东西你根本无法以开源形式交付，那是公司做的事。比如，你怎么确保你的流式任务或基于湖的数据库不会在夜里丢失所有数据？这需要一个运营团队来盯着。没办法，它必须是一个服务。所以我们作为公司，要确保在这些基础设施服务上做得很好。然后在你构建的上层，我们尽可能保持开放。

从收益角度来说，我觉得我们已经看到了各种生态集成的 pull request，尽管它周六才发布。

对，周六。对，所以有人——我们看看情况。我今天早上还问 Samnijan 关于——

已经 400 个合并了？

对，我觉得大概有一半不是我们团队的。比如，有人添加了在 Kubernetes 上运行的支持。很多人添加了云沙箱。这样就能启动一个云沙箱，在里面运行你的 agent，这对共享也很有好处，因为不是在笔记本上，别人跑一些危险的代码。对，很多初创公司已经把这些加进去了，我们预计还会有更多。我们还有更多的 agent 框架，Cursor、CLI 和 Antigravity 也都有了。

我觉得现代数据栈其实挺有用的，可能直到今天也还是。对于不了解历史的观众，现代数据栈实际上分解为：你需要一个层来摄取数据，一个层来转换数据，所有这些都运行起来，然后还需要一个层来可视化数据。所有这些都运行在某种数据仓库上，后来我们做数据仓库时，也用了 lakehouse。我觉得这些概念都非常强大和有用，支持了很多工作负载。人们最终遇到的问题，是一个统一和整合的问题：嘿，你真的需要把所有东西切成不同的碎片，和那么多不同的供应商和平台打交道，才能做一个非常简单的可视化吗？对吧。所以我觉得，随着时间的推移，大家都开始意识到客户在推动我们。我们也开始意识到这一点。所以我们开始构建越来越多的能力，并尝试整合。最终，客户不用再担心为了生成一个图表而连接五个不同的系统。但我觉得，类似的事情可能正在发生。你需要把多少个不同的框架拼在一起，才能做一个非常简单的 agent？

先说明一下，我认为核心是在所有工具链之上构建一个通用 API。这个 API 大致就是：你有一个 agent 会话，可以发送消息或文件，基本上就这些输入，然后你会收到流式输出，可能是流式文本，也可能是工具调用。另外，你还可以发送取消或切换指令。这就是 API 的概貌。我们做的是，让这个 API 能跑在终端里的 Claude Code、Codex、PyOpenAI SDK 等各种工具之上。我们把它们都映射到同一个接口。如果你自己构建 agent 编排器，这部分就需要你自己维护。一旦 Claude 改了 API，你就得调整自己的东西，还可能会丢失一些消息。所以，维护这个统一接口是有价值的。在此基础上，我们还构建了几个应用。我觉得我们做了一个挺酷的 UI，还有安全与控制模块，这个我比较兴奋，但核心还是那个通用接口。它并不试图成为一个完整的堆栈。实际上，你可以在我们的服务器之上接入自己的 UI。这是我们非常关注的一个用例，因为我们想在自己的产品中使用它。

没错。

我觉得他后来没正式发布过。我们的沙箱方案之所以能快速构建，是因为我们意识到，如果直接采用基于 Lake 的架构，去掉数据库部分——顺便说一句，这个想法来自——完全正确。

每个数据库本来就需要这个。没错。

不过也有一些区别。例如，为了支持这种特定工作负载，本地持久化很重要，因为你希望状态能持久保存。你的库文件不需要每次重新安装，对吧？而 Neon 的架构由于存储与计算分离，不需要本地持久磁盘。所以有些差异，但归根结底，是的。

这就是运行编码沙箱时的场景。比如我用它，我们在 Databricks 内部有开发基础设施。光是源代码和构建产物就有几十 GB 的数据。我希望下次还能找回这些数据。

在分析侧，我们每天大概在三大云上启动 5000 万到 6000 万个虚拟机。所以，在 CPU 计算方面，我们肯定是最大的计算编排器之一。

嗯——

所有这些流程处理的数据量，我开玩笑说，取决于你在哪个时区，通常在你吃早餐之前，Databricks 当天已经处理了 EB 级的数据。Neon 那边也很有意思，现在每天启动大约 1300 万个数据库。

是啊。

其中很多要归功于 agent 和分支实验。因为我们让数据库启动变得极其简单和快速。这要感谢 Nikita 的团队。它正在改变人们使用数据库的方式。

我花了不少时间与内部用户、开发者、安全团队、经理以及大量客户交流。有几个发现。首先，很明显的一点是，安全方面存在可用性与安全性之间的张力。现在很多编码 agent 只有非常基础的控制，比如你可以设置允许或禁止哪些工具模式，就是简单的“是”或“否”，但这会让你陷入两难。举个例子：我的 agent 能不能读取机密文档？或者，能不能从 npm 安装新包（这个包可能已被攻破）？是或否？也许我想允许。我的 agent 能不能发布内容到公司网站？如果我用它来编写网站代码，那可以。但它能不能同时做这两件事，比如抓取机密文档，然后被 prompt 注入并泄露出去？大概不行。所以我们决定需要的是有状态的，或者说我们称之为上下文策略，即跟踪会话的状态。不是简单地“是否允许推送到营销网站”，而是“如果它做了风险操作，比如安装了一个刚发布一天的 npm 包，或者读取了 1000 份机密文档，那么就不允许；否则，也许可以”。这就是一个调整权衡的例子。通过一个更强大的引擎，它既更安全，也更有用。这需要跟踪会话。另一个有趣的点是，agent 在执行非常底层的事件，你需要一些库来解析它们。比如，我们在内部有一个 Google Drive 的 MCP 服务器，它有 60 个 API 调用。我怎么知道哪些会向互联网共享文档，哪些不会？这很烦人。所以我们在 Omnigence 中设计了策略层，使其可运作，并且你可以有库。比如有人可以做一个映射，把底层事件映射到高层事件。然后你针对这些高层事件编写策略。这跟 Panther 有关。Panther 会有所帮助。Panther 在事件处理方面有类似的想法，而且它是基于 Python 的，而不是某种奇怪的自定义语言。这更偏向实时处理。我不知道他们在这方面是否擅长。是的，在事件发生时处理。所以，这些都是很酷的东西。我认为上下文或有状态的部分，以及库的方式，是亮点。这也是我们将其开源的原因之一，因为其他人会编写库，我们和我们的客户都可以使用。最后一点，因为它是有状态的，我们跟踪的一个状态是你在该会话中花了多少钱。比如，我让 agent 调试一个问题，它花了 500 美元，因为它决定读取大量日志文件并消耗了很多 token。但我可以直接说，启动一个子 agent 来做这件事，并限制花费 5 美元，如果需要更多就请求我许可。因为我们在会话内计数，它会弹出来告诉我，你已经花了 5 美元。

你想继续吗？这里有个重要背景。Matej 过去 5 年大部分时间在 Databricks 负责 Unity Catalog 的架构设计，那是数据治理层。

没错。是的。是的。

他在那个层面上把专业知识与所有AI治理工程师结合了起来。

是的。但我也花了很多时间被编码代理惹恼，还要处理各种提示。而且作为CTO，我可不想因为安装了某个奇怪的npm包导致代码泄露而登上头条。所以我特别多疑，但时间又非常有限。我不想坐在那里审批，比如“你想运行一个20行的Bash脚本吗？是还是否？”所以这就是为什么我花了很多时间琢磨，怎样才能让它既尽可能安全又不烦人？是的。

哦，是的，两者都存在。我的意思是，我不知道。我想这取决于你是什么类型的公司。所以我认为有些公司预算有限，他们真的很在意这个。

是的，完全同意。是的，是的，是的。我的意思是，对我们来说，作为云服务提供商，安全绝对是至关重要的。这是最重要的事情。至于token最大化，我们目前还不太担心，但我看到过，比如，我和一些咨询公司聊过，他们有10万名员工都在为客户编码，如果每个人每月多花1000美元，那可不是闹着玩的。我们只有几千名工程师。

是无限的，但我们确实会使用自己的产品来分析追踪数据之类的。我们有一个团队负责优化，并查看是否有人在做什么奇怪的事情。实际上，通过分析当前的追踪数据，我们得到了一些非常酷的见解，比如哪些模型在Rust或TypeScript等方面表现更好。所以，是的，至少在我们的代码库中是如此。是的。

是的。是的。我们希望让工程师使用起来非常简单，你只需要设置好就行。所以在Omnigence中，你可以让你的代理为自己设置一个策略来执行这个操作。

哦，是的，在文档里，你可以稍后查看。如果你想看，只需在文档中查找上下文策略。我只是想引导人们——看看内置的策略。是的。

是的。是的。是的。这些策略的由来是，我写了一个文档，里面列出了10个想法，都是在你开发之前就有的。那基本上是我希望人们提出的愿望清单。我告诉团队，嘿，你们能不能至少完成其中的5个，然后他们就把所有10个都做完了。

所以你可以想出更多，但其中一些只是作为示例。实际上，你可以拦截代理发出的任何事件，然后你可以选择阻止、强制它询问用户，或者允许，并且你可以更新状态来跟踪信息。

是的，是的。我们也很注重可组合性，比如其他人能否编写一个库供他人使用，这正是它的设计目的。

这里还有一种“电池包含在内”的理念，可能和你做Spark的方式非常相似，就是你拿来就能直接用。

是的，没错。它必须在某些方面开箱即用，然后你可以在上面构建你自己的东西，那些我们不想做的事情。但是，你知道，在Spark中，如果你只是想，我不知道，读取一个表或做聚合操作，它应该开箱即用就非常出色。

是的。

是的，请加入Discord和GitHub。我们的团队在那里，会进行监控，有些人们要求的功能，我们自己就构建了。有些，你知道，我们会和他们合作构建。同时，也请告诉我们你希望如何使用它，因为我认为尤其是对于开发者来说，每个人都希望它按照自己的方式工作。一个真正好的开发者工具，你必须听取各方面的反馈，并找出抽象层以及如何让人们进行定制。所以，如果你觉得“嘿，我不想让它以这种方式工作”，请告诉我们。我们真的只是想获得跨代理的兼容层，然后让你在上面做各种事情。

哦，针对初创公司？

我的意思是，作为一个拥有很多工程师的公司，任何能帮助我了解人们如何使用编码代理和花费情况的东西，以及质量，比如“你应该添加这个技能”或“你应该写这个”，或者“你的代理在处理涉及这个服务的任务时表现非常糟糕”。所以，去花时间做这个，那会很好。是的。

哦，酷，是的。

是的，我认为那里会有很多见解，你在其他领域也有这种情况。

是的，是的。LTAP的想法其实很简单。如果有人听过Ankur关于HTAP的演讲，那基本上就是数据库的世界。抱歉，这里可能需要注入很多背景信息。

这是最重要的基础系统技术之一，但数据库世界实际上大致分为两半。一边是我们所说的 OLTP 数据库，也就是事务型数据库，比如 Postgres、MySQL、Oracle 这类。另一边是分析型数据库，有时也叫 OLAP。区别在于，在 OLTP 中，你通常执行某个事务或事件，查找某一行，然后更新那一行，对吧？这是一种非常面向行的数据结构。而在分析型中，你要对数据进行推理，你要计算，比如每家店的收入是多少？我的网站每天表现如何？最终你可能还想在上面跑机器学习，来预测未来的销售趋势。这两种架构非常不同，每个人都是从 OLTP 数据库开始的。每个应用，当你做得足够认真时，如果它需要的不仅仅是 Markdown 文件，你就需要一个数据库。你不想丢失数据，你需要一定的事务一致性。但一旦你想对数据进行推理，如果你只有 100 行数据，在 Postgres 或 MySQL 上跑可能还行。但一旦数据量变大，你想做更复杂的分析，这个分析本身可能就会压垮你的 Postgres 数据库。所以你就开始把数据从复制中取出来，复制到分析系统中。

是的，有些人确实会用 Elasticsearch 做日志分析。我们很多客户显然会用 Databricks 来跑更复杂的东西。还有一个术语叫 CDC，也就是变更数据捕获。它的作用是读取数据库的 binlog。如果你不懂 binlog 是什么，没关系。但它实际上是数据的一个小增量，然后基于这个增量在分析端重建数据库的状态。但 CDC 是一件非常痛苦的事情。它基本上是行业标准，每个人都在用。但最终的结果是——我觉得很多数据工程师最后会在凌晨 3 点醒来，因为某个管道出了问题。

没错，CDC 是一件非常——它是最无聊但也是最基础的操作之一，支撑着现代社会。但它太脆弱了，我们开玩笑说它应该叫"持续数据损坏"，因为你可能在 OLTP 数据库上改了 schema，然后 CDC 管道处理不了 schema 变更，一切就都乱了。

但总的来说，这非常复杂。我在主题演讲时问观众，谁喜欢他们的 CDC 管道，举一下手。大概只有两个人举手。所以 SingleStore，大约十年前，我觉得行业里有了一个想法：如果我建一个能同时处理两种工作负载的数据库呢？

这是数据库工程的圣杯。为什么不建一个能同时做这两件事的系统呢？但最终往往需要做很多妥协。第一个问题是，Postgres 有庞大的生态系统，对吧？你想用为 Postgres 构建的工具。而 Spark 也有庞大的生态系统，有很多库你想用。如果你现在创建一个新东西，你没有生态系统。你往往会创建一个新的、较小的专有 API，两边都缺。而且也很难在性能上做到与任何一边相当。所以最终两边都做不好。我们整个 LTAB 的概念，其实是对 HTAB 这个词的文字游戏，我们认为这是 HTAB 的正确做法。HTAB 想为两者建一个统一的引擎。我们认为，通过统一存储层，你可以获得 99% 的需求。一旦有了统一的存储层，如果你的 Postgres 数据库以列式格式写入数据，那么所有分析工作就可以直接读取这些数据，没有任何延迟，对吧？中间没有管道。所有数据都会立即可用于推理分析。我之前跟一些客户说，当我们讨论这对 agent 会非常有用时，我一开始自己其实也不太信，尽管我们写了那样的定位。但昨晚我和一个澳大利亚客户吃饭，他们告诉我，我们有一个大问题，就是有来自服务订单的所有日志，我们看到 SLA 下降，想调查原因。但 agent 根本无法理解实际数据库中发生了什么。我们只能看到数据库和服务的产品遥测数据。如果 agent 能理解，比如谁在下这些订单，发生了什么，他们在做什么，那它们会强大十倍。所以现在我自己也被我们的信息说服了。我觉得这基本上能让你获得 HTAP 圣杯的几乎所有好处，也就是让数据立即可用于推理分析。

对。

对。

我记得我们数据库出问题的时候，工程师说，我不能在上面跑一个巨大的查询来看发生了什么，因为那会把数据库拖垮，让情况更糟。这就是 LTAP 能解决的问题，因为你启动了一整套独立的机器来做分析，不会让主数据库过载，对吧？主数据库还在努力提供服务。

对。

我之前和Meta的一个人聊，他问我，嘿，有什么诀窍？为什么现在能实现？我觉得实际情况是，我们花了大量时间在基于湖的架构上。显然，很多思路来自Neon团队，也就是存储与计算分离。结果发现，从那个架构到LTAP这个想法，其实只差一小步。在Neon架构和基于湖的架构中，我们以行导向格式将数据写入开放数据湖，但用的是Postgres页面。实际上，Aliya和我花了很多时间争论：我们能不能改成用列导向格式写入？我们一直在讨论，直到有一天，我们一个非常聪明的工程师过来说，嘿，我其实已经做了原型——等等，原型什么？——原型就是，不再以行导向格式（比如Postgres页面）把数据存到数据湖，而是用Parquet格式写入。他观察到，我们的存储集群有很多闲置的CPU，可以用这些CPU来做从行到列的转码，行格式适合OLTP，列格式适合分析。所以我们就决定在那时做转码。事实上，一旦你转码了数据，压缩效果会更好。所以，从那些写入S3或其他数据湖（对象存储）的服务来看，写入速度反而更快，因为数据变小了。没错，所以没有额外开销，性能上也没有妥协。

但我们本来就有多余的CPU。

反正集群里也有闲置资源。

所以争论就结束了。这算是技术问题的一个经典案例：争论了很久，但有人直接去试了原型，结果成功了。

他就是在很多会议上和我们争论，我们从基本原理出发讨论是否可行，然后，嗯，有人就直接动手做了。

是啊，如果你营造出让人能这么做的氛围，那就太好了。Omnigen也有类似的情况。我觉得如果我写个文档说“我们可以把这些整合起来”，大家都会想“那这个怎么办？那个怎么办？”但如果你直接试一下，效果就好多了。而且如果有真实用户去测试、去挑战，它还能正常工作——或者在这个例子里，如果你有实际的工作负载，你知道工作负载长什么样，你就可以直接测试同样的模式。

直接去做就行，尤其是现在这个时代。我觉得有了AI，构建东西其实更容易了。你这样的人很少见。

怎么做到的？我觉得我们招聘和合作的人非常优秀，这是很重要的一点，同时也要给他们赋能。而且，我们自己也花大量时间深入一线，这也很关键。

对，我觉得首先，人们能适应在大公司工作，这就有帮助。我们要确保他们知道可以尝试新东西、解决争论，并且有很多先例可以参考，或者直接发布测试版。另外，作为一家公司，尽管规模不小，但我们推出的产品并不多，我们尽量保持产品线的连贯性。这其实是公司的整体理念：与其像亚马逊那样搞20个服务让你自己搭分析和机器学习栈，不如只用一个。所有服务共享同一套API、同一套语义、同一份数据。这需要统一。然后我们一次只加一个功能。我们先加了Delta Lake做存储（之前我们不做存储），然后加了SQL，接着加了机器学习平台相关的东西。但没错，不要做太多，而是把每件事做好。这也有助于让一切保持可控。

对，我们另一个大力提倡的做法是，不要试图一次性解决所有问题，而是想怎么增量地做？怎么快速推进？比如我们的很多产品，都是在几周内构建出来的。然后我们会问——实际上，我每次问团队的第一个问题就是：目标客户是谁？你和他们有没有直接联系？有没有在发消息沟通？我觉得保持这种紧密的反馈循环很重要——

Omnigent本身就是这么来的。

嗯，Omnigent其实更偏向内部工具，因为我们用它来服务开发者。基本上整个AI团队都能访问并使用它。我们从一开始就确保它能处理我们内部的代码库，那是一个巨大的单体仓库。我们给他们提供了一些基础设施和大量的token容量。所以用户就是所有开发者。对，还有其他例子，我不太确定。

这应该是个公开的故事，但我想说Marketplace、Open Sharing这些产品也都是这样。我只是不记得具体哪些是公开提到过的。

公司很早期的时候，我们做了Delta Lake这个事务性存储层。当时我们最大的客户说，我需要一个云上的东西，因为如果我们的网络其他部分被攻破，这个系统需要独立出来存储和查询事件。然后他们跟我们沟通，说这是每秒的事件速率，这是我希望的数据新鲜度，你们能做到吗？那比我们当时任何工作负载都要大得多。我们的工程师Michael Armbrust专门负责这个，他努力让这个方案跑通。一旦为那个客户跑通了，对其他客户也就没问题了。对，那是公司早期，大概成立四年左右吧。2018年？嗯，2017、2018年。你有更好的例子吗？还有——

也许你还有别的。比如Clean Room，它让你在不共享底层数据的情况下共享数据，只允许特定操作。这个功能最初其实只针对两个客户。行业里有一种看法是，如果过度适配一两个客户，对你很不利。但我认为过度适配的坏处远小于它带来的好处。如果你野心太大，想一次性解决所有问题，那才是更大的问题。对，因为你最后可能一个客户都没有。

但我们可能面临的一个挑战——也许很多新一代AI公司也会遇到——是科技公司和非科技公司或传统企业非常不同。如果你只针对科技公司优化一切，在扩展到非科技公司时可能会遇到各种困难。

治理是一个大问题。

我觉得，对，一个大问题是，嗯，安全，你知道，数据隐私、治理，所有这些。所以通常如果你在构建某种B2B或开发者工具，你最大的市场会是企业，但这非常不同。一家已经存在了比如30年、有某种IT形式的公司，它们有那么多遗留系统，或者在受监管的领域运营；而一家初创公司，甚至像比较新的科技公司，一切都是新的、干净的。所以，嗯，就是不一样。如果你没跟企业合作过或没在企业待过，你就不会了解这一点。

采购流程可能也大不相同。实际上涉及的利益相关者要多得多。

这是一个。嗯。另一个有趣的点是，我觉得有些科技公司，人们会说，“哦，我可以自己建这个，对吧？我就自己建。”然后你会想，但我觉得没人会这么说Databricks。嗯，他们会。他们确实会。嗯，我是说，嗯。这取决于团队和情况。但另一方面，很多企业实际上，我从不，我永远不想做建这个东西的生意。比如，我不想我的，你知道，不管怎样，我是个零售商之类的。我永远不想因为某个奇怪的技术宅搞不定流式管道而宕机。那不是我在做的事。

但你必须明白，没在那里工作过是很难理解的。你可能体会不到。

听着，我觉得他们都很好，别误会，他们有不同挑战，但很多科技公司，当然有很多，DIY（自己动手）的倾向强得多。

另一方面，有些人非常精通自己的领域，比如他们在造飞机、设计药物之类的，他们只想要一座通往技术的桥梁，不想学数据库什么的，不管我们觉得这多酷，甚至普通软件工程师可能觉得读一点挺有趣，但他们就是不想知道，他们只会说，“我有一个巨大的矩阵，里面是我的临床数据，我怎么聚类它？”所以，嗯。对，确实如此。

所以我们大概几年前意识到的一件事是，实际上每个数据库引擎，尤其是在分析领域，差不多都有十年历史了，几乎所有有一定市场影响力的都是大约十年前开始的。它们最初都针对一些非常具体的狭窄用例。然后随着时间的推移，它们越来越成功，野心也变大了，试图支持更多用例。但支持这些用例最快的方式往往是在最初为其他用例设计的抽象层上打补丁。然后，你大概能勉强支持它们。不知不觉，经过十年的有机演变，它就变成了一堆巨大的烂摊子。顺便说一句，这包括Databricks。我认为很少有公司或系统有勇气说，“让我们从头开始吧。让我们回到绘图板，重新设计，利用我们这十年积累的工作负载和可能数十亿美元收入所知道的一切，尝试从头重写，并确保它能工作，然后支持所有这些用例。”所以我们开始这么做了，但这是一个非常雄心勃勃的项目。顺便说一句，你可以在维基百科上搜一下，有个概念叫“第二系统综合征”。嗯，我知道。

每个开发者都必须知道什么是第二系统效应。基本上，你建了第一个系统，效果很好，第二个注定会失败，因为你变得太雄心勃勃，问了太多问题。

对，结果它并不完美，然后开始失败，你太雄心勃勃，永远无法发布，然后就被干掉了。而实际上开始这个项目的工程团队非常出色。我觉得我们雇了地球上最顶尖的数据库工程师到Databricks，他们非常出色。谢天谢地，这不是他们的第二个系统。他们很多人过去已经建过不止两个了。啊，不错。但他们仍然担心这个。嘿，从头构建一个数据库引擎，传统观点认为需要五年才能成熟。这会是一个非常长期的项目。它可能会失败。我觉得有个工程师开玩笑说，“嘿，也许我们就叫它Randall Stream Engine。如果以联合创始人的名字命名，也许它就不会被取消或干掉了。”但我认为他们建了非常了不起的东西。他们回到了——他们从范式角度改变了数据库引擎的构建方式。通常建数据库引擎时，你会读很多学术论文，试图理解最新的算法和数据结构，然后把它们拼在一起，看看能不能工作。这也有很高的失败风险，因为纸上看起来很好的东西可能在70%的工作负载下表现很好，但在另外30%上会适得其反。他们实际上建了一个更像“数据库工厂”的东西。所以他们花了更多时间建这个工厂，而工厂利用了我们十年的追踪数据。他们——他们统计了追踪表中有千万亿个数据点。你什么都不丢，还是采样？

那是海量的东西。然后，嗯，他们用这个来建一个模型，嗯，一个机器学习模型。不，不，一个机器学习模型。机器学习模型基本上能非常快速地告诉我们，任何算法和任何实现对于任何特定类型的查询会表现如何，具有非常高的模态性。基于此，他们可以选择最有可能帮助不同工作负载的算法和数据结构，无论是在运行时还是在实现时，因为有无穷多种——

对，我是说，如果你想想，这不是一个数据库，它有很多独立实现的东西组合在一起，但你要确保它们都能很好地协同工作。然后对于任何给定的操作，可能有不止一种实现。所以我们让它运行得非常好。而现实是，那些在非常低延迟下表现极好的算法，可能不适合扫描PB级数据。对，没错。实际上，通常在吞吐量和延迟之间有一个权衡。

嗯，还有数据的分布，对吧？数据有多稀疏，这很重要。嗯，你访问同一数据的频率如何？

对。还有不同值的数量之类的？

这些东西很重要。比如不同值的数量基本上会影响你的聚合、哈希的内存消耗。在某个点上，会有一个哈希表。

我觉得如果你真去列，可能得有上百万种不同的特征。

但让我给你举个很奇怪的例子，它实际上对性能有深远影响——比如你的字符串是纯 ASCII 还是包含 Unicode？应该怎么编码？

对，所以举个例子，如果字符串的取值非常密集，你其实可以把每个字符串都转换成一个数组索引。想象一下，你要做聚合操作，不用哈希表，直接用数组查找就行，因为如果只有 256 种可能，你根本不需要哈希表。嗯，我想还会有——

比如国家代码之类的。

对，对。所以这个模型里可能真的有上百万个特征，但利用这些特征，他们可以优先判断哪些算法在实际中会有影响。其中很多结果非常反直觉——你以为效果很好的东西，实际表现并不好；但更重要的是，在运行时，你可以分派正确的算法和数据结构。

或者说我们设计时就考虑到了渐进式。首先我们会发布一个新端点，但这会面向更广阔的领域。而我们真正想做的，是让这个新引擎在设计上能完成之前所有功能，并且做得更好。这个"更好"特指极低延迟——能在几十毫秒内完成的工作负载。但我们希望以渐进的方式推出，逐步增加能力，这样就不用花五年时间才看到隧道尽头的光。

向量数据库本来就不该是一个独立的类别。

我认为 LTAP 的核心理念是：我们不是在查询层合并数据库，而是在存储层合并。这是非常重要的一点。而且我们确实认为，把查询层合并成一个像 HTAP 那样的单一数据库是没有意义的。另外，很多人觉得最好只有一种查询语言需要操心，不用在 PostgreSQL 和 Spark SQL 之间切换，为什么不能统一？但我不认为这对 agent 是个问题。Agent 在 PostgreSQL 或 Spark SQL 上都很擅长，只要数据在那里并且可访问，它永远不会搞混。Agent 能做得很好。五年前这对人类可能是个问题。

这个问题未来也可能出现，但这也说明了如何渐进式地做事，对吧？我们意识到现在不需要它，我们不需要解决那个问题就能从当前的 LLM 中获得很大价值。

最大的根本区别可能是：两家公司差不多同时起步，都上了云，都专注于存储与计算分离的架构。但最大的不同是，一个是开放的。Databricks 从来没有专有格式，对吧？我们从开放生态系统开始，从 Parquet 起步，然后演进到 Delta、Iceberg 等等。这是一个大方向。我认为这很重要。另一个是 AI。在 2022 年 10 月 ChatGPT 出来之前，我们一直把 Databricks 定位为机器学习加数据平台。很多平台功能都是围绕机器学习用例构建的。显然 AI 有点不同，Matej 在这方面花的时间比我多得多。但整个平台从未让我们觉得"我们只是个数据基础设施平台，只做分析"。

我觉得他们一开始的想法是：我们只管理最有价值的数据，并让它变得非常快。为此，他们有自己的存储，与引擎深度优化。然后只针对少量数据——比如经理、财务人员看的那种——让它超级快地提供服务。那是一个不同的领域。而我们一开始是做批量处理和数据摄入。你有一堆 JSON 日志文件，不管是什么，我们处理那种大规模的数据。因为 Spark 就是为此而生的——大规模 MapReduce 之类的工作。然后我们把数据以开放格式保存，可能慢一点，但数据已经在那里了，下游可以消费。结果证明，从那个覆盖面广、擅长大规模摄入、成本极低的东西出发，再创建出具备速度和易用性、适合业务用户处理小数据的版本，这条路更容易走通。

对，一开始就要开放，要大范围。从某种意义上说，我们起步比他们更上游。有一段时间，我们甚至互相把对方列为合作伙伴，因为我们说，如果你把两个方案一起用，用 Databricks 做数据摄入和计算，然后用 Snowflake 提供表服务，就能获得所有可视化功能和极快的性能，这很棒。后来我们都意识到，客户在问：为什么我还需要这个别的东西？为什么我不能直接查询你的表？我们说，不，我们在这方面很糟糕，请用我们的合作伙伴来做 SQL 仓库。然后他们也意识到，等等，大量计算正在向上游迁移，数据流到另一个系统里。你必须从那里开始，必须进入彼此的领域。但我觉得我们确实是从更大的范围和开放的理念起步的，这在架构上很重要。再说回企业，如果你的公司已经存在了 30 年，你经历过被 Oracle 锁定之类的各种疯狂事。作为 CTO，你在为公司搭建未来架构时，会想选择一个开放的基础，并且希望公司里只有一种管理数据的方式。理想情况下，你不想要七种不同的系统，而开放数据格式已经赢了。

我觉得现在每个企业都想把数据放在开放数据格式里，但当时这其实很有争议。大概是五六年前？具体什么时候？Snowflake 的一位联合创始人写过一篇博客叫《明智地选择开放》，基本上是反对这个的——我觉得他们可能已经删掉了，现在只能在存档里找到。

嗯，听你说话时，我觉得必须给 Ali 很多赞誉。是的，他是个了不起的 CEO。我认为他完美结合了智商、情商、对技术的痴迷、执行力和商业头脑。而且他还是创始人，这让他更容易调动资源和执行。就这样？

好吧，我称之为没有道德底线，但我觉得 Ali 在——

哦，不，不，不。

他在很多决策点上确实起了作用，比如在分岔路口他推动了一个方向，后来证明那是正确的方向。

嗯，Mosaic 起步时，或者说后来最出名的是早期发布开源大语言模型，而且是通用模型。实际上在那之前，他们做的是别的事，主要是优化训练系统。他们有世界上最快的图像模型训练栈之类的。然后他们决定做大语言模型，这很聪明，他们在 ChatGPT 之前就进入了这个领域，所以有了最早的一批开源大语言模型。

是的。所以我们决定，尽管我们发布了开源模型 DBRX，规模甚至超过了 Llama 3，但我们真的想专注于——会有很多人发布模型。与其做通用模型（其中很大一部分配方就是投入大量计算并规模化），我们想专注于下一步：假设你有了一个非常聪明的模型，如何让它变得有用？对我们来说，这很大程度上是关于自动化，比如让它非常擅长查询数据。这就是我们的一手代理，叫做 Genie。它就像一个虚拟数据科学家。想象一下，有一个人已经对你公司里的一切了如指掌，知道所有机器学习库、所有数据库、网上所有东西，你可以直接问它问题。这是我们想先做的事。所以这意味着，与其专注于训练某种前沿模型，不如用外部模型或微调后的定制组件来构建这个系统。不过我们仍然在做不少模型训练。事实上，我们一直在采购大量 GPU 来做这件事。我们在几个地方做这件事。一是很多高用量场景中，如果你有一个专门化的模型，它比任何通用模型都要好得多。一个很好的例子是理解文档，比如 PDF、Word 文档，解析它们。如果你试过，会很沮丧，因为发给 Claude、Fable 之类的，它几乎能搞定，但总会出点错，而且超级贵，你把一张图片扔进去就烧掉大量 token。所以我们的团队构建了一个文档视觉模型，它接收一页文档，返回一个包含所有组件的漂亮 JSON。它非常有竞争力，可能比那些前沿模型便宜 100 倍，而且效果更好。这实际上是由一位来自 DeepMind 的研究员做的，他是 Adapt 的联合创始人，很早就在做大语言模型规模化，但现在专注于这个。同样，我们也在为编码代理的部分功能做专门的子代理。如果你看过 Harvey、Anthropic 和 UC Berkeley 关于顾问模型（advisor models）的东西，实际上我的一位研究生在那之前就写了一篇叫《顾问模型》的论文。我相信其他人同时也有这个想法，但这确实帮助很大。所以，我们今天在主题演讲中也展示了一些东西——Parth？哦，你认识 Parth？对，对。

他在做持续学习。Learning Bench？对，对，对。我是他的顾问之一。

对，对，它们确实很棒。所以我们正在做这方面的工作。随着我们在第一方 agent 上积累经验，我们也在与客户一起推进。我的感觉是，模型定制实际上会随着时间的推移变得越来越容易。这是我们的发现，因为基础模型更智能了，它们已经在强化学习中生成更好的轨迹。而强化学习就是从自身过去的轨迹中学习。现在合成数据生成也变得更好了，更容易了。我们已经有使用开源模型的流水线，比如同一个模型生成训练环境并自我训练，然后在某个任务上击败了 Opus 和 GPT-5.5 等模型。所以我确实认为这会加速发展。关键在于，训练的便捷性和算法本身只会不断提升。问题在于何时能进入主流——比如不再是我们之前做的那个需要硬核大语言模型研究员的专门文档解析任务，而是变得足够简单，任何人都能轻松放入一些数据并描述一个任务。

这正是我们在 Omnigent 和可组合 agent 上看到的——你可以拥有带有专门模型的子 agent，然后训练整个系统。我认为这也会有很大帮助。

是的，我同意。我认为你拥有的数据，随着相关技术的进步，你可以在自己的领域里用它做更多事情。这不仅仅关乎 AI。即使人们开始实时收集数据时，我记得所有电力公司都安装了智能电表之类的东西，所有汽车制造商也开始安装传感器和摄像头。任何技术都会让数据更有价值，并给你带来某种优势，任何能帮你利用数据做决策的东西都是如此。AI 也是一样。你有很多数据就放在那里。现在你可以让一个 agent 自动告诉你，比如，以前我发现产品某个功能坏了是因为客户投诉，现在 agent 会告诉我：“我注意到没人再上传文件了，因为他们遇到了错误。”就像你在 Rayden 身上看到的，作为一家数据库公司，因为我们拥有所有查询历史、表结构以及它们如何工作的记录，我们可以很快构建出一个新的引擎，而且它确实很好，我们有信心它会表现不错。所以我认为这是对的。问题在于具体如何落地，但我确实认为模型定制——就像萨蒂亚提到的——会随着时间的推移变得越来越容易。

是的，我们确实有，我们正在做强化学习微调服务，并且与很多客户合作。我们基本上有预览客户，还有一个叫做 AI Runtime 的通用产品，它提供按需的 GPU 集群，并附带一个软件栈，让训练变得容易。所以我们并没有——你发明了它？这个已经存在一段时间了。我们已经有 GPU 计算服务一段时间了，Mosaic 的很多技术栈都用于帮助扩展这方面。但我们发现，客户有两种类型。有些只想要 GPU 和库来输入输出数据并进行监控。这就是 AI Runtime 的作用。另一些客户则说：“嘿，你能和我一起工作，构建评估、合成数据和更前向的部署解决方案架构吗？”这就是我们正在做的。随着更多事情从定制化转向非定制化，但这就是目前的状况。

回到我们最初的问题，我认为我们的一个论点是，一旦你能把数据整理好，AI 模型已经变得相当不错了。通用 agent 也相当——我是说，阿里已经说过 AGI 已经来了。它们有相当好的推理能力。实际上，我认为很多传统软件将被这种新范式重写，那就是把数据放好，然后在上面加一个 agent。奇迹就会发生。但如果没有正确的数据，你做不到这一点。实际上，我们进入安全领域和客户数据平台领域的方法也是如此。我们在数据与 AI 峰会上发布了两个产品，一个针对安全团队，另一个针对营销团队。这些领域已经有很多现有技术。我认为我们的方法就是，一旦你把数据放进去，在上面加 agent 就会容易得多。

谢谢。也祝贺你的成功。

是的，我们很兴奋。Databricks 会参加这个会议。

他说公司应该值 1 万亿美元。你以 100 亿美元卖亏了。

我们很幸运有本。是的，他是我们的大力支持者。

非常感谢，Sweeks。