BossAgents BossAgents

发明专利技术交底书

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

发明专利技术交底书

1. 发明名称

一种可配置的工业数字员工生成与多智能体协同执行方法

2. 技术领域

本发明涉及工业互联网与智能制造软件技术领域，具体涉及一种面向产品生命周期管理（PLM）、企业资源规划（ERP）、供应商质量管理（QMS）等工业系统的"数字员工（Digital Staff）"生成与执行方法，尤其涉及一种支持用户自助配置员工五态参数与五路径分派、并通过多智能体协作链与真实执行验证闭环来保证执行结果可验证、可追溯的方法及其系统。

3. 背景技术

在离散制造与流程制造企业的数字化转型中，机器人流程自动化（RPA）与"数字员工/智能体"被广泛用于替代重复性人工操作（变更审核、供应商审计、BOM 成本优化、内容生成、采购询价等）。然而现有方案普遍存在以下技术缺陷：

（1）配置僵化、缺乏可配置生成能力。传统 RPA 以脚本或流程图为载体，新增一名"员工"需要开发并部署代码，业务人员无法自助定义其职责、能力、调度周期与执行模式；员工配置维度（启用/停用、定时调度、执行模式、能力集、优先级）彼此割裂，无法以统一数据模型描述，难以快速生成适配不同业务域的数字员工。

（2）单智能体能力有限、缺乏多智能体协同。现有数字员工多为"一对一"的孤立机器人，彼此无协作机制：一个变更审核动作无法在成功后自动触发下游的供应商审计、BOM 优化或通知动作；缺少协作关系的建模、依赖环检测与跨员工数据传递，无法表达"员工 A 完成后由员工 B 基于 A 的结果继续处理"的链式业务流。

（3）执行不可验证、结果不可信。现有方案仅给出"执行成功/失败"的二元结论，既无第三方质量打分，也无对"是否为真实执行还是模拟/占位数据"的鉴别。演示环境与生产环境往往用 mock 数据填充，缺乏真实 API 调用痕迹、规则引擎校验与可量化的质量评分，导致执行结果不可审计、不可追溯，也无法区分端侧加速与云端降级等不同执行路径。

因此，亟需一种"可配置生成 + 多智能体协同 + 真实执行可验证"的工业数字员工方法。

4. 发明内容

4.1 要解决的技术问题

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

  1. 解决数字员工配置僵化、无法由业务人员自助生成的问题，提供覆盖启用态、调度态、执行模式态、能力态、优先级态的"五态配置"统一数据模型与生成入口；
  2. 解决单智能体能力受限、无法链式协作的问题，提供基于协作配置、依赖环检测与数据传递的"五路径分派"与多智能体协作链；
  3. 解决执行结果不可验证、不可信的问题，提供"真实执行 + 规则引擎校验 + 大模型质量评估 + mock 鉴别"的多维质量打分与五阶段可视化验证闭环。

4.2 技术方案

本发明提供一种可配置的工业数字员工生成与多智能体协同执行方法，其核心由数字员工管理（五态配置）、五路径分派调度器、对话引擎、LLM 大脑与路由、多智能体协作编排器、真实执行验证框架协同实现。下面对应真实代码（位于 server/digital-staff/、server/boss-scheduler/、real_exec_demo/、real_exec_verification/、collaboration_orchestrator/、scenario_comparison/）描述关键构成。

（一）可配置员工生成与五态配置

数字员工以统一数据模型持久化于 digital_staff 表（server/digital-staff/staff-manager.js 的 ensureTables 与 StaffManager 类）。每名员工的"五态配置"由五个可独立配置的状态维度刻画：

  • ① 启用 / 停用态（enabled 字段）：由 setStaffEnabled 动态启停，并与调度器 reloadStaffConfig 联动；
  • ② 定时调度态（schedule 字段，cron 表达式）：由 LiteScheduler 的 cronTasks 按周期触发；
  • ③ 执行模式态（execution_mode 字段，取值 auto/manual）：决定自动执行或人工确认；
  • ④ 能力态（capabilities 与 item_types 字段）：从 identify/create/repair/optimize/compare/generate 等能力中组合，并绑定业务对象类型（Part、ECR、Vendor、BOM 等）；
  • ⑤ 优先级态（priority 字段）：决定并发互斥与调度先后顺序。

员工通过 createStaff / updateStaff / deleteStaff 进行 CRUD；loadRulesAndPrompts 依据 item_types 从 sciot_rules_v2、sciot_templates、prompt_templates 表加载该员工的规则、模板与提示词，实现"配置即生效"。前端 src/views/StaffCustomizer.vue 以"描述需求→配置能力→确认创建"三步向导呈现，能力卡片即上述六类能力；config-manager.js 还提供版本化（versions / approve / publish / rollback），使员工配置可灰度、可回滚、可追溯。

（二）五路径分派调度器

调度核心为 LiteScheduler 类（server/boss-scheduler/lite-scheduler.js），其 runOnce(staffId, intent, parameters) 是统一执行入口，内部经 _withStaffMutex（员工级互斥锁）与 executionContext.withRunContext 进入 _runWorker，再由 _dispatchWorkerPath 完成"五路径分派"：

  • 路径 0a（前置）loop/goal 循环与目标驱动：_runLoopGoalPath 处理 staff.loop（循环动作）与 staff.goal（目标达成判定）；
  • 路径 0：pipeline 多步组合，_runPipelinePath 按 staff.pipeline 顺序串联多个能力（如 identify→validate→repair→optimize），前一步 _prevResult 注入后一步，并支持 MTClaw 高频动作加速（_isHighFrequencyAction + _callMTClaw）；
  • 路径 1：worker 脚本执行，_runWorkerScriptPath 经 WORKERS 映射表 require 对应脚本模块（如 ecr-worker、vendor-review、cost-optimizer、procurement 等）执行；
  • 路径 2：单能力 CapabilityRuntime，_runCapabilityPath 经 CAPABILITY_MAP 将 staff.capability 映射到 identify/validate/repair/optimize/... 方法；
  • 路径 3：自定义员工通用处理 _runGenericPath（无 worker 但有意图时）；
  • 路径 4：未知 worker 兜底，记录 ls_unknown_worker 并降级处理待办任务。

上述路径之上，CapabilityDispatcher（server/core/capability-dispatcher.js）作为统一能力调度入口，其 execute 方法先 normalizeParams 归一化多端参数（web/feishu/miniapp/scheduler），再按 source 路由：带 _staffId 或来源为 feishu 时委托 scheduler.runStaffOnce，否则调用 CapabilityRuntime，并写入审计日志（auditLog.start/complete）与记忆画像（memoryService.extractAndStoreFacts），形成"入口统一、分派五路"的骨架。

（三）对话引擎与意图驱动的路由

ConversationEngine（server/digital-staff/conversation-engine.js）提供多轮对话：用户消息经 _detectActionIntent（基于 ACTION_INTENTS 关键词）或 _detectAsrIntent（语音转写意图，映射到 DS-PROC-001/DS-ECR-001 等具体员工）识别意图；STAFF_SYSTEM_PROMPTS 为各员工注入角色提示词。回复中若含 [ACTION:type] 标记，由 _parseActions 产出待确认动作；用户回复"确认"时 _detectConfirmation 命中，经 _executeAction 调用 scheduler.runOnce 真实执行，并回写执行结果。此外 staff-router.js 的 matchStaff 以关键词加权（score += 10）与 CAPABILITY_PATTERNS 匹配，结合 _fuzzyMatch 模糊匹配，并由 matchStaffWithFallback 在无可匹配员工时回退到 DS-DATA-001，实现自然语言到具体员工的精准分派。

（四）LLM 大脑与双模型路由

LLMBrain（server/digital-staff/llm-brain.js）的 think(systemPrompt, userMessage, temperature) 是推理核心：当未配置 API Key 且无 MTClaw 时走 simulatedThinking；启用 MTClaw 时直连本地端侧服务；调用失败时按 retries 重试，并在 MTClaw 不可用时 降级到云端模型（_mtclawEnabled=false; useMtclaw=false），最终仍可回退到模拟智能，保证链路不中断。LLMRouter（server/digital-staff/llm-router.js）进一步做复杂度分类：classifyTask 依据 taskType 与复杂度关键词（complexityRules.simple/complex）将任务判为 simple/complex，simple 走 _callWorker（端侧 Ollama 小模型 gemma3:4b），complex 走 _callSolver（云端 deepseek-chat 大模型），失败时由 fallbackCount 统计并降级。该"端侧轻模型 + 云端重模型 + 自动降级"的路由，是真实执行演示中"环境自适应"与"云端降级"的代码基础。

（五）多智能体协作编排链

协作由 CollaborationOrchestrator（collaboration_orchestrator/orchestrator.py）编排：parse_collaboration_config 读取 YAML 员工配置中的 collaboration.onComplete 目标与 params_mapping，build_collaboration_graph 构建协作有向图；CircularDependencyDetector.detect 用 DFS（_dfs）检测循环依赖，存在环时返回 CIRCULAR_DETECTED 阻断执行；execute_chain 先执行首名员工，成功后经 _trigger_downstream 按 onComplete:trigger_staff_id 触发下游员工，并将 _upstreamResult 与参数映射 params_mapping 透传。ChainTracker.track 记录每一步的 staff_id、trigger_condition、data_passed 与 executed_at，产出 ChainExecutionResult（含 chain_status：completed/partial_success/failed 与 data_integrity），实现跨员工、可追溯的协同执行链。

（六）真实执行演示与质量验证闭环

真实执行由 RealExecDemoOrchestrator（real_exec_demo/orchestrator.py）驱动，其 run 串联四个阶段（STAGE_NAMES）：① 真实执行能力展示（调用 verification.verify）、② 三场景四维对比（comparator.compare）、③ 多智能体协同（collaboration.execute_chain）、④ MTClaw 与规则引擎互补（mutual_presenter.present）。

验证核心为 RealExecVerificationFramework（real_exec_verification/framework.py）的 verify：经 /api/agent/chat 真实发起员工执行，再调用 QualityScorer.score 打分。QualityScorer（real_exec_verification/quality_scorer.py）先经 MockDataDetector.detect（扫描 mock/示例/dummy/fake/sample/模拟 等关键词）鉴别是否为真实数据——一旦命中 mock，质量分直接置 0；否则结合规则引擎评分（/api/rule-engine/validate-score，权重 0.6）与 LLMQualityEvaluator.evaluate（大模型评估，权重 0.4）给出 quality_score，并记录 is_mock_data、execution_path、mtclaw_accelerated、execution_time_ms，实现"真实执行可验证、质量可量化、mock 可剔除"。

ScenarioComparator（scenario_comparison/scenario_comparator.py）对场景 A（MTClaw+端侧）、B（MTClaw+云端）、D（无 MTClaw 直连）分别执行，产出 FourDimensionReport（完成率、平均响应时间、质量评分、成本估算、端侧执行比例），CostEstimator 区分云/端 token 成本，ScenarioReportGenerator 生成四维对比 HTML/JSON 报告。前端 public/demo/real-exec.html 将上述能力可视化为五阶段演示：阶段一 MTClaw 三层路由（L1 关键词→L2 端侧 Ollama→L3 云端 DeepSeek 兜底，环境自适应检测）、阶段二 真实执行能力展示与质量打分、阶段三 三场景四维对比、阶段四 多智能体协同链、阶段五 MTClaw 与规则引擎互补验证；当端侧超时时页面以"降级"徽标切到云端，直观呈现环境自适应与云端降级。

4.3 有益效果

  1. 配置灵活、生成高效：五态配置统一数据模型 + 三步向导 + 版本化管理，使业务人员无需编码即可自助生成适配不同业务域的数字员工，并支持灰度发布与回滚。
  2. 协同增效：五路径分派覆盖脚本/能力/流水线/循环目标等多种执行形态，协作编排器支持跨员工链式触发、依赖环检测与数据传递，突破单智能体能力边界。
  3. 执行可验证、可追溯：真实 API 执行 + 规则引擎 + 大模型双重打分 + mock 鉴别，杜绝占位数据冒充实执行；五阶段演示与四维对比报告提供量化、可视、可审计的执行证据，并完整记录执行路径与 MTClaw 加速/云端降级状态。

5. 附图说明

  • 图 1 系统架构图：自顶向下分为配置层（StaffCustomizer 前端、digital-staff-routes、staff-manager 五态配置）、调度与执行层（LiteScheduler 五路径分派、CapabilityDispatcher、WORKERS/ CapabilityRuntime）、智能层（ConversationEngine、LLMRouter、LLMBrain、MTClaw 端侧/云端）、协作与验证层（CollaborationOrchestrator、RealExecVerificationFramework、ScenarioComparator），以及数据底座（sciot_import.db、digital_staff 表、审计/记忆）。
  • 图 2 员工配置与分派流程图：展示用户经 StaffCustomizer 提交五态配置 → createStaff 落库 → scheduler 按 cron/手动触发 → matchStaff 意图匹配 → _dispatchWorkerPath 五路径之一执行 → staff_execution_logs 记录。
  • 图 3 多智能体协作时序图：员工 A（如 DS-ECR-001）执行成功 → CollaborationOrchestrator 检测 onComplete → CircularDependencyDetector 确认无环 → _trigger_downstream 带 _upstreamResult 调用员工 B/C → ChainTracker 记录各步 → 汇总 ChainExecutionResult。
  • 图 4 真实执行演示五阶段图：阶段一 三层路由与环境自适应；阶段二 真实执行 + 质量打分；阶段三 三场景四维对比；阶段四 多智能体协同；阶段五 MTClaw 与规则引擎互补；并标注"云端降级"分支。
  • 图 5 质量验证流程图：/api/agent/chat 真实执行 → MockDataDetector（命中即 0 分）→ 规则引擎评分(0.6) + LLMEvaluator(0.4) → VerificationReport（quality_score、is_mock_data、execution_path、mtclaw_accelerated）。

6. 具体实施方式

下面结合真实代码给出具体实施步骤。

步骤 1：配置生成一名可配置数字员工。 业务人员在 StaffCustomizer.vue 选择能力（如 identify、repair）并填写 name、item_types、keywords，点击创建后前端 POST /api/digital-staff；digital-staff-routes.js 校验 capabilities 为数组、schedule 为合规 cron（5 字段），调用 manager.createStaff(body)→staff-manager.js 的 createStaff 写入 digital_staff。五态字段分别落库：enabled=1、schedule='/15 *'、execution_mode='auto'、capabilities=['identify','repair']、priority=5，并据 item_types 由 loadRulesAndPrompts 加载规则模板。运行时 StaffRegistry.loadStaffFromDb 以数据库为真相源构建 RuntimeStaff，并经 syncStaffToDb 与 YAML Profile 双向同步。

步骤 2：触发与五路径分派执行。 定时（cronTasks）或对话触发 ConversationEngine.sendMessage→_executeAction→scheduler.runOnce(staffId, intent, parameters)。LiteScheduler.runOnce 经 _withStaffMutex 进 _runWorker→_dispatchWorkerPath：若 staff.pipeline 非空走路径 0 _runPipelinePath（依次调用 capability.identify/validate/repair）；若 staff.worker 命中 WORKERS 走路径 1 _runWorkerScriptPath；若为单能力配置走路径 2 _runCapabilityPath；无 worker 走路径 3 _runGenericPath；未知 worker 走路径 4 兜底。执行全程写入 staff_execution_logs（addLog）。带 _staffId 的请求亦可经 CapabilityDispatcher.execute 统一归一化后入调度器。

步骤 3：多智能体协作链。 在 YAML 配置员工 collaboration.onComplete: [{target: DS-VEN-001, params_mapping: {...}}]。CollaborationOrchestrator.execute_chain(staff_id, intent) 先 build_collaboration_graph 构图，CircularDependencyDetector.detect（DFS）确认无环后执行首名员工；成功后 _trigger_downstream 对每个 target 注入 _upstreamResult 与 params_mapping 调用下游员工，ChainTracker.track 记录 step_index/staff_id/trigger_condition/data_passed，最终返回 ChainExecutionResult（含 chain_status 与 data_integrity）。

步骤 4：真实执行与质量验证。 RealExecDemoOrchestrator.run 依次执行四阶段。阶段一调用 RealExecVerificationFramework.verify(staff_id, intent)：经 POST /api/agent/chat 真实执行 → QualityScorer.score：MockDataDetector.detect 若命中 mock 关键词则 quality_score=0 且 is_mock_data=true；否则 quality_score = int(rule_engine_score0.6 + llm_eval_score0.4)，并提取 execution_path、mtclaw_accelerated、execution_time_ms。阶段二 ScenarioComparator.compare 对场景 A/B/D 执行，产出 FourDimensionReport（完成率/响应时间/质量/成本/端侧比例），CostEstimator 据 token 与 edge_execution_pct 估成本，ScenarioReportGenerator 生成对比报告。阶段三 collaboration.execute_chain 验证协同链。阶段四 mutual_presenter.present 展示 MTClaw 提速与规则引擎保质的互补结论。前端 real-exec.html 将全程以五阶段、环境自适应与云端降级徽标可视化呈现。

伪代码示例（质量打分核心）：

report = verification.verify(staff_id, intent)        # 真实API执行 + 打分
if report.is_mock_data:                               # mock鉴别
    quality_score = 0
else:
    quality_score = int(rule_engine_score * 0.6 + llm_eval_score * 0.4)
chain = collaboration.execute_chain(staff_id, intent) # 多智能体协同
assert chain.chain_status in ('completed','partial_success')

7. 权利要求书草案

权利要求 1（独立权利要求）

一种可配置的工业数字员工生成与多智能体协同执行方法，其特征在于，包括：

基于统一数据模型为每名数字员工配置五个状态维度——启用/停用态、定时调度态、执行模式态、能力态与优先级态，并据此生成可启停、可调度、可版本化的数字员工实例；

通过统一执行入口接收执行请求，依据所述数字员工实例的配置将其分派至以下五条执行路径之一并执行：流水线多步组合路径、脚本工作器路径、单能力运行时路径、自定义通用处理路径、未知工作器兜底路径，其中所述流水线路径按序串联多个业务能力并将前序执行结果注入后序步骤；

在首名数字员工执行成功后，依据预配置的协作关系触发下游数字员工，并将上游执行结果与参数映射透传至下游，形成跨员工的多智能体协作链，并在执行前对协作关系执行循环依赖检测以阻断环路；

对执行结果进行真实执行验证：通过真实接口调用数字员工、鉴别执行结果是否为模拟数据、结合规则引擎评分与大语言模型质量评估给出量化质量评分，并据评分与执行路径生成可验证、可追溯的执行证据。

权利要求 2（从属）

根据权利要求 1 所述的方法，其特征在于，所述五个状态维度存储于数字员工数据表的 enabled、schedule、execution_mode、capabilities/item_types、priority 字段中；所述能力态由 identify、create、repair、optimize、compare、generate 中的至少一个组合，并绑定业务对象类型以加载对应规则、模板与提示词；所述数字员工实例支持版本化创建、审核、发布与回滚。

权利要求 3（从属）

根据权利要求 1 所述的方法，其特征在于，所述五条执行路径由调度器的分派方法依据员工实例的 pipeline、worker、capability 配置择一执行，并在执行前经员工级互斥锁与运行上下文隔离；在执行前还依据循环/目标配置触发循环驱动或目标达成判定路径；所述统一执行入口还对来自网页、飞书、小程序与调度器的请求进行参数归一化，并按来源路由至调度器或能力运行时，同时写入审计日志。

权利要求 4（从属）

根据权利要求 1 所述的方法，其特征在于，所述真实执行验证包括：扫描执行结果中是否含有模拟数据关键词以鉴别真实/模拟，命中则质量评分置零；否则以规则引擎评分与大语言模型评估评分加权求和得到质量评分；所述协作链与验证结果以多阶段可视化方式呈现，并在端侧加速服务不可用时自动降级至云端模型执行，记录执行路径与降级状态。

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