为什么企业 AI 越来越需要 Ontology？从 Object、Link 到 Action 全解析

AI 知道该调用哪个接口，不代表它理解这件事在企业里意味着什么。

许多团队在探索企业 AI 时，往往遵循“接入大模型 + 知识库 + Tools + Agent”的路径。虽然 Demo 演示顺畅，但在真实业务场景中，一旦涉及退款、库存调整或生产任务重排等复杂操作，问题便随之显现。

AI 能查询 CRM 或数据库，但缺乏对业务上下文、规则约束、权限控制及系统间影响的理解。这正是企业 AI 从“问答助手”迈向“业务参与者”的核心瓶颈。

在此背景下，Ontology（本体）概念备受关注，尤其是 Palantir 将其置于企业数据与 AI 平台核心位置后，业界开始重新审视：在已有数据库、数据仓库和知识图谱的基础上，为何还需要 Ontology？它与 Agent 又有何关联？

本文将深入探讨 Ontology 的核心概念、其与知识图谱的区别，以及它如何赋能企业 Agent 实现从描述业务到改变业务的跨越。

以零售企业为例，尽管拥有 CRM、ERP、订单、库存等多套系统且数据互通，但当业务负责人提出“查清客户张三订单未发货原因并尝试调货”的需求时，背后涉及跨系统的数据检索、状态判断、规则校验、权限确认及状态更新等一系列复杂流程。

传统数据平台主要解决数据存储与交换，而业务规则、权限和操作逻辑往往分散在各系统中。人类可凭经验串联这些信息，但 AI 无法仅通过 API 接入自动获得这种能力。

Palantir 将 Ontology 定义为组织的“数字孪生”，旨在将数据、业务概念和逻辑组织起来，使人、应用及 AI 能围绕同一套业务对象进行理解、分析和操作，从而支持受控的业务决策与执行。

Ontology 在计算机科学中指对领域概念、关系及约束的明确形式化描述。在企业语境下，它是将业务共同理解转化为系统可识别、查询和使用的模型。

不同部门对同一概念（如 VIP 客户）可能存在不同定义，若口径不统一，AI 易得出矛盾结论。Ontology 首要解决的是业务语义统一问题。

需注意，主数据管理、语义层、领域模型及知识图谱也能承担部分工作。Palantir Ontology 的特点在于不仅止步于概念和关系，更进一步连接业务对象与操作、逻辑和权限。

这些技术并非互斥，可共同构成企业 AI 基础设施。关键在于企业是否需要一个贯通业务语义与操作的统一模型。

数据库 Schema 规定数据结构，是基础但非全部。业务人员更关心业务语义和规则，如订单归属、库存充足性、取消条件及后续处理等。

企业建模可粗略分为四个层次：

1. Vocabulary（词汇）：统一业务术语。

2. Taxonomy（分类）：组织概念分类。

3. Schema（结构）：定义数据结构。

4. Ontology（本体）：组织对象、关系与规则，支持业务操作。

Schema 解决数据结构，Ontology 则在之上建立面向业务理解和操作的统一表达。

Object：业务对象

Object 是现实业务中需单独识别和操作的实体或事件（如客户、订单、商品）。需区分 Object Type（类型结构）与 Object（具体实例）。相比数据库记录，Ontology 中的对象可通过统一身份、属性和关系关联更多业务动作。

Property：属性

描述对象特征。除直接来自底层系统的字段外，还包括计算属性（如风险评分、可用库存）。系统向上层提供统一定义的业务属性，减少重复建模。

Link：关系

表达对象间的业务关系（如客户下单、订单含商品、商品由仓库供货）。Link 使系统能沿业务关系查询信息，将底层表关联转化为可复用的业务关系，降低应用开发复杂度。

三者组合构建了业务世界的雏形，但仍未解决“什么可以发生”的问题。

业务规则决定了操作的有效性。在 Palantir Ontology 体系中，Action 概念至关重要。

API 仅解决系统调用，而 Action 解决业务操作的定义、校验和执行。例如，“修改客户等级”不仅是数据写入，还涉及权限、条件判断、审批流及审计记录。

Action 作为明确的业务单元，包含参数、前置条件、权限、执行逻辑、后置处理及审计信息。这使得业务动作能被应用和 AI 统一使用，其重要性远超简单对接接口。

Function：复杂业务逻辑计算

负责非简单字段修改的计算逻辑（如风险评分），输出结果供系统或 Agent 使用。

Interface：统一抽象

描述不同 Object Type 共享的结构或能力，使应用和 Agent 能以一致方式交互，降低扩展成本。

Role：权限控制

控制系统对 Ontology 资源和能力的访问。企业 Agent 不应拥有超级权限，每次操作均受身份、权限和规则约束。

知识图谱侧重组织实体、关系和事实；Ontology 侧重定义概念、关系、约束及逻辑。两者紧密联系但非等同。

Palantir Ontology 超越传统图谱模式，将业务对象与 Action、Function 及权限关联，为业务应用提供统一入口。

传统 Agent 架构直接调用 API，但在跨系统理解对象、判断状态及执行规则时面临挑战。若缺乏可信的系统机制提供业务约束，模型仅靠零散信息判断极易出错。

Ontology 提供业务抽象层，使 Agent 围绕业务对象查询并通过明确 Action 申请执行，底层集成由平台处理。

RAG 擅长从文档检索信息，但面对需改变真实业务状态的任务（如重新安排会议）时，仅靠检索不够。完整的企业 AI 系统需各司其职：

• RAG：检索非结构化信息。
• 数据平台：提供可靠数据访问。
• Ontology：组织业务对象、关系及操作。
• Workflow：管理多步骤流程。
• Agent：理解需求、推理并选择行动。
• 权限与审计：约束业务操作。

企业 AI 正从“回答问题”扩展到“在真实业务约束下完成任务”。

场景：订单 A1024 库存不足，需处理。

1. 识别对象：Agent 根据订单号找到 Order 及关联 Product，确保对象唯一性。

2. 查询状态：通过 Link 找到 Warehouse 及库存信息，确认可用库存（注意区分总库存与可用库存）。

3. 寻找方案：查询其他仓库库存，提出调拨候选方案，并校验物流、权限及审批阈值。

4. 申请执行：构造 TransferInventory Action 参数，由平台校验前置条件与权限。如需审批则流转，失败则反馈原因。

5. 验证结果：执行调拨，更新库存及订单状态，通知相关人员并记录审计日志。操作完成后核验实际状态，形成闭环。

Ontology 建设应避免过度复杂化。有价值的建模需关注：

1. Object 真实性：是否对应真实业务概念，而非临时中间表。

2. Link 有效性：关系是否有明确业务含义及使用场景。

3. Action 业务性：是否对应具体业务职责和结果，而非单纯技术操作。

AI 从只读走向写入，风险显著增加。Action 设计需关注：

• 单一职责：避免高风险操作隐藏其中。
• 幂等性：防止重复执行导致错误。
• 参数校验：由系统逻辑检查合法性。
• 权限控制：系统验证而非模型判断。
• 状态一致性：处理并发、部分成功及补偿。
• 审计追溯：记录操作全貌。
• 人工介入：高风险场景保留人工审批。

简化架构如下：

Foundry 解决数据接入，Ontology 组织业务世界，AIP 赋予 AI 业务能力。Ontology 为数据治理和系统集成提供了重要的组织方式，但非工程捷径。

建议从一个具体的业务闭环开始，而非构建全景大图。

1. 选场景：高频、高价值、数据可得、失败成本可控。

2. 识对象：列出支撑闭环的最小对象集合。

3. 理关系：明确数据来源、实体识别及系统关联。

4. 定规则：由系统逻辑执行关键业务规则。

5. 设 Action：定义输入、条件、授权及结果，初期可采取“AI 建议+人工确认”模式。

6. 跑闭环：关注任务完成率、失败率、人工介入比例等业务指标。

简单查询或报告生成无需完整 Ontology。但若涉及跨系统复杂对象关系、统一业务规则及状态修改，统一语义与执行模型极具价值。

评估维度：

1. 是否存在大量跨系统业务对象和关系？
2. 是否反复实现同一套业务口径和规则？
3. Agent 是否需修改业务状态？
4. 是否需要统一授权、验证和审计？

若答案为是，Ontology 值得认真考虑。反之，若仅为追逐热点，收益有限。

企业 AI 的发展正从“回答问题”、“调用工具”迈向“在真实业务约束下完成工作”。Ontology 的意义在于构建一个 AI 能理解、系统能验证、权限能约束、操作能追溯的业务世界。

Ontology 正是构建这一世界的重要基石。