无人售卖柜系统拆解：设备通信与自动结算的关键技术

1. 先把系统全景画清楚一台柜子背后至少藏着四套子系统我之前帮朋友看过一个无人售卖柜项目对方一开始的需求描述特别简单就是把冰箱门改成扫码开锁拿完东西自动扣钱嘛。结果等他们真组了团队才发现这东西远不止改造冰箱这么简单。市面上你能买到的成品方案每一台柜子背后都是一整套软硬件配合的系统拆开来看至少包含四块设备端、云端平台、用户端、运维端。设备端是整个柜子的身体包括主控板、电磁锁控制器、识别模块重力传感器、RFID读写器或摄像头、温控单元如果是冷柜、4G/ WiFi 通信模组。它的核心职责就四个接收云端指令、监控柜门状态、采集识别数据、上报交易结果。注意设备端绝不是执行完开门就不管了它还要负责在断网时暂存交易事件等网络恢复后补传否则就会出现用户拿走了货、后台却不知道的尴尬局面。云端平台是大脑一般拆成几个微服务设备接入服务负责维持长连接、验签、心跳巡检、交易引擎处理开柜、结算、退款状态机、商品与库存服务维护货道或柜内 SKU 信息、用户与订单服务对接微信/支付宝身份体系。这些服务之间的数据一致性非常关键尤其是扣除余额这类资金操作必须落到事务里绝对不能出现订单状态更新了但扣款没执行、或者重复扣款的情况。用户端通常是小程序或 App承担的角色是遥控器和账单。用户扫码→收到开柜指令→拿货→关柜→收到扣款通知这五个交互节点都要有清晰的 UI 反馈。别小看这个环节用户对乱扣费的耐心几乎为零所以用户端一定要展示明细取了几件商品、每件多少钱、优惠多少、实付多少。哪怕这些明细在技术上只是从订单服务拉数据但在产品体验上它就是信任的基石。运维端是很多团队遗漏的一块。无人售卖柜放在线下总会遇到各种匪夷所思的物理问题柜门没关严、传感器漂移、货物被调包、断电断网。没有运维端你连哪台柜子有异常都看不到。好的运维端至少要有三块内容设备实时状态看板在线/离线/告警、远程操控工具远程开门、远程重启、升级固件、库存异常预警理论上柜内应有 20 瓶水实际库存却对不上就需要推送消息给补货员。把这四块系统在脑子里串起来之后你再去看市面上那些无人柜方案商的报价心里就有数了他们卖的不是柜子是这套软硬一体的完整闭环。而你如果要自己从零做后面我讲的设备通信和自动结算就是整个项目里技术含量最高、也最容易出问题的两条链路。2. 设备通信层为什么选 MQTT 长连接而不是清一色的 HTTP设备跟云端通信是无人售卖柜所有功能的地基。我见过好几个团队在这上面摔跤第一版图省事用 HTTP 轮询每 5 秒让设备调一次接口查状态。结果柜子稍微多一点云端压力上去了不说开门指令的延迟高得离谱——用户扫码之后盯着柜子等了三四秒门才弹开这种体验基本就会被用户弃用。所以主流的无人柜方案都选 MQTT 作为设备与云端之间的主力通信协议。MQTT 的核心价值是发布/订阅 长连接服务器可以主动往设备端推消息不需要设备反复来问。这在开锁指令上特别关键用户扫码的请求到达云端后云端可以在几十毫秒内把开锁指令推给对应柜子门锁电机立刻动作用户几乎感觉不到延迟。通信链路的设计通常会拆成两个主题控制指令和状态上报。控制指令走 MQTT 的云端 → 设备方向消息主题类似vending/{deviceId}/command消息体是一个 JSON包含指令类型open/close/reboot、时间戳、签名。状态上报走设备 → 云端方向主题类似vending/{deviceId}/event上报的内容包括柜门状态、识别结果、温控数据、电量/信号强度。两个方向的主题隔离便于云端按设备粒度做订阅也方便后续做设备日志复盘。下面是一个典型的开门指令消息体示例{ cmd: open_lock, ts: 1712817600, seq: 202404120001, sign: a3f8c2e... }这里seq是设备消息的序号用来做幂等处理——避免设备因为网络抖动重复执行同一条开门指令。sign是签名一般是云端用设备密钥对消息体做 HMAC 后生成的字符串设备端验签通过才执行防止有人伪造指令随便开别人的柜子。设备端上报的关门事件消息体类似这样{ event: lock_closed, ts: 1712817905, seq: 202404120017, lock_status: ok, sensor_data: { weight_mv: [1023, 1020, 1018], rfid_tags: [E2801170, E2801171] } }lock_status表示电磁锁是否正常吸合sensor_data是识别模块的原始采集数据重量值这里直接给到毫伏级原始量程具体换算成克是云端算法的事。这种设备只采数据、云端做计算的分工是后期调识别精度的关键——你在现场调参不用重新烧固件改云端算法就行。再补充一个 MQTT 容易被忽略的细节遗嘱消息Last Will。无人柜断网、断电是家常便饭如果没有遗嘱消息云端会一直以为这台设备在线等到超时才反应过来中间的账目就很难对齐。正确做法是设备在建立 MQTT 连接时带上一个遗嘱主题内容标记为设备离线。一旦链路异常断开Broker 自动代设备发布这条遗嘱云端收到后立刻把设备状态切到离线同时把针对这台设备的交易动作挂起或转人工处理。这个机制能帮你避免非常多的幽灵数据问题。那 HTTP 在无人柜场景里就完全没有位置吗也不是。HTTP 适合低频、数据量大的场景设备启动时的配置拉取拉取商品清单、价格表、固件升级包下载、补货员上传货物照片。这些操作不需要实时性用 HTTP 更简单可靠。所以实际架构里MQTT 负责实时控制链路HTTP 负责管理和运维链路两条线路各司其职运营起来才顺手。3. 自动结算链路关门那一瞬间系统究竟在做哪些事自动结算是无人售卖柜体验的临门一脚。用户拿完东西关门如果 10 秒内微信弹出扣款消息体验就是顺畅如果半天没动静或者扣错了钱用户立刻就会产生不信任感。要把这一瞬间做好需要实现一个严谨的交易状态机我拆成四个阶段来讲。第一阶段是开柜前初始化。用户扫码后云端先锁定这台柜子和这个用户的组合生成一笔待进行的交易单。为什么提前建订单因为后面所有识别数据和扣款操作都要挂在这笔订单下避免并发场景下算错账。同时云端下发开门指令并让识别模块进入预采集状态重力柜会先记录空柜基准重量视觉柜会拍摄一张关门状态的静态照片作为对比底图。第二阶段是取货过程的数据采集。从柜门打开到关上的整个窗口期识别模块在持续做一件事记录变化。重力柜按固定频率采样重量数据视觉柜连续抓拍帧或录制短视频RFID 柜则循环读取柜内标签。这个阶段的关键词是原始数据全量留存千万不要在设备端做数据压缩或精简因为一旦后续结算有争议这些原始数据就是你唯一能回放复盘、给用户解释的依据。第三阶段是关门触发结算。用户在关门的瞬间设备会上报一个lock_closed事件。云端收到后启动结算引擎这里用重力 逻辑判断来举例结算前系统先等重力传感器的读数进入稳定窗口——关门后柜体晃动、用户手还在柜内都会导致读数上下跳一般等 1 到 2 秒连续采样 N 次差值小于阈值才认为重量稳定。稳定重量与开柜前基准重量做差得到一个重量增量。增量按 SKU 重量表去匹配匹配结果就是理论上的取走商品明细。第四阶段是扣款与通知。结算引擎算出商品明细后调用支付服务发起免密扣款。扣款成功就把订单状态流转为已完成然后通过微信公众号模板消息或小程序订阅消息推送给用户。如果扣款失败余额不足、用户解除了免密授权订单会流转到待支付状态同时给用户推送一条补缴通知如果识别结果异常重量对不上任何商品组合订单会流转到待审核由云端挂起并通知运维人工查看当时的采集数据。我用一张表把这四个阶段的核心动作和异常出口列一下阶段核心动作正常出口异常出口开柜前初始化锁交易单、下发开门指令、采集基准数据正常开门设备离线→通知用户等待取货中数据采集持续采集重量/RFID/视觉原始数据等待关门事件超时未关门→推送提醒关门触发结算延时稳定、差值匹配、生成明细进入扣款环节识别失败→人工审核扣款与通知调用免密支付、更新订单、推送消息扣款成功、订单完成扣款失败→补缴或取消整个过程里最容易出问题的就是重力值稳定这个点。不同柜子的物理结构不一样有的柜门厚重、关门震动大有的柜子放在不平的地面重力传感器本身的零点都会慢慢漂移。所以工程上我强烈建议做两件事一是每次开柜前都重新校准基准重量不要用很久之前的空柜值二是给每个柜子配置独立的稳定窗口参数不要全场统一一套阈值。你如果批量部署 100 台柜子就会发现每台柜子的传感器特性都略微不同统一参数的结果就是永远有一部分柜子识别不准。4. 识别选型重力称重、RFID、视觉识别到底怎么取舍无人柜最核心的识别技术市面上一共有三条主流路线各有各的脾气。很多项目做砸了不是方案本身不行而是选型和货品场景不匹配。我直接把三种方案的核心参数和工程体验列出来。重力称重方案在柜子的每一层或者底部整体安装压力传感器阵列通过重量变化判断用户拿了什么、放回了什么。这个方案的优势是硬件成本低、可靠性高、对商品形态无要求——瓶装水、盒装饭、袋装零食都能感知。缺陷是精度和 SKU 数量挂钩如果你柜子里只卖同一种规格的饮料精度可以做得非常高如果混着卖各种规格的不同商品重量组合爆炸识别准确率会急速下降。工程上重力的量程选择和传感器温漂处理也很关键比如冷柜里 4℃ 和常温 25℃ 下的传感器输出明显不一样需要做温度补偿。此外个别用户会玩两件放上去又拿一件下来的骚操作这类场景重力方案容易判错。RFID 方案每一件商品上贴一张 RFID 标签柜子内嵌读写器天线阵列通过读到的标签变化判断拿走和放回了什么。这个方案的识别非常直接准确率可以做到 99% 以上用户拿错放错、多拿少拿都能精确到具体标签。代价是硬件成本高标签一张几毛钱到一块多每个柜子还要装多路读写器和天线柜子整体成本会比重力柜贵不少。还有一个绕不开的痛点就是漏读——标签贴在金属罐体上容易被屏蔽液体商品对射频信号也有吸收饮料柜用 RFID 要反复调天线位置。另外标签损耗是持续的运营成本补货时每个商品都要重新贴标人工成本不容忽视。视觉识别方案在柜内安装摄像头利用图像识别算法判断商品变化。这个方案理论上最优雅不依赖标签、不依赖重量能识别任意形态商品。但现在的工程落地还是受限于算力、光照和价格。柜子里光线暗、玻璃反光、商品包装相似都会影响识别准确率目前业界普遍的做法是视觉 重力多模态融合视觉给出候选商品框重力做兜底校验。纯视觉方案在无人柜场景想做到商用级准确率需要大量真实场景数据训练模型小团队很难攒出那个量级的样本库。我建议按下面的思路选型这也是我接触过多个项目后觉得最务实的路径卖标品饮料、矿泉水这种规格统一的重力方案你优先考虑成本最低、维护最省心单 SKU 或者 SKU 数量控制在 10 个以内时准确率完全够用。卖生鲜、便当这类单价高、SKU 包装差异大的上 RFID标签成本分摊到客单价里是完全划得来的。想做一个什么都能卖的智能货柜且你本身有算法团队积累可以走视觉 重力融合但一定要做好长期迭代算法、持续亏损的运营准备。选型的另一个隐藏维度是补货效率。重力柜补货就是普通理货员就能干的活RFID 柜每次补货还要逐个核对贴标视觉柜补货时最好让商品正面朝向摄像头。这个效率差距会体现在每天的运营成本里时间一长你就知道选错方案要多花多少钱。5. 异常场景兜底设备掉线、争议退款、薅羊毛这些早晚要遇到无人售卖柜最大的特点就是无人看管所以异常场景的处理能力才是评判系统成熟度的第一指标。我从实战里挑几个必须提前设计好的场景讲。掉线断网几乎每周都会发生。柜子在商场负一层、工地门口、地下车库4G 信号差是很正常的。我见过很多方案在断网时直接拒绝开柜把用户赶走这其实是最差的体验。更好的做法是离线可开柜在线再结算设备端本地缓存一个临时的用户授权令牌用户扫码后设备先开门交易数据存在本地等网络恢复再批量上报、结算扣款。当然这里有个风险敞口如果设备离线时间太长比如超过 24 小时风险就会累积所以运维端要设定一个离线时长阈值超过阈值自动暂停该柜的开柜服务。争议退款也是高频场景。用户说我只拿了一瓶水你怎么扣了我两瓶的钱这是无人柜客服每天都要处理的。不做的话用户客诉率会飙升。工程上怎么减少争议关键在于留存证据。每笔交易都要把结算依据存档重力柜留重量变化曲线RFID 柜留标签读写的日志视觉柜留取货视频片段。用户发起申诉时客服后台能直接拉出这笔订单的证据包判断是否退款。我自己的经验是宁可花一点存储成本把所有原始数据留够 90 天也不要在用户投诉的时候拿不出依据。防薅羊毛设计也得做。最典型的作弊手法是开柜→不拿货→关门→再开柜用反复的开关门动作干扰重力传感器的稳定窗口让系统识别出错。解决思路也很直接对同一设备、同一用户短时间内多次开柜的行为加频控触发频控后强制进入人工审核模式或延长结算等待时间。说到底无人柜的核心资产是信任遇到不诚信用户宁可损失这一单也要把证据留清楚以免影响其他正常用户。还有一个细节容易被忽略温度。冷柜柜门频繁开关内部温度波动大重力传感器和电池都会受影响。冬天低温环境下锂电池掉电特别快室外柜如果没加热模块设备可以直接死机。这类问题不是在办公室写代码时能发现的必须通过小批量试运营采集真实环境数据再去反推硬件设计迭代。6. 几个工程细节做无人柜之前最好先想明白每一个环节说完最后还有一些我反复被问到、也反复踩过的工程坑集中说一下。第一自研还是买方案。你说自研不要从零开始造设备端的通信协议、交易核心逻辑、订单系统技术圈里都有开源项目和成熟的 SDK 可以抄作业比如对接微信支付分、支付宝免密代扣人家已经给你封装好了接口你只要按文档接入。但抄和抄对是两码事关键是理清你们自己的业务流程按业务场景去裁剪功能不要一上来就堆大而全的架构。不懂业务技术再新也是白搭。第二关于免密支付和合规。用户购物流程里涉及免密扣款的授权这是整个支付链路最敏感的一环。一定要让用户明确知道开通免密服务后关门即扣款并且提供便捷的关闭入口。同时用户身份证信息、地理位置、交易记录这类敏感数据通信层和存储层都必须加密防止数据泄露。这件事别省预算因为没有用户信任无人零售这个生意根本撑不起来。第三运维体系一定要留够人在环路的能力。哪怕自动化程度再高无人柜的日常运营里永远需要人工介入的节点补货、清洁、设备维修、客诉处理。所以整套系统里运维工具链的打磨优先级应该不亚于核心交易链路。能用后台看的绝不让运营跑现场能在线上处理的绝不等到线下处理。第四关于数据复盘。无人柜本质上是个线下数据采集终端每台柜子每天会产生清洗后的交易数据、库存变动数据、用户行为数据。这些数据沉淀下来之后还有很长的扩展空间某台柜子在什么时段销量最好、哪些商品组合复购率最高、什么样的点位租金对应什么样的销售额。项目做到稳定运转之后把这些数据用起来才是真正的长期价值。我在实际项目里的体会是无人售卖柜不是造一台智能冰箱那么简单它是一次硬件可靠性、通信稳定性、云端并发能力、资金安全水平的综合考验。每一个环节都有无数的细节要打磨但把这套链路从头到尾理清楚、走通一遍之后你获得的是一套可复制的线下零售数字化能力这套能力的价值远不止一台柜子本身。