BossAgents × PLM 底座 · 通用技能集成框架 v2（对齐代码现实）

修订说明：v1 由不懂代码现状的人撰写，把"采购比价"当成待建的首个实例，并引入了与现有体系平行的两套话术（"技能"vs"worker"、新建数据资产中心 vs 既有 unified-asset-service）。v2 的任务是把框架落回 BossAgents 真实代码：已有 86 个 worker、已有 DS-PROC-001 采购助手、已有 procurement-workflow-v3 编排、已有 unified-asset-service 聚合层。底座不是从零建，是把既有资产"收纳"进通用范式，并补齐真正缺的那几块。

01 结论先行（已校正）

BossAgents 要的不是"采购做一套、设备运维又做一套"，而是一个先有事实底座、后按场景插拔配置的通用技能框架。但 v1 漏了一个前提：事实底座已经存在一半。

一句话：

• 通用底座的"运行时/注册/编排"能力，现有 worker + STAFF_DEFAULTS + CapabilityRuntime + procurement-workflow-v3 已经部分实现，必须先盘点收纳，不能假装绿地重造。
• "技能"= worker 对外暴露的能力单元（一个 worker 可声明多个技能）。注册表登记的是 worker/tool，不是另起一套对象模型。
• 采购比价是第一个已上线的实例（DS-PROC-001），它验证的是"采购这件事能跑通"；真正的底座验证，是看设备运维/质量/工艺能否用同一套注册+编排机制、只换配置包接进来——目前这步还没做，所以"底座通了"是待验证，不是已验证。

02 设计原则（补充"先盘点既有资产"）

v1 对比了"一套场景一套" vs "通用底座+插拔"，方向对。补一条最关键的：

| 维度 | v1 错误前提 | v2 校正 |

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

| 起点 | 底座从零建，采购是第一个实例 | 底座已有 worker/CapabilityRuntime/procurement-workflow-v3/unified-asset-service，先盘点收纳 |

| "技能" | 新概念，MCP/API/SDK 统一调用 | = worker 能力单元；外部 MCP 是 worker 的可选实现源，非默认 |

| 数据资产 | DA-001~005 已在 PLM"注册" | 真实数据源是 SCSAI PLM（Vendor/Part/BOM）+ 外部电商 API（京东/1688）；本地 vendors/purchase_orders 表存在但采购 worker 实时比价不读它们 |

| 外部技能 | "已验证" | 仅"联网检索到"，server/ 内无 MCP 客户端，状态=待集成验证 |

新增铁律：接入任何新场景前，先 grep server/boss-scheduler/workers/ 和 local.yaml，确认没有功能等价的既有 worker，避免重复建设。

03 总体架构（在现有四层上对齐，不另起）

场景层（配置包）
  采购比价(已有 DS-PROC-001) · 设备运维 · 质量分析 · 工艺优化
        ↕ 每个场景 = 一个 worker 注册项 + 一份映射/编排配置
技能接入层（= 现有 worker 体系，泛化）
  技能注册表  ← STAFF_DEFAULTS / local.yaml 已有雏形，扩展为显式注册表
  数据映射引擎 ← 现有 worker 把映射写死在代码里，底座要把它外置成配置
  四项适配器  ← 部分已有（SCSAIClient/确认机制/i18n），补齐安全/输出适配
        ↕
运行时层（= 现有 CapabilityRuntime + procurement-workflow-v3，泛化）
  编排 · 鉴权 · 审计 · 重试 · 结果回流
        ↕
数据资产层（= 现有 unified-asset-service，扩展为带权限/审计的取数注册表）
  SCSAI PLM（Vendor/Part/BOM）· 外部电商 API（京东/1688）· 历史价/PO(待核实)

关键原则：场景只做"配置"，不做"开发"。技能不直接散落连库，统一走数据资产中心取数；技能调用统一走注册表，任何 worker 可插拔替换。数据权限和审计在底座统一管控。

04 底座组件一：数据资产注册中心（重新对齐真实数据源）

v1 的 DA 表把"采购数据已在 PLM 注册"当成事实。核实结果：采购 worker 实时比价的数据来自 SCSAI PLM + 外部电商 API，本地 vendors/purchase_orders 表不是它的实时数据源。重新登记如下：

| 资产 ID | 真实数据源 | 消费场景 | 现状 |

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

| DA-001 物料主数据 | SCSAI Part ItemType（经 SCSAIClient） | 采购、工艺 | SCSAI 已连通，待注册为资产 |

| DA-003 供应商档案 | SCSAI Vendor（findVendorsByProduct） | 采购 | 已实际读取，待注册为资产 |

| DA-005 BOM 结构 | SCSAI BOM / 本地 phos_chem | 采购、工艺 | 部分可用，待注册 |

| DA-电商 比价源 | 外部电商 /api/unified-procurement（京东+1688） | 采购 | 已实际调用，待注册（含出网审计） |

| DA-002 历史采购价 | purchase_orders(core_runtime) / SCSAI | 采购 | 114 开发实例未核实存在，待确认 |

| DA-004 采购订单 | purchase_orders(core_runtime) | 采购 | 表存在，但 worker 走 SCSAI PO 接口，非本地表 |

教训：v1 的"已注册"是意图，不是事实。资产中心落地时，取数接口必须指向真实被 worker 读取的源（SCSAI + 电商 API），而非假设本地表。

与既有代码的衔接：现有 server/core/unified-asset-service.js(126KB) 是只读聚合层（工业资产总览），industrial-data-asset-overview.js 是我们刚修过统计口径的那个。数据资产中心应扩展 unified-asset-service，在其上加"取数 API + 权限 + 审计"，不要另起一个平行模块。

05 底座组件二：技能注册表（技能=worker 能力单元）

v1 把"技能"当独立新概念，和现有 86 个 worker 体系脱节。校正：技能是 worker 对外暴露的能力单元，注册表登记的是 worker/tool。

注册表现状（已存在 vs 待建）：

| 技能 ID | 名称 | 实现 | 协议 | 状态 |

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

| SK-PROC-001 | 采购助手 | workers/procurement.js + tools/procurement-workflow-v3.js | 内部 worker（SCSAI+电商API） | 已运行（DS-PROC-001） |

| SK-PROC-002 | 成本优化 | workers/cost-optimizer.js(512行) | 内部 worker | 已运行 |

| SK-PROC-003 | 报价比对 | workers/compare.js | 内部 worker | 已运行 |

| SK-PROC-X1 | Procurement MCP Server | zavora-ai/mcp-procurement（GitHub） | MCP | 仅检索到，未集成（server 无 MCP 客户端） |

| SK-PROC-X2 | WhichBid 报价解析 | Dixon-O/which-bid（GitHub） | API | 仅检索到，未集成 |

| SK-PROC-X3 | 比价评分模型 | FastGPT 实战权重(CSDN) | 算法 | 仅检索到，未回归校准 |

注册项结构（新技能照此登记，worker 与 MCP 同表）：

{
  "skill_id": "SK-PROC-001",
  "name": "采购助手",
  "impl": "worker:procurement",          // worker:<id> 或 mcp:<server> 或 api:<endpoint>
  "inputs": ["产品", "数量", "预算", "供应商偏好"],
  "outputs": ["比价结论", "供应商推荐", "PO", "省钱报告"],
  "data_assets": ["DA-001", "DA-003", "DA-电商"],
  "license_check": "内部 worker=自有；外部 MCP/API=接入前查许可证与依赖",
  "status": "已运行 / 待集成 / 待验证"
}

红线：外部技能状态严禁写"已验证"，只能写"检索到/待集成/已集成待验证"。集成进 server/ 并跑通历史数据回测后，才允许升为"已验证"。

06 底座组件三：数据映射引擎 + 四项适配器（外置硬编码）

v1 说"映射表场景只填，引擎通用"——但现实是现有 worker 把映射写死在代码里（如 procurement.js 里 findVendorsByProduct 的字段拼装）。底座要做的真工程是：把硬编码映射外置成配置，让设备运维/质量能复用同一引擎。

| 适配器 | 现状（已有哪些） | 底座补齐 |

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

| ① 数据适配 | SCSAIClient 字段映射、电商 API 解析 | 外置为配置表，新增场景只填表 |

| ② 安全适配 | ConfirmNeededError 三阶段确认、i18n | 补：敏感字段脱敏、取数审计、出网白名单（接外部 MCP 必填） |

| ③ 性能适配 | worker 内 http.request 超时/重试散落 | 统一连接池/超时/重试/缓存 |

| ④ 输出适配 | 各 worker 自渲染 | 补：统一渲染器 → BossAgents 产物标准 Schema |

私有化 vs 公网 MCP 矛盾（v1 一笔带过，必须定分叉）：

框架既要"外部技能优先源码/MCP"，又要"数据不出厂/私有化"。两者冲突：接公网 MCP Server 就要把供应商/历史价传出网。决策点——

• 选 A（私有）：把外部 MCP 服务自建并私有化托管在厂内，数据不出网；
• 选 B（出网）：接公网 MCP，但必须经安全适配的脱敏+审计+白名单，且默认关闭，显式开启。

当前 procurement.js 的 1688 寻源就是 USE_1688_SOURCING 默认关闭的先例，沿用此模式。

07 底座组件四：编排运行时（泛化 procurement-workflow-v3）

v1 把编排运行时当待建。现实：tools/procurement-workflow-v3.js(1105行) 已经是采购场景的编排实现（搜索→比价→供应商评估→PO→绩效），走 CapabilityRuntime + ConfirmNeededError 三阶段确认。

底座要做的：把这段采购专属编排泛化为"场景编排配置"——技能序列、评分权重、回退策略、确认节点都从配置读，而非写死在 workflow 文件里。采购的编排成为第一个配置包样板，设备运维是另一个配置包，运行时同一套。

// 通用编排运行时（示意：泛化现有 procurement-workflow-v3 的结构）
async function runScenario(scenarioConfig, request, ctx) {
  const data = await dataAssetCenter.get(scenarioConfig.data_assets, request.filter);
  const result = await orchestrate(scenarioConfig.skills, data, ctx); // 按注册表 impl 分派
  const report = render(scenarioConfig.output_template, result);       // 输出适配
  await dataAssetCenter.writeBack(report);                            // 结果回流
  return report;
}

08 上层插拔：新场景接入（加第 0 步"盘点"）

v1 五步保留，新增第 0 步，并把"已验证"要求落到第 5 步：

• 第 0 步 · 盘点既有 worker：grep workers/ + local.yaml，确认无功能等价实现，避免重复建设（采购就是前车之鉴）。
• 第 1 步 · 注册数据资产（指向 SCSAI/电商等真实源，非假设本地表）
• 第 2 步 · 选技能：优先复用注册表 worker；缺则用 AI 编程工具搜真实方案，登记为"待集成"
• 第 3 步 · 填映射表（外置硬编码）
• 第 4 步 · 配编排与评分（权重从配置读，先用 v1 的 40/30/30 占位，但标"未校准"）
• 第 5 步 · 回测验证上线：用 SCSAI/本地真实历史数据回测，定验收指标，达标才升"已验证"。任何场景第 5 步没跑通，就不算接入完成。

09 场景实例一：采购比价（重写为"已有实例，纳入底座范式"）

采购比价不是待建首个实例，而是已上线的 DS-PROC-001 小臂-采购助手。本文档的价值是把它的实现"翻译"成底座范式，验证范式能装下真实 worker：

| 接入步骤 | 采购实例的真实做法（已存在） |

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

| ① 数据资产 | SCSAI Vendor/Part/BOM + 外部电商 API（京东/1688） |

| ② 选技能 | procurement + compare + cost-optimizer worker（非外部 MCP） |

| ③ 映射 | findVendorsByProduct 等硬编码在 worker 内，待外置 |

| ④ 编排 | procurement-workflow-v3 搜索→比价→评估→PO→绩效（硬编码，待配置化） |

| ⑤ 验证 | 回测未做——40/30/30 权重来自 CSDN 文章，未在 purchase_orders 回归 |

采购跑通后，底座该沉淀的不是"新建一套"，而是：把 procurement 的映射外置、把 workflow 的编排配置化、把确认/审计/渲染抽成通用适配器。这些沉淀直接被设备运维/质量复用。

10 场景实例二~四（同底座，换配置；技能方向待搜索验证）

| 场景 | ① 数据资产（真实源） | ② 候选技能方向 | ③④ 要点 | ⑤ 验收指标 |

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

| 设备运维 | SCSAI 设备台账/运行日志（待确认 ItemType） | 故障预测/维护排期（搜真实方案） | 运行参数→故障输入；编排：监控→预警→工单 | 故障提前预警率 |

| 质量分析 | SCSAI 检测记录/不良品（待确认） | SPC/根因分析（搜真实方案） | 检测项→SPC 输入；编排：判异→归因 | 异常检出率 |

| 工艺优化 | SCSAI 工艺路线/设备参数 | 参数寻优/能耗优化（搜真实方案） | 工艺参数→寻优输入 | 单件能耗下降 |

说明：上表技能方向为骨架。每个场景走第 08 章（含第 0 步盘点），技能用搜索到的真实方案替换，指标用历史数据回测后定。

11 落地节奏（先盘点收纳，再补底座缺口）

| 周次 | 任务 | 说明 |

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

| 第 1 周 | 盘点+收纳既有采购栈 | 把 DS-PROC-001/procurement-workflow-v3 翻译进底座范式；确认 86 worker 中可复用项 |

| 第 2 周 | 补底座真缺口 | 显式技能注册表（扩展 STAFF_DEFAULTS）、映射外置引擎、安全/输出适配器、出网白名单 |

| 第 3 周 | 采购回测（第 5 步） | 用 SCSAI/本地真实数据验证比价结论，校准权重，升"已验证" |

| 第 4 周起 | 场景复制 | 设备运维→质量→工艺，各 3-5 天；先搜技能，再填配置包 |

| 持续 | 技能库沉淀 | 每验证通过的技能登记注册表，配置包归档 |

提醒：不要先铺场景。底座没把采购栈收纳完就并行接多场景 = 又回到"一套场景一套代码"。

12 风险与对策（补充两条）

13 数据来源说明（校正状态）

• 现有采购栈为 BossAgents 代码事实：DS-PROC-001(local.yaml:11)、workers/procurement.js(436)、procurement-chain-worker.js(157)、cost-optimizer.js(512)、tools/procurement-workflow-v3.js(1105)、数据源 SCSAI PLM + /api/unified-procurement（京东/1688）。
• 外部技能（Procurement MCP Server / WhichBid / FastGPT）为联网检索结果（截至 2026-08-31），状态=待集成验证，非"已验证"。
• PLM 具体 ItemType 名、历史价/PO 在 114 开发实例的存在性，需与实施团队核对。
• 采购详细方案见配套文档《采购比价技能集成方案 v1》；本文档 v2 仅做框架层校正。

BossAgents 通用技能集成框架 v2（对齐代码现实）｜ BossAgents 项目组 ｜ 2026-08-31