BossAgents 实时演示能力评估 — 实测复核（2026-07-31）

方法：对源码做静态扫描 + 对运行中服务（端口 3006）做真实 HTTP 调用复核。

结论：三个演示场景都能真正工作；但原文分析在多处数字/工具清单/路由机制上已过时或有误，下面逐条校正。

一、已实测可用的三个演示场景（证据）

| 场景 | 端点 | 实测结果 |

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

| 1. 查询 P-1001 影响范围 | POST /api/change/analyze | ✅ 仅传 {"description":"查询 P-1001 的影响范围","change_type":"part"}（无 target_id），系统自动从文本正则提取零件号→查 SCSAI→解析出 SCSAI ID 284C6CFC12B34FACA25A416B3D2CD897，返回 affectedParts / affectedModels / affectedProducts 影响链 |

| 2. 运行数据质量巡检 | POST /api/ai-inspector/inspect | ✅ 返回 summary：totalChecked:1517, issuesFound:28, autoFixable:4, manualFix:24（model 范围 P2）；/inspect-stream 与 /fix-stream 也已挂载 |

| 3. 查看最近治理记录 | GET /api/audit-logs?days=7 | ✅ 返回 logs 数组（7 天窗口内如 36312 条），结构化分类/级别；/api/ai-inspector/last-result 也返回上次巡检结果 |

附加确认：/api/health 200；/api/change/stats 200（ECR 28 / ECO 1 / ECN 14）；/api/digital-staff/logs?staffId=DS-STAT-001 200（DS-STAT-001 真实存在，但近期无执行日志 total:0）。

二、对原文分析的关键校正

1. 数字员工数量：原文列 11 个 → 实际 37~38 个

源码 server/digital-staff/ 全量扫描到 38 个唯一 DS-* 标识（含 DS-SCSAI-001、DS-STAT-001、DS-DOC-001、DS-ECR-001、DS-PROC-001、DS-VEN-001、DS-DATA-001/002、DS-PLM-BRAIN-001，以及新增的 DS-CHIP-001~007、DS-BIZ-001、DS-KNOWLEDGE-001 等）。原文清单是早期快照，已显著扩张。原文"按 ID 列出 11 个"已过时。

2. 内置意图引擎规则：原文列 20 个 → 实际 15 个，且名称不一致

server/core/intent-engine.js 中 BUILTIN_INTENT_RULES 实测工具名（15）：

search_item_types, inspect_quality, get_governance_history, send_inquiry, check_quotations, procurement_decide, send_purchase_order, search_1688_sourcing, search_anysearch, search_sourcing, start_email_listener, procurement_workflow, boss_confirm_procurement, run_compliance_inspection, dashboard_summary

与原文差异（原文是旧版）：

• 原文中的 query_bom / query_inventory_analysis / query_employee_info / query_complaint_analysis / generate_quality_report / repair_object_class / change_bom_component 在代码中已不存在。
• 代码实际含原文未列的 inspect_quality、get_governance_history。

3. 规则数量：原文 10,687 → 实测 12,507

server/data/rule_engine.db 的 sciot_rules_v2 表 COUNT = 12,507（含内置 + 标准库 + 对象类规则）。/api/ai-inspector/inspect 的 model 范围实测检查 1,517 条（子集）。原文 10,687 为旧数。

4. 路由机制描述有误（功能不受影响）

原文称"router.post('/analyze') 第 1548 行"等 express 风格路由。实际系统不是 express router，而是 server.js 的统一 if (pathname.startsWith('/api/change/')) 派发到各 route 模块内部按 pathname 二次分发（change.js 用 url.startsWith('/api/change/analyze')）。端点路径本身与原文一致且可用，只是"机制描述"不成立。

5. 审计日志端点：原文正确，但挂载变量名不同

server.js 用 if (pathname.startsWith('/api/audit-logs')) auditLogRoutes(...) 整体派发；audit-log.js 导出 handleAuditLogApi 并支持 /api/audit-logs 与 /api/audit-logs/risks。实测可用。原文"端点 #2 GET /api/audit-logs"成立。

6. ai-inspector 子端点：原文多列了，部分在 server.js 未逐条命名但整体可用

server.js 把整个 /api/ai-inspector/* 命名空间转发给 aiInspector 模块（aiInspector 初始为 null，运行时惰性加载；实测已加载，否则会 501）。模块内部路由 /inspect、/inspect-stream、/fix-stream、/logs、/last-result、/itemtypes、/rules 均存在且可用（实测 /inspect、/last-result 成功）。原文列的子端点基本属实，但 server.js 不做逐条路由注册，靠模块内部分发——这点原文未说明。

三、六能力与 ToolRegistry：原文正确

• capability-runtime.js 六种能力（identify/validate/repair/optimize/compare/generate）全部存在。
• ToolRegistry 仅从 process-optimization-tools.js 注册 PROCESS_OPTIMIZATION_TOOLS，属较新子系统，尚未广泛使用——与原文一致。

四、真实风险提示（原文未充分覆盖）

1. NL→API 路由真实链路：前端 AiWorkbench.vue 的 checkKeywordRoute + 后端 /api/staff/match（关键词加权 + IntentEngine L1/L2/L3 降级）确实能把"数据质量巡检""治理记录"等意图路由到对应员工/端点；但"影响范围/P-1001"这类变更影响分析意图，原文承认需关键词命中文档员工（DS-DOC-001 含"影响分析/影响范围/影响评估"）。实测中影响分析 API 本身很强（自动解析零件号），但自然语言入口是否稳定命中取决于前端关键词表是否含"影响"——建议演示前人工点开文档员工输入，或确认关键词路由已覆盖。

1. 巡检全量模式耗时：12,507 条规则在 scope:all 下可能 >30s。已提供 /inspect-stream SSE 实时进度，演示建议走流式版。

1. aiInspector 惰性加载：若服务刚启动且模块未初始化，首次 /api/ai-inspector/* 会返回 501"未启用"。实测当前已加载，但演示环境需确认预热。

1. DS-STAT-001 近期无执行日志（total:0）——独立 cron 巡检可能未持续触发，演示时建议手动触发一次以展示日志流。

五、结论

• 三个演示场景均真实可用，无需为"能不能工作"担忧。
• 原文的分析框架（分层工具注册 / 多场景端点 / 多级路由 / 前端界面）方向正确，但具体数字（数字员工 11→37、意图工具 20→15、规则 10,687→12,507）与工具清单、路由机制描述已过时/有误，应以本实测为准。
• 演示前唯一需确认的是：影响分析的自然语言入口命中 + 巡检走流式端点 + 服务已预热（aiInspector 已加载）。