最近看了 Snowflake 关于 Business Ontology 的两篇文章。对 Snowflake 不太熟悉的话，很容易只记住“又有一家厂商开始做本体了”，却不知道这个产品放在哪里，和原来的能力有什么关系。

本文讨论的是截至 2026 年 11 月 8 日的公开产品设计。Snowflake 在 11 月 3 日的工程文章中将 Business Ontology 标为 Private Preview，并表示它与 Cortex Sense 即将开放 Public Preview。下面涉及这些能力的使用过程，以账户已开通相应预览功能为前提。产品状态

Snowflake是什么

Snowflake 是一个托管在公有云上的数据平台。企业把需要分析的数据接入进来，在平台中存储、处理和查询，再提供给报表、应用和 AI 使用。基础设施和数据库服务由 Snowflake 管理，企业主要围绕数据和业务逻辑开展工作。

如果用传统数仓的使用方式来理解，可以先想象一个场景：订单来自交易系统，客户信息来自 CRM，退款来自售后系统。企业把这些数据汇集起来，清洗、关联，再计算收入、客户留存等指标。Snowflake 为这些工作提供存储和计算基础。

它把持久化存储与计算资源分开。Virtual Warehouse 是执行查询的计算集群，不是另外复制出来的一份数据库。不同工作负载可以使用各自的计算资源，读取共享的数据。围绕这个基础，Snowflake 已经覆盖数据工程、分析、AI 和应用开发等方向。Snowflake 架构说明

理解 Business Ontology，还需要知道 Snowflake 原来就有的几个能力。

首先是 Semantic Views，语义视图。它已经能够描述客户、订单等业务实体及其关联，定义指标和分析维度，并把这些定义对应到物理数据。例如，业务人员问“各区域的净收入”，语义视图提供净收入的计算定义，以及按区域分析所需要的维度和关联关系。它本身就是一个带有业务语义的数据库对象。Semantic Views 文档

其次是 Cortex Agents。它负责分析用户问题、选择工具、查询数据并组织答案。结构化数据可以通过 Cortex Analyst 和语义视图处理，文档等非结构化内容可以通过 Cortex Search 检索，还可以调用自定义工具接入其他业务逻辑。企业已经能够在这个环境里构建使用自身数据的 Agent。Cortex Agents 文档

还有 Horizon Catalog，它提供元数据和治理基础，管理数据资产的信息及相关的访问控制。表在哪里、有哪些列、资产之间有什么血缘关系，属于这一侧要处理的事情。

因此，理解 Snowflake 当前的能力，可以沿着一条实际的使用路径来看：先有企业数据，再有数据处理和指标定义，最后由 BI、应用或 Agent 使用。数据资产的发现和治理贯穿其中。

图 1：从企业数据到分析与 Agent，存储、计算、语义视图和治理各自承担不同职责。

Snowflake新增了什么

Snowflake 把收集、补充和使用业务上下文的能力组织到 Horizon Context 中。它建立在 Horizon Catalog 的元数据基础上，把数据库、BI 和数据处理工具里的知识连接起来，供 AI 和分析使用。Horizon Context 介绍

这次值得关注的是其中的 Business Ontology，以及与它协作的 Cortex Sense。Semantic Views 和 Cortex Agents 已经是相关基础，不能把这些名字都理解为同一批新增功能。

先看一个净收入的问题

Snowflake 的工程文章用了一个很容易理解的例子，下面是这段背景故事的中文译文：

还记得你入职的第一周吗？有人问你净收入是多少。你找到了财务部门的一个列、销售部门的一个列、一个语义视图和一个仪表盘：它们的名称都一样，计算方式却不同。财务指的是扣除退款和折扣后的已确认收入；销售指的是签约时扣除折扣后的订单金额。两种定义都没有错。你通过询问同事，才知道该用哪一个；随着时间推移，你也逐渐了解到谁负责这个定义，以及谁能批准修改。

AI 智能体却每次都像第一天入职的新员工。它能读取数据仓库、编写 SQL，却无法询问那位同事。面对几个看起来都合理的定义，它可能选定一个，并用确定的语气给出回答。

业务本体为智能体补上了这段缺失的入职培训：经治理负责人批准的业务含义、清晰的责任归属，以及与数据的连接。

这个例子里，数据没有丢，计算也未必有错。问题出在“净收入”这几个字上：不同部门使用同一个词，但表达的是不同的业务概念。

图 2：同一个名称可以对应不同的业务定义，Agent 需要根据问题确定适用口径。

假设财务和销售各有一套语义视图，两边的公式都写对了，Agent 仍然需要判断这次应该使用哪一个。增加一个查询工具，解决不了这个选择问题。

当然，可以把口径说明直接写进 Agent 的 Prompt。只服务一个固定场景时，这可能就够了。但如果企业有几十个 Agent，还有多套 BI 和应用，这些说明就会跟着工具复制。财务修改一次口径，要到多少地方同步？两个同名指标含义不同，到哪里确认这是有意保留的差异，还是其中一个已经过期了？

Business Ontology管理业务定义

Business Ontology 把业务定义作为独立于某个数据实现的对象来管理。一个定义可以关联多个实现，同名但含义不同的定义也可以分别保留。各团队和 Agent 因而有了一个共同引用业务含义的位置。Business Ontology 产品介绍

从工程文章给出的模型看，可以抓住四个对象：

• Concept，概念。 净收入是一个概念，收入确认政策也可以是一个概念。它们有名称、定义、类别等属性。
• Relationship，概念关系。 例如，总收入经过扣减得到净收入，可以用 DERIVES 连接；收入确认政策适用于净收入，可以用 APPLIES_TO 连接。
• Representation，资产引用。 把概念连接到描述或实现它的资产，例如某个语义视图中的指标。它保存的是引用关系；即使概念中记录了公式，本体也不负责执行公式。
• Domain，领域。 给概念明确的归属。Finance.Net Revenue 和 Sales.Net Revenue 可以同时存在，分别表达财务和销售认可的含义。

这几个对象把业务含义与数据实现连接起来。下面是一个简化示意，视图名称为说明关系而设：工程设计说明

图 3：实线连接业务概念，虚线表示概念对数据实现的引用。

概念之间的业务关系，与概念指向数据实现的引用，是两种不同的关系。收入确认政策为什么影响净收入的解释，和取得这个数值应该查询哪个指标，需要分别描述。

这里的 Finance.Net Revenue 是指标概念，不是某个季度已经算出来的收入数值。类似地，“客户”概念也不能直接等同于某位客户的完整业务对象。这个模型主要组织概念、定义和相关资产，具体的业务事实仍然需要通过数据和工具取得。

Cortex Sense辅助发现上下文

企业未必已经整理好自己的业务知识。很多知识散落在 SQL、dbt 模型和仪表盘里，甚至只是一些被长期沿用的查询习惯。

Cortex Sense 面向的就是这类工作：根据已有的元数据和使用信号推断上下文，发现未被手工建模的内容，再通过反馈和评估改进理解。它可以帮助找到候选的业务概念、关系和冲突，供团队进一步确认。Cortex Sense 设计

但查询日志里某种写法出现得多，只能说明它常用。一份旧仪表盘也可能长期有人访问。自动发现出来的知识，仍然需要区分哪些可以参考，哪些应该成为企业正式认可的定义。

Business Ontology 为后者提供治理机制：新概念先进入草稿；修改已批准的概念时，形成编辑提案。在领域治理负责人批准之前，Agent 继续使用原来的已批准版本。审批由对业务含义负责的 Domain Steward 承担，概念的可见性也受到领域权限约束。概念审批与权限设计

图 4：自动发现提供候选知识，审核决定哪些定义可以成为正式依据。

笔者觉得，这次补全的核心，是把企业如何解释数据、谁认可这种解释、到哪里取得对应数值，变成可以共同维护和使用的内容。已有语义视图提供计算定义，自动发现帮助扩大知识覆盖，业务本体则让其中需要明确责任的定义有一个正式归属。

这些能力如何使用

下面继续用“查询上季度净收入”这个场景。假设企业已经有订单、退款等数据，以及财务和销售各自使用的语义视图，想在此基础上建立一个能够识别业务口径的 Agent。

这是根据公开产品入口整理的一条使用路径。已有术语表的企业可以先导入定义，尚未整理语义视图的企业也可以先从概念或 Cortex Sense 开始，并不要求所有团队采用同一个建设顺序。

图 5：沿着一个已有语义视图的场景，逐步准备数据、定义、工具和验证。

准备数据和指标实现

首先由数据开发人员确认，这次问题涉及哪些数据，应该按哪个时间字段统计，退款和折扣如何处理，以及是否需要排除测试账户。对“净收入”来说，确认收入的时间与订单签约时间可能不同，不能只看字段名称。

如果已经有相关语义视图，就检查并复用。否则，可以通过 Snowsight 的向导、Semantic Studio 或 SQL 创建语义视图，把指标、维度和关联关系对应到实际数据。语义视图创建入口

这一步应该得到一个能够独立核对的指标实现。例如，财务人员已经确认某个季度的结果，可以用它检查语义视图的计算。业务本体需要连接到这个实现，但不会代替它完成数据清洗或修复错误的 SQL。

创建领域和概念草稿

开通相应预览能力后，官方给出的入口包括 Snowsight 的 Business Ontology 页面，以及 Cortex Code 中的 business-ontology skill。后者可以协助创建领域、起草概念、导入已有术语表或本体，并根据语义视图提出概念。本体维护入口

业务人员先明确财务和销售各自的含义，开发人员再把这些定义与数据实现对应起来。例如，可以向该 Skill 描述下面的任务。这是自然语言任务示例，不是导入格式或固定命令：

为财务和销售分别准备 Finance、Sales 两个领域的概念草稿。

Finance.Net Revenue 表示扣除退款和折扣后的已确认收入。
Sales.Net Revenue 表示签约时扣除折扣后的订单金额。

保留两个定义的差异，记录各自的业务负责人和定义来源，
并列出需要业务人员进一步确认的问题。

如果已有术语表，可以直接把它作为输入。若知识主要散落在 BI、查询历史和转换逻辑里，也可以先借助 Cortex Sense 建立上下文，审核其发现的冲突，再把有价值的候选概念提升为本体草稿。已有定义和自动建议都需要经过审核。

这一步的产物是概念草稿，包括业务含义、领域归属，以及准备建立的关系，还不能把它直接当成正式口径。

审核定义并关联指标

接下来，由领域治理负责人检查定义。财务认可的净收入具体包含什么，哪些情况需要排除，使用哪个收入确认规则；销售的同名概念又为什么需要独立保留。这些是业务判断，不能只根据表名相似或两段 SQL 很接近来决定。

同时，检查概念与实现的对应关系。例如，财务概念应该关联到已经核对过的财务语义视图指标，不能因为名称一致就连到销售指标。通过 Representation 建立这条关联后，业务定义和计算实现才有了明确的对应。

审批完成后，概念成为 Agent 可以检索的正式定义。以后需要修改时，走提案和审核流程，而不是直接用草稿替换当前口径。负责数据实现的人也需要配合检查公式、过滤条件等是否仍与业务定义一致。

把本体和查询工具接入Agent

官方给出的方式，是让 business-ontology skill 基于本体和语义视图构建 Cortex Agent。这里要区分两个名字：business-ontology 是帮助开发者建设本体和 Agent 的 Skill；business_ontology 是 Agent 在回答问题时使用的本体搜索工具。Agent 与本体的连接方式

对于一般 Cortex Agent，Snowsight 中的入口是 AI & ML → Agents → Create agent。创建 Agent 对象后，再配置它可以使用的工具和资源，例如语义视图、计算 Warehouse 以及查询超时。仅仅创建一个 Agent，并不会让它自动拥有企业数据访问能力。创建和配置 Agent

对这个例子，Agent 需要能够搜索已批准的业务概念，也需要能够查询相应指标。开发者还应给它明确的使用指引，例如：

回答收入问题时，先确定适用的业务定义。
若存在财务和销售两种口径，且上下文不足以选择，向用户澄清。
确定定义后，使用与该定义对应的语义视图指标取得数值。
回答中说明采用的定义、统计范围和数值来源。

这些指令仍然有价值，但具体定义由本体提供，可以被多个 Agent 复用，不必在每个 Prompt 里复制整套业务术语表。

工具访问需要配置相应权限。能够看到某项指标的业务定义，并不意味着自动拥有底层数据的读取权限；本体检索与数据查询都需要在各自的权限范围内工作。

提问并验证结果

业务人员现在可以提出“上个季度的净收入是多少”。如果当前会话没有提供足够的信息，Agent 应该先说明财务和销售存在不同口径，询问用户需要哪一个；确定使用财务定义后，再查询对应指标。

图 6：回答需要交代所用口径与数值来源，本体检索和数据查询分别遵守权限约束。

返回结果时，应该能看出它采用了 Finance.Net Revenue，查询了什么指标，以及如何确定统计范围。这里“按语义视图计算”也不要求每次都直接查询视图对象；当前文档还描述了读取语义视图定义、再生成访问物理表的 SQL 的方式。关键是遵循哪套指标定义。语义视图与 AI 查询

对开发者来说，拿到一个看起来合理的数字还不够。笔者会至少准备下面几类问题，比较接入本体前后的行为：

检查场景	关注什么
只问“净收入”，不指定部门	是否识别歧义并澄清，而不是任意选一个实现
明确询问财务口径	是否采用正确的定义，计算结果是否与确认过的结果一致
已批准定义存在待审核修改	是否继续使用当前已批准版本
使用不同权限的角色提问	是否遵守概念可见性和数据访问限制

前两类检查业务解释和计算，后两类检查治理是否真正影响运行。它们是示例中的验证建议，不代表仅靠这些问题就能证明系统完全正确。

后续维护也需要延续这个过程。新增一个 Agent，可以复用已经确认的概念；某个指标实现发生变化，需要检查对应的业务定义；调整业务口径时，则需要检查关联实现是否一起更新。

笔者之前写《本体系统如何组织数据，为Agent提供上下文》时，关注的是围绕业务对象，把数据、关系和文档组织起来。Snowflake 这次把其中一个问题展开得更具体了：Agent 找到相关知识后，还需要知道它属于哪个领域，是否经过认可，以及对应什么实现。

至于让 Agent 判断某笔订单能不能提前交付，甚至执行修改生产计划的动作，还需要具体业务事实、约束校验和经过授权的执行工具。本体可以帮助解释这些信息，但仅仅定义 Policy 或 Action 概念，并不会自动完成后面的业务执行。

对已经拥有大量数据和指标的企业来说，先把常用概念的含义、归属和实现关系整理清楚，再让 Agent 使用这些知识，是一条具体而且能够逐步验证的建设路径。