The Agent Cloud: Databricks' Vision for AI and Data Infrastructure

Databricks 正在从 lakehouse 架构演进为全面的数据与 AI 操作系统。其核心论点是，一旦数据被正确定位并可访问，现代 AI agent 的推理能力就足以重写传统的软件范式——有效地从复杂的应用逻辑转向“将数据放在那里，并在其上套用一些 agent”的模型。

Omnigent: The Meta-Harness for AI Agents

Omnigent 是一个开源的 meta-harness，旨在为各种 AI agent harness（如 Claude Code, Codex, 和 Cursor）提供一个通用的 API 和基础设施层。它解决了不同团队为相同的基本 agentic 需求构建冗余框架的问题。

The Common API and Portability

Omnigent 为 agent 会话实现了一个统一的接口，允许用户发送消息或文件并接收流式文本或工具调用。这种抽象确保了如果底层的模型或 harness API 发生变化，开发者无需重写整个编排器。

Collaboration and Persistence

To move agents 从孤立的本地工具转向企业级软件，Omnigent 提供了：

  • Persistent Sessions: 能够跨会话维护历史记录和状态，因此用户无需为了保持连接而一直开着笔记本电脑。
  • Cloud Sandboxes: 隔离的计算环境，agent 可以运行代码并在其中维护库和工件的本地持久性，而无需每次重新安装。
  • Collaborative Sharing: 基于服务器的架构，允许团队成员之间安全地共享 agent 会话和历史记录。

Agent Security and Spend Control

Databricks 认为，对于 agent，二元化的“允许/禁止”安全策略是不够的。相反，Omnigent 引入了 contextual (stateful) policies。

例如，一个 agent 可能被允许分别读取机密文档和安装 NPM packages，但如果它在同一个会话中已经读取了机密数据或安装了一个可疑的、仅存在一天的 package，那么 stateful policy 就会阻止该 agent 将数据推送到公共网站。

此外，Omnigent 还实现了会话级别的 spend controls。用户可以将 sub-agents 限制在特定预算（例如 $5）内，要求在消耗更多 token 时进行手动许可，从而防止 agent 因读取海量 log files 而意外烧掉大量资金。

LTAP: Rethinking the Database Stack

Databricks 正在引入 LTAP (Lakehouse Transactional Analytics Processing)，作为解决 OLTP（事务型）与 OLAP（分析型）数据库之间历史性分歧的解决方案。

The Failure of CDC and HTAP

通常，公司使用 Change Data Capture (CDC) 将数据从事务型数据库（如 Postgres）移动到分析系统。Databricks 将 CDC 描述为“持续的数据损坏”，因为它非常脆弱；源数据库的一个简单 schema change 可能会破坏整个 pipeline，经常导致数据工程师在凌晨 3 点被叫醒。

虽然 HTAP (Hybrid Transactional/Analytical Processing) 试图构建一个单一引擎来同时处理两者，但它往往会导致折中方案，从而降低了两种工作负载的性能。

The LTAP Approach: Unified Storage

LTAP 专注于统一 storage layer 而不是查询引擎。通过将事务型数据直接写入数据湖中的列式格式（如 Parquet），分析引擎可以立即读取该数据，而无需 CDC pipeline。

这是通过利用存储集群中空闲的 CPU 来实时将数据从行式（最适合 OLTP）转码为列式（最适合 OLAP）实现的。这种方法提供了 HTAP 的优点——推理所需的即时数据可用性——而没有单一引擎架构带来的性能权衡。

The "Dream Engine" and Data-Driven Design

Databricks 正在从头开始开发一个新的数据库引擎，以避免“第二系统综合征”和那些为了支持非设计用途而通过“打补丁”来支持用例的、拥有十年历史的引擎的技术债。

A Factory for Database Algorithms

与其仅仅依赖学术论文，团队构建了一个“工厂”，利用十年的 trace 数据——数万亿个数据点——来训练一个机器学习模型。该模型可以预测特定算法和数据结构在不同工作负载下的表现（考虑维度如 latency, throughput, 和 data sparsity）。

Runtime Dispatch

该引擎可以在运行时根据查询和数据的特定特征进行 dispatch，选择最有效的算法。例如，它可以在 hash table 和 array lookup 之间切换，如果它检测到某一列中的字符串是稠密的（例如，国家代码），从而显著提高性能。

Model Strategy: From General to Specialized

在收购 MosaicML 之后，Databricks Databricks 已经将其重点从参与“前沿模型”竞赛（通用 LLM）转向了专门的、高实用性的模型。

  • Genie: 一个虚拟数据科学家 agent，旨在成为公司特定数据和机器学习库的专家的专家。
  • Specialized Vision Models: Databricks 开发了一个文档解析模型，可将 PDF 和 Word 文档转换为 JSON。据报道，该模型比前沿模型便宜 100 倍，同时在此特定任务中保持了更高的准确性。
  • RL Fine-Tuning: Databricks 正在专注于提供“强化学习 (RL) 微调即服务”，利用了这样一个事实：更智能的基础模型现在可以为 RL 生成更好的 trace，使得创建专门的 agent 系统的过程更加 efficient 效率更高。

Sources