MCP 解决连接，RAG 解决知识，那谁来解决业务理解？一文讲透企业 AI 的“本体论”

AI 会做事，不等于 AI 知道自己应该做什么。

大模型已具备读取文档、编写代码、查询数据库及调用 API 的能力，结合 MCP、Agent 和 Workflow，看似能独立承担复杂任务。然而，将其置于企业生产环境时，核心矛盾显现：

以“VIP 客户”为例，通用模型理解词汇含义，却无法知晓特定企业的定义标准（如按采购额、战略价值或审批流程）。同理，ERP、WMS 中的“库存”概念各异，包含在途、锁定或冻结状态，并非所有记录均可发货。

企业 AI 的难点在于：模型需基于真实业务事实、规则及权限约束作出判断，而非仅生成语言答案。这正是 Ontology（本体）值得深入探讨的原因——它旨在将分散的数据、业务对象、关系、规则及可执行动作，组织成 AI 可理解并参与的业务世界。

以阀门制造企业为例，客服 Agent 收到查询：“订单 A1024 能否加急发货？”

ERP 与 MES 均返回状态 ALLOCATED。若仅凭字符串匹配，模型易误判为“已分配，可发货”。但实际上，ERP 中的 ALLOCATED 可能指原材料已分配，而 MES 中指生产任务已排期。两者均不意味成品已入库或可发货。

若 Agent 将不同系统中的相同字段视为等同，可能导致无货可发却承诺发货的严重错误。这并非简单的幻觉，而是模型将“语言相似性”误作“业务等价性”，未能理解字段背后的业务含义。

判断订单 A1024 是否可加急发货，需综合考量：

• 客户加急资格（CRM）；
• 成品库存充足性（WMS）；
• 质量检验状态（QMS）；
• 订单当前状态及出库权限（ERP/OMS）；
• 仓库截单时间及其他订单占用情况。

这些信息分散于各系统，数据结构与定义各异。单一系统的正确数据，在跨系统决策中未必成立。例如，库存充足不代表未被冻结，质检通过不代表允许出库。

企业 AI 的挑战不在于数据量，而在于让模型理解业务上下文：订单归属、关联产品、库存真实状态、发货规则及允许执行的动作。这正是 Ontology 的核心价值。

知识图谱侧重实体与关系（如“客户 A 拥有订单 B”），回答“有哪些实体及关系”。但对于企业 AI，仅知关联不足以支撑决策（如订单是否可发货、VIP 有何特权）。

从企业 AI 工程视角，Ontology 可定义为：

Ontology = 业务对象 + 关系 + 业务语义 + 状态 + 逻辑 + 受控操作

其包含六个关键部分：

1. Object：业务对象

客户、订单、产品等不仅是数据库记录，更是业务人员关注、操作的对象。

2. Property：业务属性

映射底层字段，但呈现统一的业务含义（如订单金额、交付日期）。

3. Link：业务关系

连接孤立数据，明确对象间的关联（如订单关联哪些库存）。

4. State 与 Logic：业务状态和逻辑

明确状态的含义、来源及判定规则（如“可用库存”的定义）。

5. Function 与 Action：业务计算和操作

区分“计算结果”与“改变业务状态”的操作（如创建排产任务、提交发货申请）。

6. Security 与 Governance：安全和治理

明确读写权限、审批流程及审计机制，由权限体系保障，而非依赖模型自行判断。

Ontology 将对象、规则与操作连接，使 AI 能在明确的业务边界内工作。

三者解决不同层面问题，互为补充：

1. RAG：让 AI 找到需要的知识

解决“知识在哪里”的问题，从文档中检索信息。但它无法直接验证业务条件是否满足（如检索到规定不代表库存充足）。

2. Workflow：让流程按照确定的步骤执行

解决“执行步骤”的问题，编排固定流程。但随着规则复杂化，Workflow 易陷入嵌套条件判断，需清晰边界分离流程与业务规则。

3. Ontology：让系统知道流程中操作的究竟是什么

解决“业务对象与语义”的问题，提供统一的对象定义、关系及逻辑。Workflow 依赖 Ontology 获取准确的业务上下文。

总结：

• RAG 负责找到知识；
• Ontology 负责组织业务对象、关系和语义；
• Workflow 负责编排任务和执行步骤。

成熟的企业 AI 系统往往三者共存，协同工作。

引入 Ontology System 后，处理“订单 A1024 能否加急发货”的流程如下：

STEP 01：识别业务意图

LLM 理解用户需判断加急发货条件。

STEP 02：定位业务对象

系统找到订单 A1024，关联客户、产品、库存、质检及生产任务。

STEP 03：读取当前业务事实

从可信源读取实时数据：客户等级 VIP，需求 20 件，可用成品库存 10 件，质检 PASS。

STEP 04：执行业务规则

依据规则“可用成品库存 ≥ 订单需求”进行判断。10 < 20，故不满足直接加急发货条件。

STEP 05：给出有依据的结论

Agent 告知库存不足，缺 10 件，并建议创建加急排产任务。

STEP 06：执行受控操作

若用户同意，系统校验权限、参数及审批要求后，调用 Action 创建任务，并核验结果、记录审计。

全流程：理解意图 → 定位对象 → 获取事实 → 执行业务规则 → 形成决策 → 权限校验 → 审批与执行 → 结果核验。

传统系统中，业务规则常分散于代码、SQL 或配置中，难以维护。例如，VIP 客户加急发货的逻辑硬编码在程序中，业务人员难以直接理解或调整。

Ontology 允许将规则独立建模：

当规则变更（如截单时间调整），可通过配置完成，无需重新开发发布。当然，规则仍需版本管理、测试及审批，复杂逻辑仍需代码实现。

触发业务操作的 AI 决策必须具备可追溯性。出现问题时，企业需知晓：

• 判断依据的事实及数据来源；
• 使用的业务规则及其有效性；
• 操作发起人、审批情况及最终执行结果。

真正的可解释性源于可追溯的数据、明确的规则及执行记录，而非模型生成的自然语言解释。

以 A1024 为例，系统应保留如下决策记录：

• 决策结果： 不满足直接加急发货条件。
• 关键事实： 需求 20 件，可用库存 10 件，质检 PASS。
• 判断规则： 可用库存需 ≥ 订单需求。
• 判断过程： 10 < 20，条件不成立。
• 执行记录： 是否创建任务、批准人及系统反馈。

为确保安全，应将意图生成与最终执行分离：

1. LLM 提出 Action Request： 结构化表达操作意图。
2. 执行平台校验： 检查对象存在性、参数合法性、权限、业务状态及规则，必要时介入人工审批。
3. 执行与核验： 调用受控接口，验证结果并记录审计。

Ontology 需明确操作边界，支撑安全的 Agent 执行。

Ontology 不替代 ERP、CRM 等业务系统，后者仍是权威数据源。Ontology 负责映射数据，提供统一语义访问。

需注意数据同步延迟及冲突。例如，当 ERP 与 WMS 库存数据不一致时，系统需依据权威性原则处理，而非随意选择。

MCP 标准化了 Agent 连接外部工具的方式，降低了开发负担。但连接成功不等于理解业务。

Agent 调用 update_order 时，仍需 Ontology 提供业务上下文：修改哪张订单、当前状态、影响范围、权限及异常处理。

MCP 解决工具交互，Ontology 组织业务对象与规则。两者结合，Agent 可使用统一定义的业务对象和 Action，但仍需依靠工具设计、认证授权及审计机制保障安全。

并非所有场景都需要完整 Ontology。简单问答或文档生成仅需 RAG 或基础 Workflow。

Ontology 适用于多系统、多对象、复杂规则且涉及真实操作的场景（如供应链调度、库存分配）。此类场景特点：

1. 数据分散；
2. 概念定义不一；
3. 决策依赖多对象状态；
4. 触发真实操作；
5. 需满足权限与审计要求。

应避免“本体博物馆”现象：构建庞大模型却无实际业务流程使用。建议从具体场景（如订单加急）入手，建立必要对象、规则及 Action，验证判断、追溯及执行能力后，再逐步扩展。

企业 AI 正从以模型为中心转向重视业务对象、语义、规则及受控执行的体系。各组件分工明确：

• LLM： 理解意图、规划任务；
• RAG： 检索知识；
• Ontology： 组织业务对象与语义；
• Logic： 执行业务规则；
• Workflow： 编排流程；
• Action： 执行受控操作；
• Governance： 权限、审批与审计。

关键在于不让大模型承担所有责任：事实来自可信数据源，执行经过校验，审计基于真实记录。

回到订单 A1024，真正的业务参与不仅是回答“可以加急”，而是找到订单、关联多方数据、依据规则判断、说明依据、授权执行并确认结果。

Ontology 为此提供了业务基础，使 AI 理解对象、关系、状态及行为边界，从而成为可靠的业务参与者。