行业 × 岗位 × 数字员工：协同体系总体方案

版本 v1.0 · 2026-08-11 · 取代并升级 role-staff-architecture-20260810.md 的待办项 ④⑥

本文回答一个问题：行业、岗位（人类员工）、数字员工（智能体）三者如何配合与协调，才能真正解决中小企业的数字化智能化。

0. 先说清楚真问题

中小企业数字化的失败，极少是因为"没有 AI"，而是因为 AI 没有嵌进既有的人和事里。典型死法有三种：

| 死法 | 表现 | 根因 |

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

| 通用助手病 | 买了个大模型助手，问啥都能答，但答的都不能直接用 | 缺行业坐标系，不知道本行业的关键工序、检验标记、根因图谱 |

| 无人认账病 | AI 出了分析报告，没人执行，也没人负责 | 缺岗位权责，不知道该谁干、干到什么程度、谁签字 |

| 烟囱重建病 | 每换一个行业/客户就重写一套智能体 | 缺通用能力层，行业与能力耦合，成本无法摊薄 |

三层模型正是针对这三种死法的解药。它不是一个技术分层，而是一个责任与成本的分层。

1. 三层的本质：为什么恰好是这三层

每一层回答一个互不替代的问题：

┌──────────────────────────────────────────────────────────────┐
│  行业 industry  ——  回答「懂不懂行」(Know-WHAT)                 │
│  性质：死的、固定集合、不可随意增删                               │
│  内容：关键工序 / 检验标记 / SPC规则 / 根因图谱 / 知识库主题      │
│  作用：所有查询与推理的**坐标系**。没有它，回答就是通用废话        │
└───────────────────────────┬──────────────────────────────────┘
                            │ 供给知识与约束
┌───────────────────────────▼──────────────────────────────────┐
│  岗位 position  ——  回答「该谁干、谁负责」(Know-WHO / 权责)      │
│  性质：可调的、企业自定义、随组织变化                             │
│  内容：人的职责 + 授权边界 + 审批权 + 名下数字员工班组            │
│  作用：把能力**落到责任主体**。没有它，结论无人认账               │
└───────────────────────────┬──────────────────────────────────┘
                            │ 供给职责与授权
┌───────────────────────────▼──────────────────────────────────┐
│  数字员工 staff  ——  回答「能不能干」(Know-HOW)                  │
│  性质：通用的、跨行业跨岗位复用、靠调参适配                        │
│  内容：一个可执行的能力原子（SPC分析/根因定位/文档生成/排产…）     │
│  作用：真正干活。没有它，前两层只是一张组织图                      │
└──────────────────────────────────────────────────────────────┘

1.1 关键洞察：正交性决定了成本

假设 N 个行业、M 个岗位、K 个能力。

• 耦合实现（每个行业每个岗位单独做一套智能体）：需要 N × M × K 份实现。5×11×49 ≈ 2700 份 —— 中小企业永远负担不起。
• 正交解耦（本方案）：只需 N + M + K 份配置。5 + 11 + 49 = 65 份 —— 一个小团队可维护。

这不是架构洁癖，这是中小企业能用得起 AI 的唯一路径。 三层解耦的经济学意义大于技术意义。

1.2 三层如何在执行期合流

三层不是调用链，而是参数的四级级联合并（后者覆盖前者）：

员工基础 params
   ⊕ 行业上下文 industry      ← 行业层注入（critical_inspect_marks / kb_topics / spc_rules …）
   ⊕ 岗位级 params            ← 岗位层注入（本岗位全员共享的视角，如 perspective: 质量管控）
   ⊕ 角色专属 agent.params    ← 该员工在此岗位内的定制（最高优先级）
   = 执行期有效参数

同时写入 _industryId / _positionId / _positionRole，worker 内部据此聚焦真实查询（而非仅仅透传）。

⚠️ 这一步是三层模型真假的分水岭。若 worker 只是把 industry 参数收下却不改查询条件，三层就是装饰。

当前状态：process-worker 已按 industry_id 过滤（phos_chem=3302 / aerospace=157 条，无串味）；doc-worker 已按行业选库。其余 worker 仍在铺开中（见 §8）。

2. 被大多数方案遗漏的第四个主体：人

用户的原话是"岗位（人类员工）"。这个括号至关重要：

岗位首先是人的岗位，数字员工是这个岗位上的班组，不是这个岗位本身。

如果把岗位理解成"数字员工的文件夹"，就会造出一个没有人的自动化系统 —— 它会在第一次出错时崩塌，因为没人愿意为机器的结论负责。

2.1 人机职责边界（已落地为配置）

每个岗位显式声明四件事：

human:
  title: 质量管理员 / 质量经理
  duties:            # 人保留，永不授权给机器
    - 不合格品最终判定与放行签署
    - 客户投诉对外回复口径确认
    - 质量体系审核结论签字
  delegated:         # 明确授权给数字员工
    - 检验数据汇总与 SPC 统计分析
    - NCR 根因初判与 CAPA 草案起草
    - 质量报告初稿生成
  approvals: [批次放行, CAPA关闭, 让步接收]   # 该岗位人类持有的审批权
  escalate_to: 技术总监                        # 超出权限时上报给谁

2.2 三条不可让渡的原则

1. 结论权 vs 决定权分离：机器可以给结论，对外生效的决定必须有人签。
2. 授权显式化：delegated 没写的，机器就不许自动做。默认拒绝，而非默认允许。
3. 分歧上交：多个智能体结论冲突时，系统不自作主张调和，而是标记分歧、交人裁决（见 §4.5）。

approvals 与编队中 human 卡点的 approver 字段对应，构成从配置到执行的责任闭环。

覆盖情况：11/11 个岗位已全部配置 human 层（操作工、质量、工艺、调度、设备、库存、财务、采购、经营、IT、GOAI 演示）。

2.3 审批人自动回落

编队卡点若没显式写 approver，运行时会自动回落到该成员挂靠岗位的 human.title：

member.approver  →  没有则查 position.human.title  →  仍没有则标"待指派"

这条规则的意义是：不允许出现"系统在等人签字，但没人知道该谁签"的悬空状态。

配置漏写不会导致流程卡死，只会退化成一个有明确归属的待办。

2.4 人在环必须可追溯

人的每一次决策都写入 task_force_approvals 表，记录五要素：

| 字段 | 含义 |

|---|---|

| approver | 按配置应该批的人（岗位 human.title） |

| decided_by | 实际点确认的人 |

| decision | 批了什么（同意放行 / 有条件放行 / 驳回…） |

| note | 审批意见原文 |

| decided_at | 何时批的 |

approver 与 decided_by 分开记，是为了能查出"该质量经理批的，结果是别人代批的"这类越权情形 —— 这在质量体系审核里是要被开不符合项的。

3. 协同的五个等级（L0 → L4）

"单独执行、配合执行、多智能体协同、多岗位协同" —— 这四种诉求，对应一个连续的协同光谱：

| 等级 | 协同主体 | 触发方式 | 典型场景 | 精度 | 状态 |

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

| L0 裸调 | 1 个数字员工 | 直接调 API | 调试、临时问一句 | ★☆☆☆☆ | ✅ |

| L1 行业自适应 | 1 个数字员工 + 行业上下文 | 对话框直接提问 | "查一下磷酸一铵的SPC" | ★★★☆☆ | ✅ |

| L2 岗位内协同 | 1 个岗位 → N 个数字员工 | 选岗位后提问 | "生成今天的质量报告"（审核+SPC+NCR+CAPA+校验 五员工并行） | ★★★★☆ | ✅ |

| L3 跨岗位编队 | M 个岗位 → Σ N 个数字员工 + 人 | 编队/事件触发 | 客户投诉闭环（质量→工艺+调度→人工放行→经营复盘，4岗位18员工） | ★★★★★ | ✅ 本次 |

| L4 自由编队 | 任意岗位 + 任意智能体临时组队 | 临时发起 | "出口订单合规核查"（文档员+审核员+老板助手，无预置岗位） | ★★★★☆ | ✅ 本次 |

人在环（Human-in-the-loop）不是第六级，而是一个正交维度 —— L2~L4 的任何环节都可以插入人工卡点。

3.1 L2 与 L3 的本质区别

• L2 = 一个责任主体内部的分工。岗位负责人对整个结论负责，内部谁干的无所谓。
• L3 = 多个责任主体之间的交接。每个岗位对自己那段负责，交接处需要结论传递与责任划分，还常常需要人签字。

L3 才是真实企业流程的形状。客诉、停线、新品、成本异常 —— 没有一个是单岗位能闭环的。

3.2 已配置的四个预置编队

4. 六大协调机制（"怎么协调"的正面回答）

协同不等于"把几个智能体一起叫起来"。真正的协调需要六件事同时成立：

4.1 上下文级联 —— 让每个智能体知道"我是谁、在什么行业、在哪个岗位"

即 §1.2 的四级参数合并。这是空间维度的协调：确保并行的智能体站在同一坐标系上。

4.2 编排拓扑（DAG 分层）—— 让协同有先后

成员通过 dependsOn 声明依赖，运行时做拓扑分层：

TF-COMPLAINT 的实际排程：
  L0:  POS-QA(5员工)                          ← 无依赖，先跑
  L1:  POS-PROCESS-ENG(4) ∥ POS-SCHEDULER(4)  ← 都依赖 qa，彼此无关 → 并行
  L2:  [人] 质量经理放行审批                    ← 依赖 proc + sched
  L3:  POS-BOSS(5)                            ← 依赖人的决定

层内并行、层间串行。既不像纯串行那样慢，也不像纯并行那样各说各话。

配置期即拦截依赖成环与依赖不存在的成员，不把错误留到运行时。

4.3 共享黑板 —— 让下游知道上游说了什么

这是协同的信息载体。每个成员完成后把结论写入黑板；下游成员执行前收到两样东西：

• _upstream：它直接依赖的成员结论（精准，避免上下文噪声）
• _blackboard：全量已完成结论（供需要全局视野的成员，如汇总/仲裁环节）

⚠️ 实现要点：黑板必须下沉到数字员工的 parameters，而不能只停在岗位层。

否则"跨岗位协同"只是链路图上串起来了，岗位内的 18 个员工实际谁也没看到上游结论 —— 这是本次修复的一个真实缺口。

4.4 人在环卡点 —— 让机器在该停的地方停下

type: human 的成员是一等公民，不是附加的通知：

执行到人工卡点 → 整个编队挂起 → 返回 status='awaiting_human' + runId
                                  ↓
      带上「谁来批(approver) / 批什么(question) / 可选项(options)
            / 决策依据(上游全部结论)」推给人
                                  ↓
      人决策 → POST /taskforce/resume { runId, decisions } → 从挂起层继续跑完

也支持预置决策直通（decisions 参数）：用于自动化程度高的场景或回归测试，跳过挂起一次跑完。

挂起态必须落库，这不是可选项。 一次 L3 编队在到达卡点前可能已经调度了十几个数字员工、跑了半分钟。若挂起态只在内存里：

• server 重启 / 崩溃 → 待签字的编队凭空消失，前面的工作全部作废；
• 多进程部署 → A 进程挂起的编队，B 进程看不到，人在页面上根本找不到待办。

因此挂起上下文（分层结构、已完成结论、共享黑板、已有决策）序列化后写入 task_force_runs 表：

首次执行 → 遇卡点 → savePending(ctx)  ──→ core_runtime.db
                                              ↓  （server 重启，内存清空）
人打开待办 → GET /taskforce/pending  ←────────┘
提交决策 → resume(runId) → 内存无 → loadPending() 重建上下文 → 从挂起层继续跑完

重建上下文时，执行器（函数，不可序列化）用默认执行器补齐；成员结果中的 raw 原始明细体积过大不落库，会标 _rawDropped，摘要与共享黑板完整保留 —— 恢复执行只依赖后两者。

4.5 冲突检测与仲裁 —— 让分歧浮出水面而不是被平均掉

多智能体最危险的失败模式不是出错，而是几个结论互相矛盾却被强行汇总成一段圆滑的话。

系统对编队内所有结论做互斥判定（合格/不合格、继续/停机、风险低/高风险），一旦发现正反双方同时存在：

{
  "topic": "合格|通过|放行… vs 不合格|不通过|拒收…",
  "positive": [{"key": "buy", "role": "采购侧归因"}],
  "negative": [{"key": "proc", "role": "工艺侧归因"}],
  "suggestion": "结论存在分歧，建议由岗位负责人（人类员工）裁决后再执行"
}

不调和、不隐藏、直接上交。 对应 POS-BOSS 的 结论分歧仲裁 审批权。

4.6 三条触发通道 —— 让协同不止发生在有人提问时

| 通道 | 入口 | 特点 |

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

| 对话触发 | 用户在对话框提问 | 人主动，即时 |

| 定时触发 | cron / loop | 周期性，如日报、巡检 |

| 事件触发 | 业务系统 emit 事件 | 被动感知，如 NCR 建单、设备报警、客诉受理 |

事件触发是中小企业最需要却最缺的一条 —— 因为老板和班组长不会主动想起来问 AI。

事件目标现已支持三型：单个员工 / 单个岗位 / 整个跨岗位编队：

- event: complaint.received
  taskForce: TF-COMPLAINT       # 收到投诉 → 直接拉起 4 岗位 18 员工的闭环编队
  industry: phos_chem
  intent: 收到客户投诉（投诉单 {{complaintId}}，客户 {{customer}}…）

事件 → 编队 → 挂起等人决策 → 人在控制台批 → 自动跑完。这就是一条完整的无人值守业务闭环。

5. 统一收敛：无论怎么调，结果长一个样

协同形态越多，前端越容易碎。因此所有等级最终收敛到同一组契约：

// 单个智能体结果
normalizeResult() => { type, title, summary, status, blocks, staffId?, role?, raw }
//   status: ok | partial | error | confirm

// 协同链（L2/L3/L4 通用，前端一套组件渲染所有等级）
collaborationChain: [{
  taskId, assignedTo, status, title, result,
  _layer,   // L3/L4 独有：DAG 层号，用于画分层图
  _type     // position | staff | human
}]

统一入口 + 统一契约 + 统一渲染 —— 用户永远只面对一个对话框，不需要理解 L0~L4 的差别。复杂度留在系统里，简单留给用户。

6. 完整 API 面

【行业层】
GET  /api/digital-staff/industry/list

【岗位层（含人类员工职责）】
GET  /api/digital-staff/position/list?industry=          → 含 human 字段
GET  /api/digital-staff/position/:id/plan?industry=      → 执行前预览派哪几个员工
POST /api/digital-staff/position/:id/run                 → L2 岗位内多智能体
POST /api/digital-staff/staff/:id/adaptive-run           → L1 行业自适应单体

【编队层（本次新增）】
GET  /api/digital-staff/taskforce/list?industry=
GET  /api/digital-staff/taskforce/:id/plan?industry=     → DAG 分层预览 + 人工卡点位置
POST /api/digital-staff/taskforce/:id/run                → L3 跨岗位协同
POST /api/digital-staff/taskforce/adhoc                  → L4 自由编队（无需预配置）
POST /api/digital-staff/taskforce/resume                 → 人类员工提交决策后恢复（可带 decidedBy）
GET  /api/digital-staff/taskforce/pending                → 当前挂起等人的编队（跨重启存活）

【审计层】
GET  /api/digital-staff/taskforce/runs?limit=&status=&forceId=&industry=
                                                         → 编队运行历史
GET  /api/digital-staff/taskforce/run/:runId             → 单次详情（成员结论 + 黑板 + 审批记录）
GET  /api/digital-staff/taskforce/approvals/stats        → 审批负荷（按人 / 按决策聚合）

【事件层】
POST /api/digital-staff/event                            → 发布业务事件
GET  /api/digital-staff/event/triggers                   → 触发器（支持热更新增删）
GET  /api/digital-staff/event/stream                     → SSE 实时推流

7. 中小企业落地路径（四阶段，不要一步到位）

三层模型全量上线对中小企业是灾难 —— 它需要的是能看到效果的最小步。

| 阶段 | 做什么 | 用户感知 | 门槛 |

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

| 一、单点见效（1~2周） | 选 1 个行业 + 1 个最痛岗位，跑 L1/L2 | "问一句就有答案，还挺懂我们厂" | 只需配好行业档案 |

| 二、岗位铺开（1~2月） | 补齐 5~8 个岗位，写清 human 职责边界 | "各岗位都有助手，知道谁该管什么" | 需和企业一起理权责 |

| 三、跨岗位闭环（2~3月） | 上 1~2 个 L3 编队（建议从客诉或停线起步） | "一件事自动串起几个部门，还知道找我签字" | 需要流程共识 |

| 四、无人值守（持续） | 接业务系统事件，事件 → 编队 → 挂起等人 | "没人问它也在干活，该我批的时候才找我" | 需要系统对接 |

为什么建议从客诉/停线起步：这两件事痛感最强、跨部门最明显、结果最可衡量（响应时长、复产时长），最容易让老板看到 ROI 并愿意继续投入。

8. 诚实的待补齐项

8.1 已闭合

8.2 仍待补齐

无。原唯一待补齐项「挂起编队无超时/催办」已于本节闭环（邮件催办 + 定时巡检 + 升级标注），见 §8.1。

关于审批权限：已升级为"硬拦截 + 可追溯"双保险——越权代批在 resumeTaskForce 入口即被拦下（返回 403 + violations，不落库、不恢复执行），同时历史越权记录仍可通过 approver ≠ decided_by 事后审计。

当前"操作人身份"由前端/调用方传入 decidedBy（无统一登录体系时的务实方案）；若要接企业 SSO 做真正的准入，可在本拦截层之上叠加。

9. 一句话总结

行业给坐标系，岗位给责任，数字员工给能力，编队给协同，人给最终的那一笔签字。

五者缺一，中小企业的 AI 就会退化成一个昂贵的聊天框。

附：核心文件索引

数据表