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 怎么不能跨系统回答”时，可按“实体身份—关系图谱—数据源坐标—六阶段日志”这条链反推，四步中缺哪一步补哪一步，比直接换模型有效。