BossAgents 工业智能体与数字员工标准定义

姊妹文档：数字员工三层分类体系 — 三层（基础能力/通用员工/行业适配）的具体分类与协同Pipeline；本文侧重术语/成熟度/判定标准。

版本：2026-08-27 | 依据：代码实际逻辑 + 公共标准对齐

状态：与代码同步，所有数字员工/智能体的新增、修改、删除必须符合本标准

一、术语定义与公共标准对齐

1.1 智能体（AI Agent）

公共标准：

| 来源 | 定义 |

|---|---|

| IBM | A system that autonomously performs tasks by designing workflows with available tools |

| LangChain | LLM + Tools + Memory + Planning，通过 ReAct（Reasoning + Acting）循环完成任务 |

| AutoGen | 多智能体对话框架，通过对话协商完成任务 |

| Anthropic | Tool use + Computer use，LLM 作为推理引擎调用外部工具 |

我们的定义：

智能体是能自主感知环境、规划步骤、调用工具、执行行动并返回结果的系统。以目标为输入，自主完成从感知到行动的全链路。

对齐情况：

• ✅ 自主规划（LLM 任务分解 decomposeTask）
• ✅ 工具调用（7 个能力原语 + SCSAI AML）
• ✅ 记忆（全局黑板 global-blackboard.js + SQLite 持久化）
• ✅ ReAct 循环（LiteScheduler 调度 + worker 执行 + 结果反馈）
• ✅ 多智能体协同（MACP 协议 + A2A 消息）

1.2 数字员工（Digital Worker）

公共标准：

| 来源 | 定义 |

|---|---|

| IBM | Software-based labor that independently runs meaningful parts of complex, end-to-end processes by applying a range of skills |

| Forrester | Digital worker automation: 软件实体替代人类执行结构化业务流程 |

我们的定义：

数字员工是替代现实中某个人类岗位（或岗位的部分职责）的软件实体。有明确岗位职责，能独立接受业务任务、自主执行、返回真实业务结果，与人类员工协作且人类保持控制权。

对齐情况：

• ✅ 独立执行端到端流程（worker + capability runtime）
• ✅ 多技能（7 个能力原语组合）
• ✅ 理解人类意图（keywords 匹配 + LLM 意图识别）
• ✅ 代人行动（调 SCSAI API 操作真实业务数据）
• ✅ 人类控制权（确认/恢复机制 pendingConfirms）

1.3 能力原语（Capability Primitives）

二、工业智能体独有特性（与通用AI Agent的本质区别）

2.1 PLM 对象模型驱动

这是我们和其他外部实现独一无二的地方。

通用 AI Agent（LangChain/AutoGen/CrewAI）以文本对话为核心，工具是扁平的函数调用。

我们的工业智能体以 PLM 对象模型 为核心：

数字员工 = PLM 中的一个实例化对象
  ├── ItemType: "Digital Staff"（在 SCSAI 中定义）
  ├── 属性: key_name, name, capabilities, schedule, worker...
  ├── 生命周期: Preliminary → Released
  └── 关系: 与 Part/ECR/Document/BOM 等建立 PLM 关系

优势：

• 数字员工本身是 PLM 对象，可被查询、版本管理、生命周期管理
• 数字员工的配置变更走 PLM 变更流程（ECR），有审计追溯
• 数字员工和业务对象的关联关系是 PLM 原生关系，不是外部硬编码

2.2 基于关系的协同

通用多智能体协同（AutoGen/CrewAI）通过对话消息协商。

我们的工业智能体通过 PLM 关系 协同：

场景：ECR 变更影响分析

DS-ECR-001（ECR审核员）
  ↓ 查询 ECR 关联的 Part（PLM 关系: ECR → Part）
  ↓ 查询 Part 的 Where-Used（PLM 关系: BOM → Part）
  ↓ 发现 3 个 BOM 受影响
  ↓ 委托 DS-PROC-001（采购助手）评估供应商影响
  ↓ 委托 DS-COST-001（成本优化师）评估成本影响
  → 汇总返回变更影响报告

协同路径：ECR →(PLM关系)→ Part →(PLM关系)→ BOM →(A2A消息)→ 采购助手 + 成本优化师

不是简单的"Agent A 发消息给 Agent B"，而是基于业务对象的真实关系链驱动的协同。

2.3 MTCLAW 端侧加速 + 自有调度引擎降级

┌─────────────────────────────────────────────┐
│  MTCLAW 可用（端侧 NPU 加速）                │
│  ├── Worker（小模型）: 高频简单任务 ~70ms    │
│  ├── Solver（大模型）: 复杂推理任务 ~500ms   │
│  └── 70%+ 任务走 Worker，整体加速 ~7x        │
├─────────────────────────────────────────────┤
│  MTCLAW 不可用 → 降级自有调度引擎            │
│  ├── SmartLLMRouter: 意图分类 + 模型路由     │
│  ├── LiteScheduler: Cron + 队列 + 互斥       │
│  └── 远程 LLM (DeepSeek/商汤): 云端推理      │
└─────────────────────────────────────────────┘

不是依赖单一 LLM 提供商，而是端侧加速 + 云端降级的双层架构。

2.4 服务端复杂业务处理

与业务对象相关的复杂逻辑在服务端处理，不在 LLM 端：

| 层次 | 职责 | 实现 |

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

| LLM 端 | 意图理解、参数提取、结果格式化 | SmartLLMRouter + LLMBrain |

| 服务端 | 业务规则、数据查询、状态流转 | 规则引擎 + SCSAI AML + SQLite |

| PLM 端 | 数据权威源、关系管理、生命周期 | SCSAI PLM |

示例：BOM 成本分析

• LLM 端：理解"分析 P-1001 的 BOM 成本" → 提取 item_id=P-1001
• 服务端：查 SCSAI 获取 BOM 结构 → 递归计算成本 → 查供应商价格
• PLM 端：BOM 关系、Part 属性、Vendor 价格都是 PLM 原生数据

2.5 工业智能体打法（vs 通用 AI 助手）

三、架构设计

3.1 三层存储模型

┌─────────────────────────────────────────────────────┐
│  PLM (SCSAI)        ← 权威源（正确性）               │
│  数字员工是 PLM 中的实例化对象                        │
│  可与其他对象（Part/ECR/Document）建立关联关系        │
│  基于关系进行协同                                    │
├─────────────────────────────────────────────────────┤
│  YAML (local.yaml)  ← 本地缓存（效率）               │
│  启动时直接加载到内存，不验证、不同步、不崩溃          │
│  相当于 PLM 数据的本地快照                           │
├─────────────────────────────────────────────────────┤
│  SQLite             ← 运行时状态                     │
│  存任务、日志、执行记录                              │
│  不存员工定义，不参与启动加载                          │
└─────────────────────────────────────────────────────┘

3.2 启动流程

server.js 启动
  → boss-scheduler/index.js _loadProfile()
    → loadProfile('local')           // 读 YAML 文件
    → profile.staff.map(toRuntimeStaff)  // 转为内存对象
    → new LiteScheduler({ staffList })   // 传入调度器
  → digital-staff/index.js 初始化
    → loadProfile('local')           // 也从 YAML 加载
    → DIGITAL_STAFF = yamlStaff      // 不从 SQLite 覆盖

关键原则：

• 启动时只从 YAML 加载，不调用 syncStaffToDb，不调用 loadRegistry，不验证
• 启动不会因为数据库残留、不一致等问题崩溃
• SQLite 的 digital_staff 表和 agent_registry 表不参与启动加载

3.3 新建/修改/删除流程

API 请求 (POST/PUT/DELETE /api/digital-staff)
  → staff-persistence.js
    ① PLM 写入 (SCSAI createItem/updateItem/deleteItem)
       — 失败不阻断（PLM 可能没有 ItemType，降级跳过）
    ② YAML 同步 (文本追加/修改/删除 local.yaml)
       — 保证本地缓存与最新操作一致
  → staff-manager.js
    ③ SQLite 写入 (createStaff/updateStaff/deleteStaff)
       — 运行时状态持久化
  → reloadStaffConfig()
    — 通知调度器刷新内存

写入顺序：PLM → YAML → SQLite

关键文件：

| 文件 | 职责 |

|---|---|

| server/staff-persistence.js | 统一持久化入口，协调 PLM + YAML 写入 |

| server/routes/digital-staff-routes.js | API 路由，调用 staff-persistence + staff-manager |

| server/digital-staff/staff-manager.js | SQLite CRUD（运行时状态） |

| server/boss-scheduler/staff-registry.js | YAML 加载（loadProfile/toRuntimeStaff） |

四、数字员工成熟度模型

4.1 成熟度等级

| 等级 | 名称 | 定义 | 替代程度 | 当前员工 |

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

| L1 | 辅助 | 辅助人类完成部分操作，人类决策 | 0-20% | 0 个 |

| L2 | 部分 | 独立完成部分端到端流程，人类审核 | 20-50% | 27 个（DS-PROC-001, DS-STOCK-001, DS-IQC-001 等） |

| L3 | 深度 | 独立完成完整流程，异常时人类介入 | 50-80% | 41 个（DS-SCSAI-001, DS-QUALITY-001, DS-BOM-001 等） |

| L4 | 全自动 | 完全替代人类，人类仅监督 | 80-100% | 2 个（DS-LOOP-001 闭环引擎, DS-SYS-001 目标校验） |

现阶段定位：L2-L3 为主（68/70=97%），个别 L4（2/70=3%）。不可能完全替代人类。

成熟度分布（2026-08-27 实测）：

L2 规则驱动 ████████████████████████████ 27 (39%)
L3 LLM增强  █████████████████████████████████████████ 41 (59%)
L4 自主闭环 ██ 2 (3%)

4.2 成熟度评估标准

| 维度 | L1 | L2 | L3 | L4 |

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

| 自主决策 | 无 | 简单决策 | 复杂决策 | 全部决策 |

| 异常处理 | 通知人类 | 建议方案 | 自动处理+通知 | 自动处理 |

| 数据操作 | 只读 | 读写(需确认) | 读写(自动) | 读写+创建 |

| 协同能力 | 无 | 单向委托 | 多方协同 | 全自动协同 |

| LLM 依赖 | 高 | 中 | 低(规则为主) | 极低 |

五、功能清单（路线图四步）

5.1 路线图第一步：健壮性基础设施

5.2 路线图第二步：事件驱动 + 统一锁 + LLM 分解

5.3 路线图第三步：MACP 协同 + 全局黑板 + 超时告警

5.4 路线图第四步：Goal 可视化

5.5 运行时验证结果（2026-08-27）

5.6 Worker 别名映射修复（2026-08-27）

YAML 中 worker 名称用 xxx-worker 后缀（如 quality-agent-worker），但 lite-scheduler.js 的 WORKERS 映射表用 xxx（如 quality-agent），导致 25 个 worker 找不到。

修复：在 lite-scheduler.js:114-138 添加 25 个别名条目，使 YAML worker 名称与 WORKERS 映射完全对齐。

5.7 默认参数修复（2026-08-27）

4 个员工无参数运行时失败，根因是缺少默认输入值。修复后 70/70 全部成功。

| 员工 | 问题 | 修复 | 修复后产出 |

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

| DS-COST-001 | 卡在人在回路确认环节 | 添加 autoConfirm: true，worker 检查该参数跳过确认 | 500 零件 / 35 装配体 / 8 个 BOM 分析完成 |

| DS-CHIP-001 | 缺设计规格输入（≥10字符） | 添加默认 RISC-V RV32I 规格描述 | 识别出 RV32I / 5 级流水线 / 32 寄存器 |

| DS-CS-001 | 缺用户消息输入 | 添加默认欢迎咨询消息 | 返回产品介绍 + 方案推荐 |

| DS-PROC-DATA-001 | process_specs 表空导致 success=false | 改为 success: !reportWriteError，有 SCCAPP 数据即为成功 | 26163 工艺文件 / 163441 工序 / 报告已生成 |

六、判定标准

6.1 数字员工必要条件

1. 有明确岗位职责——对应现实中某个岗位的具体职责
2. 能独立接受任务并执行——给一个业务意图就能自主跑完端到端流程
3. 有真实业务产出——操作真实数据，返回真实结果
4. 有独立实现逻辑——有独立的 worker 代码文件
5. 能替代或减少人类工作——如果去掉这个数字员工，需要一个人来做这件事
6. 有默认参数——能按预设参数运行，不需要用户逐个指定
7. 有意图关键词——用户自然语言能匹配到这个员工

6.2 分类标准

七、PLM 集成

7.1 数字员工作为 PLM 对象

每个数字员工是 PLM (SCSAI) 中的一个实例化对象：

• ItemType: Digital Staff（需在 SCSAI 中预创建）
• 属性: key_name, name, description, classification, enabled, worker, capabilities, schedule, item_types
• 关联: 可与 Part/ECR/Document 等建立关系，基于关系进行协同

7.2 PLM 写入降级策略

PLM 写入失败时不阻断操作：

• SCSAI 不可用 → 跳过 PLM 写入，继续写 YAML + SQLite
• ItemType 不存在 → 跳过 PLM 写入，记录警告
• 网络超时 → 跳过 PLM 写入，继续写 YAML + SQLite

前提：YAML 和 SQLite 是本地操作，总能成功。PLM 是远程操作，可能失败。

7.3 PLM ItemType 预创建

在 SCSAI 中创建 Digital Staff ItemType（PLM 管理员操作）：

• 名称: Digital Staff
• 分类: Digital Worker
• 属性: key_name, name, description, enabled, worker, capabilities, schedule, item_types
• 生命周期: Preliminary → Released

八、当前系统盘点

8.1 员工总数

总计：70 个（从 YAML 加载）

8.2 配置统计

九、参考来源与标准对齐

9.1 公共标准

9.2 我们的创新（公共标准没有的）