DEEP DIVE · 深度研究
Databricks：从数据湖到
AI 原生操作系统
一家 Spark 公司如何用 12 年时间重新定义数据平台，并在 Agent 时代押注全栈 AI 原生架构
📅 2026-03-27
✍️ Tuntang Research
⏱️ 约 25 分钟
目录 · Contents
01 为什么要研究 Databricks
02 进化史：五次范式跃迁
03 当前全景：产品矩阵
04 Agent Bricks 深度拆解
05 Lakebase：OLTP 融入湖仓
06 Unity Catalog：治理即控制平面
07 数据工程的范式变革
08 2026 战略方向与预测
09 对我们的启示
10 总结与关键判断
Part 01
为什么要研究 Databricks
在讨论"AI 原生数据团队"时，Databricks 是一个绕不开的案例——不是因为它的市值（虽然也很惊人），而是因为它是全球唯一一家从"大数据计算引擎"出发，一路进化到"AI 原生操作系统"的公司。这条路径的完整性，使它成为理解"数据平台如何 AI 原生化"的最佳样本。
$54 亿
年度营收运行率（ARR, 2026.02）
更重要的是，Databricks 的进化历程几乎完美地映射了数据行业过去 12 年的范式变迁：从 MapReduce 到 Spark，从数据湖到 Lakehouse，从 BI 到 AI，从 AI 辅助到 Agent 自主。研究 Databricks，本质上是在研究数据行业本身的进化。
研究目的：本文不是 Databricks 产品推介。我们关心的核心问题是：一个数据平台要完成"AI 原生化"的转型，需要在架构、产品、治理、组织四个层面做哪些关键选择？Databricks 的答案是什么？这些答案对我们自己的数据团队有什么启发？
Part 02
进化史：五次范式跃迁
Databricks 的故事始于 2013 年，由 Apache Spark 的创始人 Matei Zaharia 和他在 UC Berkeley AMPLab 的同事们创立。从那时起，公司经历了五次清晰的战略转型，每次都踩在了行业拐点上。
2013-2017 · 第一阶段
Spark 即平台：统一计算引擎
将 Apache Spark 商业化，提供托管的 Spark 集群服务。核心价值是"比 MapReduce 快 100 倍的统一计算引擎"，解决了 Hadoop 生态碎片化的问题。这一阶段 Databricks 的身份是"大数据公司"。
2018-2019 · 第二阶段
Delta Lake：掌控存储层
开源 Delta Lake，在数据湖上增加 ACID 事务、Schema 管理和时间旅行。这一步至关重要——Databricks 从"只做计算"扩展到"计算 + 存储"，开始构建完整的数据栈。
2020-2022 · 第三阶段
Lakehouse：消灭数据仓库与数据湖的边界
提出 Lakehouse 架构范式——在数据湖的基础上，提供数据仓库级别的性能和治理。推出 Photon 引擎（C++ 重写的向量化执行引擎）、Unity Catalog（统一治理）。公司身份从"大数据公司"变为"数据平台公司"。
2023-2024 · 第四阶段
Data Intelligence Platform：AI 嵌入平台
收购 MosaicML（$13亿，LLM 训练）。推出 Mosaic AI（模型训练 + 服务 + RAG + Agent 框架）。发布 DBRX 开源 LLM。核心叙事变为"数据智能平台"——AI 不是附加功能，而是理解数据的方式。
2025-2026 · 第五阶段
AI Native OS：Agent 原生操作系统
2025 Data+AI Summit 宣布全面转型。发布 Agent Bricks、Lakebase、Databricks One、Lakeflow Designer、MLflow 3.0。公司身份正式升级为"AI 原生操作系统"——整个平台以 Agent 为核心重新设计。
进化逻辑：注意每次跃迁的模式——Databricks 不是在做"加法"（在老平台上加新功能），而是在做"重定义"（用新范式重新理解整个平台的角色）。从"计算引擎"到"存储+计算"到"Lakehouse"到"数据智能"到"AI 操作系统"，每一步都是对"数据平台是什么"的根本性重新回答。
关键收购时间线
| 年份 | 收购目标 | 价格 | 战略意义 |
|---|
| 2023 | MosaicML | ~$13 亿 | 获得 LLM 预训练能力，Mosaic AI 核心团队 |
| 2024 | Tabular | ~$18 亿 | Apache Iceberg 创始团队，打通开放格式互操作 |
| 2025 | Neon | 未披露 | Serverless Postgres 技术，赋能 Lakebase |
每一次收购都在补齐一块关键拼图：MosaicML 补齐了 AI 训练能力，Tabular 补齐了开放格式（Iceberg），Neon 补齐了 OLTP 事务数据库。三次收购合在一起，完成了从分析平台到全栈 AI 操作系统的拼图。
Part 03
当前全景：产品矩阵全解析
截至 2026 年初，Databricks 的产品矩阵已经扩展为一个覆盖数据全生命周期的完整操作系统。我们可以把它分为五个层次来理解：
应用层
Databricks One（统一 UX）· AI/BI Genie（对话式分析）· Databricks Apps（全栈应用托管）
智能体层
Agent Bricks（Agent 开发评估部署）· Mosaic AI（模型训练/服务/RAG）· MLflow 3.0（MLOps + LLMOps）
数据工程层
Lakeflow（统一 ETL）· Lakeflow Designer（可视化管道）· Spark Declarative Pipelines（声明式 ETL）
存储层
Delta Lake + Apache Iceberg（开放格式）· Lakebase（Serverless Postgres OLTP）· 向量搜索
治理层
Unity Catalog（统一目录 + 血缘 + 访问控制 + 指标）· AI 治理（Agent 审计 + 模型版本 + 策略执行）
架构哲学：这不是一堆产品的简单堆叠。Databricks 的核心设计原则是"垂直整合 + 水平开放"——在单一平台内垂直整合全栈能力（从存储到 Agent），同时在每一层都支持开放标准（Delta + Iceberg、PyTorch、MLflow 开源）。这与"最佳组合 (best-of-breed)"的数据工具哲学形成了鲜明对比。
2025 Summit 九大核心发布
Agent Bricks
自优化的 AI Agent 开发框架，自然语言配置，内置评估，从想法到生产数天内完成。
Lakebase
基于 Postgres 的 Serverless OLTP 数据库，融合事务+分析，消除 OLTP/OLAP 边界。
Databricks One
面向业务用户的统一体验层，低代码仪表板 + AI/BI Genie 对话式查询。
Lakeflow & Designer
统一数据工程：声明式 ETL + 可视化拖拽 + 自然语言建管道，批流融合。
MLflow 3.0
统一传统 ML + GenAI 的 MLOps，生产级追踪、LLM 评判、提示版本控制。
原生 Iceberg 支持
Unity Catalog 原生管理 Iceberg 表，联邦元数据，零拷贝互操作。
Databricks Apps
平台内全栈应用托管，Serverless 缩放至零，数据不离开 Lakehouse。
Free Edition
完全免费的工作区版本，几乎所有功能 + Academy 全部课程免费。
Lakebridge
免费迁移工具，自动化 80% 的传统数仓迁移任务。
Part 04
Agent Bricks 深度拆解
Agent Bricks 是 Databricks 2025 年最重要的产品发布，也是其"AI 原生操作系统"叙事的核心支点。它不是一个简单的 Agent 开发工具，而是一整套将 Agent 从实验推向生产的工程方法论。
4.1 解决什么问题
企业在构建 AI Agent 时普遍面临三大挑战：
质量评估难
"我的 Agent 到底靠不靠谱？"——LLM 的非确定性使得传统测试方法失效。学术 benchmark 无法映射到企业真实场景。
参数调优复杂
Prompt、模型选择、检索策略、分块大小、微调参数……数百个"旋钮"需要同时调整，人工试错成本极高。
治理缺失
Agent 在生产环境中做决策，但缺乏审计轨迹、访问控制和合规机制。从 POC 到生产的鸿沟难以跨越。
4.2 工作流程：四步走
① 声明任务
自然语言 + 数据源
→
② 自动评估
合成基准 + AI 评判
→
③ 自动优化
Prompt + 微调 + TAO
→
④ 部署监控
Unity Catalog + MLflow
Step 1：声明任务
用户不需要编写代码，只需：选择任务类型（文档 QA、信息提取、文本转换等）→ 用自然语言描述高级目标 → 连接 Unity Catalog 中的数据源。支持 txt/pdf/md/pptx/docx 等格式。
Step 2：自动评估
这是 Agent Bricks 最核心的创新。系统会自动：
- 合成评估数据：根据任务和数据源自动生成测试用例，不需要人工标注
- 构建定制评判者（Judge）：使用 LLM-as-Judge 方法，自动创建针对具体任务的评估标准
- 多维评分：从基础性（groundedness）、准确性、相关性等多个维度评估 Agent 输出
Step 3：自动优化
系统在评估基准的基础上，智能搜索最优配置组合：
- Prompt Engineering：自动优化系统提示
- 模型微调：在企业数据上精调小模型
- 奖励模型：训练专门的质量评判模型
- TAO（Test-time Adaptive Optimization）：测试时自适应优化——无需标注数据，利用测试时计算训练高效 LLM
Step 4：部署与监控
一键部署到受 Unity Catalog 管控的 Serverless 端点，自动缩放至零。通过 MLflow Tracing 记录每一次推理的完整轨迹，支持合规审计。
4.3 评判系统：三层评估架构
2025 年 11 月，Databricks 进一步升级了 Agent Bricks 的评估体系，推出了三层评判架构：
| 评判类型 | 机制 | 适用场景 |
|---|
| Agent-as-a-Judge |
自动分析 Agent 的推理轨迹，对输出的每个环节进行评分 |
通用场景，快速获得质量基线 |
| Tunable Judges |
允许领域专家定义"好"的标准（如法律合规性、事实准确性、语调） |
垂直行业，需要领域知识的场景 |
| Judge Builder |
无代码界面，可视化创建和调试评估器 |
非技术人员参与质量定义 |
"AI 具有不可预测性和非确定性。LLM 评判的关键不在于它是否'正确'，而在于它是否与人类评判者的判断一致。Agent Bricks 让你在部署前就知道答案。"
— Jonathan Frankle, Databricks 首席 AI 科学家
4.4 ALHF：Agent 从人类反馈中学习
Agent Bricks 引入了一个关键创新——ALHF（Agent Learning from Human Feedback），解决了"人类反馈如何转化为 Agent 改进"的难题：
传统 RLHF 的困境：
• 反馈通常很粗糙（👍/👎）
• 很难定位问题出在哪个组件
• 需要大量标注数据
ALHF 的解决方案：
1. 接收自然语言指导（如 "忽略 1990 年 5 月前的数据"）
2. 算法自动判断应该调整哪个组件：
- 检索算法？→ 优化 embedding / 重排序
- Prompt？→ 增加约束条件
- 向量数据库？→ 调整过滤规则
- 代理模式？→ 修改工具选择逻辑
3. 执行优化并重新评估
结果：领域专家无需理解 AI 基础设施即可直接改进系统
4.5 实际效果
客户案例
- 7-Eleven：使用 Agent 自动化大部分营销运营流程
- AstraZeneca：构建安全、准确的 AI 系统，数天内完成扩展
- Adidas：Agent 综合内部研究，设计区域特定产品，改善收入预测
- Flo Health：使用 Agent Bricks 构建生产级医疗 AI 助手
Part 05
Lakebase：OLTP 融入湖仓
如果说 Agent Bricks 是 Databricks 在"AI 维度"的突破，那么 Lakebase 就是在"数据维度"的根本性创新。它代表了一个重大的架构决策：消灭 OLTP 和 OLAP 的传统边界。
5.1 为什么需要 Lakebase
传统架构的痛点：
传统架构：
┌─────────────┐ ETL/CDC ┌──────────────┐
│ OLTP 数据库 │ ──────────────→ │ OLAP 数据仓库 │
│ (PostgreSQL) │ 延迟 + 成本 │ (Snowflake) │
└─────────────┘ └──────────────┘
↑ 写入 ↓ 查询
应用程序 分析/BI/AI
问题：
• 数据在两个系统间移动 → 延迟、成本、一致性风险
• 两套治理体系 → 安全模型不统一
• AI Agent 无法实时访问操作数据 → 响应滞后
Lakebase 架构：
┌────────────────────────────────────────────┐
│ Databricks Lakehouse │
│ │
│ ┌──────────┐ ┌────────────┐ ┌────────┐ │
│ │ Lakebase │ │ Delta Lake │ │ Iceberg│ │
│ │ (OLTP) │←→│ (OLAP) │←→│ (开放) │ │
│ └──────────┘ └────────────┘ └────────┘ │
│ ↑ ↑ ↑ │
│ Unity Catalog（统一治理） │
└────────────────────────────────────────────┘
↑ 读写 ↓ 查询 + AI Agent
应用程序 分析/BI/AI/Agent
5.2 技术特性
Postgres 兼容
基于 Postgres 协议，现有应用程序可以零改动迁移。背后使用 Neon 的 Serverless Postgres 技术。
计算存储分离
现代化架构：计算和存储独立扩展，支持环境克隆。存储基于 Delta Lake 开放格式。
原生融合
OLTP 数据直接可查询、可训练、可被 Agent 访问。无需 ETL/CDC，实时一致。
统一治理
通过 Unity Catalog 统一管理，策略、血缘和安全可以跨 Postgres、Delta、Iceberg 流动。
5.3 为什么这对 Agent 时代至关重要
核心洞察：AI Agent 需要的不是"分析洞察"，而是"实时行动能力"。传统的 OLAP-only 架构只能告诉 Agent "过去发生了什么"，而 Lakebase 让 Agent 可以直接对实时业务数据采取行动——从"记录系统"升级为"行动系统"。
具体场景举例：
- 购物车放弃 → 实时折扣：Agent 检测到用户放弃购物车，实时查询用户画像，自动生成个性化折扣
- 客户情绪低落 → 自动预警：Agent 分析实时对话情绪，触发客服升级
- 库存异常 → 自动补货：Agent 实时监控库存水位，自动触发采购流程
这些场景都需要 Agent 同时具备读取操作数据（OLTP）和分析历史数据（OLAP）的能力——这正是 Lakebase 的价值。
Part 06
Unity Catalog：治理即控制平面
如果 Agent Bricks 是 Databricks AI 原生战略的"进攻端"，那么 Unity Catalog 就是"防守端"。在 Agent 时代，治理不再是"有了更好"的附加功能，而是整个系统能否安全运行的命脉。
6.1 从数据治理到 AI 治理
Unity Catalog 在 2025-2026 年间完成了一次关键的角色升级：
| 维度 | 传统数据治理 | AI 原生治理（Unity Catalog 2.0） |
|---|
| 治理对象 |
表、视图、文件 |
表 + 模型 + Agent + 向量索引 + 提示模板 + 评估数据集 |
| 治理方式 |
访问控制（谁能读/写） |
访问控制 + 行为审计（Agent 做了什么） + 策略执行（Agent 不能做什么） |
| 血缘追踪 |
数据 → 报表 |
数据 → 模型 → Agent → 决策 → 行动 |
| 质量评估 |
数据质量检查 |
数据质量 + 模型质量 + Agent 可靠性 |
| 核心角色 |
合规检查工具 |
AI 系统的控制平面 |
6.2 治理即控制平面的三个含义
① 上下文层
Unity Catalog 中的元数据（Schema、业务定义、语义标签）引导 Agent 获取正确的数据、选择正确的工具。Agent 的"智能"很大程度上来自于治理层提供的上下文。
② 约束层
策略即代码（Policy-as-Code）定义了 Agent 的行为边界——不能访问什么数据、不能执行什么操作。这是安全扩展 Agent 系统的关键。
③ 审计层
每一次 Agent 的推理、工具调用和决策都有完整的可追溯记录，满足 GDPR、SOC 2、ISO 27001 等合规要求。
6.3 Unity Catalog Metrics：业务指标作为一等公民
2025 年的一个重要更新：Unity Catalog 现在支持在目录中定义和管理认证的业务指标（Metrics）——如会话数、转化率、用户 LTV 等。
为什么这很重要：在传统架构中，同一个指标在不同部门的仪表板上可能有不同的定义和计算方式（"指标蔓延"问题）。Unity Catalog Metrics 将业务指标的定义统一到治理层，通过 SQL 在任何工具中访问，确保全企业口径一致。对于 AI Agent 来说，这意味着它在回答业务问题时使用的是唯一真实来源。
Part 07
数据工程的范式变革
Databricks 在数据工程层面的变革，可能是对日常数据团队影响最大的部分。核心信号是：数据工程正在从命令式转向声明式。
7.1 Lakeflow：统一数据工程
Lakeflow 将数据摄取（Ingestion）、ETL 转换和编排整合为一个统一的解决方案：
Spark Declarative Pipelines
Databricks 将其核心声明式 ETL 框架捐赠给 Apache Spark，成为开源标准。支持批流融合，开发时间减少 90%。
已捐赠 Apache
Lakeflow Designer
可视化无代码界面，支持拖拽和自然语言构建数据管道。业务分析师也能参与管道创建。
No-Code Natural Language
7.2 声明式 vs 命令式：范式对比
| 命令式（传统） | 声明式（Databricks 方向） |
|---|
| 工程师说 |
"先读 A 表，JOIN B 表，过滤掉 null，写入 C 表，每小时执行" |
"我需要一张 C 表，包含 X 字段，质量 > 95%，延迟 < 1 小时" |
| 编排 |
手动定义 DAG、依赖关系、重试策略 |
平台自动处理执行计划和编排 |
| 优化 |
手动调优 Spark 参数、分区策略 |
平台自动选择最优执行策略 |
| 维护 |
管道坏了需要人工排查和修复 |
自动检测异常、自动恢复 |
| 技能要求 |
需要深入理解 Spark/SQL/调度器 |
只需理解业务需求 |
7.3 "分析即代码"（Analytics-as-Code）
Databricks 2026 年推动的一个核心理念是：数据产品的交付应该像软件产品的交付一样——
版本化语义层
→
声明式转换
→
CI/CD 管道
→
PR + 代码审查
→
自动化测试
→
提升门禁
这意味着什么：数据工程师的角色正在从"管道建设者"向"数据产品经理"转变。未来的数据工程师需要的不是写更多的 Spark 代码，而是定义清晰的数据产品规格——质量 SLA、新鲜度要求、业务语义。执行层面的工作越来越多地由平台（和 Agent）自动完成。
Part 08
2026 战略方向与预测
基于 Databricks 官方博客（2026.02）和多方分析，以下是 Databricks 2026 年的核心战略方向：
8.1 四大战略支柱
治理即控制平面
AI 治理不再仅是访问控制，而是覆盖 AI 工作负载、仪表板、语义和血缘关系的完整控制层。成功的 AI 战略必须能回答：能否识别用了什么数据？能否追踪调了哪个模型？能否解释整个 Agent 链上发生了什么？
开发整合到数据所在地
AI 开发不再分散在数十种工具中，而是整合到数据驻留的地方。消除运营复杂性，用开放和可互操作的格式连接所有数据。
统一多模态数据
跨越结构化和非结构化数据，以统一的开放格式连接所有数据源。这是让 Agent 真正有用的前提——Agent 需要理解表格、文档、图片、代码等多种数据类型。
专注"无聊 AI"+ 人类专业知识
将 AI 应用于重复和常规任务，同时为领域专家配备高度专业化的 Agent。核心是以人为本——释放人们创新的潜力，而不是取代人。
8.2 行业分析师的 12 项预测（BIX Tech, 2026）
| # | 预测 | 关键信号 |
|---|
| 1 | AI 原生湖仓成为默认配置 | 向量搜索、嵌入和检索像表和 JOIN 一样原生 |
| 2 | 实时设计成为常态 | 流优先摄取，批流融合在幕后完成 |
| 3 | 治理即产品体验 | Unity Catalog 成为策略和信任的控制平面 |
| 4 | AI Agent 集成到平台生命周期 | MLOps 和 LLMOps 合并为统一治理循环 |
| 5 | 分析即代码 | 版本化语义层、声明式转换、CI/CD 标准化 |
| 6 | 开放格式零拷贝互操作 | Delta + Iceberg 深度互操作，数据零重复 |
| 7 | 无处不在的 Serverless | 计算"不可见"，成本感知调度 |
| 8 | 内置数据 + ML 可观测性 | 数据质量、模型漂移、成本统一监控 |
| 9 | 自然语言驱动的分析 | 不只是生成 SQL，还能理解指标和推荐可视化 |
| 10 | 垂直行业加速器 | 行业特定的数据模型、KPI 和预置管道 |
| 11 | 企业级隐私和驻留控制 | VPC 限定训练/推理，司法管辖区感知存储 |
| 12 | 更大的内部市场 | 特征、提示、向量索引和策略模板的市场化 |
8.3 数据团队角色演变
Databricks 的 AI 原生化正在重新定义数据团队中每个角色的技能要求：
数据工程师
流优先 → Delta 最佳实践 → 声明式管道 → 治理原语。从"写 Spark 代码"到"定义数据产品规格"。
分析工程师
指标层 → 版本化语义 → SQL CI → 语义治理。从"写报表"到"管理业务真相"。
数据科学家/ML 工程师
RAG 设计 → 评估框架 → Agent 编排 → 生产优先。从"训练模型"到"构建可靠的 AI 系统"。
平台团队
FinOps → Serverless 编排 → 可观测性 → 模板驱动。从"维护集群"到"运营 AI 基础设施"。
Part 09
对我们的启示
Databricks 的案例对于正在思考"AI 原生数据团队"的团队来说，有哪些可借鉴的经验？
9.1 五个关键启示
① 平台 AI 化 ≠ 在平台上加 AI 功能
Databricks 的做法不是"给 Lakehouse 加一个 AI 按钮"，而是用 AI 重新定义平台的每一层：存储层支持向量、计算层支持 Agent、治理层支持 AI 审计、应用层支持自然语言。这是"加法"和"乘法"的区别。
对我们的意义：在设计数据平台升级路线时，不要只考虑"在哪里接入 LLM"，而要思考"如果 Agent 是一等公民，整个架构应该是什么样的"。
② 评估是 Agent 工程的核心
Agent Bricks 花了大量篇幅在评估上——自动评估、AI 评判、可调评判器。这不是锦上添花，而是从"AI 演示"到"AI 工程"的分水岭。
对我们的意义：在构建任何 Agent 系统之前，先回答"我怎么知道它做得好不好"这个问题。如果没有评估体系，Agent 就是一个不可控的黑箱。
③ 治理不是负担，是 Agent 的基础设施
Databricks 把治理从"合规成本"重新定义为"Agent 的控制平面"——Agent 需要元数据来理解数据，需要策略来约束行为，需要审计来建立信任。
对我们的意义：如果你的数据没有清晰的元数据、一致的业务定义和完善的访问控制，那么 Agent 在你的数据上只会制造更大的混乱。治理先行。
④ 声明式 > 命令式是大势所趋
从 Spark Declarative Pipelines 到 Lakeflow Designer 到自然语言建管道，方向很清晰：告诉系统你要什么，而不是怎么做。Snowflake 的 Cortex Code 也在走同一条路。
对我们的意义：开始思考如何将内部的数据管道从"脚本驱动"转向"规格驱动"。定义清楚输入、输出、质量要求和 SLA，让平台和 Agent 去解决"怎么做"。
⑤ OLTP + OLAP 融合是 Agent 时代的必然
Lakebase 的推出标志着一个趋势：Agent 需要同时读写操作数据和分析数据。传统的"操作库 → ETL → 分析库"的割裂架构无法满足实时 Agent 的需求。
对我们的意义：评估你的 Agent 系统是否需要实时操作数据。如果需要，考虑减少 OLTP/OLAP 之间的数据移动，或者至少建立实时同步通道。
9.2 Databricks 模式的局限性
当然，Databricks 的方案也有其局限——坦诚面对这些局限才是负责任的分析：
- 垂直整合 vs 最佳组合：Databricks 的全栈方案意味着深度绑定。对于已经有成熟工具栈的团队，迁移成本不可忽视。
- 复杂度转移：声明式不意味着简单——复杂度从"怎么做"转移到了"要什么"。如果业务需求定义不清晰，声明式同样无法工作。
- Agent 信任鸿沟：虽然 Agent Bricks 提供了评估框架，但在金融、医疗等高风险行业，"AI 评判 AI"是否足以建立信任仍是开放问题。
- 成本问题：全栈 Serverless 看起来很美，但在大规模生产环境中，成本控制仍然需要深入的 FinOps 实践。
Part 10
总结与关键判断
Databricks 从 2013 年的 Spark 商业化公司，到 2026 年的 AI 原生操作系统，走了一条清晰的进化路径。这条路径的核心逻辑是：
进化核心逻辑：
Phase 1: 掌握计算 → "数据能算"
Phase 2: 掌握存储 → "数据能管"
Phase 3: 融合分析 → "数据能用"
Phase 4: 嵌入 AI → "数据能理解"
Phase 5: Agent 原生 → "数据能行动"
从"数据为人服务" → "数据为 Agent 服务" → "Agent + 人一起用数据"
五个关键判断
判断 1
Databricks 的"AI 原生 OS"定位是战略正确的——数据平台的终态确实是"Agent 的操作系统"
判断 2
治理层是 Agent 时代的核心基础设施，不是可选项。Unity Catalog 的角色升级代表了行业共识
判断 3
评估/评判体系（Judge Model）将成为 Agent 工程的标准组件，而不仅仅是实验期工具
判断 4
OLTP/OLAP 融合是 Agent 时代的架构必然，Lakebase 代表了方向但实现路径仍需验证
判断 5
声明式数据工程将在 3-5 年内成为主流，"数据工程师"的工作内容将根本性地改变
最后一个观察：Databricks 最令人印象深刻的不是任何单一产品，而是它每一次转型都没有丢失之前积累的资产——Spark 仍在运行、Delta Lake 仍在增长、Unity Catalog 仍在扩展。每一层新能力都是建立在前一层之上。这种"累积式进化"的能力，可能是理解"AI 原生化"最重要的一课：不是推倒重来，而是在已有基础上长出新的能力。
— Tuntang Research · 2026.03.27 —
本文基于公开信息整理，不构成投资建议。数据来源：Databricks 官方博客、Fast Company、Bain & Company、Atlan、SunnyData、BIX Tech、Snowplow 等。