BossAgents 数字化员工优化方案（基于现有实现修正版）

基于 2026-06-14 战略方案，结合 BossScheduler + LiteScheduler 现有代码实现修正

一、先纠正方案中的事实错误

1.1 员工统计修正

方案说"13个活跃员工"，实际上：

| 原始员工 ID | 实际状态 | 修正 |

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

| DS-BOSS-001 | ❌ 不存在于 YAML profile | 旧 seed，非活跃 |

| DS-BOSS-002 | ❌ 不存在于 YAML profile | 旧 seed，非活跃 |

| ⟦DS-SCSAI-001⟧ | ❌ 不存在于 YAML profile | 旧 seed，非活跃 |

| DS-ECR-001 | ⏸️ 无 worker/capability，已跳过调度 | 空壳 |

| DS-REVIEW-001 | ✅ 存在，但 worker="" | 纯能力路由 |

| DS-DATA-001 | ✅ 存在，cron 调度中 | 数据同步员 |

| DS-VEN-001 | ✅ 存在，cron 调度中 | 供应商管家 |

| DS-SYS-001 | ✅ 存在 | 系统运维师（有 2 个同名） |

| DS-PROC-001 | ✅ 存在 | 采购助手（核心） |

| DS-COST-001 | ✅ 存在 | 成本优化师 |

| DS-CONTENT-001 | ✅ 存在 | 内容生成师 |

| DS-REPORT-001 | ✅ 存在 | 报告分析师 |

| DS-OPS-001 | ✅ 存在 | 数据管家 |

实际活跃 11 个员工，其中 4 个偏运维（data-clerk, data-caretaker, system-health x 2）。

1.2 "7 种能力只用了 5 种"修正

当前 LiteScheduler 的 CAPABILITY_MAP（lite-scheduler.js:31-39）：

identify: 'identify',    // ✅ 被 data-clerk 使用
validate: 'validate',    // ✅ 被 ECR/SYS 使用
repair: 'repair',        // ⚠️ 接口存在，0 次实际调用
optimize: 'optimize',    // ⚠️ 接口存在，0 次实际调用
compare: 'compare',      // ⚠️ 接口存在，procurement 硬编码不走
generate: 'generate',    // ⚠️ 接口存在，content/report 硬编码不走
create: 'create',        // ✅ 被 content 使用
inspect: 'inspect',      // ⚠️ 接口存在，0 次调用

实际情况：3 种能力被使用（identify/validate/create），5 种闲置。不是"7中5"，是8中3。

1.3 核心问题：「worker 硬编码」是最严重的问题

方案说"procurement/health/caretaker 绕开 CapabilityRuntime"，经代码审查：

| Worker | 状态 | 问题 |

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

| procurement.js | ❌ 完全硬编码 | 9000 字节自包含：供应商查询、发邮件、比价、生成PO全部自己实现 |

| system-health.js | ❌ 完全硬编码 | 自己查SCSAI、自己模板覆盖检查 |

| data-clerk.js | ⚠️ 部分硬编码 | 通过 CapabilityRuntime identify 同步，但同步逻辑自实现 |

| cost-optimizer.js | ⚠️ 部分硬编码 | 调用本地 API，不走能力路由 |

| vendor-review.js | ❌ 完全硬编码 | 自己 SCSAI 查询 + 自己生成报告 |

这是架构核心问题——能力框架形同虚设。

二、基于代码现状的优化方案

优化 1：规则引擎语法修复（有代码可修）

文件：rule-engine.js:1570 + generate-operation-rules.js:319

状态：_deserializeRule 的 JSON.parse 已修复，但数据写入端仍是纯文本

// generate-operation-rules.js:319 — 当前错误写入
tags: 'validate,date_format'  // 纯文本！

// 应改为
tags: JSON.stringify(['validate', 'date_format'])  // JSON 数组

操作：改 generate-operation-rules.js 中所有 insRule.run() 的 tags 参数 → 重新跑 node scripts/generate-operation-rules.js --full

影响：修复后 CapabilityRuntime 的 identify/validate 能走规则引擎，不再每次降级 LLM

优化 2：协作链条打通（代码已实现，只差激活）

当前协作基础设施状态：

| 组件 | 代码位置 | 状态 |

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

| taskQueue.createTask() | task-queue.js:38 | ✅ 可用 |

| taskQueue.completeTask() + collaborationNext | task-queue.js:94-113 | ✅ 可用 |

| _processStaffTasks() 消费待办 | lite-scheduler.js:306-329 | ⚠️ 已激活（今日修复） |

| cron 前置处理 | lite-scheduler.js:357-368 | ⚠️ 已激活（今日修复） |

已实现的协作任务创建（今日新增）：

// procurement.js Phase 3 — 采购完成后
ctx.taskQueue.createTask({ assignedTo: 'DS-COST-001', type: 'cost_review' });
ctx.taskQueue.createTask({ assignedTo: 'DS-VEN-001', type: 'vendor_review' });

// vendor-review.js — 评分下降
ctx.taskQueue.createTask({ assignedTo: 'DS-PROC-001', type: 'vendor_alert' });

下次 cron 轮询时：目标员工会先处理协作任务再执行自己的定时任务。

缺失但可以加的：

| 来源 | 协作目标 | 条件 | 代码改动 |

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

| data-clerk 同步完成 | DS-REPORT-001 更新仪表盘 | 有同步数据 | data-clerk.js 末尾 +10 行 |

| cost-optimizer 发现替代料 | DS-PROC-001 重新询价 | 找到替代料 | cost-optimizer.js 末尾 +10 行 |

| content 发布文章 | DS-REPORT-001 生成营销效果报告 | 发布成功 | content.js 末尾 +10 行 |

优化 3：经营日报 MVP（从零开始，不依赖现有 worker）

思路：不走 CapabilityRuntime，直接写一个轻量 worker

代码结构：

server/boss-scheduler/workers/biz-daily.js  (约 120 行)

数据来源：

| 数据项 | 来源代码 | 获取方式 |

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

| 昨日采购订单 | findPurchaseOrders() | 读 data/purchase-orders/*.json |

| 库存预警 | querySCSAIStock() | SCSAI Part.qty_on_hand |

| 供应商评分 | readVendorReports() | 读 data/reports/vendor-review-*.html |

| 系统健康 | readSystemHealthLog() | 读 staffLogs 中最近 health 记录 |

| 内容发布 | queryContentLog() | 读 staffLogs 中 content 记录 |

YAML 配置：

- id: DS-BIZ-001
  name: 小智-经营日报
  title: 经营日报生成器
  description: 每天早7点生成经营日报并推送飞书
  cron: "0 7 * * 1-5"
  worker: report-analyst    # 复用 report-analyst worker 的报告生成能力
  llm: true
  keywords: ["经营", "日报", "利润", "分析", "报告", "business", "daily", "report"]
  params:
    reportType: daily_brief
    channels: ["feishu", "email"]

实现要点：

• 复用 report-analyst.js 的 generateAndSendReport 方法
• 新增 daily_brief 类型，不走 LLM，用模板拼接
• 推送飞书：走现有的 feishu-bot.pushMessage()

优化 4：procurement 走 CapabilityRuntime（架构改动，需谨慎）

现状：procurement.js 是自包含的 9000 字节硬编码

逐步改造方案：

Step 1（不改 procurement.js）：新增 DS-SCM-001 作为能力路由员工

- id: DS-SCM-001
  name: 小智-供应智囊
  capability: create        # 走 CapabilityRuntime Path 2
  item_types: [Vendor, Part, BOM]
  llm: true

此时 DS-PROC-001 保留不动。两个员工并行运行。

Step 2：Procurement v4（不走 worker，走能力链）

// 新文件：server/boss-scheduler/workers/procurement-v4.js
// 仅作为 CapabilityRuntime 的编排层，实际执行走能力
async function runProcurementV4(staff, ctx, intent, parameters) {
  const { capability } = ctx;
  
  // identify — 找供应商
  const vendors = await capability.identify({ 
    item_type: 'Vendor', 
    data: { product, maxResults: 5 } 
  });
  
  // compare — 比价
  const best = await capability.compare({
    item_type: 'Vendor',
    candidates: vendors,
    criteria: { product, quantity, budget }
  });
  
  // create — 生成 PO
  const po = await capability.create({
    item_type: 'PurchaseOrder',
    data: { vendor: best, product, quantity, amount }
  });
}

Step 3：DS-PROC-001 标记 deprecated，DS-SCM-001 成为主入口

优化 5：客户管家 DS-CRM-001（需要新数据表）

当前系统无客户数据的证明：

| 数据 | 来源 | 状态 |

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

| 客户/客户公司 | SCSAI Customer / Company | SCSAI 可能有，当前 AML 不查 |

| 销售订单 | SCSAI Sales Order | SCSAI 可能有，当前不查 |

| 应收账款 | 无数据源 | ❌ 完全缺失 |

| 交付记录 | 无数据源 | ❌ 完全缺失 |

两步走：

Step 1：添加 SCSAI 客户查询能力

// capability-runtime.js identify 方法中
// 识别 item_type: 'Customer' 时查 SCSAI
const aml = `<AML><Item type="Customer" action="get" select="id,name,email,phone" maxRecords="50"></Item></AML>`;

Step 2：新增本地 customers 和 orders 表

CREATE TABLE customers (
  id TEXT PRIMARY KEY,
  name TEXT, email TEXT, phone TEXT,
  company TEXT, credit_limit REAL, 
  last_order_date TEXT, total_orders INTEGER
);

CREATE TABLE orders (
  id TEXT PRIMARY KEY,
  customer_id TEXT, product TEXT, quantity INTEGER,
  amount REAL, status TEXT, delivery_date TEXT,
  payment_status TEXT
);

三、分阶段实施路线（基于代码实际）

| 阶段 | 内容 | 工期 | 核心文件 | 前置依赖 |

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

| P0 | 规则引擎 tags 修复 + 重新生成数据 | 30分钟 | generate-operation-rules.js | 无 |

| P0-2 | 协作链条补全（data-clerk+content+cost） | 1小时 | 各 worker 文件末尾加 10 行 | 无 |

| P1 | 经营日报 DS-BIZ-001 | 半天 | workers/biz-daily.js (新增) | 无 |

| P2 | procurement v4 能力化（DS-SCM-001 并行运行） | 1天 | workers/procurement-v4.js | P0 |

| P3 | CRM 客户数据通道（SCSAI Customer 查询） | 1天 | capability-runtime.js | 无 |

| P4 | 前端老板仪表盘重构 | 1天 | DigitalStaff.vue + 新页面 | P1 |

建议启动顺序：P0 → P1 → P0-2 → P2 → P3 → P4

执行 P0（30分钟修复规则引擎）+ P1（半天经营日报），让老板明天就能在飞书看到日报，这是最快的见效路径。

四、技术债务总结（必须面对）