本体+LLM实践：用 OWL2 + Jena + QLExpress 打造确定性运输资源调度推理 Agent

wasp520

486人浏览 · 2026-07-06 10:35:21

wasp520 · 2026-07-06 10:35:21 发布

本体+LLM实践：用 OWL2 + Jena + QLExpress 打造确定性运输资源调度推理 Agent

在工业级物流与多式联运场景中，运输调度系统（TMS）往往扮演着指挥中枢的角色。随着生成式 AI 的爆发，许多团队尝试引入大语言模型（LLM）来重构调度助手，希望通过自然语言交互实现运力匹配、路线推荐和调度合规检查。

然而，在涉及安全红线与履约效率的调度业务中，单纯依赖大模型的“概率性”生成方案很快就会碰壁。大模型在解析复杂的危险品运输禁忌、超限超载地方法规以及排程优先级公式时，频繁出现路线编码幻觉、硬性约束越权和计算漂移。

在涉及到安全与效率红线的运输调度中，‘概率性’的回答就是事故，‘确定性’的推理才是底线。

为了实现业务结论的 100% 可解释与可测试，我们设计并落地了一套融合本体（Ontology）语义推理与轻量级业务规则引擎的运输调度推理 Agent 架构。该架构运行于 Java 虚拟机（JVM）内，完全融入企业现有的 Java/Spring 微服务生态。

为了便于大型系统开发和维护，我们将该系统的设计分为 业务层设计 与 架构层设计 两个核心部分。

第一部分：业务层设计（Business Layer Design）

业务层设计聚焦于如何准确表达运输调度领域中的核心概念、实体属性以及复杂的业务约束逻辑。在确定最终的技术路线前，我们需要对知识表达与规则定义协议进行权衡。

一、领域知识表达协议对比与选择

在表达复杂的“运输资源调度”业务领域时，有多种定义协议可供选择。我们对目前主流的方案进行了多维度对比：

协议/模式	核心特点	运输调度适用性（优点）	局限性（缺点）
关系型模式 (SQL Schema)	二维表格，外键强关联。	事务性极强，基础资产数据检索效率极高。	多对多关联和多级继承关系查询繁琐，不具备逻辑推理与隐含事实推导能力。
属性图模型 (Property Graph - Cypher)	节点、边、属性。无强 Schema 约束。	路径查询和多层关系跳转（如路线分析、车队归属）极快。	缺乏标准的语义逻辑表达规范，无法在引擎层自动做分类推导与不一致性检测。
数据校验协议 (W3C SHACL / JSON Schema)	定义数据形状，进行数据合规性校验。	能够非常轻量、标准地校验订单或车辆信息的必填项与格式正确性。	属于被动的“是非”校验，无法从已知事实自动推导（分类）出隐含知识。
语义网本体协议 (OWL2 TBox - 描述逻辑)	强类型，支持继承、等价类、传递性及描述逻辑。	高度契合约束推导。例如：自动判断某普通车辆因缺乏危险品证书，不能归类为可用危险品车，并自动触发违规警报。	纯文本解析开销大，数值运算（如距离计算、运费打分公式）表达极为笨拙。

协议选择结论：
针对运输资源调度中“概念多级分类”、“资质证书继承”和“装载禁忌硬约束检测”的特点，我们选择使用 OWL2 TBox 作为业务语义表达的核心协议。它既提供了严密的描述逻辑定义，又能借助标准的推理机自动完成硬性合规性检查。

二、领域本体 Mermaid 类图定义

为了直观地展示运输调度本体中类与类之间的继承关系、以及对象属性（关联关系）的指向，我们首先通过 Mermaid 建立可视化模型：

三、 OWL2 TBox 形式化定义（Turtle 语法）

基于上述 UML 模型，我们将其转化为可供 Apache Jena 推理机直接加载的 OWL2 TBox Turtle（TTL）形式化定义：

@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix dpt:   <http://dpt.xxx.com/ontology#> .

# 本体定义声明
<http://dpt.xxx.com/ontology> rdf:type owl:Ontology ;
    rdfs:comment "运输资源调度领域本体定义，用于合规性推导与约束检查" .

# =================================================================
# 类定义 (Classes)
# =================================================================

# 运输资源基类
dpt:TransportResource rdf:type owl:Class ;
    rdfs:label "运输资源" .

# 车辆类
dpt:Vehicle rdf:type owl:Class ;
    rdfs:subClassOf dpt:TransportResource ;
    rdfs:label "运输车辆" .

# 危险品专用车
dpt:HazardousApprovedVehicle rdf:type owl:Class ;
    rdfs:subClassOf dpt:Vehicle ;
    rdfs:label "危险品运输专用车" .

# 普货运输车
dpt:GeneralCargoVehicle rdf:type owl:Class ;
    rdfs:subClassOf dpt:Vehicle ;
    rdfs:label "普货运输车" .

# 货物基类
dpt:Cargo rdf:type owl:Class ;
    rdfs:label "运送货物" .

# 危险化学品
dpt:HazardousCargo rdf:type owl:Class ;
    rdfs:subClassOf dpt:Cargo ;
    rdfs:label "危险化学品货物" .

# 普货
dpt:GeneralCargo rdf:type owl:Class ;
    rdfs:subClassOf dpt:Cargo ;
    rdfs:label "普货" .

# 调度单/派车单
dpt:DispatchOrder rdf:type owl:Class ;
    rdfs:label "调度派车单" .

# 调度冲突/违规记录基类
dpt:ConstraintViolation rdf:type owl:Class ;
    rdfs:label "调度约束冲突" .

# 缺少资质冲突
dpt:MissingCertificateViolation rdf:type owl:Class ;
    rdfs:subClassOf dpt:ConstraintViolation ;
    rdfs:label "缺少危险品运输资质冲突" .

# =================================================================
# 对象属性 (Object Properties)
# =================================================================

# 派送关联的货物
dpt:dispatchedCargo rdf:type owl:ObjectProperty ;
    rdfs:domain dpt:DispatchOrder ;
    rdfs:range dpt:Cargo ;
    rdfs:label "派送货物" .

# 派送分配的车辆
dpt:dispatchedVehicle rdf:type owl:ObjectProperty ;
    rdfs:domain dpt:DispatchOrder ;
    rdfs:range dpt:Vehicle ;
    rdfs:label "分配车辆" .

# 冲突关联
dpt:hasViolation rdf:type owl:ObjectProperty ;
    rdfs:domain dpt:DispatchOrder ;
    rdfs:range dpt:ConstraintViolation ;
    rdfs:label "存在违规冲突" .

# =================================================================
# 数据属性 (Datatype Properties)
# =================================================================

# 车辆或货物的资质证书标识
dpt:hasCertificate rdf:type owl:DatatypeProperty ;
    rdfs:domain [ rdf:type owl:Class ; owl:unionOf (dpt:Vehicle dpt:Cargo) ] ;
    rdfs:range xsd:string ;
    rdfs:label "拥有资质证书" .

# 车辆实时状态 (IDLE, BUSY, INACTIVE)
dpt:vehicleStatus rdf:type owl:DatatypeProperty ;
    rdfs:domain dpt:Vehicle ;
    rdfs:range xsd:string ;
    rdfs:label "车辆状态" .

第二部分：架构层设计（Architecture Layer Design）

架构层设计关注于流水线的高效编排、异构数据源的转换、双推理引擎的配合以及对最终推理结论的合规校验与自愈重试。

零、分层技术架构图 (Layered Technical Architecture)

为了展示运输调度推理 Agent 在微服务体系中的运作全貌，我们将技术架构划分为五个核心层次：用户交互层、Agent 状态图编排层、双引擎分层推理层、数据物化存储层以及基础数据源层。

一、基于 Spring AI 与 Spring AI Alibaba Graph 的 7 节点确定性流水线

基于 Spring AI 与 Spring AI Alibaba Graph 构建了整个 Agent 的核心流转图。

Spring AI 提供了标准化的大模型客户端接入与结构化输出（Structured Output）能力。而 Spring AI Alibaba Graph 则在 Java 生态中实现了类似于 Python LangGraph 的 StateGraph 状态图编排框架。它将复杂的推理流程抽象为一个由 7 个 Spring Bean 节点组成的确定性有向图，并通过线程安全的通道流转强类型状态。

在这套流水线中，大模型被严格限制在“意图识别”与“解释性输出”的两端，中间的核心推理逻辑由 Jena 推理机和 QLExpress 引擎掌控。

把 LLM 负责‘翻译’与‘包装’，把符号推理放在判断的中心，这就是架构的妥协与艺术。

1.1 Spring AI Alibaba Graph 关键实现代码

在 Spring Boot 微服务生态下，我们使用 Java 强类型定义状态及有向图编排。以下是完整的核心实现代码示例：

① 强类型工作流状态定义 (State)

import java.util.List;
import java.util.Map;

/**
 * 线程安全的工作流状态对象，由 Spring AI Alibaba Graph 引擎负责状态合并与流转
 */
public class dptReasoningState {
    private String sessionId;
    private String userQuery;
    private IntentType intent;
    private ResolvedContext resolvedContext;
    private ReasoningConclusion conclusion;
    private List<ReasoningTraceStep> trace;
    private String answer;
    private EvalResult evalResult;
    private int retryCount = 0;
    private Map<String, Object> retryHints;

    // Getters and Setters...
    public String getSessionId() { return sessionId; }
    public void setSessionId(String sessionId) { this.sessionId = sessionId; }
    public String getUserQuery() { return userQuery; }
    public void setUserQuery(String userQuery) { this.userQuery = userQuery; }
    public IntentType getIntent() { return intent; }
    public void setIntent(IntentType intent) { this.intent = intent; }
    public ResolvedContext getResolvedContext() { return resolvedContext; }
    public void setResolvedContext(ResolvedContext resolvedContext) { this.resolvedContext = resolvedContext; }
    public ReasoningConclusion getConclusion() { return conclusion; }
    public void setConclusion(ReasoningConclusion conclusion) { this.conclusion = conclusion; }
    public List<ReasoningTraceStep> getTrace() { return trace; }
    public void setTrace(List<ReasoningTraceStep> trace) { this.trace = trace; }
    public String getAnswer() { return answer; }
    public void setAnswer(String answer) { this.answer = answer; }
    public EvalResult getEvalResult() { return evalResult; }
    public void setEvalResult(EvalResult evalResult) { this.evalResult = evalResult; }
    public int getRetryCount() { return retryCount; }
    public void incrementRetryCount() { this.retryCount++; }
    public Map<String, Object> getRetryHints() { return retryHints; }
    public void setRetryHints(Map<String, Object> retryHints) { this.retryHints = retryHints; }
}

② 7 节点图定义与编译 (Configuration)

import com.alibaba.spring.ai.graph.StateGraph;
import com.alibaba.spring.ai.graph.CompiledGraph;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.beans.factory.annotation.Autowired;
import java.util.List;

@Configuration
public class dptReasoningGraphConfiguration {

    @Autowired private dptReasoningIntentNode intentNode;
    @Autowired private dptReasoningOntologyParseNode parseNode;
    @Autowired private dptReasoningMaterializeNode materializeNode;
    @Autowired private dptReasoningReasoningNode reasoningNode;
    @Autowired private dptReasoningOutputNode outputNode;
    @Autowired private dptReasoningEvalNode evalNode;
    @Autowired private dptReasoningReflectRouterNode reflectRouterNode;

    @Bean
    public CompiledGraph<dptReasoningState> dptReasoningGraph() {
        // 初始化图并指定状态构造器
        StateGraph<dptReasoningState> graph = new StateGraph<>(dptReasoningState::new);

        // 1. 注册 7 个 Spring Bean 作为图节点
        graph.addNode("dpt_r_intent", intentNode);
        graph.addNode("dpt_r_parse", parseNode);
        graph.addNode("dpt_r_materialize", materializeNode);
        graph.addNode("dpt_r_reasoning", reasoningNode);
        graph.addNode("dpt_r_output", outputNode);
        graph.addNode("dpt_r_eval", evalNode);
        graph.addNode("dpt_r_reflect", reflectRouterNode);

        // 2. 指定启动入口
        graph.setEntryPoint("dpt_r_intent");

        // 3. 配置静态与动态（条件）边关系
        // 动态路由边：意图识别判定，超出范围则直接短路走向 END
        graph.addConditionalEdges("dpt_r_intent", state -> {
            if (state.getIntent() == IntentType.OUT_OF_SCOPE) {
                return List.of("END");
            }
            return List.of("dpt_r_parse");
        });

        // 静态执行路线
        graph.addEdge("dpt_r_parse", "dpt_r_materialize");
        graph.addEdge("dpt_r_materialize", "dpt_r_reasoning");
        graph.addEdge("dpt_r_reasoning", "dpt_r_output");
        graph.addEdge("dpt_r_output", "dpt_r_eval");

        // 动态路由边：评测结果判定，通过则结束，失败则进入反思路由
        graph.addConditionalEdges("dpt_r_eval", state -> {
            if (state.getEvalResult().isPass()) {
                return List.of("END");
            }
            return List.of("dpt_r_reflect");
        });

        // 动态路由边：反思与回退路由
        graph.addConditionalEdges("dpt_r_reflect", state -> {
            if (state.getRetryCount() >= 3) {
                return List.of("END"); // 达到最大重试限制，输出降级文本并结束
            }
            // 根据 Eval 判定出的失败分类，引导状态回退至对应节点
            switch (state.getEvalResult().getFailureType()) {
                case ENTITY_ERROR:
                    return List.of("dpt_r_parse");
                case MATERIALIZE_ERROR:
                    return List.of("dpt_r_materialize");
                case RULE_ERROR:
                case CONCLUSION_ERROR:
                default:
                    return List.of("dpt_r_reasoning");
            }
        });

        // 4. 编译图，生成可运行实例
        return graph.compile();
    }
}

③ 核心 Node 实现代码示例 (OutputNode)

import com.alibaba.spring.ai.graph.Node;
import org.springframework.ai.chat.model.ChatModel;
import org.springframework.ai.chat.prompt.Prompt;
import org.springframework.ai.chat.messages.SystemMessage;
import org.springframework.ai.chat.messages.UserMessage;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import java.util.List;

/**
 * 解释性输出节点：使用 Spring AI 提供的 ChatModel，结合推理 Trace 生成对用户友好的自然语言回答。
 */
@Component
public class dptReasoningOutputNode implements Node<dptReasoningState> {

    @Autowired
    private ChatModel chatModel;

    @Override
    public dptReasoningState apply(dptReasoningState state) {
        String systemInstruction = "你是一个专业温和的运输调度助理。请结合推理链(Trace)中的数据和合规规则，组织流畅的回答。"
                                 + "注意：必须只使用 Trace 中提供的数据，禁止幻觉或捏造任何不存在的车辆ID和分数。";

        String userPrompt = String.format("用户提问：%s\n逻辑推理结论：%s\n推理执行链(Trace)：%s",
                state.getUserQuery(),
                state.getConclusion().toString(),
                state.getTrace().toString());

        // 使用 Spring AI 核心模型接口调用大模型
        String finalResponse = chatModel.call(new Prompt(List.of(
            new SystemMessage(systemInstruction),
            new UserMessage(userPrompt)
        ))).getResult().getOutput().getContent();

        // 将生成的答案写入图状态
        state.setAnswer(finalResponse);
        return state;
    }
}

二、双引擎分层推理机制：Jena（语义）与 QLExpress（规则）

本架构的核心创新在于将推理职责明确划分为两层：语义与约束层与数值与算法层。这两个引擎相互配合，以强类型的上下文（RuleContext）作为信息流转的纽带。

1. Jena 语义约束层

此层负责加载 OWL2 TBox（上述运输本体元模型），并执行 Jena Generic Rules 进行结构一致性推导与非法配载拦截。例如，当系统识别到某订单属于危化品（HazardousCargo），且车辆未通过安全检查时，Jena 的推理机将自动标记该配载方案不合法。

以下是一个典型的 Jena 语义约束规则定义：

# 危险品车辆资质一致性检查规则
[hazardousVehicleConstraint:
    (?cargo rdf:type dpt:HazardousCargo)
    (?cargo dpt:requiresCertificate ?cert)
    (?dispatch dpt:dispatchedCargo ?cargo)
    (?dispatch dpt:dispatchedVehicle ?vehicle)
    notMatches(?vehicle, dpt:hasCertificate, ?cert)
    ->
    (?dispatch dpt:hasViolation dpt:MissingCertificateViolation)
]

Jena 引擎专注于概念分类和硬性逻辑约束判断，不涉及任何打分算法。

2. QLExpress 业务打分层

通过 Jena 推理过滤掉不合规的非法运力后，系统将逻辑事实（Inferred Facts）组装入强类型的 RuleContext，并输入阿里开源的 QLExpress 规则引擎。

QLExpress 负责执行轻量级的运力评分和工序依赖自动补全。例如，对于满足约束的备选车辆进行距离与信誉度加权评分：

# rules/match-vehicle.yaml
rule-id: R-VEHICLE-MATCH-SCORE
intent: DISPATCH_ADVICE
expression: |
  score = 0;
  // 基础车型匹配加分
  if (vehicle.type == demand.preferredVehicleType) { score += 10; }
  // 距离加权打分（每接近10公里加5分，上限20分）
  double distanceKm = geoService.getDistance(vehicle.lat, vehicle.lng, site.lat, site.lng);
  double distScore = Math.max(0, 20 - (distanceKm / 10.0) * 5.0);
  score += distScore;
  // 资质完备度加分
  score += (vehicle.certCount * 3);
  return score;

此外，QLExpress 还可用于装卸货标准作业程序（SOP）的自动补全：若推荐了某危险品车辆，则自动将“安检登记”、“预冷容器”等前置工序加入执行链，并标记为 autoCompleted=true。

双引擎职责划分与对比

特性	Jena 语义推理层	QLExpress 业务规则层
主要职责	实体关系分类、非法配载硬约束拦截	运力评分、多权重公式计算、工序链补全
计算类型	描述逻辑、图谱一阶逻辑	数值计算、条件控制流、过程式脚本
输入源	OWL TBox + TDB2 三元组 (RDF)	强类型 `RuleContext` Java 对象
运行效率	毫秒级（受 ABox 图规模限制，百毫秒以内）	极快（通常小于 10 毫秒）

三、动态 ABox 物化：解决“图-关系”数据一致性

本体推理通常需要图数据（RDF Triples）作为输入。在实际的 TMS 场景中，车辆定位、订单状态、运力调度都在 MySQL 关系型数据库中频繁变动，全量将关系型数据库同步到图数据库会带来严重的写入延迟与数据不一致性。

为了解决这一问题，我们在 materialize 节点中设计了**“请求级动态物化层”**。

在接收到具体的调度请求后，物化节点通过只读 MyBatis Mapper 仅查询与当前订单、当前装卸货点、以及当前空闲运力相关的行数据，利用 dptRdfMapper 将这些关系数据动态转化为 RDF 实例三元组（ABox）。

// ABox 动态物化服务核心逻辑
public Model materializeSessionGraph(String sessionId, Long orderId) {
    Model sessionModel = ModelFactory.createDefaultModel();
    // 1. 查询订单数据并物化
    TransportOrder order = orderMapper.selectById(orderId);
    Resource orderResource = sessionModel.createResource(prefix + "Order/" + orderId);
    orderResource.addProperty(RDF.type, sessionModel.createResource(prefix + "TransportOrder"));
    orderResource.addProperty(sessionModel.createProperty(prefix + "cargoType"), order.getCargoType());

    // 2. 查询区域内空闲运力并物化
    List<VehicleStatus> idleVehicles = vehicleMapper.selectIdleVehiclesByArea(order.getAreaId());
    for (VehicleStatus vehicle : idleVehicles) {
        Resource vehicleRes = sessionModel.createResource(prefix + "Vehicle/" + vehicle.getVehicleId());
        vehicleRes.addProperty(RDF.type, sessionModel.createResource(prefix + "Vehicle"));
        vehicleRes.addProperty(sessionModel.createProperty(prefix + "status"), "IDLE");
    }
    
    // 3. 动态写入 Jena TDB2 Named Graph
    tdb2Dataset.begin(ReadWrite.WRITE);
    try {
        tdb2Dataset.getNamedModel("graph://session/" + sessionId).add(sessionModel);
        tdb2Dataset.commit();
    } finally {
        tdb2Dataset.end();
    }
    return sessionModel;
}

动态物化的 ABox 写入专属于本次请求的 Named Graph。推理结束后，系统触发 TTL 清理机制，将该 Named Graph 自动擦除。这种设计不仅实现了高并发下的事务级隔离，更避免了冗余的同步机制。

四、确定性分层评测与自愈 Loop 闭环机制

大模型作为自然语言的输入输出节点，其意图识别和实体绑定偶尔会出现偏差。为了拦截这一风险，我们引入了 dptReasoningEvalNode 与 dptReasoningReflectRouterNode。

EvalNode 采用纯确定性断言（禁止使用大模型作为裁判 LLM-as-judge），对推理状态进行分层评估。每一层均有其特定的校验机制，一旦校验失败，将触发对应的自愈重试路径（Loop），引导图状态回推并携带纠错 Hints 进行修正。

评测层级与自愈路由设计

评测层级 (Layer)	校验内容 (Validation Goal)	校验机制与断言 (Assertion Logic)	失败分类 (Failure Code)	回退节点 (Routing Node)	恢复策略与 Hint (Recovery Action & State Payload)
L1: 格式与 Schema 校验	结构完整性，防止大语言模型生成非法格式。	验证 ReasoningConclusion 实例是否符合 Jackson Schema。包括车辆 ID 列表、推荐等级、Trace 步骤等字段是否完整。	`SCHEMA_MALFORMED`	`dpt_r_output`	格式修复：将 JSON Schema 解析报错信息注入 `ER_RETRY_HINTS`，强制 OutputNode 严格遵循 JSON 结构重新生成。
L2: 实体与约束存在性校验	校验推荐的资源是否属于物化的上下文，杜绝虚假幻觉。	遍历 Conclusion 中推荐 of VehicleID 和 RouteID，断言它们在 session ABox 图中存在对应的实体节点。	`ENTITY_NOT_FOUND`	`dpt_r_parse`	语义重新解析与消歧：将不存在的实体 ID 存入 Hints，返回 OntologyParseNode，结合数据库记录重新对 mention 进行模糊匹配或消歧。
L3: 硬性约束一致性校验	验证推荐方案是否满足 OWL 本体一阶逻辑硬性约束。	检查 session ABox 模型中，调度单实例上是否挂载了 `dpt:hasViolation` 的属性关系。若存在该三元组，则断言失败。	`HARD_CONSTRAINT_VIOLATION`	`dpt_r_reasoning`	强制剪枝过滤：将违规规则 ID（如 `MissingCertificateViolation`）及冲突实体反馈给 ReasoningNode，修剪不合规的候选运力，由 QLExpress 重新对合法池打分。
L4: 规则覆盖度校验	检验业务核心算法（如打分规则、装卸 SOP 补全）是否完整执行。	检查 `ER_TRACE` 中是否包含指定 Intent 对应的所有 QLExpress 规则运行记录（例如必须包含 `R-VEHICLE-MATCH-SCORE` 步骤）。	`RULE_NOT_TRIGGERED`	`dpt_r_reasoning`	重新加载规则链：重置推理上下文，清除受损的临时缓存，指定静态规则 classpath 重跑 QLExpress。
L5: 反幻觉证据链校验	校验自然语言解释与结构化数据 Trace 的严格对齐，防止文本编造。	提取自然语言文本中的所有数字（如评分、距离、时间）和 ID，断言它们必须出现在 `ER_TRACE` 中。	`HALLUCINATION_DETECTED`	`dpt_r_output`	严厉事实注入约束：把检测到的幻觉数字/ID 列为“禁止生成词（Blacklist）”，同时把 Trace 里的 Ground Truth 用强提示词包裹，返回 OutputNode 重写自然语言。
L6: 语义一致性校验	校验最终推荐结果与本体分类的深层逻辑一致性。	检查推荐的车辆实体在 Jena OntModel 中是否推导出了非活跃或不可用子类（如属于 `InactiveVehicle` 实例）。	`SEMANTIC_INCONSISTENCY`	`dpt_r_reasoning`	更新 ABox 事实：标记该车辆的 ABox 状态为不可用，重新触发 Jena 推理及后续计算。

不可评测的 Agent 永远无法走出沙箱，能自我修正的自愈 Loop 才能支撑起生产高可用。

在 CI 门槛中，我们要求 Tier 2 场景测试用例的通过率必须大于 95%，且平均回退重试次数小于 1.5 次，方可允许合并上线。如果在重试次数超过阈值（如配置 maxRetries = 3）后仍未通过，系统将直接输出预置的降级结论（如“根据当前规则链未找到完全匹配的车辆，已为您准备人工审核通道”），确保系统不会抛出未捕获的 500 异常。

结论

本系统将**业务层的静态概念关系建模（OWL2）与架构层的动态确定性计算编排（StateGraph + 双引擎推理）**解耦，既保留了本体技术在领域分析时的清晰性，又避免了其在业务落地时的计算效率和集成瓶颈。在运输调度这一高严苛度的场景中，以 Spring AI 与 Spring AI Alibaba Graph 为核心的技术架构，成功在大语言模型的“灵活性”与传统 IT 架构的“确定性”之间找到了黄金分割点。