岗位助手 V2.0 + 稳定性治理 交付总结

岗位助手 V2.0 + 稳定性治理 交付总结

日期:2026-08-09

状态:✅ 全部完成并验证通过


一、交付目标

  1. 云服务器死机治理 — 找出"运行一会死机"根因并落地治理开关
  2. core_runtime.db 损坏修复 — 数据库损坏导致核心链路报错
  3. 岗位助手 V2.0 — 以"10 个制造业岗位"为主页的数字员工平台改版(岗位配置层 + API + 反馈闭环 + 前端重组)

二、死机治理(根因 + 方案)

根因(证据闭环)

  • 启动日志注册 62 行 cron 定时任务(41 个员工 + loop/goal 循环),
  • 每小时 ×3(DS-STOCK-LOOP / DS-DATA-SYNC / DS-SPC 巡检)、每 2 小时 ×5、
  • 每个任务 = SCSAIPLM 查询 + LLM 调用 + 同步 better-sqlite3 写库
  • 主进程实测 878MB 内存 / 279.9 秒 CPU(单次启动)
  • 多个整点任务同时点火 → 低配云服务器资源耗尽 → 死机

治理方案(环境变量开关,默认行为不变)

| 开关 | 位置 | 作用 |

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

| BOSS_SCHEDULER_CRON=off | server/boss-scheduler/lite-scheduler.js start() | 不注册任何定时 cron,手动 runStaffOnce 不受影响 |

| BOSS_HEAVY_BG=off | server.js | 跳过自进化管道、RuleDrift 对账(60s)、定时/首次数据采集 |

云服务器 .env 追加两行即可,开发机不带开关行为不变。

验证结果

  • off 模式:日志确认 4 处开关生效;health / llm-config / status 正常;手动执行链路可用
  • 默认模式回归:62 cron + 自进化管道照常注册(行为兼容)

三、core_runtime.db 损坏修复

  • 现象:better-sqlite3 报 database disk image is malformed(部分运行记录写不出)
  • 步骤:
  1. 备份原文件 core_runtime.db.bak-20260805-202823
  2. sqlite3 .recover 命令(chocolatey 3.51.2)导出 core_recover.sql
  3. 导入为全新 db,恢复 94-102 张表(含 52 行缓存数据,可回源 SCSAI)
  4. PRAGMA integrity_check=ok,重启无 malformed 报错

四、岗位助手 V2.0(核心交付)

4.1 岗位配置层(纯配置,不改引擎)

server/boss-scheduler/profiles/local.yaml 末尾新增 positions: 段,10 个制造业岗位:

| 岗位 ID | 名称 | 职责定位 |

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

| POS-OPERATOR | 车间操作工 | 产线执行、设备点检、报工 |

| POS-QA | 质检员 | 来料/过程/成品检验、质量记录 |

| POS-PROCESS-ENG | 工艺工程师 | 工艺卡片制作、变更管理 |

| POS-SCHEDULER | 生产调度员 | 计划排产、订单跟踪 |

| POS-EQUIP | 设备维护员 | 点检维护、故障报修 |

| POS-STOCK | 仓库管理员 | 出入库、库存查询 |

| POS-FINANCE | 财务专员 | 成本核算、发票对账 |

| POS-PROCURE | 采购专员 | 请购转采购、供应商管理 |

| POS-BOSS | 老板/管理者 | 经营总览、决策辅助 |

| POS-IT | 系统管理员 | 系统巡检、用户账号 |

每个岗位含字段:

  • name / slogan / description / target_users
  • agents[] — 岗位关联的智能体组合(多对多,3-5 个)
  • scenarios[] — 预置场景(3 个一键体验)
  • related_rules[] / feedback_points[] / process_steps[](流程透明 5 步)

多对多关联:一个岗位挂多个智能体(如老板助手 5 个);一个智能体服务多个岗位(如 DS-SPC-001 同时服务操作工 + 质量)。

4.2 后端 API

| 接口 | 说明 |

|---|---|

| GET /api/digital-staff/positions | 全部岗位 + 关联智能体完整信息(total=10) |

| POST /api/feedback | 提交体验反馈(必须带 content) |

| GET /api/feedback?position_id=&category=&status=&page= | 按条件查反馈 |

| GET /api/feedback/stats | 按岗位/分类/状态统计 |

反馈数据落 server/data/feedback.db(server/routes/feedback-routes.js 独立模块)。

踩坑记录:反馈 SQL 统计 WHERE position_id != "" 会被 better-sqlite3 当列名报错 — 必须用单引号 ''

4.3 前端岗位首页(作为项目首页)

  • 路由:/ 重定向到 /positions(岗位助手 = 默认首页)
  • 布局(src/views/PositionsView.vue):
  • 10 岗位卡片阵列(卡片=岗位名 + slogan + 智能体数/场景数)
  • 工具箱卡片(数字员工总览/任务看板入口,虚线样式)
  • 内容/营销/客服/文档 保留区按钮
  • 岗位详情抽屉:
  • 组合智能体列表(点击 → #/ai-workbench?runStaffId=xx&runIntent=xx)
  • 预置场景一键体验(quickRun 跳转 AI 工作台自动执行)
  • 规则标签 + 流程透明 5 步展示
  • 体验反馈表单(提交 → POST /api/feedback)
  • 导航入口:navGroups.js 增加 flat 首项 positions,i18n 增加 nav_positions 中/英

4.4 构建与 E2E 结果

  • npm run build 成功(生成 dist/views-positionsview 独立 chunk)
  • /api/digital-staff/positions → total=10,页面 [200]
  • 反馈闭环 POST → GET(按岗位过滤)→ stats 全链路通过
  • 静态资源 200,首页可访问

五、路由隐患排查修复(验证中发现)

验证 /api/digital-staff/run-detail 时发现新旧路由层共存的三个真实 bug:

| Bug | 现象 | 根因 | 修复 |

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

| reload 无限挂起 | POST 不回包、客户端卡 10s 超时 | reload 不在新路由层 oldPaths 白名单,请求被新层吞掉 | 白名单加入 /api/digital-staff/reload |

| 未知路径静默挂起 | 任意不在白名单的 API 无响应 | staffRoutes 返回 false 后无兜底 | false → 明确 404 未找到数字员工接口 |

| tasks/ 动态路径被吞 | /tasks/:id/:action 超时 | 精确匹配白名单不包含动态子路径 | 增加 pn.startsWith('/api/digital-staff/tasks/') 前缀匹配 |

回归套(修复后全绿):

  • reload → 200 OK;未知路径 → 快速 404;tasks 前缀 → 404(不再挂起)
  • health / status / positions / llm-config / run-detail?runId= / loops / feedback-stats 全 200
  • 测试反馈数据已清理,服务器已停止,端口释放

六、使用与运维

云服务器防死机(2 行即可)

# .env 追加
BOSS_SCHEDULER_CRON=off
BOSS_HEAVY_BG=off

岗位配置扩展(新增岗位只需改 YAML)

local.yamlpositions: 段增加 - id: POS-XXX ... 后重启(或调用 POST /api/digital-staff/reload 热刷新)。

前端构建

npm run build   # 产物 dist/,由 server.js 静态托管

反馈数据查看

sqlite3 server/data/feedback.db "select * from feedback order by id desc limit 10"

七、关键文件清单

| 文件 | 说明 |

|---|---|

| server/boss-scheduler/profiles/local.yaml | 员工 61 条 + positions 10 岗位配置 |

| server/boss-scheduler/staff-registry.js | loadPositions() 加载岗位配置 |

| server.js | positions/reload 路由 + 治理开关 + oldPaths 白名单修复 |

| server/routes/feedback-routes.js | 反馈闭环(新增) |

| server/routes/digital-staff-routes.js | 新路由层(未知路径 404) |

| server/data/feedback.db | 反馈数据(新库) |

| server/data/core_runtime.db | 已重建(损坏备份:core_runtime.db.bak-*) |

| src/views/PositionsView.vue | 岗位首页(新) |

| src/router/index.js | /positions 路由 + 默认重定向 |

| src/constants/navGroups.js / frontend/i18n.js | 岗位入口与文案 |


八、遗留项

  1. server/ai-agent.js:1513 resume_staff 的 require('../boss-scheduler/index') 相对路径 bug 仍未修(此前被链路端到端验证阻塞,不影响演示)
  2. 岗位助手的反馈后台(管理视图)、岗位级权限、更多场景库(每岗位可扩至 消费10-20 场景)均可后续迭代

九、六大能力验证(2026-08-10)

验证结果

能力入口结果说明
识别 identifyPOST /api/capability/identifyitem_type=Part 返回 1242 条;修复前 500
创建 createPOST /api/capability/create复杂嵌套创建成功(主件+2 BOM 子件+数量)
修复 repairPOST /api/capability/repairmode=preview 正常返回
优化 optimizePOST /api/capability/optimizeexecuted=true
比对 comparePOST /api/capability/compare正常返回
生成 generatePOST /api/capability/generateitem_type=Part 生成内容成功;修复前 500

新修复的 Bug:识别/生成 500(元数据表缺失)

  • 根因: rule-engine.js _recoverMetaIfEmpty() 源库路径指向 rule_engine.db(自己),但 sciot_properties(41240条)/sciot_item_types(1217)/sciot_relationships(587)等元数据实际在 sciot-metadata.db → 恢复永远不生效 → executeIdentify/executeGenerate 查询 no such table: sciot_properties → 500
  • 修复: _recoverMetaIfEmpty 源库优先 sciot-metadata.db,缺失回退 rule_engine.db(已生效,六表全部恢复)

"无对象类先创建对象类" 验证通过

  • 用不存在的对象类 QA_CapTest_Obj/api/unified/create:
  1. ensureItemType 自动调 smartCreateItemTypeSCSAI 侧对象类真实创建成功(id=F0337BD8, label 正常)
  2. 随后实例创建成功(5C95A9FC)
  • 复杂嵌套创建(Part BOM 两条):主件 9061C088 → 子件 QA-BEARX-001(qty=2) + QA-COVX-001(qty=1),SCSAI 查询验证真实落库
  • 全链路测试数据已清理(对象类/实例/BOM 残留=0)

注意(创建参数格式)

  • /api/unified/create 参数为 camelCase: itemType / properties / relationships / itemProperties
  • 嵌套关系子对象标准格式: related_items: [{ properties: {...}, item_properties: {...} }]
  • related 字段会被忽略(需 related_items)
← 返回案例列表
分享:
🤖 Try Now →
🤖
🎁