Snowflake上的操作性本体：从业务语义到受治理的AI行动

一种面向 AI 代理的参考架构，用于对运营状态进行推理、模拟决策、执行受治理的操作，并验证现实世界的执行结果。

从企业知识到运营决策

下午 1:30，配送中心内的包装站 PB-04 离线。订单开始积压，而计划于下午 5:00 出发的承运商可能会在其货物准备就绪之前就离开。

连接到仓库数据的 AI 代理可以识别出故障的站点、追踪受影响的订单，并解释运输风险。但仓库经理需要决定该做什么。

合格工人能否转移到另一个站点？订单能否改道？哪种恢复计划最有可能在不产生另一个瓶颈的情况下赶上截止时间？

回答这些问题需要当前的运营状态、资源能力、业务约束，以及一种评估拟议变更的方法。基于决策采取行动还需要授权，并确认预期变更确实发生。

在之前的Snowflake 本体系列中，我探讨了本体定义、企业数据、语义模型和 AI 推理如何建立对业务信息的共同理解。Snowflake 现在推出了一款Business Ontology产品，用于受治理的业务定义（即将公开预览）。

本文在此基础上进一步提出一种Snowflake 运营本体参考架构。它将受治理的业务含义与运营状态、约束、仿真、AI 推理和受控操作连接起来。

目标是建立一种可复用的模式。仓库、供应链网络和数据中心需要不同的运营模型，但它们可以共享架构契约和通用的决策生命周期。

1. 什么使本体具备运营性？

本体定义领域中的概念、关系和语义。在我们的仓库示例中，本体定义了包装站、工人、订单和承运商承诺，以及诸如工人操作站点、站点处理订单等关系。

该模型解释了 PB-04 故障为何重要。但它本身并不能告诉我们，将一名工人转移到另一个站点是否会改善运输结果。

运营本体通过扩展领域模型，加入评估和治理变更所需的语义。这里，运营语义是指治理真实资源如何变化的业务规则：它们能做什么、适用哪些限制，以及允许哪些干预。（这不是同名的编程语言术语。）

这些要素将业务含义与运营行为连接起来。

本体定义某个操作意味着什么以及适用哪些规则。决策服务评估其后果。执行服务执行经授权的变更。

关键的架构原则是将含义与行为分离，同时通过显式契约将它们连接起来。

2. 运营本体参考架构

所提出的框架包含六项能力。

1. 受治理的含义提供业务实体、指标和关系的一致定义。
2. 运营状态捕获当前和历史状况，包括时间戳、版本和来源。
3. 运营语义定义能力、约束、策略和操作类型。
4. 决策服务验证拟议变更，并通过仿真、预测或优化评估备选方案。
5. AI 推理使用 Cortex Agents 调查问题、调用工具并解释建议。
6. 受治理的执行与验证处理审批、操作分发、观测和结果评估。

这些能力共同支持一个通用的决策生命周期：

观察 → 理解 → 评估 → 决策 → 执行 → 验证

该架构在不同应用之间保持一致。每个领域提供自己的规则、行为模型和执行适配器。

图 1 展示了这六项能力如何在 Snowflake 上协同工作。含义、状态和语义为决策服务和 Cortex Agents 提供输入。只有受治理的过程才会将操作分派到外部系统，而观测到的结果会回流到运营状态中。

3. 在 Snowflake 上实现该框架

Snowflake 提供实现该架构所需的数据、元数据、计算、AI 和治理能力。

流和任务在受支持的源上为这些能力提供异步处理。

以下小节重点介绍每项能力特有的设计选择。

受治理的含义：Business Ontology

（Business Ontology 即将公开预览。）

Snowflake 新的Business Ontology是 Horizon Catalog 的一部分，为业务术语、指标、实体和关系提供由管理员治理的层。

概念可以绑定到表示它们的 Snowflake 表、视图、列和语义视图。

例如，包装站、工人、订单和承运商承诺可以在仓库管理、劳动力和运输系统中拥有一致定义。

Business Ontology 与语义视图（定义可执行的分析指标）以及 Cortex Sense（预览版，有助于为尚未完全建模的数据推导上下文）互为补充。

Business Ontology 治理含义。运营语义和服务提供决策与操作所需的规则和行为。

它建模的是概念而非实例，并且不执行规则或操作。这表明了明确的分工：

• 在 Business Ontology 中：对象类型，例如工人和站点（实体节点）、它们之间的类型化关系，以及命名约束和操作类型（通过诸如适用于等关系关联的术语）。
• 在 Snowflake 表中：对象本身、其当前链接、约束参数以及操作类型规范。

表示将每个概念绑定到实现它的表或视图，因此智能体可以从概念重新分配工作人员移动到定义其参数和审批策略的记录。

操作状态：标准和混合表

操作型应用需要历史上下文和对当前状态的可靠视图。

对于 PB-04，这意味着工位状态、工作人员分配、订单队列和承运商承诺。

标准表存储事件、事务和历史记录，是一个可靠的默认选择。混合表可以支持选定的、受益于索引点查找和强制键的事务性状态工作负载；（请注意，它们仅在 AWS 和 Azure 商业区域中可用）并且带有按数据库的存储和吞吐量配额。

一种应用结构可能如下：

ONT   Operational Ontology  Constraint parameters and action-type specifications,
                            keyed to Business Ontology concepts (plus object types
                            and relationships where Business Ontology is not used)
LIVE  Live State            Current state, assignments, active commitments
SIM   Simulation            Scenarios, proposed plans, projected outcomes
DEC   Decision              Proposals, approvals, commands, observations

这些是应用定义的架构。

分离 LIVE、SIM 和 DEC 可以防止假设性变更与实际操作混淆。

每个操作快照都应携带状态版本、观测时间和来源信息。模拟结果还应标明用于生成它们的快照和模型版本。

操作语义：能力、约束和操作

操作模型定义了资源能做什么以及适用哪些规则。

在我们的仓库中，这些包括工作人员资质、工位容量、订单处理要求和发货截止时间。

诸如 REASSIGN_WORKER 和 REROUTE_ORDERS 之类的操作类型描述了参数、前置条件和预期状态转换。

这些定义可以存放在受治理的 Snowflake 表和视图中，并链接到规范业务概念。

执行处理器应被显式注册并测试。元数据不应变成任意可执行代码。

同一组规则应同时用于模拟和执行验证，因此规划期间被认为可行的操作在派发前要接受一致的检查。

决策服务：使用 Snowpark 进行模拟

模拟回答了一个仅靠本体无法回答的问题：如果我们改变某些东西会发生什么？

对于 PB-04，资源调度引擎可以使用处理速率、容量、队列大小和承运商截止时间来比较人员配置和路由计划。

Snowpark Python 存储过程可以在接近 Snowflake 数据的地方实现这些计算。要求更高的模拟可以通过 Snowpark Container Services 托管的专用服务运行。

一个常见的应用接口可能如下：

result = simulate(
    snapshot=current_state,
    actions=proposed_plan,
    constraints=operational_rules
)

这是一个概念性接口，而非 Snowflake 内置函数。在实践中，它可能是某个 Snowpark Python 存储过程的签名，该过程读取 LIVE 快照并将结果写入 SIM。

模拟返回可行性、预计结果、约束违反情况、假设以及模型版本信息。

结果应归属于隔离的场景上下文，且不得修改权威操作状态。

并非每个操作都需要模拟。简单的变更可能只需要验证。当决策涉及相互竞争的目标、不确定性或下游影响时，模拟最为有用。

AI 推理：Cortex Agents

Cortex Agents 提供主要的 AI 编排层在此架构中。

结构化问题基于 Snowflake Semantic Views。Cortex Search 提供对操作程序、策略和事件报告的访问。自定义工具将智能体连接到本体关系、验证服务和模拟。

仓库经理问道：

“我们如何保障下午 5:00 的承运商发车？”

智能体检索操作指标、识别受影响的订单、查阅相关程序，并请求对可行恢复计划进行模拟。

如果经理添加约束，例如“保持 PB-03 人员满编”，智能体可以请求另一次评估。

智能体解释各个选项。操作服务仍负责计算、可行性检查和授权。

受治理执行：写回与验证

模拟评估可能的变更。受治理写回将已批准的决策连接到操作系统。

应用可以公开类型化的 Snowflake 存储过程，用于提议、批准、派发和验证操作。

例如：

SP_PROPOSE_DECISION(...)
SP_APPROVE_DECISION(...)
SP_DISPATCH_ACTIONS(...)
SP_VERIFY_OUTCOME(...)

这些是示例性应用过程，而非 Snowflake 内置函数。

在提议和派发之间有一个人工授权关卡：智能体可以提议，但只有获得授权的角色才能批准。

执行路径应强制执行授权、操作参数、当前状态版本和幂等性。

随后适配器将已批准的请求发送到负责系统，例如 WMS。Snowflake 保留决策记录、命令历史、确认和观测结果。

流和任务可以在支持的源上支持异步处理。混合表不支持流，且触发的任务无法监视它们，因此保存在混合表中的状态变更需要受支持的事件源（例如，标准表上的事件表或发件箱表）或由应用管理的调度器。对于低延迟外部命令，应用服务或 SPCS 托管的适配器可能更合适。

命令接受与操作完成之间的区别很重要。WMS 接受重路由请求并不能证明订单已被重新分配。

验证需要观测到的证据。

闭环处理 PB-04

以下是下午 1:30 故障的生命周期如何展开。下面的计划和步骤是示例性的。

1. 观察。LIVE 显示 PB-04 不可用，其订单队列相对于下午 5:00 的承运商承诺不断增长。
2. 理解。本体将 PB-04 链接到排队订单、合格工作人员以及可以处理相同订单类型的工位。
3. 评估。智能体请求对候选计划进行模拟，例如：

• 计划 A：将两名合格工作人员从 PB-03 重新分配到 PB-02。
• 计划 B：在不调动工作人员的情况下，将 PB-04 的队列重新路由到 PB-01 和 PB-02。
• 计划 C：将一个部分改道与一次工作人员重新分配相结合。
• SIM 中的每个结果都会记录其可行性、下午 5:00 的预计就绪状态、任何约束违反情况，以及它所使用的快照和模型版本。

4. 决定。经理补充“让 PB-03 保持满员配置”，这使方案 A 变得不可行。智能体解释了 B 与 C 之间的权衡，经理通过 SP_APPROVE_DECISION 批准了方案 C。

5. 执行。 SP_DISPATCH_ACTIONS 检查状态版本是否仍与模拟一致，然后使用幂等键将 REROUTE_ORDERS 和 REASSIGN_WORKER 命令发送至 WMS。WMS 对两者均予以确认。

6. 验证。 确认并不等于完成。SP_VERIFY_OUTCOME 将观测到的分配和队列深度与模拟预测进行比较，记录差异，并且只有当订单被确认已准备好交付给承运商时，才将该决定标记为已验证。

每一步都会留下记录：问题、所考虑的模拟、排除方案 A 的约束、审批者、命令以及观测到的结果。

图 2 总结了这一循环，并以 PB-04 示例为中心。

4. 使架构可复用的四项契约

当应用程序无需重建相同的基础设施即可采用参考架构时，参考架构才会变得有用。

我们提出四项逻辑契约。

这些契约定义了组件之间如何通信，而不规定特定领域的算法。

模拟契约可以支持仓库调度、供应链分配或数据中心热建模。操作契约可以支持 WMS 命令、ERP 事务或基础设施管理请求。

验证契约区分已接受的指令与已确认的变更。

为使这一点具体化，PB-04 计划的 Action 记录可能包含如下字段（示例性）：

action_type      REASSIGN_WORKER
parameters       { worker_id: W-117, from_station: PB-04, to_station: PB-02 }
preconditions    worker qualified for PB-02; PB-02 below capacity
state_version    LIVE snapshot used by the approved simulation
policy           requires OPS_MANAGER approval
approval         approved_by, approved_at
idempotency_key  decision_id + action sequence

其 Verification 记录说明了为什么接受并不等同于完成：

action           REASSIGN_WORKER (W-117 → PB-02)
command_status   ACKNOWLEDGED by WMS at 1:42 PM
expected_effect  W-117 at PB-02; 42 orders ready by 5:00 PM
observed_state   W-117 at PB-02; 41 orders ready at 5:00 PM
outcome          VERIFIED_WITH_VARIANCE
forecast_variance    −1 order (held for an inventory shortage)

WMS 于下午 1:42 确认了该命令，但该决定直到下午 5:00 才根据观测到的状态被验证。差异会反馈到模拟模型中。

共享契约和决策生命周期。特化运营模型和执行逻辑。

5. 在三个领域应用该框架

我们正在通过 Snowflake 上的三个参考应用来探索这一架构。

这些领域模型各不相同，并且它们应当保持不同。

通用模拟引擎不应尝试使用相同的算法来建模供应链物料流、仓库资源调度和数据中心热行为。

可以共享的是运营契约、状态版本控制约定、决策生命周期、治理模式以及 Cortex Agent 工具接口。

这些应用是正在开发中的合成参考实现。它们展示的是架构，而非与物理企业系统的生产集成。

图 3 展示了哪些是共享的，哪些是特化的。

6. 这对企业 AI 智能体意味着什么

随着企业智能体获得能够改变运营状态的工具访问权限，它们需要可靠的数据、明确的约束、可信的评估服务以及受控的操作接口。

该框架将这些职责分配给独立的组件。

智能体进行调查并提出建议。决策服务评估可行性和后果。操作服务强制执行授权和策略。执行系统执行操作。观测确立结果。

这种分离使决策更容易被审查。

被拒绝的计划可以指出被违反的约束。模拟可以暴露其假设。已执行的操作可以追溯到其请求者、审批、命令以及观测到的结果。

它还在不限制智能体帮助人们做出决策的能力的前提下，限制了智能体的权限。

7. 从运营本体到数字孪生

运营本体提供了支持决策所需的含义、约束和操作契约。

数字孪生在此基础之上构建，包含对运营状态和随时间变化的行为的表示。

在我们的仓库中，本体决定了哪些人员配置和路线变更有效。数字孪生可以预测队列如何演变、可视化设施，并将预测与观测到的结果进行核对，在供应链和数据中心领域也是如此。

通用架构保持一致：

受治理的含义 → 运营状态 → 可行的决策 → 受治理的操作 → 已验证的结果

Snowflake 提供数据、语义、AI、计算和治理能力。领域特定服务提供运营行为。

在下一篇文章中，我们将探讨该框架如何支持 Snowflake 上由 AI 驱动的数字孪生，以审视时间状态、模拟、可视化和已验证的结果。

参考资料

Snowflake 上的本体

Snowflake 业务本体（即将公开预览）

Cortex Sense（即将公开预览）

企业世界模型：为智能体提供可操作的世界

关于作者：Tianxia Jia 是一位 AI 与云专家，专注于在 Snowflake 和 AWS 上架构前沿的 AI/ML 解决方案。

Snowflake 上的运营本体：从业务含义到受治理的 AI 操作最初发表于 Snowflake Builders Blog：数据工程师、应用开发者、AI 与数据科学 在 Medium 上，人们通过高亮并回应这个故事来继续对话。