Industry × Role × Digital Employee: Overall Collaborative System Architecture

Version v1.0 · 2026-08-11 · Replaces and upgrades the to-do items ④⑥ from role-staff-architecture-20260810.md

This article answers one question: How can industry, roles (human employees), and digital employees (agents) collaborate and coordinate to genuinely solve the digitalization and intelligentization challenges for small and medium-sized enterprises (SMEs).

0. First, Clarify the Real Problem

The failure of digitalization in SMEs is rarely due to "lack of AI," but rather because AI is not embedded into existing people and processes. There are three typical failure modes:

| Failure Mode | Manifestation | Root Cause |

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

| General Assistant Syndrome | Purchased a large model assistant that can answer anything, but the answers are not directly usable | Lacks an industry coordinate system; unaware of key processes, inspection markers, and root cause maps specific to the industry |

| Accountability Void Syndrome | AI produces analysis reports, but no one executes them or takes responsibility | Lacks role-based authority and responsibility; unclear on who should do what, to what standard, and who signs off |

| Silo Rebuilding Syndrome | Rewriting a set of agents for each new industry/client | Lacks a generic capability layer; industry specifics are coupled with capabilities, preventing cost amortization |

The three-layer model is precisely the antidote to these three failure modes. It is not a technical layering, but a layering of responsibility and cost.

1. The Essence of the Three Layers: Why Exactly These Three?

Each layer addresses a distinct, non-interchangeable question:

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

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

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

• Coupled implementation (creating a separate agent for each industry and each role): Requires N × M × K implementations. 5×11×49 ≈ 2700 implementations — unaffordable for SMEs forever.
• Orthogonal decoupling (this solution): Requires only N + M + K configurations. 5 + 11 + 49 = 65 configurations — maintainable by a small team.

This is not architectural purism; it is the only path for SMEs to afford AI. The economic significance of three-layer decoupling outweighs its technical significance.

1.2 How the Three Layers Converge at Runtime

The three layers are not a call chain, but a four-level cascading merge of parameters (the latter overrides the former):

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

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

⚠️ This step is the watershed for determining the authenticity of the three-layer model. If the worker merely receives the industry parameter without modifying the query conditions, the three layers are merely decorative.

Current status: The process-worker has already filtered by industry_id (phos_chem=3302 / aerospace=157 records, no cross-contamination); the doc-worker has selected databases by industry. Other workers are still being rolled out (see §8).

2. The Fourth Entity Overlooked by Most Solutions: People

The user's original statement was "role (human employee)." This parenthesis is crucial:

A role is first and foremost a human position. The digital employee is the team member assigned to this role, not the role itself.

If a position is understood as a "folder for digital employees," it creates an automated system without people — it will collapse at the first error because no one is willing to take responsibility for the machine's conclusions.

2.1 Human-Machine Responsibility Boundary (Implemented as Configuration)

Each position explicitly declares four things:

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

2.2 三条不可让渡的原则

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

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

Coverage: 11/11 positions have all been configured with a human layer (operator, quality, process, scheduling, equipment, inventory, finance, procurement, management, IT, GOAI demo).

2.3 Automatic Fallback of Approver

If a formation checkpoint does not explicitly specify an approver, the runtime will automatically fall back to the human.title of the position to which the member is assigned:

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

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

Missing configuration will not cause the process to stall; it will only degrade into a pending task with clear ownership.

2.4 Human-in-the-Loop Must Be Traceable

Every human decision is recorded in the task_force_approvals table, capturing five elements:

| Field | Meaning |

|---|---|

| approver | The person who should approve according to configuration (position human.title) |

| decided_by | The person who actually clicked confirm |

| decision | What was approved (approve release / conditional release / reject…) |

| note | Original approval comment |

| decided_at | When it was approved |

Recording approver and decided_by separately allows detection of unauthorized situations, such as "this quality manager's approval was actually performed by someone else" — which would be flagged as a non-conformity in quality system audits.

3. Five Levels of Collaboration (L0 → L4)

"Independent execution, coordinated execution, multi-agent collaboration, multi-role collaboration" — these four requirements correspond to a continuous collaboration spectrum:

| Level | Collaboration Entity | Trigger Method | Typical Scenario | Precision | Status |

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

| L0 Direct Call | 1 Digital Employee | Direct API call | Debugging, ad-hoc queries | ★☆☆☆☆ | ✅ |

| L1 Industry-Adaptive | 1 Digital Employee + Industry Context | Direct dialog query | "Check the SPC for monoammonium phosphate" | ★★★☆☆ | ✅ |

| L2 Intra-Role Collaboration | 1 Role → N Digital Employees | Query after selecting role | "Generate today's quality report" (5 employees in parallel: review+SPC+NCR+CAPA+verification) | ★★★★☆ | ✅ |

| L3 Cross-Role Formation | M Roles → Σ N Digital Employees + Human | Formation/Event-triggered | Customer complaint closed-loop (Quality→Process+Scheduling→Manual Release→Business Review, 4 roles, 18 employees) | ★★★★★ | ✅ This Release |

| L4 Free Formation | Any role + any agent temporary team | Ad hoc initiation | "Export Order Compliance Check" (Document Clerk + Reviewer + Executive Assistant, no predefined roles) | ★★★★☆ | ✅ This time |

Human-in-the-loop is not a sixth level, but an orthogonal dimension — manual checkpoints can be inserted at any stage from L2 to L4.

3.1 The Essential Difference Between L2 and L3

• L2 = Division of labor within a single responsible entity. The role owner is accountable for the final conclusion; who does the work internally is irrelevant.
• L3 = Handoffs between multiple responsible entities. Each role is responsible for its own segment; conclusions must be transferred and responsibilities defined at handoffs, often requiring human sign-off.

L3 reflects the actual shape of enterprise processes. Customer complaints, line stoppages, new product launches, cost anomalies — none can be closed by a single role alone.

3.2 Four Pre-configured Formations

4. The Six Coordination Mechanisms (A Positive Answer to "How to Coordinate")

Coordination is not just "calling up several agents together." Real coordination requires six things to be established simultaneously:

4.1 Context Cascading — Letting each agent know "who I am, in what industry, and in which role"

That is, merging the four-level parameters from §1.2. This is spatial coordination: ensuring parallel agents operate within the same coordinate system.

4.2 Orchestration Topology (DAG Layering) — Establishing an order for collaboration

Members declare dependencies via dependsOn, and the runtime performs topological layering:

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

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

During configuration, it intercepts members with circular dependencies or non-existent dependencies, preventing errors from reaching runtime.

4.3 Shared Blackboard — Letting downstream members know what upstream members have said

This is the information carrier for collaboration. Each member writes its conclusions to the blackboard upon completion; downstream members receive two things before execution:

• _upstream: Conclusions from members they directly depend on (precise, avoiding context noise)
• _blackboard: Full set of completed conclusions (for members requiring a global view, such as aggregation/arbitration stages)

⚠️ Key Implementation Points: The blackboard must be pushed down to the digital employees' parameters, not just remain at the job position level.

Otherwise, "cross-position collaboration" is only connected on the link diagram, and the 18 employees within the positions actually never see the upstream conclusions — this is a real gap addressed in this fix.

4.4 Human-in-the-Loop Checkpoints — Making the machine stop where it should

Members of type: human are first-class citizens, not just add-on notifications:

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

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

The suspended state must be persisted to the database; this is not optional. An L3 formation may have already dispatched over a dozen digital employees and run for half a minute before reaching a checkpoint. If the suspended state only exists in memory:

• Server restart/crash → the formation awaiting sign-off disappears into thin air, invalidating all prior work;
• Multi-process deployment → a formation suspended by process A is invisible to process B, making the pending task impossible to find on the user interface.

Therefore, the suspension context (hierarchical structure, completed conclusions, shared blackboard, existing decisions) is serialized and written to the task_force_runs table:

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

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

4.5 Conflict Detection and Arbitration — Surfacing disagreements instead of averaging them out

The most dangerous failure mode in multi-agent systems is not errors, but several contradictory conclusions being forcibly merged into a smooth, ambiguous statement.

The system performs mutual exclusion checks on all conclusions within a formation (e.g., pass/fail, continue/halt, low risk/high risk). Once opposing conclusions are detected:

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

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

4.6 Three Trigger Channels — Enabling collaboration beyond just when someone asks a question

| Channel | Entry Point | Characteristics |

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

| Dialog Trigger | User asks in dialog box | Human-initiated, real-time |

| Scheduled Trigger | cron / loop | Periodic, e.g., daily reports, inspections |

| Event Trigger | Business system emits events | Passively perceived, e.g., NCR creation, equipment alarms, complaint handling |

Event triggering is the most needed yet most lacking capability for SMEs—because bosses and team leaders won't proactively think to ask AI.

Event targets now support three types: individual employee / individual role / entire cross-role team:

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

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

5. Unified Convergence: Regardless of adjustments, results remain consistent

More collaboration patterns lead to greater front-end fragmentation. Therefore, all levels ultimately converge to the same set of contracts:

// 单个智能体结果
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. Complete API Surface

【行业层】
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. 中小企业落地路径（四阶段，不要一步到位）

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

| Phase | What to Do | User Perception | Barrier |

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

| I. Quick Wins (1–2 weeks) | Select 1 industry + 1 most critical role, run L1/L2 | "Ask a question and get an answer—it really understands our factory" | Only need to configure industry profile |

| II. Role Expansion (1–2 months) | Complete 5–8 roles, clarify human responsibility boundaries | "Each role has an assistant, knows who is responsible for what" | Need to define responsibilities with the enterprise |

3. Cross-Role Closed Loop (2–3 months) | Launch 1–2 L3 Task Forces (recommended to start from customer complaints or line stoppages) | "One issue automatically connects several departments and still knows to come to me for approval" | Requires process consensus |

4. Unattended Operation (ongoing) | Connect to business system events, event → task force → suspend and wait for people | "It keeps working even when no one asks, only notifying me when my approval is needed" | Requires system integration |

Why start with customer complaints/line stoppages: These issues have the strongest pain points, the most obvious cross-departmental impact, and the most measurable results (response time, recovery time), making it easiest for management to see ROI and be willing to continue investment.

8. Honest Gaps to Be Filled

8.1 Closed

8.2 Remaining Gaps

None. The only original pending item, "No timeout/reminder for suspended formations," has been closed in this section (email reminders + scheduled inspections + escalation tagging). See §8.1.

Regarding approval permissions: Upgraded to a dual safeguard of "hard interception + traceability"—unauthorized proxy approvals are blocked at the resumeTaskForce entry point (returning 403 + violations, without persisting to the database or resuming execution), while historical unauthorized records remain auditable via approver ≠ decided_by.

Currently, the "operator identity" is passed in by the frontend/caller as decidedBy (a pragmatic approach in the absence of a unified login system). To integrate with enterprise SSO for true access control, it can be layered on top of this interception mechanism.

9. One-Sentence Summary

The industry provides the coordinate system, the role provides the responsibility, the digital employee provides the capability, the formation provides the collaboration, and the human provides the final signature.

Without any one of these five, AI for SMEs will degenerate into an expensive chat window.

Appendix: Core File Index

Data Tables