BossAgents BossAgents

架构分析与主链统一方案_v1

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

BossAgents 架构 Reality-Check 与主链统一方案

生成时间：2026-07-06

方法：所有 claim 均经源码实锤（grep/read），非 AI 推断

范围：剔除"数据量"类问题，只谈架构/产品/工程闭环

零、先纠正一处：之前那份分析有 1 条要推翻

原分析 claim："SmartLLMRouter 不存在 / LLM 调度三轨未落地"

实测结果：server/digital-staff/smart-llm-router.js 存在（1043 行，含 MTCLAW→Ollama→DeepSeek→规则引擎 多级降级链路）。

修正结论：SmartLLMRouter 已实现但未被主路径采用。真正的差距是"已实现 vs 主路径未接入"，不是"未实现"。这比原分析乐观——收敛工作量更小。

一、已实锤的事实清单（✅=源码确认）

P0-1 数字员工数量：计划书12 vs 代码27

  • profiles/local.yaml 真实 ID = 30（含 3 个 LLM 平台占位 mtclaw/ollama/deepseek + 自动循环员工）
  • 正式业务员工 27 个，enabled: false 仅 3 个
  • 计划书 V7.0 主推"12 大数字员工"
  • 定性 ✅：对外 12、对内 27 的"产品定义漂移"成立

P0-2 LLM 调度：已实现但主路径直连 LLMBrain

  • 主路径散落 new LLMBrain() 点：
  • server/routes/aml.js ×9（4188/4368/5380/5858/5972/6184/6318/6420 等）
  • conversation-engine.js:78、object-modeler.js:273、procurement-workflow-v3.js:16、health-patrol.js:175
  • SmartLLMRouter 引用点存在（server.js / lite-scheduler.js / capability-api.js / smart-llm-router.js 自身）
  • 定性 ✅：三轨并存成立，但根因是"主路径未收敛到 SmartLLMRouter"，而非"没实现"

P0-3 Create 主路径截断：前端+后端双重绕开规则引擎

  • 前端：src/composables/useCapabilityCreate.js + useCreate.js

buildAML() → bomService._arasApiRequest('ApplyItem', mainAml) 直接打 SCSAI

  • 后端：server/routes/unified-create.js

直接 getSharedClient → precreateItem / createRelationshipsRecursive 直接打 SCSAI

全文无 ruleEngine / CapabilityRuntime / llm-router 引用

  • 规则引擎入口 /api/rule-engine/create-post（server.js:2320）前端从未调用
  • 定性 ✅（比原分析更严重）：不仅后端绕开，前端也直连 SCSAI。"规则兜底 90%"在 Create 路径上无法统计、无法审计

P0-4 "五维"名实不符

  • 代码内"五维" = 数据健康体检五维评分：完整性/准确性/时效性/可用性/安全性（前端 govern 模块实锤）
  • 计划书把"五维对象交易市场"与"五维健康体检"混用同一词
  • 定性 ✅：真实命名冲突，尽调必被挑战

P1-1 Worker 未统一到 CapabilityRuntime

实测 19 个 worker 调用情况（CR=走CapabilityRuntime, LLM=直连LLMBrain）：

| Worker | CR | LLM | 说明 |

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

| aras-creator | ✅ | ❌ | 走 CR |

| biz-analyst | ✅ | ❌ | 走 CR |

| cost-optimizer | ✅ | ❌ | 走 CR |

| data-clerk | ✅ | ❌ | 走 CR |

| ecr-worker | ✅ | ❌ | 走 CR |

| report-analyst | ✅ | ❌ | 走 CR |

| vendor-review | ✅ | ❌ | 走 CR |

| auto-loop-worker | ❌ | ❌ | 独立存储 auto-loop-data.json |

| content | ❌ | ❌ | 自写逻辑 |

| data-caretaker | ❌ | ❌ | 自写逻辑 |

| doc-worker | ❌ | ❌ | 自写逻辑 |

| equip-worker | ❌ | ❌ | 自写逻辑 |

| mkt-worker | ❌ | ❌ | 自写逻辑 |

| pm-worker | ❌ | ❌ | 自写逻辑 |

| process-worker | ❌ | ❌ | 自写逻辑 |

| procurement | ❌ | ❌ | 自写逻辑 |

| stock-manager | ❌ | ❌ | 自写逻辑 |

| system-health | ❌ | ❌ | 自写逻辑 |

结论：仅 7/19 走 CR，其余 12 个各自实现业务逻辑。计划书"六能力×行业知识"在工程上是"12 种实现风格"。

定性 ✅："无需 FDE、复制即部署"难以证明。

P1-2 双库分裂

  • server/data/core_runtime.db（1.7MB，89 表）
  • server/data/core_runtime.db（20KB，2 表）
  • 两套库并存，行为不一致风险
  • 定性 ✅

P1-3 Legacy 未清理

  • server/digital-staff/index.js 仍存在（2423 行），与 boss-scheduler 双入口
  • 定性 ✅：认知负担 + 路由歧义

P1-4 mtclaw-tools.yaml 是"空插座"

  • 注册 9 个 handler：leftarm.db.query / leftarm.rule_engine.cost_calc / leftarm.notification.send 等
  • 全仓 零 leftarm handler 实现
  • 定性 ✅：配置存在但无后端，Phase2 MTClaw 未实装

P1-5 自进化未入主路径

  • rule-evolution.js 存在，但仅由 DS-AUTO-LOOP-001 旁路 cron 触发
  • 未接入规则引擎执行后钩子（hit_count / user_correction → 候选规则）
  • 定性 ✅：计划书"越用越准"目前只能讲设计，无法 live demo

P2-1 测试覆盖

  • 仅 3 个测试文件：aml-integrity.test.mjs / digital-staff.test.mjs / rule-engine.test.mjs
  • 全仓数千文件，融资尽调高风险
  • 定性 ✅

P2-2 多租户

  • tenant-db.js 有 enterprises 表，但调度/双库/员工配置无租户隔离
  • 定性 ✅（部分）：框架有，隔离无

二、优化方案（不导入任何数据，只动架构/路由/收敛）

方案总纲：一条唯一主链

用户意图/前端操作
  → SmartLLMRouter（唯一 LLM 入口，含降级链）
  → CapabilityRuntime（规则引擎优先，LLM 降级）
  → 六能力（识别/创建/修复/优化/比对/生成）
  → 统一 SCSAI 适配层（禁止各 worker 直连）
  → 可审计结果（rule hit_count + execution_log）

改动清单（按优先级）

#### 【P0】主链收敛（本次立即动手）

  1. Create 闭环统一
  • 前端 useCapabilityCreate.js / useCreate.js：buildAML 后改调 /api/rule-engine/create-post（而非直连 _arasApiRequest）
  • 后端 unified-create.js：改为先查规则引擎 + 双库去重，再 applyAML；保留直连作为 ?bypass=rule 逃生阀
  • 验收：Create 操作在 sciot_rule_hits 表产生记录
  1. LLM 单入口
  • 在 server.js 启动时建立全局 global.__smartLLMRouter = new SmartLLMRouter(...)
  • aml.js 9 处 + 其余散落 new LLMBrain() 改为 global.__smartLLMRouter.call(...)
  • 验收：所有 LLM 调用经统一 metrics 出口
  1. "五维"正名
  • 代码内：健康体检保持"五维评分"命名
  • 计划书：将"五维对象交易市场"改名为"六类对象交易市场"（数据/模型/规则/Skill/工作流/数字员工）
  • 避免尽调同名冲突

#### 【P1】OS 内核化（第二步）

  1. Worker 强制走 CapabilityRuntime
  • 12 个未接入 worker：逐个改为 runtime.call({capability, itemType, params})
  • 保留 worker 作为"参数配置器 + 能力编排器"，禁止直通 LLM/SCSAI
  1. 双库合一
  • 统一使用 server/data/core_runtime.db，删除 server/data/core_runtime.db 引用
  • 配置项 DB_PATH 单一真相源
  1. Legacy 清理
  • digital-staff/index.js 标记 deprecated，路由全部指向 boss-scheduler
  • 1 个版本后删除
  1. mtclaw 空插座处理
  • 要么实装 leftarm.* handler（复用现有 db/rule-engine/notification 模块）
  • 要么从 mtclaw-tools.yaml 删除，避免"配置幻觉"
  1. 自进化入主路径
  • rule-evolution.js 接入 CapabilityRuntime 执行后钩子
  • 每次能力执行后：更新 hit_count + 采集 user_correction → 生成候选规则

#### 【P2】规模化（第三步）

  1. 测试补齐：核心主链（create/identify/router）加 integration test
  2. 多租户隔离：调度上下文注入 tenant_id
  3. 产品层收敛：local.yaml 分 profile（boss-lite / enterprise），主叙事只用 12 标准 Skill

三、本次立即执行的优化（P0 三项）

见下方"优化执行记录"。

← 返回案例列表
分享：
🤖 Try Now →
🤖
🎁