1. 组件定位

1.1 核心职责

本组件负责通过六大基础数字员工能力编排43个专业数字员工，结合MTClaw调度引擎与规则引擎双引擎协同，实现工业数据从识别、创建、修复、优化、比对到生成的全链路闭环，达成数据资产化与降本增效。

1.2 核心输入

1. 用户自然语言业务请求（通过 POST /api/agent/chat 或前端页面传入，如"帮我采购伺服电机""优化BOM成本"）
2. SCSAI PLM系统业务对象数据（Part、BOM、Document、Vendor、Project、ECR、ECO等对象的结构化数据）
3. MTClaw Function Router路由信号（L1关键词匹配、L2端侧推理、L3云端兜底三层路由结果）
4. 规则引擎三级防线信号（create_pre双库查重结果、validate必填补全结果、create_post关联完整性结果）
5. 调度器配置信号（SCHEDULER_TYPE、MTCLAW_ENDPOINT、MODEL_PROVIDER等环境变量/配置文件）
6. 数字员工YAML Profile定义（员工ID、能力组合、关键词、MTClaw高频动作、Pipeline流水线、Loop闭环配置）
7. 硬件检测信号（GPU可用性、端侧推理服务可用性，影响模型路由策略）
8. 外部审批系统回调通知（审批通过/驳回结果，触发工作流异步恢复）
9. 多源数据采集信号（SCSAI/数据库/文件/API等数据源的采集触发信号）

1.3 核心输出

1. 返回给用户的业务执行结果（采购订单、BOM成本报告、优化方案、估值报告、内容文档等）
2. 推送给用户的执行进度通知（当前步骤类型标识：模型推理/确定性操作/规则计算/异步等待）
3. 数据审计报告（4维审计：基础完整性→关联完整性→语义质量→生命周期）
4. 数据资产估值报告（三阶段估值：成本法/收益法/市场法，8类资产估值清单）
5. 规则引擎执行记录（create_pre/validate/create_post三级防线通过率、修正详情）
6. MTClaw加速效果指标（端侧~70ms vs 云端~5000ms加速比、L1关键词命中时~200ms vs 原始路径~60s）
7. 数字员工协同事件（onComplete触发链、Pipeline流水线执行记录、Loop闭环迭代记录）
8. PLM系统更新确认（对象创建/修复/优化后的AML提交确认、Sequence更新确认）
9. 全链路闭环演示输出（6阶段真实执行结果：产品创建→BOM生成→商城上架→内容文档→数据资产化→私有化部署）

1.4 职责边界

• 本组件不负责上游LLM的训练与管理，仅在需要推理的步骤中调度其推理能力
• 本组件不负责SCSAI PLM系统的底层数据持久化，仅通过API查询和AML提交与SCSAI交互
• 本组件不负责MTClaw Function Router的模型加载与推理执行，仅通过HTTP接口调用其路由能力
• 本组件不负责用户认证与权限管理，由上游网关处理
• 本组件不负责审批流程的定义与管理，仅通过push_approval推送和等待审批结果回调
• 本组件不负责前端UI的渲染逻辑，前端通过统一API入口交互
• 本组件不负责外部数据源（1688/阿里巴巴等电商平台）的数据采集，采购数字员工仅模拟询价流程
• 本组件不负责数字员工YAML Profile的运行时动态修改，Profile在启动时加载，修改需重启服务

2. 领域术语

数字员工（Digital Staff）

: 基于六大基础能力（识别/创建/修复/优化/比对/生成）组合编排的智能Agent，每个数字员工对应一个特定的业务角色，通过YAML Profile定义其能力组合、关键词、Pipeline流水线。

六大基础能力（Six Core Capabilities）

: 识别师（identify）、创建师（create）、修复师（repair）、优化师（optimize）、比对师（compare）、生成师（generate）——构成数字员工能力的原子单元，所有43个专业数字员工均由这六种能力的特定组合构成。

识别师（Identifier）

: 执行4维审计（基础完整性→关联完整性→语义质量→生命周期），输出审计报告的基础能力。对应CapabilityRuntime的identify方法。

创建师（Creator）

: 执行语义解析→查L1标准库→创建对象类/实例→强制完整创建→关联建模→入库为L1标准资产的基础能力。对应CapabilityRuntime的create方法，流程为：规则引擎create_pre→validate→组装AML→提交SCSAI→create_post。

修复师（Repairer）

: 执行三级修复策略的基础能力：Tier1自动修复（规则引擎直接修正）+Tier2建议确认（生成修复建议，用户确认后执行）+Tier3仅建议（仅输出建议，不自动执行）。对应CapabilityRuntime的repair方法。

优化师（Optimizer）

: 执行描述润色→命名规范化→分类精化→关联补强→同类对比的基础能力。对应CapabilityRuntime的optimize方法。

比对师（Comparator）

: 执行三种比对模式的基础能力：对象vs L1标准、对象vs同类最佳、对象vs历史版本。对应CapabilityRuntime的compare方法。

生成师（Generator）

: 执行拉对象全量数据→查同类生成模板→生成→用户确认→输出并关联的基础能力。对应CapabilityRuntime的generate方法。

Pipeline流水线（Capability Pipeline）

: 数字员工的多步骤能力执行链，按顺序串联多个基础能力。例如供应链管家的Pipeline为：identify→repair→generate。

Loop闭环引擎（Loop Engine）

: 数字员工的持续执行机制，支持三种模式：监控型Loop（条件触发持续监控）、目标驱动型Loop（目标达成后执行动作）、自修复型Loop（自动修复+验证循环）。

MTClaw三层路由（MTClaw Three-Layer Routing）

: MTClaw Function Router的请求路由策略：L1关键词匹配（<5ms）→L2端侧推理（~70ms）→L3云端兜底（~5s）。命中L1时响应时间约200ms，相比原始路径60s实现300倍加速。

规则引擎三级防线（Rule Engine Three-Level Defense）

: 对象创建流程中的三道质量保障：create_pre（双库查重，防止重复创建）→validate（必填补全，确保数据完整）→create_post（关联完整性，确保关系建立）。目标通过率89%+。

L1标准资产（L1 Standard Asset）

: 经过完整创建流程、通过规则引擎三级防线、关联完整性校验通过的高质量数据资产。当前存量10万+，目标1000万+。

L2待治理准资产（L2 Pending Asset）

: 已入库但未通过完整质量校验的数据资产，约176万条，需通过修复师/优化师治理后升级为L1标准资产。

CapabilityRuntime

: 六大基础能力的统一运行时SDK，将L2层基础能力包装为统一接口供L3业务员工调用。执行策略：规则引擎优先→条件匹配→LLM（仅当规则不足时）。

SmartLLMRouter

: LLM智能路由层，将任务分为Worker（端侧小模型处理简单任务）和Solver（云端大模型处理复杂任务），IntentType从18种扩展到36种。

加速比（Acceleration Ratio）

: MTClaw混合调度相比全量云端推理的加速指标。真实测量：端侧~70ms vs 云端~5000ms ≈ 74倍；AI对话×MTClaw前置路由：命中时~200ms vs 原始路径~60s。

数据资产估值（Data Asset Valuation）

: 对数据资产执行三阶段估值：成本法（采集/加工/存储成本）、收益法（预期收益折现）、市场法（同类市场交易参考），生成可入表资产清单。

全链路闭环演示（Full Closed-Loop Demo）

: 6阶段真实执行演示：产品创建（~8s）→BOM生成（~700ms）→商城上架（~72ms）→内容+文档（~84ms）→数据资产化（8类资产估值¥150,000）→私有化部署。禁止Mock数据。

Mock数据检测（Mock Data Detection）

: 通过关键词扫描（mock/测试/示例/dummy/placeholder/fake/sample等）自动识别执行结果中是否包含虚假数据，确保演示真实性。

环境自适应（Environment Adaptive）

: 系统根据硬件环境自动切换推理策略：有GPU时使用端侧模型（Qwen等），无GPU时自动切换云端DeepSeek，调度逻辑不变。

SchedulerFactory

: 根据配置和运行时环境自动创建合适调度器实例的工厂组件。检测MTClaw服务可用性和GPU硬件状态，决定创建MTClawScheduler或BuiltinScheduler实例。

YAML Profile

: 数字员工的声明式配置文件，定义员工ID、名称、能力组合、关键词、MTClaw配置、Pipeline流水线、Loop闭环、协同事件等。作为配置真相源，DB作为运行时真相源。

协同事件（Collaboration Event）

: 数字员工之间的触发联动机制，onComplete配置定义当前员工完成后触发目标员工的条件、任务类型和负载参数。

3. 角色与边界

3.1 核心角色

• 工艺工程师：通过自然语言发起工艺优化请求的制造企业人员，触发16步工艺优化工作流
• 采购工程师：通过自然语言发起采购请求的人员，触发采购数字员工的询价/比价/订单流程
• 成本分析师：发起BOM成本优化请求的人员，触发成本优化师的替代料推荐和成本报告生成
• 数据管理员：负责数据资产巡检、修复、估值、入库的数据治理人员
• 内容运营：发起内容生成请求的市场部人员，触发内容生成师的公众号文章/海报/说明书生成
• 审批人：接收业务方案审批通知的管理人员，审批通过后工作流自动恢复
• 系统管理员：管理调度器配置、监控数字员工运行状态、处理异常实例的技术人员
• 部署运维人员：负责MTClaw服务部署、GPU硬件配置、环境变量设置的基础设施管理人员
• 企业老板：查看经营日报、数据资产估值报告、全链路闭环演示结果的决策者

3.2 外部系统

• SCSAI PLM系统：产品生命周期管理系统，存储Part/BOM/Document/Vendor/Project/ECR/ECO等业务对象，本组件通过REST API查询和AML提交与其交互
• MTClaw Function Router：工作流调度服务（:18790），提供三层路由能力（L1关键词/L2端侧推理/L3云端兜底），本组件通过OpenAI-compatible接口调用
• 上游LLM服务：提供通用推理能力的LLM端点，端侧模型（Qwen/Gemma等）或云端模型（DeepSeek/豆包Pro），用于模型推理步骤
• 审批系统：外部审批流程系统，push_approval工具的下游依赖，审批结果通过回调通知工作流恢复
• 飞书/邮件通知服务：消息推送通道，用于发送采购预警、库存预警、经营日报等业务通知
• SmartLLMRouter：LLM智能路由服务，将任务分为Worker/Solver两层调度，IntentType扩展到36种
• SQLite数据库：本地数据存储，包含4张数字员工表、规则引擎表、资产估值表等

3.3 交互上下文

@startuml
left to right direction

actor "工艺工程师" as Engineer
actor "采购工程师" as Buyer
actor "成本分析师" as Analyst
actor "数据管理员" as DataAdmin
actor "内容运营" as ContentOps
actor "审批人" as Approver
actor "企业老板" as Boss
actor "系统管理员" as Admin

rectangle "BossAgents\n(工业界的Cursor)" as System {
    usecase "六大基础能力\n识别/创建/修复/优化/比对/生成" as SixCaps
    usecase "43个专业数字员工\n(Pipeline+Loop+协同)" as Staff43
    usecase "规则引擎三级防线\ncreate_pre/validate/create_post" as RuleEngine
    usecase "MTClaw×BossAgents\n双引擎协同" as DualEngine
    usecase "全链路闭环演示\n6阶段真实执行" as Demo
}

cloud "SCSAI PLM" as SCSAI
cloud "MTClaw\nFunction Router" as MTClaw
cloud "上游LLM\n(端侧/云端)" as LLM
cloud "审批系统" as Approval
cloud "飞书/邮件" as Notify

Engineer --> Staff43 : "优化工艺，降本增效"
Buyer --> Staff43 : "帮我采购伺服电机"
Analyst --> Staff43 : "分析BOM成本"
DataAdmin --> Staff43 : "巡检数据健康"
ContentOps --> Staff43 : "生成公众号文章"
Approver --> Approval : 审批通过/驳回
Boss --> Demo : 查看经营日报/估值报告
Admin --> DualEngine : 调度器配置/监控

Staff43 --> SixCaps : 调用基础能力
SixCaps --> RuleEngine : 规则优先
SixCaps --> LLM : 规则不足时降级
Staff43 --> MTClaw : 高频确定性操作加速
Staff43 --> SCSAI : 查询/创建/修复对象
Staff43 --> Approval : 推送审批
Staff43 --> Notify : 发送通知
Approval --> Staff43 : 审批结果回调
Demo --> Staff43 : 编排6阶段执行
@enduml

4. DFX约束

4.1 性能

1. MTClaw L1关键词匹配响应时间必须 ≤ 5ms
2. MTClaw L2端侧推理响应时间必须 ≤ 100ms（真实测量~70ms）
3. MTClaw L3云端兜底响应时间必须 ≤ 10s（真实测量~5s）
4. 端侧vs云端加速比必须 ≥ 50x（真实测量~74x）
5. AI对话×MTClaw前置路由命中时响应时间必须 ≤ 500ms（真实测量~200ms）
6. AI对话×MTClaw前置路由命中时vs原始路径加速比必须 ≥ 100x（真实测量~300x）
7. 规则引擎单条规则执行时间必须 ≤ 50ms
8. 规则引擎三级防线（create_pre+validate+create_post）总执行时间必须 ≤ 500ms
9. CapabilityRuntime规则引擎命中时响应时间必须 ≤ 200ms
10. CapabilityRuntime LLM降级时响应时间必须 ≤ 15s
11. Worker（小模型）响应时间必须 ≤ 500ms（真实测量~70ms）
12. Solver（大模型）响应时间必须 ≤ 30s
13. 全链路闭环演示6阶段总执行时间必须 ≤ 60s
14. 产品创建阶段响应时间必须 ≤ 15s（真实测量~8s）
15. BOM生成阶段响应时间必须 ≤ 2s（真实测量~700ms）
16. 商城上架阶段响应时间必须 ≤ 500ms（真实测量~72ms）
17. 内容+文档生成阶段响应时间必须 ≤ 1s（真实测量~84ms）
18. 数字员工注册加载初始化时间必须 ≤ 3s
19. MTClaw可用性健康检测响应时间必须 ≤ 2s
20. GPU可用性检测响应时间必须 ≤ 1s

4.2 可靠性

1. 规则引擎三级防线通过率必须 ≥ 89%
2. MTClaw不可用时，SchedulerFactory必须自动降级到BuiltinScheduler，降级切换时间必须 ≤ 3s
3. 无GPU时必须自动切换云端DeepSeek，切换时间必须 ≤ 5s
4. 工作流状态必须持久化，进程重启后可从最近检查点恢复
5. 异步挂起的工作流实例必须在7天内可恢复
6. 审批回调与挂起上下文必须校验匹配性，防止错误恢复
7. PLM系统写入必须保证数据一致性，AML提交失败时不得产生脏数据
8. LLM调用失败时必须自动降级（Worker失败→Solver，端侧失败→云端）
9. 连续降级≥5次必须触发熔断器，自动禁用故障链路
10. Mock数据检测必须覆盖所有演示输出，禁止Mock数据出现在真实执行结果中
11. 全链路闭环演示必须使用真实数据，禁止Mock

4.3 安全性

1. 所有LLM API调用必须通过API Key鉴权
2. API Key必须通过环境变量引用，禁止明文存储在代码或配置文件中
3. 工具调用参数必须经过Schema校验，禁止注入攻击
4. 异步恢复回调必须携带签名验证，防止伪造审批回调
5. PLM系统写入操作必须通过审批后才能执行
6. 工具调用必须通过内部网络（127.0.0.1），禁止暴露到公网
7. 规则引擎脚本执行必须在安全沙箱（vm.createContext）中运行，限制全局访问
8. 数据资产估值报告必须标记"真实测量"或"模型估算"，禁止编造估值数据

4.4 可维护性

1. 每次数字员工执行必须记录结构化日志（员工ID、能力类型、执行来源：规则引擎/LLM、耗时、状态）
2. 必须支持debug日志模式，记录完整的工具调用参数和返回值
3. 规则引擎审计记录必须保留最近500条，支持按scope和时间范围查询
4. 新增数字员工只需在YAML Profile中添加定义，禁止修改核心代码
5. 新增规则只需在规则引擎DB中添加记录，支持从AML文件自动生成
6. 调度器类型切换必须通过环境变量/配置文件驱动，禁止修改代码
7. 必须提供调度器状态查询接口（GET /api/scheduler/status），返回调度器类型、模型提供商、运行状态
8. 必须提供数字员工列表查询接口（GET /api/digital-staff/），返回员工ID、名称、状态、能力组合
9. 必须记录MTClaw加速效果指标（确定性操作节省的推理时间、加速比、L1/L2/L3命中分布）
10. 必须提供全链路闭环演示可视化界面，展示6阶段进度和真实执行耗时
11. Mock数据检测必须作为演示流程的内置环节，自动扫描执行结果

4.5 兼容性

1. MTClaw Function Router接口必须兼容OpenAI function calling格式
2. 统一API入口（POST /api/agent/chat）必须对前端完全透明，前端不感知调度器类型
3. 必须能在MTT AIBOOK（AIOS 1.4.2 / Ubuntu 22.04）上直接运行
4. 必须能在无GPU环境（纯CPU服务器）上运行，自动切换云端模型
5. 数字员工YAML Profile必须支持从SQLite DB同步加载，YAML为配置真相源，DB为运行时真相源
6. SCSAI PLM接口必须兼容SCSAI Agent REST API
7. 通知接口必须兼容飞书Webhook和SMTP邮件两种方式
8. 四种部署场景（MTClaw+GPU/MTClaw无GPU/无MTClaw+GPU/无MTClaw无GPU）下的用户API入口和响应格式必须完全一致

5. 核心能力

5.1 六大基础数字员工能力

5.1.1 业务规则

1. 识别师4维审计规则：识别师必须按顺序执行4维审计，每维审计必须输出评分和问题清单

a. 验收条件：[对Part对象执行identify能力] → [依次输出基础完整性评分→关联完整性评分→语义质量评分→生命周期评分，以及对应问题清单]

1. 创建师强制完整创建规则：创建师必须通过规则引擎三级防线确保对象完整创建，禁止跳过任何防线

a. 验收条件：[创建Part对象] → [依次执行create_pre（双库查重）→validate（必填补全）→组装AML→提交SCSAI→create_post（关联完整性），任一防线失败则中止并返回具体原因]

1. 修复师三级修复策略规则：修复师必须根据问题严重程度自动选择修复层级

a. 验收条件：[字段缺失等简单问题] → [Tier1自动修复，直接修正并返回结果]

a. 验收条件：[需要业务判断的问题] → [Tier2建议确认，生成修复建议，等待用户确认后执行]

a. 验收条件：[需要人工决策的复杂问题] → [Tier3仅建议，输出建议但不自动执行]

1. 优化师五步优化规则：优化师必须按顺序执行五步优化流程

a. 验收条件：[对Vendor对象执行optimize能力] → [依次执行描述润色→命名规范化→分类精化→关联补强→同类对比，输出优化前后对比报告]

1. 比对师三种比对模式规则：比对师必须支持三种比对模式，用户可指定或由系统自动选择

a. 验收条件：[指定mode=standard] → [执行对象vs L1标准比对，输出偏差清单]

a. 验收条件：[指定mode=peer] → [执行对象vs同类最佳比对，输出差距分析]

a. 验收条件：[指定mode=history] → [执行对象vs历史版本比对，输出变更轨迹]

1. 生成师确认后输出规则：生成师必须在用户确认后才输出最终结果并建立关联

a. 验收条件：[执行generate能力生成说明书] → [先展示生成预览，用户确认后才正式输出并关联到源对象]

1. CapabilityRuntime规则优先规则：六大基础能力必须优先使用规则引擎执行，仅当规则不足时才降级到LLM

a. 验收条件：[执行identify能力且规则引擎有匹配规则] → [规则引擎直接返回结果，耗时≤200ms，不调用LLM]

a. 验收条件：[执行identify能力且规则引擎无匹配规则] → [降级到LLM推理，耗时≤15s，标记source=llm_fallback]

1. 禁止项：禁止在规则引擎可处理的场景下调用LLM

a. 验收条件：[db_query/check_inventory/validate_record等确定性操作] → [必须走规则引擎或MTClaw加速，禁止走LLM]

5.1.2 交互流程

@startuml
actor "用户" as User
participant "CapabilityRuntime" as CR
participant "规则引擎" as RE
participant "MTClaw" as MT
participant "LLM Router" as LLM

User -> CR : 调用基础能力(identify/create/repair/optimize/compare/generate)
CR -> RE : 查询匹配规则
alt 规则命中
    RE -> CR : 返回规则执行结果(≤200ms)
    CR -> User : 返回结果(source=rule_engine)
else 规则未命中
    CR -> MT : 检查MTClaw高频动作
    alt MTClaw可加速
        MT -> CR : 返回加速结果(≤100ms)
        CR -> User : 返回结果(source=mtclaw_accelerated)
    else 需要LLM推理
        CR -> LLM : Worker/Solver路由
        LLM -> CR : 返回推理结果(≤15s)
        CR -> User : 返回结果(source=llm_fallback)
    end
end
@enduml

5.1.3 异常场景

1. 规则引擎初始化失败

a. 触发条件：规则引擎DB文件不存在或损坏

b. 系统行为：记录错误日志，降级到LLM执行所有能力

c. 用户感知：响应时间变长（从≤200ms变为≤15s），日志标记source=llm_fallback_no_rule_engine

1. MTClaw服务不可用

a. 触发条件：MTClaw Function Router(:18790)连接超时或返回5xx

b. 系统行为：跳过MTClaw加速，直接走LLM Router，记录降级次数

c. 用户感知：响应时间变长，调度器状态显示mtclaw_available=false

1. LLM API调用超时

a. 触发条件：Worker超时(>5s)或Solver超时(>30s)

b. 系统行为：Worker失败自动降级到Solver，Solver失败返回错误，触发熔断器计数

c. 用户感知：错误码LLM_TIMEOUT，建议稍后重试

1. 规则引擎脚本执行异常

a. 触发条件：规则中的JavaScript脚本语法错误或运行时异常

b. 系统行为：在安全沙箱中捕获异常，记录错误规则ID，跳过该规则继续执行

c. 用户感知：该规则未生效，日志标记rule_execution_error

5.2 43个专业数字员工编排

5.2.1 业务规则

1. 数字员工定义规则：每个专业数字员工必须由YAML Profile定义，包含ID、名称、能力组合、关键词、MTClaw配置

a. 验收条件：[新增数字员工DS-NEW-001] → [在local.yaml中添加staff条目，重启服务后可通过GET /api/digital-staff/查询到]

1. Pipeline流水线编排规则：数字员工可通过pipeline字段定义多步骤能力执行链，按顺序串联执行

a. 验收条件：[供应链管家执行] → [依次执行identify(Vendor,问题供应商)→repair(Vendor,修复建议)→generate(ActionItem,预警)，每步输出传递给下一步]

1. Loop闭环引擎规则：数字员工可通过loop字段定义持续执行机制，支持三种模式

a. 验收条件：[价格监控员(DS-LOOP-001)每天9点检查] → [满足涨价>5%条件时触发identify→compare→generate流水线]

a. 验收条件：[目标追踪员(DS-LOOP-001)每天18点检查] → [月销售额≥100万时发送庆功通知，未达成时提醒差距]

a. 验收条件：[数据修复员(DS-LOOP-001)每天2点执行] → [自动修复供应商缺失字段，修复后再次校验，最多重试3次]

1. 协同事件触发规则：数字员工可通过collaboration.onComplete定义完成后触发其他员工

a. 验收条件：[经营大脑(DS-BIZ-001)执行完成且result.success=true] → [自动触发报告分析师(DS-REPORT-001)发送邮件]

1. MTClaw员工级配置规则：每个数字员工可独立配置mtclaw_enabled和mtclaw_high_frequency_actions

a. 验收条件：[采购助手(DS-PROC-001)的mtclaw_high_frequency_actions包含db_query/check_inventory] → [这些动作走MTClaw加速，其他动作走正常路径]

1. 数字员工领域覆盖规则：43个数字员工必须覆盖采购/BOM/工艺/质量/设备/内容/营销/成本/项目/芯片/数据资产等10+领域

a. 验收条件：[按department统计数字员工分布] → [覆盖IT部、采购部、市场部、质量部、工艺部、财务部、数据部、工程部、设备部、项目部、芯片设计部、知识部、行政部等]

1. 禁止项：禁止数字员工在YAML Profile中定义循环依赖的协同事件

a. 验收条件：[DS-A的onComplete触发DS-B，DS-B的onComplete触发DS-A] → [启动时检测并拒绝循环依赖，返回配置错误提示]

5.2.2 交互流程

@startuml
actor "用户" as User
participant "数字员工调度器" as Scheduler
participant "YAML Profile" as Profile
participant "CapabilityRuntime" as CR
participant "协同调度器" as Collab

User -> Scheduler : "帮我采购伺服电机"
Scheduler -> Profile : 匹配关键词→DS-PROC-001
Profile -> Scheduler : 返回员工配置(pipeline/mtclaw/params)
Scheduler -> CR : 执行pipeline步骤1: identify
CR -> Scheduler : 返回供应商列表
Scheduler -> CR : 执行pipeline步骤2: compare
CR -> Scheduler : 返回比价结果
Scheduler -> CR : 执行pipeline步骤3: generate
CR -> Scheduler : 返回采购订单
Scheduler -> User : 返回执行结果

alt 有协同事件
    Scheduler -> Collab : 检查onComplete条件
    Collab -> Scheduler : 触发目标员工
end
@enduml

5.2.3 异常场景

1. 关键词匹配冲突

a. 触发条件：用户输入同时匹配多个数字员工的关键词

b. 系统行为：按YAML定义顺序选择第一个匹配的员工，记录冲突日志

c. 用户感知：执行第一个匹配员工的能力，日志标记keyword_conflict

1. Pipeline步骤执行失败

a. 触发条件：Pipeline中某一步能力执行返回success=false

b. 系统行为：中止后续步骤，返回已执行步骤的结果和失败原因

c. 用户感知：部分结果+失败步骤的错误信息

1. Loop闭环超过最大迭代次数

a. 触发条件：Loop执行次数超过max_iterations限制

b. 系统行为：停止Loop，记录迭代次数和最终状态

c. 用户感知：收到闭环停止通知，包含已完成的迭代结果

5.3 规则引擎三级防线

5.3.1 业务规则

1. create_pre双库查重规则：对象创建前必须执行create_pre规则，同时查询L1标准资产库和L2待治理库，防止重复创建

a. 验收条件：[创建Part对象"伺服电机-A型"] → [create_pre查询L1和L2库，发现已存在同名对象] → [返回查重命中信息，阻止重复创建]

1. validate必填补全规则：create_pre通过后必须执行validate规则，检查必填字段完整性，自动补全可推导字段

a. 验收条件：[创建Part对象缺少description字段] → [validate检测到必填缺失，尝试从规则推导补全] → [补全成功则继续，补全失败则返回缺失字段清单]

1. create_post关联完整性规则：对象创建成功后必须执行create_post规则，确保关联关系建立完整

a. 验收条件：[创建Part对象成功，AML提交SCSAI返回item_id] → [create_post检查Part与BOM/Document的关联关系，自动建立缺失关联]

1. 三级防线通过率规则：三级防线整体通过率必须 ≥ 89%

a. 验收条件：[统计最近100次对象创建] → [create_pre通过率+validate通过率+create_post通过率的加权平均 ≥ 89%]

1. 规则作用域分类规则：规则必须按scope分类存储和执行，支持identify/create/create_pre/create_post/repair/optimize/compare/validate/generate/inspect共10个作用域

a. 验收条件：[查询scope=create_pre的规则] → [仅返回create_pre作用域的规则列表]

1. 规则工厂自动生成规则：规则引擎必须支持从sciot_properties自动生成所有ItemType的规则（全覆盖）

a. 验收条件：[新增ItemType"CustomPart"到sciot_properties] → [规则工厂自动生成identify/create/validate等全套规则]

1. 禁止项：禁止跳过create_pre直接执行validate，禁止跳过validate直接执行create_post

a. 验收条件：[对象创建流程] → [必须严格按create_pre→validate→create_post顺序执行，任何防线不可跳过]

5.3.2 交互流程

@startuml
actor "用户" as User
participant "CapabilityRuntime" as CR
participant "规则引擎" as RE
participant "SCSAI PLM" as SCSAI

User -> CR : 创建对象(Part, data)
CR -> RE : execute('create_pre', {item_type, data})
RE -> RE : 双库查重(L1标准库+L2待治理库)
alt 查重命中
    RE -> CR : 返回重复对象信息
    CR -> User : 错误：对象已存在
else 查重通过
    RE -> CR : create_pre通过
    CR -> RE : execute('validate', {item_type, data})
    RE -> RE : 必填检查+自动补全
    alt 必填缺失且无法补全
        RE -> CR : 返回缺失字段清单
        CR -> User : 错误：缺少必填字段
    else 校验通过
        RE -> CR : validate通过
        CR -> SCSAI : 组装AML并提交
        SCSAI -> CR : 返回item_id
        CR -> RE : execute('create_post', {item_type, data, item_id})
        RE -> RE : 关联完整性检查+自动关联
        RE -> CR : create_post通过
        CR -> User : 创建成功
    end
end
@enduml

5.3.3 异常场景

1. create_pre查重服务不可用

a. 触发条件：L1标准库或L2待治理库查询超时

b. 系统行为：降级为仅查本地缓存，标记查重结果为"降级模式"

c. 用户感知：创建流程继续，但日志标记dedup_degraded=true

1. validate规则冲突

a. 触发条件：同一字段有多条validate规则且结论矛盾

b. 系统行为：按规则优先级执行，高优先级规则覆盖低优先级

c. 用户感知：以高优先级规则结果为准

1. create_post关联建立失败

a. 触发条件：关联目标对象不存在或SCSAI写入失败

b. 系统行为：记录关联失败日志，不阻塞主流程（create_post为非阻塞）

c. 用户感知：对象创建成功，但部分关联缺失，日志标记post_association_failed

5.4 MTClaw × BossAgents 双引擎协同

5.4.1 业务规则

1. 三层路由规则：MTClaw Function Router必须按L1→L2→L3顺序路由请求，命中上层则不再向下路由

a. 验收条件：[请求"查询库存水位"] → [L1关键词匹配命中check_inventory，<5ms返回结果]

a. 验收条件：[请求"分析供应商绩效趋势"] → [L1未命中，L2端侧推理路由到vendor_review，~70ms返回]

a. 验收条件：[请求"生成工艺优化方案"] → [L1/L2均未命中，L3云端兜底路由到DeepSeek，~5s返回]

1. 加速比真实测量规则：所有加速比数据必须标注"真实测量"，禁止编造

a. 验收条件：[展示端侧vs云端加速比] → [必须标注"真实测量：端侧~70ms vs 云端~5000ms ≈ 74x"，禁止使用"约""大约"等模糊词]

1. AI对话×MTClaw前置路由规则：AI对话请求必须先经过MTClaw L1关键词预筛选+精确动作映射

a. 验收条件：[AI对话"帮我采购伺服电机"] → [L1关键词预筛选命中procurement_assistant，精确动作映射到DS-PROC-001，~200ms返回]

a. 验收条件：[AI对话"分析工艺瓶颈原因"] → [L1未命中，走原始LLM路径，~60s返回]

1. 互补协同规则：BossAgents规则引擎与MTClaw调度引擎是互补协同关系，不是替代关系

a. 验收条件：[确定性操作(db_query/check_inventory)] → [规则引擎直接处理，不走MTClaw]

a. 验收条件：[高频确定性操作且规则引擎无直接规则] → [走MTClaw L1/L2加速]

a. 验收条件：[复杂推理任务] → [走MTClaw L3云端或LLM Router Solver]

1. 降级路径规则：MTClaw不可用时必须有降级路径，确保业务不中断

a. 验收条件：[MTClaw服务(:18790)不可用] → [SchedulerFactory自动降级到BuiltinScheduler，所有请求走LLM Router]

1. 环境自适应规则：系统必须根据硬件环境自动切换推理策略

a. 验收条件：[检测到GPU可用] → [使用端侧模型(Qwen/Gemma)，Worker走本地Ollama]

a. 验收条件：[检测到GPU不可用] → [自动切换云端DeepSeek，Worker走DeepSeek API]

1. 禁止项：禁止在MTClaw可用时绕过三层路由直接走云端推理

a. 验收条件：[MTClaw服务可用且L1/L2可命中] → [必须走MTClaw加速路径，禁止直接调用云端LLM]

5.4.2 交互流程

@startuml
actor "用户" as User
participant "BossAgents\n调度器" as BA
participant "MTClaw\nFunction Router" as MT
participant "规则引擎" as RE
participant "LLM Router" as LLM

User -> BA : "查询库存水位"
BA -> RE : 规则引擎查询
alt 规则命中
    RE -> BA : 直接返回(≤200ms)
else 规则未命中
    BA -> MT : MTClaw三层路由
    alt L1关键词命中
        MT -> BA : 精确动作映射(<5ms)
    else L2端侧推理命中
        MT -> BA : 端侧推理结果(~70ms)
    else L3云端兜底
        MT -> BA : 云端推理结果(~5s)
    end
end
BA -> User : 返回结果

== MTClaw不可用降级路径 ==

User -> BA : "查询库存水位"(MTClaw不可用)
BA -> RE : 规则引擎查询
alt 规则命中
    RE -> BA : 直接返回
else 规则未命中
    BA -> LLM : Worker/Solver路由
    LLM -> BA : LLM推理结果
end
BA -> User : 返回结果(降级模式)
@enduml

5.4.3 异常场景

1. MTClaw L1/L2/L3全部未命中

a. 触发条件：请求无法匹配任何MTClaw工具定义

b. 系统行为：透传到上游LLM模型，标记route_fallback=cloud

c. 用户感知：响应时间较长(~5s)，结果来源标记为云端LLM

1. 端侧推理服务崩溃

a. 触发条件：Ollama/摩尔线程等端侧服务进程异常退出

b. 系统行为：InferenceServiceDetector自动探测失败，LLM Router自动切换到云端Solver

c. 用户感知：响应时间从~70ms变为~5s，日志标记edge_inference_unavailable

1. MTClaw连续降级触发熔断

a. 触发条件：MTClaw调用连续失败≥5次

b. 系统行为：熔断器打开，后续请求直接走LLM Router，60s后尝试半开恢复

c. 用户感知：MTClaw加速暂时不可用，调度器状态显示mtclaw_circuit_breaker=open

5.5 全链路闭环演示

5.5.1 业务规则

1. 禁止Mock数据规则：全链路闭环演示的所有数据必须来自真实执行结果，禁止使用Mock/测试/示例数据

a. 验收条件：[演示完成后扫描所有输出] → [MockDataDetector检测到0个mock关键词，is_mock=false]

1. 6阶段顺序执行规则：全链路闭环必须按6阶段顺序执行，每阶段必须等待上一阶段完成

a. 验收条件：[启动全链路演示] → [依次执行Step1产品创建→Step2 BOM生成→Step3商城上架→Step4内容+文档→Step5数据资产化→Step6私有化部署]

1. 真实耗时标注规则：每个阶段的执行耗时必须标注真实测量值，禁止编造

a. 验收条件：[Step1产品创建完成] → [标注"真实测量：~8s"，禁止标注"约8s"或"预计8s"]

1. 数据资产化估值规则：Step5数据资产化必须执行三阶段估值模型，输出8类资产估值清单

a. 验收条件：[执行数据资产化] → [依次执行成本法→收益法→市场法估值，输出8类资产(Part/BOM/Vendor/Document/ECR/ECO/ProcessSpec/Equipment)的估值结果，总估值¥150,000]

1. 演示可录屏规则：演示页面必须支持直接录屏，无需额外处理

a. 验收条件：[打开演示页面real-exec.html或closed-loop.html] → [页面可直接通过OBS等工具录屏，展示真实执行过程和结果]

1. 加速比展示规则：演示必须展示MTClaw加速效果的真实对比数据

a. 验收条件：[演示页面展示加速比] → [显示"端侧~70ms vs 云端~5000ms ≈ 74x（真实测量）"和"AI对话×MTClaw前置路由：命中时~200ms vs 原始路径~60s（真实测量）"]

1. 禁止项：禁止在演示中使用预生成的静态数据替代实时执行结果

a. 验收条件：[演示执行过程中] → [每个阶段必须实时调用BossAgents API获取结果，禁止从缓存或文件读取预生成数据]

5.5.2 交互流程

@startuml
actor "演示观众" as Viewer
participant "演示页面\n(real-exec.html)" as Page
participant "BossAgents\n(:3006)" as BA
participant "MTClaw\n(:18790)" as MT
participant "SCSAI PLM" as SCSAI

Viewer -> Page : 启动全链路演示
Page -> BA : Step1: 创建Part对象
BA -> SCSAI : 提交AML创建Part
SCSAI -> BA : 返回item_id(~8s)
BA -> Page : Step1完成

Page -> BA : Step2: 生成BOM
BA -> BA : 成本优化师生成物料清单(~700ms)
BA -> Page : Step2完成

Page -> BA : Step3: 商城上架
BA -> BA : 自动生成商品页面+SKU(~72ms)
BA -> Page : Step3完成

Page -> BA : Step4: 内容+文档
BA -> BA : 海报/说明书/宣传册并行生成(~84ms)
BA -> Page : Step4完成

Page -> BA : Step5: 数据资产化
BA -> BA : 三阶段估值(成本法/收益法/市场法)
BA -> Page : 8类资产估值¥150,000

Page -> BA : Step6: 私有化部署
BA -> BA : 从体验到企业专属平台
BA -> Page : Step6完成

Page -> Viewer : 展示6阶段真实执行结果+Mock检测通过
@enduml

5.5.3 异常场景

1. SCSAI PLM连接失败

a. 触发条件：Step1创建Part时SCSAI服务不可用

b. 系统行为：降级为本地SQLite创建，标记SCSAI_degraded=true

c. 用户感知：Step1仍可完成，但标注"SCSAI降级模式"

1. 某阶段执行超时

a. 触发条件：某阶段执行时间超过StageTimeout限制

b. 系统行为：记录超时日志，标记该阶段为timeout，继续执行下一阶段

c. 用户感知：该阶段显示超时，其他阶段正常展示

1. Mock数据检测发现虚假数据

a. 触发条件：MockDataDetector在执行结果中扫描到mock/测试/示例等关键词

b. 系统行为：标记is_mock=true，列出所有mock指标

c. 用户感知：演示结果标记"检测到Mock数据"，列出具体mock字段

5.6 数据资产底座

5.6.1 业务规则

1. L1标准资产管理规则：L1标准资产必须通过完整创建流程（三级防线通过），存量10万+，目标1000万+

a. 验收条件：[查询L1标准资产数量] → [返回≥100,000条记录，每条均通过create_pre+validate+create_post]

1. L2待治理准资产管理规则：L2待治理准资产约176万条，必须通过修复师/优化师治理后升级为L1

a. 验收条件：[对L2资产执行repair能力] → [修复后自动重新执行validate，通过则升级为L1标准资产]

1. 三阶段估值模型规则：数据资产估值必须依次执行成本法→收益法→市场法，输出加权估值

a. 验收条件：[对Part类资产执行valuate能力] → [依次计算成本法估值(采集+加工+存储成本)→收益法估值(预期收益折现)→市场法估值(同类市场参考)，输出加权估值和三阶段明细]

1. 8类资产估值清单规则：估值报告必须覆盖8类资产（Part/BOM/Vendor/Document/ECR/ECO/ProcessSpec/Equipment），总估值¥150,000

a. 验收条件：[执行数据资产化] → [输出8类资产的分别估值和总估值，总估值≈¥150,000]

1. 资产估值持久化规则：估值结果必须持久化到asset_valuations表，支持历史查询

a. 验收条件：[执行估值后查询asset_valuations表] → [可查询到scope/asset_count/cost_value/income_value/market_value/weighted_value/valuated_at等字段]

1. 禁止项：禁止编造估值数据，所有估值必须基于真实数据计算或明确标注"模型估算"

a. 验收条件：[估值报告中的数值] → [必须标注计算方法来源：规则引擎计算/LLM估算/真实测量，禁止无来源的数值]

5.6.2 交互流程

@startuml
actor "数据管理员" as Admin
participant "数据估值师\n(DS-COST-001)" as Valuator
participant "CapabilityRuntime" as CR
participant "规则引擎" as RE
participant "asset_valuations表" as DB

Admin -> Valuator : "对数据资产估值"
Valuator -> CR : 执行pipeline: identify→valuate→generate
CR -> RE : identify: 查询L1/L2资产分布
RE -> CR : 返回资产统计(8类资产数量)
CR -> RE : valuate: 成本法估值
RE -> CR : 返回成本法估值结果
CR -> RE : valuate: 收益法估值
RE -> CR : 返回收益法估值结果
CR -> RE : valuate: 市场法估值
RE -> CR : 返回市场法估值结果
CR -> DB : 持久化估值记录
CR -> RE : generate: 生成估值报告
RE -> CR : 返回估值报告(8类资产+总估值¥150,000)
Valuator -> Admin : 返回估值报告
@enduml

5.6.3 异常场景

1. 估值数据源不完整

a. 触发条件：某类资产(如ECO)在数据库中无记录

b. 系统行为：该类资产估值标记为N/A，其他资产正常估值

c. 用户感知：估值报告中ECO行显示"数据不足，无法估值"

1. 估值规则缺失

a. 触发条件：某类资产无对应的valuate规则

b. 系统行为：降级到LLM估算，标记source=llm_estimated

c. 用户感知：该类资产估值标注"模型估算（非规则引擎计算）"

5.7 六大落地案例

5.7.1 业务规则

1. 案例真实性规则：六大落地案例必须基于真实客户项目，禁止虚构

a. 验收条件：[展示案例列表] → [每个案例包含真实客户名称、项目背景、部署模式、业务效果]

1. 案例覆盖规则：六大案例必须覆盖不同行业和部署场景

a. 验收条件：[统计案例行业分布] → [覆盖农产品加工(麻城将军红)、气象服务(罗田气象局)、文旅(大柴湖移民纪念馆)、电力(某省电力公司)、军工(军工工艺数据修复)、化工(贵州磷化集团)]

1. 案例业务效果量化规则：每个案例必须包含量化的业务效果指标

a. 验收条件：[查看案例详情] → [包含数据治理量、通过率提升、人工节省等量化指标]

1. 禁止项：禁止编造客户案例或夸大业务效果

a. 验收条件：[案例中的量化指标] → [必须标注数据来源：真实测量/客户反馈/内部统计，禁止无来源的量化指标]

5.7.2 交互流程

@startuml
actor "演示观众" as Viewer
participant "BossAgents" as BA

Viewer -> BA : 查看落地案例
BA -> BA : 加载6个案例数据
BA -> Viewer : 展示案例列表

Viewer -> BA : 查看案例详情(麻城将军红)
BA -> Viewer : 展示：客户背景+部署模式+业务效果+数据治理量
@enduml

5.7.3 异常场景

1. 案例数据加载失败

a. 触发条件：案例数据文件缺失或格式错误

b. 系统行为：显示可加载的案例，跳过失败案例，记录错误日志

c. 用户感知：案例列表显示部分案例，失败案例显示"数据加载失败"

6. 数据约束

6.1 数字员工（Digital Staff）

1. id：全局唯一标识，格式DS-{领域}-{序号}，如DS-PROC-001、DS-COST-001、DS-CHIP-001，必须大写
2. name：中文名称，格式"小智-{角色名}"，如"小智-采购助手"，不超过20字
3. title：职位名称，如"智能采购工程师"，不超过30字
4. description：功能描述，必须说明该员工的核心业务能力和触发场景
5. capability：主能力标识，必须为identify/create/repair/optimize/compare/generate/validate/inspect/valuate/collect之一
6. llm：是否需要LLM参与，布尔值，llm=false的员工必须完全由规则引擎驱动
7. mtclaw_enabled：是否启用MTClaw加速，布尔值
8. mtclaw_high_frequency_actions：MTClaw高频动作列表，每个动作必须与MTClaw工具定义中的action_name对应
9. keywords：关键词列表，用于自然语言匹配，必须包含中英文关键词
10. pipeline：能力流水线定义，按顺序列出capability+item_types+params
11. loop：闭环引擎配置，包含enabled/trigger/condition/action/max_iterations
12. collaboration：协同事件配置，包含onComplete触发条件和目标员工
13. department：所属部门，必须与组织架构一致
14. enabled：是否启用，布尔值，disabled的员工不参与调度

6.2 规则引擎规则（Rule）

1. scope：规则作用域，必须为identify/create/create_pre/create_post/repair/optimize/compare/validate/generate/inspect之一
2. item_type：适用的对象类型，如Part/BOM/Vendor/Document/ECR/ECO等
3. condition：触发条件，JavaScript表达式，在安全沙箱中执行
4. action_config：执行动作配置，JSON对象，包含修正/补全/关联等动作定义
5. priority：优先级，整数，数值越大优先级越高，冲突时高优先级覆盖低优先级
6. enabled：是否启用，布尔值
7. source：规则来源，必须为aml_generated/SCSAI_native/manual/rule_factory之一
8. tags：标签列表，JSON数组或逗号分隔文本

6.3 数据资产估值（Asset Valuation）

1. scope：估值范围，如Part/BOM/Vendor/Document或all
2. asset_count：估值范围内的资产数量，正整数
3. cost_value：成本法估值，数值，单位元
4. cost_breakdown：成本法估值明细，JSON对象
5. income_value：收益法估值，数值，单位元
6. income_breakdown：收益法估值明细，JSON对象
7. market_value：市场法估值，数值，单位元
8. market_breakdown：市场法估值明细，JSON对象
9. weighted_value：加权估值，数值，单位元，由三种方法加权计算
10. weights：权重配置，JSON对象，如{"cost":0.3,"income":0.4,"market":0.3}
11. rule_engine_used：是否使用规则引擎计算，布尔值
12. rule_params：规则引擎参数，JSON对象
13. valuated_at：估值时间，ISO 8601格式时间戳

6.4 MTClaw加速统计（MTClaw Stats）

1. total_calls：MTClaw总调用次数，非负整数
2. accelerated_calls：MTClaw加速命中次数，非负整数
3. degraded_calls：MTClaw降级次数，非负整数
4. failed_calls：MTClaw调用失败次数，非负整数
5. avg_duration_ms：MTClaw调用平均耗时，非负数值，单位毫秒
6. l1_hits：L1关键词匹配命中次数，非负整数
7. l2_hits：L2端侧推理命中次数，非负整数
8. l3_hits：L3云端兜底命中次数，非负整数
9. acceleration_ratio：加速比，数值，=云端平均耗时/MTClaw平均耗时

6.5 全链路演示结果（Demo Result）

1. stages：6阶段执行结果数组，每项包含stage_id/stage_name/duration_ms/status/result
2. total_duration_ms：6阶段总耗时，非负整数，单位毫秒
3. mock_detection：Mock数据检测结果，包含is_mock(boolean)/mock_indicators(数组)
4. report_path：演示报告文件路径
5. stage.duration_ms：每阶段真实执行耗时，必须标注"真实测量"
6. stage.status：每阶段执行状态，必须为success/timeout/error之一