BossAgents BossAgents

数字员工组织化方案 · 行业 × 岗位 × 场景 专家团协同

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

数字员工组织化方案 · 行业 × 岗位 × 场景 专家团协同

目标：把当前 70 个"散兵式、只能单个调用的数字员工"组织成可按行业/岗位/场景分类、可组合、可协同的专家体系。

每个数字员工 = 一个能独立运行的专家单元；多个专家按场景组合成专家团，协同完成一个岗位或具体业务场景的任务。

本方案对应"先出方案、再实现、迭代驱动"的工作方法；本次落地 P1 垂直切片（已实跑验证）。

1. 问题诊断（已用代码/配置硬证据确认）

| 维度 | 现状 | 性质 |

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

| 单人执行 /api/digital-staff/run | 70 员工全可单跑、已归一化返回 steps | ✅ 主干可用 |

| 员工层分类标注（industry / position / scenario / team / tags） | 完全没有；行业只在 16 个岗位层标注 | ❌ 缺失 |

| 协同编排框架（position-runtime / task-force / task-force-store / position-events） | 真实存在、能调真实工人 | ✅ 但主前端（小程序+admin）完全不接，是"建好没通电"的孤岛 |

| 主前端调用方式 | 小程序 + admin exclusively 单人 /run | ❌ 只能一个一个叫 |

| 工人能力契约（input / output / 依赖声明） | 没有，只有 run() 黑盒 | ❌ 无法自动编排 |

| 场景团队（专家团）组合层 | 仅 4 个手写硬编码 taskForce，覆盖 8 岗位 | ❌ 覆盖极窄 |

结论：执行引擎（runStaffOnce 调真实工人）已 proven 可用。缺的是"用 行业×岗位×场景 对 70 个真实员工做分类与团队组合"的元数据层 + 把这套接到主流程的端点/UI。

2. 设计原则

  1. 专家单元优先：每个员工首先是一个可独立运行、输入输出清晰的单元（/run 已满足）。不破坏现有单跑能力。
  2. 分类即元数据：行业 / 岗位 / 场景 / 标签 以元数据形式标注，不改动 70 个 worker 与 local.yaml 的运行逻辑（零回归风险）。
  3. 协同靠编排器：专家团 = 有向无环图（DAG），成员可并行/串行、有依赖、有共享黑板（blackboard）、可选人工卡点。
  4. 复用已有执行引擎：专家团编排器直接复用已 proven 的 runStaffOnce（执行单个专家）与 positionRuntime.runPosition（执行岗位）。不重建轮子。
  5. handoff 契约：下游专家通过 parameters._upstream 拿到上游结论、通过 parameters._blackboard 拿到全员共享上下文——"单个完不成、团队能完成"的关键。

3. 四层模型

L0  专家单元 (Expert)        每个数字员工 = 能独立运行的专家
    │  元数据: industry / position / scenarios / tags / expertise / standalone
L1  分类索引 (Registry)      行业×岗位×场景 三维索引，按任意维度检索专家
    │
L2  专家团 (Team)            DAG = 成员(专家/岗位) + dependsOn + blackboard + gate
    │                        例: 质量闭环 = IQC→IPQC→OQC→NCR→CAPA→FMEA→SPC→AUDIT→STAT→QUALITY
L3  场景编排 (Scenario)       场景 = 专家团 + 触发(手动/事件/定时)；assembleTeam(industry,position,scenario) 自动组队
  • L0 单元契约：run(staff, ctx, intent, parameters) 已就绪；团编排器额外注入 _upstream / _blackboard / industry。
  • L1 索引：expert-registry.json（由 tools/build-expert-registry.cjs 从 local.yaml 生成），含 70 专家、16 岗位、N 场景、行业映射。
  • L2 团：expert-teams.js 定义可复用团队（真实 DS-* id），执行 DAG、聚合结果、收集全员过程步骤、产出协同图。
  • L3 场景：/api/digital-staff/teams 端点暴露团队列表/详情/运行；后续接事件与定时触发。

4. 专家团执行引擎（复用，不重建）

expert-teams.runTeam(teamId, {intent, parameters, industry})
  1. 解析团队 DAG，Kahn 拓扑排序成"波次(wave)"
  2. 逐波次：同波成员 Promise.all 并行执行
       runStaffOnce(member.id, memberIntent, {
         ...parameters, industry,
         _blackboard,                         // 全员共享上下文
         _upstream: 依赖成员结果合并           // 上游结论
       }, { skip_mtclaw:true, source:'team', fromTeam:true })
  3. 每个成员结果写入 blackboard[key]，并收集 {key,id,name,role,success,steps,summary}
  4. 聚合：combinedSummary + 全员 steps 时间线 + 协同图(graph)
  5. 返回 { teamId, name, success, members[], blackboard, graph, totalSteps }

fromTeam:true 用于抑制团队内成员的"独立 A2A 链"重复触发（已在 index.js runStaffOnce 加一行守卫）。

5. 本轮落地（P1）交付物

| 文件 | 作用 |

|---|---|

| docs/digital-employee-orchestration-design.md | 本方案 |

| tools/build-expert-registry.cjs | 从 local.yaml 生成分类注册表（可重跑） |

| server/boss-scheduler/expert-registry.json | 70 专家 / 16 岗位 / 场景 / 行业 分类元数据 |

| server/boss-scheduler/expert-registry.js | 注册表加载 + 按行业/岗位/场景检索 |

| server/boss-scheduler/expert-teams.js | 专家团编排器（DAG+黑板+聚合）+ 5 个真实场景团 |

| server/routes/expert-team-routes.js | /teams(列表) /teams/run(运行) /teams/registry(全量元数据) /teams/:id(详情) |

| server/routes/digital-staff-routes.js | +3 行：把 /teams* 委派给 expert-team-routes |

| server/boss-scheduler/index.js | +1 行：fromTeam 守卫，抑制团队内 A2A 重复触发 |

**5 个真实场景专家团（全部用真实 DS-* id）：

  1. new_product_launch 新品上架全流程：PRODUCT→CONTENT→MALL→DOC→LOOP
  2. quality_loop 质量闭环：IQC→IPQC→OQC→NCR→CAPA→FMEA→SPC→AUDIT→STAT→QUALITY
  3. process_optimize 工艺优化：PROC-DATA→SCCAPP-DESIGN→SCCAPP-OPT→SCCAPP-QBRIDGE→SCCAPP-SYNC（PROCESS-OPT 协调）
  4. procure_fulfill 采购履约：PROC-PLAN→PROC→VEN→SUP-AUDIT→COST→LOG→STOCK
  5. knowledge_governance 知识治理：KBPIPE→KNOWLEDGE→PLM-BRAIN→DATA-OPS→DOC

6. 验收标准（用户口径）

  • 单个专家仍可在小程序/网页独立运行出结果+过程步骤（不退化）。
  • 给定场景，专家团能自动组队、按依赖协同执行、产出组合结果 + 各专家过程步骤 + 协同图。
  • 对比：单独调任一质量员工只看到局部；调"质量闭环"专家团可看到跨 IQC/IPQC/OQC/NCR/CAPA/FMEA/SPC 的整体质量态势 + 各自步骤——即"单个完不成、团队能完成"。

7. 后续（P2/P3，本轮未做）

  • P2 前端场景控制台：小程序/网页新增"场景/专家团"入口，按行业→场景浏览，一键运行，展示协同图 + 组合结果 + 各专家步骤（现有 taskforce-ui.html 可改造成主流程入口）。
  • P3 事件/定时触发：position-events 已就绪，把"投诉→质量闭环""停线→生产应急"等接入；把现有 4 个硬编码 taskForce 迁移为场景团。
  • 元数据回写：把 expert-registry.json 的 industry/position/scenario/tags 回写进 local.yaml 各员工条目，成为单一真相源。
  • handoff 深化：逐步让下游 worker 真正消费 _upstream（如 CAPA 读取 NCR 根因、海报读取商品定义），使组合结果产生 1+1>2 的增量价值，而非仅顺序执行。

8. 架构校正（2026-09-06，关键）

用户指出：上轮的 expert-registry.json + TEAMS 硬编码常量仍是"随手拼凑"，与普通人手搓无异；行业/岗位/场景/数字员工必须在 PLM 中以对象模型 + 关系组织，编排引擎只"读图"而非"读常量"。

8.1 PLM 实况硬证据（直连 114 SCSAI / InnovatorServer.aspx 探查）

  • 存在**：ES_Agent(仅 1 实例)、Employee、Team、hr_dept、RelatedScene/Scene_、BossAgent_、Program/Project Team。
  • 不存在：Industry/行业、Position/岗位、Scenario/场景(独立类型)、DigitalEmployee/数字员工、Agent/Expert、OrgUnit/Department。
  • 621 个 RelationshipType 里，行业/岗位/场景/员工相关的绑定关系（R_STAFF_POSITION、R_STAFF_INDUSTRY、R_SCENARIO_MEMBER…）一个都没有；只有 Member、Team Identity、RelatedScene、ES_AgentState。
  • 结论：行业/岗位/场景/数字员工的分类今天根本没在 PLM 建成对象+关系。它们被 staff-registry.js 拍平成了 agent_registry 表的 industry/position_code 两列——其注释声称的 R_STAFF_POSITION/R_STAFF_INDUSTRY 关系纯属谎言，未建。

8.2 校正后的架构（已落地）

新建 server/boss-scheduler/plm-org-model.js 作为"对象模型"单一真源，PLM 原生结构：

  • 4 个 ItemType：DS_Industry / DS_Position / DS_DigitalEmployee / DS_Scenario（含属性元数据）。
  • 4 个 RelationshipType：R_Industry_Position / R_Position_Employee / R_Industry_Scenario / R_Scenario_Member（含 role/depends_on/exec_order 属性）。
  • 实例 + 关系实例：7 行业 / 26 岗位(部门去重) / 70 员工 / 5 场景；33 条 R_Scenario_Member 关系实例承载"组合即关系数据"。
  • 读取器：getIndustries/getPositions/getEmployees/getScenarios/getScenario/assembleFromModel 全部从关系图推导；assembleFromModel({industry,position,scenario}) 按"场景→岗位→行业"优先级动态组队，无任何硬编码。
  • toAML()：生成 56KB 可部署 AML，一键把整套对象模型落到 114 PLM。

expert-teams.js 删除 TEAMS 常量，改调 plm-org-model（DAG 执行引擎 topoWaves/runTeam/共享黑板 保留复用）；expert-registry.js 改为委托薄层。

8.3 验收（真实运行）

  • GET /api/digital-staff/teams 列表 5 个团（来自 DS_Scenario 实例）。
  • POST /api/digital-staff/teams/run 跑 quality_loop：10 专家 / 49 步 / 完整 DAG (iqc→ipqc→…→quality)，全部从 R_Scenario_Member 关系实例读取，真实汇聚 PLM/SCSAI 数据（NCR 43/CAPA 3/SPC 15 特性/审核 1…）。新增/调整场景 = 加 R_Scenario_Member 关系实例，不再改代码。

8.4 待用户拍板：对象模型落点

当前模型以"PLM 结构"存在于本地（引擎已读它）。是否把模型真正部署进 114 PLM（执行 toAML()，建 ItemType/RelationshipType + 实例），还是先本地运行、等环境/你确认再部署？若 114 之外另有 PLM 实例存放行业/岗位定义，也请指明地址与凭据。

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