六能力功能现状分析

时间: 2026-07-10

仓库: D:\openclaw\bossagents\

一、整体架构

HTTP 请求
  ├─ POST /api/unified/create   ──→  unified-create.js（独立路径）
  │
  └─ POST /api/capability/*      ──→  CapabilityDispatcher.execute()
                                           ├─ normalizeParams()
                                           └─ CapabilityRuntime[capability]()
                                                    │
                         ┌──────────────────────────┴────────────────────────┐
                         ▼                                                  ▼
               试规则引擎（rule_engine）                              规则引擎无匹配 → LLM降级
               execute{Capability}()                                     _callLLMViaRouter()
                         │
                         ▼
               _buildRepairAML / _applyOptimizeAction → SCSAI applyAML

二、各能力现状

1. create ✅ 可用（独立体系）

• 路径：unified-create.js → 7步流水线 → SCSAI 直写AML
• 6类主业务（Project/Product/Part/Vendor/Customer/ECN）均已验证真实落库
• 与其他5个能力完全独立

2. repair ⚠️ 表面可用，实际"假修复"

规则现状（8条内置）：

| 规则 | 检查内容 | 实际行为 |

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

| repair-001 | 编号格式 invalid_format | 触发条件模糊，难以命中 |

| repair-002 | name 字段为空 | ✅ 可检测 |

| repair-003 | Vendor 税号/地址缺失 | ✅ 可检测 |

| repair-004 | 单位非标准（pcs→PC） | ✅ 可修复 |

| repair-005 | 价格异常（>10万或<0.001） | ✅ 可检测 |

| repair-006 | 无效引用（含{null{undefined}） | ✅ 可检测 |

| repair-007 | VendorQuote 涨价>5% | ⚠️ 需 last_unit_price 字段 |

| repair-008 | Vendor 信息自动补全 | ⚠️ 生成"待补充-xxx"占位符 |

| repair-009 | 库存低于安全库存→生成采购申请 | ⚠️ 需 stk_stock_setup 类型 |

核心缺陷：

• auto_apply 默认为 false → 默认只"识别问题"不写回SCSAI
• 写回路径存在（_applyRepairToARAS），但默认不触发
• 修复后验证存在（executeValidate），但依赖 options.arasClient 传参
• 最关键：规则只覆盖"特定已知问题"，无法处理"任何可能出现的问题"
• 例如：Part 的 classification 字段缺失 → 无规则
• 例如：Product 的 keyed_name 格式错误 → 无规则
• 例如：关系对象缺失 → 无规则

3. optimize ❌ 假优化

规则现状（5条内置）：

| 规则 | 检查内容 | 实际行为 |

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

| optimize-001 | name/description 数据标准化 | 仅 suggest，从不 auto_fix |

| optimize-002 | Part BOM成本分析 | 仅 suggest（文本建议） |

| optimize-003 | Vendor 供应商评分<75 | 仅 suggest（文本建议） |

| optimize-004 | 库存周转率<2 | 仅 suggest（文本建议） |

| optimize-005 | ECR审批>7天 | 仅 suggest（文本建议） |

核心缺陷：

• 所有规则 action_type: 'suggest' → 从不走 auto_fix
• 没有任何字段实际写入SCSAI
• 不存在"优化后对象符合某标准"的概念
• auto_apply 参数存在但无人调用

4. compare ✅ 基础可用

• 对比两个对象，输出字段差异列表
• 有3条规则（字段差异、版本变更、供应商对比）
• 属于"分析展示"类，结果是报告，不是动作
• 无写回机制：比对出来的差异不会自动同步

5. identify ✅ 可用（但有死代码）

• L879 的 SCSAI 查询型：实际可用，rule_engine + LLM 降级
• L772 的资产目录型：死代码，无调用路径
• 属于"查询识别"类，输出 SCSAI 数据

6. generate ⚠️ LLM 降级兜底

• 有 rule_engine.executeGenerate 路径（查 prompt_templates 表）
• 模板为空时降级到 LLM 路由
• 属于"内容生成"类，可生成结构化对象内容
• LLM 生成的内容需要配合 create 路径才能落库

三、核心问题根因

问题1：repair 和 optimize 的"正确状态"未定义

任何修复都必须先知道"正确是什么"。 当前系统：

• VALIDATE 规则定义了"什么是错的"（必填字段、格式、逻辑）
• 但没有定义"什么是正确的 Part / Product / Vendor"
• 因此 repair 只能修复"已知错误"，无法处理"未知错误"
• optimize 只能提建议，无法定义"优化目标"

对比：SCSAI 的 create 路径是完整的——有模板 → 有必填字段 → 有默认值 → 有序列号 → 关系预创建 → AML 生成。只有这套东西完整，create 才真正work。

repair 和 optimize 也需要这样一套完整的"正确性定义"：

正确性定义（每个 ItemType 都需要）
  ├─ 必填字段（不能为空）
  ├─ list 字段可选值（不能超范围）
  ├─ 字段逻辑约束（结束日期≥开始日期）
  ├─ 业务规则（Vendor 必须有税号 / Part 必须有单位）
  ├─ 关系完整性（Product 必须有 Model 关系）
  └─ 编号规范（格式正则匹配）

问题2：修复后验证缺失

即使 repair 规则能检测并修复，修复后的对象没有强制验证流程：

• 当前：修复 → 写回 SCSAI → 调用 VALIDATE scope → 如果有 error 级别规则失败，设置 repair_validation_failed: true
• 但 repair_validation_failed: true 不会阻断返回，只作为一个 extra 字段
• 调用方可能不知道修复失败了

问题3：optimize 完全是文本建议

optimize-001 数据标准化 的 action_script：

// 只是字符串操作，不写回任何字段
var normalized = value.trim().replace(/\s+/g, ' ');
return { fixed: true, changes: { [field]: normalized } };

即使返回了 changes，optimize 路径没有 _applyOptimizeAction 的默认调用（只有 auto_apply=true 才调用）。

问题4：identify 有两套实现

L772 和 L879 都叫 identify()，后者覆盖前者。L772 的资产目录型（autoClassify + detectDuplicate）从未被调用，属于死代码。

四、修复方案方向

核心原则

每个能力必须有明确承诺：完成后的对象是什么状态

• repair 承诺：无 error 级别 VALIDATE 规则失败
• optimize 承诺：符合某业务标准（需定义）
• 巡检承诺：定期扫描 + repair 直到无 error

P0 修复项

1. repair 后置验证强制化

• 修复写回后必须运行 VALIDATE scope
• 如果有 error 级别规则失败 → 标记 repaired: false，记录未解决问题
• 调用方必须处理未完全修复的情况

1. optimize 实现 auto_fix 路径

• optimize-001 数据标准化 改为 action_type: 'auto_fix'
• 添加 _applyOptimizeAction 默认调用路径（当 auto_apply 未指定时继承 context 设置）
• 定义每个 ItemType 的"优化目标标准"

1. VALIDATE 规则补全

• 当前 VALIDATE 规则：6条（Project专用3条 + 通用4条）
• 缺少：Product/Part/Customer/ECN 的必填字段规则
• 缺少：关系完整性规则（某类型必须有某关系）

1. repair 的"正确性定义"扩展

• 为每个核心 ItemType 添加业务规则：
• Part：必须有 unit/unit_cost / classification / keyed_name
• Product：必须有 Model 关系（类型B）
• Vendor：必须有 tax_id / address
• ECN：必须有 affected_items
• 当规则检测失败 → repair 能自动修复或明确报告无法修复

1. 巡检（patrol）能力实现

• 基于 repair 能力，循环扫描对象列表
• 发现问题 → repair → 验证 → 记录
• 周期性执行（cron）

P1 修复项

1. identify 死代码清理（L772 删除或标记废弃）
2. compare 结果写回机制（比对出的差异可选择性同步）
3. generate 与 create 的桥梁（LLM 生成的内容直接落入 create 流水线）

五、现状与目标的差距