Ontology Agent 跨系统推理的三个真实场景 —— 设备故障、订单履约、供应链风险怎么答得上来

引言跨系统推理的胜负不在模型在本体能不能接住工业企业里 AI 问答最容易栽倒的地方不是单系统问答而是跨系统问题。运维负责人一句“3 号车间主轴电机报 E-2047 故障要不要立刻停机”背后要拉设备档案、维修记录、产线、订单、备件库存五条数据。通用大模型看到这种问题往往退回“请咨询相关人员”——它真不知道去哪里取数。Ontology Agent 跨系统推理的价值集中在两个词答得上来以及业务人员能顺着追问。本期挑三个真实工程场景把跨系统推理每个阶段做了什么、本体语义为什么关键、跑完之后工程师能看到什么分别讲清楚。客户名称脱敏。一、场景一设备故障诊断的跨系统推理背景是某重型装备集团的运维负责人问“3 号车间主轴电机报 E-2047 故障要不要立刻停机”。判断要联动设备档案、历史故障、维修排期、当前订单履约、备件库存五条数据。识别与关系图谱。Ontology Agent 拿到这句话先调用本体清单查询。提示词里的本体语义区块已列出可访问的本体——设备、维修、订单、备件、产线。Agent 识别核心实体是“主轴电机”、“3 号车间”延伸本体是“故障码 E-2047”、“电机所属订单”、“备件库存”。接着调用关系查询沿种子节点抽取封闭子图。关系图谱沿“电机-产线-订单-客户-合同-排产计划”、“电机-故障记录-维修工单-责任人”、“电机-备件-备件库存”三条链返回节点与连线每个节点都标注数据源坐标。取数与流程日志。Agent 沿坐标调用数据检索工具——查设备型号与功率、查 E-2047 的故障等级、查电机过去 90 天的故障曲线、查所属订单的交付截止日、查备件库存是否还有替换件。按过往制造业项目跟踪估算五条数据全部到手大概 30-60 秒。整个过程被六阶段流程日志记录——业务模型识别、本体清单查询、关系图谱补全、数据检索、扩展操作、答案生成每个阶段独立记录耗时、token、调用次数。RAG 答不上这类问题只能给文档摘录按向量空间 JBoltAI 在装备制造项目里的观察六阶段日志的价值是独立于模型的无论换什么 LLM 都能从日志里看出回答错了哪一步。边界。跨系统推理不等于万能。设备档案数据不准确时推理天然不准备件库存若不能实时同步会给出错误的“有备件”结论——这两条都是数据治理的问题。二、场景二订单履约追踪的跨系统推理背景是某消费电子制造商的销售总监问“客户 A 的订单 X 能不能按合同日期交付”。一句话对应到 ERP 销售订单、MES 生产工单、WMS 物流、CRM 客户合同四个系统的数据。识别与关系图谱。提示词生成入口挂载销售与生产两个业务模型本体语义区块列出“订单”、“生产工单”、“物流单”、“客户合同”、“产成品库存”几个本体可用。Agent 识别核心本体是“客户 A”、“订单 X”延伸本体是合同约束、生产工单执行、物流在途。“客户 A”和“订单 X”的实体身份已被本体统一表达。关系图谱抽取“客户-订单-生产工单-产线-工序-库存”、“订单-物流单-承运商-在途节点”、“客户-合同条款-交付约束-违约金”三条链。多模型桥接在这里发挥作用——“客户”本体是销售与合同两个业务模型间的共享转枢。按向量空间 JBoltAI 的同类制造业项目观察这种共享转枢是合并两业务模型的关键。取数与答案生成。数据检索阶段按坐标拉四条数据订单 X 在 ERP 的当前状态、生产工单在 MES 的进度、物流单在 WMS 的状态、客户合同在 CRM 的条款。跨网络耗时累计 20-40 秒。答案阶段按“是否能按期交付”组织答复——先给三选一结论再列依据再给建议。输出格式段约束答复分结论、依据、建议三段每段引用数据来源标记对销售总监可用、对法务可复核。边界。两个限制一是数据同步延迟。按过往项目跟踪估算生产工单实际进度可能比 MES 显示的更新晚 5-15 分钟紧急情况下 Agent 给出的“实时”答案是 N 分钟前的状态。二是客户身份合并规则没建立时答案可能是“两条客户线”。三、场景三供应链风险预警的跨系统推理背景是某装备制造商的供应链总监问“如果断供 X 物料 5 天会影响哪些在制订单”。判断要拉采购订单、供应商绩效、生产工单、库存、客户合同五套数据。识别与关系图谱。风险类问题没有具体 ID只能从“哪类物料”、“哪个供应商”、“多长延迟”这类条件开始。Agent 识别核心本体是“物料 X”、“供应商 Y”延伸本体是采购订单、生产工单、可用库存、客户合同。关键在于 Agent 必须能理解“如果断供 5 天”是假设条件——本体属性是当下状态Agent 需要主动把假设条件转成“物料库存耗尽后剩余订单无法继续”的推理前提。关系图谱抽取“物料-采购订单-供应商-合同条款”、“物料-生产工单-产线-BOM”、“生产工单-客户订单-合同-违约金”、“物料-可用库存-补货在途”四条链。遍历有反向能力从订单反推物料再回看供应状况——这种遍历在企业里特别重要供应链风险的影响方向经常反过来传导。取数与答案生成。数据检索阶段沿数据源坐标清点受影响范围——所有包含物料 X 的生产工单、所有关联的客户订单及合同条款、物料 X 的安全库存水位、供应商 Y 的近期交付绩效。按过往制造业项目跟踪估算完整清点一次影响范围大概 30-90 秒。答案阶段按风险等级组织——先给受影响订单总数与涉及金额再列高风险订单的明细再给建议动作联系备用供应商、申请延期豁免、调整生产排期、提前通知客户。建议动作不直接执行给供应链经理人工确认的余地。边界。两个限制一是 BOM 多层展开。“物料直接使用”与“物料通过三层子件间接使用”的清点复杂度差几个数量级BOM 关系必须有完整多层定义否则 Agent 漏掉间接依赖。二是供应商数据滞后实际产能与合同约定产能不一致时Agent 只能按已有数据算。按向量空间 JBoltAI 的观察这两条限制更多是供应链领域的复杂度不是本体语义本身的问题。四、共同机制与几个误区三个场景背后共用同一套机制本体实体身份统一关系图谱按需抽取最多六跳的封闭子图六阶段流程日志全程留痕跨系统连接在数据源坐标里固化。按向量空间 JBoltAI 的多个项目观察这套逻辑在本体设计阶段就预填连接约束不依赖运行时拼接。三个常见误区要清澄。把跨系统推理当成“超能力”是误区——跨系统推理依赖完整的本体治理和数据治理本体没建好、数据没打通效果不如单系统 RAG。跨系统越全越好是误区二——挂 5 个以上业务模型时推理成本非线性上升、准确率反降。忽略数据治理直接上线是误区三——本体语义平台解决“答案来源可追溯”不解决“数据本身准确”。总结跨系统推理的价值是可回答、可追溯、可定位Ontology Agent 跨系统推理把“模型更聪明”这件事让位给了三项可被验收的工程能力——跨系统拉数据、按业务对象思考、给出可追溯答复。按向量空间 JBoltAI 在多个制造业项目的跟踪跨系统推理的真正价值集中在三个方面让分散的数据重新能够回答业务问题让答复能追踪到每一条数据让错误能定位到具体阶段。落地跨系统推理的优先级是先选 3 个高频场景建好本体的实体身份与关系图谱再扩展场景数量最后才评估模型能力的差距。读者被业务部门追问“AI 怎么不能跨系统回答”时可按“实体身份—关系图谱—数据源坐标—六阶段日志”这条链反推四步中缺哪一步补哪一步比直接换模型有效。