Databricks 押注 Agent Cloud：AI 真正的瓶颈不是模型，而是数据

当所有人都在追逐更大的模型时，Databricks 的创始人却抛出一个反直觉判断：AI 的天花板不在模型，而在数据和架构。这期 Latent Space 的对谈，罕见地把“AI Agent 为什么现在才可能落地”讲透了。

最反直觉的一句话：模型已经够好了，问题在别处

在这期对话里，最容易被忽略、却最致命的一句话是：“一旦你把数据放在正确的位置，AI 模型其实已经相当不错了——真正卡住我们的，是数据。”这和当下行业的主流叙事几乎完全相反。过去一年，所有注意力都在模型规模、参数量、推理能力上，但 Matei Zaharia 明确指出：没有干净、可控、可被访问的数据，再聪明的 Agent 也只是空转。

这也是为什么他们反复强调“fuse”这个概念——不是再造一个更聪明的大脑，而是把数据、工具、状态和权限真正接到一起。Agent 的能力，不是来自灵光一现的 prompt，而是来自它能否稳定地读数据、写状态、调用工具、并在多轮交互中不迷路。

Agent 热潮背后，其实是一次架构层的复刻

对话中有一个很有意思的类比：这波 Agent 的兴起，让人想起“现代数据栈”刚出现的那个阶段。当年大家也在尝试把一堆零散能力拼起来，而现在，类似的事情正在 Agent 世界里重演。

Matei 提到，很多人都在探索一种“meta harness”的概念——让 Agent 能在更高层次被编排、被约束、被观察。但区别在于，以前大家更多是停留在概念验证，而这次他们是“真的把它做成了一个可用的东西”。这背后的关键，不是 Agent 会不会对话，而是系统是否允许你：阻止一次行动、强制询问用户、更新内部状态、追踪长期任务。这些听起来像“工程细节”的东西，恰恰决定了 Agent 能不能进生产环境。

Agent 不是一个人，而是一群在对话的角色

在讨论架构时，有一个画面被特意提出来：Agent 之间在互相“说话”，用户也在和 Agent 交流，工具则像第三种参与者。这不是炫技，而是一种非常现实的抽象。

当 Agent 需要完成复杂任务时，它不再是一次性生成答案，而是一个持续运行的系统：某些 Agent 负责理解需求，某些负责查数据，某些负责执行操作。真正的难点在于，如何让这些角色之间的沟通是可控的、可回溯的，而不是黑箱。这也是为什么他们反复谈“结构”“状态”和“权限”——Agent Cloud 的核心，其实是治理，而不是聪明。

从“Dream Engine”到现实：为什么现在更可行了

对话中提到一个颇具想象力的概念——Dream Engine。听起来很激进，但他们自己也承认：如果放在几年前，这几乎是不可能落地的。

变化来自两个方面。第一，AI 的基础能力确实上来了，很多过去需要人写规则的地方，现在模型可以胜任。第二，也是更重要的一点：数据和计算的形态变了。有人提到，这种方式“几乎拿到了 HTAP 圣杯的大部分好处”，而代价却低得多。这并不是在炫耀技术名词，而是在强调一个现实判断：当读写、分析、决策开始在同一个系统里发生时，Agent 才有连续性可言。

这不是功能更新，而是一场平台级的赌注

在节目快结束时，讨论的语气明显变得更“辣”。因为他们其实在做一个很大的判断：Agent 不会只是附加在现有系统上的新功能，而会逼着整个数据和 AI 平台重新洗牌。

如果你的系统无法让 Agent 安全地访问数据、无法精细控制它能做什么、无法记录它做过什么，那么你最终只能停留在 Demo 层。反过来，一旦这些能力变成平台的默认配置，Agent 才可能真正成为生产力工具。这也是为什么他们对这条路线如此笃定——这不是一次实验，而是一次长期押注。

总结

这期对谈真正有价值的地方，不在于某个新名词，而在于一个清醒的判断：AI Agent 的未来，不取决于模型多聪明，而取决于系统多扎实。对从业者来说，这意味着两个行动方向：第一，别再只盯着 prompt 和模型，开始认真梳理你的数据、权限和状态管理；第二，评估你现在的架构，是否真的允许 Agent 在其中长期运行。如果答案是否定的，那问题不在 Agent，而在底座。接下来值得思考的是：当 Agent 成为“默认用户”时，你的系统，准备好了吗？

关键词： AI Agent， Agent Cloud， 数据架构， 系统设计， Databricks

事实核查备注： 需要核查：Matei Zaharia 的完整职务表述；视频的实际时长；“Dream Engine”“HTAP 圣杯”等表述是否为原话或语境性总结；引用语句的精确措辞。