一、一个反直觉的事实
过去一年，大模型的能力飞速提升。从理解复杂指令到处理多轮对话，从生成代码到推理分析，模型越做越大，参数越来越多。按理说，企业用AI处理业务应该越来越容易了。
但实际情况恰恰相反。
一个做工厂信息化的工程师讲了这么一个案例：他们用一个大模型驱动的Agent去查生产数据，问它"上个月产线B的设备综合效率是多少"。Agent理解了这个问题的意思，也知道自己需要去数据库里查数据，但它不知道"设备综合效率"对应的字段叫什么、在哪个系统的哪张表里、计算公式是什么、产线B的系统编码是什么。
大模型什么都懂，但不懂这家工厂。它不知道"设备综合效率"是OEE，不知道OEE在MES系统里对应的三张表分别记录了什么，不知道"产线B"在系统里的正式名称是"B2车间第三产线"。
这不是模型不够聪明的问题，而是模型不理解企业的数据含义和系统关系的问题。
企业数据分散在ERP、MES、OA、CRM、财务系统等十几个系统里，每个系统有自己的字段定义、编码规则、业务逻辑。同一个概念在不同系统里的名字都不一样——"客户"在CRM里叫Customer，在ERP里叫BP（Business Partner），在财务系统里可能叫交易对手。大模型没有这些知识，就无法做出准确的查询和推理。
这就是企业AI落地最被低估的瓶颈：语义鸿沟。模型和企业的数据之间，隔着一层语义翻译的问题。
二、本体语义层要做什么
本体语义层的核心任务只有一个：给企业的数据建立一层统一的语义描述，让Agent能理解这些数据的含义和系统之间的关系。
说得更直白一点，就是把企业里"人知道但系统不知道、系统知道但模型不知道"的那些知识，显式地表达出来。
具体包括三类知识。
第一类：实体定义。
企业里的核心业务对象——客户、订单、物料、供应商、设备、工单、产品——每个对象在系统里可能有很多字段，但Agent需要知道哪些字段是关键的、每个字段的业务含义是什么。比如"订单状态"这个字段，1代表什么、2代表什么、3代表什么，不同系统可能不一样。本体语义层统一这些定义。
第二类：关系定义。
企业和系统之间充满了复杂的关联关系。一个订单关联一个客户、多个物料、多条BOM、多个工序。一个设备关联一个车间、多条维保记录、多套备件。大模型天然有推理能力，但它需要先知道这些关系存在，才能做出正确的推理。本体语义层把隐藏在系统架构里的关系显式化。
第三类：流程定义。
企业的业务不是静态的数据查询，而是动态的流程——一个审批要经过哪些节点，一个质检要对照哪些标准，一个采购要走哪些步骤。这些流程知识是Agent执行任务时必须遵守的规则。本体语义层把这些流程规则结构化地存储下来。
有了这三类知识，Agent才能真正做到"理解业务"——不是泛泛的理解，而是精确到字段级别、流程级别、系统级别的理解。
三、没有语义层，Agent会遇到什么
没有本体语义层的Agent，在实际业务中会遇到三类典型问题。
第一类：找不到数据。
Agent知道要查数据，但不知道去哪个系统查。企业通常有十几个信息系统，Agent需要有人告诉它"库存数据在ERP的INV模块里，设备数据在MES的EQUI表里，客户数据在CRM的CONTACT对象里"。没有这个映射，Agent只能瞎猜。
第二类：理解错含义。
Agent找到了数据，但理解错了含义。比如"交期"在采购合同里指的是供应商承诺的交货日期，在生产排产里指的是计划完成日期，在出货计划里指的是实际发货日期——同一个词在不同语境下含义完全不同。没有语义层的消歧，Agent很可能查对了表但理解错了字段。
第三类：串联不了系统。
一个完整的业务问题通常需要跨系统查询。比如"上个月因为供应商延迟交货导致的停线损失是多少"——需要从采购系统查供应商交期记录，从生产系统查停线事件，从财务系统查损失金额。没有语义层提供的关系定义，Agent不知道这三个系统之间的数据怎么关联。
这三类问题在向量空间JBoltAI的实际项目经验中反复出现，也是促使平台从V4.5的Skill整合升级到V4.6语义管理能力的直接原因。
四、向量空间JBoltAI的语义层实践
向量空间JBoltAI当前正在用公司内部的多个业务系统做本体语义打通验证。选择先用自己的业务来验证——因为如果连自己的多系统业务都串不起来，就谈不上给工厂做改造。
验证的业务系统包括：内部OA工单系统、发展计划管理系统、客户工单处理业务、飞书上的客户画像登记等。这些系统分别由不同团队在不同时期建设，数据结构各异，字段命名不统一，编码规则不一致——这跟大多数工业企业的IT现状高度相似。
验证的目标很明确：向Agent发问，Agent能自主判断该上哪个系统查什么数据、怎么关联不同系统的信息、怎么给出完整的回答，不需要人工提供额外上下文。
目前验证的效果已经可以做到：问Agent"张工手里有几个未处理的bug"，Agent知道"张工"对应OA系统里的某个用户ID，"bug"对应工单系统里的缺陷类型，"未处理"对应状态字段值，然后自动去OA系统查询，返回结果。整个过程不需要告诉Agent"bug在OA系统的哪个模块"——本体语义层已经把这些知识沉淀好了。
这个验证虽然范围还不大，但说明了一个关键判断：本体语义层不是理论构想，是可以落地的工程问题。
从框架架构的角度看，向量空间JBoltAI的六大中心中，"智能数据中心"对应的是数据基石，"AI能力中心"对应的是工具基石，"AI资源中心"对应的是模型基石。本体语义层属于智能数据中心的核心能力——它解决的是"数据有了但模型看不懂"的问题，是企业AI落地的数据基石。
五、本体语义和RAG的区别
很多人会问：这不就是RAG吗？把企业数据灌进向量库，让大模型检索不就行了？
RAG和本体语义层解决的是不同层面的问题。
RAG解决的是"检索"问题——把非结构化的文档（SOP、操作手册、技术文档）向量化后做语义检索，让Agent能找到相关文档片段。
本体语义层解决的是"理解"问题——让Agent理解企业系统里的结构化数据：字段含义、表与表的关系、系统与系统的关联、业务流程的规则。
两者的区别在于：RAG处理的是"文档知识"（人写的文字），本体语义层处理的是"系统知识"（数据结构和业务逻辑）。一家企业的知识资产，既包括写下来的文档，也包括沉淀在系统里的数据关系和业务规则。两者缺一不可。
向量空间JBoltAI的平台架构同时支持这两类知识。智能数据中心同时提供知识库（文档RAG）和本体语义层（结构化数据语义），让Agent既能查文档、又能理解系统数据。这就是AgentRAG的完整形态——不是单纯的文档检索增强，而是文档知识和系统知识的双重增强。
