整体系统架构
平台中心架构：multuex-engine 多智能体平台是架构中心与能力总线；tigo-loop 是第一个领域分支项目；工作台是统一人机入口——平台管能力 · 领域管规则 · 工作台管入口
心智模型（三句话）：平台管能力——智能体、工具、记忆、设备接入都长在 multuex-engine 上；领域管规则——tigo-loop 只是第一个领域分支，状态机、关闭闸门等业务规则在领域层执行；工作台管入口——人与企微消息的统一出入口。
因此 ERP/PLM/客服/知识库这些企业能力注册到平台的工具代理层，未来任何领域项目（不只售后）的智能体都能调用——这是与上一版最大的修正。
因此 ERP/PLM/客服/知识库这些企业能力注册到平台的工具代理层，未来任何领域项目（不只售后）的智能体都能调用——这是与上一版最大的修正。
领域项目与平台的关系 为什么这样分
| 层次 | 管什么 | 不管什么（刻意隔离） |
|---|---|---|
| 智能体平台 multuex-engine · 中心 | 智能体运行、企业能力注册（工具代理）、设备接入（节点网关）、记忆/技能/审计/模型 | 不写业务规则——时限、闸门、状态机判定不在平台 |
| 领域项目 tigo-loop 为第一个 | 自己的表单、状态机、规则引擎、数据库、关闭硬校验；把领域能力注册为平台工具供智能体调用 | 不碰企微凭据、不直连其他领域数据库 |
| 工作台 tigo-workbench · 入口 | 登录发证、统一壳与导航、企微消息网关、各领域 /api/* 反代 | 不含业务逻辑 |
外部系统接入规划 全部注册到平台工具代理，全领域共享
| 系统 | 交换内容 | 方向 | 集成方式 | 阶段 |
|---|---|---|---|---|
| ERP | 物料库存与价格、请购单回写、供应商交期（变更协调智能体风险预测的数据源） | 双向 | API（M2 只读 → M3 写） | M2 读 / M3 写 |
| PLM | 图纸/BOM/程序版本受控发布（ECN 七项校验第 1 项的数据源）、BOM 差异（影响面四数） | 入 | API / 受控文件同步 | M3 |
| 客服系统 | 客服工单与客户反馈 → AI 识别后生成建单候选（受理助理扩展） | 入 | API / 事件订阅 | M3 / 规划 |
| 外部知识库 | 既有文档/经验 → 批量导入知识库，与自动沉淀合并去重 | 入 | 批量导入 → API | M2 |
| 设备数据采集 | 交付设备远程运行/报警/工况时序 → 分析结果回工作台（下卡详解） | 入 | 节点上报（仅出站） | M2 试点 / M3 全量 |
设备数据采集与分析 重点展开 · 公司设备交付后的远程能力
链路
设备侧轻量采集 agent（仅出站连接，客户网络无需开入站端口）→ 智能体平台节点网关（X-Node-Token 设备身份，心跳保活）→ 设备时序库（平台侧）→ 设备洞察智能体（规划中的第八个）分析 → 工作台「设备健康」视图查看与预警
| 业务场景 | 说明 |
|---|---|
| 在役设备健康看板 | 按客户/机型聚合运行概览：开机率、报警频次、工况偏移——工作台直接查看，售后从"被动报修"走向"主动服务" |
| 异常预警 → 自动关联问题单 | 阈值/模型触发预警 → 设备洞察智能体初判 → 与跟踪哨兵联动：提醒责任工程师，必要时生成建单候选（人确认） |
| 4D 根因佐证 | 故障时段工况回放（温度/振动/偏移曲线）作为根因分析证据链，附入 4D 报告——告别"凭口述猜根因" |
| ECN 整改效果验证 | 在役整改完成后的观察期内，用同工况数据对比验证"改了确实好了"，作为论证三项的量化依据 |
接入原则（红线，每新增一个接入都过这四条）
- ① 外部能力统一注册到平台工具代理：角色裁剪、频控、全量审计——不直连任何数据库
- ② 领域项目之间经平台共享能力，互不直连、互不碰库
- ③ 企微凭据唯一持有者仍是工作台消息网关，平台与外部系统不触碰
- ④ 数据边界评估：进什么数据、给谁看、留多久，接入前书面确认
接入演进里程碑
| 阶段 | 接入内容 |
|---|---|
| M1 | 手工导入导出过渡：ERP 物料表、PLM 图纸版本人工导入（规格书第 13 节） |
| M2 | ERP 只读 API（库存/交期）· 外部知识库批量导入 · 设备数采试点（重点机型 10–20 台）+ 平台侧时序库 |
| M3 | ERP 写回（请购）· PLM 受控版本对接 · 客服建单候选 · 设备数采全量 + 设备洞察智能体与「设备健康」工作台页 |