仰望星空：从 Databricks、Snowflake 与 Palantir 看数据平台走向 Agent

1. 三家公司，最初在我眼里属于三个世界

刚开始学数据平台时，我给三家公司贴过很简单的标签：

Databricks = Spark + Lakehouse
Snowflake   = 云数据仓库
Palantir    = Ontology + 行业应用

这些标签帮我快速建立初步印象，也让我忽略了它们正在发生的共同变化。

截至 2026 年 9 月，Databricks 已经把统一治理、业务语义、Agent、MCP 服务和评估放进同一套平台能力；Snowflake 在数据库中提供 Semantic View，并让 Cortex Agents 在权限控制下组合结构化数据、非结构化资料和工具；Palantir 则继续把 Ontology 扩展成供人和 Agent 共同查询、判断和执行 Action 的业务世界模型。

我开始意识到，三家公司虽然从不同位置出发，却在靠近同一个问题：

企业怎样让 Agent 理解数据的业务含义，并且只在允许的范围内采取行动？

这个问题比“接入哪个大模型”更难。模型可以读懂一句话，却不会自然知道“收入”的统一口径、“订单”当前允许的状态变化，以及调用某个业务动作需要谁授权。

2. 它们正在汇合到同一条链路

我把三家平台的共同方向整理成下面这条链路：

Physical Data
     ↓
Catalog / Governance
     ↓
Business Semantics
     ↓
Agent Tools
     ↓
Permission / Evaluation / Audit
     ↓
Decision or Business Action

这里每一层都在消除一种不确定性。

过去的数据平台通常在前三层投入很多精力。Agent 出现以后，后面三层开始变得同样重要。

3. Databricks：从数据与 AI 工程向上生长

Databricks 最容易让我理解的起点是 Lakehouse：对象存储负责保存开放格式的数据，Spark、SQL、机器学习和流水线围绕这些数据运行。

但只把数据放进同一个湖里，不能保证所有人对业务的理解一致。两个团队都查询 revenue，可能分别使用订单金额、已付款金额或扣除退款后的金额。

Databricks 当前使用 Unity Catalog 统一治理数据和 AI 资产。它能够管理访问权限、发现资产和追踪血缘，模型、函数与其他 AI 资产也可以成为受治理对象。Unity Catalog 文档说明，治理范围已经超出表和文件。

在语义层，Metric View 将指标、维度、连接关系和过滤条件集中定义：

source: catalog.sales.orders
fields:
  - name: Order Month
    expr: DATE_TRUNC('MONTH', source.order_time)
measures:
  - name: Paid Revenue
    expr: SUM(source.paid_amount)

这段 YAML 是根据官方结构改写的简化示例。它表达的是“怎样计算已付款收入”，没有绑定某个具体图表。SQL、Dashboard 和 Agent 可以复用同一份定义。Unity Catalog Metric View将它描述为 Unity Catalog 语义能力的核心实现。

2026 年 9 月的官方文档还出现了 Genie Ontology。它将人工维护的 Metric View、Domain、Page 与系统从查询、Dashboard 和 Genie Agent 中提取的上下文组织到一起，作为 Genie 系列体验共享的业务上下文层。这个功能目前标记为 Public Preview，因此我把它看作清晰的产品方向，还不能当成所有生产环境都已稳定采用的默认能力。Genie Ontology 文档

Agent 侧同样延续了这条治理主线。外部 MCP Server 可以注册成 Unity Catalog 中的 MCP Service，再通过授权、工具筛选、策略和调用日志进行管理。MCP Services 文档把 MCP 服务作为一种受治理资产。MLflow 则承担 Trace、评估和线上监控，让 Agent 的每一步可以被检查。Databricks Agent 文档

我对 Databricks 的理解因此从“处理大数据的工具”扩展成：

开放数据底座
+
统一的数据与 AI 治理
+
业务指标和上下文
+
Agent 开发、工具与评估

它的优势仍然扎在数据工程、机器学习和开放数据生态中，然后逐层向业务语义与 Agent 延伸。

4. Snowflake：让 Agent 在受治理的数据附近工作

Snowflake 的起点更接近企业数据仓库。大量结构化数据已经在数据库中，权限、计算资源和 SQL 使用方式也比较成熟。

自然语言问数带来了一个直接问题：模型认识 SQL，不代表它认识公司的业务指标。Snowflake 的 Semantic View 因而很关键。它是数据库中的 Schema 级对象，可以描述业务实体、关系、Fact、Dimension 和 Metric。Semantic View 文档明确把它作为物理数据与业务概念之间的抽象层。

Physical Tables
      ↓
Semantic View
├── Customer
├── Order
├── Product
├── Order → Customer
└── Net Revenue
      ↓
Cortex Analyst / Cortex Agents

Cortex Agents 会规划任务并调用工具。面对结构化数据时，它可以通过 Cortex Analyst 和 Semantic View 生成 SQL；面对文档时，可以调用 Cortex Search；需要进一步处理时，还能调用代码执行或自定义工具。Cortex Agents 文档同时说明，Agent 对数据和工具的访问仍受 Snowflake 角色、对象权限与工具执行上下文约束。

这让我看到 Snowflake 的连续性：

SQL Warehouse
     ↓
Governed Data
     ↓
Semantic View
     ↓
Cortex Agent

它首先让 Agent 更可靠地查询和分析数据库中的数据，再通过自定义工具扩展可执行范围。与 Palantir 的 Action 相比，Snowflake Semantic View 当前更侧重“怎样正确理解和查询数据”；业务写回与跨系统动作需要由 Agent 工具继续承接。这是我依据公开文档做的能力边界归纳。

5. Palantir：把对象、规则和 Action 放在一起

Palantir 给我的冲击来自另一个方向。它没有先让用户面对表，而是先问企业中有哪些对象：

Machine
Order
Supplier
Inventory
Shipment

对象之间有 Link，对象上可以挂载逻辑，还能定义真正改变业务状态的 Action。

Palantir 官方架构文档把 Ontology 放在体系核心，用 data、logic、action、security 四个部分描述一次业务决策。Ontology system将对象和关系称为企业里的“名词”，将 Action 和 Automation 看作“动词”。

以库存调拨为例，仅仅知道库存数量还不够：

Inventory
├── 当前数量
├── 所属仓库
├── 预留订单
└── 可用数量

ReallocateInventory
├── 谁可以提交
├── 哪些状态允许提交
├── 调拨数量怎样校验
├── 需要调用哪些系统
└── 执行后怎样审计

Ontology 因此同时提供理解业务和约束行动的入口。

这套抽象在 Agent 时代变得更直接。Ontology MCP 可以把 Object Type、Action Type 和 Query Function 暴露为 MCP 工具。外部 Agent 可以读取对象、调用查询函数，或者执行预先定义的 Action；OAuth、应用限制和原有权限继续约束这些调用。Ontology MCP 架构

Palantir 还把两类用途分开：

Builder / Coding Agent
        ↓
Palantir MCP
        ↓
构建数据集、Ontology 和应用

Business / Runtime Agent
        ↓
Ontology MCP
        ↓
查询 Object、调用 Function、执行 Action

Palantir MCP 文档说明，Palantir MCP 面向平台构建者，可以修改 Ontology 类型，但不能直接写 Ontology 数据；Ontology MCP 面向能力消费者，通过应用限制暴露指定对象与动作。

权限也没有交给提示词决定。AI FDE 使用当前用户身份，服务端继续执行原有权限检查；写操作需要用户确认，并进入 Foundry 审计记录。AI FDE 安全与治理

从公开架构看，Palantir 更关注完整的运营闭环：

观察现实状态
    ↓
理解业务对象
    ↓
运行规则或模型
    ↓
提交受约束的 Action
    ↓
写回业务系统
    ↓
保存结果和反馈

6. 三条上山路线，在 Agent 入口处相遇

我目前会这样区分三家公司。这张对照表是我自己的整理，不是厂商给出的统一分类。

这张表没有回答谁最终会赢。对我更有帮助的问题是：为什么它们都在补语义层、Agent 工具和治理？

因为企业 Agent 面对的障碍通常不在模型能否生成一句通顺回答，而在下面这些地方：

同一个指标存在多个计算口径
表名和字段名缺少业务含义
权限只控制数据，没有控制工具
Agent 能提出动作，却没有可靠执行边界
执行以后缺少审计、证据和反馈

三家公司采用的产品结构不同，但都在尝试把这些上下文放到模型外部，由平台持续维护。

7. 我对后端开发的理解也随之变化

刚做 Java 后端时，我很容易把后台系统理解成下面四层：

Controller
    ↓
Service
    ↓
Mapper
    ↓
Database

研究这三家公司以后，我会在 Service 前面再问几件事：

这个请求操作的是哪个业务对象？
对象当前处于什么状态？
调用者可以执行哪些动作？
动作需要哪些确定性校验？
本次执行使用了哪版数据和规则？
失败、重试和审计记录保存在哪里？

这些问题可以整理成一个更完整的平台结构：

Data Plane
保存 Dataset、Episode、训练记录和模型产物

Semantic Plane
定义 DatasetVersion、TrainingJob、ModelVersion、Evaluation
以及它们之间的业务关系

Action Plane
定义 approveDataset、startTraining、publishModel
以及状态前提和参数校验

Agent Plane
理解用户意图、查询对象、提出下一步动作

Governance Plane
执行身份、权限、审批、日志、评估和版本追踪

这是我从三家平台提炼出的五层结构，不是任何一家公司的官方产品分层。

8. 把星空落回工程项目

这些平台非常大，我现在不可能复刻它们。对个人工程项目有价值的部分，是选一条能够完成并解释的小链路。

放进 AI 数据平台，可以先实现：

DatasetVersion
      ↓ used by
TrainingJob
      ↓ produces
ModelVersion
      ↓ evaluated by
Evaluation

然后增加三个明确的业务动作：

approveDataset(versionId)
startTraining(versionId, recipeId)
publishModel(modelVersionId)

每个动作都回答五个问题：

1. 谁可以调用？
2. 当前状态是否允许？
3. 参数和关联版本是否有效？
4. 并发提交时谁成功？
5. 执行结果和失败原因怎样留下记录？

Agent 可以负责把“用审核通过的数据训练一个新模型”解析成对象和动作，但 Java 服务仍然校验权限、状态、版本和幂等条件。真正的 Python 训练执行器继续负责 GPU 计算，完成后把状态、日志和产物引用返回平台。

User
  ↓
Agent：理解目标，提出 startTraining
  ↓
Java Platform：鉴权、校验、创建任务、记录审计
  ↓
Python Worker：执行训练、保存检查点与产物
  ↓
Java Platform：关联 ModelVersion 与 Evaluation

我不需要先创造一个宏大的 Ontology 平台。只要这条链路中的对象、状态、动作和证据能够互相对应，就已经开始解决同一类工程问题。

9. 个人判断

Databricks 让我看到，数据、模型、Agent、MCP 工具和评估可以进入统一治理体系；Snowflake 让我理解，Agent 要可靠地查询企业数据，需要数据库里的业务语义和权限上下文；Palantir 则把这个问题继续推向真实行动，让对象、规则、权限与 Action 构成一个可以被人和 Agent 共同使用的业务世界模型。

我现在更愿意用下面这句话描述数据平台正在发生的变化：

数据平台正在从“保存和计算数据的地方”，扩展成“人和 Agent 共同理解业务、调用能力并留下责任边界的地方”。

仰望这些公司的产品，会看到非常复杂的系统；回到个人工程项目，我能先把一份数据的版本、一项业务动作的前提和一次执行的证据做清楚。这个距离依然很远，但方向已经比“再增加一个聊天框”具体得多。

相关阅读

• SQL 能运行，为什么问数结果还是错的？
• 企业 RAG 数据怎样进入 Milvus：文档版本、切分、索引与权限
• Agent 平台为什么要保存 Trace 和 Evidence：从一次检索到受控 Action
• 从 AI 数据平台到 LeRobot：我对 Java 后端开发理解的变化