岗位助手 V2.0 + 稳定性治理 交付总结
日期:2026-08-09
状态:✅ 全部完成并验证通过
一、交付目标
- 云服务器死机治理 — 找出"运行一会死机"根因并落地治理开关
- core_runtime.db 损坏修复 — 数据库损坏导致核心链路报错
- 岗位助手 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(部分运行记录写不出) - 步骤:
- 备份原文件
core_runtime.db.bak-20260805-202823 - 用
sqlite3 .recover命令(chocolatey 3.51.2)导出core_recover.sql - 导入为全新 db,恢复 94-102 张表(含 52 行缓存数据,可回源 SCSAI)
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_usersagents[]— 岗位关联的智能体组合(多对多,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.yaml → positions: 段增加 - 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 | 岗位入口与文案 |
八、遗留项
server/ai-agent.js:1513resume_staff 的require('../boss-scheduler/index')相对路径 bug 仍未修(此前被链路端到端验证阻塞,不影响演示)- 岗位助手的反馈后台(管理视图)、岗位级权限、更多场景库(每岗位可扩至 消费10-20 场景)均可后续迭代
九、六大能力验证(2026-08-10)
验证结果
| 能力 | 入口 | 结果 | 说明 |
|---|---|---|---|
| 识别 identify | POST /api/capability/identify | ✅ | item_type=Part 返回 1242 条;修复前 500 |
| 创建 create | POST /api/capability/create | ✅ | 复杂嵌套创建成功(主件+2 BOM 子件+数量) |
| 修复 repair | POST /api/capability/repair | ✅ | mode=preview 正常返回 |
| 优化 optimize | POST /api/capability/optimize | ✅ | executed=true |
| 比对 compare | POST /api/capability/compare | ✅ | 正常返回 |
| 生成 generate | POST /api/capability/generate | ✅ | item_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:
ensureItemType自动调smartCreateItemType→ SCSAI 侧对象类真实创建成功(id=F0337BD8, label 正常)- 随后实例创建成功(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)
BossAgents