Hardware autonomous control method and system based on spatial intelligence and self-evolution learning

Abstract

This invention discloses a hardware autonomous control method and system based on spatial intelligence and self-evolutionary learning, an electronic device, and a computer-readable storage medium. The system includes: a multi-source device discovery module for automatically scanning intelligent hardware devices and establishing a unified device model through multiple communication protocols; a capability reflection module for automatically extracting device control capabilities and parameter constraints from protocol metadata; a skill management module for storing and loading skill packages and establishing a mapping index from device type to skill package; a rule engine module for performing millisecond-level deterministic evaluation of sensor data and generating control commands; an intelligent decision engine module for orchestrating planning nodes and execution nodes based on state diagrams and making context-aware control decisions through a large language model; a command security module; an execution verification module; a multi-layer memory module; a preference learning module; and a multi-layer self-evolutionary engine module.

Description

Technical Field

[0001] This invention relates to the field of integrated control technology of artificial intelligence and Internet of Things, specifically to a hardware autonomous control method and system based on spatial intelligence and self-evolutionary learning. This method and system are driven by a large language model and have skill orchestration and a multi-layer self-evolutionary mechanism. Background Technology

[0002] With the rapid development of IoT technology, smart home systems have evolved from remote control of single devices to scenario-based automation involving multiple devices. Current mainstream smart home control paradigms primarily employ trigger-execution programming mechanisms or static rule engines. This means users predefine "if A, then B" conditional rules, and the system executes preset actions when a trigger condition is detected. This paradigm requires users to possess a certain level of logic programming ability, and the system's response is mechanical and deterministic, unable to adapt to dynamic environmental changes or understand users' ambiguous natural language commands.

[0003] With the explosive growth of large-scale language models, AI agent systems centered around these models are becoming a new paradigm for smart hardware control. Existing agent system architectures mainly fall into the following categories: The first is a simple text intent converter that maps user natural language commands to device control interface calls. This approach only supports single-turn command mapping and lacks contextual understanding and multi-step reasoning capabilities. The second is a linear dialogue agent based on chained reasoning, achieving multi-step reasoning through prompt word engineering. However, its architecture is a single linear pipeline, unable to differentiate between the different latency requirements of safety-critical scenarios and comfort optimization scenarios. Furthermore, each decision relies entirely on the online reasoning of the large language model, leading to complete system failure when the model service becomes unavailable. The third is a customized component deeply integrated into existing open-source home platforms. While leveraging the platform's existing device ecosystem, its device intelligence logic is deeply coupled with the platform, requiring modifications to the core code for new device types, thus limiting scalability.

[0004] In recent years, academia and industry have begun to focus on the self-evolving capabilities of AI agents. Self-evolving agents are intelligent systems that can autonomously improve their decision-making strategies, knowledge bases, and behavioral patterns through continuous interaction with their environment during operation. Related research has proposed several self-evolving paradigms: recursive self-improvement frameworks based on self-references achieve continuous optimization by allowing the agent to modify its own logic and behavior; open self-improvement systems based on evolutionary search achieve capability growth by maintaining an archive of agent variants and generating new versions using a base model; experience-driven lifecycle evolution methods achieve long-term adaptation by distilling interactive experiences into reusable capabilities; and context-based self-optimization methods based on cue word evolution achieve decision improvement by synthesizing policy guidelines from execution trajectories. However, these studies are mainly geared towards general programming tasks or gaming environments and have not yet been effectively applied to the specific field of IoT smart hardware control.

[0005] In summary, existing solutions share the following common technical shortcomings: (1) Lack of domain knowledge encapsulation mechanism specific to equipment type. The existing system uses a unified big language model for reasoning on all devices. The model does not understand the interaction between humidifiers and air conditioners in humidity regulation, nor does it understand the domain rules that the color temperature of lights should be adjusted according to the diurnal rhythm, resulting in insufficient accuracy and professionalism of control decisions.

[0006] (2) Lack of a hierarchical decision-making architecture for safe fast paths and intelligent slow paths. Pure rule systems cannot understand context and natural language, while pure large language model systems suffer from high inference latency and poor determinism. When a safety threshold alarm occurs in the physical environment (such as when the temperature exceeds the safe range), waiting for the large language model to make inference may delay the process by several seconds, posing a safety risk.

[0007] (3) Lack of ability to continuously learn preferences from users’ long-term usage behavior. The user preferences of the existing system are configured statically and once, and cannot be automatically learned and evolved according to the actual operating habits of users at different times and in different seasons. The personalization level of the system has stagnated for a long time.

[0008] (4) Lack of physical security verification mechanism for instructions generated by large language models. Large language models may generate parameter values ​​that exceed the capabilities of the device, call non-existent device functions, or generate multi-device control instructions with logical conflicts. Direct execution of these instructions may result in device damage or security risks. Current benchmark studies show that even the most advanced large language models have an extremely low correct rejection rate when faced with invalid compound instructions.

[0009] (5) Lack of intelligent capabilities for zero-configuration access to new device types. When users add new device types, developers need to manually write control logic and decision rules, and non-technical users cannot expand the system's device support range on their own.

[0010] (6) Lack of self-evolution capability of the agent system. The decision-making strategies, prompt word templates and automation rules of existing smart home agent systems remain static after deployment, and cannot autonomously optimize their decision-making logic, knowledge structure and behavior strategies based on the successful and failed experiences accumulated over a long period of operation. The intelligence level of the system is limited by the initial design and cannot be continuously improved with the increase of usage time.

[0011] Therefore, there is an urgent need for an intelligent hardware autonomous control method and system that can achieve domain knowledge-driven device intelligent orchestration, security and intelligent hierarchical decision-making, continuous preference learning and behavior evolution, security verification of large language model output, generation of new device automated skills, and multi-layer self-evolution of agent decision-making strategies, prompt word templates and automation rules. Summary of the Invention

[0012] To address the technical problems existing in current intelligent hardware control systems, such as the lack of device-specific domain knowledge encapsulation, the lack of hierarchical security and intelligent decision-making, the inability of user preferences to continuously learn and evolve, the lack of physical security verification in large language model outputs, the inability to intelligently access new device types with zero configuration, and the lack of self-evolving decision-making strategies and knowledge structures in agent systems, this invention provides a hardware autonomous control method and system based on spatial intelligence and self-evolutionary learning, an electronic device, and a computer-readable storage medium.

[0013] This invention provides a hardware autonomous control method based on spatial intelligence and self-evolutionary learning, comprising: S1: Automatically scan and connect to smart hardware devices through a multi-source device discovery mechanism, establish a unified device model, and automatically extract the control capabilities and parameter constraints supported by each device through a protocol metadata reflection mechanism to generate a standardized capability description. S2: Construct a skill package system, with each skill package corresponding to a device type. Each skill package contains a domain knowledge base, decision prompt word templates, learning prompt word templates, and executable action scripts. A mapping index from device type to skill package is established through a skill loader. S3: When a change in sensor data is detected, a dual-path decision architecture of fast rule path and slow language model is used for control decision. The rule engine generates deterministic control instructions in millisecond-level response for events that meet the safety threshold conditions. For scenarios not covered by the rule engine, the intelligent decision engine based on state graph performs context-aware control decision through planning nodes and execution nodes. S4: The planning node assembles the device's real-time status, user memory context, environmental snapshot, and available skill summary into structured prompt words. The large language model generates a priority task plan list. The execution node executes tasks in order of priority. For skill execution tasks, the corresponding skill package is loaded. The large language model makes device-level decisions based on domain knowledge. S5: Perform capability matching and parameter safety processing on the control instructions generated by the large language model, including action name alias mapping, numerical parameter range pruning and step alignment, enumeration parameter fuzzy matching, and Boolean parameter type conversion; S6: After executing the control command, the execution effect is confirmed through the execution-verification-retry closed loop, that is, the device status is refreshed and the expected status is compared with the actual observed status. If there is a mismatch, the execution is re-executed within the maximum number of retries. S7: Write the execution result into the multi-layer memory system and trigger preference learning. The preference learning includes an incremental memory extraction stage and a special profile synthesis stage based on device type. The updated profile will automatically take effect in the next decision. S8: The system's decision-making strategy, prompt word templates, and automation rules are continuously and autonomously optimized based on a multi-layered self-evolutionary engine, which includes: The decision-making strategy self-evolution module extracts tactical corrections and strategic principles from successful and failed experiences through dual-stream analysis of the execution trajectory, and automatically updates the planning strategy prompts. The prompt word template self-evolution module identifies inefficient prompt word patterns through statistical analysis of device-level decision results and generates optimized prompt word variants, which replace the original templates after sandbox verification. The rule self-generation module automatically generates deterministic rules by identifying high-frequency, repetitive decision patterns and injects them into the rule engine; and The skill self-repair module automatically locates the root cause of skill execution failure and generates a repair patch through attribution analysis.

[0014] In one embodiment of the present invention, optionally, in step S1, the unified device model includes a device identifier, a device type, a capability list, and a sensor list.

[0015] In one embodiment of the present invention, optionally, in step S1, the multi-source device discovery mechanism adopts a four-layer priority merging strategy: manually configured devices are given the first priority, the cached cloud device list is given the second priority, real-time cloud discovery is given the third priority, and local area network broadcast discovery is given the fourth priority; the four-layer discovery results are merged in priority order, and network address and device identifier are used for dual-dimensional cross-duplicate removal.

[0016] In one embodiment of the present invention, optionally, in step S1, the protocol metadata reflection mechanism extracts command group definitions from the device class metadata of the protocol library for devices of known models, and extracts parameter lists, parameter types and parameter constraints through function signature analysis; for devices of unknown models, it automatically downgrades to a general reflection capability based on service identifiers and attribute identifiers.

[0017] In one embodiment of the present invention, optionally, in step S3, the intelligent decision engine includes two independent state graphs: a periodic scheduling graph triggered by a timer, supporting three task types: environment refresh, skill execution, and response; and a user dialogue graph triggered by natural language interaction, additionally supporting two task types: user inquiry and system action. The two state graphs share the skill execution engine, memory system, and environmental perception infrastructure.

[0018] In one embodiment of the present invention, optionally, in step S7, the multi-layer memory system comprises five layers: the first layer is a human-readable and editable explicit user preference declaration; the second layer is a behavior history record of a scrolling window; the third layer is a persistent memory extracted from the history by a large language model, stored by topic classification, including four categories: preference, habit, constraint, and context; the fourth layer is a five-dimensional preference profile independently synthesized according to device type, with the five dimensions being stable preference, time period pattern, seasonal pattern, weak signal, and confidence level description; and the fifth layer is a cold start default value automatically generated according to the type of connected device.

[0019] In one embodiment of the present invention, optionally, in step S7, the incremental memory extraction stage tracks the processed historical positions through a cursor mechanism, and only processes newly added historical batches each time; the large language model is guided to prioritize updating existing memories with the same topic, filter one-time execution noise, and issue forgetting instructions to outdated memories to maintain the freshness of the memory bank during extraction.

[0020] In one embodiment of the present invention, optionally, in step S7, the specialized profile synthesis stage by device type loads the exclusive learning prompt word template in its skill pack for each device type, and uses the relevant history, current profile and associated memory extracted in the first stage as input to synthesize a five-dimensional preference profile by the large language model; before learning, an evidence threshold is checked, requiring at least a preset number of relevant historical records before learning is started.

[0021] In one embodiment of the present invention, optionally, in step S8, the decision strategy self-evolution module adopts a dual-stream analysis mechanism: the first stream is the tactical correction stream, which extracts the root causes of failure from the decision records of verification failure or low confidence and generates targeted tactical correction entries, which are then added to the planning strategy prompt words; the second stream is the strategic principle stream, which summarizes the general decision principles across scenarios from the continuous successful and high-confidence decision sequences and writes them into the global strategy part of the planning strategy prompt words; when the number of tactical correction entries exceeds the preset limit, the large language model merges and simplifies the existing entries.

[0022] In one embodiment of the present invention, optionally, in step S8, the prompt word template self-evolution module maintains a performance rating table for the decision prompt word template of each skill pack. The performance rating is calculated based on the verification pass rate, first-time success rate, no-operation reasonableness rate, and user satisfaction. When the performance rating is lower than a preset threshold, an optimization process is triggered, and an optimized prompt word variant is generated by a large language model. The prompt word variant is compared and verified in a sandbox environment using historical decision scenarios, and replacement is only approved when the comprehensive score of the new variant is not lower than that of the original template.

[0023] In one embodiment of the present invention, optionally, in step S8, the rule self-generation module performs sliding window aggregation analysis on the slow path decision records. When the frequency of occurrence of a certain decision pattern exceeds a preset frequency threshold and the verification pass rate exceeds a preset pass rate threshold, a deterministic rule containing triggering conditions and execution actions is automatically generated. The generated rule is injected into the rule engine after security verification, and its priority is lower than that of manually preset rules. The system performs performance tracking on the self-generated rules, and rules that perform poorly during the observation period are automatically removed.

[0024] In one embodiment of the present invention, optionally, in step S8, the skill self-repair module is triggered when the number of consecutive failures or the cumulative failure rate of the skill package exceeds a preset threshold, and performs three stages: failure attribution analysis, patch generation, and patch verification. Failure attribution is classified into four categories: capability matching failure, parameter out-of-bounds, verification mismatch, and script execution anomaly. Patch verification includes format checking, abstract syntax tree parsing, and sandbox execution security verification. After repair, the performance of the skill package is continuously monitored, and if there is no significant improvement, it is rolled back to the version before repair.

[0025] In one embodiment of the present invention, optionally, in step S8, all outputs of the multi-layer self-evolutionary engine must pass security gating verification before being deployed to runtime. The security gating includes format integrity checks, semantic consistency checks, regression verification based on historical scenarios, and a progressive deployment mechanism. The progressive deployment mechanism runs the evolved content and the original content in parallel in shadow mode during the observation window period, and only officially switches when the simulation decision quality of the evolved content is not lower than that of the original content.

[0026] In one embodiment of the present invention, optionally, when a device discovers a new device type and there is no corresponding skill package in the system, the skill package generation process is automatically triggered: the large language model generates a complete skill package file based on the device capability description, including metadata files, domain knowledge files, decision prompt word templates, learning prompt word templates, and executable action scripts; each generated file is independently subjected to structured verification, and if the verification fails, the error information is fed back to the large language model for self-repair; after the verification passes, it is written to the skill catalog and the skill loader is triggered to rediscover it; the automatically generated skill package is included in the monitoring scope of the self-evolution engine.

[0027] In one embodiment of the present invention, the method may optionally further include a multi-device coordination decision-making step: designing and using coordinator skills to aggregate state snapshots, environmental sensor data and user preferences of all active devices, performing multi-device joint analysis by a large language model, detecting potential conflicts and synergies between devices, and outputting a coordinated list of multi-device control instructions according to the priority of safety over comfort and comfort over energy saving.

[0028] In one embodiment of the present invention, optionally, each rule in the rule engine includes a sensor name, comparison operator, threshold, control instruction, and cooling time; the cooling mechanism is based on a monotonic clock, and the same rule is not triggered repeatedly during the cooling period; the evaluation of the rule engine is independent of the availability of the large language model, ensuring deterministic response in safety-critical scenarios.

[0029] The present invention provides an electronic device including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0030] The present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0031] This invention provides a hardware autonomous control system based on spatial intelligence and self-evolutionary learning, comprising: The multi-source device discovery module is used to automatically scan smart hardware devices through multiple communication protocols and establish a unified device model. The capability reflection module is used to automatically extract device control capabilities and parameter constraints from protocol metadata; The skills management module is used to store and load skills packs and establish a mapping index from device types to skills packs; The rules engine module is used to perform millisecond-level deterministic evaluation of sensor data and generate control commands; The intelligent decision engine module is used to orchestrate planning nodes and execution nodes based on state diagrams and to make context-aware control decisions through a large language model. The instruction security module is used to perform capability matching and parameter verification on the control instructions output by the large language model. The execution verification module is used to execute control commands and verify the execution effect through status comparison; A multi-layered memory module is used to store user preferences, behavioral history, extracted memories, and learning profiles; The preference learning module is used to extract persistent memories from incremental behavioral history and synthesize preference profiles by device type; The multi-layered self-evolution engine module is used to autonomously optimize decision-making strategy prompts, device-level decision prompt templates, automation rules, and skill package code based on execution trajectory analysis.

[0032] In one embodiment of the present invention, optionally, the multi-source device discovery module maintains two core mappings: a device registry and an adapter routing table; the device registry stores a unified device model with the device identifier as the key; the adapter routing table stores the protocol adapter instance corresponding to the device with the device identifier as the key; control commands are executed after finding the corresponding adapter through the adapter routing table.

[0033] In one embodiment of the present invention, the system may optionally further include an event bus module for asynchronous event distribution among various functional modules; the event bus supports precise event type subscription and wildcard global listening, event processors are executed sequentially according to the registration order, and an exception isolation strategy is adopted, so that an exception of a single processor does not affect the execution of other processors.

[0034] Compared with the prior art, the present invention has the following beneficial technical effects: (1) By encapsulating the domain knowledge, decision templates, and learning templates specific to each device type into independent, hot-loadable units through the skill package system, the large language model makes decisions based on domain knowledge constraints, which significantly improves the accuracy of control commands and domain adaptability. When adding a new device type, only the skill package file needs to be added, without modifying the core code, and the system has high scalability.

[0035] (2) Through a two-layer decision-making architecture of fast rule path and slow big language model, safety-critical scenarios are responded to by the rule engine in milliseconds, without relying on the availability of big language model; complex scenarios are intelligently planned by big language model based on complete context. The two layers of decision-making share a unified device instruction model and execution path, which takes into account both safety determinism and intelligent flexibility.

[0036] (3) Through a five-layer memory architecture and a preference learning mechanism based on device type, the system can continuously extract preferences from users' long-term usage behavior and automatically update the learning profile. The cold start mechanism automatically generates an initial preference profile based on the type of connected devices. When a new device is connected, a reasonable control strategy can be provided. The system is continuously optimized as it is used, thus achieving continuous evolution of system behavior.

[0037] (4) The device capability description is automatically extracted through protocol metadata reflection, and a multi-layer parameter safety pipeline (including capability matching, range pruning, step alignment, and type conversion) is inserted between the output of the large language model and the device execution to effectively prevent damage to the physical device caused by abnormal instructions such as out-of-bounds parameters and unsupported actions generated by the large language model. The execution-verification-retry closed loop further ensures the actual execution effect of the control instructions.

[0038] (5) Through the automatic skill package generation mechanism driven by the large language model, the system can automatically analyze the capabilities of newly discovered device types and generate complete skill packages (including domain knowledge, decision templates, learning templates, and execution scripts), realizing zero-configuration intelligent access for new devices. The generation process includes multi-layer verification and self-repair mechanisms to ensure the availability and security of the generated skill packages.

[0039] (6) Through a multi-layered self-evolutionary engine, the system can autonomously extract decision-making experience from long-term execution trajectories, achieving dual-stream self-optimization of decision strategy prompts (parallel evolution of tactical correction and strategic principles), statistical-driven optimization of device-level prompt templates, automatic sedimentation of high-frequency slow-path decisions into deterministic fast-path rules, and automatic attribution and repair of skill package execution failures. This self-evolutionary mechanism enables the system's intelligence level to no longer be limited by the initial design, but to continuously and autonomously improve with the increase of running time, forming an open evolutionary closed loop of "execution → evaluation → evolution → better execution". Attached Figure Description

[0040] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a schematic diagram of the overall architecture of the intelligent hardware autonomous control system with self-evolution capability of the present invention. Figure 2 This is a flowchart illustrating the dual-path decision control method of the present invention; Figure 3 This is a schematic diagram of the hierarchical structure of the multilayer memory system of the present invention; Figure 4 This is a schematic diagram of the closed loop of skill execution and verification in this invention; Figure 5 This is a schematic diagram of the preference learning closed loop of the present invention; Figure 6 This is a schematic diagram of the architecture and data flow of the multi-layer self-evolution engine of this invention. Detailed Implementation

[0042] 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.

[0043] In this invention, "hardware" refers to intelligent hardware. Spatial intelligence means that the intelligent hardware no longer operates solely on "passive instructions," but can autonomously perceive, understand, and utilize its physical spatial environment, making autonomous decisions and controls based on spatial location, spatial relationships, and spatial layout. In this invention, the intelligent hardware can acquire the following physical spatial information in real time through sensors: (1) Its own position, posture, and orientation; (2) Surrounding obstacles and passable areas; (3) Spatial structure (rooms, passageways, boundaries); (4) The relative position of the target object in space.

[0044] The above forms the basis for intelligent hardware to "know where it is and what's around it," and it possesses the following spatial decision-making and autonomous control capabilities: (1) Based on spatial information, actions are planned autonomously without the need for human to issue instructions one by one; (2) Autonomous path planning and obstacle avoidance; (3) Adjust the movement posture, speed, and actions according to the spatial layout; (4) Correct behavior in real time in dynamic space; (5) Coordinated spatial scheduling among multiple hardware components (avoiding collisions and coordinating operations).

[0045] In summary, spatial intelligence refers to the comprehensive intelligent capability of intelligent hardware to autonomously complete spatial positioning, path planning, behavioral decision-making, and environmental adaptation by sensing, modeling, and understanding the physical spatial environment and its dynamic changes. It is the core foundation for realizing truly autonomous, adaptive, and unmanned control of hardware.

[0046] like Figure 1 As shown, the hardware autonomous control system based on spatial intelligence and self-evolutionary learning of this invention adopts a layered architecture design, including a user interaction layer, an intelligent decision-making layer, a skill and memory layer, a device abstraction layer, and a protocol adaptation layer from top to bottom. The layers communicate asynchronously and loosely coupledly through an event bus. The system also includes a multi-layered self-evolutionary engine that runs through the intelligent decision-making layer and the skill and memory layer, used for continuous autonomous optimization of the system's decision-making strategies, prompt word templates, automation rules, and skill packages.

[0047] The user interaction layer offers four interaction methods: natural language dialogue, a visual control panel, a command-line interface, and a REST API. The natural language dialogue interface receives user voice or text commands and routes them to the dialogue state graph of the intelligent decision-making layer for intent understanding and task planning. The visual control panel displays device status, decision logs, and system operating status in a real-time dashboard format, and supports users manually issuing control commands. The REST API provides standardized interfaces for device control, status query, and configuration management for third-party system integration.

[0048] The intelligent decision-making layer is the core hub of the system, comprising a rule engine and a state graph-based intelligent decision-making engine. The rule engine maintains a set of condition-action rules, each containing a sensor name, comparison operator, threshold, control command, and cooldown time. When sensor data changes, the rule engine completes condition evaluation and command generation in milliseconds, providing a deterministic and secure response independent of the availability of large language models. The intelligent decision-making engine is built upon a data flow graph-based planning and execution pipeline, containing two independent but shared execution infrastructure state graphs: a periodic scheduling graph and a user dialogue graph. The periodic scheduling graph is periodically triggered by a timer for environment-aware autonomous decision-making; the user dialogue graph is triggered by natural language interaction, supporting richer task types (including proactively asking users and system-level operations). Both state graphs employ a linear pipeline topology of planning nodes and execution nodes, passing contextual data between nodes through a state dictionary.

[0049] The skills and memory layer comprises a skill loader, a collection of device skill packages, multi-layered memory storage, and a preference learning engine. The skill loader recursively scans the skill catalog upon system startup, discovering and parsing all skill packages, and establishing a dual-index cache by skill name and device type. Each skill package is a core business unit of the system; each skill corresponds to a device type or system function, encapsulating the domain knowledge, decision-making logic, and learning strategies for that device type. The multi-layered memory storage manages the entire persistent state of the system, using a pure file system (human-readable markup language files and structured data files), requiring no database dependency, making it suitable for deployment on resource-constrained home gateway devices.

[0050] The device abstraction layer comprises a device discovery orchestrator, a capability reflection module, an execution verification module, and a command routing distributor. The device discovery orchestrator maintains two core mappings: a device registry and an adapter routing table, uniformly managing device discovery, status updates, and command routing from different protocols. The capability reflection module automatically extracts the device's control capability description from protocol metadata, including a list of supported actions and parameter constraints for each action (numerical range, step size, enumeration options, etc.). The execution verification module implements an execution-verification-retry closed loop to ensure the actual execution effect of control commands. The command routing distributor locates the corresponding adapter instance based on the device identifier and routes standardized control commands to the correct protocol adapter for execution.

[0051] The protocol adaptation layer encapsulates the differences between various communication protocols through a unified adapter abstraction interface. Each adapter implements three core methods: a device discovery method for scanning devices in the network, a state subscription method for listening to device state changes, and a command execution method for translating standardized control commands into native protocol commands. The system supports attaching multiple adapters simultaneously, covering different IoT protocol ecosystems.

[0052] The event bus runs through all levels, providing an asynchronous publish-subscribe communication mechanism that supports precise event type subscriptions and wildcard global listening. Event types include device discovery, device offline, sensor updates, rule triggering, action execution, and user commands. Event handlers are executed sequentially in the order of registration, employing an exception isolation strategy; an exception in one handler does not affect the execution of other handlers.

[0053] For example, the device discovery orchestrator shown in the description and illustration implements the aforementioned multi-source device discovery module, the skill loader corresponds to the skill management module, the multi-layer memory storage corresponds to the multi-layer memory module, and the preference learning engine corresponds to the preference learning module.

[0054] like Figure 2 As shown, the self-evolving intelligent hardware autonomous control method provided by the present invention includes the following steps.

[0055] Step S101: Multi-source Device Discovery and Unified Modeling. The system periodically triggers device scanning via a timer. The device discovery orchestrator traverses all registered protocol adapters, with each adapter executing its protocol-specific scanning process. Taking the Xiaomi IoT adapter as an example, device discovery employs a four-layer priority mechanism: the first layer is manual device configuration, where users specify the device's network address and token via an interface, which has the highest priority; the second layer is a cached cloud device list, providing offline startup capabilities; the third layer is real-time cloud discovery, obtaining a complete list of devices under the user's account via an encrypted API; and the fourth layer is LAN broadcast discovery, extracting device identifiers and tokens from the responses by sending protocol probe packets within the LAN. The four-layer discovery results are merged in priority order, using a dual-dimensional cross-duplicate method of network address and device identifier to ensure that the same physical device is not registered repeatedly.

[0056] For each newly discovered device, the system creates a unified device model instance, including device identifier, device name, adapter source, device type, room of origin, online status, capability list, and sensor list. The device identifier is globally unique and serves as the index key for all subsequent operations. The device type is automatically inferred through a model prefix matching table; for example, a specific model prefix maps to a humidifier type, while another prefix maps to an air conditioner type. The discovery orchestrator registers the new device simultaneously in the device registry and adapter routing table, and emits a device discovery event via the event bus, triggering subsequent skill matching and cold start initialization processes.

[0057] Step S102: Protocol Metadata Reflection and Capability Extraction. The capability reflection module automatically extracts capabilities for each discovered device. For devices of known models, the system extracts command group definitions from the device class metadata in the protocol library and automatically extracts the parameter list, parameter types (numeric, boolean, enumeration), and parameter constraints (minimum, maximum, step size, and list of optional values) supported by each command through a function signature analysis mechanism. Specifically, the system simulates the decorator chain within the protocol library to reconstruct the parameter list and then infers the parameter types through function signature annotations. For devices of unknown models, the system automatically downgrades to general protocol reflection capabilities, providing general read / write and action invocation interfaces based on service identifiers and attribute identifiers.

[0058] The extracted capability descriptions are standardized into a list of capability objects, each containing a capability name and a parameter dictionary. Each entry in the parameter dictionary contains a label, help text, and input constraints. This capability list is written to the capability field of the device model for subsequent use in decision prompt assembly and command security processing.

[0059] Step S103: Skill Pack Building and Loading. At startup, the system recursively scans the skill directory using the skill loader, identifying all subdirectories containing skill tag files. Each skill pack is an independent file directory containing the following components: Skill metadata file: The structured preface defines the skill name, description text, list of applicable equipment types and version number, while the body describes the triggering conditions and working rules in natural language.

[0060] Domain knowledge files: Store professional domain knowledge for this type of device. For example, domain knowledge for humidifier skills includes the suitable indoor humidity range, the impact of air conditioning operation on humidity, and humidity adjustment strategies for different seasons.

[0061] Decision prompt template: Defines parameterized decision prompts, including seven standard placeholders: current sensor data, device capability list, environmental status, user preferences, learning profile, recent decision history, and domain knowledge. The large language model outputs structured decision results based on the filled prompts, including action name, parameters, reason, confidence level, expected result, and suggested waiting time, and mandates support for the "no action" option.

[0062] Learning prompt templates: Define preference learning prompts specific to device type. For example, the learning template for humidifiers focuses on the relationship between seasons and humidity, and the interaction with air conditioning; the learning template for lighting focuses on the relationship between color temperature and circadian rhythm, and brightness and activity scenarios.

[0063] Executable Action Script: Defines the control action functions supported by the skill. Each function receives context parameters and returns a standardized device control instruction object.

[0064] After parsing all skill packs, the skill loader establishes a dual-index cache: an exact lookup cache by skill name and a matching cache by device type. The system distinguishes between system-built-in skills and user-defined skills, storing them in separate directories.

[0065] Step S104: Dual-path decision-making. When sensor data changes, the event bus distributes the sensor update event to the registered processor. The processor first updates the corresponding sensor value in the device state cache, and then triggers the decision cycle of the intelligent decision engine.

[0066] During the decision-making cycle, the rule engine first performs a fast-path evaluation. The rule engine filters the applicable rule list by device type, extracts the required sensor values ​​from the sensor data dictionary, and performs comparison operations through an operator mapping mechanism. If the conditions are met and the cooling time has elapsed since the last trigger, a deterministic control command is immediately generated. The rule engine has default preset safety rules, such as immediately activating the air conditioner when the room temperature exceeds 35 degrees Celsius and immediately activating the humidifier when the humidity is below 20%. The cooling mechanism is based on a monotonic clock and is unaffected by system time adjustments.

[0067] For scenarios not covered by the rule engine, slow-path reasoning is performed by a state-graph-based intelligent decision engine. The planning node performs the following operations: retrieves the user's memory context from multi-layer memory storage; retrieves a list of all online devices and their sensor data from the device discovery orchestrator; constructs an environmental snapshot, aggregating the sensor data of all devices into a structured environmental signal dictionary by device type and room; retrieves a list of available device skill summaries from the skill loader; and assembles all the above information with planning strategy prompts into a complete planning request, which is then submitted to the large language model to generate a task plan.

[0068] The large language model makes conservative decisions with extremely low temperature parameters (approaching zero), outputting a structured list of task plans. Each task plan item includes a task type, target skill name, execution objective, execution reason, and priority. Task types include: environment refresh type for retrieving the latest device status; skill execution type for invoking a specific skill to control the device; system action type for performing system-level operations (such as device discovery, skill creation); user inquiry type for requesting clarification from the user; and response type for generating plain text responses.

[0069] The execution node sorts the task list by priority from lowest to highest and executes each task sequentially. For tasks of the skill execution type, the execution node loads the corresponding skill package and calls its action script to execute the device-level decision-making process.

[0070] Step S105: Skill execution and device-level decision-making. For example... Figure 4 As shown, for each skill execution task, the system first uses the skill loader to find the corresponding skill pack by name, and then loads its executable action script through a dynamic module loading mechanism. The action script internally calls the device-level decision-making method of the intelligent decision engine, and the execution flow of this method is as follows: First, obtain a list of all online devices under this device type. For each target device, assemble a decision context containing the following seven dimensions of information: 1) Current sensor data, extracted from the sensor list of the device model to obtain real-time sensor values; 2) Device capability list, a standardized capability description generated by the capability reflection module; 3) Environmental status, including sensor data from other types of devices, providing a global environmental perspective across devices; 4) User preferences, explicit user preference statements obtained from multi-layer memory storage; 5) Learning profile, a five-dimensional preference profile corresponding to this device type; 6) Recent decision history, extracting several recent execution records of the device from the behavioral history layer of the multi-layer memory system. Each record includes fields such as the name of the executed control action, action parameters, decision reason, number of execution attempts, whether the verification passed, final execution status, expected status, and actual observed status, enabling the large language model to perceive the sequence of instructions recently issued by the device, thereby avoiding the repeated issuance of substantially the same control instructions to the same device and adjusting the current decision based on feedback from recent execution effects; 7) Domain knowledge, professional domain knowledge text built into the skill package.

[0071] The aforementioned seven-dimensional information, combined with the decision prompt template from the skill package, fills in the standard placeholders in the template. Adding the execution goals and reasons provided during the task planning phase, a complete device-level decision request is formed. Based on this request, the large language model returns a structured decision result, including the recommended control action, action parameters, decision reason, decision confidence level, expected result, and suggested waiting time. If the large language model determines that no action is required in the current state, it returns a "no action" decision.

[0072] Step S106: Instruction safety processing. Before actual execution, the control instructions generated by the large language model must pass through a multi-layered parameter safety pipeline.

[0073] The first layer is capability matching: the system searches the device's capability list for capability definitions that match the command action name. The search process supports alias mapping, maintaining a set of commonly used action name equivalence pairs (such as "on" and "start", "set humidity" and "set target humidity") to ensure that semantically equivalent action names can be correctly matched.

[0074] The second layer is parameter safety: For each parameter in the instruction, type conversion and range validation are performed based on the parameter constraints in the matched capability definition. For numeric parameters, the parameter value is trimmed to the minimum and maximum range of the capability definition and automatically aligned to the nearest valid step value (aligned according to rounding). For enumeration parameters, case-insensitive fuzzy matching is performed to standardize the enumeration values ​​output by the large language model to the valid options in the capability definition. For boolean parameters, automatic parsing of various formats (strings "true" / "false", numbers one / zero, etc.) is supported, and they are uniformly converted to standard boolean values. Missing parameters are automatically filled with default values ​​from the capability definition.

[0075] The third layer is the derivation of the expected state: the system automatically derives the expected device state after execution based on the safety-enhanced control commands. For example, the "turn on" action is deduced as the power status being on, and "set humidity to 55%" is deduced as the target humidity value being 55%. The deduced expected state is used in the subsequent execution verification stage.

[0076] Step S107: Execution-Verification-Retry Loop Closure. The secured control commands are routed and distributed by the command router of the device discovery orchestrator. Based on the device identifier, the corresponding adapter instance is located, and the adapter translates the standardized commands into native protocol commands and sends them to the physical device. Upon successful execution, the system emits an action execution event via the event bus.

[0077] After the command is executed, the system immediately enters the verification phase: First, it calls the adapter to refresh the latest status of the target device and obtains a sensor snapshot after execution; then, it compares the expected status derived in step S106 with the actual observed status field by field. The verification result is divided into four states: verification passed, indicating that the expected status is consistent with the actual status; mismatch, indicating that there is a difference in status and retry is required; unverifiable but executed, indicating that the command has been sent but there is no clear expected status for comparison; device lost, indicating that the device is no longer online after the refresh.

[0078] If the verification result is a mismatch and the maximum number of retries has not been reached (preferably, a maximum of three by default), the system re-executes the control command and verifies again. The retry mechanism effectively handles common network latency, device response latency, and transient failures in IoT environments. The final verification result (including the number of attempts, final state, expected value, and actual observation value) is fully recorded.

[0079] Step S108: Multi-layered memory storage and preference learning. For example... Figure 3 and Figure 5As shown, the execution result of each control command (including skill name, execution target, device identifier, device type, control action, parameters, decision reason, verification success or failure, expected state, actual observed state, and timestamp) is appended to the behavior history layer. The behavior history adopts a rolling window strategy, for example, retaining the most recent 1,000 records, balancing historical depth and storage space.

[0080] After each execution record, the system automatically schedules the preference learning service for asynchronous background learning. The preference learning service consists of two phases: The first stage is incremental memory retrieval. The memory retrieval service tracks the processed historical position through a cursor mechanism, reading only newly added unprocessed historical batches at a time (preferably, no more than fifty entries per batch). The retrieval service submits the new historical batches, the existing memory list, and retrieval prompts to the large language model for analysis. The large language model is guided to perform the following operations: identify user preferences, behavioral habits, constraints, and environmental context reflected in the new history; prioritize updating existing memories on the same topic rather than creating duplicate entries; filter out one-off execution noise and temporary sensor fluctuations; and issue forgetting instructions for outdated memories. Each retrieved memory includes a topic identifier, title, category (one of four: preference / habit / constraint / context), summary, detailed description, associated device type, confidence level (low / medium / high), and source action tracing. After processing a batch, the retrieval service advances the cursor, enabling incremental retrieval with breakpoint resumption.

[0081] The second stage involves device-type-specific preference learning. The preference learning engine extracts a list of all relevant device types from the behavioral history and performs learning independently for each device type. Before learning, an evidence threshold is checked; preferably, at least three relevant historical records are required to initiate learning, avoiding overfitting when data is insufficient. For device types that meet the threshold, the system loads the learning prompt word template for the corresponding skill package and submits the filtered device type-related history, current profile, and associated memories extracted in the first stage (cross-memory injection) to the large language model. The large language model synthesizes a five-dimensional preference profile based on the domain-specific learning template: the stable preference dimension records persistent preferences supported by sufficient evidence; the time-period pattern dimension records behavioral patterns associated with different times of day; the seasonal pattern dimension records preference changes associated with seasons or weather; the weak signal dimension records preliminary tendencies that require further evidence for confirmation; and the confidence level dimension records data quality and reliability assessments.

[0082] The updated preference profile is written into the learning profile layer and automatically injected with planning prompts and device-level decision context in the next decision cycle, forming a continuous evolutionary closed loop of "execution → recording → extraction → learning → better decision → execution".

[0083] Step S109: Multi-layered self-evolution engine. (e.g.) Figure 6 As shown, the system builds a multi-layered self-evolving engine on top of the preference learning loop, continuously and autonomously optimizing the system's decision-making strategies, prompt word templates, automation rules, and skill package code. The self-evolving engine uses an execution trajectory library as a unified input source, which aggregates three types of data: behavior history, verification results, and decision logs.

[0084] The self-evolution engine contains four self-evolution modules that run in parallel. The output of each module must be verified by a security gating system before it can be deployed to the runtime.

[0085] Step S109a: Decision Strategy Self-Evolution. The decision strategy self-evolution module performs dual-stream analysis on the decision trajectory of the planning nodes, simultaneously extracting two types of improvement signals from successful and unsuccessful experiences.

[0086] The first stream is the tactical correction stream. The system filters decision records from the execution trajectory library that have failed verification or whose decision confidence is below a preset threshold, constructing a failure case set. For each failure case, the system extracts the complete decision context at the time of failure (including a snapshot of the environment at the time, user memory, skill summary, and planning prompt words) and the specific manifestations of the failure (verification mismatch fields, reasons for retries exhausted, negative user feedback, etc.). The system submits the failure case set along with the current planning strategy prompt words to the large language model, guiding it to analyze the root cause of each failure case and generate targeted tactical correction entries. Each tactical correction entry includes a description of the triggering condition (e.g., "when the air conditioner is heating and the humidity is below 40%)), a description of the correction action (e.g., "the humidifier skill should be called first instead of waiting for the next cycle"), and an explanation of the expected improvement. The tactical correction entries are appended to the prompt entry list of the planning strategy prompt words, enabling planning nodes to avoid repeating the same mistakes when encountering similar scenarios in the future.

[0087] The second stream is the strategic principle stream. The system filters consecutively successful decision sequences with decision confidence levels above a preset threshold from the execution trajectory library, constructing a success pattern set. This success pattern set is then submitted to a large language model, guiding it to summarize abstract decision principles. Unlike tactical adjustments, strategic principles are not specific to any particular scenario but rather extract general decision-making wisdom across scenarios. For example, from multiple successful multi-device coordination decisions, the general principle "before performing operations that may change environmental humidity, the current status of all humidity-related devices should be assessed" can be summarized. These strategic principles are incorporated into the global strategy section of the planning strategy prompts, improving the overall decision-making quality of planning nodes.

[0088] Dual-stream analysis employs asynchronous periodic scheduling, executing once every 24 hours by default. Each execution compares the trajectory cursor position with the previous analysis, processing only newly added trajectory data to achieve incremental evolution. To prevent the policy cue words from expanding indefinitely, the system maintains a maximum limit on the number of tactical correction entries (default 50). When this limit is exceeded, the large language model merges and simplifies existing entries, combining multiple similar tactical corrections into more abstract policy principles.

[0089] Step S109b: Prompt Template Self-Evolution. The prompt template self-evolution module performs statistically driven optimization of the device-level decision prompt template.

[0090] The system maintains a performance rating table for each skill pack's decision prompt word template. The performance rating is calculated based on the template's overall performance in the most recent N decisions. The rating dimensions include: validation pass rate (the proportion of the expected state after execution that matches the actual state), first-time success rate (the proportion of validations that pass without retrying), no-action reasonableness rate (the proportion of the environment that does not deteriorate after the large language model returns a "no-action" decision), and user satisfaction (the proportion of users who do not manually override the action after making the decision).

[0091] When the performance score of a skill set falls below a preset threshold (preferably, 0.7 by default), the system triggers a prompt word optimization process. The optimization process first extracts the most recent decision trajectory samples for that skill set from the execution trajectory library (containing at least five successful and five failed cases). Then, it submits the current prompt word template, trajectory samples, and performance score to the large language model. The large language model is guided to analyze the shortcomings of the current template (such as incomplete domain knowledge coverage, vague descriptions of decision boundary conditions, and insufficiently strict output format constraints), and generates optimized prompt word variants.

[0092] The generated prompt word variants do not directly replace the original template but instead enter a sandbox validation phase. Sandbox validation uses historical decision-making scenarios extracted from the execution trajectory library as test cases. The original template and the new variant are used to simulate decisions in the same scenario, and the decision quality of the two is compared. The decision quality is evaluated by a large language model, which scores the variants based on four dimensions: safety, reasonableness, parameter accuracy, and domain adaptability. Replacement is only approved when the new variant's overall score across all test cases is not lower than that of the original template. The replacement operation employs an atomic write mechanism while retaining a backup version of the original template, supporting rapid rollback if the new template performs poorly.

[0093] Step S109c: Rule self-generation. The rule self-generation module automatically converts frequently repeated slow path decisions into deterministic fast path rules by mining patterns in the execution trajectory.

[0094] The system performs sliding window aggregation analysis on slow path decision records in the execution trajectory database. For each device type, the system counts the frequency of the large language model making the same decision (same action and similar parameters) under similar environmental conditions (sensor values ​​within a preset tolerance range). When the frequency of a certain decision pattern exceeds a preset threshold (default ten times) and the validation pass rate of that pattern exceeds a preset threshold (default 90%), the system marks that pattern as a rule candidate.

[0095] For each rule candidate, the system extracts its triggering conditions (sensor name, comparison operator, and threshold) and execution action (device control command), and automatically generates a rule definition. The generated rule definition includes the rule name (automatically concatenated from the device type and triggering conditions), the condition object, the action object, the applicable device type, and the cooldown time (derived from the average interval of historical decisions).

[0096] The generated rules must pass security verification before being injected into the rule engine. Security verification includes: checking whether the rule's triggering conditions conflict with existing rules (i.e., threshold values ​​in the same direction from the same sensor should not produce contradictory actions); checking whether the rule's control commands are within the device's capabilities; and checking whether the rule's cooling time is reasonable (not less than the device's minimum response interval). Rules that pass verification are marked as "self-generated rules" and injected into the rule engine, participating in fast path evaluation along with manually preset rules. Self-generated rules have lower priority than manually preset rules; in case of conflict, the manually preset rules prevail.

[0097] The system also maintains performance tracking for self-generated rules. If a self-generated rule is triggered zero times or has a pass rate lower than a preset threshold during the observation period after injection (seven days by default), the system automatically marks it as invalid and removes it from the rule engine to prevent outdated rules from interfering with normal decision-making.

[0098] Step S109d: Skill Self-Repair. The skill self-repair module generates and verifies repair patches by automatically attributing failures to skill execution, thereby enabling the autonomous maintenance and iteration of skill packages.

[0099] When the number of consecutive failures of a skill pack exceeds a preset threshold (default is three consecutive failures) or the cumulative failure rate exceeds a preset threshold (default is a failure rate of more than 30% in the last twenty executions), the system triggers the skill self-repair process.

[0100] The first stage of the self-healing process is failure attribution analysis. The system extracts all failure records for the skill package from the execution trajectory database and categorizes them by failure type: capability matching failure (the action name output by the large language model cannot match the device capability), parameter out of bounds (the safety pipeline prunes parameter values, indicating that the large language model misunderstands the device parameter range), verification mismatch (the device state after execution does not match expectations), and script execution exception (an exception is thrown during the execution of the action script). The system submits the categorized failure records, the current file content of the skill package (metadata, domain knowledge, decision templates, learning templates, and action scripts), and the latest capability description of the device to the large language model for attribution analysis. The large language model outputs a structured attribution report, including the failure root cause classification, a list of affected files, and suggested repair directions.

[0101] The second phase of the self-healing process is patch generation. Based on the attribution report, the system generates repair patches for each affected file. For repairing domain knowledge files, the large language model supplements or corrects domain knowledge entries based on knowledge deficiencies exposed in the failure cases. For repairing decision prompt word templates, the large language model adjusts the constraint descriptions, output format requirements, or decision boundary conditions in the templates. For repairing action scripts, the large language model generates code patches to fix runtime exceptions or adjust parameter mapping logic. Each patch includes the original content before modification, the new content after modification, and an explanation of the reason for the modification.

[0102] The third stage of the self-healing process is patch verification. Each generated patch undergoes independent verification: the metadata file verifies the format correctness of the preface and the completeness of necessary fields; the prompt word template verifies the existence and format consistency of standard placeholders; the action script verifies syntactic correctness through abstract syntax tree parsing and verifies runtime security through sandbox execution (disallowing dangerous operations such as file system writes and network access). Patches that pass verification are applied to the skill pack file, while a complete backup of the patch before repair is retained. If patch verification fails, the system sends the verification error information back to the large language model for secondary repair; each file can be retried a maximum of three times.

[0103] After the repair is completed, the system triggers the skill loader's rediscovery process, reloading the repaired skill pack into the index cache. In subsequent execution cycles, the system continuously monitors the performance of the repaired skill pack. If the failure rate does not significantly improve after the repair, the system rolls back to the pre-repair backup version and generates an alert notification, prompting the developer to intervene manually.

[0104] Step S109e: Self-evolving security gating. All outputs of self-evolving modules must pass a unified security gating verification before being deployed to runtime. The security gating includes the following check layers: The first layer is a format integrity check: verifying that the generated strategy prompts, prompt templates, rule definitions, and skill pack files conform to their respective format specifications and are free from grammatical errors or structural defects.

[0105] The second layer is semantic consistency checking: verifying that the evolved content does not conflict with the system's core security constraints. For example, self-generated rules should not override or weaken manually preset security rules; optimized prompt word templates should not remove mandatory support for the "no operation" option; and repaired action scripts should not bypass the command security pipeline.

[0106] The third layer is regression validation: historical scenarios extracted from the execution trajectory library are used as the regression test set to verify that the evolved system performs no worse than the unevolved system in known scenarios. Regression validation employs a large language model review mechanism to compare and score the decision results before and after evolution.

[0107] The fourth layer is a gradual deployment: the evolved content will not take full effect immediately, but will first run in "shadow mode" for an observation window (default 48 hours). That is, the evolved content and the original content will execute decisions in parallel, but only the decisions of the original content will be actually executed, while the decisions of the evolved content will only be recorded for comparative analysis. After the observation window ends, if the simulated decision quality of the evolved content is not lower than that of the original content, it will officially switch to the main decision path.

[0108] Cold start preference initialization: When a new user starts the system for the first time or a new device type is connected for the first time, the user's behavioral history is empty, and there is no data to base preference learning. To solve the cold start problem, the system automatically generates initial preferences and learning profiles based on the combination of currently connected device types.

[0109] The system incorporates a knowledge mapping between device types and comfort parameters: if an air conditioner is connected, it automatically generates a temperature range preference (e.g., 22 to 24 degrees Celsius) and a cooling / heating mode preference; if a humidifier is connected, it generates a humidity range preference (e.g., 45% to 55%); if a lighting device is connected, it generates a diurnal rhythm preference for high color temperature during the day and low color temperature at night. The system generates an initial five-dimensional preference profile for each connected device type, explicitly marking it as a cold start value with low confidence.

[0110] The cold start mechanism follows the idempotent design principle: if a user has manually edited their preferences, the system will not overwrite the user's custom settings. The cold start profile exists as the fifth layer of memory, and its design intent is to be gradually overwritten and replaced by profiles learned from real-world behavior.

[0111] Skill packs are automatically generated: When a device discovers a new device type in the orchestrator and a corresponding skill pack does not exist in the system, the system automatically triggers the skill pack generation process. This process uses a three-stage pipeline architecture: The first phase is requirements analysis: The system submits the type information of the new equipment and the capability description (including the list of supported actions and parameter constraints) extracted by the capability reflection module to the large language model, analyzes and generates skill specifications, including suggested skill names, descriptions, sets of supported control actions, key domain knowledge points and safety constraint rules.

[0112] The second stage involves file-by-file generation: based on the skill specifications, the large language model sequentially generates five component files for the skill package—a skill metadata file, a domain knowledge file, a decision prompt word template, a learning prompt word template, and an executable action script. The generation of each file follows the format constraints of that file type (e.g., the metadata file is required to include a structured preface, and the decision prompt template is required to include seven standard placeholders).

[0113] The third stage involves multi-layered verification and self-repair: Structured verification is performed independently on each generated file. The metadata file verifies the format correctness of the preface and the completeness of necessary fields; the prompt word template verifies the existence of standard placeholders; the action script verifies syntax correctness through abstract syntax tree parsing and checks whether standardized device control command types are correctly referenced. If verification finds problems, the system feeds back the error information to the large language model for self-repair, retrying a maximum of three times per file.

[0114] Once the skill pack file passes verification, it is written to the custom skill directory, triggering the skill loader's rediscovery process to load the new skill pack into the index cache. The new skill pack is immediately available and can be selected by the planning node in the next scheduling cycle or user interaction. Automatically generated skill packs are also included in the self-evolution engine's monitoring scope, and their subsequent performance will be continuously tracked, triggering a skill self-repair process for iterative optimization when necessary.

[0115] Skill pack generation supports two methods: automatic generation based on device capabilities and generation based on user natural language requests. An example of generation based on user natural language requests is as follows: Users can say "Help me create a skill to turn off the air purifier when I leave home" in the dialogue, and the system will automatically analyze the needs and generate a complete custom skill package.

[0116] Multi-device coordinated decision-making: When multiple types of smart devices are present in a home environment, independent control of a single device may lead to physical state conflicts. For example, when an air conditioner is cooling, it reduces indoor humidity. If a humidifier is unaware of the air conditioner's operating status, it may set an inappropriate target humidity value. Similarly, if an air purifier is running while windows are open for ventilation, the effects of the two will cancel each other out.

[0117] To address the multi-device coordination challenge, the system employs a coordinator skill as a unique global orchestration skill. This skill is not tied to a specific device type; instead, it aggregates complete status snapshots of all active devices, environmental sensor data, and user preferences. This data is then fed into a large language model for joint multi-device analysis via a dedicated orchestration prompt template. The large language model is guided to detect potential conflicts between devices (such as heating versus cooling, or purification versus ventilation), identify synergistic effects (such as increasing the humidifier's target value after air conditioning dehumidification), prioritize devices based on safety over comfort, and comfort over energy efficiency, ultimately outputting a consistent list of multi-device control commands.

[0118] When constructing environmental snapshots at planning nodes, the intelligent decision engine cross-aggregates sensor data from all devices by type and room to form a global environmental signal dictionary. This dictionary serves as the environmental context input for each device-level decision, enabling even single-device decisions to be aware of the operational status of other devices, thereby mitigating conflicts to some extent.

[0119] Example 1: Autonomous Humidity Regulation Based on Environmental Perception In one embodiment, a user's home has a networked humidifier and a networked air conditioner. After the system starts, it performs device discovery, detecting the humidifier (model prefix matching the humidifier type) and the air conditioner (model prefix matching the air conditioner type) via local area network broadcast. The capability reflection module automatically extracts the humidifier's supported capability list: on / off, setting target humidity (range 30% to 80%, step 1%), setting operating mode (auto / constant humidity / silent / high power); and the air conditioner's capability list: on / off, setting temperature, setting mode, etc.

[0120] The system automatically matches the built-in humidifier and air conditioning skills for the two devices. Since the user is a new user, the cold start mechanism automatically generates initial preferences: temperature range of 22 to 24 degrees Celsius, humidity range of 45% to 55%, and high color temperature during the day and warm color temperature at night.

[0121] On a winter night, the air conditioner's continuous heating caused the indoor humidity to slowly drop from 48% to 38%. The humidifier's sensor reported a humidity update event, which was distributed to the decision-making chain via the event bus. After evaluation, the rule engine determined that 38% was not below the 20% emergency threshold and therefore did not trigger the fast path. The intelligent decision engine's planning node assembled the context: current humidity 38%, user preferred humidity range 45% to 55%, air conditioner currently heating, and the humidifier's learning profile recording a time pattern of "preferring to set the target humidity 5 percentage points higher during winter heating periods."

[0122] The large language model plans and outputs the skill execution task: invoking the humidifier skill with the goal of "increasing humidity to a comfortable range." The execution node loads the humidifier skill package. Based on current sensor data, the capability list, environmental status (air conditioning in heating mode), user preferences, and the winter mode in the learning profile, the large language model decides to set the target humidity to 60% (based on the learning profile's "increase by 5 percentage points during heating" mode, increasing from the upper limit of 55%), and sets the operating mode to constant humidity mode. The instruction safety module verifies that the target humidity of 60% is within the capability range of 30% to 80%, and that constant humidity mode exists in the selectable mode list, confirming the parameters are valid. Post-execution verification: refreshing the sensors reveals that the device has accepted the target humidity setting of 60%, verification successful. The execution record is written to the behavior history, and preference learning further reinforces the "winter heating-linked humidification" mode in subsequent cycles.

[0123] Example 2: Multi-device linkage control based on natural language In another embodiment, the user sends the command "It's a bit hot, please turn on the air conditioner and the humidifier as well" via a natural language dialogue interface. The system routes the user message to the dialogue state graph of the intelligent decision engine.

[0124] The dialogue planning node assembles user messages, all device states, user memories, and a summary of available skills into a dialogue planning request. After parsing the user intent, the large language model generates a task plan list containing two skill execution tasks: the first task is to invoke the air conditioner skill with the goal of "turning on cooling" and a priority of 1 (execution first); the second task is to invoke the humidifier skill with the goal of "turning on humidification" and a priority of 2.

[0125] The dialogue execution nodes are executed sequentially according to priority. First, the air conditioning skill is executed: based on the current room temperature of 28 degrees Celsius, the user's preference for 22-24 degrees Celsius, and the learning profile's "afternoon preference for 24 degrees Celsius" time period pattern, the large language model decides to set the temperature to 24 degrees Celsius and the mode to cooling. The command is secured, executed, and verified successfully. Next, the humidifier skill is executed: considering that the air conditioner is about to start cooling (the air conditioner status in the environmental context has been updated to cooling operation), the large language model, based on the domain knowledge that "cooling mode will reduce indoor humidity," proactively sets the target humidity to the preferred upper limit of 55%. After both control commands are executed and verified successfully, the system generates a natural language response: "Okay, the air conditioner has been set to 24-degree cooling mode, and the humidifier has been turned on and set to a target humidity of 55%." Example 3: Zero-configuration intelligent access for new devices In another embodiment, a user purchases a new smart air purifier and connects it to their home network. The system detects the new device during the next scheduled device scan and identifies its model prefix as corresponding to the air purifier type. The device discovery event triggers a skill matching check, which finds that no skill pack for the air purifier type exists in the system.

[0126] The system automatically triggers the skill package generation process. The capability reflection module extracts the air purifier's capability list: turn on / off, set fan speed (levels 1-3), and set operating mode (auto / sleep / manual / favorite). The first stage of the skill generation pipeline submits the device type and capability list to the large language model for requirements analysis, generating skill specifications: the skill name is "Air Purifier," domain knowledge points include air quality indicators, filter maintenance reminders, interaction with ventilation status, etc., and safety constraints include not running at maximum airflow continuously when unattended. The second stage generates five skill package files sequentially. The third stage performs verification on each file: the metadata file verifies that the device type list includes "Air Purifier," the decision template verifies that all seven placeholders are present, and the action script verifies that the syntax is correct and references standard control command types.

[0127] After all verifications are successful, the new skill package is written to the system skill directory, and the skill loader performs rediscovery and updates the index cache. Simultaneously, the cold start mechanism generates an initial preference profile for the air purifier: default automatic mode, and automatic switching to sleep mode during sleep periods. Starting from the next scheduling cycle, the air purifier skill appears in the available skill list of the planning node, and the system can then autonomously control the air purifier's operation based on air quality sensor data and user preferences.

[0128] Example 4: Self-evolution of decision-making strategies In another embodiment, the system has been running for thirty days, accumulating approximately five hundred execution trajectory records. The decision-making strategy self-evolution module initiates dual-stream analysis during periodic scheduling.

[0129] Tactical correction flow analysis identified the following failure modes: In the last fifteen days, there were seven cases where the humidifier's target humidity was set too high (above 65%) within thirty minutes after the air conditioner switched from heating to off, resulting in excessive indoor humidity that then needed to be reduced. The system extracted the complete context of these seven failure cases and found that the common feature was "the air conditioner has just been turned off, the indoor temperature starts to naturally drop, and the humidity naturally rises due to the cessation of heating." After analysis by the large language model, a tactical correction entry was generated: "When the air conditioner has been switched from the heating mode to the off state for less than thirty minutes, the humidifier's target humidity should be conservatively set to the median of the preferred range rather than the upper limit, and wait for the humidity to naturally rise before evaluating whether further adjustment is needed." This entry was appended to the planning strategy prompt.

[0130] Strategic principle flow analysis identified the following successful modes: In all successful decisions involving multi-device linkage, the planning node executed an environment refresh task to obtain the latest sensor data before generating the task plan. The large language model generalized a strategic principle from this: "Before generating control tasks involving two or more devices, an environment refresh task should be inserted first to ensure that decisions are based on the latest device status." This principle was written into the global strategy section of the planning strategy prompt.

[0131] In subsequent operations, when the humidity scenario reappeared after the air conditioner was turned off, based on the newly added tactical correction entry, the planning node conservatively set the humidifier's target humidity to 50% (the median of the preferred range of 45% to 55%), avoiding the problem of excessive humidification. At the same time, all multi-device linkage decisions automatically inserted an environment refresh task at the beginning of the task plan, significantly improving the accuracy of the decisions.

[0132] Example 5: Prompt Template Self-Evolution and Rule Self-Generation In another example, after the system had been running for sixty days, the prompt template self-evolution module detected that the effectiveness score of the lighting skill pack had dropped from an initial 0.85 to 0.62. Analysis found that the main reason for the drop was that the user had frequently manually adjusted the lighting color temperature from the system-set 2700K to 3500K in the evenings in the last two weeks, indicating a deviation between the system's decisions and the user's actual preferences.

[0133] The prompt optimization process extracted the decision trajectories of the lighting skill pack in the last thirty times and found that the circadian rhythm rule in the current decision template fixed the color temperature recommendation after 21:00 to 2200K to 2700K, but the user's actual behavior showed that their preference was to use an intermediate color temperature of 3000K to 3500K between 21:00 and 23:00. The large language model generated an optimized prompt variant that adjusted the evening color temperature recommendation range to "Refer to the period pattern in the learning portrait. If there is no clear portrait, default to 2700K to 3500K", increasing the priority reference to the learning portrait.

[0134] Sandbox validation used comparative testing of fifteen recent nighttime decision-making scenarios. The original template showed a 40% consistency rate between its decisions and actual user actions in these scenarios, while the optimized variant improved this to 80%. Security gating validation confirmed that the new variant retained support for the "no action" option, all seven standard placeholders were complete, and the decision-making quality did not degrade in daytime scenarios. After passing validation, the new variant entered a 48-hour shadow mode observation period before officially replacing the original template.

[0135] Meanwhile, the rule self-generation module discovered the following high-frequency pattern: In the past sixty days, whenever the indoor humidity was below 40% and the air conditioner was in heating mode, the large language model selected to turn on the humidifier and set the target humidity to 55% to 60% in all twelve decisions, and all twelve executions passed the verification. This pattern meets the frequency threshold (twelve times is greater than ten times) and the verification pass rate threshold (100% is greater than 90%), and is marked as a rule candidate.

[0136] The system automatically generates a rule definition: the rule name is "Heating-Linked Humidification," the trigger condition is that the humidity sensor value is less than 40% and the air conditioner is in heating mode, the action is to turn on the humidifier and set the target humidity to 57% (the median of the parameters from twelve decisions), and the cooling time is 300 seconds. Safety verification confirms that this rule does not conflict with existing rules, the target humidity is within the device's capabilities, and the cooling time is reasonable. After the rule is injected into the rule engine, the response time for subsequent similar scenarios is reduced from several seconds in the slow path of the large language model to milliseconds in the fast path of the rule.

[0137] Example 6: Skill Self-Repair In another embodiment, the air purifier skill package automatically generated by the system failed repeatedly after two weeks of operation. The skill self-repair module detected that the skill package had failed eight out of the last twenty executions (a failure rate of 40%, exceeding the 30% threshold), triggering the self-repair process.

[0138] During the failure attribution analysis phase, the system extracted and categorized eight failure records: five were capability matching failures, where the action name "set_fan_speed" output by the large language model could not match "set_fan_level" in the device capability list; three were parameter out-of-bounds errors, where the large language model output a fan speed value of 4, but the device only supports speeds 1 to 3. The attribution report indicated that the capability description format in the decision prompt word template was inconsistent with the actual capability name of the device, and the domain knowledge file lacked a clear description of the fan speed range.

[0139] During the patch generation phase, the large language model generates fix patches for the two affected files: for the domain knowledge file, it adds a clear explanation that "the fan speed range of this device is 1 to 3, where 1 is silent, 2 is standard, and 3 is powerful"; for the decision prompt word template, it adds the constraint that "the action name must strictly use the original name in the device capability list and must not use synonyms" in the usage instructions of the capability description placeholder.

[0140] During the patch verification phase, the domain knowledge file was verified to be in the correct format, and the decision template was verified to have all seven standard placeholders intact, with the added constraints not affecting the output format. After the patch was applied, the skill loader reloaded the air purifier skill pack. In the subsequent twenty executions, the number of capability matching failures decreased to zero, the number of parameter out-of-bounds errors decreased to zero, and the skill pack performance returned to normal.

[0141] Compared with the prior art, the present invention has the following beneficial technical effects: (1) By encapsulating the domain knowledge, decision templates, and learning templates specific to each device type into independent, hot-loadable units through the skill package system, the large language model makes decisions based on domain knowledge constraints, which significantly improves the accuracy of control commands and domain adaptability. When adding a new device type, only the skill package file needs to be added, without modifying the core code, and the system has high scalability.

[0142] (2) Through a two-layer decision-making architecture of fast rule path and slow big language model, safety-critical scenarios are responded to by the rule engine in milliseconds, without relying on the availability of big language model; complex scenarios are intelligently planned by big language model based on complete context. The two layers of decision-making share a unified device instruction model and execution path, which takes into account both safety determinism and intelligent flexibility.

[0143] (3) Through a five-layer memory architecture and a preference learning mechanism based on device type, the system can continuously extract preferences from users' long-term usage behavior and automatically update the learning profile. The cold start mechanism automatically generates an initial preference profile based on the type of connected devices. When a new device is connected, a reasonable control strategy can be provided. The system is continuously optimized as it is used, thus achieving continuous evolution of system behavior.

[0144] (4) The device capability description is automatically extracted through protocol metadata reflection, and a multi-layer parameter safety pipeline (including capability matching, range pruning, step alignment, and type conversion) is inserted between the output of the large language model and the device execution to effectively prevent damage to the physical device caused by abnormal instructions such as out-of-bounds parameters and unsupported actions generated by the large language model. The execution-verification-retry closed loop further ensures the actual execution effect of the control instructions.

[0145] (5) Through the automatic skill package generation mechanism driven by the large language model, the system can automatically analyze the capabilities of newly discovered device types and generate complete skill packages (including domain knowledge, decision templates, learning templates, and execution scripts), realizing zero-configuration intelligent access for new devices. The generation process includes multi-layer verification and self-repair mechanisms to ensure the availability and security of the generated skill packages.

[0146] (6) Through a multi-layered self-evolutionary engine, the system can autonomously extract decision-making experience from long-term execution trajectories, achieving dual-stream self-optimization of decision strategy prompts (parallel evolution of tactical correction and strategic principles), statistical-driven optimization of device-level prompt templates, automatic sedimentation of high-frequency slow-path decisions into deterministic fast-path rules, and automatic attribution and repair of skill package execution failures. This self-evolutionary mechanism enables the system's intelligence level to no longer be limited by the initial design, but to continuously and autonomously improve with the increase of running time, forming an open evolutionary closed loop of "execution → evaluation → evolution → better execution".

[0147] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

[0148] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A hardware autonomous control method based on spatial intelligence and self-evolutionary learning, characterized in that, include: S1: Automatically scan and connect to smart hardware devices through a multi-source device discovery mechanism, establish a unified device model, and automatically extract the control capabilities and parameter constraints supported by each device through a protocol metadata reflection mechanism to generate a standardized capability description. S2: Construct a skill package system, with each skill package corresponding to a device type. Each skill package contains a domain knowledge base, decision prompt word templates, learning prompt word templates, and executable action scripts. A mapping index from device type to skill package is established through a skill loader. S3: When a change in sensor data is detected, a dual-path decision architecture of fast rule path and slow language model is used for control decision. The rule engine generates deterministic control instructions in millisecond-level response for events that meet the safety threshold conditions. For scenarios not covered by the rule engine, the intelligent decision engine based on state graph performs context-aware control decision through planning nodes and execution nodes. S4: The planning node assembles the device's real-time status, user memory context, environmental snapshot, and available skill summary into structured prompt words. The large language model generates a priority task plan list. The execution node executes tasks in order of priority. For skill execution tasks, the corresponding skill package is loaded. The large language model makes device-level decisions based on domain knowledge. S5: Perform capability matching and parameter safety processing on the control instructions generated by the large language model, including action name alias mapping, numerical parameter range pruning and step alignment, enumeration parameter fuzzy matching, and Boolean parameter type conversion; S6: After executing the control command, the execution effect is confirmed through the execution-verification-retry closed loop, that is, the device status is refreshed and the expected status is compared with the actual observed status. If there is a mismatch, the execution is re-executed within the maximum number of retries. S7: Write the execution result into the multi-layer memory system and trigger preference learning. The preference learning includes an incremental memory extraction stage and a special profile synthesis stage based on device type. The updated profile will automatically take effect in the next decision. S8: The system's decision-making strategy, prompt word templates, and automation rules are continuously and autonomously optimized based on a multi-layered self-evolutionary engine, which includes: The decision-making strategy self-evolution module extracts tactical corrections and strategic principles from successful and failed experiences through dual-stream analysis of the execution trajectory, and automatically updates the planning strategy prompts. The prompt word template self-evolution module identifies inefficient prompt word patterns through statistical analysis of device-level decision results and generates optimized prompt word variants, which replace the original templates after sandbox verification. The rule self-generation module automatically generates deterministic rules by identifying high-frequency repetitive decision patterns and injects them into the rule engine; as well as The skill self-repair module automatically locates the root cause of skill execution failure and generates a repair patch through attribution analysis.

2. The method according to claim 1, characterized in that, In step S1, the unified device model includes device identifier, device type, capability list, and sensor list.

3. The method according to claim 1, characterized in that, In step S1, the multi-source device discovery mechanism adopts a four-layer priority merging strategy: manually configured devices are the first priority, the cached cloud device list is the second priority, real-time cloud discovery is the third priority, and local area network broadcast discovery is the fourth priority; the four-layer discovery results are merged in priority order, and network address and device identifier are used for dual-dimensional cross-duplicate removal.

4. The method according to claim 1, characterized in that, In step S1, the protocol metadata reflection mechanism extracts command group definitions from the device class metadata of the protocol library for devices of known models, and extracts parameter lists, parameter types and parameter constraints through function signature analysis; for devices of unknown models, it automatically downgrades to a general reflection capability based on service identifiers and attribute identifiers.

5. The method according to claim 1, characterized in that, In step S3, the intelligent decision engine includes two independent state graphs: a periodic scheduling graph triggered by a timer, supporting three task types: environment refresh, skill execution, and response; and a user dialogue graph triggered by natural language interaction, additionally supporting two task types: user inquiry and system action. The two state diagrams share the skill execution engine, memory system, and environment-aware infrastructure.

6. The method according to claim 1, characterized in that, In step S7, the multi-layer memory system comprises five layers: the first layer is a human-readable and editable explicit user preference declaration; the second layer is a behavior history record in a scrolling window; the third layer is a persistent memory extracted from history by a large language model, stored by topic, including four categories: preferences, habits, constraints, and context; the fourth layer is a five-dimensional preference profile independently synthesized according to device type, with the five dimensions being stable preferences, time-period patterns, seasonal patterns, weak signals, and confidence level descriptions; and the fifth layer is a cold start default value automatically generated based on the type of connected device.

7. The method according to claim 1, characterized in that, In step S7, the incremental memory extraction stage tracks the processed historical positions through a cursor mechanism, and only processes newly added historical batches each time. During extraction, the large language model is guided to prioritize updating existing memories with the same topic, filter out one-time execution noise, and issue forgetting instructions to outdated memories to maintain the freshness of the memory bank.

8. The method according to claim 1, characterized in that, In step S7, during the device type-specific profile synthesis stage, a unique learning prompt word template from the skill pack is loaded for each device type. The relevant history, current profile, and associated memories extracted in the first stage of the device type are used as inputs to synthesize a five-dimensional preference profile by the large language model. Before learning, an evidence threshold is checked, requiring at least a preset number of relevant historical records before learning can begin.

9. The method according to claim 1, characterized in that, In step S8, the decision strategy self-evolution module adopts a dual-stream analysis mechanism: the first stream is the tactical correction stream, which extracts the root causes of failure from the decision records of verification failure or low confidence and generates targeted tactical correction items, which are then added to the planning strategy prompt words; the second stream is the strategic principle stream, which summarizes the general decision principles across scenarios from the continuous successful and high-confidence decision sequences and writes them into the global strategy part of the planning strategy prompt words. When the number of tactical modification entries exceeds the preset limit, the large language model merges and simplifies the existing entries.

10. The method according to claim 1, characterized in that, In step S8, the prompt word template self-evolution module maintains a performance score table for the decision prompt word template of each skill pack. The performance score is calculated based on the verification pass rate, first success rate, no-operation reasonableness rate, and user satisfaction. When the performance score is lower than a preset threshold, an optimization process is triggered, and the large language model generates an optimized prompt word variant. The prompt word variant is compared and verified in a sandbox environment using historical decision scenarios. Replacement is only approved when the comprehensive score of the new variant is not lower than that of the original template.

11. The method according to claim 1, characterized in that, In step S8, the rule self-generation module performs sliding window aggregation analysis on slow path decision records. When the frequency of occurrence of a certain decision pattern exceeds a preset frequency threshold and the verification pass rate exceeds a preset pass rate threshold, a deterministic rule containing triggering conditions and execution actions is automatically generated. After security verification, the generated rule is injected into the rule engine, and its priority is lower than that of manually preset rules. The system tracks the performance of the self-generated rules, and rules that perform poorly during the observation period are automatically removed.

12. The method according to claim 1, characterized in that, In step S8, the skill self-repair module is triggered when the number of consecutive failures or the cumulative failure rate of the skill package exceeds a preset threshold, and performs three stages: failure attribution analysis, patch generation, and patch verification. Failure attribution is classified into four categories: capability matching failure, parameter out-of-bounds, verification mismatch, and script execution anomaly. Patch verification includes format checking, abstract syntax tree parsing, and sandbox execution security verification. After repair, the performance of the skill package is continuously monitored, and if there is no significant improvement, it is rolled back to the version before the repair.

13. The method according to claim 1, characterized in that, In step S8, all outputs of the multi-layer self-evolution engine must pass security gating verification before being deployed to runtime. The security gating includes format integrity checks, semantic consistency checks, regression verification based on historical scenarios, and a progressive deployment mechanism. The progressive deployment mechanism runs the evolved content and the original content in parallel in shadow mode during the observation window, and only officially switches when the simulation decision quality of the evolved content is no lower than that of the original content.

14. The method according to claim 1, characterized in that, When a device discovers a new device type and there is no corresponding skill pack in the system, the skill pack generation process is automatically triggered: the large language model generates a complete skill pack file based on the device capability description, including metadata file, domain knowledge file, decision prompt word template, learning prompt word template and executable action script; Each generated file undergoes independent structured validation. If validation fails, the error message is fed back to the large language model for self-repair. Once validation passes, the file is written to the skill directory and the skill loader is triggered to rediscover the skill. The automatically generated skill packs are included in the monitoring scope of the self-evolution engine.

15. The method according to claim 1, characterized in that, It also includes a multi-device coordination decision-making step: designing and using coordinator skills to gather status snapshots of all active devices, environmental sensor data and user preferences, performing multi-device joint analysis by a large language model, detecting potential conflicts and synergies between devices, and outputting a coordinated list of multi-device control instructions based on the priority of safety over comfort and comfort over energy saving.

16. The method according to claim 1, characterized in that, Each rule in the rule engine includes a sensor name, comparison operator, threshold, control command, and cooling time. The cooling mechanism is based on a monotonic clock, and the same rule is not triggered repeatedly during the cooling period. The evaluation of the rule engine is independent of the availability of the large language model, ensuring deterministic response in safety-critical scenarios.

17. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 16.

18. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 16.

19. A hardware autonomous control system based on spatial intelligence and self-evolutionary learning, characterized in that, include: The multi-source device discovery module is used to automatically scan smart hardware devices through multiple communication protocols and establish a unified device model. The capability reflection module is used to automatically extract device control capabilities and parameter constraints from protocol metadata; The skills management module is used to store and load skills packs and establish a mapping index from device types to skills packs; The rules engine module is used to perform millisecond-level deterministic evaluation of sensor data and generate control commands; The intelligent decision engine module is used to orchestrate planning nodes and execution nodes based on state diagrams and to make context-aware control decisions through a large language model. The instruction security module is used to perform capability matching and parameter verification on the control instructions output by the large language model. The execution verification module is used to execute control commands and verify the execution effect through status comparison; A multi-layered memory module is used to store user preferences, behavioral history, extracted memories, and learning profiles; The preference learning module is used to extract persistent memories from incremental behavioral history and synthesize preference profiles by device type; The multi-layered self-evolution engine module is used to autonomously optimize decision-making strategy prompts, device-level decision prompt templates, automation rules, and skill package code based on execution trajectory analysis.

20. The system according to claim 19, characterized in that, The multi-source device discovery module maintains two core mappings: a device registry and an adapter routing table. The device registry stores a unified device model with the device identifier as the key. The adapter routing table stores the protocol adapter instance corresponding to the device with the device identifier as the key. Control commands are executed after finding the corresponding adapter in the adapter routing table.

21. The system according to claim 19, characterized in that, The system also includes an event bus module for asynchronous event distribution among various functional modules. The event bus supports precise event type subscription and wildcard global listening. Event handlers are executed sequentially according to their registration order, and an exception isolation strategy is adopted so that an exception in a single handler does not affect the execution of other handlers.

Images