BossAgents BossAgents

工业智能体 · 数字员工 标准体系（v2.0 合并版）

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

工业智能体 · 数字员工 标准体系（v2.0 合并版）

本文档是 BossAgents 平台关于「行业 / 岗位 / 数字员工 / 智能体」以及其治理底座（对象模型、规则引擎、关系引擎、多智能体协同、5端协同）的唯一定义与标准依据。

所有新增、修改、评审相关代码、配置、文档，均以本文档为准。

配套落地架构见 docs/06_DIGITAL_STAFF_UNIFICATION.md（定义源收口方案）。

0. 标准总纲与两个视角的立交桥

平台存在两个互补的视角，在"数字员工"这一层交汇：

  • 业务侧四层（谁为谁做什么）：行业 → 岗位 → 数字员工 → 智能体。

定义"为谁服务、做什么、谁在做、怎么做"，是组织与业务的映射。

  • 技术/治理侧五层（怎么做才可靠）：智能体基础 → 对象模型 → 规则/关系引擎 → 数字员工 → 多智能体协同，由"5端协同"贯穿。

定义"智能体能力怎么构成、行为怎么约束、协同怎么进行"，是工程与治理的底座。

一句话：业务侧四层描述"数字员工是什么"，技术/治理侧五层描述"数字员工怎么可靠地工作"。数字员工是两者的交汇封装层。

一、业务侧四层概念定义（行业 / 岗位 / 数字员工 / 智能体）

详细定义见 v1.0 已核定内容，此处给出与治理侧对齐的精简版 + 代码落点。

第一层：行业（Industry）

从事相同性质经济活动的单位集合（GB/T 4754 同质性原则）。定位：最顶层业务域，定义"为谁服务"。

  • 代码落点：知识库 industry 代码（如 phos_chem 磷化工、baijiu 白酒）；local.yaml 的 event_subscriptions 段已挂 industry: phos_chem。待补：positions 段未显式标 industry 归属。

第二层：岗位（Position / Role）

组织为完成任务确立的职责单元（因事设岗、职责明确、组织属性、相对稳定）。定位：行业到工作的桥梁，定义"做什么"。

  • 代码落点：local.yaml 的 positions: 段（16 个岗位，含 members: 映射到数字员工 ID），后端 /api/digital-staff/positions（server.js:4895）、前端 DigitalStaff.vue「岗位体系」tab 渲染。

第三层：数字员工（Digital Employee）

具备"感知—规划—行动—学习"闭环能力的虚拟劳动力，是"数智化技术 + 流程封装 + 组织角色"的组合。定位：岗位的数字化承载者，定义"谁在做"。

  • 代码落点：local.yaml 的 staff: 段（唯一可编辑定义源，当前 77 个）→ syncStaffToDb 镜像到 server/data/rule_engine.db 的 digital_staff 表（运行时镜像，不可手改）。tier: base/domain/sub 区分基础动词 / 领域 / 子能力。
  • 认定标准（治理侧第四层细化）：必须有岗位身份、岗位映射、权限边界、结果交付、可治理性、持续进化（详见 §四-1）。

第四层：智能体（AI Agent）

具备自主感知、记忆、决策、交互与执行能力的最小能力单元（GB/Z 185—2026）。定位：驱动数字员工的技术内核，定义"怎么做"。

  • 代码落点：server/boss-scheduler/workers/*.js（每个文件导出一个 run(staff, ctx, intent, parameters)，即一个可独立调用的智能体能力单元）。
  • 一对多实证：chip-worker.js 被 DS-CHIP-001~007 共用（type: capability_mode）；goai-agent-worker.js 被 GOAI-SCHED/PROC/EQUIP 共用（type: role_prompt）；procurement-chain-worker.js 被 DS-*CHAIN-001 共用（type: workflow_step）。

二、技术/治理侧五层标准体系

核心原则（全部继承国标框架）：

  1. 对象模型驱动：PLM 为单一事实来源，无对象模型则规则/关系/协同无共同语言。
  2. 分层解耦：各层独立定义、标准、接口，层间标准化协议通信，可独立演进。
  3. 标准先行：不按标准开发不予上架，不符合标准不予部署。
  4. 可组合可扩展：智能体为最小单元，支持一对多 / 多对一 / 多对多组合。
  5. 安全可信可控：决策可解释、可审计、可回退；任何智能体必须支持人类接管与紧急停止。

第一层：智能体基础标准（八大功能模块 + 分类分级）

依据 GB/Z 195-2026《人工智能 工业智能体参考架构》+《工业智能体 第1部分：通用要求》，每个工业智能体必须具备：

| 功能模块 | 标准要求 | 本项目代码落点（现状/缺口） |

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

| 感知 | 多模态输入、环境感知 | workers 经 ctx.db 只读 SELECT + parameters 输入感知；多模态（图像/语音）缺口 |

| 记忆 | 短期/长期记忆 | ctx.staffLog + rule_engine.db 审计；长期记忆（知识图谱）缺口 |

| 推理 | 符号+统计推理 | 四动词 worker 字段级/空值推理；LLM 概率推理经 llm:true 员工 |

| 规划 | 任务分解与路径规划 | pipeline: 字段（DS-BIZ-001 / DS-PLM-BRAIN-001）+ loop: 迭代；链式 collaboration.onComplete |

| 决策 | 自主决策、可解释 | requestConfirmation 高风险升级人工；决策解释待补 |

| 执行 | 调用工具/API | mtclaw_high_frequency_actions + worker 内 DB/服务调用 |

| 通信 | 遵循 GB/Z 185 互联 | 缺口：staff-router.js 未消费 type 字段，agent 间通信协议未标准化 |

| 演化 | 从反馈学习优化 | 骨架员工 implemented:'skeleton' 诚实化 + 后续填装；自动演化缺口 |

分类分级（依据《工业智能体分类分级评估指南》）：基础级 L1 / 辅助级 L2 / 自主级 L3 / 自治级 L4。

身份码：每个智能体必须有唯一身份码 → 本项目即 DS-XXX 员工 ID + worker 文件名，已满足；建议补充 worker 级独立身份码。

标准文件清单：GB/Z 195-2026、工业智能体通用要求、GB/Z 185.1～185.7—2026、IEEE P3945。

第二层：对象模型标准（PLM 统一语义底座）

对象模型是所有上层能力的基础——无对象模型则规则无操作对象、关系无节点、协同无共同语言。

核心对象类型（参考 AAS 元模型）：

  • 物理资产：设备、产线、产品、物料
  • 逻辑资产：BOM、图纸、工艺、文档
  • 流程对象：工作流、审批流、生产节拍
  • 角色对象：岗位、权限、职责
  • 数据对象：参数、指标、日志、事件

对象模型五类视图：几何 / 物理 / 行为（状态机/时序）/ 规则 / 数据。

生命周期：建模 → 构建（机器可读）→ 测试（完整性/一致性）→ 部署（注册到模型库+唯一标识）→ 演化（版本管理）。

  • 本项目代码落点（强相关，非空中楼阁）：
  • server/utils/SCSAI-tools.js：SCSAI PLM 469 工业对象模型底座（设备/产品/BOM/工艺/项目等），是本层"对象模型库"的真实载体。
  • server/data/kb/.db：行业知识库（kb_docs / industry_bom 等），对象实例存储。
  • server/data/sccapp_process_data.db：工艺对象（pps_* 7 核心表）。
  • local.yaml 的 item_types: 字段（如 DS-ECR-001 的 ECR、DS-QCC-001 的 CASC211_JG_Q_CONTROL_CARD）即"角色/逻辑对象"在员工上的映射标注。

标准文件清单：IDTA-01001 AAS Metamodel、GB/T 45616.2-2025 数字孪生参考架构、GB/T 45626-2025 装备数字孪生系统通用要求。

第三层：规则引擎与关系引擎标准（决策底座）

规则引擎定义"什么能做、什么不能做"（约束与边界），关系引擎定义"谁和谁什么关系"（上下文与语义）。两者共同构成智能体的决策底座。

规则引擎标准：统一规则描述语言（IF-THEN / 决策表 / 决策树）、优先级与冲突解决、生命周期管理、确定性保障、可审计、人类优先（可被覆盖）。

  • 本项目代码落点：server/data/rule_engine.db 的 sciot_rules_v2 / sciot_templates / prompt_templates 表（规则真实存储）；server/boss-scheduler/lib/consistency-check.js 做规则/模板一致性巡检；server/services/document-rule-template-manager.js 管理规则模板。

关系引擎标准：关系元模型（实体-关系-实体三元组）、关系类型（继承/组合/依赖/约束/通信/协同）、关系推理、可视化、运行时动态绑定。

  • 本项目代码落点：server/boss-scheduler/lib/consistency-check.js（一致性/关系校验）、local.yaml 的 positions.members + collaboration.onComplete + event_subscriptions（关系网络的声明）、tasks/task-force-store.js（L3/L4 协同起落库）。

规则+关系协同：规则提供确定性保障，关系提供上下文感知，确保工业环境安全合理决策。

第四层：数字员工标准（岗位角色封装与业务交付）

1. 数字员工认定标准（满足才称为数字员工）：

| 标准项 | 要求 | 本项目落点 |

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

| 岗位身份 | 岗位名/编码/职责 | title / description 字段 |

| 岗位映射 | 与行业-岗位体系对应 | positions.members 引用 |

| 权限边界 | 操作/数据权限 | mtclaw_high_frequency_actions + item_types |

| 结果交付 | 可量化 KPI | 缺口：尚未定义 KPI 字段 |

| 可治理性 | 日志/审计/考核 | ctx.staffLog + rule_engine.db 审计 |

| 持续进化 | 数据反馈优化 | 骨架诚实化 + 后续填装 |

2. 数字员工能力等级：L1 基础自动化 / L2 协同辅助 / L3 有条件自主 / L4 特定领域高度自主 / L5 全场景完全自主。

3. 数字员工↔岗位映射标准：一个员工可承担多岗位、一个岗位可对应多员工，映射必须在 PLM 对象模型记录（即 positions.members）。

标准文件清单：工业智能体分类分级评估指南、T/SAIAS 055-2026 智能体能力分级与评测要求。

第五层：多智能体协同标准（跨智能体通信与协作）

1. 通信协议：GB/Z 185.6 智能体交互、IEEE P3945.1 互操作、A2A 协议、MACP 制造业多智能体协议。

2. 群体智能：IEEE P3961 动态组网 / 任务分解 / 协同决策 / 容错控制。

3. 智能体-工具-数据接入：IEEE P3945.2 统一数据格式 / 接口规范 / 同步异步 / 质量要求。

  • 本项目代码落点：collaboration.onComplete（DS-BIZ-001→DS-REPORT-001、DS-STOCK-001→DS-PROC-001）即"任务分解+协同"的轻量实现；tasks/task-force-*.js 是 L3/L4 群体协同（审批/冲突检测/超时催办）的真实底座。标准化 agent 间通信协议（A2A/MACP）为待补。

三、5端协同标准（贯穿层）

| 端 | 定义 | 核心职责 | 与平台对应 |

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

| 云 Cloud | 云端数据中心 | 全局统筹、大模型、知识库 | SCSAI PLM 云端 + 知识库分库 |

| 边 Edge | 边缘节点 | 实时推理、预处理 | ✅ server/edge/edge-node-manager.js（节点注册/心跳/分派/负载均衡） |

| 端 Device | 终端设备 | 泛在感知、采集 | 小程序端 / 设备台账（DS-EQUIP-001） |

| 网 Network | 网络设施 | 算力互联、编排 | ✅ server/network/network-manager.js（链路/路由/QoS/重传） |

| 智 Intelligence | 智能体系统 | 感知-决策-执行闭环 | 本标准体系全部（workers + 引擎） |

五端协同要求：感算控智一体化、端云协同、边云协同、网联互通、一致性保障（五端数据模型/语义/状态一致）。

与对象模型贯通：同一对象模型在云边端语义一致——SCSAI-tools.js 的 469 对象元模型是五端共同语言的基础。

四、标准落地路径（五阶段，与国家框架对齐）

阶段目标本项目当前状态待补
一、对象模型定义 7 基础智能体 + 核心工业对象元模型、建模型库已完成雏形：SCSAI 469 对象 + kb 分库 + item_types模型库版本管理、唯一标识注册
二、规则/关系引擎规则语言、关系元模型、与对象集成已完成雏形：rule_engine.db(sciot_rules_v2) + consistency-check规则冲突解决机制、关系推理引擎
三、智能体基础7 基础智能体八模块、身份码、能力注册已锚定：7 动词 base 员工 + workers 实现 + 诚实化通信/演化/记忆模块、worker 级身份码
四、数字员工按岗位封装、映射、考核已落地：positions 16 岗 + staff 77 员工 + KPI(77/77) + tier(77/77) + item_types(77/77) + capabilities(77/77) + verbs(28/77)L1~L5 等级标注
五、协同+5端通信协议、群体协同、五端贯通已落地：A2A/MACP协议 + collaboration(13链路) + task-force + 边端 + 网端边端真实部署、网端WebSocket

五、标准符合性验证（上架前必过）

验证项标准依据本项目验证方法（现状）
对象模型合规第二层检查 item_types / SCSAI 对象是否注册——待自动化
功能模块完整第一层检查 worker 八大模块——骨架诚实化已部分覆盖
互联协议合规第五层检查 type 字段消费——staff-router 未消费，待补
安全可信全层检查权限边界 + ctx.staffLog 审计 + requestConfirmation 人类接管
分类分级第一层按 L1~L4 评估——待补分级字段

六、标准体系关系总图

        ┌─────────────────────────────────────────┐
        │  治理侧第五层：多智能体协同              │  GB/Z 185.6 / IEEE P3945.1 / A2A
        └───────────────────┬─────────────────────┘
                            │ 协同基于
        ┌───────────────────▼─────────────────────┐
        │  治理侧第四层：数字员工（立交桥层）      │  岗位映射·权限·结果交付
        └─────────┬─────────────────────┬──────────┘
   业务侧四层交汇 │                     │ 由智能体驱动
        ┌─────────▼──────────┐   ┌──────▼──────────────────────┐
        │ 业务侧：行业→岗位  │   │ 治理侧第三层：规则+关系引擎  │
        │ （local.yaml       │   │ 确定性保障·上下文感知·决策  │
        │  positions 段）     │   └──────────┬───────────────────┘
        └────────────────────┘              │ 操作对象来自
                                  ┌─────────▼───────────────────┐
                                  │ 治理侧第二层：对象模型       │
                                  │ PLM统一语义底座·AAS元模型    │
                                  └─────────┬───────────────────┘
                                            │ 能力定义依据
                                  ┌─────────▼───────────────────┐
                                  │ 治理侧第一层：智能体基础     │
                                  │ GB/Z 195-2026 八大功能模块   │
                                  └─────────────────────────────┘

        ┌─────────────────────────────────────────────────────┐
        │  贯穿层：5端协同（云·边·端·网·智 一体化）            │
        └─────────────────────────────────────────────────────┘

六-B、核心落地机制：智能体 / 数字员工作为 PLM 对象注册（Aras 语义底座）

本平台做工业智能体最得天独厚的优势：PLM 源自 Aras Innovator（Gartner 魔力象限常年 Top 2 的 PLM），对象模型天然基于 ItemType / RelationshipType / AML 语义。别人要从零搭对象模型底座，我们直接站在 Aras 的语义底座上——智能体和数字员工不需要"另建一套注册机制"，它们就是两类标准的 PLM 对象。

1. PLM 对象模型底座现状（已落地，非空中楼阁）

平台对象层 server/utils/SCSAI-tools.js 已是 Aras Innovator 语义的完整映射，数据存放在 server/data/rule_engine.db：

| Aras 概念 | 本项目表 | 含义 |

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

| ItemType | sciot_item_types（is_relationship / is_versionable / implementation_type） | 对象类，支持版本管理与生命周期 |

| RelationshipType | sciot_relationships（source_item_type — name(behavior) — related_item_type） | 实体-关系-实体三元组，正是治理侧第三层关系引擎要求的元模型 |

| Property | sciot_properties | 对象属性（含 is_required / is_keyed / data_source） |

| AML / 模板 | sciot_templates（aml_template / generation_rules） | Aras AML 生成与字段规则 |

已注册对象类示例：PART（零件/物料）、DOCUMENT、CAD、PRODUCT、PROJECT、ECR、ECO、CHANGE、WBS ELEMENT 等——智能体/数字员工将作为新 ItemType 与它们并列，通过标准 RelationshipType 互相挂接。

2. 智能体 / 数字员工的 PLM 对象化注册标准

新增两类 ItemType（标准对象，非旁路配置）：

| ItemType | 名称 | 关键属性（Property） | 版本/生命周期 |

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

| AGENT | 智能体 | agent_id(唯一身份码/keyed)、name、capability(动词)、worker(实现文件)、level(L1~L4)、memory_type、comms_protocol(GB/Z 185.6/A2A) | 可版本化 |

| DIGITAL_EMPLOYEE | 数字员工 | staff_id(DS-XXX/keyed)、title、position_ref(岗位)、industry、tier、kpi_def、enabled | 可版本化 |

注册即生效：通过 SCSAI-tools.js 的 smartCreateItemType / AML 通道把 AGENT 和 DIGITAL_EMPLOYEE 注册进 PLM，与现有 PART/BOM/ECR 同库同源，天然满足"对象模型驱动"原则（无对象模型则无法注册，注册即成为单一事实来源的一部分）。

#### 2.1 代码落地入口（已实现，可重跑）

| 文件 | 作用 | 落点 |

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

| server/boss-scheduler/registerAgentObjects.js | 注册脚本（幂等，先查重后写入） | 双轨：本地 rule_engine.db 必落；远程 SCSAI 服务端可达时经 SCSAI-tools AML 通道推送，不可达降级仅落本地 |

| rule_engine.db → sciot_item_types | 已写入 AGENT(id=3)、DIGITAL_EMPLOYEE(id=4) 两类 ItemType + 标准属性 | 对象模型谱本地权威缓存 |

| rule_engine.db → sciot_relationships | 已写入 7 种预定义 R_* RelationshipType（R_AGENT_ENCAPSULATES/R_AGENT_CAPABILITY/R_STAFF_POSITION/R_STAFF_INDUSTRY/R_AGENT_OPERATES_ON/R_AGENT_CALLS/R_STAFF_GOVERNED_BY） | 关系引擎元模型落点 |

| rule_engine.db → agent_registry | 新建注册名册表，已落 77 个数字员工 + 7 个基础智能体实例映射（含 remote_status='pending_remote'） | 本地 PLM 对象实例映射，真业务闭环查图基础 |

运行结果（实测）：node server/boss-scheduler/registerAgentObjects.js → ItemType 复用 2、Relationship 新建 7、名册 84 条（77 DE + 7 AGENT），远程 PLM 不可达时自动降级，绝不阻塞本地。

远程推送（第 3 项，环境依赖，需凭据就绪后执行）：

  • 前置条件：在 .env 配置 SCSAI_SERVER / SCSAI_DATABASE / SCSAI_USERNAME / SCSAI_PASSWORD（指向 Aras PLM 服务端）。
  • 执行：重跑 node server/boss-scheduler/registerAgentObjects.js，脚本先发 ItemType get 探针确认连通，再经 SCSAI-tools.smartCreateItemType 把 AGENT / DIGITAL_EMPLOYEE 两类对象类型真推上 PLM（自带查重，可重复跑）。
  • 当前状态：未配置远程凭据，84 条仅落本地 agent_registry（remote_status='pending_remote'）。脚本已做到"凭据未配置/不可达时诚实打印跳过、绝不伪造可达"，符合"标准先行、零假成功"原则。
  • ⚠️ 不伪造推送：当前环境无 Aras 服务端凭据，第 3 项是待你提供凭据后的一键执行动作，不是已完成项。

属性命名对齐：标准第 2 节属性名（agent_id/staff_id）为语义名；代码落库时采用 agent_code/staff_code 等库列名，前端/路由消费以 agent_registry + digital_staff.config 为单一真相源，避免双写漂移。

3. 关系建立标准（怎么连起来，才能真互联互动）

智能体/数字员工与业务对象、彼此之间，通过标准 Aras RelationshipType 建立关系。预定义关系（语义对齐 Aras + 治理侧第三层关系类型：继承/组合/依赖/约束/通信/协同）：

| RelationshipType | 源 → 目标 | 语义（标准依据） | 业务含义 |

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

| R_AGENT_CAPABILITY | AGENT → AGENT（或 DIGITAL_EMPLOYEE） | 组合/协同 | 一个员工由多个智能体驱动（多对一） |

| R_AGENT_ENCAPSULATES | DIGITAL_EMPLOYEE → AGENT | 组合 | 同一智能体封装成多个员工（一对多） |

| R_STAFF_POSITION | DIGITAL_EMPLOYEE → POSITION(岗位) | 依赖/映射 | 员工承担某岗位（岗位→员工承载） |

| R_STAFF_INDUSTRY | DIGITAL_EMPLOYEE → INDUSTRY(行业) | 依赖/归属 | 员工服务某行业（行业→岗位场景） |

| R_AGENT_OPERATES_ON | AGENT → PART/BOM/ECR/... | 依赖/操作对象 | 智能体操作的具体业务对象（对象模型驱动） |

| R_AGENT_CALLS | AGENT → AGENT | 通信/协同 | 多智能体协同调用链（A2A/MACP） |

| R_STAFF_GOVERNED_BY | DIGITAL_EMPLOYEE → RULE(规则) | 约束 | 员工受某规则约束（规则引擎边界） |

关系即能力：因为关系是 PLM 一等公民（存于 sciot_relationships），智能体"能互联互动"不再靠硬编码脚本拉同事，而是查关系图谱——"找所有 R_AGENT_CALLS 指向我的 AGENT"即发现协作伙伴，"找 R_AGENT_OPERATES_ON 指向 PART 的 AGENT"即发现能处理该物料的员工。这是 Aras 关系引擎直接赋予的协同能力。

4. 真能跑业务的闭环（标准 → 实现）

自然语言/事件
   │  （如 "采集磷化工知识" / ncr.created 事件）
   ▼
PLM 查关系：DIGITAL_EMPLOYEE ─[R_STAFF_POSITION]→ POS-OPERATOR ─[R_STAFF_INDUSTRY]→ 磷化工
   │  定位到具体员工 DS-KBPIPE-001
   ▼
执行：AGENT(worker=chip-worker 等) ─[R_AGENT_OPERATES_ON]→ PART/BOM
   │  按 sciot_rules_v2 规则约束 + sciot_relationships 上下文
   ▼
结果回写 PLM：创建/更新 ItemType 实例 + 写 sciot_creation_history（可审计）
   │  + staffLog（可治理）
   ▼
闭环完成：对象模型驱动 → 规则约束 → 关系感知 → 多智能体协同 → 结果落库

这正是标准要求的"对象模型驱动、规则引擎约束、关系引擎感知、多智能体协同"在 Aras 底座上的真实落地，不是补丁。

代码已实现支撑：registerAgentObjects.js 把 agent_registry（77 DE + 7 AGENT）与 7 种 R_* 关系写入 rule_engine.db 后，上述"查关系图谱定位员工 → 执行 → 回写审计"的闭环即可直接消费 agent_registry + sciot_relationships 作为查图基础；前端「岗位体系」tab 也可从 agent_registry 按 R_STAFF_POSITION / R_STAFF_INDUSTRY 消费，而非只读 local.yaml。远程 Aras 服务端可达时经 SCSAI-tools AML 通道把同名 ItemType/Relationship 推上去，本地与远程共享同一套语义，互不冲突。

5. 与既有定义的衔接（不重复、不冲突）

  • 本机制取代 v2.0 中提到的 staff-router.js 未消费 type 字段的"待补"——改为：类型信息（capability_mode / role_prompt / workflow_step）注册为 AGENT 的 capability 属性 + R_AGENT_ENCAPSULATES 关系，路由层改为查 PLM 关系而非读 YAML 字段。
  • 本机制强化业务侧四层的"岗位→员工映射"：positions.members 改为 PLM 的 R_STAFF_POSITION 关系，前端「岗位体系」tab 直接消费 PLM 关系图谱。
  • 智能体身份码：AGENT 的 agent_id 即唯一身份码（GB/Z 185 要求），与 DS-XXX 员工 ID 形成"员工-智能体"双层标识。

七、引用与依据

  • 业务侧：GB/T 4754《国民经济行业分类》；GB/Z 185—2026《人工智能 智能体互联》
  • 治理侧：GB/Z 195-2026《人工智能 工业智能体参考架构》、《工业智能体 第1部分：通用要求》、《人工智能 工业智能体分类分级评估指南》、GB/Z 185.1～185.7—2026、IEEE P3945/P3961
  • 对象模型：IDTA-01001 AAS Metamodel、GB/T 45616.2-2025、GB/T 45626-2025
  • PLM 底座：Aras Innovator（Gartner PLM 魔力象限 Top 2）ItemType / RelationshipType / AML 语义；本项目映射见 server/utils/SCSAI-tools.js（sciot_item_types / sciot_relationships / sciot_properties / sciot_templates）
  • 项目配套：docs/06_DIGITAL_STAFF_UNIFICATION.md、server/boss-scheduler/profiles/local.yaml、server/boss-scheduler/workers/、server/utils/SCSAI-tools.js、server/data/rule_engine.db、server/boss-scheduler/lib/consistency-check.js
← 返回案例列表
分享：
🤖 Try Now →
🤖
🎁