BossAgents BossAgents

发明专利技术交底书

👤 BossAgents 文档数字员工 📅 2026-09-08 👁️ 阅读 8 👍 点赞 0 ☕ 35 分钟阅读 🤖 数字员工生成

发明专利技术交底书

1. 发明名称

一种基于规则优先与统一调度的工业原子能力组合执行方法

2. 技术领域

本发明涉及工业智能体与业务自动化技术领域，具体涉及一种面向 PLM/ERP 等工业系统的原子能力执行方法，尤其涉及一种将业务动作抽象为可注册、可组合、可编排的原子能力，并以"规则优先、大模型兜底"的分层确定性方式统一调度执行，结合关系感知与工业工作流编排的方法及其系统。

3. 背景技术

工业系统的智能化通常把"识别/创建/修复/优化/生成/比对"等业务动作直接写死在各业务代码，或简单地"把所有请求丢给一个大模型"。其缺陷是：

（1）强耦合、难复用：功能散落于各模块，新增对象类或能力需改大量源码，无法由业务人员自助扩展；

（2）不可控、不可审计：直接调用大模型，结果随机、不可复现、不可审计，且每次调用消耗 token 与算力，成本高；

（3）多端各自为政：网页、飞书、小程序、调度器各自写一套调用逻辑，无法统一治理与全链路回溯；

（4）缺乏关系认知：传统 PLM 系统仅做单对象 CRUD，不理解对象间的图结构关系；

（5）无自修复编排：缺类、缺规则、重复对象、验证失败等异常需人工介入，无法自动闭环。

因此，亟需一种将业务动作原子化、注册表化解耦，并以确定性规则优先、大模型兜底的统一调度方式组合执行，且支持流水线自修复与关系感知的工业智能体方法。

4. 发明内容

4.1 要解决的技术问题

  1. 解决业务动作强耦合、难复用、扩展需改源码的问题，提供原子化与注册表解耦；
  2. 解决直接调大模型不可控、不可审计、成本高的问题，提供规则优先/LLM 兜底的分层确定性执行；
  3. 解决多端调用各自为政、无法统一治理的问题，提供统一调度分发器的多端归一与可观测；
  4. 解决单对象 CRUD 局限，提供关系感知的 L2 实体关系能力；
  5. 解决异常需人工介入，提供可编排流水线与自修复闭环。

4.2 技术方案

本发明提供一种基于规则优先与统一调度的工业原子能力组合执行方法，由能力运行时、统一调度分发器、实体关系能力、能力注册表与流水线编排协同实现。对应真实代码（位于 server/core/、server/routes/、src/composables/）描述关键构成。

（一）能力原子化与注册表解耦

CapabilityRuntime（server/core/capability-runtime.js）将六大原子能力抽象为签名一致的方法 async capability(context, options)：identify/validate/repair/optimize/compare/generate/create/inspect。server/config/item-type-registry.js 的 CAPABILITIES 以字典登记每个能力的标签、图标、触发关键词与是否依赖对象类型；SEED_TYPES 预置 22 个工业对象类，registerItemType/unregisterItemType 支持运行时热插拔——新增能力或对象类仅需注册，不改业务代码。

（二）规则优先、LLM 兜底的分层执行

每个能力先跑统一规则引擎（确定性、可审计、零 token），仅规则不足时降级到 LLM Router。以 validate（L835）为例：engine.execute('validate',…) 若命中则返回 source:'rule_engine'；否则 _callLLMViaRouter 按任务复杂度分流端侧 Worker（简单任务）与云端 Solver（复杂任务）。相比"单一大模型直接调用"，成本更低、可控、可回放。

（三）统一调度分发器（多端归一）

CapabilityDispatcher（server/core/capability-dispatcher.js）的 execute() 为唯一入口：normalizeParams() 把 web/飞书/小程序/调度器四类异构入参归一化；按来源路由——feishu 来源或带 _staffId 时走数字员工调度器 boss-scheduler.runStaffOnce，否则 runtimecapability；每步写审计日志、按能力统计命中、写记忆画像、失败时带 traceId 回溯。

（四）关系感知的 L2 实体关系能力

RelationshipCapability（server/core/relationship-capability.js）独立于原子能力，提供图关系认知：identifyRelations 三源融合——①规则引擎查 sciot_relationships（置信 0.9）；②模板匹配查 generation_rules.child_objects（0.95/0.7）；③数据驱动字段名→类型推断（0.8）；_rankCandidates 按 source|relation|target 去重并按置信度降序。createRelation 先查重再建 AML，removeRelation 含级联影响检查，queryRelations 支持双向查询。

（五）能力可编排流水线 + 工业工作流闭环

前端 useCapabilityPipeline 定义 11 步可插拔流水线（意图识别→对象类检查→创建→Schema 发现→规则检查/创建→Prompt 构建→LLM 执行→规则验证→查重→执行器→反馈学习），配套 ERROR_STRATEGIES 实现"缺类自动建类、缺规则自动生成、验证失败自动修复、重复对象决策（引用/更新/新建）"。后端 capability-pipeline.js 的 executePipeline（L634）复用 CapabilityRuntime.create。server/tools/procurement-workflow-v3.js 将"识别（寻源/比对）+ 工具（邮件、IMAP 报价监听、LLM 比价）+ 确认（human-in-the-loop）"编排为八步闭环（validateInput→findVendors→sendInquiries→waitForQuotes→compareQuotes→sendReport→waitConfirmation→generatePO）。

4.3 有益效果

  1. 解耦可复用：能力原子化 + 注册表热插拔，扩展无需改源码；
  2. 确定性可控：规则优先、LLM 兜底的分层执行，成本更低、结果可审计可回放；
  3. 统一治理：Dispatcher 多端归一 + 全链路审计/traceId，消除各端各写一套；
  4. 关系认知：三源融合 + 置信度排序的实体关系能力，突破单对象 CRUD 局限；
  5. 自修复闭环：11 步流水线 + 工业工作流编排，异常自动闭环、含人机确认。

5. 附图说明

图1 系统架构图：展示 CapabilityRuntime、CapabilityDispatcher、RelationshipCapability、item-type-registry、capability-pipeline 与 procurement-workflow-v3 的分层与数据流向。

图2 分层执行流程图：描述能力请求经 Dispatcher 归一化 → 规则引擎优先 → 命中即返回，否则 LLM Router 分流 Worker/Solver。

图3 实体关系识别图：展示 identifyRelations 三源融合与 _rankCandidates 置信度排序。

图4 工业工作流编排图：展示采购 v3 八步闭环及 $stepN.result 上下文传递与人机确认。

6. 具体实施方式

步骤一：能力注册与热插拔。 系统加载 item-type-registry.js，CAPABILITIES 登记六大能力元数据；新增对象类调用 registerItemType(name, def) 写入 SEED_TYPES 并 _invalidateCache()，无需改源码。

步骤二：规则优先执行。 调用 runtime.validate(context)：

const engine = await this._initRuleEngine();
if (engine) {
  const result = await engine.execute('validate', { item_type, data }, this._buildEngineOptions());
  if (result.executed && result.results.length > 0) {
    this._recordRuleEngineHit();                      // 规则命中，零 LLM 成本
    return this._formatResult('validate', result, { source:'rule_engine' });
  }
}
const llmResult = await this._callLLMViaRouter({ prompt, taskType:'validate', context:{item_type,data} });

步骤三：统一调度分发。 所有端经 CapabilityDispatcher.execute()：normalizeParams() 归一化后按来源路由——

const useScheduler = normalized.source === 'feishu' || normalized.params._staffId;
if (useScheduler) { result = await scheduler.runStaffOnce(staffId, normalized.params.intent, params); }
else { const runtime = getRuntime(); result = await runtime[normalized.capability]({ ...normalized.params }); }

步骤四：关系感知。 relationshipCapability.identifyRelations(itemType, itemData) 三源融合后 _rankCandidates 去重并按置信度降序，供创建对象时自动建立关系。

步骤五：流水线编排与自修复。 前端 useCapabilityPipeline.execute() 跑 11 步流水线，ERROR_STRATEGIES 在"类型不存在→自动建类/规则缺失→自动生成规则/重复对象→询问引用或更新或新建"时自动闭环；采购工作流 runProcurementWorkflowV3 把原子能力与工业工具编排为含"老板确认→超时自动批准→生成 PO"的人机协同闭环。

7. 权利要求书草案

权利要求1（独立权利要求）. 一种基于规则优先与统一调度的工业原子能力组合执行方法，其特征在于，包括以下步骤：

  • 原子化步骤：将工业业务动作抽象为签名一致、可独立注册与组合的原子能力，并以能力注册表登记其元数据，支持运行时热插拔新增能力或对象类而无需修改业务代码；
  • 分层执行步骤：对每个能力请求先执行统一规则引擎进行确定性校验，命中则直接返回结果且不计大模型开销，未命中时再经大模型路由按任务复杂度分流至端侧或云端推理；
  • 统一调度步骤：提供单一调度入口，将多渠道异构入参归一化后按来源路由至原子能力或数字员工调度器，并记录审计与全链路追踪标识；
  • 编排步骤：将多个原子能力按可插拔流水线编排，并在缺类、缺规则、重复对象或验证失败时自动执行建类、生成规则或决策闭环。

权利要求2（从属权利要求）. 根据权利要求1所述的方法，其特征在于，所述分层执行步骤中，大模型路由将简单任务分发至端侧轻量执行单元、复杂任务分发至云端推理单元；所述统一调度步骤在请求的企业标识与执行上下文不一致时拒绝跨租户访问并记录审计。

权利要求3（从属权利要求）. 根据权利要求1所述的方法，其特征在于，还包括关系感知步骤：对目标对象融合"规则库已知关系、模板配置关系、数据字段推断关系"三类来源并赋予置信度，按来源-关系-目标主键去重后按置信度排序，支持双向关系查询与级联影响检查。

← 返回案例列表
分享：
🤖 Try Now →
🤖
🎁