BossAgents Industrial Intelligent Agents and Digital Employees Standard Definition

Companion Document: Digital Employee Three-Tier Classification System — Specific classifications and collaborative pipeline for the three tiers (basic capabilities/general employees/industry adaptation); this document focuses on terminology/maturity/assessment criteria.

Version: 2026-08-27 | Basis: Actual code logic + alignment with public standards

Status: Synchronized with code. All additions, modifications, and deletions of digital employees/intelligent agents must comply with this standard.

1. Terminology Definition and Alignment with Public Standards

1.1 Intelligent Agent (AI Agent)

Public Standards:

| Source | Definition |

|---|---|

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

| LangChain | LLM + Tools + Memory + Planning, completing tasks through the ReAct (Reasoning + Acting) cycle |

| AutoGen | A multi-agent conversation framework that completes tasks through conversational negotiation |

| Anthropic | Tool use + Computer use, where the LLM serves as a reasoning engine to invoke external tools |

Our Definition:

An intelligent agent is a system capable of autonomously perceiving the environment, planning steps, invoking tools, executing actions, and returning results. It takes a goal as input and autonomously completes the entire chain from perception to action.

Alignment Status:

• ✅ Autonomous Planning (LLM task decomposition via decomposeTask)
• ✅ Tool Invocation (7 capability primitives + SCSAI AML)
• ✅ Memory (Global blackboard via global-blackboard.js + SQLite persistence)
• ✅ ReAct Loop (LiteScheduler orchestration + worker execution + result feedback)
• ✅ Multi-Agent Collaboration (MACP protocol + A2A messaging)

1.2 Digital Worker

Common Standards:

| Source | Definition |

|---|---|

| 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: software entities that replace humans in executing structured business processes |

Our Definition:

A digital worker is a software entity that replaces a real human position (or part of its responsibilities). It has clear job duties, can independently accept business tasks, autonomously execute them, return actual business results, collaborate with human employees while humans retain control.

Alignment Status:

• ✅ Independently executes end-to-end processes (worker + capability runtime)
• ✅ Multi-skill (combinations of 7 capability primitives)
• ✅ Understands human intent (keyword matching + LLM intent recognition)
• ✅ Acts on behalf of humans (calls SCSAI API to operate real business data)
• ✅ Human control (confirmation/recovery mechanism pendingConfirms)

1.3 Capability Primitives

II. Unique Characteristics of Industrial Agents (The Essential Difference from General AI Agents)

2.1 PLM Object Model Driven

This is what makes our approach unique compared to other external implementations.

General AI Agents (LangChain/AutoGen/CrewAI) are centered around text dialogue, with tools being flat function calls.

Our Industrial Agents are centered around the PLM object model:

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

优势：

• The digital employee itself is a PLM object, which can be queried, version-managed, and lifecycle-managed.
• Configuration changes to digital employees follow the PLM change process (ECR), with audit trails.
• The association between digital employees and business objects is a native PLM relationship, not externally hard-coded.

2.2 Relationship-Based Collaboration

General multi-agent collaboration (AutoGen/CrewAI) negotiates via dialogue messages.

Our Industrial Agents collaborate through PLM relationships:

场景：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消息)→ 采购助手 + 成本优化师

It's not simply "Agent A sends a message to Agent B", but collaboration driven by the real relationship chain of business objects.

2.3 MTCLAW Edge Acceleration + Proprietary Scheduling Engine Degradation

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

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

2.4 Server-Side Complex Business Processing

Complex logic related to business objects is handled on the server side, not on the LLM side:

| Layer | Responsibility | Implementation |

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

| LLM Side | Intent understanding, parameter extraction, result formatting | SmartLLMRouter + LLMBrain |

| Server Side | Business rules, data queries, state transitions | Rule Engine + SCSAI AML + SQLite |

| PLM Side | Authoritative data source, relationship management, lifecycle | SCSAI PLM |

Example: BOM Cost Analysis

• LLM Side: Understands "Analyze BOM cost for P-1001" → Extracts item_id=P-1001
• Server Side: Queries SCSAI for BOM structure → Recursively calculates cost → Queries supplier prices
• PLM Side: BOM relationships, Part attributes, Vendor prices are all native PLM data

2.5 Industrial Agent Approach (vs. General AI Assistant)

III. Architecture Design

3.1 Three-Tier Storage Model

┌─────────────────────────────────────────────────────┐
│  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 覆盖

关键原则：

• Load only from YAML on startup; do not call syncStaffToDb, do not call loadRegistry, no validation
• Startup will not crash due to database residue, inconsistency, or similar issues
• SQLite's digital_staff and agent_registry tables are not involved in startup loading

3.3 Create/Modify/Delete Process

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

Key Files:

| File | Responsibility |

|---|---|

| server/staff-persistence.js | Unified persistence entry, coordinates PLM + YAML writes |

| server/routes/digital-staff-routes.js | API routes, calls staff-persistence + staff-manager |

| server/digital-staff/staff-manager.js | SQLite CRUD (runtime state) |

| server/boss-scheduler/staff-registry.js | YAML Loading (loadProfile/toRuntimeStaff) |

IV. Digital Employee Maturity Model

4.1 Maturity Levels

| Level | Name | Definition | Replacement Degree | Current Employees |

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

| L1 | Assistant | Assists humans with partial operations, human makes decisions | 0-20% | 0 |

| L2 | Partial | Independently completes partial end-to-end processes, human reviews | 20-50% | 27 (DS-PROC-001, DS-STOCK-001, DS-IQC-001, etc.) |

| L3 | Deep | Independently completes full processes, human intervenes on exceptions | 50-80% | 41 (DS-SCSAI-001, DS-QUALITY-001, DS-BOM-001, etc.) |

| L4 | Fully Automated | Fully replaces humans, humans only supervise | 80-100% | 2 (DS-LOOP-001 closed-loop engine, DS-SYS-001 target verification) |

Current positioning: Primarily L2-L3 (68/70=97%), with a few L4 (2/70=3%). Cannot fully replace humans.

Maturity distribution (2026-08-27 actual measurement):

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

4.2 成熟度评估标准

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

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

| Autonomous Decision-Making | None | Simple Decisions | Complex Decisions | Full Decisions |

| Exception Handling | Notify Human | Suggest Solutions | Auto-Handle + Notify | Auto-Handle |

| Data Operations | Read-Only | Read-Write (Requires Confirmation) | Read-Write (Automatic) | Read-Write + Create |

| Collaboration Capability | None | Unidirectional Delegation | Multi-Party Collaboration | Fully Automated Collaboration |

| LLM Dependency | High | Medium | Low (Rule-Based) | Very Low |

5. Functional List (Roadmap Four Steps)

5.1 Roadmap Step One: Robust Infrastructure

5.2 Roadmap Step Two: Event-Driven + Unified Lock + LLM Decomposition

5.3 Roadmap Step 3: MACP Collaboration + Global Blackboard + Timeout Alert

5.4 Roadmap Step 4: Goal Visualization

5.5 Runtime Verification Results (2026-08-27)

5.6 Worker alias mapping fix (2026-08-27)

Worker names in YAML use the xxx-worker suffix (e.g., quality-agent-worker), but the WORKERS mapping table in lite-scheduler.js uses xxx (e.g., quality-agent), causing 25 workers to be missing.

Fix: Added 25 alias entries in lite-scheduler.js:114-138 to fully align YAML worker names with the WORKERS mapping.

5.7 Default parameter fix (2026-08-27)

4 employees failed during no-parameter execution due to missing default input values. After the fix, all 70/70 succeeded.

| Employee | Issue | Fix | Post-Fix Output |

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

| DS-COST-001 | Stuck at human-in-the-loop confirmation step | Added autoConfirm: true; worker checks this parameter to skip confirmation | 500 parts / 35 assemblies / 8 BOM analyses completed |

| DS-CHIP-001 | Missing design specification input (≥10 characters) | Added default RISC-V RV32I specification description | Identified RV32I / 5-stage pipeline / 32 registers |

| DS-CS-001 | Missing user message input | Added default welcome inquiry message | Returns product introduction + solution recommendation |

| DS-PROC-DATA-001 | Empty process_specs table causing success=false | Changed to success: !reportWriteError; success if SCCAPP data exists | 26,163 process files / 163,441 process steps / report generated |

VI. Evaluation Criteria

6.1 Prerequisites for Digital Employees

1. Has clear job responsibilities—corresponding to the specific duties of a real-world position
2. Can independently accept tasks and execute—given a business intent, can autonomously run the end-to-end process
3. Delivers real business outcomes — operates on real data and returns real results
4. Has independent implementation logic — has a dedicated worker code file
5. Can replace or reduce human work — if this digital staff is removed, a person would be needed to perform this task
6. Has default parameters — can run with preset parameters without requiring users to specify each one
7. Has intent keywords — can be matched by user natural language

6.2 Classification Criteria

7. PLM Integration

7.1 Digital Staff as PLM Objects

Each digital staff is an instantiated object in PLM (SCSAI):

• ItemType: Digital Staff (must be pre-created in SCSAI)
• Attributes: key_name, name, description, classification, enabled, worker, capabilities, schedule, item_types
• Association: Can establish relationships with Part/ECR/Document, enabling collaboration based on these relationships.

7.2 PLM Write Degradation Strategy

PLM write failures do not block operations:

• SCSAI unavailable → Skip PLM write, proceed with YAML + SQLite
• ItemType does not exist → Skip PLM write, log a warning
• Network timeout → Skip PLM write, proceed with YAML + SQLite

Prerequisite: YAML and SQLite are local operations and always succeed. PLM is a remote operation and may fail.

7.3 PLM ItemType Pre-creation

Create the Digital Staff ItemType in SCSAI (PLM administrator operation):

• Name: Digital Staff
• Category: Digital Worker
• Attributes: key_name, name, description, enabled, worker, capabilities, schedule, item_types
• Lifecycle: Preliminary → Released

Eight. Current System Inventory

8.1 Total Number of Employees

Total: 70 (loaded from YAML)

8.2 Configuration Statistics

Nine. Reference Sources and Standards Alignment

9.1 Public Standards

9.2 Our Innovations (Not in Public Standards)