BossAgents 第二层：组合 + 自演化 — 而非新建

一、重新认识已有积累（我上次看浅了）

数据库存量（sciot_import.db）

| 领域 | 规则数 | 覆盖的SCSAI类型数 | 关键对象 |

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

| 财务/会计 | 173条 | 42种 | acc_AccountsReceivable, acc_ProfitandLoss, acc_BalanceSheet… |

| 销售/订单 | 142条 | 20种 | sop_sale_order, sop_delivery_order, sop_sale_invoice… |

| 采购 | 55条 | 8种 | pop_purchase_order, pop_purchase_request… |

| 库存 | 47条 | 14种 | stk_stock_setup, stk_issue, stk_replenish… |

| 文档 | 48条 | 3种 | Document, File |

| 项目 | 40条 | 3种 | Project, WBS Element… |

| Part | 35条 | 3种 | Part, BOM |

| 客户 | 7条 | 1种 | Customer（规则已存在！） |

| 供应商 | 4条 | 1种 | Vendor |

| 变更管理 | 11条 | 3种 | ECR, ECN |

2,306条规则已覆盖全部核心业务领域，并非只有IT运维。

已建成但未激活的关键能力

二、正确方向：能力组合（Composition）而非新建

当前每个员工只绑定一种能力（procurement用create, DS-ECR用validate, DS-VEN用validate...）。

真正的威力是让一个员工顺序调用多个能力，形成工作流管道（pipeline）。

组合模式示例

核心业务管道（无需 worker 脚本，全部走 CapabilityRuntime）：

输入 → [identify] → [validate] → [repair] → [create] → 输出
         ↓           ↓            ↓          ↓
       查数据      校验问题     自动修复    新建对象

实际场景举例：

场景1：供应商绩效检讨
  identify(Vendor, score<60)     → 查出低分供应商
  compare(Vendor, candidates)     → 对比其他供应商价格
  create(Alert)                   → 生成预警 + 协作任务

场景2：订单利润实时核算
  identify(sop_sale_order, today) → 查出今日订单
  identify(Part, order_items)     → 查出涉及的物料成本
  compare(cost vs price)          → 计算每个订单的利润率
  create(Report)                  → 生成利润报告

场景3：库存短缺自动补货
  inspect(stk_stock_setup)        → 巡检库存水位
  identify(Vendor, top_rated)     → 查最优供应商
  create(pop_purchase_request)    → 自动生成采购申请

核心改造：LiteScheduler Path 2 增强

当前 Path 2 只调用单一能力。改为能力管道模式：

- id: DS-BIZ-001
  name: 小智-经营大脑
  worker: ""                                   # 无脚本，纯能力组合
  pipeline:                                     # ★ 能力管道
    - capability: identify
      item_types: [sop_sale_order, acc_ProfitandLoss, stk_stock_setup]
    - capability: compare
      context: { mode: "computed" }
    - capability: generate
      output: "report"

调度器执行逻辑变为：

1. 调用 identify(sop_sale_order) → 拿到原始数据
2. 把上一步结果作为 context 传给 compare → 计算比对
3. 再把结果传给 generate → 输出 HTML 报告/飞书消息

这不需要写任何 worker 脚本，完全基于已有的 rule-engine + capability-runtime。

三、自进化激活（Self-Evolution）

系统已有完整闭环框架，只是没通：

用户修正 → sciot_corrections → pattern检测 → sciot_rule_candidates → 审批 → 新规则
修正记录表        候选规则表
(当前0条)         (当前0条)

要点

1. 规则引擎已自带命中统计

-- sciot_rules_v2 已有字段：
hit_count, last_hit_at, avg_duration_ms, user_correction_count

这些字段当前都是0，需要在调度器执行时回写。

2. LLM 对比用户修正和原始输出，自动生成候选规则

• 修正积累超过阈值（如同一类型≥3条）→ 触发规则候选生成
• LLM 分析修正模式 → 输出候选 AML/condition → 写入 sciot_rule_candidates
• 低风险候选（P3）自动批准，高风险（P0-P1）人工审核

3. 从 execution_logs 反向驱动

• 2,557条日志分布在活跃员工中
• 解析错误模式 → 回写 sciot_rule_history
• 高频错误类型 → 触发 repair 规则候选

四、协作链激活

现有资源

• staff_tasks 表已存在
• task-queue.js 已实现 createTask() / completeTask()
• _completeTaskForStaff() 有 collaborationNext 参数但从未传递

改动量极小

在 lite-scheduler.js 的 _completeTaskForStaff() 加入一段规则匹配：

// 执行完成后，检查是否需要创建接力任务
const chainRule = this._getCollaborationChain(staff.id, result);
if (chainRule) {
  const taskQueue = require('./task-queue');
  await taskQueue.createTask({
    targetStaffId: chainRule.target,
    taskType: chainRule.taskType,
    payload: { triggeredBy: staff.id, result }
  });
  staffLog('info', `→ 创建协作任务给 ${chainRule.target}`);
}

协作规则可配置在 local.yaml 中：

# 每个员工新增 collaboration 段
- id: DS-PROC-001
  collaboration:
    onComplete:
      - target: DS-VEN-001
        condition: "result.supplierCount > 0"
        taskType: "update_vendor_scores"
      - target: DS-COST-001
        condition: "result.poAmount > 50000"
        taskType: "recalculate_margin"

五、立即可行的三个高价值场景

场景 A：经营日报（组合 identify + generate）

不需要新 Agent。在 DS-REPORT-001 的 pipeline 中加入：

1. identify(sop_sale_order, yesterday) → 昨日订单
2. identify(acc_ProfitandLoss)         → 昨日利润
3. identify(stk_stock_setup, low)      → 库存预警
4. identify(Vendor, score_changed)     → 供应商变动
5. generate(report)                    → 输出HTML/飞书

场景 B：客户订单追踪（组合 identify + validate + alert）

1. identify(sop_sale_order, overdue)     → 查出超期订单
2. validate(sop_delivery_order, delayed)  → 校验交付延迟
3. create(Alert)                          → 推送老板

场景 C：供应链自动修复（组合 identify + repair — 填补0规则的空白）

这是关键的第一步——先写 repair 规则：

1. identify(Vendor, score<60)        → 查出问题供应商
2. repair(Vendor, score<60)          → 自动生成修复建议
   （自动标注 under_review，发送询价给后备供应商）

六、执行建议

第1优先：写 repair/optimize/compare 规则（2天）

当前这三个 scope 在 rule-engine.js 中代码完整，但 DB 中 0条规则。

用已有的 LLM 规则生成能力（_autoGenerateRule）从 execution_logs 和模板数据批量生成。

第2优先：增强 LiteScheduler 支持 pipeline（3天）

• 修改 Path 2 执行逻辑：从单次 capability.call() 改为顺序遍历 staff.pipeline[]
• 每个步骤的输出作为下个步骤的上下文输入
• 完成后写入 chain 检测

第3优先：激活自进化闭环（1天）

• 在 capability-runtime 执行后添加 result 回写（hit_count, last_hit_at）
• 在 sciot_corrections 有 3+ 同类修正时触发候选规则生成

第4优先：协作链激活（1天）

• _completeTaskForStaff() 加入 20 行规则匹配代码
• yaml 配置 collaboration 段

七、关键理念转变

| 旧思维（我的方案） | 正确方向（您已建好的基础） |

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

| 建4个新的Big Agent | 组合已有13个员工的能力 |

| 写新的 worker 脚本 | 纯能力管道，不走 worker |

| 从头设计协作 | 已有 staff_tasks 表，只需激活 |

| 从零补充业务数据 | 已有40K属性+2K规则+ERP/财务对象 |

| 先做新功能 | 先写 repair/optimize 规则（0→有） |

| 自进化需要新系统 | 已建 sciot_corrections + candidates 表，只差激活 |

系统的 DNA 已经是正确的：规则引擎驱动 → 7大基础能力 → 任意组合 → 自运维 + 自进化。我没有真正理解已有的 57 张表、2,306 条规则和 40K 属性的广度。

下一阶段的核心工作不是"造什么"，而是"连什么"：

1. 补齐 repair/optimize/compare 的规则（0→有）
2. 激活 pipeline 组合模式（单一能力→多步管道）
3. 激活 自进化闭环（修正→候选→批准）
4. 激活 协作链（员工间接力任务）