在AI技术深入企业应用的今天，许多项目却陷入投入大、见效微的困境。这背后，往往不是算法或数据的问题，而是AI缺少对业务逻辑的结构化理解，也就是本体的支撑。

本文将从企业AI落地面临的实效困境出发，梳理企业当前Agent困境与本体建模实践，并重点阐述如何通过构建业务事理与整合权威事实，为AI提供可理解、可执行的逻辑框架，使其真正赋能具体业务场景，推动企业智能化走向深入、走向实处。

分享嘉宾：Datablau数语科技创始人&CEO 王琤

内容已做精简，如需获取专家完整版课件和视频，请扫码领取。

---

01 企业AI正从浅层问答走向深度洞察

过去18个月，企业应用AI的认知经历了三个阶段的变化。

最初，AI被普遍视为由CIO主导的技术问题。随后，企业意识到需与自身流程结合，开始构建知识库与RAG应用，为各部门打造AI助手，进入初步探索期。

然而，这类浅层应用已无法满足当前需求。企业希望用AI深入分析全域KPI，但仅将报表数据灌入大模型，仍难获得真正的业务洞察，比如利润波动的具体归因与改进建议。

此时，仅靠RAG或人工编排的dify工作流已显不足。必须深入一步：既要用本体厘清业务逻辑，又要以扎实的数据治理确保事实准确。唯有两者结合，AI才能真正解决业务问题，创造价值。

所以企业都希望拥有一套清晰漂亮的AI战略，把AI真正用好、落地。

但现实往往是，问题出在更基础的数据质量。如果底层数据本身就有问题，输入错误的数据，AI自然无法给出正确的输出。

此外，如果业务定义不清晰，比如表中字段的中文名称或逻辑含义没有明确统一，那么指望AI准确地找到数据、并串联起深度洞察，其实是难以实现的。

在企业落地大模型的过程中，常常遇到幻觉、知识过期、安全、可解释性差等问题。其实，这些本质上都是数据治理要解决的事。

比如业务一致性：当业务问“某个产品上个月的利润怎么样”，就必须先明确，这里说的利润是毛利还是净利？分摊规则是什么？覆盖直销、渠道还是全部？

这些定义如果不在前期对齐，指标就无从谈起。

过去我们做报表、建指标时，就要反复澄清这些；如今面向大模型，不仅要澄清指标本身，底层明细数据的口径也同样需要明确。只有这样，大模型才有可能基于全域数据做深度洞察。

也就是说，得先建立起数据标准，把业务术语、业务概念定义清楚，再把带有上下文信息的数据喂给大模型。

如今的大模型以推理见长，因此关联关系至关重要。如果只是简单问数，或许还能基于某张宽表实现；但一旦问题变复杂，需要跨多张表关联查询，或涉及多个加工链路才能得出的指标，表之间如何连接、加工逻辑与指标公式是否一致，这些都要靠清晰的关联关系来支撑。

否则，大模型很难完成真正的深度分析与洞察。

当前，我们现在正经历着从中间状态向更理想状态的过渡与演进。

之前提到，将各个数据孤岛提供给智能体，或许能让它在某个单一业务领域内回答一些简单问题。但如果我们想打通财务域与生产域，去发现数据之间的动态关联与问题，仅靠某一个系统的数据孤岛是远远不够的。况且，这些数据孤岛往往缺乏足够的元数据描述。

在这个过程中，我们通常会引入一个语义层，将数据库中有哪些表、哪些字段，结合元数据及指标定义，系统地管理起来。这确实带来了一定程度的改进，比如大模型能据此编写一些SQL了。

但问题在于，这个语义层是否足够厚实？

当你进一步要求它做一些深度的业务解释时，它往往就无能为力了，因为它本质上仍是在机械地执行查询脚本。

而有了本体之后，我们对大模型的期待就完全不同了。我们希望它不仅能查数，更能做业务，这不只是执行查询这类相对表层的工作，而是能基于当前情况，自然地触发相应的业务行动。

这就像情报系统一样：当我发现某个特定组织有多人出现在同一地点，系统就应该自动触发威胁预警，这是一种直接触发业务行为的操作，与之前只能查询和简单回答的模式，有着本质的不同。

因此，大家需要深刻理解这张图所揭示的逻辑，我认为未来一定是这样的运行方式。

智能体的核心，在于它掌握的事实以及可调用的能力，以及MCP工具。

这里的事实是源自扎实的数据治理工作，确保为智能体提供最可靠、可信、唯一的数据来源。而事理则来自本体建模，它把清晰的业务逻辑赋予智能体。

这样一来，智能体便能在接收到数据时，理解应该如何根据业务逻辑进行判断，并知道通过MCP去调用既有的系统能力，从而触发并完成具体的业务行为。

这才是完整的运作闭环，也必定是未来的方向。

事实上，许多企业此前已经构建了不少AI助手。但在我们看来，那些应用大多仍停留在比较浅的层面，通常只能回答一些政策性问题，比如“某项费用能否报销、标准如何”。

然而，当企业需要真正驱动业务行为、开展深度业务协作时，仅靠问答是不够的。这时必须依赖本体的结构化描述，来支撑复杂的业务逻辑与决策。

过去，许多系统，尤其是早期的信息化系统，往往设计得相对僵化，主要扮演数据存储库的角色。

而今天的方向，是让系统不仅能存和看，更能基于业务逻辑动起来，真正参与到业务流程的自动执行中。这才是从存储数据到驱动业务的关键转变。

02 本体的核心在于让AI理解业务逻辑

在讲解本体的实际应用时，以金融行业的一个本体片段为例，选取其中一小部分来具体说明。

例如，图中定义了一个协议类。

在这个类中，包含一种称为约束的结构，其含义是：一份协议中必须包含至少一个或多个具体的承诺。这很符合业务实际，因为任何合同或协议，必然涉及对具体事项的承诺条款。

接下来，它还定义了协议与另一个类即参与方的关系。这对应着现实业务中合同的签署双方，明确了协议必须有明确的签署与履行主体。

通过这个简单的例子可以看出，本体的核心作用是将一个具体的业务概念清晰定义出来，并阐明它与其他相关概念之间存在怎样的约束与关联。这正是本体以结构化语言描述业务逻辑的方式。

我们回过头来看其他符号系统，比如ER图。其实它也在呈现类似的逻辑。

以这张ER图为例，这里有一个叫做“产品合约”的实体。一份产品合约可以关联多个合约条件，而一个合约条件又可以关联费用条件、利息条件、范围条件、列表条件等。这些本质上都是对业务概念之间关系的约束。

其核心思路，都是将最基础的业务概念拆解清楚，并阐明它们之间的约束关系。

不过，如今的本体建模还更进一步：它不仅描述静态的关系，还能表达与关系绑定的行为。

例如，一份合约在经历“签署”这个行为后，状态可能从未签约变为已归档，系统随后可能自动触发生成付款计划等后续动作。

这意味着，本体不仅能说清业务是什么，还能关联做什么，从而更动态地支撑业务执行与流转。

那么，为什么本体这件事令人如此兴奋？我们可以从业务系统的演进来看，这大致可以分为三个阶段。

第一代业务系统，核心是记录。

在信息化过程中，它主要承担信息录入的功能，比如记录公司今天收了哪笔款、明天付了哪笔钱。这个阶段可以概括为：存储与处理由机器完成，理解、决策与执行仍然完全依赖人。

第二代业务系统，则向前迈进了一步，不再只局限于记录。它开始具备一定的分析与辅助决策能力。

过去几年企业推进数字化转型时，出现的智能信贷、智能投顾等应用，就属于这个范畴，系统已经能够为我们提供分析参考，甚至完成一部分标准化的决策。

第三代业务系统，正是当前本体+大模型所指向的方向。

它的特点是融合数据、分析、决策，并能触发一部分自动化执行。人的角色进一步聚焦，只需处理少数需要沟通、判断或最终确认的行动。

未来，企业在设定与追踪KPI时，可能就是由大模型基于本体来直接分解和执行。而人更像一个终端执行者与协调者，例如在智能补货的超市里，理货员主要根据系统生成的指令进行货品摆放，而进什么货、如何摆放这些决策，早已由系统规划完成。

我们来看一个大家可能比较熟悉的例子：Plantir的本体平台。

如图所示，其核心架构清晰体现了这一运行逻辑：

位于中心的是本体，它负责接收流入的数据，并基于内置的业务逻辑进行识别与判断。

在此基础上，平台会触发相应的后续动作，可能会驱动一个工作流，也可能启动专项分析，或者直接调用系统能力自动执行具体任务。

这正是数据-逻辑-行动闭环的直观体现。

我们可以通过几个具体例子来理解这一点。

例如在反恐行动中，威胁识别系统的构建本质上也是一个设计过程。这再次强调，本体应用的核心在于设计。

进入大模型时代，全球顶尖的程序员可能不再是单纯编写代码的人，而是那些能将复杂业务需求描述得极其清晰的人。无论你是将清晰的指令交给大模型来生成代码，还是将其转化为本体直接交给大模型去执行业务，关键在于前期的设计。

未来，设计为王将成为主导模式。

具体而言，在前期的设计阶段，需要定义清楚涉及哪些实体，如人员、组织、地点、时间，以及它们之间的关联规则。

到了推理执行阶段，系统便能基于这些设计做出判断：例如，当监测到某个地点在72小时内出现五个属于同一组织的人员时，就会依据既定规则自动触发前端警报。

这就是一个从设计到自动响应的完整闭环。

另一个例子与我们近期关注的伊朗海湾地区事件相关，它涉及供应链风险管理。

同样，这也需要先进行设计与建模：明确定义供应商、物流路线、原材料、港口、政治事件等实体，并建立它们之间的关系规则。

一旦完成建模，系统就能够在推理阶段发挥作用。例如，当监测到某个重要港口或半导体工厂发生地震，系统便可自动推算出受影响的客户订单范围，并判断是否需要启动备用供应商进行补货。

这些业务逻辑都在本体中预先定义。当相关数据触发条件时，系统便会自动依据这些逻辑执行判断与响应，实现从事件感知到业务应对的自动化流转。

03 Plantir如何用本体构建自动决策的完整闭环

我们对Plantir Foundry平台也进行了初步的调研与了解。

该平台的核心架构主要包含三个部分：

首先是数据连接，平台能够接入来自各类数据库和系统的数据。其次是本体建模，这是核心设计层，用于定义业务概念、关系与逻辑。最后是数据血缘追溯，确保数据的来源、加工过程清晰可信，为基于本体的推理提供可靠基础。

这三层共同构成了从数据接入、业务建模到数据可信管理的完整支持体系。

当前这个案例完整展示了本体建模的实际应用。

其中定义了工厂、原材料、客户订单等一系列核心业务概念，并将它们之间的逻辑关系清晰地描述出来。当然，这是一个相对高阶的综合示例。我们可以基于此，在后续内容中逐步拆解，从更基础的层面展开说明。

在更大的架构视角下，正如我们刚才看到的，本体位于整体流程的右侧。左侧的源头是业务系统，比如当某个工厂因地震停产，系统中该工厂的状态数据就会实时更新。

这一状态变化会立即被传递到本体层，从而触发相应的业务判断与响应。

同样，左下角还接入了外部数据源。例如，当监测到原材料价格发生波动，这一变化也会实时传入本体，驱动系统判断是否需要调整生产计划，比如是否应该减产。

因此，其运作模式是：一旦内部业务数据或外部市场数据的状态发生变化，这些变化就会实时触发本体中预设的业务逻辑，进而自动驱动后续的业务决策与行动。

在这一平台上，本体的构建不仅涉及业务逻辑的设计，还需要与实际存在于云端业务系统中的数据库表结构建立映射关系。

如图所示，左侧展示的是物理模型，即基于ER图设计的实际数据库表，比如具体记录工厂信息的物理表。右侧则是本体设计的逻辑模型，其中定义了“工厂”这一业务概念。两者通过明确的映射关系连接在一起。

当业务发生变化时，例如有新的订单产生、某工厂停工或新工厂上线，这些都会体现为底层数据的状态更新。一旦数据状态发生变更，便会实时触发本体模型中预设的逻辑进行判断与响应，驱动后续的业务流程自动运转。

这正是数据变化驱动业务响应的核心模式。

简而言之，我们所探讨的实现路径离不开两个关键层面：

一方面，需要通过本体建模将业务逻辑清晰地梳理出来；另一方面，传统的数据建模工具如ER图依然至关重要，它承上启下，向上对接本体设计，向下映射到底层数据库，是连接业务定义与数据实现的桥梁。

04 以动态语义驱动，触发真正的业务响应

我们当前的本体平台与此前常见的RAG或工作流方案相比，有一些质的变化和升级，主要体现在以下几个方面。

过去的RAG或编排式工作流，本质上仍偏重于静态的知识检索与流程执行。而如今基于本体的系统，则演进为动态的语义化系统。

它不仅能够融合结构化与非结构化数据，更关键的是，可以通过本体模型实时理解数据背后的业务语义与状态变化，从而驱动动态的判断与响应。

在这一架构中，左侧是基于本体建模所设计的业务概念，例如这里定义的“车辆”类及其相关数据属性。右侧则对接了企业实际运行的CRM、ERP等业务系统的数据库表。

该平台的核心机制，正是通过建立左侧本体模型与右侧物理数据表之间的映射关系，使业务定义能够直接关联到实时数据，从而驱动基于语义理解的动态运转。

不仅如此，在该平台上还可以进行更深度的本体设计，包括定义业务规则、配置推理逻辑等。

目前，许多企业在落地这套本体方案后，都取得了显著成效。

这远远超越了简单的问数，如果仅用于查询，反而像是“杀鸡用牛刀”。其更大的价值在于深度洞察。

例如，当发现某个门店效率偏低时，你可以直接要求系统：“帮我分析它效率低的原因。”这时，本体与大模型将协同工作，自动关联并探查所有相关的运营明细数据，最终定位问题根源。

这是一套非常强大的分析决策方法论，它让业务问题的诊断从依赖经验猜想，转向基于全域数据的自动推理与归因。

正因如此，在实际落地中，我们也可以通过建模平台来降低使用门槛。众所周知，本体建模的技术门槛较高，甚至比传统的ER建模更为复杂。

为此，我们可以引入AI助手来辅助完成本体的模型设计。具体方式是：将业务需求描述提交给AI助手，由AI基于需求理解，自动构建或推荐相应的本体模型结构。这能够显著减轻人工设计的负担，提升建模效率与规范性。

此外，我们还探索出一种高效的实现路径。

具体而言，需要先将连接数据库的ER图，转换为一个中间层，我们称之为ER与本体的桥接模型，并最终生成完整的本体模型。

通过这种方式，整个系统将成为一个能够动态响应、灵活演进的活系统，同时具备强大的智能化业务理解与处理能力。

05 告别人工逐点维护，转向AI驱动的主动式常态治理

传统的企业数据治理工作，长期以来主要依赖人工完成。过去二十余年中，我们帮助企业补充元数据、统一字段业务含义、梳理并发布数据标准，再将标准与元数据逐一映射关联，这整套流程在过去基本都是纯手动操作。

如今我们发现，AI可以在其中发挥重要辅助作用，显著提升效率。因此，当前的实现路径是：通过多个智能体分工协同，它们之间形成联动的工作网络。上层的各类数据治理任务，均由这些智能体共同处理，而它们都基于底层统一的MCP基础能力进行调用与协作。

随着OpenClaw、开源大模型等AI技术的成熟，当前的数据治理工作已不再局限于被动响应人工指令。

企业的数据环境始终处于动态变化中：新系统上线、版本迭代带来新增的表和字段，各类数据资产不断积累，新的指标也在持续开发中。传统依靠人力逐项跟进的方式，难以匹配这种持续演进的节奏。

因此，数据治理正转向一种主动、常驻、自动化的运行模式。我们可以基于AI构建持续监测与执行的机制，对数据资产进行实时发现、映射、标准化与关联，实现7x24小时的可持续治理。

这标志着从人工逐点维护到系统主动治理的根本性转变，也正是当前数据治理领域一个重要的发展趋势。

整体来看，这种方式的投资回报率较以往的传统方式有显著提升。在落标率、标准执行量、元数据覆盖率与完备度等关键环节，AI能够以更高效率、更可持续的方式完成相关工作。

基于当前实践，我们正在推动治理智能化，利用AI进行数据治理。

• 信通院数据资产专家委员会成员，数据资产管理实践白皮书主要撰写人之一
• 多项专利和论文关于统一（关系型与非关系型）数据建模
• IEEE member, OMG member, DAMA CDMP，TheOpenGroup 专家成员
• 国资委数据要素专家组成员
•  复旦大学、北京航空航天大学 客座讲师
•  曾任CA ERwin全球研发负责人。2006年加入CA，十几年经验在数据建模领域。客户多来自世界500强，美国银行（BOA），SunTrust，AT&T，壳牌等。 深度参与建设银行新一代系统数据模型设计。