企业本体不是给数据再贴一层标签，而是把企业中的对象、事件、关系和规则定义成一套可以共同使用的业务语义。当这些定义通过语义层映射到表、字段、指标或 API，Data Agent 才能知道用户说的“客户”、“买了”、“上个月”和“销售额”分别指什么，并沿着可追溯的路径查询数据。本文只回答一个问题：本体如何帮助 Data Agent 理解企业业务。
业务人员问：
上个月高价值客户买了哪些商品？
人会凭经验补全许多默认条件，系统却必须把它们逐项说清楚。
| 用户表达 | Data Agent 必须确认的业务含义 |
|---|---|
| 高价值客户 | 按收入、利润、会员等级，还是企业制定的综合规则判断 |
| 买了 | 指下单、支付成功、签收完成，还是收入确认 |
| 上个月 | 采用自然月还是企业财务月，使用哪个事件的时间字段 |
| 商品 | 按 SKU、SPU、品类还是产品线汇总 |
| 销售额 | 使用应付、实付、含税金额，还是扣除退款后的净销售额 |
如果系统根据字段名临场猜测，同一句话可能在不同时间、不同系统或不同提问方式下走向不同的查询。真正需要稳定下来的，不只是 SQL，而是 SQL 之前的业务解释。
本体的作用，就是把这些默认存在于业务人员经验中的解释显式化，并让不同系统、不同应用和不同使用者共享同一套定义。
在知识工程中，本体（Ontology）用于形式化描述一个领域中的概念及其关系。进入企业数据场景后，可以先抓住四类最基本的内容：
| 建模内容 | 回答的问题 | 零售示例 |
|---|---|---|
| 对象 | 企业持续识别和管理什么 | 客户、订单、商品、门店 |
| 事件 | 围绕对象发生了什么变化 | 下单、支付、发货、退款 |
| 关系 | 对象与事件怎样连接 | 客户提交订单、订单包含商品 |
| 规则 | 什么条件下一个业务判断成立 | 有效订单、高价值客户、退款率 |
这四类内容搭起业务世界的骨架。要让它真正服务 Data Agent，还需要补齐一组工程要素：对象身份、事件时间、指标口径、数据来源、映射规则、权限范围和版本记录。
例如，“客户”在 CRM 中可能是销售跟进对象，在财务系统中可能是付款或开票主体，在客服系统中又可能是实际使用者。本体不会简单把三个同名字段合并，而是先说明它们分别代表什么、是否属于同一对象、用什么身份关联，以及这种关系在什么时间范围内有效。
因此，本体的重点不是让概念看起来更完整，而是让可能改变答案的业务选择变得明确。
一份术语说明文档本身不会自动改善问数效果。本体定义必须进入问题解析和查询执行，才能成为 Data Agent 的运行时能力。
flowchart LR A[自然语言问题] --> B[识别对象、事件、关系和时间] B --> C[匹配企业口径与用户权限] C --> D[形成结构化语义] D --> E[映射表、字段、指标或 API] E --> F[执行查询] F --> G[返回答案、口径与来源]
这条链路中，本体化语义层主要承担四项工作：
假设企业已经确认：“买了”表示订单完成支付，“上个月”使用付款完成时间，“商品”按 SKU 汇总，“净销售额”按行级实付减去截止某时刻的成功退款计算。那么系统可以沿一条稳定链路执行：
高价值客户规则 → 客户身份 → 客户提交的订单 → 订单完成支付事件 → 订单包含的商品明细 → 行级实付与退款规则 → 按 SKU 汇总
如果企业把“买了”改成签收完成，系统使用的事件、时间和订单范围也应随版本一起变化，而不是由模型自行猜测。
如果要理解企业本体怎样从概念进入实际业务，Palantir Ontology 是一个具有代表性的行业实践。Palantir 官方在 Ontology Overview 中（https://www.palantir.com/docs/foundry/ontology/overview）把 Ontology 定义为组织的“操作层”：它位于数据集、虚拟表和模型等数字资产之上，把这些资产连接到工厂、设备、产品、客户订单和金融交易等现实对象。在许多场景中，它也构成组织的数字孪生。
这套 Ontology 同时包含两类元素：Objects、Properties、Links 等语义元素，用来描述企业世界；Actions、Functions 和动态安全等可操作元素，用来把业务逻辑和受治理的动作接入工作流。这说明，企业本体不只回答“企业里有什么”，还可以进一步组织数据、逻辑、动作和安全边界，让人和 AI Agent 在同一套业务语境中协作。
对国内企业而言，值得借鉴的不是复制 Palantir 的整套平台，而是这条工程原则：先把业务对象、事件、关系和规则说清楚，再把它们连接到真实数据、权限与执行路径。Palantir Ontology 是 Palantir 对企业本体的产品化实现，并不等同于本体的一般定义；亿问也不是照搬其架构，而是在可信问数场景中通过 SemanticDB、Alisa、LogicForm 和受控执行链路，让 Data Agent 按企业自己的定义理解和查询数据。
在亿问 Data Agent 的技术架构中，自研 NL2LF2SQL 引擎 Alisa 将自然语言问题转换成 LogicForm（逻辑形式）；SemanticDB 根据企业语义与物理映射，把 LogicForm 映射为 SQL、API 或 URL 等执行目标；执行层在权限与审计边界内完成调用并返回结果。
可以把这几个组件理解为不同分工：
本文只讨论分析链路。创建订单、修改库存、发起付款等会改变业务状态的动作，还需要单独定义授权、审批、审计、失败处理和回退机制，不能因为系统能够理解问题就自动获得写权限。
本体更适合处理以下问题：
如果任务只是查询一张表上的固定指标，现有数仓、指标模型或报表可能已经足够。是否建设本体，应由问题价值、语义复杂度、现有资产和长期维护成本共同决定。
如果把目光放得更长远，我们认为，在 AI 时代，本体建设的重要性将愈发凸显。随着 AI 从“理解语言”走向“理解业务并执行任务”，只有建立统一、清晰的业务概念、指标口径和关系体系，才能让 AI 更准确地理解企业数据与业务语义，并在复杂场景下持续输出可信、一致的结果。
数据字典通常解释表、字段和取值；本体进一步定义业务对象、事件、关系和规则，并说明这些定义怎样跨系统成立。两者可以互相补充，但数据字典通常不能单独回答“买了对应哪个事件”“某段关系何时有效”这类问题。
不一定。OWL 是表达本体的一种标准化技术，图数据库是保存和查询关系的一种实现。企业也可以使用轻量元数据模型、领域 DSL 或配置规则。关键是业务定义能否被共享、映射、执行和维护。
本体是一种业务建模方法。企业世界语义层描述 Data Agent 需要具备的完整语义范围；本体化语义层则强调用对象、事件、关系和规则等方式建设这套语义。具体产品还要补齐指标、权限、数据映射和执行能力。
Data Agent 要理解企业，不能只认识字段名，也不能把业务口径交给模型临场推断。AI 越深入业务，本体建设就越重要，因为它决定了 AI 能否真正理解企业语义，并持续输出准确、可信、一致的结果。
企业本体先把对象、事件、关系和规则定义清楚，再由语义层连接真实数据、权限和执行路径。它最终解决的不是“如何把概念画得更完整”，而是让同一个业务问题能够被稳定解释、执行和复核。