发明专利技术交底书

1. 发明名称

一种工业规则引擎的统一调度与自进化方法

2. 技术领域

本发明涉及工业互联网与智能制造软件技术领域，具体涉及一种面向产品生命周期管理（PLM）、企业资源规划（ERP）等工业系统的规则引擎，尤其涉及一种能够对多业务域规则进行统一调度、自动冲突检测与基于运行反馈自进化的方法及其系统。

3. 背景技术

在现代离散制造与流程制造企业的数字化系统中，业务规则（命名规范、必填字段、数据完整性约束、审批流、合规校验等）广泛分布于 PLM、ERP、MES、QMS 等异构系统。传统方案主要采用以下两类技术：

（1）硬编码规则：将校验与处理逻辑直接写死在业务代码中。其缺陷是规则与代码强耦合，任何规则变更都需要修改并重新部署系统，无法由业务人员自助维护，且规则分散于各模块，缺乏统一视图与统一执行入口。

（2）通用规则引擎（如 Drools、RETE 算法引擎）：虽支持将规则外部化为 DRL/决策表，但仍存在以下突出问题：

• 规则冲突难检测：当多条规则对同一字段施加相互矛盾的约束（如一条要求"名称长度≥8"，另一条要求"名称长度≤6"）时，引擎按固定匹配顺序执行，仅返回首条命中结果，既不提示冲突、也不按业务优先级裁决，导致校验结果失真。
• 缺乏自进化能力：规则一旦配置完成即长期固化，无法从系统实际运行中的用户修正行为（correction）自动归纳出新的规则，规则质量随业务演进持续劣化却无人修正。
• 调度不统一：识别、创建、修复、优化、比对、验证等不同业务动作各自调用独立的执行入口，规则作用域（scope）割裂，无法共享同一套优先级、缓存与上下文注入机制，且难以与上层意图识别、工作流调度协同。
• 安全与治理缺失：用户可自定义脚本规则，但缺乏受限执行沙箱，存在代码注入风险；同时缺乏规则包的质量治理与可追溯机制。

因此，亟需一种能够统一调度多域规则、自动检测并裁决规则冲突、并可根据运行反馈持续自进化的工业规则引擎方法。

4. 发明内容

4.1 要解决的技术问题

本发明旨在解决以下技术问题：

1. 解决异构工业系统中规则分散、调度入口不统一的问题，提供覆盖识别/创建/修复/优化/比对/验证等多作用域的单一统一调度入口；
2. 解决规则冲突隐蔽、无法自动裁决的问题，提供基于优先级排序与语义冲突识别的冲突检测与消解机制；
3. 解决规则固化、无法随业务演进的问题，提供"修正采集→模式识别→规则候选→审批部署→效能监控"的自进化闭环；
4. 解决用户脚本规则的安全执行与规则包质量治理问题，提供受限沙箱与五维治理评分。

4.2 技术方案

本发明提供一种工业规则引擎的统一调度与自进化方法，其核心由统一规则引擎、意图加权匹配、冲突检测、规则仿真、自进化引擎、企业级规则库及统一调度器协同实现。下面对应真实代码（位于 server/core/ 与 server/scheduler/）描述关键构成。

（一）统一规则引擎与统一调度入口

核心类 UnifiedRuleEngine（server/core/rule-engine.js）提供统一执行方法 execute(scope, context, options)。系统预定义多业务作用域常量 RULE_SCOPES（identify、create、create_pre、create_post、repair、optimize、compare、validate、inspect、transform、generate 等）与优先级枚举 RULE_PRIORITIES（P0~P3）。execute 方法依据 scope 从数据库表 sciot_rules_v2 拉取活跃规则，按 priority 升序排序后逐条执行：先调用 _evaluateCondition(rule, context) 评估条件是否命中，命中后由 _executeAction 执行动作，并通过 _recordHistory、_updateRuleStats 累计命中次数，形成统一的调度执行闭环。

为适配不同作用域的语义，execute 默认按作用域采用差异化冲突策略：对 validate/inspect 采用 merge（收集全部违规），其余采用 first_match（命中即应用），该策略可由单条规则的 conflict_strategy 字段覆盖。执行前由 _injectTypeContext 根据 ItemType 自动注入属性定义、必填字段、默认值等上下文，使通用规则适用于所有对象类型。

（二）优先级偏置与加权匹配

在意图识别阶段（server/core/intent-engine.js 的 recognize 方法），系统对用户自然语言输入进行加权关键词匹配：对每条意图规则 rule，其基础得分 score 由关键词命中（领域词权重 3、通用动词权重 1、长短语额外加分 lengthBonus）累加得到；随后引入优先级偏置：

const priorityBias = Math.min((rule.priority || 5) - 5, 5);   // 最高加 5 分
const verbBoost = scopeBoostMap[rule.scope] || 0;             // 上下文意图动词加权
const finalScore = score + priorityBias + verbBoost;

即同关键词得分相近时，优先级更高的规则获得偏置加分而胜出；同时若消息含明确操作动词（如"优化""修复"），通过 SCOPE_VERB_BOOST 对对应作用域的规则额外加 4 分，实现意图与规则调度的联动加权。

（三）冲突检测与自动裁决

系统的冲突检测由 RuleIntentInterpreter.detectRuleConflicts()（server/core/rule-intent-interpreter.js）实现。该方法对所有规则两两比较，调用 _detectPairConflict(desc1, desc2) 识别语义冲突：包括数值约束冲突（一方含"≥/大于等于/至少"、另一方含"≤/小于等于/不超过"）与语气风格冲突（"专业/严谨"与"口语化"）。一旦检测到冲突，依据预设的 priorityOrder（compliance > brand > technical_accuracy > content_integrity > readability > seo）通过 _getRulePriority 判定双方业务优先级，优先级高者（priorityOrder 索引更小）作为胜出方 winner，并给出"已按X优先处理"的消解建议。该机制与 execute 内的 block 动作拦截（触发 block_reason 与 blocking_rule 返回）共同构成冲突消解双保险。

（四）规则仿真验证

RuleSimulator（server/core/rule-simulator.js）在不改变真实数据的前提下对规则进行干跑（_dry_run: true）。其 simulate(ruleId, inputParams, userId, options) 方法在受限沙箱中执行规则的 condition_script/action_script（通过 _safeEval 以 vm 上下文运行），返回是否命中、动作输出与耗时，并写入 rule_simulations 表；batchSimulate 支持批量验证，compareResults 可对比两次仿真差异，saveTestCase/getTestCases 支持测试用例沉淀，从而在规则上线前完成回归验证。

（五）规则自进化闭环

RuleEvolution（server/core/rule-evolution.js）实现运行反馈驱动的规则演进：

• 修正采集与模式识别：analyzeCorrections(itemType, threshold) 查询 sciot_corrections 表中同一对象类型的用户修正记录，按 rule_id 分组，调用 _detectPattern 统计字段修改频率，当高频修改字段占比超过 50% 时判定为稳定模式，并由 _findDominantValue 抽取主导值，生成置信度 confidence；
• 规则候选生成：基于模式由 _generateRuleScript 生成可直接部署的 condition_script/action_script，存入 sciot_rule_candidates 候选表，标注 correction_count 与 confidence；
• 审批与部署：approveRule(candidateId, approvedBy) 将候选转化为正式规则（source='evolved'）并写入 sciot_rules_v2，同时使引擎缓存失效（invalidatePattern(/^rules:/)）；rejectRule 支持驳回；
• 效能监控与自动降级：monitorRuleHealth() 对修正率（user_correction_count/hit_count）超过 30% 且命中数 >10 的活跃规则自动置 is_active=0 降级，对高频高延迟规则给出"以确定性脚本替代 LLM 调用"的优化建议。

（六）企业级规则库与规则桥接

EnterpriseRules（server/core/enterprise-rules.js）管理跨对象类的企业级约束（required_fields、naming_convention、forbidden_patterns、data_type_standards、relationship_standards），提供 validateType 健康度评分与 applyIndustryTemplate（IATF16949/AS9100/ISO9001 等行业模板）。sciot-rules-bridge.js 的 loadAndFormatRules 将 sciot_rules_v2 中匹配作用域的规则格式化注入 LLM 提示，确保大语言模型在识别/创建/修复等动作中遵守业务约束。

（七）统一调度器

server/scheduler/ 提供 BuiltinScheduler 与 MTClawScheduler（经 SchedulerFactory 创建、initializeScheduler 启动），通过 INTENT_TOOL_MAP 将意图（identify/optimize/compare/approve…）映射到工具调用，并由 WorkflowEngine 编排多步工业工作流，使规则引擎成为上层意图与工作流的统一调度下游。

4.3 有益效果

相较于背景技术，本发明具有以下有益效果：

1. 调度统一：以 execute(scope, …) 单一入口统一编排识别/创建/修复/优化/比对/验证等全作用域规则，结合意图加权匹配，实现"意图—规则—动作"联动，消除多入口割裂；
2. 冲突可检可解：通过两两语义冲突识别与优先级裁决（detectRuleConflicts + priorityOrder），并能对阻塞规则准确返回 blocking_rule，避免校验结果失真；
3. 持续自进化：基于用户修正的闭环使规则能够从真实运行反馈中自动归纳、审批、部署并自动降级劣化规则，显著降低规则维护成本并提升数据质量；
4. 安全与可治理：vm 受限沙箱（createSafeContext/runSafeScript）杜绝脚本注入；规则包五维治理评分（_computePackageGovernance）与仿真干跑（RuleSimulator）保障规则可管、可控、可验证。

5. 附图说明

图1 系统架构图：展示统一规则引擎 UnifiedRuleEngine、意图识别（intent-engine）、冲突检测（rule-intent-interpreter）、仿真（RuleSimulator）、自进化（RuleEvolution）、企业规则库（EnterpriseRules）、规则桥接（sciot-rules-bridge）与统一调度器（scheduler）的分层关系及数据流向。

图2 规则调度流程图：描述从意图输入经 recognize 加权匹配得到 scope，到 execute 拉取按 priority 排序的活跃规则、逐条 _evaluateCondition 评估、_executeAction 执行、依据 conflict_strategy 决定 first_match/merge/block 分支，直至返回结果的完整流程。

图3 自进化反馈闭环图：展示"用户修正记录（sciot_corrections）→ analyzeCorrections 模式识别 → 候选规则（sciot_rule_candidates）→ approveRule 审批部署 → sciot_rules_v2 生效 → 运行命中与修正率反馈 → monitorRuleHealth 自动降级"的负反馈闭环。

图4 冲突检测时序图：展示调用方请求 detectRuleConflicts、引擎遍历规则对、调用 _detectPairConflict 判定冲突、经 _getRulePriority 与 priorityOrder 裁决胜出方并返回消解建议的交互时序。

6. 具体实施方式

以下结合真实代码说明本发明的实施步骤。

步骤一：规则初始化与元数据兜底。 系统启动时 UnifiedRuleEngine.initialize() 依次执行 _ensureTables（建 sciot_rules_v2、缓存表、历史表）、_syncBuiltinRules、_mergeStdRules（从 sciot_import.db 合并 SCSAI 全量规则，跳过 builtin- 前缀与已退役规则）、_recoverMetaIfEmpty（当 sciot_properties 等元数据表为空时从标准库全量复制），保证规则与元数据一致。

步骤二：意图加权匹配。 用户提交自然语言，调用 intent-engine.recognize：

for (const rule of rules) {
  let score = 0;
  for (const keyword of (rule.keywords||[])) {
    if (msg.includes(keyword.toLowerCase()))
      score += (isGeneric?1:3) + Math.min(kw.length-1, 4);   // 加权关键词匹配
  }
  if (score > 0) {
    const priorityBias = Math.min((rule.priority||5)-5, 5);    // 优先级偏置
    const verbBoost = scopeBoostMap[rule.scope] || 0;          // 意图动词加权
    const finalScore = score + priorityBias + verbBoost;
    if (finalScore > bestScore) { bestScore = finalScore; bestRule = rule; }
  }
}

由此得到目标 scope（如 optimize/repair），实现意图到规则调度的加权联动。

步骤三：统一调度执行。 经路由 server/routes/rule-engine.js 的 /api/rule-engine/execute/:scope 入口调用 engine.execute(scope, context, options)：

const rules = this.getRules({ scope, item_type: context.item_type, is_active: true });
rules.sort((a,b)=> (a.priority||2)-(b.priority||2));      // 按优先级排序
for (const rule of filteredRules) {
  const match = await this._evaluateCondition(rule, context);
  if (match) {
    const actionResult = await this._executeAction(rule, context, options);
    this._recordHistory(rule, scope, context, actionResult);
    this._updateRuleStats(rule.id);
    if (rule.action_type==='block' && actionResult.blocked)
      return { executed:true, blocked:true, blocking_rule: rule.id, results };
    const strategy = rule.conflict_strategy || conflict_strategy;
    if (strategy==='first_match'){ results.push(resultItem); break; }
    else if (strategy==='merge'){ results.push(resultItem); continue; }
  }
}

其中 _injectTypeContext 在执行前按 ItemType 注入必填字段与默认值；quality_score 低于规则 min_quality_score 时该规则被过滤，实现治理前置。

步骤四：冲突检测与裁决。 在规则上线或治理巡检时调用 rule-intent-interpreter.detectRuleConflicts()，对所有规则对执行 _detectPairConflict；若一方描述含"≥/至少"而另一方含"≤/不超过"则判定数值约束冲突。裁决时按 priorityOrder：

const priorityOrder = ['compliance','brand','technical_accuracy','content_integrity','readability','seo'];
const winner = priorityOrder.indexOf(p1) <= priorityOrder.indexOf(p2) ? r1 : r2;
conflicts.push({ conflictRules:[r1.id,r2.id], suggestedResolution:`已按${label}优先处理`, winner: winner.id });

步骤五：规则仿真验证。 上线前由 RuleSimulator.simulate 以 _dry_run 在 vm 沙箱（_safeEval）中执行规则脚本，记录 matched、output、duration_ms 至 rule_simulations，并由 compareResults 对比版本差异，确保规则行为符合预期。

步骤六：自进化闭环。 运行期间用户修正经 /api/rule-engine/corrections 写入 sciot_corrections 并累加 user_correction_count。周期性触发 RuleEvolution.analyzeCorrections：

const corrections = db.prepare('SELECT * FROM sciot_corrections WHERE item_type=? ...').all(itemType);
if (corrections.length < threshold) return { candidates:[] };     // 阈值保护
// 按 rule_id 分组 → _detectPattern 识别高频字段 → _generateRuleScript 生成脚本
db.prepare('INSERT INTO sciot_rule_candidates (...) VALUES (...)').run(...);

生成的候选经 getPendingCandidates 列出、人工 approveRule 审批后转为正式规则（自动 invalidatePattern(/^rules:/) 刷新缓存），或 rejectRule 驳回。monitorRuleHealth 每日巡检，对修正率 >30% 的活跃规则自动 is_active=0 降级，形成负反馈自进化。

步骤七：企业级约束与桥接。 EnterpriseRules.validateType 根据行业模板（INDUSTRY_TEMPLATES）对对象类做健康度评分；sciot-rules-bridge.loadAndFormatRules 将命中规则格式化为"【业务规则】"注入 LLM 提示，使大模型在各作用域动作中遵守约束。

步骤八：统一调度编排。 上层 initializeScheduler 创建 BuiltinScheduler/MTClawScheduler，由 INTENT_TOOL_MAP 将意图映射到工具并由 WorkflowEngine 编排，规则引擎作为统一调度下游被协同调用。

7. 权利要求书草案

权利要求1（独立权利要求）. 一种工业规则引擎的统一调度与自进化方法，其特征在于，包括以下步骤：

• 统一调度步骤：提供统一的规则执行入口，接收业务作用域标识与执行上下文，从规则库中拉取处于活跃状态且匹配所述作用域与对象类型的规则集合，按规则优先级排序后逐条评估条件并执行动作，并依据规则冲突策略对命中结果进行 first_match、merge 或 block 处理返回执行结果；
• 加权匹配步骤：在接收自然语言输入时，对意图规则进行加权关键词匹配得到基础得分，并引入优先级偏置分与意图动词加权分得到最终得分，以最终得分最高者确定目标业务作用域；
• 冲突检测步骤：对规则集合进行两两语义冲突识别，并依据预设的业务优先级顺序对存在冲突的规则对进行自动裁决，确定胜出规则；
• 自进化步骤：采集用户对规则执行结果的修正记录，当同类修正达到阈值时识别高频修改字段的稳定模式并生成规则候选，经审批后将候选部署为正式规则，并依据规则的修正率对劣化规则执行自动降级。

权利要求2（从属权利要求）. 根据权利要求1所述的统一调度与自进化方法，其特征在于，所述统一调度步骤中，不同业务作用域采用差异化的默认冲突策略：验证类与巡检类作用域采用 merge 策略以收集全部违规项，其余作用域采用 first_match 策略以命中即应用；且执行前根据对象类型自动注入属性定义、必填字段与默认值上下文，并对上下文质量评分低于规则最低质量阈值的规则进行过滤。

权利要求3（从属权利要求）. 根据权利要求1所述的统一调度与自进化方法，其特征在于，所述自进化步骤具体包括：将用户修正记录按规则标识分组并统计字段修改频率，当高频修改字段占比超过设定比例时抽取主导值并计算置信度，生成包含条件脚本与动作脚本的规则候选存入候选库；经审批部署的正式规则使规则缓存失效以即时生效；并周期性监控规则的修正率，对修正率超过设定比例的活跃规则自动置为非活跃以完成降级。

权利要求4（从属权利要求）. 根据权利要求1所述的统一调度与自进化方法，其特征在于，所述冲突检测步骤中，语义冲突识别至少包括数值约束冲突与语气风格冲突两类：数值约束冲突指一方约束含"大于等于/至少"而另一方含"小于等于/不超过"；裁决所依据的业务优先级顺序为合规优于品牌、品牌优于技术准确性、技术准确性优于内容完整性、内容完整性优于可读性、可读性优于检索优化；且规则脚本在执行前于受限沙箱环境中运行以保障安全。