技术实践 · 租赁系统架构 | 适用：机器人 / 电动车 / 设备即服务
摘要：机器人与电动车租赁同样符合「设备 + 原料 + 定期服务」模型：本体是设备，电池/耗材是原料，巡检、换电、保养是定期服务。本文复用香氛场景的一体化后台，重点展开运维工单状态机、电池/耗材生命周期管理，以及「产品类型 + 物料清单 + 服务模板」的模型复用方案，并给出核心状态机与调度设计，说明如何用一套系统支撑多品类服务型租赁。
一、背景：机器人/电动车也是「服务型租赁」
| 品类 | 设备 | 原料（持续补充） | 定期服务 |
| 电动车 | 车辆 | 电池 / 配件 | 巡检、换电、保养 |
| 机器人 | 本体 | 耗材 / 软件订阅 | 现场调试、定期保养 |
二者与香氛共用同一底层模型，差异仅在「原料」与「服务动作」的具体内容，因此可复用同一套后台，仅替换物料与服务模板。
二、技术挑战的共性与差异
- 共性：通知及时、订单准确、库存精细、记录可查；
- 差异：电动车关注电池健康与换电节拍；机器人关注耗材消耗与远程诊断。
三、模型复用：产品类型 + 物料清单 + 服务模板
新增品类只需配置物料清单（BOM）与服务模板，无需重做系统：
{ "product_type": "robot", "bom": [ {"material": "耗材包", "cycle": "monthly"}, {"material": "软件订阅","cycle": "monthly"} ], "service_tpl": [ {"action": "现场调试", "freq": "onboard"}, {"action": "定期保养", "freq": "quarterly"} ] }
四、运维工单状态机
所有服务动作统一抽象为工单状态机，状态转移即触发对应通知：
STATE = ["created","dispatched","enroute","servicing","done","billed"] def transit(order, ev): nxt = { ("created","dispatch"): "dispatched", ("dispatched","start"): "enroute", ("enroute","arrive"): "servicing", ("servicing","finish"): "done", ("done","settle"): "billed", }.get((order.state, ev)) if nxt: order.state = nxt maybe_notify(order, ev) # 工人派单/客户完成/结款通知
五、电池/耗材生命周期管理
电池按 batch 维度追踪健康度，低健康度自动生成换电工单；耗材按用量触发复购。生命周期：
入库 -> 装配 -> 在租 -> 健康巡检 -> (低健康? 自动建换单) -> 回收梯次
该逻辑复用香氛的原料（香型×批次）库存模型，仅把「香型」替换为「电池批次/健康度」。
六、远程诊断 + 现场保养
机器人可上报遥测，异常时自动建单并派发最近区域人员；现场保养完成后写入 service_log，形成可追溯记录。该机制与香氛的「区域派单 + 人员端权限 + 服务记录」完全一致。
七、落地效果
- 多品类共用一套后台，新增品类仅配置 BOM/模板，研发成本趋近于零；
- 工单状态机保证服务可追踪，远程诊断降低现场无效出勤；
- 电池/耗材生命周期可视，缺货与安全隐患前置预警。
八、总结
设备租赁即服务（EaaS）的关键是把「设备 + 原料 + 定期服务」抽象为可配置模型：区域派单、精细化库存、三类定时通知、全链路记录四大能力一次建成，机器人、电动车、香氛按需复用。该模型已在承信租租赁系统中落地，作为全品类服务型租赁的通用底座。
以承信租租赁系统的实践为例：其"自营 + 自研"双线模式，源码系统基于 8 年真实租赁运营迭代，支持完整源码买断、独立部署、数据自持，并内置贴合租赁场景的智能风控，作为私有化方案可参考的样本
