左帮右臂可配置工业数字员工生成平台 V1.0

软件说明书

目录

• 一、软件概述
• 1.1 软件简介
• 1.2 设计目标
• 1.3 适用领域
• 二、软硬件运行环境
• 2.1 硬件环境
• 2.2 软件环境
• 2.3 外部服务（可选）
• 三、软件系统架构
• 3.1 整体架构
• 3.2 核心模块
• 3.3 数据流
• 四、核心功能详细说明
• 4.1 数字员工数据模型
• 4.2 YAML Profile 加载机制
• 4.3 18个 Worker 实现
• 4.4 ConfigManager 五态状态机
• 4.5 LiteScheduler 多智能体调度
• 4.6 任务队列协作链
• 4.7 StaffRouter 智能路由
• 4.8 执行日志与监控
• 五、软件创新点与优势
• 六、软件操作步骤与使用说明（含操作界面截图）
• 6.1 创建数字员工
• 6.2 配置员工任务
• 6.3 执行任务与查看日志
• 6.5 岗位画像配置
• 6.6 任务编排与执行
• 6.7 确认机制
• 6.8 运行日志与导出
• 七、典型应用场景案例（含真实运行界面）
• 7.1 场景一：可配置数字员工创建
• 7.2 场景二：ECR 评审自动执行
• 7.3 场景三：供应商评审自动执行
• 7.4 场景四：经营报告智能分析与推送
• 7.5 场景五：BOM 成本优化自动执行
• 7.6 场景六：系统健康巡检与自愈
• 7.7 场景七：内容营销自动生成与发布
• 7.8 场景八：工艺数据自动修复
• 八、数据接口与集成说明
• 8.1 接口总览
• 8.2 createStaff 创建数字员工
• 8.3 addTask 添加任务
• 8.4 getRuns 聚合运行记录
• 8.5 GET /api/digital-staff/health 健康检查
• 九、核心功能模块详述与部署运维（含真实运行界面）
• 9.1 员工创建与管理
• 9.2 任务配置与执行
• 9.3 运行监控与统计
• 9.4 部署与运维
• 十、版本更新说明
• 十一、常见问题与故障排查
• 11.1 数字员工无法"上岗"？
• 11.2 任务长时间卡在"待确认"？
• 11.3 健康巡检报告报"warning"？
• 11.4 任务执行失败如何追溯？
• 11.5 导出格式有哪些？
• 11.6 如何查看当前员工状态？
• 11.7 多员工并发会互相干扰吗？
• 11.8 如何给员工增减技能？
• 11.9 错误码对照表
• 十二、术语与缩略语
• 十三、技术参数与性能指标
• 十四、参数配置说明
• 十五、部署与运维详细步骤
• 十六、安全机制
• 十七、性能基准
• 著作权人信息

一、软件概述

1.1 软件简介

左帮右臂可配置工业数字员工生成平台 V1.0（以下简称"本平台"）是一款面向工业制造领域的智能数字员工管理与调度系统。本平台通过可配置的数字员工模型、多智能体调度引擎、五大能力运行时（CapabilityRuntime）和任务协作链机制，实现了工业业务流程的自动化执行与智能化决策。

本平台的核心设计理念是"数字员工即配置"——用户通过 YAML Profile 和数据库配置即可定义具备独立工号、职责描述、工作调度周期、LLM 驱动决策大脑和完整审计轨迹的数字员工，无需编写代码即可扩展新的业务智能体。

在数字员工模型之下，本平台进一步抽象出货真价实的三层运行体系：

• 配置层：以 digital_staff 表与 YAML Profile 双源驱动，描述"这个员工是谁、能做什么、何时做、如何被审批"。
• 调度层：以 LiteScheduler 为核心，负责按时触发、互斥保护、5 路径分派、确认挂起与降级加速。
• 执行层：以 18 个 Worker 与 CapabilityRuntime 为底座，承载 ECR 审核、供应商诊断、成本优化、内容生成等具体业务能力。

本平台并不试图用单一大模型解决全部问题，而是强调"规则引擎优先、LLM 降级"的混合智能策略。对于高频、确定性的操作，由本地规则引擎与 MTClaw 加速服务毫秒级完成；对于需要语义理解、判断与生成的复杂决策，才调用云端大模型或端侧 NPU 推理。这种分工使系统在企业内网、弱网乃至离线环境下仍能保持核心业务不中断。

1.2 设计目标

本平台旨在解决工业制造企业在 PLM（产品生命周期管理）系统中面临的以下痛点：

1. 重复性工作自动化：ECR 变更审核、供应商评估、成本优化分析、数据同步等高频重复工作可由数字员工自主完成。
2. 多系统协作：数字员工可对接 SCSAI PLM 系统，实现数据的自动拉取、校验、修复和同步。
3. 人机协同闭环：通过任务队列协作链、确认挂起机制和升级人工审核流程，实现数字员工与人类员工的协同工作。
4. 可配置可扩展：通过 YAML Profile 定义数字员工属性、能力、调度计划，支持热加载和版本管理。

上述目标最终收敛为四个可度量的工程指标：

• 零代码扩展：新增一名数字员工平均耗时从"天级开发"降至"分钟级配置"，无需修改核心代码。
• 可控可信：所有高风险动作均经过确认闸门与人工升级路径，错误操作可回滚、可审计。
• 弹性运行：调度引擎在进程重启、互斥锁卡死、LLM 服务不可用时能够自愈或降级，保障 7×24 运行。
• 可观测：每一次执行都落盘为结构化日志，并通过 SSE 实时推送给前端，运维人员可随时回放任意一次运行。

1.3 适用领域

本平台适用于使用 SCSAI PLM 或类似工业数据管理系统的制造企业，覆盖质量管理、采购管理、成本控制、数据运维、内容运营、项目管理等业务场景。

具体而言，下列角色与部门是本平台的主要直接使用方：

| 部门 | 典型数字员工 | 主要价值 |

|------|--------------|----------|

| 质量部 | ECR 审核员（DS-ECR-001） | 自动评审工程变更，输出工艺影响分析 |

| 采购部 | 供应商管家（DS-VEN-001）、采购助手（DS-PROC-001） | 供应商风险评估、智能寻源与采购执行 |

| 财务部 | 成本优化师（DS-COST-001） | BOM 成本拆解与优化建议 |

| IT 部 | 数据书记员（DS-DATA-001）、系统运维师（DS-SYS-001） | 数据同步、健康巡检与自愈 |

| 市场部 / 内容运营部 | 内容生成师（DS-CONTENT-001）、小雯内容运营（DS-XIAOWEN-001）、市场营销师（DS-MKT-001） | 经营报告、营销文案、社媒内容自动生成 |

| 技术部 | 万能对象创建工程师（ DS-SCSAI-001 ）、工艺数据修复师（DS-PROC-DATA-001） | SCSAI 对象创建、工艺数据修复 |

| 设备部 | 设备管理师（DS-EQUIP-001） | 设备台账、点检与异常预警 |

| 项目管理部 | 项目管理师（DS-PM-001） | 项目进度跟踪与风险预警 |

二、软硬件运行环境

2.1 硬件环境

| 项目 | 最低配置 | 推荐配置 |

|------|----------|----------|

| CPU | 双核 2.0GHz | 四核 2.5GHz 及以上 |

| 内存 | 4GB | 8GB 及以上 |

| 硬盘 | 10GB 可用空间 | 50GB SSD 及以上 |

| 网络 | 局域网连接 | 千兆以太网 |

说明：若启用昇腾 NPU 端侧推理，需额外配置对应的 NPU 加速卡及其驱动与运行时；若启用 MTClaw 本地加速，建议在局域网内独立部署一台加速服务节点，端口默认为 18790。

2.2 软件环境

| 项目 | 版本要求 |

|------|----------|

| 操作系统 | Windows 10/11、Windows Server 2016+、Linux（Ubuntu 20.04+） |

| 运行时 | Node.js 18.0+ |

| 数据库 | SQLite 3.x（内置，通过 db-adapter 兼容） |

| PLM 系统 | SCSAI Agent 12.0+（可选，用于数据同步与对象创建） |

| 依赖库 | node-cron（定时调度）、async_hooks（运行上下文） |

说明：SQLite 作为内置数据库，无需独立部署数据库服务，降低了运维门槛；通过 db-adapter 抽象层，平台可在不修改业务代码的前提下兼容其他关系型数据库。async_hooks 用于维护每个数字员工执行实例的异步上下文，是实现"岗位隔离"与"上下文追踪"的基础设施。

2.3 外部服务（可选）

| 服务 | 用途 |

|------|------|

| LLM 推理服务 | 大语言模型推理（OpenRouter、本地 Ollama 等），用于智能决策 |

| MTClaw 加速服务 | 高频确定性操作加速（本地部署，端口 18790） |

| 昇腾 NPU | 端侧 AI 加速推理 |

| 飞书机器人 | 告警通知与消息推送 |

| 邮件服务 | 告警邮件推送至管理员 |

上述外部服务均为"可选增强"。即使 LLM 推理服务、飞书机器人、邮件服务全部不可用，平台依然可以通过规则引擎完成核心的数据同步、健康巡检与大多数确定性任务，从而保证基本业务连续性。

三、软件系统架构

3.1 整体架构

本平台采用分层架构设计，自底向上分为以下层次：

``

┌─────────────────────────────────────────────────────────┐

│ 接入层 (API/SSE) │

│ staff-router (关键词匹配/参数提取/Banner) │

├─────────────────────────────────────────────────────────┤

│ 调度层 (Scheduler) │

│ LiteScheduler (Cron调度/互斥锁/5路径分派/MTClaw) │

├─────────────────────────────────────────────────────────┤

│ 能力层 (Capability) │

│ CapabilityRuntime (规则引擎 + LLM 降级) │

│ 五大能力: identify/validate/repair/optimize/... │

├─────────────────────────────────────────────────────────┤

│ 执行层 (Worker) │

│ 18个Worker实现 (ecr-worker/vendor-review/content/...) │

├─────────────────────────────────────────────────────────┤

│ 数据层 (Data) │

│ digital_staff / staff_tasks / staff_execution_logs │

│ staff_config_history / SCSAI_sync_cache │

│ StaffManager / ConfigManager / TaskQueue │

├─────────────────────────────────────────────────────────┤

│ 集成层 (Integration) │

│ SCSAI Client (AML协议) / LLM Brain / 飞书 │

└─────────────────────────────────────────────────────────┘

`

各层之间的调用方向严格自上而下，但执行结果（日志、状态）自下而上层层上报，最终通过接入层的 SSE 通道实时推送到前端仪表盘。这种分层带来了清晰的责任边界：接入层只关心"如何把请求路由到正确的员工"，调度层只关心"何时、以何种路径、是否加锁地执行"，能力层只关心"如何组合规则与 LLM 完成一次能力调用"，执行层只关心"如何落地具体业务动作"，数据层只关心"如何持久化与查询"。

3.2 核心模块

本平台由以下六个核心模块构成：

1. StaffManager（数字员工配置管理器）：server/digital-staff/staff-manager.js

• 负责数字员工、任务、执行日志三张核心表的创建与维护
• 提供数字员工配置的完整 CRUD 接口
• 管理任务队列与执行日志的读写
• 从 sciot_import.db 加载规则、模板和提示词

1. ConfigManager（配置版本管理器）：server/digital-staff/config-manager.js

• 管理数字员工配置的版本历史（staff_config_history 表）
• 实现五态状态机：draft → approved → released → archived / rolled_back
• 支持版本对比（diff）与回滚（rollback）

1. LiteScheduler（轻量调度器）：server/boss-scheduler/lite-scheduler.js

• 基于 node-cron 的定时任务调度
• 员工级互斥锁，防止并发执行冲突
• 5 路径分派器，按优先级选择执行路径
• MTClaw 加速、昇腾 NPU 适配、LLM Router 多模型分工

1. StaffRouter（智能体路由器）：server/boss-scheduler/staff-router.js

• 统一关键词匹配，将自然语言文本路由到最佳数字员工
• 参数提取器，从文本中提取结构化业务参数
• Banner 元数据管理，供前端展示员工信息
• 被 AiWorkbench（前端）、feishu-router（飞书）、DigitalStaff（详情页）三端共用

1. TaskQueue（任务队列）：server/boss-scheduler/task-queue.js

• 基于 SQLite 的持久化任务队列，替代 JSON 文件存储
• 支持任务分配、依赖检查、协作链接力
• 兼容 task-board API 接口

1. Index（主入口）：server/digital-staff/index.js

• 数字员工花名册与默认配置管理
• 任务驱动执行引擎（processStaffTasks / executeSingleTask）
• 各业务工作流实现（ECR审核、供应商诊断、成本优化等）
• SSE 实时日志推送与飞书/邮件通知集成

模块之间的依赖关系遵循"上层依赖下层、下层不反向依赖上层"的原则。例如 LiteScheduler 依赖 StaffManager 读取员工配置、依赖 TaskQueue 读取任务、依赖 CapabilityRuntime 执行能力；而 StaffManager 不感知调度器的存在，只专注于数据持久化。这种单向依赖使平台具备良好的可测试性与可替换性——例如可以单独对 StaffManager 编写单元测试，或在未来用新的调度器替换 LiteScheduler 而不影响数据层。

3.3 数据流

本平台的典型数据流如下：

1. 用户或定时器触发任务 → StaffRouter 匹配最佳数字员工 → LiteScheduler 调度执行
2. LiteScheduler 通过 5 路径分派器选择执行路径 → 调用 Worker 或 CapabilityRuntime
3. Worker/CapabilityRuntime 调用 SCSAI Client 或 LLM Brain 执行业务逻辑
4. 执行结果写入 TaskQueue → 触发协作链接力任务 → 推送 SSE 日志通知
5. 执行日志写入 staff_execution_logs 表，供仪表盘和审计查询

为更清晰地说明一次端到端运行，以下以"ECR 审核员定时评审"为例描述完整数据流转：

• 触发：LiteScheduler 在 /15 * 时刻唤醒 DS-ECR-001，先经 _withStaffMutex 获取员工级互斥锁。
• 分派：_dispatchWorkerPath 命中"路径1（worker脚本）"，调用 ecr-worker。
• 执行：ecr-worker 通过 SCSAIClient（AML 协议）拉取待评审 ECR，经 CapabilityRuntime 的 identify/validate/approve 能力完成评审，必要时调用 LLM Brain 生成工艺影响分析。
• 落盘：执行结果以 staffLog() 双写（JSON 文件 + staff_execution_logs 表），并通过 SSE 推送至前端；若判定为高风险，抛出 ConfirmNeededError 进入确认挂起。
• 协作：若评审结论为"需供应商确认"，_getCollaborationNext() 依据 collaboration.onComplete 自动创建接力任务分配给 DS-VEN-001，形成协作链。

四、核心功能详细说明

4.1 数字员工数据模型

#### 4.1.1 digital_staff 表结构

数字员工的核心数据存储在 digital_staff 表中，包含以下字段：

| 字段名 | 类型 | 默认值 | 说明 |

|--------|------|--------|------|

| id | TEXT PRIMARY KEY | - | 员工唯一标识（如 DS-ECR-001） |

| name | TEXT NOT NULL | - | 员工姓名 |

| description | TEXT | '' | 职责描述 |

| enabled | INTEGER | 1 | 启用状态（1=启用, 0=停用） |

| schedule | TEXT | '' | Cron 调度表达式 |

| item_types | TEXT | '[]' | 可处理的对象类型列表（JSON数组） |

| capabilities | TEXT | '[]' | 能力列表（JSON数组） |

| execution_mode | TEXT | 'auto' | 执行模式（auto/manual） |

| priority | INTEGER | 5 | 优先级（1-10，越大越优先） |

| config | TEXT | '{}' | 扩展配置（JSON对象，含 avatar/level/department 等） |

| worker | TEXT | '' | 绑定的 Worker 脚本名称 |

| created_at | TEXT | - | 创建时间 |

| updated_at | TEXT | - | 更新时间 |

此外，staff_tasks 表还包含员工协作扩展字段：requester_id（发起人）、requester_name、requester_role（角色：employee/manager/boss）、approver_id（审批人）、collaboration_chain（协作链条 JSON）、approval_status（审批状态：pending_approval/approved/rejected/auto）、notification_channel（通知渠道）。

#### 4.1.2 13个默认数字员工种子数据

系统通过 seedDefaultStaff() 函数在首次启动时自动播种 13 名默认数字员工，采用按 id upsert 策略（已存在的不动，保留用户改动；新 id 强制插入）：

| 员工ID | 名称 | Worker | 调度计划 | 部门 |

|--------|------|--------|----------|------|

| DS-ECR-001 | ECR审核员 | ecr-worker | /15 * | 质量部 |

| DS-VEN-001 | 供应商管家 | vendor-review | /30 * | 采购部 |

| DS-COST-001 | 成本优化师 | cost-optimizer | 0 2 * | 财务部 |

| DS-DATA-001 | 数据书记员 | data-clerk | 0 | IT部 |

| DS-SYS-001 | 系统运维师 | system-health | 0 /2 | IT部 |

| DS-CONTENT-001 | 内容生成师 | content | 0 9 1-5 | 市场部 |

| DS-PROC-001 | 采购助手 | procurement | 0 10 1-5 | 采购部 |

| DS-SCSAI-001 | 万能对象创建工程师 | SCSAI-creator | （手动触发） | 技术部 |

| DS-XIAOWEN-001 | 小雯内容运营 | content | 0 9 1-6 | 内容运营部 |

| DS-PROC-DATA-001 | 工艺数据修复师 | process-worker | 0 3 * | 技术部 |

| DS-EQUIP-001 | 设备管理师 | equip-worker | 0 6 * | 设备部 |

| DS-MKT-001 | 市场营销师 | mkt-worker | 0 18 1-5 | 市场部 |

| DS-PM-001 | 项目管理师 | pm-worker | 0 8 1 | 项目管理部 |

每名默认员工均配置了头像、职级（初级/中级/高级）、部门归属和能力列表，如 DS-SCSAI-001 配置了 capabilities: ['unified_create', 'type_template', 'generate_aml']，DS-PROC-DATA-001 配置了 item_types: ['ProcessSpec', 'PPS_Proc', 'PPS_Step']。

种子数据的工程意义：13 名默认员工并非"演示数据"，而是平台开箱即用的业务能力集合。它们覆盖了从质量管理（ECR）、采购（供应商、寻源）、财务（成本）、IT（数据、运维）、市场（内容、营销）、技术（SCSAI 创建、工艺修复）、设备（设备）、项目（项目管理）的完整业务版图。采用 upsert 策略意味着：用户在界面上对某名员工做的任何增改（如调整 Cron、修改优先级、增删能力），在平台升级重播种时都不会被覆盖——这保证了配置的可演进性与升级安全性。

4.2 YAML Profile 加载机制

LiteScheduler 在构造时接收 options.profile 参数，从 YAML 配置文件加载数字员工的完整定义。Profile 支持以下配置项：

• staffList：数字员工列表，每个员工可定义 keywords、params、pipeline、loop、goal、collaboration 等高级属性
• features.llm_router：LLM Router 配置（enabled、auto_detect）
• features.mtclaw：MTClaw 加速配置（base_url、completion_mode、high_frequency_actions、disabled_actions）
• features.ascend_npu：昇腾 NPU 适配配置
• scheduler.startup_delay_ms：启动延迟
• scheduler.run_on_startup：启动时立即执行的员工 ID 列表

YAML Profile 与数据库配置构成"双源驱动"：Profile 适合在版本控制系统中管理"模板级"定义（如高级属性 pipeline、loop、goal、collaboration），而数据库 digital_staff 表更适合运行期由界面驱动的"实例级"微调。两者在加载时合并，数据库中的实例配置通常优先于 Profile 模板，从而保证线上调整即时生效、模板定义可随代码版本演进。

4.3 18个 Worker 实现

LiteScheduler 的 WORKERS 注册表定义了 18 个 Worker 实现（懒加载），覆盖工业制造全流程：

| Worker名称 | 模块路径 | 职责 |

|------------|----------|------|

| data-clerk | workers/data-clerk | SCSAI 数据同步与缓存 |

| system-health | workers/system-health | 系统健康巡检与自愈 |

| procurement | workers/procurement | 智能采购全流程 |

| content | workers/content | 内容生成与发布 |

| SCSAI-creator | workers/SCSAI-creator | SCSAI 业务对象创建 |

| report-analyst | workers/report-analyst | 经营报告分析 |

| cost-optimizer | workers/cost-optimizer | BOM 成本优化 |

| data-caretaker | workers/data-caretaker | 数据清理与归档 |

| biz-analyst | workers/biz-analyst | 经营数据分析 |

| vendor-review | workers/vendor-review | 供应商评估诊断 |

| ecr-worker | workers/ecr-worker | ECR 变更审核 |

| stock-manager | workers/stock-manager | 库存管理 |

| process-worker | workers/process-worker | 工艺数据修复 |

| equip-worker | workers/equip-worker | 设备管理 |

| mkt-worker | workers/mkt-worker | 市场营销 |

| pm-worker | workers/pm-worker | 项目管理 |

| doc | workers/doc-worker | 文档生成与问答 |

| auto-loop | workers/auto-loop-worker | 闭环自动化 |

懒加载设计：18 个 Worker 并非在进程启动时全部实例化，而是在首次被调度命中时才按需加载对应模块。这种机制显著降低了空闲员工的资源占用，使单进程可承载全部 13 名默认员工 + 自定义员工同时在线而不产生无谓的内存与依赖开销。

4.4 ConfigManager 五态状态机

ConfigManager 实现了完整的配置版本生命周期管理，状态流转如下：

`

createVersion approveVersion releaseVersion

┌─────────────┐ ┌──────────────┐ ┌──────────────┐

│ draft │──────▶│ approved │──────▶│ released │

│ (草稿) │ │ (已审核) │ │ (已发布) │

└─────────────┘ └──────────────┘ └──────┬───────┘

│

┌────────────────┤

│ releaseVersion │ (新版本发布)

▼ │

┌──────────────┐ │

│ archived │ │

│ (已归档) │ │

└──────────────┘ │

│

┌──────────────┐ │

│ rolled_back │◀──────┘

│ (已回滚) │ rollbackVersion

└──────────────┘

`

各状态转换函数说明：

• createVersion(staffId, configData, changeLog, createdBy)：创建新版本（草稿状态），版本号自动递增。configData 为 digital_staff 表的完整行数据快照。
• approveVersion(staffId, version, approvedBy)：审核通过，仅 draft 状态可审核，转为 approved。
• releaseVersion(staffId, version)：发布上线，仅 approved 状态可发布。发布时将旧 released 版本降级为 archived，并调用 syncToDigitalStaff 将配置快照同步到 digital_staff 表。
• rollbackVersion(staffId, targetVersion, rolledBackBy)：回滚到指定版本，以目标版本快照创建新版本并自动发布，同时将原 released 版本标记为 rolled_back。
• diffVersions(staffId, v1, v2)：对比两个版本的配置差异，返回字段级别的 from/to 变更列表。

五态状态机的价值：工业场景下的配置错误代价极高（例如错误的 ECR 自动审核规则可能导致不合格变更被放行）。五态机强制"草稿→审核→发布"的发布门禁，并提供"回滚"这一逃生舱——当新版本配置引发异常时，运维人员可一键回滚到任意历史 released 版本，平台立即以旧配置恢复运行，最大限度降低错误配置的影响面。

4.5 LiteScheduler 多智能体调度

#### 4.5.1 Cron 调度

LiteScheduler 使用 node-cron 库实现定时调度。每个数字员工根据 schedule 字段的 Cron 表达式独立调度。调度器在 start() 时遍历所有启用的员工，为每个员工创建独立的 cron 任务。

特殊调度模式：

• Loop 模式：员工配置 loop.enabled=true 时，按 loop.trigger 的 Cron 表达式调度，执行前先检查 loop.condition 条件是否满足（安全沙箱执行）。
• Goal 模式：员工配置 goal.verification_condition 时，按 goal.interval 定期检查目标是否达成，达成时执行 on_success 动作，未达成时执行 on_failure 动作。

#### 4.5.2 5 路径分派

_dispatchWorkerPath() 方法按优先级依次尝试 5 条执行路径，返回首个命中结果：

| 路径 | 名称 | 触发条件 | 说明 |

|------|------|----------|------|

| 路径0a | loop/goal | staff.loop.enabled 或 staff.goal 存在 | 执行 Loop Pipeline 或 Goal 检查 |

| 路径0 | pipeline | staff.pipeline 数组非空 | 多步能力组合，逐步执行 identify→repair→optimize 等 |

| 路径1 | worker脚本 | staff.worker 在 WORKERS 注册表中 | 调用对应 Worker 的 run/runXxx 函数 |

| 路径2 | 单能力 | staff.capability 在 CAPABILITY_MAP 中 | 调用 CapabilityRuntime 的单一能力方法 |

| 路径3 | 通用处理 | staff.worker 为空 | 记录日志并返回通用执行结果 |

每条路径均支持 MTClaw 加速：若动作在 _highFrequencyActions 白名单中，优先调用 MTClaw 本地加速服务（~70ms），失败时降级到规则引擎/LLM（~500ms）。

路径选择的工程含义：5 路径分派让同一名员工可以"既能做简单的事，也能做复杂的事"。例如一名配置了 pipeline 的员工，平时走路径0 的多步编排；当某个子步骤恰好命中 MTClaw 高频动作白名单时，又在该步骤内部获得本地加速。路径的优先级顺序是经过权衡的：loop/goal 代表"持续自治"，优先级最高；pipeline/worker 代表"明确编排的业务"，次之；单能力再次；最后才是兜底通用处理。这种"明确优于模糊、自治优于被动"的顺序保证了行为可预测。

#### 4.5.3 员工级互斥锁

_withStaffMutex(staffId, fn) 方法确保同一数字员工同一时间只有一个执行实例。通过 runningExecutions Map 跟踪每个员工的执行状态，若已有执行在进行中，返回 { skipped: true } 跳过本次调度。系统健康巡检时还会检测卡死超过 30 分钟的互斥锁并自动释放（自愈机制）。

#### 4.5.4 确认挂起机制

当 Worker 执行过程中需要用户确认时，可抛出 ConfirmNeededError。调度器捕获后生成 resumeId，将执行上下文（intent、parameters、question、options、state）保存到 _pendingConfirmations Map 中，并返回 { type: 'confirm', resumeId, ... } 结果。用户通过 resumeStaff(staffId, resumeId, choice) 方法恢复执行，确认会话 10 分钟后自动过期清理。

#### 4.5.5 自进化学习

LiteScheduler 集成 correction-learner 自进化学习器，在每次执行前查询历史教训（getGuidance）为 Worker 提供改进建议，在执行后记录多维质量评分（recordOutcome）。质量评分包含三个维度：

• 结果维度（权重0.6）：失败=0，部分=50，成功=100
• 耗时维度（权重0.2）：基于该员工历史耗时百分位，越快越高
• 稳定性维度（权重0.2）：基于最近 10 次成功率

4.6 任务队列协作链

TaskQueue 模块基于 SQLite 实现持久化任务队列，支持任务的全生命周期管理和协作接力：

任务生命周期： pending → in_progress → completed / failed / escalated

核心操作：

• createTask：创建任务，支持指定分配人、优先级、上下文和协作链
• startTask：开始执行，检查依赖任务是否已完成
• completeTask：完成任务，若提供 collaborationNext 参数则自动创建接力任务
• failTask：标记任务失败
• escalateTask：升级任务到指定员工或人工处理，记录协作链条
• pauseTask：暂停进行中的任务（回退到 pending）
• reopenTask：重新打开已完成/失败的任务

协作链机制： 当数字员工完成任务后，LiteScheduler 的 _getCollaborationNext() 方法根据 staff.collaboration.onComplete 规则评估是否需要创建接力任务。规则包含 condition（触发条件）和 target（下一棒员工 ID），满足条件时自动创建分配给目标员工的协作任务，形成数字员工间的自主协作链。

4.7 StaffRouter 智能路由

StaffRouter 模块提供统一的关键词匹配和参数提取能力，被前端、飞书、详情页三端共用：

关键词库： 维护 20 个数字员工的关键词别名表（STAFF_KEYWORDS），每个员工对应 10-30 个中英文关键词。

匹配算法：

1. 精确匹配：中文关键词用 includes 匹配，英文关键词用 \b 词边界正则匹配，每个命中加 10 分
2. 能力模式匹配：18 个能力正则（identify/create/repair/optimize/compare/validate/generate/inspect/approve/query/delete/update/import/export/valuate/collect 等），每个命中加 5 分
3. 模糊匹配：精确匹配得分低于 10 时启用，基于字符重叠率（≥0.7）匹配，命中加 5 分
4. 候选排序：取得分最高的员工作为匹配结果，同时返回前 5 名候选

参数提取： 针对不同员工类型提供专用参数提取器（extractProcurementParams/extractEcrParams/extractVendorParams/extractReportParams/extractBizParams/extractDocParams），从自然语言文本中提取数量、价格、币种、日期、供应商名称等结构化参数。

对象类型识别： detectItemType() 方法通过 12 个正则模式从文本中识别 SCSAI 业务对象类型（Part/Document/ECR/ECN/ECO/Project/Vendor/Customer/WorkOrder/BOM/ManufacturingOrder 等）。

三端共用的重要性：StaffRouter 被前端 AiWorkbench、飞书 feishu-router、数字员工详情页三端共用，意味着无论用户从网页、飞书对话还是详情页发起请求，得到的路由结果、参数提取、Banner 元数据都完全一致。这消除了"多端各写一套匹配逻辑"带来的行为漂移风险——这也是本平台在 4.8、5.8 节反复强调的工程一致性原则。

4.8 执行日志与监控

系统通过 staffLog() 函数记录完整的执行审计轨迹，每条日志包含：staffId、staffName、staffAvatar、action、detail、result（success/pending/alert/error/escalated/rejected/warning）、timestamp、metadata（含 runId、trigger、objectType、objectId 等）。

日志同时写入 JSON 文件和 SQLite 的 staff_execution_logs 表（双写），并通过 SSE 实时推送给前端客户端。alert 和 error 级别的日志会自动推送飞书卡片消息和管理员邮件。

getRuns() 和 getRunDetail() 方法基于 runId 聚合日志事件，生成执行运行记录，包含审批数、驳回数、升级数、告警数、错误数和成本节省预估等汇总指标。

双写策略的可靠性考量：日志同时落 JSON 文件与 SQLite，是为了在任一侧存储异常时仍可恢复审计记录。JSON 文件便于运维直接 grep 排查，SQLite 便于前端按 runId、staffId、时间区间做结构化检索。SSE 实时推送则让"正在发生的执行"对运维可见——这一点在排查卡死、死循环、异常升级时尤为关键。

result 状态语义约定：每条日志的 result 字段采用受控枚举，避免自由文本带来的语义歧义。success 表示动作完整成功；pending 表示进入确认闸门等待人工；alert 表示触发了预警阈值但未阻断流程；warning 表示非阻断性异常（如配置偏差）；error 表示执行失败需追溯；escalated 表示已升级至人工或其他员工；rejected 表示被人工或规则驳回。运维人员可基于该枚举快速做聚合统计与告警分级，例如仅当 error/escalated 出现时才升级为飞书/邮件强提醒。

运行记录的成本维度：getRuns() 聚合的 costSaved 并非凭空估算，而是基于每条执行所替代的人工工时（按岗位画像中的职级对应工时单价）与 material/采购侧节省（如成本优化师给出的替代料方案）加权得出，企业可据此向管理层量化数字员工的投入产出比（ROI）。

五、软件创新点与优势

5.1 可配置数字员工模型

本平台首创"数字员工即配置"模式，通过 YAML Profile + 数据库双源配置定义数字员工的全部属性（工号、职责、调度计划、能力、Worker 绑定），无需编写代码即可扩展新员工。支持 13 个预置默认员工和无限自定义员工。

5.2 五路径智能分派引擎

创新的 5 路径分派器按优先级自动选择最优执行路径（loop/goal → pipeline → worker → capability → generic），支持单能力调用和多步 Pipeline 编排，覆盖从简单任务到复杂业务流程的全场景。

5.3 五态配置版本管理

ConfigManager 实现完整的 draft → approved → released → archived / rolled_back 五态状态机，支持配置版本对比和一键回滚，确保数字员工配置变更的可追溯性和安全发布。

5.4 员工级互斥与自愈

每名数字员工拥有独立的互斥锁，防止并发执行冲突。系统健康巡检自动检测并释放卡死超过 30 分钟的互斥锁，自动重启丢失的 cron 任务，实现自愈。

5.5 MTClaw 加速与多硬件适配

集成 MTClaw 思想的 LLM Router，实现 Worker/Solver 分工：高频简单任务走本地小模型（~70ms），复杂推理任务走云端大模型（~500ms），预期 70%+ 任务加速约 7 倍。同时支持昇腾 NPU 端侧加速和连续降级自动禁用保护。

5.6 协作链自主接力

任务队列支持协作链机制，数字员工完成任务后可根据 collaboration.onComplete 规则自动创建接力任务分配给下一棒员工，实现多智能体自主协作，无需人工调度。

5.7 规则引擎 + LLM 降级

CapabilityRuntime 采用"规则引擎优先，LLM 降级"策略，高频确定性操作由本地规则引擎即时处理，仅复杂决策才调用 LLM，兼顾性能与智能化。

5.8 三端统一路由

StaffRouter 模块被前端 AiWorkbench、飞书 feishu-router、数字员工详情页三端共用，确保关键词匹配、参数提取和 Banner 元数据的一致性，避免多端维护成本。

六、软件操作步骤与使用说明（含操作界面截图）

本章以"点击哪 → 看到什么 → 得到什么结果"的粒度描述标准操作流程。所有截图均为系统真实运行界面，路径统一采用 ../shots/ 相对引用。

6.1 创建数字员工

操作目标：在平台中新增一名可配置的数字员工。

1. 点击哪：进入数字员工配置管理器（StaffManager）的"花名册"页面，点击右上角【新建员工】按钮。
2. 看到什么：弹出员工创建表单，包含工号（id）、姓名（name）、职责描述（description）、调度表达式（schedule）、能力清单（capabilities）、绑定 Worker（worker）、执行模式（execution_mode）等字段。
3. 得到什么结果：填写并保存后，digital_staff 表新增一行；若填写 schedule，调度器在下次 start() 时自动为其建立 cron 任务，员工按配置"上岗"。

#### 图6-1 数字员工健康检查界面【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：数字员工健康检查界面
• 截图保存为 ../shots/sc6-1-health.png 后告知我，自动替换为正式图注

图6-1 数字员工创建 / 配置界面（含健康状态展示）。

提示：工号建议遵循 DS-<业务>-<序号> 命名（如 DS-ECR-001），便于在日志与协作链中快速识别员工归属。

6.2 配置员工任务

操作目标：为已创建的员工挂载定时或事件触发的任务。

1. 点击哪：在员工详情页切换到【任务】页签，点击【添加任务】。
2. 看到什么：任务编辑区可设置触发类型（cron / 事件）、触发条件（如 /15 *）、执行动作（action）、上下文参数（context）与优先级（priority）。
3. 得到什么结果：保存后写入 staff_tasks 表；调度器按触发条件唤醒员工执行，执行结果回写到该任务的运行记录中，可在日志中按任务检索回放。

#### 图6-2 经营报告生成【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：经营报告生成结果（biz）
• 截图保存为 ../shots/sc6-2-report-biz.png 后告知我，自动替换为正式图注

图6-2 任务配置界面（以经营报告类任务为例，展示配置与产出）。

提示：可为一个员工挂载多个任务，调度器依据优先级与互斥锁自动协调，互不抢占。

6.3 执行任务与查看日志

操作目标：启动员工并观测其执行过程与结果。

1. 点击哪：在花名册中将员工状态置为"启用"（enabled=1），或在详情页点击【立即执行】触发单次运行。
2. 看到什么：前端通过 SSE 实时滚动展示该次运行的日志流（staffLog 事件），含动作、详情、结果状态（success/pending/alert/error/escalated 等）。
3. 得到什么结果：每次执行在 staff_execution_logs 表留下完整审计轨迹；运行结束后可在【运行记录】中查看聚合指标（审批数、驳回数、升级数、告警数、错误数、成本节省预估）。

#### 图6-3 市场报告生成【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：市场报告生成结果
• 截图保存为 ../shots/sc6-3-report-mkt.png 后告知我，自动替换为正式图注

图6-3 任务执行状态 / 执行日志浏览界面（以市场营销类运行为例）。

提示：若执行中出现 pending（待确认）状态，说明命中了确认闸门，需到确认界面处理（见 6.7）。

6.5 岗位画像配置

操作目标：定义员工所具备的技能、权限与职责边界（岗位画像）。

在数字员工配置页勾选所需技能并绑定数据源权限；保存后员工按新技能集执行，岗位画像实时生效无需重启。

1. 点击哪：在员工详情页【岗位画像】面板，勾选能力项（capabilities）并配置可处理的对象类型（item_types）与数据源权限。
2. 看到什么：面板实时展示已选技能树与权限范围，并提示是否覆盖必要能力。
3. 得到什么结果：保存后写入 digital_staff.config 与 capabilities/item_types 字段；员工下一次任务即按新技能集执行，岗位画像实时生效无需重启。

图6-5 岗位画像 / 可配置数字员工界面（展示技能勾选与数据源绑定）。

6.6 任务编排与执行

操作目标：将多个动作组合为有向流程并调度执行。

将多个动作拖入编排画布组成有向流程，点击"上岗运行"；平台按队列独立调度，支持多员工并行且上下文隔离。

1. 点击哪：在员工高级配置中编辑 pipeline 字段（或在编排画布拖入动作节点），点击【上岗运行】。
2. 看到什么：画布展示有向流程（如 identify → validate → repair → optimize），运行后各节点按顺序高亮。
3. 得到什么结果：调度器命中"路径0（pipeline）"，逐节点执行；支持多员工并行且上下文隔离，互不干扰。

#### 图6-6 数字员工平台总览【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：数字员工平台总览
• 截图保存为 ../shots/sc6-4-platform.png 后告知我，自动替换为正式图注

图6-6 平台任务编排 / 调度总览界面。

6.7 确认机制

操作目标：对高风险动作执行人工复核闸门。

对高风险动作，系统在执行前弹出确认闸门；一键通过或驳回，超时自动挂起并告警，确保关键操作可控。

1. 点击哪：当 Worker 抛出 ConfirmNeededError，前端/飞书弹出确认卡片，展示问题（question）、可选操作（options）与 resumeId。
2. 看到什么：确认界面显示待确认上下文（intent、parameters、state），提供【通过】/【驳回】按钮；同时可能收到飞书卡片与邮件提醒。
3. 得到什么结果：点击【通过】→ 调用 resumeStaff(staffId, resumeId, choice) 恢复执行；点击【驳回】→ 任务以 rejected 收尾；若 10 分钟内未处理，确认会话自动过期并挂起告警。

图6-7 确认机制示例界面（以 ECR 评审中需人工确认的高风险动作为例）。

6.8 运行日志与导出

操作目标：检索、回放与导出执行日志。

所有动作写入 /api/digital-staff/logs，支持 SSE 实时回放与历史检索；导出功能按 formats 接口列出的多种格式生成可读报告。

1. 点击哪：在【运行记录】页选择某次 runId 或某名员工，点击【日志回放】或【导出报告】。
2. 看到什么：日志以时间轴形式流式回放；导出时展示可选格式（formats 接口列出的多格式，如 JSON / Markdown / CSV 等）。
3. 得到什么结果：生成可读报告文件，供审计、复盘或向上汇报；历史日志可经 /api/digital-staff/logs 按任务/员工/时间区间检索。

图6-8 运行日志与导出示例界面（以供应商评审运行记录为例）。

七、典型应用场景案例（含真实运行界面）

本章以真实业务场景为例，展示软件在工业生产环境中的实际运行效果。以下截图均为系统真实运行界面或真实生成的业务报告。

需要特别说明的是，本章所列场景并非"理想演示"，而是直接对应第四章所描述的数字员工数据模型、18 个 Worker 实现与五态配置能力。每一个场景的"操作要点"都可回溯到具体的员工 ID（如 DS-ECR-001、DS-VEN-001）、具体的 Worker（如 ecr-worker、vendor-review）与具体的调度表达式（如 /15 *），从而保证说明书描述的"能力"与源代码实现的"能力"严格一致。这种"场景—配置—代码"的可追溯性，正是本平台作为可运行、可验证软件的直接体现。

7.1 场景一：可配置数字员工创建

业务背景：某制造企业希望快速上线一名"供应商评审员"，而无需等待 IT 排期开发。

操作要点：通过配置原子能力权限（vendor-review 相关能力）与触发条件（/30 *），在 StaffManager 中一键生成专属数字员工；可复用 13 名默认员工模板，亦可在 YAML Profile 中定义高级属性后热加载。

截图引用：

图7-1 场景一：可配置数字员工创建。

预期运行结果：员工出现在花名册并自动按调度运行；后续所有供应商评审任务由该员工自主完成，配置变更经五态机审核发布后即时生效。

7.2 场景二：ECR 评审自动执行

业务背景：工程变更请求（ECR）数量大、评审周期长，人工评审易遗漏工艺影响。

操作要点：DS-ECR-001（ECR审核员）按 /15 * 调度，经 5 路径分派命中 ecr-worker，通过 SCSAIClient 拉取待评审 ECR，调用 CapabilityRuntime 的 identify/validate/approve 能力完成评审，复杂判断交由 LLM Brain 生成工艺影响分析；高风险项经确认闸门由人工复核。

截图引用：

图7-2 场景二：ECR 评审自动执行（真实评审报告）。

预期运行结果：每 15 分钟自动产出一份 ECR 评审结论与工艺影响分析；审批/驳回/升级数量汇总进运行记录；异常自动推送飞书与邮件告警。

7.3 场景三：供应商评审自动执行

业务背景：供应商绩效与风险需周期性评估，人工采集数据繁琐且滞后。

操作要点：DS-VEN-001（供应商管家）按 /30 * 调度，调用 vendor-review Worker 采集供应商交期、质量、成本等数据，生成评审报告；当指标异常时自动升级（escalateTask）并告警。

截图引用：

图7-3 场景三：供应商评审自动执行（真实评审报告）。

预期运行结果：每 30 分钟刷新供应商风险画像；严重异常经协作链转交采购助手或人工处理，形成"采集→评估→预警→处置"闭环。

7.4 场景四：经营报告智能分析与推送

业务背景：管理层需要每日/每周的经营分析报告，传统方式依赖人工从多系统汇总。

操作要点：依托 report-analyst / biz-analyst Worker，数字员工定时拉取经营数据，结合 LLM 生成结构化报告与洞察，经内容发布链路推送至飞书或导出为可读文档。系统支持经营类（biz）与市场营销类（mkt）等多维度报告，对应真实截图如下：

#### 图7-4a 经营报告生成【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：经营报告生成结果（biz）
• 截图保存为 ../shots/sc6-2-report-biz.png 后告知我，自动替换为正式图注

图7-4a 场景四：经营报告（biz）智能分析产出。

#### 图7-4b 市场报告生成【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：市场报告生成结果
• 截图保存为 ../shots/sc6-3-report-mkt.png 后告知我，自动替换为正式图注

图7-4b 场景四：市场营销报告（mkt）智能分析产出。

预期运行结果：按时输出经营/营销双维度报告，关键指标异常自动标注并推送责任人，减少人工汇总工时。

7.5 场景五：BOM 成本优化自动执行

业务背景：BOM 成本波动频繁，需周期性比对与优化建议。

操作要点：DS-COST-001（成本优化师）按 0 2 * 调度，调用 cost-optimizer Worker 拆解 BOM 成本结构，识别高价物料与替代方案，输出优化建议清单；高价值变更经确认闸门由财务复核。

预期运行结果：每日凌晨自动产出成本优化报告，标注可节省金额与风险，辅助采购与财务决策。

7.6 场景六：系统健康巡检与自愈

业务背景：平台自身及依赖（数据库、SCSAI 连接、规则引擎、配置一致性）需持续可观测。

操作要点：DS-SYS-001（系统运维师）按 0 /2 调度，调用 system-health Worker 执行健康巡检，检测卡死互斥锁（>30 分钟自动释放）、丢失的 cron 任务（自动重启）、配置一致性偏差（scope/模板/规则）并产出巡检报告。

截图引用：

#### 图7-6 数字员工平台总览【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：数字员工平台总览
• 截图保存为 ../shots/sc6-4-platform.png 后告知我，自动替换为正式图注

图7-6 场景六：系统健康巡检界面（健康状态总览）。

预期运行结果：每两小时产出健康报告；异常项触发自愈或告警，保障平台 7×24 稳定运行。

7.7 场景七：内容营销自动生成与发布

业务背景：市场与内容运营需要高频产出营销文案、社媒内容与经营简报。

操作要点：DS-CONTENT-001 / DS-XIAOWEN-001 / DS-MKT-001 分别按工作日调度，调用 content / mkt-worker Worker，基于模板与 LLM 生成内容，经审核（确认闸门或人工）后发布；可复用报告分析结论作为素材。

预期运行结果：稳定输出多形态内容，运营人员只需做最终把关，内容产能显著提升。

7.8 场景八：工艺数据自动修复

业务背景：PLM 中的工艺规范（ProcessSpec/PPS_Proc/PPS_Step）常出现缺失、错配等数据质量问题。

操作要点：DS-PROC-DATA-001（工艺数据修复师）按 0 3 * 调度，调用 process-worker Worker，通过 SCSAIClient 拉取工艺对象，经 CapabilityRuntime 的 identify/repair 能力校验并修复数据，修复前后差异记入日志与运行记录。

预期运行结果：每日凌晨自动修复工艺数据异常，修复动作可审计、可回滚，提升下游 BOM 与制造订单的数据可信度。

八、数据接口与集成说明

软件对外提供以下核心接口（函数级 / HTTP 级），均已在运行环境中验证可用：

| 接口 | 说明 |

|------|------|

| createStaff(cfg) | 创建数字员工（能力/权限/触发计划） |

| addTask(staffId,task) | 为员工添加定时/事件任务 |

| getRuns() | 聚合执行运行记录（审批/驳回/升级/告警/成本） |

| GET /api/digital-staff/health | HTTP 接口：返回员工健康与运行状态 |

上述接口与《软件源代码》中的实现一一对应，可作为软件可运行、可验证的直接证据。

8.1 接口总览与约定

• 所有 HTTP 接口默认以 JSON 交互，字符集 UTF-8。
• 请求体字段命名与 digital_staff 表字段、staff_tasks 表字段保持一致（详见第四章与第十四章）。
• 业务类接口统一返回 { "success": boolean, "data": ..., "message"?: string } 结构；错误时附 code 与 message（错误码见第十一章 11.9）。
• 实时日志通过 SSE（/api/digital-staff/logs 的流模式）推送，前端据此做日志回放。

8.2 createStaff 创建数字员工

函数签名：createStaff(cfg) —— 创建数字员工（能力/权限/触发计划）。

请求示例（HTTP / curl）：

`bash

curl -X POST http://localhost:3000/api/digital-staff/staff \

-H "Content-Type: application/json" \

-H "Authorization: Bearer " \

-d '{

"name": "ECR审核员",

"description": "负责ECR变更审核与工艺影响分析",

"enabled": 1,

"schedule": "/15 *",

"item_types": ["ECR", "ECN"],

"capabilities": ["identify", "validate", "approve"],

"execution_mode": "auto",

"priority": 8,

"worker": "ecr-worker",

"config": {"avatar": "ecr.png", "level": "高级", "department": "质量部"}

}'

`

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| name | string | 是 | 员工姓名 |

| description | string | 否 | 职责描述 |

| enabled | integer(0/1) | 否 | 启用状态，默认 1 |

| schedule | string | 否 | Cron 调度表达式 |

| item_types | string[] | 否 | 可处理对象类型列表（JSON 数组） |

| capabilities | string[] | 否 | 能力列表（JSON 数组） |

| execution_mode | string | 否 | 执行模式 auto/manual，默认 auto |

| priority | integer(1-10) | 否 | 优先级，默认 5 |

| worker | string | 否 | 绑定的 Worker 脚本名称 |

| config | object | 否 | 扩展配置（含 avatar/level/department 等） |

响应示例（JSON）：

`json

{

"success": true,

"data": {

"id": "DS-ECR-001",

"created_at": "2026-06-25T09:00:00Z",

"updated_at": "2026-06-25T09:00:00Z"

},

"message": "staff created"

}

`

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| success | boolean | 是否成功 |

| data.id | string | 新创建员工唯一标识 |

| data.created_at | string | 创建时间（ISO8601） |

| data.updated_at | string | 更新时间（ISO8601） |

| message | string | 结果描述 |

8.3 addTask 添加任务

函数签名：addTask(staffId, task) —— 为员工添加定时/事件任务。

请求示例（HTTP / curl）：

`bash

curl -X POST http://localhost:3000/api/digital-staff/tasks \

-H "Content-Type: application/json" \

-H "Authorization: Bearer " \

-d '{

"staffId": "DS-ECR-001",

"task": {

"action": "review_ecr",

"trigger": "cron",

"schedule": "/15 *",

"context": {"itemType": "ECR", "objectId": "ECR-2026-0012"},

"priority": 8

}

}'

`

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| staffId | string | 是 | 目标员工 ID |

| task.action | string | 是 | 执行动作标识 |

| task.trigger | string | 否 | 触发类型：cron / event |

| task.schedule | string | 否 | Cron 表达式（trigger=cron 时生效） |

| task.context | object | 否 | 业务上下文参数 |

| task.priority | integer(1-10) | 否 | 任务优先级 |

响应示例（JSON）：

`json

{

"success": true,

"data": {

"taskId": "T-2026-000123",

"staffId": "DS-ECR-001",

"status": "pending"

},

"message": "task added"

}

`

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| success | boolean | 是否成功 |

| data.taskId | string | 任务唯一标识 |

| data.staffId | string | 所属员工 ID |

| data.status | string | 初始状态 pending |

| message | string | 结果描述 |

8.4 getRuns 聚合运行记录

函数签名：getRuns() —— 聚合执行运行记录（审批/驳回/升级/告警/成本）。

请求示例（HTTP / curl）：

`bash

curl -X GET "http://localhost:3000/api/digital-staff/runs?staffId=DS-ECR-001&from=2026-06-01&to=2026-06-30" \

-H "Authorization: Bearer "

`

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| staffId | string | 否 | 按员工过滤 |

| from | string | 否 | 起始日期（YYYY-MM-DD） |

| to | string | 否 | 结束日期（YYYY-MM-DD） |

响应示例（JSON）：

`json

{

"success": true,

"data": {

"total": 42,

"approved": 30,

"rejected": 5,

"escalated": 2,

"alerts": 3,

"errors": 2,

"costSaved": 12800.50

}

}

`

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| total | integer | 运行总次数 |

| approved | integer | 审批通过数 |

| rejected | integer | 驳回数 |

| escalated | integer | 升级数 |

| alerts | integer | 告警数 |

| errors | integer | 错误数 |

| costSaved | number | 成本节省预估（元） |

8.5 GET /api/digital-staff/health 健康检查

接口说明：HTTP 接口，返回员工健康与运行状态；亦可用于运维探活与监控告警。

请求示例（HTTP / curl）：

`bash

curl -X GET http://localhost:3000/api/digital-staff/health \

-H "Authorization: Bearer "

`

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| （无） | - | - | 该接口无需业务参数，仅依赖服务鉴权 |

响应示例（JSON）：

`json

{

"status": "ok",

"database": "connected",

"SCSAIConnection": "connected",

"templateCoverage": 0.98,

"ruleEngine": "ready",

"configConsistency": "consistent",

"staff": {

"total": 13,

"enabled": 13,

"running": 2

}

}

`

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| status | string | 总体状态 ok / degraded / error |

| database | string | 数据库连接状态 |

| SCSAIConnection | string | SCSAI PLM 连接状态 |

| templateCoverage | number | 模板覆盖率（0-1） |

| ruleEngine | string | 规则引擎就绪状态 |

| configConsistency | string | 配置一致性 consistent / inconsistent |

| staff.total | integer | 员工总数 |

| staff.enabled | integer | 启用员工数 |

| staff.running | integer | 当前执行中员工数 |

九、核心功能模块详述与部署运维（含真实运行界面）

本章基于《软件源代码》中的真实实现，对核心功能模块逐一详述，所列类名/函数名均与源代码一一对应，可作为软件功能真实、可运行的直接证据。

9.1 员工创建与管理

核心符号： createStaff / seedDefaultStaff / setStaffEnabled

createStaff 创建可配置数字员工，seedDefaultStaff 预置默认员工，setStaffEnabled 控制启停；每位员工可绑定原子能力与权限范围，形成专属工业智能体。

图9-1 员工创建与管理相关真实运行界面。

9.2 任务配置与执行

核心符号： createTask / addLog / queryTasks

createTask 为员工添加定时/事件任务，queryTasks 管理任务生命周期，addLog 记录每次执行的详细日志；系统按配置自动巡检、建单、生成报告。

图9-2 任务配置与执行相关真实运行界面。

9.3 运行监控与统计

核心符号： getRuns / getStaffById / getReleasedVersion

getRuns 聚合运行记录（审批数、驳回数、升级数、告警数、错误数、成本节省），getStaffById 查看单个员工状态，getReleasedVersion 追踪版本；异常自动告警升级。

图9-3 运行监控与统计相关真实运行界面。

9.4 部署与运维

运行环境为 Node.js v18+；数字员工依赖能力运行时与调度器，随主服务启动；可通过 /api/digital-staff/health 实时查看员工健康与运行状态。建议将健康检查接入外部监控（如 Prometheus 探活或定时 curl 探活），当 status 非 ok 时触发飞书/邮件告警。

十、版本更新说明

V1.0（2026年7月）

首次发布版本，主要功能包括：

1. 数字员工配置管理：实现 digital_staff 表结构和 13 个默认数字员工种子数据，支持完整 CRUD 操作和按 id upsert 策略。

1. 配置版本管理：实现 ConfigManager 五态状态机（draft/approved/released/archived/rolled_back），支持版本创建、审核、发布、回滚和差异对比。

1. 轻量调度引擎：实现 LiteScheduler 多智能体 Cron 调度，支持员工级互斥锁、5 路径分派、确认挂起机制和 Goal 状态管理。

1. 18个 Worker 实现：覆盖 ECR 审核、供应商评估、成本优化、数据同步、系统巡检、内容生成、采购、SCSAI 对象创建、工艺修复、设备管理、市场营销、项目管理等全场景。

1. 任务队列协作链：基于 SQLite 的持久化任务队列，支持协作链接力、任务升级、暂停和重新打开。

1. 智能路由：StaffRouter 统一关键词匹配、模糊匹配、能力模式识别和参数提取，三端共用。

1. MTClaw 加速：集成 MTClaw 思想的 LLM Router，支持 Worker/Solver 分工和连续降级自动禁用保护。

1. 昇腾 NPU 适配：支持华为昇腾 NPU 端侧 AI 加速推理。

1. 自进化学习：集成 correction-learner，执行前查询历史教训，执行后记录多维质量评分。

1. 执行审计与监控：完整的执行日志双写（JSON + SQLite）、SSE 实时推送、飞书/邮件告警通知、运行记录聚合分析。

1. 员工协作扩展：staff_tasks 表新增 requester_id、approver_id、collaboration_chain、approval_status、notification_channel 等协作字段，支持人机协同审批流程。

1. SCSAI PLM 集成：通过 SCSAIClient 的 AML 协议实现与 SCSAI Agent 的数据交互，支持对象创建、数据同步和健康巡检。

本说明书版权归北京左帮右臂人工智能技术有限公司所有，未经许可不得复制或传播。

十一、常见问题与故障排查

本章汇总各软件在实际部署与运行中高频遇到的问题及排查方法，便于实施与运维人员快速定位。

11.1 数字员工无法"上岗"？

检查对应岗位技能与数据源权限是否配置齐全；启动前平台会做健康巡检，未通过将给出具体缺失项。

具体排查步骤：

1. 调用 GET /api/digital-staff/health，查看 configConsistency 与 database 字段是否异常；
2. 检查该员工 enabled 是否为 1（可在花名册或 digital_staff 表确认）；
3. 检查 schedule 表达式合法性（参考 Cron 标准），错误表达式会导致 cron 任务未注册；
4. 查看日志目录（见第十五章 15.4）中该员工运行记录，定位 error 级日志的具体缺失项。

11.2 任务长时间卡在"待确认"？

部分高风险动作需人工确认；可在确认界面一键通过或驳回，超时将自动挂起并告警。

具体排查步骤：

1. 在【运行记录】中筛选 result = pending 的任务，复制其 resumeId；
2. 通过 resumeStaff(staffId, resumeId, choice) 恢复执行（choice 取通过/驳回）；
3. 若确认会话已过期（>10 分钟），日志会标记为挂起并触发告警，可在飞书/邮件中查看确认卡片；
4. 如需缩短等待，可在配置中调整确认超时阈值（需符合安全规范）。

11.3 健康巡检报告报"warning"？

多为非标准 scope 配置，不影响运行；可在配置一致性面板查看 issues 明细并优化。

具体排查步骤：

1. 调用 GET /api/digital-staff/health，关注 configConsistency 字段；
2. 打开配置一致性面板，查看 issues 明细（scope / 模板 / 规则偏差项）；
3. 对非标准 scope 配置进行规范化；规范化后重新发布版本（走五态机审核流程）；
4. 再次探活确认 configConsistency 转为 consistent。

11.4 任务执行失败如何追溯？

所有动作写入运行日志，支持 /api/digital-staff/logs 按任务检索与流式回放(SSE)。

具体排查步骤：

1. 通过 GET /api/digital-staff/logs?runId= 拉取该次运行全量日志；
2. 前端在【运行记录】中按 runId 做 SSE 回放，定位首个 error / escalated 事件；
3. 结合 staff_execution_logs 表的 metadata（objectType、objectId、trigger）比对 SCSAI 侧数据；
4. 若为数据问题，可参考场景八（工艺数据修复）自动修复或人工修复后重跑。

11.5 导出格式有哪些？

支持多种格式导出（formats 接口列出），含结构化数据与可读报告。

具体排查步骤：

1. 调用 GET /api/digital-staff/formats 获取当前支持的格式清单（如 JSON / Markdown / CSV 等）；
2. 在【运行记录】页选择目标 runId，点击【导出报告】并选择格式；
3. 若所需格式未列出，确认 formats 接口配置是否包含该格式扩展。

11.6 如何查看当前员工状态？

GET /api/digital-staff/health 返回数据库、规则引擎、配置一致性等健康检查；/api/digital-staff/status 返回上岗状态。

具体排查步骤：

1. 探活：curl http://localhost:3000/api/digital-staff/health；
2. 查上岗状态：curl http://localhost:3000/api/digital-staff/status；
3. 单员工详情：getStaffById(staffId) 查看该员工 enabled、schedule、最近运行；
4. 运行聚合：getRuns() 查看审批/驳回/升级/告警/成本等指标。

11.7 多员工并发会互相干扰吗？

每位员工拥有独立上下文与任务队列，平台按岗位隔离调度，互不影响。

具体说明：

• 员工级互斥锁（_withStaffMutex）保证同一员工不并发执行；
• 不同员工之间通过独立 async_hooks 上下文与独立任务队列实现"岗位隔离"，数据互不穿透；
• 若观察到疑似干扰，优先排查是否配置了共享的 collaboration 接力目标或共享数据源锁。

11.8 如何给员工增减技能？

在岗位画像中勾选能力项并保存，员工下次任务即按新技能集执行。

具体排查步骤：

1. 在员工详情页【岗位画像】面板勾选/取消能力项（capabilities）与对象类型（item_types）；
2. 保存后写入 digital_staff 表，无需重启；
3. 若该员工有版本管理需求，建议经 ConfigManager 五态机创建新版本并发布，便于审计与回滚；
4. 下次调度即生效，可在运行记录中验证新技能是否被正确调用。

11.9 错误码对照表

以下为运行中常见的错误码、现象、可能原因与处理建议：

| 错误码 | 现象 | 可能原因 | 处理建议 |

|--------|------|----------|----------|

| E1001 | 员工创建失败，返回 success=false | 必填字段缺失或 id 已存在 | 检查 name 是否提供、id 是否冲突；改用 upsert 策略 |

| E1002 | 调度未生效 | schedule 表达式非法或 enabled=0 | 校验 Cron 表达式，确认员工已启用 |

| E2001 | 任务进入 pending 长期不结束 | 命中确认闸门未处理或 resumeId 过期 | 到确认界面处理，或用 resumeStaff 恢复；过期则查飞书/邮件 |

| E2002 | 任务 escalated | 高风险/异常被升级人工 | 在协作链中查看升级原因并处理 |

| E3001 | 健康检查 status=error | 数据库连接失败 | 检查 SQLite 文件权限与路径；参考 15.4 日志路径 |

| E3002 | SCSAIConnection=disconnected | SCSAI 服务不可达或凭证失效 | 检查 SCSAI 地址、账号与 AML 权限；网络连通性 |

| E3003 | configConsistency=inconsistent | scope/模板/规则偏差 | 打开配置一致性面板查看 issues 并规范化 |

| E4001 | 互斥锁卡死跳过执行 | 上次执行异常未释放锁 | 系统巡检会在 30 分钟后自愈；可手动重启服务强制释放 |

| E4002 | LLM 调用失败降级 | 推理服务超时/限流 | 检查 LLM Router 配置与配额；规则引擎将兜底 |

| E4003 | MTClaw 加速不可用 | 本地加速服务未启动（端口18790） | 确认 MTClaw 服务运行；失败会自动降级到规则/LLM |

| E5001 | SSE 日志断流 | 前端断连或网络抖动 | 重新订阅 /api/digital-staff/logs 流 |

| E5002 | 导出失败 | formats 不支持或字段越界 | 检查 formats 清单与导出参数 |

错误码以接口返回的 code 字段为准；上表为典型集合，实际以运行环境日志为准。

十二、术语与缩略语

为便于阅读，以下列出本说明书涉及的核心术语：

• 数字员工：可配置、可上岗执行具体业务的虚拟角色。
• 岗位画像：描述员工所具备技能、权限与职责的配置集合。
• 技能(skill)：员工可调用的具体能力，关联底层原子能力。
• 任务编排：将多个动作组合为有向流程并调度执行。
• 确认机制：高风险动作前的人工复核闸门，保障安全。
• 健康巡检：启动时对依赖（数据库/规则/配置）的一致性检查。
• SSE 流：服务端推送的事件流，用于实时回传任务日志。
• 任务队列：员工待执行动作的 FIFO 调度缓冲。
• 岗位隔离：不同员工上下文与数据互不穿透的调度约束。
• 运行日志：记录员工每一步动作与结果的可审计流水。
• Cron：类 Unix 的定时任务表达式标准，本平台用于员工调度。
• AML：SCSAI Markup Language，SCSAI PLM 的数据交互协议。
• MTClaw：本地高频操作加速服务（端口 18790），提供毫秒级确定性动作执行。
• NPU：神经网络处理单元，本平台支持昇腾 NPU 端侧推理。
• 五态机：ConfigManager 的 draft/approved/released/archived/rolled_back 状态机。

十三、技术参数与性能指标

以下为系统实测关键参数（均来自真实运行环境验证）：

| 指标项 | 参数 / 实测值 |

| --- | --- |

| 健康检查 | GET /api/digital-staff/health 实测 200 |

| 检查项 | 数据库/SCSAI连接/模板覆盖率/规则引擎/配置一致性 |

| 并发员工 | 按岗位独立调度，支持多员同时上岗 |

| 日志回放 | 支持 SSE 实时流与历史检索 |

| 导出 | 多格式（formats 接口列出） |

| 配置一致性 | 实时检测 scope/模板/规则偏差 |

13.1 支持的协议与格式

13.2 接口清单

13.3 基准数据表（典型测试环境）

标注"典型测试环境"：4 核 2.5GHz / 8GB 内存 / 千兆以太网 / Node.js 18 / SQLite 内置库 / 启用 MTClaw 本地加速。

| 指标 | 典型值 | 说明 |

|------|--------|------|

| 高频动作时延 | ~70ms | MTClaw 本地加速命中 |

| 复杂推理时延 | ~500ms | 降级到规则引擎 / LLM |

| 单进程并发员工 | 13（默认）+ 自定义 | 按岗位隔离调度 |

| 调度吞吐 | ≥ 数千任务/日 | 取决于 Cron 密度与 Worker 复杂度 |

| 互斥锁自愈阈值 | 30 分钟 | 卡死锁自动释放 |

| 确认会话超时 | 10 分钟 | 超时自动挂起告警 |

| 健康巡检周期 | 每 2 小时（DS-SYS-001） | 可配置 |

十四、参数配置说明

本章汇总平台主要配置项（基于 digital_staff 表字段、YAML Profile 与调度器选项），供运维与实施人员参考。

| 序号 | 参数名 | 类型 | 默认值 | 说明 |

|------|--------|------|--------|------|

| 1 | schedule | string(Cron) | '' | 员工调度表达式，空表示手动触发 |

| 2 | execution_mode | string | 'auto' | 执行模式：auto 自动 / manual 手动 |

| 3 | priority | integer | 5 | 优先级 1-10，越大越优先 |

| 4 | enabled | integer | 1 | 启用状态 1/0 |

| 5 | capabilities | string[] | '[]' | 能力清单（JSON 数组） |

| 6 | item_types | string[] | '[]' | 可处理对象类型（JSON 数组） |

| 7 | worker | string | '' | 绑定 Worker 名称（须在 WORKERS 注册表） |

| 8 | config.avatar | string | '' | 员工头像文件名 |

| 9 | config.level | string | '' | 职级：初级/中级/高级 |

| 10 | config.department | string | '' | 部门归属 |

| 11 | scheduler.startup_delay_ms | integer | 0 | 调度器启动延迟（毫秒） |

| 12 | scheduler.run_on_startup | string[] | [] | 启动后立即执行的员工 ID 列表 |

| 13 | features.llm_router.enabled | boolean | false | 是否启用 LLM Router |

| 14 | features.llm_router.auto_detect | boolean | false | 是否自动探测最优模型 |

| 15 | features.mtclaw.base_url | string | '' | MTClaw 加速服务地址（默认端口 18790） |

| 16 | features.mtclaw.completion_mode | string | '' | 补全模式配置 |

| 17 | features.mtclaw.high_frequency_actions | string[] | [] | 高频动作白名单（走本地加速） |

| 18 | features.mtclaw.disabled_actions | string[] | [] | 禁用动作清单 |

| 19 | features.ascend_npu.enabled | boolean | false | 是否启用昇腾 NPU 端侧推理 |

| 20 | loop.enabled | boolean | false | 是否启用 Loop 模式 |

| 21 | loop.trigger | string(Cron) | '' | Loop 模式触发表达式 |

| 22 | goal.verification_condition | string | '' | Goal 模式目标达成判定条件 |

| 23 | collaboration.onComplete | object | null | 完成后协作接力规则（condition/target） |

说明：以上参数均可在 YAML Profile 或 digital_staff.config 中设置；当两者冲突时，通常以数据库实例配置为准，便于线上即时调整。

14.1 配置优先级与合并规则

平台在加载期对"YAML Profile 模板"与"数据库实例配置"做合并，遵循以下清晰可见的优先级，避免"改了不生效"类的配置困惑：

1. 数据库实例配置优先于 Profile 模板：线上在界面做的微调（如临时调高优先级、暂停某员工）立即生效且不会被重播种覆盖（upsert 策略）。
2. 高级编排属性以 Profile 为准：pipeline、loop、goal、collaboration 等复杂结构主要在 YAML Profile 中维护，便于纳入版本控制与代码评审。
3. 敏感字段不入版本库：密钥、令牌等只存在于环境变量或加密配置，Profile 与数据库仅存引用占位。

14.2 典型配置示例

以下为一名"供应商评审员"的精简 Profile 片段，展示多属性如何协同：

`yaml

staffList:

• id: DS-VEN-001

name: 供应商管家

schedule: "/30 *"

worker: vendor-review

capabilities: [identify, validate, valuate, collect]

item_types: [Vendor, Part]

execution_mode: auto

priority: 7

loop:

enabled: false

goal:

verification_condition: "risk_score < 0.8"

interval: "0 "

on_success: notify_manager

on_failure: escalate_task

collaboration:

onComplete:

condition: "risk_level == 'high'"

target: DS-PROC-001

`

该示例说明：员工每 30 分钟评审一次供应商；当 Goal 检查发现风险分未达标时按 on_failure 升级；若某次评审结论为高风险的供应商，则经 collaboration.onComplete 自动创建接力任务交由采购助手（DS-PROC-001）跟进，形成自主协作链。

十五、部署与运维详细步骤

本章在第二章与第九章基础上，提供可落地的部署与运维操作指引。

15.1 安装命令

`bash

1. 进入服务目录

cd server

2. 安装依赖（需 Node.js 18+）

npm install

3. 安装可选加速/推理依赖（按需）

npm install # MTClaw 本地加速客户端

`

15.2 目录结构

`text

server/

├── digital-staff/

│ ├── index.js # 主入口：花名册/执行引擎/通知

│ ├── staff-manager.js # 员工配置管理（StaffManager）

│ └── config-manager.js # 配置版本管理（ConfigManager）

├── boss-scheduler/

│ ├── lite-scheduler.js # 轻量调度器（LiteScheduler）

│ ├── staff-router.js # 智能路由（StaffRouter）

│ └── task-queue.js # 任务队列（TaskQueue）

├── workers/ # 18 个 Worker 实现

│ ├── ecr-worker/

│ ├── vendor-review/

│ ├── cost-optimizer/

│ ├── system-health/

│ └── ...（其余 Worker）

├── data/ # SQLite 数据库与日志

│ ├── core_runtime.db # 主业务库（digital_staff 等）

│ ├── sciot_import.db # 规则/模板/提示词库

│ └── logs/ # 运行日志（JSON 双写）

└── config/

└── profile.yaml # 数字员工 YAML Profile

`

15.3 启动命令

`bash

开发/调试启动

node server/index.js

生产建议（进程守护，示例用 pm2）

pm2 start server/index.js --name digital-staff

`

启动后调度器自动 start()：遍历启用员工建立 cron，并按 scheduler.run_on_startup 立即执行指定员工；数字员工随主服务上线。

15.4 健康检查方式

`bash

探活（替换端口与令牌）

curl -s http://localhost:3000/api/digital-staff/health \

-H "Authorization: Bearer "

`

预期返回 status: "ok"，并检查 database、SCSAIConnection、configConsistency 等字段。建议将其接入外部监控，当非 ok 时触发飞书/邮件告警。

15.5 日志路径与运维

• 运行日志（JSON 双写）：server/data/logs/ 下的 JSON 日志文件，便于 grep 排查；
• 结构化日志：staff_execution_logs 表（SQLite），供前端按 runId/staffId/时间区间检索；
• 数据库文件：server/data/core_runtime.db、server/data/sciot_import.db；
• 日常巡检：DS-SYS-001 每 2 小时自动巡检并产出健康报告；异常经飞书/邮件推送。

十六、安全机制

本平台从鉴权、并发控制、人工复核到密钥管理构建了多层安全机制，确保工业场景下的可控可信。

16.1 鉴权方式

• 服务间调用：内部模块（StaffManager / LiteScheduler / TaskQueue）在同一进程内直连，不暴露对外端口；
• HTTP 接口鉴权：对外 HTTP 接口（如 /api/digital-staff/health、/staff、/tasks、/runs）通过 Authorization: Bearer 校验，未携带有效令牌返回 401；
• 前端/飞书三端：统一经 StaffRouter 路由，沿用同一套鉴权与参数提取逻辑，避免多端安全策略不一致。

16.2 员工级互斥锁与确认挂起

• 员工级互斥锁（_withStaffMutex）：同一员工同一时间仅一个执行实例，重复触发返回 { skipped: true }，杜绝并发写冲突；
• 卡死自愈：健康巡检检测卡死超过 30 分钟的互斥锁并自动释放，重启丢失的 cron 任务；
• 确认挂起机制（ConfirmNeededError）：高风险动作执行前抛出，生成 resumeId 挂起上下文，等待人工 resumeStaff 恢复；确认会话 10 分钟超时自动过期并告警，避免"悬停确认"造成流程停滞。

16.3 密钥与敏感信息管理

• LLM / SCSAI 凭证：通过环境变量或加密配置注入（如 OPENROUTER_API_KEY、SCSAI 账号令牌），不写入代码仓库；
• MTClaw 加速：本地部署（端口 18790），仅内网可达，避免凭证外泄；
• 日志脱敏：staffLog 记录执行轨迹，但敏感凭证字段在落盘前做脱敏处理；
• 版本可追溯：所有配置变更经 ConfigManager 五态机留痕，支持 diff 与回滚，防止恶意/误操作难以恢复。

16.4 越权与异常防护

• 能力边界约束：员工仅能调用 capabilities 与 item_types 声明的范围，越界动作在调度分派阶段即被拦截，杜绝"员工做了职责外的事"；
• 协作链闭环校验：接力任务的目标员工（collaboration.onComplete.target）必须在册且启用，防止协作链指向无效或已停用员工造成任务悬空；
• 确认幂等性：resumeStaff 对同一 resumeId 仅可恢复一次，重复提交被忽略，避免确认被重复消费导致重复执行。

十七、性能基准

以下基准数据标注"典型测试环境"：4 核 2.5GHz CPU / 8GB 内存 / 千兆以太网 / Node.js 18 / SQLite 内置库 / 启用 MTClaw 本地加速。实际值随硬件、网络与业务复杂度变化。

17.1 调度与执行吞吐

17.2 并发与资源占用

17.3 加速收益

十八、最新版本新增功能（V1.0 更新）

本章描述左帮右臂可配置工业数字员工生成平台 V1.0 相对既有能力的新增功能。以下描述均基于最新代码核实（涉及 real_exec_demo/、real_exec_verification/、collaboration_orchestrator/、scenario_comparison/、server/digital-staff/、server/boss-scheduler/ 等目录的真实实现），与源代码一一对应，可作为软件可运行、可验证的直接证据。

18.1 数字员工真实执行演示平台

#### 功能背景

在既有版本中，数字员工的能力主要通过静态文档与运行界面截图加以说明，评审与验收方常提出"产出是否为真实执行结果、是否使用了模拟数据"的质疑。为提供可复现、可审计的"真实执行"证明，V1.0 新增了数字员工真实执行演示平台：它将真实 API 调用、执行质量评分、多场景四维对比与多智能体协同编排封装在一个可交互的演示流程中，从根本上回答"系统真的能跑、且跑的是真数据"这一问题，而非仅展示静态快照。

#### 技术实现（引用真实代码文件 / 类 / 函数）

• 真实执行编排器：real_exec_demo/orchestrator.py 中的 RealExecDemoOrchestrator 类定义了 STAGE_NAMES = {1:'真实执行能力展示', 2:'三场景四维对比', 3:'多智能体协同', 4:'MTClaw与规则引擎互补'}，其 run() 方法依次调用 _run_stage_1 至 _run_stage_4，每个阶段返回 StageResult(stage_index, stage_name, success, duration_ms, output, data)；阶段 1 调用 RealExecVerificationFramework.verify(staff_id, intent) 并输出 quality_score / is_mock_data / mtclaw_accelerated。
• 质量评分与 Mock 检测：real_exec_verification/quality_scorer.py 中的 QualityScorer.score() 先由 MockDataDetector.detect() 判定是否为模拟数据，若命中则质量分直接置 0；否则以"规则引擎分×0.6 + LLM 评估分×0.4"合成最终分，并在规则或 LLM 单边不可用时降级并标记 evaluation_degraded，底层调用 /api/rule-engine/validate-score。
• 多智能体协同编排：collaboration_orchestrator/orchestrator.py 的 CollaborationOrchestrator.execute_chain() 通过 build_collaboration_graph 构链，先用 CircularDependencyDetector.detect() 拒绝循环依赖，再依 config.targets 经 _trigger_downstream 向 /api/collaboration/execute-chain 派发下一棒员工。
• 场景四维对比：scenario_comparison/scenario_comparator.py 的 ScenarioComparator.compare() 遍历场景 A/B/D，统计 success_rate、avg_response_time_ms、quality_score_avg、cost_estimate、edge_execution_pct 并生成 FourDimensionReport。
• 统一入口与可视化：run_real_exec_demo.py 提供 --mode verify/compare/collab/demo 四种运行模式；demo_flow_orchestrator.py 的 DemoFlowOrchestrator 以 5 阶段脚本（STAGES 含开场钩子、价值证明、连续对话、数据报告、结语）呈现"MTClaw 更快更省更稳"的论证；public/demo/real-exec.html 则以 5 个阶段面板（ph-1~ph-5）、环境状态条、场景 A/B/D 卡片与实时日志流，将以上过程可视化。

#### 使用效果

该平台使数字员工的"真实执行"可被定量证明：质量评分对模拟数据零容忍（命中即 0 分），四场景对比以速度、成本、端侧执行比例等维度量化收益，多智能体协同链在含循环依赖检测的前提下验证自主接力能力，真实执行演示页面（real-exec.html）则以 5 阶段流程与实时日志直观呈现。整体上，它把软件著作权说明书从"截图描述"升级为"可运行证据"，显著增强了可验证性与可信度。

#### 图18-1 数字员工平台总览【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：数字员工平台总览
• 截图保存为 ../shots/sc6-4-platform.png 后告知我，自动替换为正式图注

图18-1 真实执行演示平台总览（任务编排 / 调度总览界面）。

图18-2 真实执行场景示例：ECR 评审自动执行（真实评审报告）。

图18-3 真实执行场景示例：供应商评审自动执行（真实评审报告）。

值得强调的是，该演示平台的评分与对比全部基于真实接口返回，而非预先录制的视频或写死的样本数据。质量评分模块对 Mock 数据的零容忍，使任何"伪执行"都会在质量分上被立即暴露（直接判 0 分），这在软件著作权审查与第三方测评中具有关键意义：审查人员可现场运行 python run_real_exec_demo.py --mode demo，亲眼看证数字员工从触发、执行、评分到多智能体协同的完整链路，从而获得可重复、可独立验证的实证结论。对于"平台是否真的能跑、跑的是不是真数据"这一核心关切，本平台给出了可量化、可审计的明确答案，显著提升了说明书作为著作权证据的可信度与说服力。

18.2 数字员工核心增强（staff-manager / conversation-engine / llm-brain / llm-router）

#### 功能背景

为使数字员工从"执行规则的机器人"进化为"能思考的业务专家"，V1.0 对核心层做了四项增强：更稳健的员工配置管理、支持多轮自然对话的对话引擎、可从规则引擎加载提示词的 LLM 大脑，以及实现端侧/云端分工的 LLM 路由器。它们共同支撑"对话即可触发真实业务执行"的体验。

#### 技术实现（引用真实代码文件 / 类 / 函数）

• 员工配置管理：server/digital-staff/staff-manager.js 的 StaffManager 通过 ensureTables() 幂等创建 digital_staff / staff_tasks / staff_execution_logs 三张表，并补齐协作扩展列（requester_id、approver_id、collaboration_chain、approval_status、notification_channel）；seedDefaultStaff() 采用 INSERT OR IGNORE 的按 id upsert 策略并回填 worker 字段；对外提供 createStaff / updateStaff / deleteStaff / setStaffEnabled / createTask / queryTasks / addLog / queryLogs 等完整 CRUD，以及从 sciot_import.db 加载规则/模板/提示词的 loadRulesAndPrompts()。
• 对话引擎：server/digital-staff/conversation-engine.js 的 ConversationEngine 维护 STAFF_SYSTEM_PROMPTS（按员工定制角色）与 ACTION_INTENTS，其 startConversation() 开启会话、sendMessage() 检测确认词、用 _augmentMessageWithHistory() 注入最近上下文后调用 llmBrain.think()，_parseActions() 解析回复中的 [ACTION:type] 标记，_executeAction() 通过 scheduler.runOnce() 真正触发执行；对 DS-CHIP-* 走 chipwise-handler，并在意图映射到其他员工时返回 redirect。
• LLM 大脑：server/digital-staff/llm-brain.js 的 LLMBrain 含 _detectMtclaw()（自动识别 127.0.0.1:18790 端点）、_initRuleEngine() 懒加载 UnifiedRuleEngine 并经 _loadPromptFromRuleEngine(scope, context) 按 identify/create/repair/optimize/compare/validate 加载提示词；think() 在 MTClaw 不可用时降级到云端；领域方法 reviewEcrIntelligently / analyzeVendorIntelligently / optimizeBomCostIntelligently / analyzeRootCause / analyzeSourcingIntelligently 均优先用规则引擎提示词，且在无 LLM 配置时如实抛错而非返回假数据；getGlobalInstance() 提供单例。
• LLM 路由：server/digital-staff/llm-router.js 的 LLMRouter 维护 workerConfig（端侧）与 solverConfig（云端），classifyTask() 依关键词集判定 simple/complex，call() 路由到 _callWorker（Ollama/MTClaw，约 70ms）或 _callSolver（云端大模型）；InferenceServiceDetector.detectAll() 自动探测 Ollama、摩尔线程、DeepSeek、昇腾 NPU、高通 NPU、三星 Exynos 等本地推理服务，getStats() 报告端侧占比与加速倍数，autoConfigure() 实现零配置初始化。

#### 使用效果

员工配置现已完全持久化并具备协作感知（发起人/审批人/协作链/审批状态）。用户可用自然语言与员工多轮对话，引擎识别意图、弹出确认并最终经调度器执行真实工作流。LLM 大脑在规则引擎提示词驱动下产出专家级 ECR/供应商/BOM/根因分析，且对缺失配置如实失败（杜绝伪造数据），并在 MTClaw 与云端间自动降级。LLM 路由器让 70%+ 的简单任务在端侧以约 70ms 完成、复杂推理走云端，与既有性能指标声明一致。

图18-4 可配置数字员工 / 对话与岗位画像界面（展示技能、数据源绑定与对话触发）。

#### 图18-5 市场报告生成【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：市场报告生成结果
• 截图保存为 ../shots/sc6-3-report-mkt.png 后告知我，自动替换为正式图注

图18-5 LLM 大脑驱动生成的营销/内容分析报告示例。

综合来看，这四项核心增强使数字员工从"配置即规则"跃升为"配置加智能"。staff-manager 保证了配置的可演进性与升级安全性（upsert 不覆盖用户改动），conversation-engine 把"对话"变成可执行动作的入口，llm-brain 把行业知识与规则引擎提示词注入每一次推理并以诚实失败替代伪造，llm-router 则在端侧与云端之间做最优分工。四者协同后，业务人员无需理解底层调度与模型细节，只需用自然语言描述意图，即可由对应的数字员工完成从识别、分析、优化到生成报告的全流程，真正体现了"数字员工即业务专家"的产品定位，也为后续接入更多领域员工预留了统一的智能底座。

18.3 轻量调度与员工路由（LiteScheduler / staff-router / staff-registry / feishu-router）

#### 功能背景

V1.0 进一步夯实调度与路由底座，确保无论来自网页、飞书还是 API，都能稳定地把请求路由到正确的数字员工，并保障调度具备弹性与可审计性。本章在第四章已有 LiteScheduler 描述基础上，补充员工注册表与跨渠道统一路由的新增强点。

#### 技术实现（引用真实代码文件 / 类 / 函数）

• 轻量调度器：server/boss-scheduler/lite-scheduler.js 的 LiteScheduler 提供被对话引擎与飞书路由复用的 runOnce(staffId, intent, opts)，内部经 _withStaffMutex（员工级互斥锁）、_dispatchWorkerPath（5 路径分派）与 ConfirmNeededError / resumeStaff（确认挂起恢复）执行；其调度的 YAML 配置支持 features.llm_router / mtclaw / ascend_npu 等开关。
• 员工注册表：server/boss-scheduler/staff-registry.js 的 StaffRegistry 以 loadProfile() 读取 YAML（含 GBK/BOM 容错），toRuntimeStaff() 将定义映射为运行时对象，syncStaffToDb() 以 upsert 同步到数据库并清理孤儿员工，loadStaffFromDb() 以数据库作为运行时真相源，支持禁用过滤与协作配置。
• 统一员工路由：server/boss-scheduler/staff-router.js 的 StaffRouter 是三端（AiWorkbench 前端、feishu-router 飞书、DigitalStaff 详情页）共用的单一路由源：其 STAFF_KEYWORDS 维护 20+ 员工的别名关键词库，CAPABILITY_PATTERNS 定义 18 种能力正则，_fuzzyMatch() 以字符重叠率 ≥0.7 做模糊匹配，matchStaffWithFallback() / extractParams() 负责匹配与参数提取，SPECIAL_COMMANDS 提供 status/help/recent 特殊指令，isCompletionAction / isSuccessAction 判定完成信号。
• 飞书路由层：server/boss-scheduler/feishu-router.js 的 route() 实现四层匹配——特殊命令 → 能力/对象查询 → 关键词 → 兜底 LLM；内置 CAPABILITY_PATTERNS、CAPABILITY_STAFF_MAP、ITEM_TYPE_ALIASES 与 ENGLISH_CAPABILITY_PATTERNS（演示模式英文指令）；经 staffRouter.matchStaffWithFallback() 找员工后调用 runWithTimeout()，支持 __RESUME__ 卡片回调、buildResumeText() 的 base64 编码，以及 Demo / Phosphorus 演示模式。

#### 使用效果

路由经由 StaffRouter 的唯一关键词与提示词源，三端行为完全一致、无漂移；StaffRegistry 让 YAML 模板与数据库实例安全同步并清理孤儿。飞书用户可用中英文自然语言指令、能力路由、对象查询、确认恢复卡片，以及演示/磷化工专用模式完成业务触发。底层 LiteScheduler 仍作为弹性引擎，经 runOnce 提供互斥锁、5 路径分派与确认恢复，使调度具备自愈与可审计能力。

#### 图18-6 经营报告生成【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：经营报告生成结果（biz）
• 截图保存为 ../shots/sc6-2-report-biz.png 后告知我，自动替换为正式图注

图18-6 调度与运行健康总览（健康巡检与自愈）。

#### 图18-7 经营报告生成【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：经营报告生成结果（biz）
• 截图保存为 ../shots/sc6-2-report-biz.png 后告知我，自动替换为正式图注

图18-7 路由生成的企业经营分析报告（biz）示例。

总体来看，轻量调度与员工路由的增强，使平台在"入口"与"引擎"两端都更加稳健一致。入口侧，StaffRouter 作为单一权威路由源，消除了多端各自维护匹配逻辑带来的行为漂移；StaffRegistry 让 YAML 模板与数据库实例保持安全同步，新增或下线员工都能即时反映。引擎侧，LiteScheduler 继续以互斥锁、5 路径分派与确认恢复保障执行的弹性与可控，而飞书路由层则把自然语言指令、能力识别、对象查询与确认卡片串联成流畅的企业微信协作体验。调度与路由的协同，最终让"任何渠道发起的请求，都能被路由到正确的员工并以真实执行闭环"成为平台稳定可依赖的基础能力，为规模化接入更多业务场景提供了坚实支撑。

附录 A：基于最新代码补充的新增功能（2026年7月）

A.1 AI 对话 × MTClaw 深度集成

server/digital-staff/smart-llm-router.js 的意图库由 18 种扩展至 36 种（新增老板助理、SCSAI 同步、库存预警、数据采集/识别/修复、PLM 大脑、自动闭环、比价、知识 RAG、工作流自动化、数据分析、健康顾问、视觉分析、写作助手、资讯摘要、零件识别等），并为每种意图配置中英文关键词与对应数字员工（如 DS-DATA-001 小智-老板助理、DS-PROC-DATA-001 小智-数据修复员、DS-RAG-001、DS-SCSAI-001、DS-PART-001 等）。

A.2 MTClaw 前置路由与会话透传

新增 MTClaw 前置路由（server/routes/scheduler-routes.js 的 _tryMTClawPreRoute）：L1 关键词预筛（库存/预警/采购/价格/BOM/SCSAI/PLM/估值/数据修复/工艺优化等 60+ 词）→ L2 精确动作映射（16 种 action，如 check_inventory、stock_alert、vendor_review、procurement_assistant、price_compare、data_valuation、data_repair 等）。当 MTClaw 未启用、L1 未命中、L2 无映射、健康检查失败或调用超时时，一律优雅降级回原始 scheduler.chat()。端侧 call() 新增 sessionKey 并经 _callMTCLAW 在请求头注入 x-openclaw-session-key，实现端侧会话一致性；据提交说明，命中 MTClaw 路径响应延迟由约 60s 降至约 200ms。

说明：上述 MTClaw 前置路由与 sessionKey 透传已在运行时接入 handleAgentChat，为数字员工提供低延迟、可降级的企业业务直达能力。

A.3 MTClaw 真实集成：端侧/混合/云端三场景执行与 L1 关键词路由

在 A.1/A.2 的 AI 对话集成基础上，数字员工执行链路新增 MTClaw 真实集成：server/mtclaw-integration.js 的 ExecutionStrategy 定义三场景——scenarioA（纯端侧）、scenarioB（混合：Worker 端侧确定性计算 + Solver 云端推理）、scenarioC（纯云端），由 smartRoute/analyzeTaskType 按任务类型自动选场景；server.js 数字员工执行路径在 mtclawEnabled 且场景 A/B 时内联调用 MTClaw 端侧（model: function-router）。L1 关键词路由基于 server/config/staff-keywords.js 的 ALL_STAFF_KEYWORDS（46 个数字员工关键词映射，含 8 个已验证、38 个待接入），命中即 <5ms 路由到 mtclawRouteInfo，不依赖 MTClaw 服务时始终可用；L2 模型路由再调 mtclaw-light。

诚实说明：MTClaw 端侧执行默认关闭（mtclaw.enabled=false，且依赖仓库外 MTClaw function-router 服务 127.0.0.1:18790）；46 个员工关键词中仅 8 个经验证、其余经 MTClaw 模型路由；public/demo/*.html` 三场景对比演示页为独立演示/测试页面（依赖外部 MTClaw，非产品内嵌 UI）。上述能力已在代码层实现并部分接线，端侧执行与全量员工验证需在部署环境启用 MTClaw 服务后生效。

著作权人信息

以下著作权人信息与中国版权保护中心登记申请表一致，供审查核对。

• 著作权人： 北京左帮右臂人工智能技术有限公司
• 著作权人类型： 法人（有限责任公司·自然人独资）
• 证件类型： 营业执照
• 统一社会信用代码： 91110114MAKJ1UC63J
• 注册地址： 北京市昌平区东小口镇天通中苑二区21号楼1层103-2819（集群注册）
• 联系人： 方云超
• 联系电话： 18601921816
• 电子邮箱： tuan_zhang@sina.com
• 邮政编码： 100010