从思考到执行，动态本体重构企业AI决策智能

通用大模型难以独立支撑企业智能化，根源在于它不懂业务语义，无法跨越数据孤岛，也难以承担高昂的私有化落地成本。更重要的是，传统模式只能提供建议，无法真正触发业务流程。知识图谱解决了静态语义，却无法驱动执行。

本次分享嘉宾提出了从静态本体走向动态本体的破局路径。以对象、属性、链接、函数、行为、规则与推演场景构成的动态语义层，为大模型注入业务确定性，让智能体从会“思考”走向“能执行”。

分享嘉 宾 ： 中国电子云 AI 产品线本体产品负责人，高斌

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

01

通用AI为什么难以独立实现业务智能化

我们在实践中发现，通用人工智能很难独立实现企业业务的智能化，最核心的原因有几个。

第一，这一代大语言模型主要基于Transformer架构，本质上依靠注意力机制判断下一个Token或者下一个动作是什么。如果模型训练时没有接触过企业的业务和数据，它就很难理解具体行业的业务，这也是很多AI应用出现幻觉的重要原因。

因为存在语义断层，AI没有办法理解企业特定的业务语义，进而导致业务决策偏差。

第二，企业AI的落地成本比较高。很多企业的数据不能出域，要求在私有云等私有化环境部署。算力、硬件、咨询、实施和软件开发成本都很高，最后得到的却可能只是一个用于Demo或者POC的智能体系统，投入与产出很难成正比。

第三，企业现有的数据基础非常分散。现在很多AI应用最终落在问答或者问数上，本质上很像传统BI或数仓架构的延伸，构建大宽表，再通过分析报表辅助决策。

企业这些年建设了太多数据系统，一个企业少则几百个IT烟囱，多则上千个，形成了大量数据孤岛。每个数据系统只包含局部信息，又分散在不同位置，AI没有机会拿到业务全貌。

第四，大数据发展到今天，大部分情况下仍然以报表为中心。系统只负责提供建议，不会真正触发业务流程。我们离业务闭环始终差一步，这一步就是让AI指挥各个业务系统，把真实的业务流程触发起来，让业务真正运行起来。

回到AI时代，大语言模型很像一个处理器或者计算器：输入一段自然语言，再输出一段自然语言。但它是概率模型，很多时候无法满足企业对确定性的要求。

这时就需要本体，也就是一个语义层。这个语义层可以把具体业务逻辑和确定性注入每一次与大语言模型的交互中。AI应用要真正落地，就必须以业务对象为中心，进行动态的语义理解。

知识图谱可以认为是本体的一种初级形态。它反映了世界的语义模型，却不能让数据真正动起来。实时数据进来以后怎么处理，业务动作如何触发，知识图谱很难形成闭环。自然语言交互也不是知识图谱擅长的事情，这正是大语言模型可以补上的能力。

所以，企业AI落地不是一个单点突破问题，而是一个综合问题。做本体，本质上是在做一个交叉领域：一边要面对企业积累的大量数据基础设施，一边要应对大语言模型的不确定性，还要处理各种专业业务知识。

02

从静态本体走向动态本体

按照Palantir的说法，它所做的是一种典型的业务本体，也可以叫动态本体。

本体首先有一张静态蓝图，类似于知识图谱。很多本体厂商的产品都会带有图引擎，不管底层是图数据库还是其他图计算引擎，目的都是解释真实世界里有什么对象、对象有哪些属性、对象之间存在什么关系。

动态本体在静态蓝图之上增加了函数和行为。

所谓函数，是各种业务逻辑的计算。以供应链为例，一个地方库存不够，需要从另一个物流中心调货，就要计算两个仓库之间的距离、应该派什么车辆、运送多少货物。这些计算在本体模型中体现为函数。

行为则是基于计算结果真正触发业务动作。比如计算出要从A仓库调两辆货车把货物运到B仓库，真正调车的动作可能是在企业业务系统中发送一张工单。发送工单这件事，在本体模型里就叫行为。

函数和行为让动态本体成为一个实时的业务沙盘。企业不可能等到真实问题出现后再做决策，而是要经常推演故障和异常，测试系统能不能应对。我们现在做的很多应用都与推演、仿真和模拟有关。真实决策并不是时时刻刻发生，更多时候是在不断演练，等到真实事件出现时再执行决策。

从某种意义上讲，本体为大模型提供了一条向世界模型演进的新技术路线。

动态本体有几个重要特点。

第一是动态性。有了函数和行为，系统就会出现状态，而一旦开始处理状态，工程复杂度就会明显增加。

第二是因果性。图谱记录世界里有什么，本体模型还要解释为什么会这样，解析动作与状态之间的逻辑链条，把因果律和确定性加入大模型。

第三是可解释性和可审计性。每一步推演都按照本体模型进行，因此每一步都可以被解释和审计。

第四是闭环性。系统触发业务流程后，可以把执行结果保存下来，再利用智能体持续演化。用现在比较流行的说法，就是系统的自演进。

动态本体的核心模型包括对象、属性、链接和动作。函数与动作有很强的关联，此外还需要规则，规则是驱动世界运行的触发器。

另一个重要部分是推演场景。我们会利用不同版本的本体，对用户的真实业务场景进行持续推演，观察不同输入进入后，本体模型和业务流程会产生什么结果。

横向来看，对象模型解释世界是什么；动作解释世界能做什么；规则解释什么时候应该做什么；推演则回答假设做了某件事，接下来世界会发生什么。

03

动态本体让智能体从思考走向行动

为什么动态本体要与智能体结合？因为企业AI项目最终交付给用户的形态，很多时候就是智能体。

两三年前，智能体主要依靠工作流；最近一两年，行业开始转向自主规划；现在则进一步走向基于动态本体的智能体。

前两年的智能体只能读取数据、提供分析。动态本体与智能体结合以后，可以把业务流程串起来，智能体不只会思考，还可以真正行动。这正是企业AI落地一直缺少的能力：智能体不能只提建议，还要进入真实业务流程。

中国电子云的动态本体核心架构可以分为三部分。

第一，数据与业务。需要基于本体给数据赋予业务语义。

第二，模型与逻辑。把动态本体和规则加入模型上下文，再通过MCP工具调用或者SDK提供给上层应用。这样可以基于本体管理多智能体上下文，也能让模型理解真实世界。

第三，决策与执行。把洞察连接到真实系统中的行动，让决策真正进入业务流程自动化。

过去二十多年，数据技术先解决运营问题，再解决分析和决策问题。到了AI时代，我们开始解决执行问题，让用户能够以智能化方式完成决策和行动。

04

本体是多智能体的实时认知底座

本体与多智能体结合时，本质上充当多智能体的认知底座。

在感知层，系统接入多模态数据，并从中提取本体需要的实时信息；在认知层，系统感知事件，并基于知识图谱帮助智能体推理；在融合层，系统把真实世界的约束加入推理过程，让智能体给出的结果满足现实要求。

从计算机科学的角度看，大模型类似于CPU，是一种计算器或计算引擎；本体则很像文件系统加缓存系统，为计算引擎提供可以理解和调用的业务上下文。有了规则约束、关系推理和大模型语义推理，就有机会驱动自主决策。

整个过程是一个循环：首先感知多模态数据，把信息映射到动态本体；然后支持智能体推理，推理结果再驱动业务流程行动；行动结果写回本体，新的增量数据再次进入感知和推理。这个飞轮一旦转起来，系统就能够持续演化。

它有几个重要好处：整个过程可解释、决策中间可以人工干预（Human in the Loop）、智能体还可以在持续决策中不断进化。

05

本体平台要做动态语义层

中国电子云过去主要做动态数据治理，把结构化、非结构化数据转成可以使用的信息。

现在我们继续向上走一层，建设本体构建平台，把人工智能、本体和多智能体技术融合起来，解决智能应用落地问题。

平台上层是智能应用开发能力，旁边还需要模型服务，并与外部系统连接，让数据可以进入和输出。

这个本体构建平台不是把数据中台再做一遍，也不是再构建一个知识图谱。我们主要做的是动态语义层，再基于动态语义层赋能智能体，让大模型应用能够进入企业。

从软件工程角度看，本体也可能带来新的变化。过去开发系统，知识主要处在边缘位置，大家围绕数据库开发服务，再在服务之上构建应用，整个过程由代码驱动。

现在，本体是语义层，大语言模型又天然对自然语言友好。本体越来越像一个Runtime，甚至像一种更接近自然语言的新计算机语言。

我们在尝试以本体为核心，把工作流编排、大模型服务、查询和聚合计算、图算法、记忆管理、行为规则以及智能体统一在同一个语义运行时中。

只有把这些能力串起来，智能决策才真正成立，企业决策才能变得更快。

06

Q&A 问答

爱分析：本体应用实际落地时主要面临哪些挑战？

高斌：最初业务理解对我们的挑战更大。

中国电子云内部有业务专家，对相关业务有一定了解。我们落第一个项目时，仅理解业务就花了差不多两个月，经历了比较长的磨合期，但从0到1一旦走过去，后面的路会好走很多。

我们也尝试过用自然语言构建本体模型。纯靠大模型不太行，因为幻觉太多。后来我们的做法是，先让大模型构建初版的本体模型，业务规则也采用类似方式。初版准确率达到50%至60%，就已经可以作为起点。剩下的误差再与业务专家沟通，通过人工校正弥合。

企业最开始通常会选一个具体业务场景，本体模型的复杂度不会太高。但规模化以后，复杂度会明显上升。我们现在做的一个项目，本体对象类型接近1000个，链接有四、五千个，数据量更大。

为了解决规模化问题，我们开始利用大语言模型生成本体初版，再通过工程化方式提高可靠性。我们编写了多智能体系统，让它约束负责构建本体模型的大模型，使模型遵守本体标准。

最初完成一个场景大约需要两个月，现在如果业务专家配合，差不多一周可以完成。

另一个经常遇到的问题不是技术，而是组织协调。

模型出来以后要持续接入数据，这时会遇到不同系统怎样打通、数据怎样协调、权限怎样控制等问题。

我们现在探索出的一条路，是用工程化方式控制大模型，再让被约束的大模型帮助我们构建本体、编写本体函数和本体应用。

爱分析：这套多智能体架构，主要是为构建本体的模型提供通用约束吗？

高斌：它与具体业务场景没有那么强的相关性。我们做的本体体系和Palantir比较接近，包括对象类型、链接、函数、行为和规则，这些结构比较通用。

我们把这些要求写成多智能体系统，作为上下文提供给模型，模型就能够更好地遵守本体标准。

业务侧的大部分智能决策场景，其结构也比较相似。我们在构建本体的多智能体系统时，已经陆续加入一些特定领域的内容。这样的工作做一次之后，后续可以持续复用，节省很多时间。

爱分析： 本体比传统知识图谱增加了函数、行为和业务逻辑，也具备向原有业务系统回写数据、调整状态的能力，它已经从辅助决策进入执行环节。即使只做决策，权限管理也会比关键词或敏感词控制更严格。进入执行阶段以后，控制要求还会更高，那么平台怎样设计权限管理？

高斌：我们主要做平台，过去建设数据中台时，已经对权限分级分类做过一轮。本体是从数据之上抽象出来的语义层，但增加了函数和行为。

第一步，要具备基本的RBAC，也就是基于角色的访问权限。

第二步，要把权限控制到本体实例层。这部分与过去的数据平台有一定延续性。

挑战更大的是函数和行为。它们的执行权限、修改权限和可见权限，需要重新定义一套模型，再应用到平台中。

还有一类问题来自推演。真实的应急决策可能只发生一次，但系统平时需要不断推演和演练。模拟运行会产生数据变化，这些变化必须在安全、可控的范围内发生。不能因为演练了一遍本体，就把生产系统里的真实数据改掉。

因此，数据安全以及函数、行为可以执行到什么范围，是当前权限设计中更复杂的部分。

爱分析：当本体应用从Demo或试点进入生产级，底层数据平台层面有哪些实践和挑战？

高斌：数据集成永远是复杂话题，因为用户的数据基础设施很多。我们做决策智能，使用了较多实时数据处理和流数据处理技术，也会使用Flink等工具。

目前比较突出的挑战来自实时多模态数据。以城市火灾场景为例，系统会接入可见光图片、热力数据、红外数据和卫星遥感数据。我们需要在一定时效范围内提取最重要的信息，再映射到本体模型中。

过去也有人处理这些数据，但通常依赖小模型或传统计算机视觉算法。现在面向本体，需要同时解决实时和多模态理解问题，这对我们来说是一个很大的挑战。

传统数据集成更多面对MySQL、PostgreSQL、OceanBase、GaussDB、TDSQL等关系型数据库，或者MongoDB等非关系型数据库。过去没有按照本体要求仔细处理的多模态数据，怎样被实时理解并映射为业务对象，反而成为更难的问题。

爱分析：企业现在普遍建设智能体中台或智能体开发平台。您怎么理解本体平台与智能体平台之间的关系？

高斌：我们做的是通用语义层，对上层各种智能体平台提供服务。

反过来看，构建本体应用也离不开智能体能力，智能体平台同样会为本体平台提供服务。所以我更倾向于把智能体看作执行层，把本体看作语义层，两者是彼此赋能的关系。

爱分析：Palantir的AIP可以等同于国内所说的智能体平台吗？

高斌：我认为Palantir 的AIP本质上是在Foundry数据平台之上增加大量智能体功能，把数据平台、本体和智能体融合在一起形成的新平台。

Palantir的理念有值得借鉴的地方，但在自己的架构选择上，我不完全赞同继续以数据为中心、只把本体看作附加语义层。

计算机科学发生重大变化，往往从数据计算方式的变化开始。大模型本质上是一种新的数据计算引擎，本体为这个计算引擎提供缓存、文件系统和业务上下文，最终服务企业。

企业的核心资产是数据，但数据是被处理的对象。更重要的是让本体与智能体融合，以更高效、更可靠的方式处理数据。

以上就是本次分享的内容，如需获取完整课件和视频回放，请扫码领取。

现任中国电子云AI 产品线本体平台产品负责人。从事数据与智能相关工作二十余年，历经过 Oracle、蚂蚁金服 OceanBase、PingCAP TiDB 等平台的产品与技术工作，长期关注企业级数据管理系统、管控平台与 AI 落地相关领域。当前聚焦于如何将动态本体、多智能体和数据管理技术进行融合，从而推动人工智能在企业落地相关的领域，并探索如何用本体约束小模型写出更高质量的代码相关的领域。