TIGO 售后多智能体闭环平台 · 技术设计稿

面向客户核对的技术方案 —— 总体架构、企业微信集成、工作台设计、数据部署、安全边界与分期计划

V0.1 讨论稿 2026-10-15 配套文档：《售后问题闭环系统 · 建设规格书 V0.2》 用途：客户核对确认后作为开发依据

01项目概述与目标

贵司售后问题目前用企业微信多维表管理。多维表能存数据，但缺三样东西：状态机（状态只能人工填，"派生"做不到）、签批与字段级权限（谁该改哪个字段管不住）、定时规则引擎（预警只能靠人巡查）。这三样恰恰是整套闭环规则的载体，所以本项目的目标不是"把表搬上网"，而是把规则固化成系统行为。

系统的地基是规格书第 1 节的三条铁律，技术方案逐条对应落实：

铁律（规格书第 1 节）	技术落实方式（本稿）
铁律一：主单状态由落地物派生，不允许手工修改	"主单状态"等派生字段由业务后台计算生成，接口层拒绝任何手工写入（M1 验收项：尝试手改被系统拒绝）
铁律二：关闭只认落地物编号	关闭接口做强校验：无落地物编号、落地物未签批、状态不符，一律拒绝保存并返回明确原因（规格书第 9 节）
铁律三：只能有一个 HUB	全系统单一"我的待办中心"，所有角色登录第一屏都是它；不存在第二个消息中心页面

---

02总体架构

架构以多智能体平台为中心：multuex-engine（我方已有引擎）是整个架构的中心与能力总线——智能体、工具、记忆、设备接入都长在平台上；tigo-loop 售后闭环是挂在平台上的第一个领域项目（自己的表单、状态机、规则与数据库），后续贵司其他领域项目以同样方式挂载；工作台是统一人机入口（登录、界面壳、企微消息）。三句话记住分工：平台管能力、领域管规则、工作台管入口。外部系统（ERP/PLM/客服/知识库）与交付设备远程数采统一接入平台，成为全部领域项目共享的企业能力。

组件	内部代号	职责	部署形态
客户企业微信	—	员工身份来源（OAuth 授权）；通知触达通道（应用消息）	客户企微后台建一个自建应用
工作台	tigo-workbench	登录发证、界面壳与导航、智能体对话卡片区、企微凭据唯一持有者、把页面请求签名转发给业务后台	独立服务 :18795，独立代码仓库
售后业务后台	tigo-loop	第一个领域项目：11 张表单、主单/落地物状态机、规则引擎、HUB 待办、审计留痕；领域能力注册为平台工具供智能体调用	独立服务 :18796，独立代码仓库
多智能体平台	multuex-engine	架构中心：智能体运行、企业能力注册中心（工具代理）、设备接入（节点网关）、记忆/技能/审计；不写业务规则——时限、闸门、状态机判定在各领域项目执行	我方已有引擎，零改动复用

---

03企业微信集成方式

企业微信在本方案中承担两个角色：登录授权（员工点开应用即登录，不需要另记账号密码）和消息通道（预警、催办、签批提醒推送到企微）。两者都只用企业微信官方标准能力，不涉及个人微信。

3.1 登录授权流程（OAuth 网页授权）

3.2 消息通道（应用消息推送）

规格书第 8 节通知矩阵的所有推送（P0 立即推送、当日汇总、周报）都通过工作台的消息网关走企业微信应用消息送达，支持点击卡片直接跳转到 HUB 里对应的那条任务。推送规则举例如下：

事件	优先级	推送对象与形式
P0 单创建	立即	售后经理＋文员，应用消息卡片
已超应关闭日	立即	责任人＋经理＋台账管理员，标红 @责任人
物料缺口	立即	整改跟单员＋经理
节点停留超时 / 临近应关闭日	当日	责任人（＋经理），当日汇总一条，不逐条轰炸
复发窗口到期 / 分级健康度	周报	文员 / 总经理，进周报不打扰

完整事件清单见规格书第 8 节；推送对象是岗位，具体人名由账号映射决定（见第 6 章）。

3.3 回调接收（排期 M2）

员工在企业微信里直接给应用发消息、与智能体对话的能力（回调接收）排在二期（M2）。一期的通知是单向推送，已够闭环运转；对话式交互等业务跑顺后再开，避免一期面铺太大。

3.4 需要客户在企微后台完成的事项

#	事项	说明
1	创建自建应用（建议名「售后闭环」）	应用管理 → 自建 → 创建；上传 logo（可后补）
2	配置网页授权可信域名	开发期为我方测试域名；生产域名确定后（第 11 章 #1）改为正式域名
3	设置应用可见范围	建议先设为售后、技术、质量、销售、计划相关人员，跑通后按需扩大
4	把工作台主页 URL 配到应用「工作台应用主页」	员工在企微工作台点应用图标即进入系统
5	交接三样凭据	corp_id、agent_id、app_secret——安全交接方式见第 8 章，不要走微信群发

---

04工作台设计

工作台（内部代号 tigo-workbench）是贵司各类系统统一的入口门户，本项目的售后系统以页面模块方式挂在里面。我方已为其他制造企业交付过同构工作台并经过生产验证，本项目复用该成熟形态。

4.1 界面结构

区域	内容
顶部栏	当前系统名、登录人姓名与岗位、消息图标、退出
左侧导航	「我的待办（HUB）」「售后闭环」（本期模块）；后续项目落地后并列出现各自入口
卡片区	智能体对话：员工可以直接提问（如"帮我看看这台设备的历史故障"），由多智能体平台作答——日常答疑与查询入口，不承载业务流程
业务页面区	售后闭环的全部业务页面（问题单列表/详情、落地物、看板等）在此区加载，走工作台签名转发调用业务后台

4.2 后续项目如何挂载

工作台与业务后台之间只有一条标准通道（/api/模块名/* 签名转发 + 页面模块注册）。后续新项目（如设备管理）照此挂载：新建自己的业务后台与数据库，页面模块注册进工作台导航。新项目上线、升级、故障都不影响售后模块，反之亦然。

---

05售后闭环系统功能设计

本章只做功能地图与出处索引，业务规则以《建设规格书 V0.2》为准。

功能域	系统实现内容	详见规格书
表单体系	11 个表单／13 张表：主表 S1（34 字段）、落地物 5 张（4D／ECN／TIP／PCR／工单）、过程单 3 张（应急／EQCT／配件申请）、HUB 任务中心、基础数据 3 张	第 3 节
主单状态机	7 个状态全部由落地物状态派生（铁律一），派生字段接口层锁死；节点停留超时自动预警	第 4 节
落地物状态机	五类落地物各自的状态序列与签批时限；EQCT 与应急措施单永不提供"关闭主单"入口	第 5 节
HUB 待办中心	规则引擎自动生成 12 类任务，按人聚合；唯一入口页，不允许手工建任务	第 6 节
自动化规则引擎	A1–A15 共 15 条规则：状态派生、时限计算、三级逾期预警、挂起规则、影响面锁定闸门、4D↔ECN 互锁、复发提醒等——全部由定时任务＋事件监听自动执行，不依赖人工巡查	第 7 节
通知矩阵	按事件优先级推送（立即／当日／周报），走企微应用消息（本稿第 3.2）	第 8 节
关闭硬校验	主单关闭五条通用校验＋ECN 关闭七项硬校验，不满足直接拒绝保存并返回原因	第 9 节
数据迁移	设备档案 100% 完整性 → 历史问题补录 → 双轨运行 4 周后停用多维表	第 11 节

---

06身份与权限

员工身份来自企业微信（OAuth 换 userid），系统内不另设密码。权限按规格书 2.1 节的 8 个岗位建模，一人可兼多岗（如售后经理兼文员），以岗位决定能做什么、能看什么。

6.1 身份链路

环节	载体	说明
登录	企微 userid	OAuth 静默授权获得，员工无感知
账号映射	工作台用户表	userid ↔ 姓名 ↔ 岗位（8 选 N）；台账管理员等特殊约束（只亮灯不催办）在岗位定义里固化
会话凭证	JWT（12 小时）	登录后系统签发，过期自动重登（再次静默授权，无感）
业务鉴权	签名转发	工作台调业务后台时携带"当前用户＋岗位"签名，业务后台据此执行字段级权限（谁能改哪个字段）

6.2 岗位与权限

8 岗位（售后文员／售后经理／售后工程师／技术／质量／销售／整改跟单员／台账管理员）的完整动作权限矩阵直接采用规格书 2.2 节，系统按矩阵实现到字段级：例如文员打不开"出口归属"编辑、非经理看不到降档按钮、任何人改不了派生字段。岗位人员名单与初始映射由客户提供（第 10 章 #6），日常增减由售后文员在系统内维护。

---

07数据与部署

7.1 数据库

库	归属服务	内容
tigo_workbench	工作台	用户与岗位映射、登录审计
tigo_loop	售后业务后台	S1–S11 全部业务表单、任务、审计留痕（客户业务数据唯一落点）

两库物理隔离（独立账号、独立授权），随服务独立备份、独立迁移。附件（现场照片、4D／ECN 文件）存对象文件区并纳入每日备份，文件版本受控（发布新版自动把旧版置"已回收待确认"，规格书第 10 节要求）。

7.2 部署拓扑

环境	位置	用途
开发／联调环境	我方开发服务器，域名 tigo.multuex.com（HTTPS）	M0–M2 期间开发、联调、客户远程预览；用开发模式登录或客户测试企微应用
生产环境	待确认 客户自有机房 / 客户云 / 我方托管（第 11 章 #1）	M1 末期确定并完成部署；生产域名改为客户域名

两套环境同构（相同的服务划分与库结构），迁移＝部署脚本重跑＋数据导入，不重写。所有服务只监听本机回环地址，公网唯一入口是 nginx 反向代理（HTTPS，证书自动续期）。

7.3 运行与备份

项	方案
服务守护	systemd 托管（tigo-workbench、tigo-loop 两个服务），崩溃自动拉起、开机自启
每日备份	每天凌晨自动全量备份数据库＋附件，加密压缩存储，保留 14 天，可定期导出交付客户留存
监控	健康检查接口（数据库／服务／智能体平台连通性），异常在系统内可查；生产告警接入客户指定方式（待确认）
升级发布	先备份后发布，支持回滚；发布不影响另一服务

---

08安全边界

边界	措施
网络	两个业务服务仅监听本机回环；公网唯一入口 nginx（HTTPS 全站加密）；管理端口不对公网开放
企微凭据	corp_id／agent_id／secret 只存工作台服务器的加密环境文件（权限 600，代码仓库不含任何凭据）；交接走安全渠道（当面或加密文件传输），不经微信群
客户数据	业务数据只落 tigo_loop 库；多智能体平台只接收工作台转发的提问文本，拿不到客户凭据与数据库；如后续要求，可对转发文本做脱敏白名单
内部调用	工作台→业务后台走本机回环＋签名＋时间戳（防伪造、防重放）；业务后台不暴露给公网
审计留痕	所有降档、挂起、关闭、签批动作留痕不可删（规格书第 10 节），含操作人、时刻、变更前后值
权限失效	员工调岗／离职：企微移出应用可见范围即无法登录；系统内岗位调整即时生效

---

09分期实施计划

M0–M3 四期，业务范围与验收标准对齐规格书第 12 节；每期结束做一次可运行版本的现场演示验收。

阶段	周期	交付内容	验收标准（可测）
M0 骨架	约 2 周	工作台＋业务后台双服务跑通：企微 OAuth 登录闭环（开发模式联调）、界面壳与导航、HUB 占位首屏、智能体对话卡片区打通、两库初始化、部署与备份脚本	登录→壳→HUB 占位→对话全链路走通；健康检查全绿
M1 一期	第 1–6 周	S1 主表（34 字段）＋状态机＋8 岗位字段级权限＋关闭五条硬校验＋设备/客户档案导入＋生产环境部署	手改"主单状态"被拒；文员改不了出口归属；无落地物编号点关闭报错；按设备编号可查全部历史问题单
M2 二期	第 7–12 周	五张落地物＋三张过程单＋规则引擎 A1–A7＋HUB 12 类任务＋企微推送通知矩阵＋P0 快通道＋企微回调（对话式交互）＋首批智能体场景	造一条逾期数据 15 分钟内收到企微推送；五类出口各跑通一张真实单；P0 全程 ≤1 天留痕完整
M3 三期	第 13–20 周	ECN 三态跟踪＋影响面四数锁定闸门＋在役逐台子表＋A8–A15＋五项度量指标＋看板与月度复盘报表	未锁定四数时请购按钮不可点；能回答"改了 27 台还是 30 台"；月度自动产出五项指标

周期为工作日历自然周；里程碑起算以设计稿与规格书双双确认（客户核对通过）为准。

---

10客户配合事项清单

以下事项不要求一次备齐，但各有时点要求；越早确定，工期越稳。

#	事项	何时需要	说明
1	企微后台五项操作（建应用／可信域名／可见范围／主页 URL／凭据交接）	M0 联调前	见本稿 3.4 节；开发期可先用测试应用
2	生产域名与部署位置决策	M1 末期	决定买不买域名、放客户机房还是云（第 11 章 #1）
3	设备档案（S11-1）：全部在役设备序列号	M1 数据迁移前	100% 有客户名、机型、出厂日期——这是 ECN 影响面清点的唯一来源，缺了根治链断一半（规格书第 11 节）
4	历史售后问题数据	M1 数据迁移前	近 12 个月未关闭问题补录，须有责任人、设备、现状
5	工厂工作日历（节假日与调休表）	M1 末期	全系统"工作日"只认这一份（规格书 3.4 节）；后续每年更新一次
6	岗位人员名单（8 岗位谁兼什么）	M1 上线前	用于初始账号映射；之后文员在系统内维护
7	双轨运行配合	M1 上线后 4 周	多维表与新系统并行，差异每日核对（规格书第 11 节）

---

11待客户确认清单

以下问题影响设计与部署，请核对时一并拍板；确认后本稿升 V1.0 作为开发依据（与规格书第 14 节的 7 项业务待确认相互独立）。

#	问题	影响范围
1	生产域名与部署位置：客户自有域名＋自有机房？客户云账号？或暂用我方托管？涉及数据存放位置与年费用分担	部署拓扑、企微可信域名、备份与导出方式
2	通知接收人规则：通知矩阵按岗位推送，具体到人靠账号映射；特殊单子是否需要额外抄送人（如总经理订阅全部 P0）？	消息网关配置、HUB 任务生成规则
3	岗位名单来源：初始名单由谁整理提供（建议售后经理牵头）；日常维护授权给谁	账号映射流程、上线培训内容
4	数据迁移范围：历史工单是否补录近 6 个月（用于备件对照初始值，规格书第 11 节标"可选"）？	M1 迁移工作量、备件建议初始质量
5	附件与文件管理：现场照片、4D／ECN 文件的保留年限与容量预估；是否有客户侧文件服务器要求	存储与备份方案
6	生产告警方式：服务异常时通知谁、走什么渠道（短信／邮件／企微）	监控与运维方案
7	智能体使用范围：卡片区问答对哪些岗位开放；提问内容是否需要限制或留痕审查	卡片区权限、审计策略（M2 前确认即可）