岗位助手三层模型架构（行业 → 岗位 → 员工）· 2026-08-10

本文锁定「岗位助手」的目标架构与本次已实现的核心，作为后续增量改进的对齐基准。

设计要点（来自产品定义）：

• 行业是死的（固定集合，不可随意增删）。
• 岗位是可调的（绑定行业、内含多员工、可配岗位级/角色级参数）。
• 员工是通用的（同一员工服务多岗位；按 行业 + 岗位 动态调参）。
• 岗位 = 多智能体协同：一个岗位可同时调度多名员工并行/串行完成任务。
• 任何调用都收敛到对话框，结果统一呈现。

一、三层模型

┌─────────────────────────────────────────────────────────────┐
│ 行业 industry（死 / 固定）                                     │
│   phos_chem · baijiu · aerospace_machinery · general_machinery │
│   · electronics_manufacturing  (来源: industry-profile-loader)  │
└───────────────────────────┬─────────────────────────────────┘
                            │ 行业匹配岗位（industries 字段）
┌───────────────────────────▼─────────────────────────────────┐
│ 岗位 position（可调）                                          │
│   含多个员工 agents[]，每个有 role；可配 params（岗位级默认）   │
│   例: 操作工助手 / 质量管理员助手 / 工艺工程师助手 ...          │
└───────────────────────────┬─────────────────────────────────┘
                            │ 岗位匹配员工 + 调参
┌───────────────────────────▼─────────────────────────────────┐
│ 员工 staff（通用）                                             │
│   基础 params ⊕ 行业上下文 ⊕ 岗位级 params ⊕ 角色专属 params   │
│   → 执行时拿到"适配后参数"，无需为每个行业写一份员工            │
└──────────────────────────────────────────────────────────────┘

参数适配合并顺序（后者覆盖前者）

1. 员工基础 params（staff 定义里）
2. 行业上下文 industry（critical_inspect_marks / kb_topics / ncr_root_cause_mapping / spc_rules…）
3. 岗位级默认 position.params（本岗位全员共享）
4. 角色专属 agent.params（该员工在此岗位内的覆盖，最高优先级）

合并后同时写入 _industryId / _positionId / _positionRole，worker 可直接读 parameters.industry 聚焦查询。

二、本次已实现（可运行，已验证）

1. 核心运行时 server/boss-scheduler/position-runtime.js

• listIndustries() — 固定行业集合
• getPositions(industry?) — 按行业过滤岗位（未声明 industries = 服务全部行业，渐进迁移默认）
• resolveStaffParams(staffId, {industry, positionId}) — 三层级联合并
• getOrchestrationPlan(positionId, industry) — 岗位协同计划（执行前预览）
• runPosition(positionId, intent, {industry, mode}) — 岗位多智能体编排（并行/串行，结果统一合并）
• runStaffAdaptive(staffId, intent, {industry}) — 直接调用员工（仍按行业调参；不带 industry 则仅基础参数=精度较低）
• normalizeResult(result) — 统一结果契约（前端对话框统一渲染）

2. 行业绑定样板 server/boss-scheduler/profiles/local.yaml

POS-OPERATOR 已加 industries: [phos_chem, baijiu] + 岗位级 params + 角色专属 params（monitor_target/equip_focus），作为后续岗位的填写模板。

3. HTTP 入口 server/routes/digital-staff-routes.js（已挂载于 server.js）

• GET /api/digital-staff/industry/list
• GET /api/digital-staff/position/list?industry=
• GET /api/digital-staff/position/:id/plan?industry=
• POST /api/digital-staff/position/:id/run { industry, intent, mode }
• POST /api/digital-staff/staff/:id/adaptive-run { industry, intent }

路径刻意避开 /api/digital-staff/:id 单段详情路由，防止被误匹配为员工 id。

验证结果：三层参数合并正确（行业上下文+岗位级+角色专属）；行业过滤正确（POS-OPERATOR 在 electronics 不可见）；岗位编排扇出+合并正确（mock 验证）；真实员工 DS-SYS-001@phos_chem 自适应执行成功；5 个端点路由分发全部命中。回归脚本：scripts/test-position-runtime.cjs。

三、统一结果契约（前端渲染基准）

normalizeResult(result) =>
{
  type, title, summary,
  status: 'ok' | 'partial' | 'error' | 'confirm',
  blocks: [...],          // 卡片/结构化数据，员工返回 cards/blocks/data 原样承载
  staffId?, role?,
  raw                     // 原始结果，便于调试
}
// 岗位编排结果额外包裹：
{ type:'position', positionId, positionName, industry, intent, mode,
  agents:[ normalizedResult... ], summary }

四、后续增量（一点一点做）

• [ ] 前端收敛（核心体验）：行业选择器 → 岗位卡片 → 对话框；岗位内"一键协同"调用 position/:id/run；所有结果走 normalizeResult 统一卡片（StaffResultCard 已存在，需对接契约）。
• [ ] 岗位行业绑定铺开：其余 9 个岗位补 industries + 岗位级/角色级 params（参照 POS-OPERATOR 模板）。
• [ ] worker 消费行业上下文：让各 worker 真正读取 parameters.industry（如知识检索按 kb_topics 聚焦、质检按 critical_inspect_marks 聚焦），使"调参"落到查询而非仅透传。
• [ ] 多智能体协同视图：复用 CollaborationChainGraph.vue 在对话框渲染岗位编排的 Agent 链路与各自结论。
• [ ] 精度提示：直接调用（无岗位）vs 经岗位调用，前端标注"本次未带入岗位上下文，结果可能不够精确"。
• [ ] 事件驱动触发（可选）：支持"新 NCR 建好 → 自动跑根因分析岗位"等，补上 cron/对话之外的第三类触发。

五、模型回答用户之问

| 用户之问 | 本架构如何回答 |

|---|---|

| 设计对吗 | 对。行业(死)→岗位(可调)→员工(通用+调参) 解耦清晰，岗位即多智能体编排器 |

| 用户是谁 | 业务角色人员（按行业+岗位进入）+ 企业数字化/IT（配置监管） |

| 怎么用 | 选行业 → 选岗位 → 对话框提问（岗位精确派单）；或直接问（员工自适应，精度略低） |

| 达成什么目的 | 把"发现+报告"升级为"按岗位协同、带行业上下文的精准执行" |

| 帮到企业吗 | 能。前提是岗位级闭环+行业调参真正落到 worker 查询（增量 3） |