A retail equipment distributed intelligent decision system and method based on cloud and edge node cooperation

Abstract

The application discloses a retail equipment distributed intelligent decision system and method based on cloud and edge node cooperation, relates to the technical field of Internet of Things intelligent retail equipment, and comprises a cloud intelligent layer, an equipment end intelligent layer and a physical hardware layer, wherein the cloud intelligent layer, the equipment end intelligent layer and the physical hardware layer are sequentially connected; the cloud intelligent layer comprises one orchestration agent and multiple professional sub-agents and is used for performing strategy analysis, decision optimization and on-site operation management on all-network retail equipment; the equipment end intelligent layer deploys one node agent for each retail equipment and directly controls the physical hardware layer through a hardware abstraction layer. The application realizes unified intelligent operation management of self-service retail equipment distributed in multiple geographical regions. Through comprehensive use of artificial intelligence multi-agent system, edge computing, an MQTT Internet of Things communication protocol, a hardware abstraction layer, a model context protocol and other technologies, efficient cooperation between cloud strategy decision and equipment end autonomous execution is realized.

Description

Technical Field

[0001] This invention relates to the field of IoT smart retail equipment technology, and more specifically to a distributed intelligent decision-making system and method for retail equipment based on cloud and edge node collaboration. Background Technology

[0002] Currently, the operation and management of self-service retail equipment mainly adopts a centralized cloud management model. All decisions such as monitoring, replenishment scheduling, fault handling, and pricing strategies of all equipment are completed in the cloud, and the equipment itself only acts as a passive executor. This architecture has the following problems: (1) Strong network dependence: The equipment cannot perform any intelligent decisions when offline, resulting in safety hazards (such as the inability to automatically stop sales when the temperature control is abnormal) and revenue loss during network interruption; (2) High response latency: All decisions need to be processed in the cloud before being issued, and the handling time for safety emergencies (such as door lock failure and leakage detection) cannot meet the real-time requirements; (3) Poor scalability: As the number of equipment increases (such as from dozens to hundreds or more), the cloud load increases linearly, and the system performance decreases.

[0003] Some solutions introduce edge computing nodes, but they usually only implement simple rule engines or data caching functions and lack the following key capabilities: (1) lack of hierarchical autonomous decision-making mechanism: the autonomous permissions of edge nodes cannot be dynamically adjusted according to the device operation stage and risk level; (2) lack of cloud-edge bidirectional collaboration mechanism: there is a lack of structured conflict resolution rules and decision log review mechanism between the cloud and the edge; (3) lack of secure and controllable model update mechanism: the AI ​​decision model update at the edge lacks phased verification, manual approval gate and automatic rollback protection.

[0004] In the field of retail equipment operations, existing solutions typically employ a single backend service to handle all business logic. A technical solution that applies a multi-agent AI architecture (Orchestrator + professional Sub-Agent) to the overall operation and management of retail equipment, combined with technologies for scenarios such as fleet management, compliance tracking, and predictive maintenance, is currently unavailable.

[0005] Therefore, how to propose a distributed intelligent decision-making system and method for retail equipment based on cloud and edge node collaboration, and overcome the shortcomings of existing technologies, is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] In view of this, the present invention provides a distributed intelligent decision-making system and method for retail equipment based on cloud and edge node collaboration, used for unified intelligent operation management of self-service retail equipment (such as vending machines, smart vending machines, smart claw machines, etc.) distributed in multiple geographical areas. By comprehensively utilizing technologies such as multi-agent systems, edge computing, MQTT IoT communication protocol, Hardware Abstraction Layer (HAL), and Model Context Protocol (MCP), efficient collaboration between cloud-based policy decision-making and device-side autonomous execution is achieved. To achieve the above objectives, the present invention adopts the following technical solution: A distributed intelligent decision-making system for retail devices based on cloud and edge node collaboration, comprising: The cloud-based intelligent layer, the device-side intelligent layer, and the physical hardware layer are connected sequentially. The cloud-based intelligent layer includes an orchestration agent and multiple specialized sub-agents, used for strategy analysis, decision optimization, and on-site operational management of retail devices across the entire network. The device-side intelligent layer deploys a node agent for each retail device and directly controls the physical hardware layer through the hardware abstraction layer; The node agent has a dynamically adjustable hierarchical autonomy level. The cloud intelligence layer dynamically adjusts the autonomy level of each retail device according to the device's operating status, enabling devices with different maturity and risk levels to have appropriate autonomous decision-making capabilities.

[0007] Optionally, the orchestration agent is used to understand the operator's natural language intent, decompose high-level instructions into specific tasks, schedule the execution of corresponding Sub-Agents, synthesize results, and manage context and memory.

[0008] Optionally, the specialized sub-agent includes: Inventory Agent: Used for comprehensive network inventory analysis, demand forecasting, and intelligent replenishment route planning; Pricing agency: Used for price optimization, promotional effectiveness analysis, and flexible pricing; Customer Agent: Used for customer insights, churn prediction, and targeted marketing; Operations agent: Used for equipment health prediction, anomaly detection, and maintenance scheduling; Analysis / Financial Agency: Used for revenue analysis, trend discovery, and reconciliation auditing; Fleet management agent: used for replenishment route optimization, maintenance dispatch, fleet scheduling, compliance tracking and cost control.

[0009] Optionally, the cloud intelligence layer may also include an MCP interface layer and a platform service layer; The agent interacts with the platform service layer in a standardized manner through the MCP interface layer, which adopts a four-layer architecture to provide business semantic tools. The platform service layer includes a data backend unit, a module marketplace unit, and an event bus unit.

[0010] Optionally, the node agent includes: Routine scheduler: Used to execute daily tasks according to a predefined schedule; Local decision engine: Includes a rule engine, a lightweight machine learning model, and a threshold management module, for autonomous decision-making on the device; Local memory: used to store transaction history, frequent customer tokens and last purchase records, sales patterns, and decision log edge data; Action executor: Used to control hardware, update the UI, and send alarms through the hardware abstraction layer.

[0011] Optionally, the physical hardware layer includes: a motor, a sensor, a payment terminal, a screen, and a door lock.

[0012] Electric motors, including screw motors, elevator motors, gravity motors, and locker motors; Sensors, including temperature sensors, door sensors, power sensors, and network sensors; Payment terminals, including Octopus cards, QR code and NFC terminals; Screens include touchscreens, LED screens, and screenless modes; Door locks, including electromagnetic locks and mechanical locks; The hardware abstraction layer provides a unified control interface for different hardware components, so that node agents do not need to be aware of the differences in the underlying hardware.

[0013] Optionally, it also includes dynamically adjusting the autonomy level of each retail device based on its operating status; L0: The node agent only executes the instructions issued by the cloud and does not make any independent decisions. The cloud has complete control. L1: The node agent monitors itself and only sends out alerts without taking action when it detects problems. The cloud receives the alerts and then makes decisions. L2: Node agents autonomously execute security-related decisions, while other decisions are reported to the cloud. The cloud is responsible for policy decisions and reviews security decision logs. L3: Based on L2, it adds local recommendation, simple promotion execution, and automatic inventory warning notification capabilities, while the cloud is responsible for high-level strategy and model updates; L4: Operates completely autonomously within the authorized scope, only notifying the cloud in case of anomalies; the cloud only monitors and handles exceptions.

[0014] Optionally, the node agent and the cloud also include conflict resolution rules; Rule 1: The Node is the source of physical truth. When the Cloud records are inconsistent with the Node sensor detection results, the Node shall prevail. Rule 2: Prices issued by the Cloud override the local cache of the Node; Rule 3: Each transaction has a unique ID, and duplicates will be automatically removed during upload after reconnection; Rule 4: Safety-related decisions take precedence over operational decisions; Rule 5: Cloud's pending instructions during offline periods have an expiration date; expired instructions will be automatically discarded upon reconnection. Rule 6: After the Cloud distributes a new model, the Node will only switch if the verification is successful; otherwise, it will roll back to the previous version.

[0015] Optionally, each autonomous decision made by the node agent is recorded in a decision log in JSON format, including the triggering conditions, context, executed actions, and the autonomy level information on which they are based, and uploaded to the cloud for post-event review.

[0016] Optionally, it also includes updating the system through a conservative, gradual model evolution mechanism, including: Step 1: Collect decision logs and operational data from the entire network, train / fine-tune the decision model, and generate candidate versions after model compression; Step 2: Perform offline replay and live testing in a separate Staging Node group to monitor accuracy, inference latency, and resource consumption; Step 3: The approval request is pushed to the Dashboard and notifications, where the approver can view the verification report, decision discrepancies, and risk assessment. Step 4: Conduct three-stage verification for grayscale release, with an automatic rollback gate set for each stage; Step 5: Notify the device via MQTT QoS 2, and after CDN download and SHA-256 verification, perform local benchmark testing on the node. The node adopts a three-slot design. If the verification is successful, it will be activated; if the verification fails, the service will be unaffected. Step Six: Monitor from six dimensions and automatically roll back the trigger conditions: security anomaly > 0, accuracy drop > 5%, node crash. Periodically generate an effect summary, mark it as STABLE, and feed the effect data back to the next round of training.

[0017] Optionally, the cloud-based intelligent layer also includes dedicated agents categorized by device type, including: Vending machine agent: Used for handling browsing dwell time analysis, product pairing recommendations, low inventory response, and payment discount scenarios; Smart locker agent: Used to handle parcel delivery, pickup verification, overdue management, and member identification scenarios; Intelligent ordering machine agent: used to handle scenarios such as add-to-cart recommendations, allergen detection, meal calculation, and queue management; Each device type has its own dedicated agent with its own toolset, and the system automatically routes devices to the corresponding dedicated agent based on their type.

[0018] Optionally, the local decision engine of the node agent employs a four-step decision pipeline for event processing, including: Step 1, Trigger Events: Receive raw event data, including guest browsing events, payment events, and low inventory alert events; Step 2, AI Agent Loop: Inference analysis is performed through tool calls, supporting local fast mode and cloud LLM mode; Step 3, Business Rule Verification: Conduct a compliance review of the AI's decision and return one of three rulings: pass, modify, or block. Step 4, Workflow Execution: Translate the validated decisions into specific operational steps; The four-step decision pipeline uses an asynchronous generator architecture, supporting streaming output and mid-process cancellation.

[0019] Optionally, the business rule verification includes handling the following conflict scenarios: Budget conflict: Prevent discounts from being issued when the promotional budget is exhausted; Offline conflict: Automatic fallback to local cache strategy when network connection is lost; Weather-related issues: Restocking will be temporarily suspended and dynamic pricing will be implemented during the typhoon. Business hours conflict: Promotional information is delayed at night; Capacity conflict: If there are no empty lockers, delivery will be refused and the locker will be redirected to an alternative location.

[0020] Optional features also include an emergency full-network rollback mechanism: Operators can trigger a rollback command with a single click via the Dashboard; The cloud broadcasts a rollback command to all devices on the network via the MQTT QoS2 protocol; Each node agent completes the switch from the Active slot to the Rollback slot within 10 seconds; The rolled-back model version is marked as RECALLED. The system automatically generates an accident report.

[0021] Optionally, different validation intensities can be applied to models with different risk levels: High-risk models include anomaly detection models, which require 7 days of staging validation, dual approval, and 7 days of canary observation. The medium-risk model includes an inventory model and a pricing model, and adopts a standard process; Low-risk models include recommendation models and personalized models, using standard procedures but with a 24-hour observation period in Canary.

[0022] Optionally, the tasks generated by the fleet management agent employ complete lifecycle state management, including the following state transitions: PREDICTED status: AI predicts demand, including out-of-stock and outage trends; PLANNED status: Task generated and route optimized; ASSIGNED status: Matched personnel, vehicles, and spare parts; ENROUTE status: GPS tracking, supports dynamic route adjustment; INPROGRESS status: Replenishment, repair, or inspection operations are being performed; VERIFIED status: Confirmed by node agent self-check. After replenishment, the sensor verifies the correct inventory quantity. After repair, the node agent confirms normal hardware operation through self-check. CLOSED status: Data archiving and KPI statistics.

[0023] Optionally, the task adopts an SLA-based graded response mechanism according to the severity of the fault: P0 safety-related faults include temperature control failure, door lock failure, and electrical leakage, requiring a response within 4 hours. P1 operational failures: These include shipping facility failures and offline payment terminals, requiring a response within 24 hours; P2 optimization-type faults: including screen failures and cosmetic damage, requiring a response within 72 hours; Replenishment task: Machines with a stockout rate exceeding 30% must be replenished within 24 hours.

[0024] Optionally, a distributed intelligent decision-making method for retail devices based on cloud and edge node collaboration includes: S1: Deploy orchestration agents and multiple specialized sub-agents in the cloud to perform strategy analysis, decision optimization, and on-site operation management for retail devices across the entire network; S2: Deploy a node agent on each retail device, the node agent directly controlling the physical hardware through a hardware abstraction layer; S3: Dynamically adjust the autonomy level of each retail device according to the device's operating status. The autonomy level includes five levels: L0 Pure Execution, L1 Monitoring and Alarm, L2 Security Autonomy, L3 Operational Autonomy, and L4 Full Autonomy. S4: The node agent autonomously executes decisions within its autonomy level authorization scope, and decisions exceeding the authorization scope are reported to the cloud for processing; S5: Each autonomous decision made by the node agent is recorded in the decision log and uploaded to the cloud for post-event review; S6: Data inconsistencies are handled between the cloud and node agents according to conflict resolution rules, which include: inventory status is based on node sensors, pricing is based on cloud-issued pricing, transactions are deduplicated using unique IDs, security decisions take precedence over operational decisions, instructions have expiration dates during offline periods, and model updates require local verification before switching.

[0025] Optionally, it also includes system updates through conservative, incremental model evolution methods, including: S7: Collect decision logs and operational data from the entire network, train or fine-tune the decision model, and generate candidate versions after model compression; S8: Perform offline playback and real-machine verification in a separate StagingNode group; S9: Push the approval request to the dashboard, where the approver reviews the verification report and decides whether to approve, reject, or postpone it; S10: Conduct three-stage verification for canary release, namely, deploying 5% of devices in the Canary stage, expanding to 25% to 50% in the Phased stage, and full rollout deployment, with an automatic rollback gate set in each stage; S11: Notify the device to download the new model via MQTTQoS2, and perform local benchmark testing on the node. The node adopts a three-slot design. If the verification is successful, it will be activated; if the verification fails, there will be no impact on the business. S12: Conduct 14 days of continuous monitoring across six dimensions: decision quality, security, performance, resources, business, and stability. Once the conditions are met, the system is marked as stable.

[0026] As can be seen from the above technical solution, compared with the prior art, the present invention discloses a distributed intelligent decision-making system and method for retail equipment based on cloud and edge node collaboration, which has the following beneficial effects: (1) Offline security operation: Through the local decision engine of Node Agent, the device can still make security decisions autonomously when the network is interrupted (such as automatically stopping sales when the temperature control is abnormal), eliminating the single point of failure risk of the traditional centralized architecture; (2) Response latency is significantly reduced: security emergencies are handled locally by the Node Agent, reducing the response time from the traditional cloud round trip in seconds to the millisecond level; (3) Significantly reduced operation and maintenance manpower costs: Fleet Management Agent significantly reduces the number of trips and manpower waste through TSP / VRP route optimization, task merging (replenishment + maintenance on the same trip), predictive maintenance and other means; (4) The fleet operating cost is significantly reduced: The route optimization engine minimizes the total mileage and time by solving multiple constraints (vehicle capacity, working hours, traffic conditions, site opening time); (5) Zero accidents in model updates: The conservative and progressive six-step closed loop ensures that each model update is verified by staging (≥72h), manually approved, gray release (at least 4-5 days) and continuously monitored for 14 days. The three-slot design enables 10-second rollback and zero impact on business. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0028] Figure 1 This invention provides a structural framework diagram of a distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration.

[0029] Figure 2 A schematic diagram of the autonomous hierarchy system provided by this invention.

[0030] Figure 3 A schematic diagram of the conflict resolution rule matrix provided by the present invention.

[0031] Figure 4 The model evolution pipeline flowchart provided for this invention.

[0032] Figure 5 This is a schematic diagram of the deployment of the three-slot model for the Node provided by the present invention.

[0033] Figure 6 This is a schematic diagram of the Fleet Management Agent collaboration flow provided by the present invention.

[0034] Figure 7 Cloud provided for this invention Node execution closed-loop flowchart.

[0035] Figure 8 The task lifecycle state transition diagram provided for this invention. Detailed Implementation

[0036] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0037] This invention aims to solve the technical problems of high response latency, strong network dependence, lack of autonomous decision-making ability on the device side, and lack of security guarantee for model updates in the centralized architecture of existing retail equipment management systems, and provides a distributed intelligent decision-making system based on cloud and edge node collaboration.

[0038] Specifically, the present invention aims to solve the following technical problems: (1) A hierarchical intelligent architecture is realized to achieve multi-agent collaborative decision-making in the cloud and autonomous execution on the device side, so that the system can both optimize the whole network strategy and ensure the safe operation of a single device in offline scenarios; (2) Establish a dynamically adjustable hierarchical autonomous authority mechanism (L0-L4 five levels) to enable equipment with different maturity and risk levels to have appropriate autonomous decision-making capabilities; (3) Establish a structured cloud-edge two-way collaboration mechanism, including conflict resolution rules, decision logs and post-event review system; (4) Provide a conservative and gradual model evolution mechanism to ensure that each update of the AI ​​decision model is fully verified, manually approved and released in a gray-scale manner, so as to achieve a secure deployment with zero impact on business.

[0039] This invention discloses a distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration, comprising: The cloud-based intelligent layer, the device-side intelligent layer, and the physical hardware layer are connected sequentially. The cloud-based intelligent layer includes an orchestration agent and multiple specialized sub-agents, used for strategy analysis, decision optimization, and on-site operational management of retail devices across the entire network. The device-side intelligent layer deploys a node agent for each retail device and directly controls the physical hardware layer through the hardware abstraction layer; The node agent has a dynamically adjustable hierarchical autonomy level. The cloud intelligence layer dynamically adjusts the autonomy level of each retail device according to the device's operating status, enabling devices with different maturity and risk levels to have appropriate autonomous decision-making capabilities.

[0040] In a specific implementation, this invention proposes a distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration, such as... Figure 1 As shown, its overall architecture consists of three layers: the Cloud Agent Layer, the Node Agent Layer, and the Hardware Layer. The three layers communicate bidirectionally via the MQTT protocol (QoS1-2).

[0041] Furthermore, the cloud-based intelligent layer includes an Orchestrator + Sub-Agents multi-agent architecture.

[0042] The cloud intelligence layer includes an orchestrator agent and multiple specialized sub-agents for strategy analysis, decision optimization, and on-site operational management of retail devices across the entire network.

[0043] Specifically, for retail equipment, a dedicated AI agent has been implemented: Vending Agent – ​​Handles scenarios such as browsing time, product recommendations, low inventory, and payment discounts; Smart Locker Agent – ​​Handles scenarios such as package delivery, pickup, overdue items, and member identification; Kiosk Agent – ​​Handles scenarios such as add-to-cart recommendations, allergen detection, meal set calculation, and queue management; Each agent has its own dedicated toolset (22+ tools) and automatically routes users to the corresponding agent based on device type. This demonstrates that the system has the capability for multi-agent collaboration based on device type.

[0044] The Orchestrator Agent is responsible for understanding the operator's natural language intent, breaking down high-level instructions into specific tasks, scheduling the corresponding Sub-Agents to execute, synthesizing results, and managing context and memory.

[0045] The specialized sub-agents include: (a) Inventory Agent: Responsible for network-wide inventory analysis, demand forecasting, and intelligent replenishment route planning; (b) Pricing Agent: Responsible for price optimization, promotional effectiveness analysis, and flexible pricing; (c) Customer Agent: Responsible for customer insights, churn prediction, and targeted marketing; (d) Operations Agent: Responsible for equipment health prediction, anomaly detection, and maintenance scheduling; (e) Analytics / Finance Agent: Responsible for revenue analysis, trend discovery, and reconciliation auditing; (f) Fleet Management Agent: such as Figure 6 As shown, the responsibilities include replenishment route optimization (TSP / VRP algorithm), maintenance dispatch, fleet scheduling, compliance tracking, and cost control.

[0046] All agents interact with platform services through the MCP Interface Layer, which adopts a four-layer architecture of Transform→Compute→Cache→Auth and provides business semantic tools. The Model Context Protocol (MCP) is a communication protocol for standardized interaction between AI agents and external tools, defining a unified interface specification for tool registration, input pattern description, invocation execution, and result return.

[0047] Specifically, a standardized tool call interface layer is built, including: Tool Registry — All tools are registered uniformly and can be searched by name; Pure function execution—every tool is a deterministic pure function: same input + context = same output; JSON Schema-driven—each tool has a standard input pattern definition that supports automatic form generation; Scene awareness—All tools receive the current scene context (weather, crowds, network status, etc.). The tools cover six major areas: inventory management, pricing strategy, customer analysis, data analysis, locker operation, and ordering machine operation.

[0048] The Tool Sandbox feature has been implemented, allowing users to manually invoke any tool, fill in parameters, and view results in exploration mode. This further verifies the integrity and operability of the tool system.

[0049] Platform Services include a data backend (PostgreSQL + TimescaleDB + Redis), a module marketplace, and an event bus (MQTT Broker + Message Queue).

[0050] Furthermore, the device-side intelligent layer includes four main components: Node, Agent, etc.

[0051] Each retail device deploys a Node Agent, which includes the following four core components: (a) Routine Scheduler: Performs daily tasks according to a predefined schedule, including 06:00 morning check, 07:00-23:00 all-day monitoring, 14:00 midday report, 23:00 daily summary and 02:00 late-night maintenance; (b) Local Decision Engine: Includes a rule engine (if-then rules, which can be updated from the cloud), a lightweight machine learning model (TFLite / ONNX format), and a threshold management module for autonomous decision-making on the device. (c) Local Memory: Stores edge data such as 7-day transaction history, frequent customer tokens and last purchase records, sales patterns and decision logs; (d) Action Executor: Controls hardware, updates the UI, and sends alarms via HAL; Physical devices can be directly controlled through the Hardware Abstraction Layer (HAL), including motors (screw / lift / gravity / storage lockers), sensors (temperature / door / power / network), payment terminals (Octopus / QR / NFC), screens (touchscreen / LED / screenless), and door locks (electromagnetic locks / mechanical locks).

[0052] Furthermore, such as Figure 2 As shown, the two-way collaboration mechanism includes—autonomy level + conflict resolution + decision log.

[0053] (1) Five-level autonomy rating system (L0-L4): L0 (Pure Execution): The Node Agent only executes instructions issued by the Cloud and does not make any autonomous decisions; the Cloud has complete control. Suitable for the initial deployment of new machines and high-risk scenarios. L1 (Monitoring and Alerts): The Node Agent performs autonomous monitoring, issuing alerts but taking no action upon detecting issues. The Cloud receives the alerts and then makes a decision. Suitable for the testing phase. L2 (Security Autonomy): The Node Agent autonomously executes security-related decisions (stopping sales, disabling channels, refunds), and reports other decisions to the Cloud. The Cloud is responsible for policy decisions and reviews security decision logs. This is the default level for most machines. L3 (Autonomous Operation): Building upon L2, it adds capabilities such as local recommendations, simple promotion execution, and automatic inventory alert notifications. The Cloud handles high-level strategy and model updates. Suitable for stable machines. L4 (Fully Autonomous): Operates entirely autonomously within the authorized scope, only notifying the Cloud in case of anomalies. The Cloud only monitors and handles exceptions. Suitable for mature scenarios and low-risk product categories.

[0054] Cloud Agent can dynamically adjust the autonomy level of each device based on its operational status. Operators can set the autonomy level for each device through the autonomy level control panel.

[0055] (2) For example Figure 3As shown, there are six conflict resolution rules: Rule 1 (Inventory Status Conflict - Node Priority): The Node is the source of physical truth. When the Cloud record and the Node sensor detection results are inconsistent, the Node shall prevail. Rule 2 (Pricing Conflict - Cloud Priority): Pricing reflects the operator's strategic intent, and the price issued by the cloud will always override the local cache of the node; Rule 3 (Duplicate Transactions - ID Idempotency): Each transaction has a unique ID, and duplicates are automatically removed during upload after reconnection; Rule 4 (Safety vs. Operations - Safety First): Safety-related decisions (abnormal temperature → stop sales, door forcibly opened → lock) always take precedence over operational decisions (promotion, recommendation); Rule 5 (Command Validity - Timestamp Sorting): Cloud commands to be executed during offline periods have an expiration date; expired commands are automatically discarded upon reconnection. Rule 6 (Model Version Conflict - Cloud Priority + Rollback): After the Cloud distributes a new model, the Node will only switch if the verification is successful; otherwise, it will roll back to the previous version.

[0056] (3) Structured decision log: Each autonomous decision made by the Node Agent is recorded in a JSON-formatted decision log, which includes information such as triggering conditions, context, actions performed, and the level of autonomy on which they are based. This log is then uploaded to the Cloud for post-event review.

[0057] Furthermore, such as Figure 4 As shown, the model evolution mechanism includes a conservative, gradual, six-step closed-loop process.

[0058] A conservative and gradual model evolution mechanism is adopted to ensure the safe and reliable updating of AI decision-making models, which includes the following six steps: Step 1 (Cloud Training): Collect decision logs and operational data from the entire network, train / fine-tune the decision model (pricing, inventory, anomaly detection), and generate a candidate version (candidate-vX.YZ) after model compression (quantization / distillation). The candidate version will never be directly deployed to the production environment. Step Two (Staging Test Environment Verification): Perform offline replay (30 days of real-world data replay) and live verification (3-5 Staging Nodes running for ≥72 hours) in an independent Staging Node group, monitoring accuracy, inference latency (<50ms), and resource usage (<80%). Safety-related decision regression = 0; otherwise, automatically reject. Automatically generate a "Model Validation Report." Step 3 (Manual Approval – Mandatory Gate): The approval request is pushed to the Dashboard and notifications. The approver reviews the verification report, decision discrepancies, and risk assessment. The result is APPROVE (entering grayscale), REJECT (returning to training), or DEFER (deferred, not automatically approved after 7 days). High-risk models (such as anomaly detection) require dual approval (technical + operations). Step 4 (Gray Release - Three Stages): Canary Stage (5% of devices, observation ≥48h) → Phased Stage (25% → 50%, each stage ≥24h) → Full Rollout (100% full rollout). Each stage has an automatic rollback gate, with a minimum total timeline of 4-5 days. Manual pause / rollback is possible at any stage. Step 5 (Production Deployment—02:00 Maintenance Window): Notify the device via MQTT QoS 2, and after CDN download and SHA-256 verification, perform a local benchmark (replay of nearly 100 decisions) on the Node. For example... Figure 5 As shown, the Node uses a three-slot design (Active is currently running / Shadow is a new model to be switched / Rollback is the previous stable version). If the verification is successful, Shadow will switch to Active; if the verification fails, there will be no impact on the business. Step Six (Continuous Monitoring – 14 Days): Monitor across six dimensions (decision quality, security, performance, resources, business, and stability). Automatic rollback trigger conditions: security anomalies > 0, accuracy drop > 5%, Node crash. Rollback completes within 10 seconds (no download required, the previous version is already in the Rollback slot). After 14 days, a performance summary is generated, marked as STABLE, and the performance data is fed back into the next training round.

[0059] Furthermore, the system also supports emergency full network rollback: the operator can trigger it with one click through the Dashboard, the Cloud broadcasts the rollback command (MQTT QoS 2), each Node completes the Active→Rollback switch within 10 seconds, the model is marked as RECALLED, and an incident report is automatically generated.

[0060] Different verification intensities are applicable to models with different risk levels: anomaly detection (high risk) requires 7 days of staging + two-person approval + 7 days of canary processing; inventory / pricing (medium risk) adopts the standard process; recommendation / personalization (low risk) adopts the standard process but canary processing can be shortened to 24 hours.

[0061] In a specific embodiment, such as Figure 8 As shown, the intelligent replenishment scenario uses vending machine A3 in a shopping mall in Hong Kong, China as an example to illustrate the intelligent replenishment process of the system: (1) The Node Agent’s Routine Scheduler executes the midday news task at 14:00. The local DecisionEngine predicts that five beverages will be out of stock on the machine tomorrow based on the 7-day sales pattern data stored in Local Memory. (2) The prediction is reported to the Inventory Agent on the Cloud via MQTT QoS 1; (3) The Inventory Agent integrates the inventory data and sales forecasts of the entire network to confirm the replenishment needs of A3. At the same time, the Customer Agent detects that the customer flow of the nearby C12 site will increase by 40% on Friday and needs to be replenished in advance. The Pricing Agent marks that there are near-expiry products on the E5 machine and new products need to be replenished after the price is reduced. (4) The Fleet Management Agent integrates the above information, uses the TSP / VRP algorithm to generate the optimal replenishment route (A3→C12→E5), assigns van-01 to execute it, automatically calculates the required number and volume of SKUs, matches vehicle capacity, and avoids the lunch rush period; (5) After the replenishment staff arrives at the site according to the route, they scan the code through the field service App to confirm the replenishment. The Node Agent's sensor verifies the inventory change. After the verification is successful, the work order status changes to VERIFIED, and the Cloud updates the inventory data of the entire network.

[0062] In a specific embodiment, a complete scene configuration system is constructed. (1) Simulate various variables in a real retail environment: Location—shopping malls, offices, hospitals, universities, etc.; Time period—0-23 hours, affecting pedestrian flow and decision-making; Foot traffic – low / medium / high – affects sales forecasts and replenishment recommendations; Weather—sunny / rainy / typhoon / cold weather—affects sales and logistics decisions; Network status—online / unstable / offline—determines whether to use cloud services; Hardware failures—logging, sensor malfunctions, screen errors, etc., analog device malfunctions; Special events—holidays, typhoons, weekends, clearance sales, promotions; Each scenario variable directly affects the tool's output and rule decisions, demonstrating that the system has the ability to dynamically adjust its decisions based on the environment.

[0063] (2) The end-to-end process for shipment failures, including: The "Due to Inventory" hardware failure option in the scene panel → triggers a 100% shipment failure rate; Shipment overlay—displays shipment progress and provides "retry" and "cancel" options in case of failure; Workflow step status—when there is a fault, the circle turns red and displays [indicating a problem]. Icons and "Glitch" labels; Receipt overlay—displays order details and member points after successful shipment; can be manually closed. Post-purchase pipeline events—trigger subsequent AI processing (inventory update, points calculation, and product recommendation); This demonstrates that the system can handle physical failures of edge devices and respond in real time at the node, without relying on cloud commands.

[0064] (3) Four-step decision pipeline

[0065] Trigger Event — Receives raw event data (such as customer browsing, payment, low inventory alerts); AI Agent Loop — Performs inference analysis via tool calls (supports local fast mode and cloud LLM mode). Business Rules Validation — Conducting compliance reviews (approval / modification / blocking) of AI's decisions; Workflow execution—translating decisions into concrete operational steps; This pipeline uses an asynchronous generator architecture, supports streaming output and mid-stream cancellation, and is the core implementation of the "three-layer architecture" in the patent.

[0066] (4) Conflict resolution rules

[0067] A complete conflict resolution rule engine is implemented in business-rules.ts, where each rule returns one of three rulings: pass — Decisions are compliant and implemented directly; mod (modify) — Decisions need to be adjusted before execution (e.g., automatically capped when the discount exceeds 20%). blk (block) — Decision violation, refusal to execute (e.g., blocking the distribution of discounts when the promotion budget has been exhausted); The specific rules include: Budget conflict—preventing discounts from being issued when the promotional budget is exhausted; Offline conflict—automatic fallback to local cache strategy when network connection is lost; Weather-related conflicts—Replenishment will be temporarily suspended and dynamic pricing will be implemented during typhoons; Business hours conflict—promotional information is delayed late at night; Capacity conflict—If there are no empty lockers, delivery will be refused and the locker will be redirected to an alternative location.

[0068] In a specific embodiment, such as Figure 7 As shown, the safety autonomous decision-making scenario uses a cold chain vending machine B7 in a shopping mall in Macau, China as an example to illustrate the decision-making process under the L2 safety autonomy level: (1) The temperature sensor of the Node Agent detected an abnormal increase in the internal temperature of the device (exceeding the preset threshold). (2) The device's autonomy level is L2 (safe autonomy), and the Decision Engine determines this to be a safety-related event; (3) The Node Agent immediately and autonomously executes the sales suspension operation (displaying "Suspend service" and disabling payment terminals on the HAL control screen) without waiting for a response from the Cloud; (4) At the same time, the Decision Log records the complete decision log (triggering condition: temperature > threshold, context: current temperature value, action: stop sales, basis level: L2 security autonomy); (5) Decision logs and alarms are reported to the Cloud via MQTT, and the Operations Agent classifies them as P0 safety-related faults (4h SLA). (6) The Fleet Management Agent automatically generates high-priority maintenance dispatch orders, matches the nearest available technician with refrigeration system qualifications, and predicts the required spare parts; (7) After the technician completes the on-site repair, the Node Agent performs a self-test to confirm that the hardware is normal, and the work order is closed. The entire timeline of the process is recorded and can be used for food safety audits.

[0069] In a specific embodiment, the model update deployment scenario uses the update of the whole network pricing model as an example to illustrate the conservative and gradual model evolution mechanism: (1) Collect decision logs from the entire network for 30 days on the cloud side, train a new version of the pricing model (pricing-v2.1.0), and generate candidate versions after quantization and compression; (2) The candidate version was deployed to 3 Staging Nodes for 30 days of offline data playback and 72 hours of real-world verification. The monitoring results showed that the accuracy improved by 3%, the inference latency was 38ms (<50ms), the resource usage was 65% (<80%), and the security decision regression was 0. (3) The system automatically generates a "Model Validation Report" and pushes the approval request to the Dashboard. Since the pricing model is of medium risk, it requires approval by one person. The approver reviews the report and clicks "APPROVE". (4) Entering the gray-scale release: In the Canary phase, the deployment was carried out to 5% of the devices (about 20 units), and no abnormalities were observed for 48 hours; in the Phased phase, the deployment was expanded to 25% (100 units), and after 24 hours, it was expanded to 50% (200 units), and all phases were normal; (5) Full Rollout is executed during the 02:00 maintenance window: MQTT QoS 2 notifies all network devices → CDN downloads model file → SHA-256 verification passes → local Benchmark (100 historical decision replays) passes → Shadow → Active switchover complete; (6) Enter the 14-day continuous monitoring period. All six dimensions of monitoring are normal. After 14 days, the model is marked as STABLE and the performance data is fed back to the next round of training.

[0070] If the accuracy drops to >5% at any stage in step (4), the system will automatically trigger a rollback. The affected Node will switch from Active to Rollback slot (the previous stable version) within 10 seconds, with zero impact on business operations.

[0071] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0072] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration, characterized in that, include: The cloud-based intelligent layer, the device-side intelligent layer, and the physical hardware layer are connected sequentially. The cloud-based intelligent layer includes an orchestration agent and multiple specialized sub-agents, used for strategy analysis, decision optimization, and on-site operational management of retail devices across the entire network. The device-side intelligent layer deploys a node agent for each retail device and directly controls the physical hardware layer through the hardware abstraction layer; The node agent has a dynamically adjustable hierarchical autonomy level. The cloud intelligence layer dynamically adjusts the autonomy level of each retail device according to the device's operating status, enabling devices with different maturity and risk levels to have appropriate autonomous decision-making capabilities.

2. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, The orchestration agent is used to understand the operator's natural language intent, decompose high-level instructions into specific tasks, schedule the corresponding Sub-Agent to execute, synthesize results, and manage context and memory.

3. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, The specialized sub-agents include: Inventory Agent: Used for comprehensive network inventory analysis, demand forecasting, and intelligent replenishment route planning; Pricing agency: Used for price optimization, promotional effectiveness analysis, and flexible pricing; Customer Agent: Used for customer insights, churn prediction, and targeted marketing; Operations agent: Used for equipment health prediction, anomaly detection, and maintenance scheduling; Analysis / Financial Agency: Used for revenue analysis, trend discovery, and reconciliation auditing; Fleet management agent: used for replenishment route optimization, maintenance dispatch, fleet scheduling, compliance tracking and cost control.

4. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, The cloud-based intelligent layer also includes the MCP interface layer and the platform service layer; The agent interacts with the platform service layer in a standardized manner through the MCP interface layer, which adopts a four-layer architecture to provide business semantic tools. The platform service layer includes a data backend unit, a module marketplace unit, and an event bus unit.

5. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, The node agent includes: Routine scheduler: Used to execute daily tasks according to a predefined schedule; Local decision engine: Includes a rule engine, a lightweight machine learning model, and a threshold management module, for autonomous decision-making on the device; Local memory: used to store transaction history, frequent customer tokens and last purchase records, sales patterns, and decision log edge data; Action executor: Used to control hardware, update the UI, and send alarms through the hardware abstraction layer.

6. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration according to claim 1, characterized in that, The physical hardware layer includes: motors, sensors, payment terminals, screens, and door locks. The physical hardware layer is uniformly controlled through a hardware abstraction layer.

7. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, This also includes dynamically adjusting the autonomy level of each retail device based on its operating status; L0: The node agent only executes the instructions issued by the cloud and does not make any independent decisions. The cloud has complete control. L1: The node agent monitors itself and only sends out alerts without taking action when it detects problems. The cloud receives the alerts and then makes decisions. L2: Node agents autonomously execute security-related decisions, while other decisions are reported to the cloud. The cloud is responsible for policy decisions and reviews security decision logs. L3: Based on L2, it adds local recommendation, simple promotion execution, and automatic inventory warning notification capabilities, while the cloud is responsible for high-level strategy and model updates; L4: Operates completely autonomously within the authorized scope, only notifying the cloud in case of anomalies; the cloud only monitors and handles exceptions.

8. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration according to claim 1, characterized in that, The node agent and the cloud also include conflict resolution rules; Rule 1: The Node is the source of physical truth. When the Cloud records are inconsistent with the Node sensor detection results, the Node shall prevail. Rule 2: Prices issued by the Cloud override the local cache of the Node; Rule 3: Each transaction has a unique ID, and duplicates will be automatically removed during upload after reconnection; Rule 4: Safety-related decisions take precedence over operational decisions; Rule 5: Cloud's pending instructions during offline periods have an expiration date; expired instructions will be automatically discarded upon reconnection. Rule 6: After the Cloud distributes a new model, the Node will only switch if the verification is successful; otherwise, it will roll back to the previous version.

9. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, Each autonomous decision made by the node agent is recorded in a JSON-formatted decision log, which includes the triggering conditions, context, actions performed, and the autonomy level information on which they are based, and is uploaded to the cloud for post-event review.

10. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, This also includes system updates through conservative, gradual model evolution mechanisms, including: Step 1: Collect decision logs and operational data from the entire network, train / fine-tune the decision model, and generate candidate versions after model compression; Step 2: Perform offline replay and live testing in a separate Staging Node group to monitor accuracy, inference latency, and resource consumption; Step 3: The approval request is pushed to the Dashboard and notifications, where the approver can view the verification report, decision discrepancies, and risk assessment. Step 4: Conduct three-stage verification for grayscale release, with an automatic rollback gate set for each stage; Step 5: Notify the device via MQTT QoS 2, and after CDN download and SHA-256 verification, perform local benchmark testing on the node. The node adopts a three-slot design. If the verification is successful, it will be activated; if the verification fails, the service will be unaffected. Step Six: Monitor from six dimensions and automatically roll back the trigger conditions: security anomaly > 0, accuracy drop > 5%, node crash. Periodically generate an effect summary, mark it as STABLE, and feed the effect data back to the next round of training.

11. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 1, characterized in that, The cloud-based intelligent layer also includes dedicated agents categorized by device type, including: Vending machine agent: Used for handling browsing dwell time analysis, product pairing recommendations, low inventory response, and payment discount scenarios; Smart locker agent: Used to handle parcel delivery, pickup verification, overdue management, and member identification scenarios; Intelligent ordering machine agent: used to handle scenarios such as add-to-cart recommendations, allergen detection, meal calculation, and queue management; Each device type has its own dedicated agent with its own toolset, and the system automatically routes devices to the corresponding dedicated agent based on their type.

12. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 5, characterized in that, The local decision engine of the node agent uses a four-step decision pipeline for event processing, including: Step 1, Trigger Events: Receive raw event data, including guest browsing events, payment events, and low inventory alert events; Step 2, AI Agent Loop: Inference analysis is performed through tool calls, supporting local fast mode and cloud LLM mode; Step 3, Business Rule Verification: Conduct a compliance review of the AI's decision and return one of three rulings: pass, modify, or block. Step 4, Workflow Execution: Translate the validated decisions into specific operational steps; The four-step decision pipeline uses an asynchronous generator architecture, supporting streaming output and mid-process cancellation.

13. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 12, characterized in that, The business rule verification includes handling the following conflict scenarios: Budget conflict: Prevent discounts from being issued when the promotional budget is exhausted; Offline conflict: Automatic fallback to local cache strategy when network connection is lost; Weather-related issues: Restocking will be temporarily suspended and dynamic pricing will be implemented during the typhoon. Business hours conflict: Promotional information is delayed at night; Capacity conflict: If there are no empty lockers, delivery will be refused and the locker will be redirected to an alternative location.

14. The distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 10, characterized in that, It also includes an emergency full-network rollback mechanism: Operators can trigger a rollback command with a single click via the Dashboard; The cloud broadcasts a rollback command to all devices on the network via the MQTT QoS2 protocol; Each node agent completes the switch from the Active slot to the Rollback slot within 10 seconds; The rolled-back model version is marked as RECALLED. The system automatically generates an accident report.

15. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 10, characterized in that, Different levels of risk require different levels of validation strength: High-risk models include anomaly detection models, which require 7 days of staging validation, dual approval, and 7 days of canary observation. The medium-risk model includes an inventory model and a pricing model, and adopts a standard process; Low-risk models include recommendation models and personalized models, using standard procedures but with a 24-hour observation period in Canary.

16. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 3, characterized in that, The tasks generated by the fleet management agent employ complete lifecycle state management, including the following state transitions: PREDICTED status: AI predicts demand, including out-of-stock and outage trends; PLANNED status: Task generated and route optimized; ASSIGNED status: Matched personnel, vehicles, and spare parts; ENROUTE status: GPS tracking, supports dynamic route adjustment; INPROGRESS status: Replenishment, repair, or inspection operations are being performed; VERIFIED status: Confirmed by node agent self-check. After replenishment, the sensor verifies the correct inventory quantity. After repair, the node agent confirms normal hardware operation through self-check. CLOSED status: Data archiving and KPI statistics.

17. A distributed intelligent decision-making system for retail equipment based on cloud and edge node collaboration as described in claim 16, characterized in that, The task adopts an SLA-based graded response mechanism according to the severity of the fault: P0 safety-related faults include temperature control failure, door lock failure, and electrical leakage, requiring a response within 4 hours. P1 operational failures: These include shipping facility failures and offline payment terminals, requiring a response within 24 hours; P2 optimization-type faults: including screen failures and cosmetic damage, requiring a response within 72 hours; Replenishment task: Machines with a stockout rate exceeding 30% must be replenished within 24 hours.

18. A distributed intelligent decision-making method for retail equipment based on cloud and edge node collaboration, characterized in that, include: S1: Deploy orchestration agents and multiple specialized sub-agents in the cloud to perform strategy analysis, decision optimization, and on-site operation management for retail devices across the entire network; S2: Deploy a node agent on each retail device, the node agent directly controlling the physical hardware through a hardware abstraction layer; S3: Dynamically adjust the autonomy level of each retail device according to the device's operating status. The autonomy level includes five levels: L0 Pure Execution, L1 Monitoring and Alarm, L2 Security Autonomy, L3 Operational Autonomy, and L4 Full Autonomy. S4: The node agent autonomously executes decisions within its autonomy level authorization scope, and decisions exceeding the authorization scope are reported to the cloud for processing; S5: Each autonomous decision made by the node agent is recorded in the decision log and uploaded to the cloud for post-event review; S6: Data inconsistencies are handled between the cloud and node agents according to conflict resolution rules, which include: inventory status is based on node sensors, pricing is based on cloud-issued pricing, transactions are deduplicated using unique IDs, security decisions take precedence over operational decisions, instructions have expiration dates during offline periods, and model updates require local verification before switching.

19. A distributed intelligent decision-making method for retail equipment based on cloud and edge node collaboration as described in claim 18, characterized in that, It also includes system updates through conservative, incremental model evolution methods, including: S7: Collect decision logs and operational data from the entire network, train or fine-tune the decision model, and generate candidate versions after model compression; S8: Perform offline playback and real-machine verification in a separate StagingNode group; S9: Push the approval request to the dashboard, where the approver reviews the verification report and decides whether to approve, reject, or postpone it; S10: Conduct three-stage verification for canary release, namely, deploying 5% of devices in the Canary stage, expanding to 25% to 50% in the Phased stage, and full rollout deployment, with an automatic rollback gate set in each stage; S11: Notify the device to download the new model via MQTTQoS2, and perform local benchmark testing on the node. The node adopts a three-slot design. If the verification is successful, it will be activated; if the verification fails, there will be no impact on the business. S12: Conduct 14 days of continuous monitoring across six dimensions: decision quality, security, performance, resources, business, and stability. Once the conditions are met, the system is marked as stable.

Images