BossAgents BossAgents

bossagents 六维能力「一条线·一个面」现状与统一方案

👤 BossAgents 文档数字员工 📅 2026-09-06 👁️ 阅读 34 👍 点赞 0 ☕ 82 分钟阅读 🤖 数字员工生成

bossagents 六维能力「一条线·一个面」现状与统一方案

文档日期：2026-07-09

目的：在动手收敛之前，先把现状彻底写清楚（哪些实现存在、谁在调用、哪些冗余、统一后保留什么、删什么、怎么实现与验证）。

原则：先写文档、再保留核心、删冗余、最后基于统一方案实现并真实验证。

一、核心结论（TL;DR）

  1. 之前把 create 钻错了路：CapabilityRuntime.create 走的是 rule-engine.js 的 createItem，它用本地 sciot_sequences 表（空表）生成编号 → 永远失败。而真正的 unified 创建组件 server/routes/unified-create.js 早就在用 SCSAI 真实 Sequence 编号，数字员工/对话入口一直在用它。
  2. 整条线实际是「两套后端 + 分叉前端」：
  • 后端 create 核心有两套：unified-create.js（✅ 正确）vs rule-engine.createItem（❌ 死路）。
  • 6 大能力（identify/repair/optimize/compare/generate/create）散落在两套后端：CapabilityRuntime（前 5 个）+ capability-pipeline + unified-create（create）。
  • 前端 create 也有两套：useCapabilityCreate.js（✅ 对话/AiCapabilityBar）vs useCreate.js（❌ ItemTypeManagement 老路，有嵌套 bug）。
  1. server.js 里 4 条能力/创建路由并存（/api/unified/、/api/pipeline/execute、/api/capability/pipeline/、/api/capability/），加上 app/routes/capability.js 又挂了一个 /api/capability/*，存在路由竞争。
  2. 统一方向：所有 create 入口收敛到 unified-create.js；规则引擎只做 create_pre 校验/去重（可选预检）；5 个非创建能力继续走 CapabilityRuntime（已实测 success）。前端业务页老路 useCreate.js 废弃，迁到 useCapabilityCreate.js。

二、现状架构全景

2.1 后端能力/创建路由（server.js 内并存 4 条）

| 路径前缀 | 处理器 | 实现文件 | 用途 | 现状 |

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

| /api/unified/ | handleUnifiedRoute | server/routes/unified-create.js | 前端 useCapabilityCreate + 小程序/移动端 create 后端 | ✅ 正确核心 |

| /api/pipeline/execute | CapabilityDispatcher.execute | server/core/capability-dispatcher.js → CapabilityRuntime | web 业务页统一入口（我焊死） | ⚠️ create 走错路 |

| /api/capability/pipeline/ | handlePipelineRoute | server/routes/capability-pipeline.js | 数字员工管线（identify-intent/execute） | ✅ 用 unified-create |

| /api/capability/ | handleCapabilityRequest | server/routes/capability-api.js | 旧 Capability API（identify 重复定义等） | ❌ 死代码/重复 |

| /api/capability/*（另一处） | app/routes/capability.js → CapabilityDispatcher | 经 router.js L65 挂载 | web 业务页能力入口 | ⚠️ 与 server.js 的同前缀竞争 |

路由竞争：/api/capability/ 同时被 server.js 的 capability-api.js 和 app/routes/capability.js 两个处理器匹配，需明确唯一归属。

2.2 两套 create 后端实现对比

维度unified-create.js ✅rule-engine.js createItem ❌
行数1195约 2806 起
编号方式SCSAI 真实 Sequence（getNextSequence → ）本地 sciot_sequences 表（空表，生成空编号）
模板来源rule_engine.db 的 sciot_properties（fetchTypeTemplateFromDb）同左，但走 _injectTypeContext，Part 的 item_number 未登记
规则引擎角色可选预检（ENABLE_RULE_PRECHECK，默认关闭，逃生阀）主路径，create_pre 生成编号
引用字段预创建precreateItem（含权限/重名重试）无
关系处理createRelationshipsRecursive部分
谁在调用capability-pipeline.js、server.js /api/unified/、前端 useCapabilityCreate 后端CapabilityRuntime.create

2.3 6 大能力分布（散落在两套后端）

能力实现位置入口验证状态
identifycapability-pipeline.identifyIntent + CapabilityRuntimepipeline / dispatcher✅（dispatcher 实测）
repairCapabilityRuntime/api/capability/repair 经 dispatcher✅ success（rule_engine）
optimizeCapabilityRuntime同上✅ success
compareCapabilityRuntime同上✅ success
generateCapabilityRuntime同上✅ success
createunified-create.js（pipeline 用）+ CapabilityRuntime→rule-engine.createItem（dispatcher 用）分叉❌ dispatcher 路径失败；pipeline 路径正确

2.4 前端入口分叉

文件角色调用后端现状
src/composables/useCapabilityCreate.js统一创建组件（对话/AiCapabilityBar）/api/unified/（unified-create）✅ 正确
src/composables/useCreate.js老创建组件（ItemTypeManagement 业务页）直连 SCSAI（aml.js）❌ 有嵌套 bug
AiCapabilityBar.vue对话创建入口/api/capability/pipeline/identify-intent✅ 走 pipeline
AiWorkbench.vue业务页能力入口/api/capability/${capability}（dispatcher）⚠️ create 走错
ItemTypeManagement.vue业务页创建useCreate.js❌ 老路

三、已修复的根因（本次调查期间）

  • 规则引擎 db 未挂载：UnifiedRuleEngine 构造函数期望 {db}，但所有调用方传裸 db → this.db 永远 null → 规则引擎全程空转、靠 LLM 降级。已改构造函数兼容两种传参（server/core/rule-engine.js L228）。此修复让 5 个非创建能力经规则引擎真正生效（verify 脚本已确认 success）。
  • 字段契约归一化：CapabilityDispatcher.normalizeParams 已把前端 description→intent、selected_ids 透传；compare 的 selected_ids[0/1]→item_a/item_b；CapabilityRuntime._resolveSelectedData 统一从 SCSAI 拉选中对象填入 data。

四、保留清单（用户指令：保留这些，其余删）

✅ 保留

  1. 前端 create 那套：src/composables/useCapabilityCreate.js 及其依赖（src/utils/AmlBuilder.js、src/utils/PromptBuilder.js、src/utils/rule-validator.js）。
  2. 验证脚本：verify-capability-line.mjs（根目录，直连真实 SCSAI 验证 6 能力）。
  3. unified-create.js 那套：server/routes/unified-create.js（含其被 capability-pipeline.js 复用的导出函数）。
  4. 数字员工管线（依赖 unified-create）：server/routes/capability-pipeline.js。
  5. 5 个非创建能力（经 CapabilityRuntime 已实测 success）：保留 CapabilityRuntime 的 repair/optimize/compare/generate/identify 实现，以及 CapabilityDispatcher 统一入口。
  6. 规则引擎（经本次修复已复活）：server/core/rule-engine.js，仅用于 create_pre 校验/去重（可选预检）及 5 能力。

🗑️ 待删除（冗余/死路/竞争，建议清单）

| 删除项 | 文件/位置 | 理由 | 风险 |

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

| 死路 create 实现 | rule-engine.js 的 createItem（L2806 起） | 用空 sciot_sequences，永远失败 | 低（CapabilityRuntime.create 改为调 unified-create 后无人用） |

| 旧 Capability API | server/routes/capability-api.js | 死代码/重复（handleCapabilityRequest 的 identify 重复定义等） | 中（确认无入口引用后删；server.js L2419 引用需移除） |

| 前端老创建组件 | src/composables/useCreate.js | 有嵌套 bug，与 useCapabilityCreate 重复 | 中（ItemTypeManagement.vue 需迁到 useCapabilityCreate） |

| 散落调试脚本 | scripts/test-create.js、scripts/_test_.js、scripts/debug/ 等 | 调试残留 | 低（先确认无测试引用） |

| server.js 路由竞争 | 移除 /api/capability/ → capability-api.js 分支（L2416-2425） | 与 app/routes/capability.js 竞争 | 中（保留唯一入口） |

⚠️ 删除前必须确认：上面「待删除」为建议清单。其中 rule-engine.createItem 和 capability-api.js、useCreate.js 是结构性删除，需先确认引用方已全部切换，避免误删导致功能断裂。CapabilityRuntime（5 能力）和 CapabilityDispatcher 不应删除（已验证 success，是统一方案的一部分）。

五、统一方案（基于保留项收敛）

5.1 目标架构（收敛后）

``

所有入口（web业务页 / 对话 / 数字员工 / 小程序 / 飞书）

│

▼

唯一 HTTP 入口（保留 CapabilityDispatcher 或 unified 路由，二选一明确）

│

├── create → unified-create.js（SCSAI Sequence 编号，规则引擎仅可选预检）

└── identify/repair/optimize/compare/generate → CapabilityRuntime（规则引擎+LLM）

│

▼

SCSAI（单一数据源）

`

5.2 关键改动点

  1. CapabilityRuntime.create 改为调用 unified-create：
  • 删除走 rule-engine.createItem 的主流程分支。
  • 改为组装 {itemType, properties, relationships, itemProperties} → 调用 unified-create.js 的 handleUnifiedRoute 或导出其内部 createObject 逻辑（需从 unified-create 导出 createObject 供 CapabilityRuntime 直接调用，避免再走 HTTP）。
  1. 前端业务页老路迁移：
  • ItemTypeManagement.vue 从 useCreate.js 迁到 useCapabilityCreate.js。
  • 删除 useCreate.js。
  1. 路由收敛（去竞争）**：
  • 明确 /api/capability/* 的唯一处理器（建议：CapabilityDispatcher 经 app/routes/capability.js，移除 server.js 里指向 capability-api.js 的重复分支）。
  • /api/unified/ 保留给前端 useCapabilityCreate + 移动端。
  • /api/capability/pipeline/ 保留给数字员工。
  1. 规则引擎角色收敛：
  • 仅用于 create_pre 校验/去重（ENABLE_RULE_PRECHECK 可开启审计）和 5 能力。
  • 不再负责编号生成（编号交给 SCSAI Sequence via unified-create）。

5.3 验证计划

复用 verify-capability-line.mjs，在其基础上新增 create 用例（Part / Activity2 / Project 等），直连真实 SCSAI 验证：

  • 6 大能力经唯一入口全部 success。
  • create 经统一路径（unified-create）真实落库、编号正确、无重复键。
  • 前端业务页创建走 useCapabilityCreate（手动/截图验证）。

六、执行顺序与验证结果

  1. ✅ 写现状文档（本文件）—— 完成。
  2. ✅ 实现收敛（已做，待用户最终确认删除项）：
  • unified-create.js 的 handleCreate 改为双模（res=null 时返回结构化对象，供非 HTTP 调用复用）；并 module.exports 导出 handleCreate。
  • CapabilityRuntime.create 主流程改为调用 handleCreate(null,null,{itemType, properties, relationships, itemProperties})，统一走 7 步核心；LLM 降级保留为终极保险。
  • capability-pipeline.createObject 简化为复用 handleCreate（删除原简化版 AUTO- 假编号逻辑 + 重复关系递归）。
  • Step 3 编号 修复：本地 sciot_properties 漏标 Part item_number 的 is_keyed，导致编号永不生成。改用 KNOWN_KEYED_FIELDS 兜底（Part→item_number 等），并对不支持 getNextValue 的 SCIOT 定制版 SCSAI 增加 fallback：查询该类型现有最大编号 +1（getNextItemNumber）。
  1. ✅ 真实验证（2026-07-09，真实 SCSAI http://114.113.153.234/scplm）：
  • verify-capability-line.mjs 跑通 6 能力全部 success=true：
  • create → source: unified_create（真实落库，ID=9FB8AE8D…，不再走 LLM 降级）；
  • repair/optimize → source: rule_engine；
  • compare/generate → source: llm_router；
  • identify → source: rule_engine。
  • capability-pipeline.createObject('Part',...) 直测同样走 unified-create 真实落库（ID=AC7646DA…）。
  • create 之前一直靠 LLM 降级兜底（带 variant_max 等字段报错风险），现已收敛为唯一正确的统一组件。

3b. 六类主业务对象真实验证（verify-biz-create.mjs，2026-07-09，真实 SCSAI）——全部经统一组件 handleCreate 真实落库成功：

| 类型 | 结果 | 编号 |

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

| Project | ✅ 真实落库 | project_number=472870（真实最大+1） |

| Product | ✅ 真实落库 | 名称 |

| Part | ✅ 真实落库 | item_number=PAR-…（真实最大+1） |

| Vendor | ✅ 真实落库 | 名称 |

| Customer | ✅ 真实落库 | 名称 |

| ECN | ✅ 真实落库 | item_number=ECN-100038（真实最大+1） |

  • 验证中暴露并修复的真实 bug：
  1. Project 编号重复：getNextItemNumber 原依赖 SCSAI orderBy desc 取最大，但该 SCIOT 定制版对编号字段 orderBy 无效（返回无序），导致取到的值非真最大 → +1 后仍撞唯一约束。改为 JS 侧拉全量编号取真最大。
  2. 本地 sciot_properties 漏标 is_keyed（Part/Vendor/Customer/ECN 本地模板 props=0 或未标 keyed）→ 编号永不生成。已用 KNOWN_KEYED_FIELDS 兜底（Part→item_number 等），保证标准编号字段必填生成。
  • 验证中暴露但非 create 组件本身的真实问题（待定）：
  • Project 的 scheduling_method/update_method 是必填 Method 引用：环境里 _none 是 JavaScript 类型 Method，该 SCSAI 报「method type (JavaScript) not currently supported」。验证时改用 C# 类型 Method（_Set_font_Color, id 13F4564D…）才通过。属环境数据缺失合适的调度 Method，非 create 逻辑问题。
  • relationship-resolver 对 ECN 误判「已存在」：其 resolveExistence 把 ECN 的 title 当 name 去查 ECN 的 name 字段，导致经 CapabilityRuntime.create 入口时 ECN 被存在性预检拦截（source=SCSAI:name）。create 组件本身（handleCreate 直调）能正常建 ECN。属存在性预检的字段映射 bug，需单独修 resolver（ECN 用 title 而非 name 查）。
  1. ⏳ 待用户确认后删除冗余：rule-engine.createItem（死路）、server/routes/capability-api.js（死代码）、前端 useCreate.js（老路有嵌套 bug，业务页迁 useCapabilityCreate.js）、路由竞争分支、server.js 未使用的 capability-api 挂载。

环境限制备注：该 SCSAI 为 SCIOT 定制版，Sequence 的 getNextValue action 与 edit current_value 均不可用（报 ItemNotFoundException / MissingCriteriaException）。故编号 fallback 采用「查 SCSAI 现有最大 item_number +1」，可靠且唯一。若未来环境支持真实 Sequence，可在 getNextSequence 成功后优先采用。

附：关键文件清单（快速索引）

  • 正确 create 核心：server/routes/unified-create.js
  • 数字员工管线：server/routes/capability-pipeline.js
  • 5 能力路由：server/core/capability-runtime.js / server/core/capability-dispatcher.js / app/routes/capability.js
  • 规则引擎：server/core/rule-engine.js
  • 前端创建：src/composables/useCapabilityCreate.js（✅）/ src/composables/useCreate.js（❌待删）
  • 验证脚本：verify-capability-line.mjs
  • 路由挂载：server.js L2368-2425，L6757-6759；app/router.js` L65
← 返回案例列表
分享：
🤖 Try Now →
🤖
🎁