A multi-agent-based internet of things service logic automatic generation system and method

Abstract

The application discloses a kind of multi-agent-based Internet of Things service logic automatic generation system and method.The application constructs three agents: function implementation agent, which decomposes and implements user function intent into function demand branch;Quality implementation agent is constructed, and quality intent is instantiated based on environment evaluation to generate quality demand branch;Service logic synthesis agent is constructed, which synthesizes and detects conflicts for the two branches, and extracts and switches the conflict-free service logic scheme in real time.Through the three-layer demand model of "user intent-implementation planning-service logic", the three agents collaborate.If the service logic synthesis agent finds a conflict, the conflict information is explicitly passed to the function implementation agent for collaborative refinement until there is no conflict.The application realizes white-box and high explainability of the generation process through the three-layer model, and the multi-agent collaboration resolves hardware resource preemption conflicts at the source, significantly improving the quality of service scheduling logic.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) applications and multi-agent technology, and more specifically, to an automatic generation system and method for IoT service logic based on multi-agent technology. Background Technology

[0002] With the deepening of digital transformation and the accelerated evolution of the Internet of Things (IoT) trend, IoT technology is increasingly being applied in fields such as smart homes, smart communities, and the industrial internet. Smart devices are evolving from simply responding passively to proactively serving, which requires IoT systems to transform from mechanically executing instructions to being able to deeply understand and realize user intentions.

[0003] Current IoT service configurations largely rely on users manually writing static rules. However, faced with increasingly complex smart scenarios, ordinary users often only have high-level, vague intentions in mind, making it difficult to bridge the "cognitive gap" and unravel the underlying complex logic, resulting in a lack of operational capability. Furthermore, this manual configuration is prone to overlooking crucial aspects: while focusing on setting explicit "functional experiences" such as lighting and audio-visual settings, users often neglect implicit "quality concerns" such as security and privacy, thus creating security risks in the physical space. In addition, static rules are quite fragile; once environmental changes such as device disconnection occur, the entire service chain can easily be paralyzed.

[0004] To address these issues, several technologies for automatically generating IoT service logic have emerged in the industry. However, existing automatic generation systems and methods have revealed serious bottlenecks when dealing with modern, complex IoT scenarios:

[0005] First, most existing generation mechanisms are characterized by an "end-to-end" black box approach, lacking a clear deductive path from "high-level intent" to "low-level code." When faced with complex system requirements, due to the absence of hierarchical intermediate representations, the system often generates control rules in one step, making the reasoning process difficult to trace and the results difficult to interpret. Once the generated service logic performs poorly or contains vulnerabilities in the environment, it is extremely difficult for the system to perform accurate backtracking and correction.

[0006] Secondly, and more challengingly, in complex IoT environments, users' explicit functional intentions and implicit quality concerns often map to the same underlying physical devices, easily leading to hardware resource contention and physical execution conflicts. For example, air purification requires opening windows for ventilation, while security requires closing windows for burglar prevention. Traditional single-generation systems lack multi-perspective dynamic verification mechanisms, failing to effectively identify and resolve such underlying conflicts during the generation phase. This often results in generated control scripts interfering with each other after deployment, even causing system paralysis or security incidents. Therefore, existing technologies struggle to balance the interpretability of service logic generation with the reliability of physical execution, urgently requiring a new IoT service logic orchestration method that breaks through traditional paradigms. Summary of the Invention

[0007] In view of this, the purpose of this invention is to provide an automatic generation system and method for IoT service logic based on multi-agent systems. This invention aims to introduce a dynamic collaboration and cross-validation mechanism among multiple agents to jointly construct a transparent three-layer requirement model, achieving a "white-box" transformation from high-level user intent to conflict-free, highly reliable low-level service logic. This effectively solves the problems of difficult-to-trace reasoning processes, easy conflicts in low-level hardware resources, and poor environmental adaptability in existing automatic generation technologies.

[0008] To achieve the above objectives, the present invention provides the following technical solution:

[0009] An IoT service logic automatic generation system based on multi-agent technology is characterized by comprising: a three-layer requirement model and a functional implementation agent, a quality implementation agent, and a service logic synthesis agent; the three agents perform read and write operations on the three-layer requirement model, and each agent has read and write permissions: the functional implementation agent is responsible for constructing functional requirement branches and writing the results into the three-layer requirement model; the quality implementation agent is responsible for constructing quality requirement branches and writing the results into the three-layer requirement model; and the service logic synthesis agent is responsible for reading the functional requirement branches and quality requirement branches, synthesizing the branches, and writing the synthesis results into the three-layer requirement model to construct a complete service logic scheme.

[0010] The three-layer demand model includes an intent layer, a planning layer, and a rule layer. It is used to record the hierarchical mapping relationship from high-level user intent to logical planning schemes and then to low-level service logic, and supports the representation of alternative related branches of alternative schemes.

[0011] The three intelligent agents are specifically configured as follows:

[0012] The functional implementation agent is configured with preset intent templates and prompts with atomic granularity to guide the large model to decompose the user's input functional intent into indivisible atomic intents; it is configured with environmental awareness tools and prompts to combine available abstract device states to generate logical planning schemes; it is configured with device protocol mapping tools to map logical planning schemes to underlying service logic; and it is configured with reverse verification prompts to verify from the bottom up whether the generated service logic and planning schemes meet the top-level functional intents.

[0013] The quality implementation agent is equipped with environmental perception tools, preset quality templates and prompts to assess current resources, instantiate preset quality templates, and trigger a degradation inference mechanism when environmental resources are limited to infer the intention and planning scheme of the second-best quality; it is equipped with device protocol mapping tools to map the planning scheme to the underlying service logic; and it is equipped with reverse verification prompts to verify from the bottom up whether the generated result meets the top-level quality intention.

[0014] The service logic synthesis agent is equipped with a physical conflict detection tool to determine whether there is a hardware resource contention conflict between the underlying service logics; it is also equipped with an environmental awareness tool to verify the real-time online status of physical devices. If a device is offline, a self-healing mechanism is triggered to backtrack along alternative related branches, switch in real time, and modify the service logic.

[0015] The three agents follow the following cooperation mechanism: the functional implementation agent and the quality implementation agent are independent of each other in the shared workspace and can be executed in parallel or serially; if the service logic synthesis agent detects a conflict during synthesis, it explicitly feeds back the conflict information to the functional implementation agent to drive it to collaboratively refine and reimplement the functional requirement branches at the conflict point; the convergence condition of the cooperation mechanism is set as no conflict in the synthesized three-layer requirement model or reaching the preset maximum number of iterations.

[0016] Furthermore, the three-layer demand model is specifically a bidirectional demand traceability tree (BRT) data structure. The bidirectional demand traceability tree (BRT) is a multi-layered directed tree structure containing nodes and edges, wherein:

[0017] The nodes include the intent layer node at the top level, the planning layer node in the middle level, and the rule layer node at the bottom level.

[0018] The intent layer nodes include functional intent nodes and quality intent nodes, used to represent device-independent high-level objectives;

[0019] The planning layer nodes are used to represent logical planning schemes for a given intent, transforming high-level intents into causal expressions for abstract devices;

[0020] The rule layer node is used to represent the specific device scheduling rules for a given logical planning scheme, and convert the planning scheme into the service logic of specific Internet of Things devices;

[0021] The edges include:

[0022] The decomposition edge: used to characterize the dependency relationship of combined calls of multiple physical hardware that need to be jointly executed in the physical space to achieve the same goal;

[0023] Or the decomposition edge: as a specific representation form of the alternative association branch, used to characterize different hardware combination alternative solutions to achieve the same goal.

[0024] An Internet of Things service logic automatic generation method applied to the above system, the method includes the following steps:

[0025] S1. Construction of the function requirement realization agent: The function realization agent decomposes the function intention input by the user, maps it to the abstract device and generates a logical planning scheme, and then converts it into the corresponding underlying service logic, constructs a function requirement branch in the three-layer requirement model, and performs a satisfaction check based on the guidance of the large model on the generation result;

[0026] S2. Construction of the quality requirement realization agent: The quality realization agent instantiates the quality intention based on the real-time environment assessment, generates the corresponding logical planning scheme and underlying service logic, constructs a quality requirement branch in the three-layer requirement model, and performs a satisfaction check based on the guidance of the large model on the generation result;

[0027] S3. Construction of the service logic synthesis agent: The service logic synthesis agent performs branch synthesis on the function requirement branch and the quality requirement branch; performs conflict detection after synthesis, if there is a conflict, feedback it to the function realization agent for collaborative refinement; after there is no logical conflict, extract the service logic scheme and perform a physical environment availability check, if the environment is unavailable, execute a self-healing mechanism based on the alternative association branch to modify the three-layer requirement model;

[0028] Among them, S1 and S2 are independent of each other and can be executed in parallel or serially in any order; in S3, if the service logic synthesis agent detects a conflict in the synthesized three-layer requirement model, then explicitly feedback the conflict information to the function realization agent to collaboratively modify and re-implement the function requirement branch; set the convergence condition of the collaboration mechanism to that there is no conflict in the synthesized three-layer requirement model or reach the preset maximum number of iterations.

[0029] Further, the step S1 specifically includes:

[0030] S1-1, Intent Decomposition: The original functional requirements received from the user are used as input. Prompt words are designed to guide the large model to decompose these into multiple indivisible atomic intents. During the decomposition process, the system pre-defines intent templates with atomic granularity. This granularity requires that atomic intents must have a substantial physical impact on external entities and logically represent the smallest indivisible semantic unit. Specifically, this includes single-step causal triggering rules, absolute action instructions, and single-state constraints. By constructing prompt words that include the aforementioned granularity requirements and template format specifications, the large model is guided to accurately decompose the user intent and fill it into the corresponding intent template, thereby ensuring the standardization of the decomposition results.

[0031] S1-2, Intent Implementation Design: When mapping atomic intents to logical plans, the built-in environment awareness tool is invoked to obtain the set of abstract functional device states in the current IoT environment; abstract functional devices in the current environment that are in an unavailable state are filtered out, and at least one logical plan scheme is generated by combining them.

[0032] S1-3, Service Logic Generation: When mapping the logical planning scheme to the service logic of a specific IoT device, the built-in device protocol mapping tool is called to map the abstract planning instructions to the underlying protocol code that can be executed by the target physical device, so as to form the underlying service logic.

[0033] S1-4 Satisfaction Check: A bottom-up reverse verification mechanism is adopted. The generated initial functional branch is used as input and the output is the verified functional branch. The large model guides the check to see whether the underlying service logic and the intermediate planning scheme truly satisfy the top-level functional intent in the current environment. If not, it returns to S1-1 to regenerate.

[0034] Furthermore, step S2 specifically includes:

[0035] S2-1, Environmental Assessment and Intent Generation: The built-in environmental perception tool is invoked to obtain the specific devices in the current IoT environment, and the preset quality template is instantiated into quality intent and logical planning scheme. The agent will assess whether the current environmental resources can realize the preset quality template. If the environmental resources are limited and the realization fails, the degradation reasoning mechanism is triggered. The preset quality template is used as the starting point for dynamic modification, and a suboptimal quality intent and planning scheme that matches the current resources is inferred.

[0036] S2-2, Service Logic Generation: When mapping the planning scheme to the service logic of specific IoT devices, the built-in device protocol mapping tool is called to map the abstract planning instructions to the underlying protocol code that can be executed by the target physical device, so as to form the underlying service logic.

[0037] S2-3 Satisfaction Check: A bottom-up reverse verification mechanism is adopted. The generated initial quality branch is used as input and the output is the verified quality branch. The large model guides the check to see whether the underlying service logic and the intermediate planning scheme truly satisfy the top-level quality intent in the current environment. If not, it returns to S2-1 for forced degradation reasoning.

[0038] Furthermore, step S3 specifically includes:

[0039] S3-1, Branch Synthesis: Read the functional requirement branches and quality requirement branches in the workspace, associate them at the top level of the model, and synthesize a unified three-layer requirement model; during the synthesis process, identify duplicate service logic and perform logic fusion to remove duplicates;

[0040] S3-2, Conflict Detection: Perform physical conflict detection on the synthesized three-layer requirement model to determine whether there is a conflict of hardware resource contention between the underlying service logics; if a conflict exists, the conflict information is fed back to the functional implementation agent, which re-plans the generation logic for the conflict point, eliminates the conflict through cooperation between agents, and finally generates a conflict-free three-layer requirement model.

[0041] S3-3, Solution Extraction: Taking a conflict-free three-layer requirement model as input, extract all service logic and output as a deployable underlying physical control script; the agent calls the built-in environmental awareness tool to verify the real-time online status of physical devices. If the device is found to be offline, causing the solution to be unavailable, the self-healing mechanism is immediately triggered. The agent backtracks along the unavailable service logic to the nearest alternative related branch, automatically switches to other alternative solutions available in other environments, and re-extracts the script; if it is still unavailable after backtracking through all alternative related branches, a global execution failure warning is thrown.

[0042] As can be seen from the above technical solution, compared with the prior art, the present invention has the following beneficial effects: The present invention establishes a three-layer requirement model of "intent-planning-rules" by constructing a bidirectional requirement traceability tree (BRT), breaking the traditional "black box" mode of automatic generation and realizing the "white box" and high interpretability of the service logic generation process. Simultaneously, the system introduces a multi-agent collaborative mechanism to decouple the generation process of functions and quality, and through the conflict detection and feedback mechanism in the synthesis stage, it resolves resource contention conflicts of the underlying hardware at the source, ensuring the safety and reliability of physical execution. Based on this, the present invention combines a large model-guided "bottom-up" reverse verification to form a rigorous bidirectional closed loop, ensuring that the underlying code strictly supports the top-level intent. Furthermore, for highly dynamic physical environments, it utilizes alternative branches to achieve automatic backtracking and seamless solution switching when devices are offline, significantly improving the fault tolerance capability of the IoT system. Attached Figure Description

[0043] Figure 1 This is a system architecture diagram of the present invention;

[0044] Figure 2 This is a diagram illustrating the artifact evolution of the functional intent intelligent agent construction process in an embodiment of the present invention.

[0045] Figure 3 This is a diagram illustrating the evolution of the artifact during the construction process of the quality intent intelligent agent in this embodiment of the invention.

[0046] Figure 4 This is an artifact evolution diagram of the service logic synthesis agent construction process in an embodiment of the present invention;

[0047] Figure 5 This is the bidirectional demand tracing tree result for a simple IoT smart home system scenario in an embodiment of the present invention. Detailed Implementation

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

[0049] Refer to the system architecture diagram of this invention. Figure 1 This invention provides a system and method for automatically generating IoT service logic based on multiple agents. The system includes a function implementation agent, a quality implementation agent, and a service logic synthesis agent. The three agents jointly perform read and write operations on a three-layer requirement model, and each agent has read and write permissions: the function implementation agent is responsible for constructing functional requirement branches and writing the results into the three-layer requirement model; the quality implementation agent is responsible for constructing quality requirement branches and writing the results into the three-layer requirement model; and the service logic synthesis agent is responsible for reading the functional requirement branches and quality requirement branches, synthesizing the branches, and writing the synthesized results into the three-layer requirement model.

[0050] Preferably, the three-layer demand model in this invention specifically adopts a bidirectional demand traceability tree (BRT) data structure. The BRT is a multi-layered directed tree structure containing nodes and edges, used to record the hierarchical mapping relationship from high-level user intent to logical planning schemes, and then to low-level service logic: At the top are intent layer nodes, including functional intent nodes and quality intent nodes, used to represent device-independent high-level goals; at the middle layer are planning layer nodes, used to represent logical planning schemes for a given intent, converting high-level intents into causal expressions for abstract devices; at the bottom are rule layer nodes, used to represent specific device scheduling rules for a given logical planning scheme, converting the planning scheme into service logic for specific IoT devices, for example, it can be specifically instantiated as trigger-command programming (TAP) rules, etc. Edges are used to define the hierarchical decomposition relationship between nodes, including AND decomposition edges representing the dependency relationships of multiple physical hardware combinations that need to be jointly executed in physical space to achieve the same goal, and OR decomposition edges as specific representations of alternative hardware combinations used to achieve the same goal.

[0051] The automatic generation process of IoT service logic based on multi-agent technology in this invention includes the following overall steps:

[0052] S1. Functional Requirements Implementation Agent Construction: The functional requirements implementation agent decomposes the user's input functional intent, maps it to the abstract device and generates a logical planning scheme, which is then transformed into the corresponding underlying service logic. Functional requirement branches are built in BRT, and the generated results are subjected to a satisfaction check based on the large model.

[0053] S2. Construction of Quality Requirement Realization Agent: The quality realization agent instantiates the quality intent based on real-time environmental assessment, generates the corresponding logical planning scheme and underlying service logic, constructs the quality requirement branch in BRT, and performs a satisfaction check based on the large model guidance on the generated results.

[0054] S3. Service Logic Synthesis Agent Construction: The service logic synthesis agent synthesizes functional requirement branches and quality requirement branches; after synthesis, conflict detection is performed. If a conflict exists, it is fed back to the functional implementation agent for collaborative refinement; after there is no logical conflict, the service logic scheme is extracted and the physical environment availability is verified. If the environment is unavailable, the self-healing mechanism is executed based on the alternative related branches to modify the BRT.

[0055] In this process, steps S1 and S2 are independent of each other. The function implementation agent and the quality implementation agent can be executed in parallel or in any order. In step S3, if the service logic synthesis agent detects a conflict in the synthesized BRT, it will explicitly feed back the conflict information to the function implementation agent to collaboratively modify and reimplement the functional requirement branch. The convergence condition of the collaboration mechanism is set as the BRT having no conflict or reaching the preset maximum number of iterations.

[0056] Furthermore, step S1 specifically includes:

[0057] S1-1, Intent Decomposition: The original functional requirements received from user input are used as input. Prompt words guide the large model to decompose these into multiple indivisible atomic intents. During decomposition, the system pre-defines intent templates with atomic granularity. These atomic intents must have a substantial physical impact on external entities and logically represent the smallest indivisible semantic unit, specifically encompassing single-step causal triggering rules, absolute action instructions, and single-state constraints. By constructing prompt words that include granularity requirements and template format specifications, the large model is guided to accurately decompose user intents and fill them into the corresponding intent templates, thereby ensuring the standardization of the decomposition results.

[0058] S1-2, Intent Implementation Design: When mapping atomic intents to logical plans, the built-in environment awareness tool is invoked to obtain the set of abstract functional device states in the current IoT environment; abstract functional devices in the current environment that are in an unavailable state are filtered out, and at least one logical plan scheme is generated by combining them.

[0059] S1-3, Service Logic Generation: When mapping the logical planning scheme to the service logic of a specific IoT device, the built-in device protocol mapping tool is called to map the abstract planning instructions to the underlying protocol code that can be executed by the target physical device, so as to form the underlying service logic.

[0060] S1-4 Satisfaction Check: This is a bottom-up reverse verification mechanism. It takes the generated initial functional branch as input and outputs the verified functional branch. It uses the large model to guide the check of whether the underlying service logic and the intermediate planning scheme truly satisfy the top-level functional intent in the current environment. If not, it returns to S1-1 to regenerate.

[0061] Furthermore, step S2 specifically includes:

[0062] S2-1, Environmental Assessment and Intent Generation: The built-in environmental perception tool is invoked to obtain specific devices in the current IoT environment. A preset quality template is instantiated into a quality intent and logical planning scheme. The agent assesses whether the current environmental resources can achieve the preset quality template. If limited environmental resources lead to failure, a degradation inference mechanism is triggered, dynamically modifying the preset quality template to infer a suboptimal quality intent and planning scheme that matches the current resources.

[0063] S2-2, Service Logic Generation: When mapping the planning scheme to the service logic of specific IoT devices, the built-in device protocol mapping tool is called to map the abstract planning instructions to the underlying protocol code that can be executed by the target physical device, so as to form the underlying service logic.

[0064] S2-3 Satisfaction Check: This is a bottom-up reverse verification mechanism. It takes the generated initial quality branch as input and outputs the verified quality branch. It uses a large model to guide the check of whether the underlying service logic and intermediate planning scheme truly satisfy the top-level quality intent in the current environment. If not, it returns to S2-1 for forced degradation reasoning.

[0065] Furthermore, step S3 specifically includes:

[0066] S3-1, Branch Synthesis: Read the functional requirement branches and quality requirement branches in the workspace, associate them at the top level of the model, and synthesize a unified BRT; during the synthesis process, identify duplicate service logic and perform logic fusion to remove duplicates;

[0067] S3-2, Conflict Detection: Perform physical conflict detection on the synthesized BRT to determine whether there is a conflict of hardware resource contention between the underlying service logics; if a conflict exists, the conflict information is fed back to the functional implementation agent, which re-plans the generation logic for the conflict point, eliminates the conflict through cooperation between agents, and finally generates a conflict-free BRT.

[0068] S3-3, Solution Extraction: Taking a conflict-free BRT as input, extract all service logic and output as a deployable underlying physical control script. The agent calls the built-in environment awareness tool to verify the real-time online status of physical devices. If it finds that the device is offline and the solution is unavailable, it immediately triggers a self-healing mechanism, backtracking upwards along the unavailable service logic to the nearest alternative related branch, automatically switching to other alternative solutions available in other environments and re-extracting the script; if it is still unavailable after backtracking through all alternative related branches, a global execution failure warning is thrown.

[0069] Example

[0070] In this embodiment, based on a simple IoT smart home system scenario, the present invention elaborates on the specific execution process of how each intelligent agent collaboratively constructs a BRT to automatically generate IoT service logic containing temperature control intent and safety and quality intent. In this embodiment, the available devices in the scenario include:

[0071] The aqara_temp_sensor is a temperature sensor capable of sensing ambient temperature. It supports acquiring the current ambient temperature, and its specific configuration is shown in Table 1.

[0072] Table 1

[0073]

[0074] The MijiaAC air conditioner features ambient temperature control capabilities. It supports status reading, allowing users to determine whether it is currently in cooling mode, heating mode, or off. It also supports three control actions: turning on cooling mode to lower the ambient temperature, turning on heating mode to raise the ambient temperature, and turning off the air conditioner. Specific configurations are shown in Table 2.

[0075] Table 2

[0076]

[0077] The MijiaHeater electric heater is capable of raising the ambient temperature. It supports both on / off control, and its specific configuration is shown in Table 3.

[0078] Table 3

[0079]

[0080] The LG_smoke_sensor is a smoke sensor capable of detecting ambient smoke. It supports obtaining the current ambient smoke concentration, and its specific configuration is shown in Table 4.

[0081] Table 4

[0082]

[0083] The MijiaAlarm is a smart alarm bell with alarm capabilities. It supports both on and off control, and its specific configuration is shown in Table 5.

[0084] Table 5

[0085]

[0086] In the initial stage of the generation process, the functional implementation agent will decompose the user's input functional intent, "desired temperature between 18℃ and 24℃," and implement it as underlying service logic. The specific process is as follows: Figure 2 As shown.

[0087] When a user inputs a high-level and vague functional intent such as "desiring a temperature between 18℃ and 24℃," the functional implementation agent performs an intent decomposition step. The input is the user's functional intent, and the output is a standardized set of atomic intents. The prompt words for this step are designed as follows:

[0088] "You are a rigorous IoT system expert. Please break down the following user intent into atomic intents. Each atomic intent must meet the following requirements: (1) It has a substantial physical impact on external environmental entities; (2) Logically, it is represented as the smallest indivisible semantic unit, specifically covering single-step causal triggering rules, absolute action instructions, and single-state constraints. Available atomic intent expressions include: 'If <environmental state>, then <expected environmental effect>', '<expected environmental effect> should / should not occur', '<environmental attribute> should / should not be higher / lower than <expected value>'. The following is a successful example: Input 'Expect indoor light to be 300 lux', output is:

[0089] ['If the light intensity is higher than 300 lux, then reduce the light intensity', 'The light intensity should not be lower than 300 lux']. Please output only a list of atomic intents that conform to the above format, with each atomic intent on a separate line, and do not include explanatory text or vague descriptive terms.

[0090] The aforementioned prompts, through strict output control and semantic constraints, guide the large model to precisely decompose user intent into indivisible atomic functional units. Thus, the large model decomposes this into two atomic intent nodes at the intent layer: "If the temperature is greater than 24℃, then lower the temperature" and "If the temperature is less than 18℃, then raise the temperature." These two atomic intents will affect the external environmental entity "temperature" and logically belong to the indivisible semantic unit of a single-step logical causal relationship.

[0091] Subsequently, the functional implementation agent executes the intent implementation design steps, taking a list of atomic intents as input and outputting a logical programming scheme, expressed as a causal expression for the abstract device. The design prompt for this step is:

[0092] "You are a meticulous IoT system expert. Please use the environment awareness tool to obtain the set of abstract functional device states in the current environment, and generate planning schemes according to atomic intents. Please carefully filter out abstract functional devices that are unavailable in the current environment, and combine them to generate at least one logical planning scheme. The logical planning scheme is expressed as: 'IF <abstract device>.<function> <operator> <threshold> THEN <function> <abstract device>'. The following is a successful example: After calling the environment awareness tool, the available abstract functional devices in the current environment include: 'brightness sensing device (reads ambient brightness)' and 'brightness enhancement device (brightens)'. The input atomic intent is 'light intensity should not be less than 300 lux', and the output is: 'IF brightness sensing device.read ambient brightness()<300 THEN brighten() brightness enhancement device'. Please only use the above-mentioned available abstract functional devices for planning, and do not introduce non-existent abstract devices and functions. Each atomic intent generates at least one planning scheme. If an atomic intent has multiple planning schemes, please split it into multiple parallel schemes."

[0093] The purpose of the above design is to constrain the planning and solution space of the large model within the set of abstract devices actually available in the current environment, ensuring the physical feasibility of the planning scheme. Therefore, the functional implementation agent generates planning layer nodes based on the decomposed atomic intents: "IF Temperature sensing device.reading()>24 THEN Turn on () Temperature cooling device" and "IF Temperature sensing device.reading()<18 THEN Turn on () Temperature heating device".

[0094] Then, the functional implementation agent will execute the service logic generation step, with the logic planning scheme as input and the specific service logic as output. In this embodiment, the trigger-action programming (TAP) rule is used as the service logic. The prompt words for this step are:

[0095] "You are a rigorous IoT system expert. Please use the device protocol mapping tool to map the given logical planning scheme, combined with the specific abstract functional devices and physical devices in the current environment, into trigger-action programming (TAP) rules. The TAP rule should be expressed as: 'IF <physical device>.<capability>(<parameter>) <operator> <threshold> THEN <capability>(<parameter>) <physical device>'. The following is a successful example: The logical planning scheme is 'IF brightness sensing device.read ambient brightness()<300 THEN brighten() brightness increase device', and the following devices exist in the environment: 'light sensor aqara_brightness_sensor -capability 1: get() reads the current ambient brightness, no input parameter, returns the ambient brightness in lux', 'smart light XiaomiLamp -capability 1: turn_on() turn on the light, no input parameter, no output parameter; -capability 2: turn_off() turn off the light, no input parameter, no output parameter', after calling the device protocol mapping tool, the deterministic rule is output: 'IF `aqara_brightness_sensor.get()<300 THEN turn_on() XiaomiLamp'. Ensure that each TAP rule fully satisfies the corresponding logical planning scheme and does not introduce devices or capabilities that do not exist in the environment. If an abstract action in a logical planning scheme can be matched by multiple entity device capabilities, please automatically split it into multiple parallel TAP rules.`

[0096] The purpose of the above design is to map abstract logical planning schemes to specific, usable service logical rules. For cooling planning, the functional implementation agent uniquely matches the cooling action capability of the air conditioner MijiaAC in the environment, thus generating a definite rule layer node: "IF aqara_temp_sensor.get() > 24 THEN turn_cool_on() MijiaAC". However, for heating planning, the functional implementation agent finds that the heating action capability of the air conditioner MijiaAC and the turning action capability of the electric heater MijiaHeater both meet the logical planning requirement of "turning on the heating device". Therefore, an OR-DE relationship is automatically generated here, deriving two parallel rule layer nodes: the rule node "IF aqara_temp_sensor.get() < 18 THEN turn_heat_on() MijiaAC" which links the air conditioner to heating, and the rule node "IF aqara_temp_sensor.get() < 18 THEN turn_on() MijiaHeater" which links the electric heater to heating.

[0097] Finally, the function implementation agent performs a satisfaction check step, performing a bottom-up reverse verification of the generated initial function branches. The prompt words for this step are:

[0098] "You are a rigorous IoT system expert. Please complete the following three-level judgment in sequence and output the conclusion of 'satisfied' or 'not satisfied': (1) Does the bottom TAP rule fully satisfy the conditions and action requirements of the middle planning scheme? (2) Does the middle planning scheme fully cover the semantic meaning of the top atomic intent? (3) Can the top atomic intent jointly satisfy the user input intent? The following is a successful example: The input is the bottom rule 'IF aqara_brightness_sensor.get()<300THEN turn_on() XiaomiLamp' and the middle planning 'IF brightness sensing device.read ambient brightness()<300 THEN brighten() brightness increase device' and 'IF aqara_brightness_sensor.get()>300 THEN turn_off() XiaomiLamp' and the middle planning 'IF brightness sensing device.read ambient brightness()>300 THEN decrease()' The output of the brightness reduction device is: 'Satisfied.' The triggering condition of the underlying rule, aqara_brightness_sensor.get(), corresponds to the mid-level plan's temperature and brightness sensing device.Read Ambient Brightness(). XiaomiLamp's actions, turn_on() and turn_off(), correspond to the brightness increase device's brightening action and the brightness reduction device's dimming action, respectively, which are completely matched. 'Input is mid-level plan' IF Brightness Sensing Device.Read Ambient Brightness() < 300 THEN Brighten() Brightness increase device' and atomic intent 'Light intensity should not be less than 300 lux' and mid-level plan 'aqara_brightness_sensor.get()>300 THEN turn_off() XiaomiLamp' and atomic intent 'If the light intensity is higher than 300 lux, then reduce the light intensity', the output is: 'Satisfied.' The triggering condition and action of the mid-level plan completely cover the causal relationship of the top-level intent'. Input is atomic intent 'Light intensity should not be less than 300 lux' The statement "If the light intensity is higher than 300 lux, then reduce the light intensity" aligns with the user's input intent "Desires indoor light to be 300 lux," resulting in the output "Satisfied. The atomic intents can jointly achieve the user's desired effect." Please compare each layer and provide the reasoning for your judgment. If any layer fails to meet the requirement, please clearly indicate the missing or biased point.

[0099] The aforementioned prompts guide the large model to perform satisfaction checks through a bottom-up decision-making process of "bottom-level rules → mid-level planning → top-level intent". For example, the bottom-level TAP rule "IF aqara_temp_sensor.get()>24THEN turn_cool_on() MijiaAC" fully satisfies the mid-level cooling plan "IF temperature sensing device.reading()>24THEN turn() temperature cooling device", which satisfies the top-level cooling intent "if the temperature is greater than 24℃, then lower the temperature". Furthermore, the cooling intent and the heating intent together satisfy the top-level temperature control intent "the desired temperature is between 18℃ and 24℃". After the satisfaction check passes, the functional implementation agent writes the existing branches representing functional requirements into the BRT.

[0100] This concludes the process of building the intelligent agent to meet the functional requirements.

[0101] Subsequently, the quality implementation agent will assess the environment and instantiate the quality intent to ensure that the final generated service logic has native security at the underlying level. The specific process is as follows: Figure 3 As shown.

[0102] The quality-enabling intelligent agent first performs an environmental assessment and intent generation step. The input is a pre-defined quality template written by human experts, which includes "security requirements" and "property protection requirements." An environmental assessment is then conducted based on the specific devices within the current IoT environment. The design prompts for this step are:

[0103] "You are a meticulous IoT quality expert. Please use the environmental awareness tool to obtain the current environmental devices and evaluate whether the following quality templates can be instantiated in the current environment. Evaluation rules: If the required device capabilities of the template have a matching item in the environmental device list, retain the quality intent and instantiate the corresponding causal programming expression; if the required device capabilities are missing, discard the branch; if partially satisfied but with constraints, infer the suboptimal alternative. The following is a successful example: The quality template input is: '[INT] Quality Template - AND - Safety Requirements - Fire Detection - If a fire occurs, then start the alarm - IF Smoke Detector.Reading()>5% THEN Start() Alarm Device; └ AND - Property Protection Requirements - Overload Protection - If a circuit overload is detected, then disconnect the device connection - IF Power Detector.Reading()==Overload THEN Disconnect()' The available devices in the current environment are: 'aqara_power_sensor' and 'MijiaSmartSwitch'. The output is '[INT] Quality Template - AND - Property Protection Requirement - Overload Protection - If circuit overload is detected, then disconnect the device connection - IF Power Detection Device.Reading() == Overload THEN Disconnect() Smart Switch'. Because the safety requirement lacks device support, it is discarded, while the property protection requirement is fully supported by the device and is therefore retained. Please evaluate the template rigorously to avoid omissions and output the results.

[0104] The aforementioned prompts, by clearly defining the evaluation rules, guide the large model to execute template instantiation decisions based on resource matching, avoiding the generation of invalid rules without device support. During the environmental assessment, the quality implementation agent discovers that the environment contains a smoke sensor (LG_smoke_sensor), a smart alarm (MijiaAlarm), and household appliances (MijiaAC air conditioner and MijiaHeater), perfectly supporting the quality requirement of "detecting and handling fires." Therefore, this safety intent and its corresponding planning layer nodes, namely "IF smoke sensor.reading()>5% THEN activate() alarm device" and "IF smoke sensor.reading()>5% THEN turn off() household appliances," are retained. Simultaneously, the quality implementation agent discovers during comparison that the current physical environment lacks power detection devices and smart switches. Due to the lack of device support, the quality implementation agent discards the branch related to "overload protection" in the quality template, thus avoiding the generation of invalid rules.

[0105] Subsequently, the quality implementation agent further maps the logical planning to specific devices. The prompt word design and the service logic generation steps of the function implementation agent are consistent. Based on the planning layer node "IF smoke sensor.reading()>5% THEN start() alarm device", the corresponding rule layer node "IF LG_smoke_sensor.get()>5% THEN turn_on() MijiaAlarm" is generated. Based on the planning layer node "IF smoke sensor.reading()>5% THEN turn_off() household appliances", two parallel rule layer nodes are generated: the rule node to turn off the air conditioner "IF LG_smoke_sensor.get()>5% THEN turn_off() MijiaAC" and the rule node to turn off the electric heater "IF LG_smoke_sensor.get()>5% THEN turn_off() MijiaHeater".

[0106] Finally, the quality-realizing agent will also guide the large model to sequentially determine from the bottom up whether the lower-level rules can satisfy the middle-level planning, and whether the middle-level planning can satisfy the top-level intent. The satisfaction check step prompts are designed as follows:

[0107] "You are a rigorous IoT quality expert. Please complete the following layer judgments in sequence and output the conclusion of 'satisfied' or 'not satisfied': (1) Whether the bottom TAP rule fully satisfies the conditions and action requirements of the middle planning scheme; The following is a successful example: The input is the bottom rule 'IF aqara_power_sensor.isOver()==true THEN break()MijiaSmartSwitch' and the middle planning 'IF power detection device.reading()==overload THEN disconnect() smart switch', and the output is: 'satisfied. The trigger condition of the bottom rule aqara_power_sensor.isOver() corresponds to the power detection device.reading() of the middle planning, and the action break() of MijiaSmartSwitch corresponds to the disconnect action of the smart switch, which is a perfect match.' Please compare them one by one and give the reason for the judgment. If any layer is not satisfied, please clearly point out the missing or deviation and return to the environmental assessment and intent generation steps for downgrade reasoning."

[0108] Similar to the function of the intelligent agent, after the satisfaction check is passed, the quality implementation intelligent agent writes the branch representing the quality requirements into the BRT.

[0109] This concludes the process of constructing the quality-realizing intelligent agent.

[0110] Finally, the service logic synthesis agent synthesizes the functional requirement branches and quality requirement branches to obtain a usable and conflict-free service logic solution. The specific process is as follows: Figure 4 As shown.

[0111] The service logic synthesis agent first reads the functional requirement branches and quality requirement branches that have been generated in the workspace, and then associates them at the top level of the model, merging them into a unified BRT and removing duplicate service logic.

[0112] Next, the service logic synthesis agent performs physical conflict detection on the synthesized demand model. The detection result determines that there is a physical conflict of hardware resource preemption. For example, when the environment meets the conditions of temperature greater than 24℃ and smoke concentration greater than 5%, i.e., aqara_temp_sensor.get()>24 and LG_smoke_sensor.get()>5%, the underlying physical device, the air conditioner MijiaAC, will simultaneously receive the turn_cool_on() action command from the functional branch and the turn_off() action command from the quality branch. After discovering this preemption conflict, the service logic synthesis agent immediately explicitly feeds back the conflict information to the functional implementation agent. The conflict information is structured as: 'Conflict exists! Conflict situation: When aqara_temp_sensor.get()>24 and LG_smoke_sensor.get()>5%, MijiaAC will simultaneously receive two action signals turn_cool_on() and turn_off(), constituting hardware resource preemption.' The conflict stems from the functional rule `IF aqara_temp_sensor.get()>24 THEN turn_cool_on() MijiaAC` and the quality rule `IF LG_smoke_sensor.get()>5% THEN turn_off() MijiaAC`. The user is asked to redesign the functional rule to address this conflict, adding a mutual exclusion constraint to ensure no further conflict occurs. Upon receiving feedback, the functional implementation agent appends the conflict information to the original prompt to redesign the generated results. The agent re-executes the construction process, forcibly adding a mutual exclusion constraint of "no fire occurred," i.e., `LG_smoke_sensor.get()<=5%`, to the original trigger condition of the air conditioning cooling control TAP rule. The rule is modified to `IF aqara_temp_sensor.get()>24 AND LG_smoke_sensor.get()<=5% THEN turn_cool_on() MijiaAC`. Similarly, the TAP rule for air conditioner heating control has also been modified to include a mutual exclusion constraint, becoming "IF aqara_temp_sensor.get()<18 AND LG_smoke_sensor.get()<=5% THEN turn_heat_on() MijiaAC", while the TAP rule for electric heater heating control has also been modified to include a mutual exclusion constraint, becoming "IF aqara_temp_sensor.get()<18 AND LG_smoke_sensor.get()<=5% THEN turn_on()MijiaHeater".Through this cross-collaboration among intelligent agents, the original conflicts were successfully eliminated, ultimately resulting in a conflict-free BRT.

[0113] Finally, the service logic synthesis agent takes the modified, conflict-free BRT as input, extracts all service logic, and outputs a deployable underlying physical control script. Since the logic planning for "increasing temperature" in the functional requirements branch retains an "OR decomposition edge"—that is, heating via MijiaAC air conditioning or MijiaHeater electric heater—the service logic synthesis agent extracts and encapsulates two sets of mutually alternative automated TAP rule sets. After the solution extraction is complete, the service logic synthesis agent further performs a physical environment availability verification operation, calling the built-in environment awareness tool to obtain the real-time online status of each physical device in the current environment, and designs a self-healing verification prompt:

[0114] "You are an IoT status monitor. The existing solutions are as follows: [Solution List]. The current real-time online status of each physical device is as follows: [Physical Device Online Status List]. The current bidirectional demand traceability tree status is as follows: {BRT}. Please verify whether all devices involved in each solution are online. If a solution has offline devices, determine that the solution is unavailable, and backtrack upwards along the unavailable rule to the nearest or decomposed edge in the BRT, cut off the branch path corresponding to the offline device, and re-extract the solution from the remaining available paths. If all alternative solutions are unavailable, output: 'Global execution failure warning: All alternative solutions have offline devices, please check the physical environment.' Please execute the verification according to the above logic and output the results."

[0115] The aforementioned prompts, through explicit injection of real-time device status and scheme-by-scheme verification logic, guide the large model to proactively identify device offline risks before deployment and automatically backtrack and switch along the OR decomposition edge of the BRT. During actual deployment and operation, if the air conditioning unit in the first scheme suddenly goes offline, rendering the scheme unusable, the system will immediately trigger a self-healing mechanism, automatically switching to the second alternative scheme using electric heaters for heating. Simultaneously, the service logic synthesis agent will backtrack along the unusable air conditioning heating rule to the "OR decomposition edge," removing and discarding it, and re-extracting the script, thus ensuring the highly reliable operation of the global service environment. In extreme cases, if the system still cannot find a usable scheme after backtracking through all alternative related branches, such as finding that both the air conditioner and electric heater are offline simultaneously, the agent will throw a global execution failure warning, reminding the user to perform a physical environment check.

[0116] At this point, the service logic synthesis intelligent agent construction process is complete, and the final simple IoT smart home system BRT is as follows: Figure 5 As shown.

[0117] The details of the various embodiments in this specification are described in a progressive manner. The focus of each embodiment detail is to explain the differences from the details of other embodiments. The same or similar parts between the various embodiments can be referred to each other.

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

Claims

1. A system for automatically generating IoT service logic based on multi-agent interaction, characterized in that, The system includes a three-layer requirement model and three intelligent agents: a function implementation agent, a quality implementation agent, and a service logic synthesis agent. The three agents perform read and write operations on the three-layer requirement model, and each agent has read and write permissions: the function implementation agent is responsible for constructing the function requirement branch and writing the result into the three-layer requirement model; the quality implementation agent is responsible for constructing the quality requirement branch and writing the result into the three-layer requirement model; and the service logic synthesis agent is responsible for reading the function requirement branch and the quality requirement branch, synthesizing the branch, and writing the synthesis result into the three-layer requirement model to construct a complete service logic solution. The three-layer demand model includes an intent layer, a planning layer, and a rule layer. It is used to record the hierarchical mapping relationship from high-level user intent to logical planning schemes and then to low-level service logic, and supports the representation of alternative related branches of alternative schemes. The three intelligent agents are specifically configured as follows: The functional agent is configured with preset intent templates and prompts with atomic granularity to guide the large model to decompose the user's input functional intent into indivisible atomic intents; It is equipped with environmental awareness tools and prompts to combine the status of available abstract devices to generate logical planning schemes; it is equipped with device protocol mapping tools to map logical planning schemes to underlying service logic; and it is equipped with reverse verification prompts to verify from the bottom up whether the generated service logic and planning schemes meet the top-level functional intent. The quality implementation agent is equipped with environmental perception tools, preset quality templates and prompts to assess current resources, instantiate preset quality templates, and trigger a degradation inference mechanism when environmental resources are limited to infer the intention and planning scheme of the second-best quality; it is equipped with device protocol mapping tools to map the planning scheme to the underlying service logic; and it is equipped with reverse verification prompts to verify from the bottom up whether the generated result meets the top-level quality intention. The service logic synthesis agent is equipped with a physical conflict detection tool to determine whether there is a hardware resource contention conflict between the underlying service logics; it is also equipped with an environmental awareness tool to verify the real-time online status of physical devices. If a device is offline, a self-healing mechanism is triggered to backtrack along alternative related branches, switch in real time, and modify the service logic. The three intelligent agents follow the following cooperation mechanism: the functional implementation intelligent agent and the quality implementation intelligent agent are independent of each other in the shared workspace and can be executed in parallel or serially; if the service logic synthesis intelligent agent detects a conflict during synthesis, it will explicitly feed back the conflict information to the functional implementation intelligent agent to drive it to collaboratively refine and reimplement the functional requirement branches at the conflict point. The convergence condition for the collaboration mechanism is set as follows: the synthesized three-layer demand model has no conflict or reaches the preset maximum number of iterations.

2. The IoT service logic automatic generation system according to claim 1, characterized in that, The three-layer demand model is specifically a bidirectional demand traceability tree data structure, which is a multi-layered directed tree structure containing nodes and edges, wherein: The nodes include the intent layer node at the top level, the planning layer node in the middle level, and the rule layer node at the bottom level. The intent layer nodes include functional intent nodes and quality intent nodes, used to represent device-independent high-level objectives; The planning layer node is used to represent a logical planning scheme for a given intention, and convert the high-level intention into a causal expression of abstract devices; The rule layer node is used to represent the specific device scheduling rules for a given logical planning scheme, and convert the planning scheme into the service logic of specific Internet of Things devices; The edges include: AND decomposition edges: Used to represent the dependency relationship of combined calls of multiple physical hardware that need to be jointly executed in the physical space to achieve the same goal; OR decomposition edges: As a specific representation form of the alternative association branch, used to represent different hardware combination alternatives for achieving the same goal.

3. A method for automatically generating IoT service logic applied to the system described in claim 1, characterized in that, The method includes the following steps: S1. Construction of the function requirement realization agent: The function realization agent decomposes the function intention input by the user, maps it to abstract devices, generates a logical planning scheme, and then converts it into the corresponding underlying service logic. A function requirement branch is constructed in the three-layer requirement model, and a satisfaction check guided by a large model is performed on the generated result; S2. Construction of the quality requirement realization agent: The quality realization agent instantiates the quality intention based on the real-time environment assessment, generates the corresponding logical planning scheme and underlying service logic. A quality requirement branch is constructed in the three-layer requirement model, and a satisfaction check guided by a large model is performed on the generated result; S3. Construction of the service logic synthesis agent: The service logic synthesis agent synthesizes the function requirement branch and the quality requirement branch; performs conflict detection after synthesis. If there is a conflict, it feeds back to the function realization agent for collaborative refinement; after there is no logical conflict, extracts the service logic scheme and performs a physical environment availability check. If the environment is unavailable, the self-healing mechanism is executed based on the alternative association branch to modify the three-layer requirement model; Among them, S1 and S2 are independent of each other and can be executed in parallel or serially in any order; in S3, if the service logic synthesis agent detects a conflict in the synthesized three-layer requirement model, then explicitly feeds back the conflict information to the function realization agent to collaboratively modify and re-implement the function requirement branch; the convergence condition of the collaboration mechanism is set to that there is no conflict in the synthesized three-layer requirement model or the preset maximum number of iterations is reached.

4. The method for automatically generating IoT service logic according to claim 3, characterized in that, S1 specifically includes: S1-1. Intention decomposition: Receives the original function requirement input by the user as input, designs prompt words to guide the large model to decompose it into multiple indivisible atomic intentions; during the decomposition process, the system presets an intention template with atomic granularity properties. The granularity properties require that the atomic intention must have a substantial physical impact on external environmental entities and be the smallest semantic unit that is logically indivisible, specifically covering single-step causal trigger rules, absolute action instructions, and single state constraints; by constructing prompt words that include the granularity property requirements and template format specifications, guiding the large model to accurately disassemble the user intention and fill it into the corresponding intention template, so as to ensure the standardization of the decomposition result; S1-2, Intent Implementation Design: When mapping atomic intents to logical plans, the built-in environment awareness tool is invoked to obtain the set of abstract functional device states in the current IoT environment; abstract functional devices in the current environment that are in an unavailable state are filtered out, and at least one logical plan scheme is generated by combining them. S1-3, Service Logic Generation: When mapping the logical planning scheme to the service logic of a specific IoT device, the built-in device protocol mapping tool is called to map the abstract planning instructions to the underlying protocol code that can be executed by the target physical device, so as to form the underlying service logic. S1-4 Satisfaction Check: A bottom-up reverse verification mechanism is adopted. The generated initial functional branch is used as input and the output is the verified functional branch. The large model guides the check to see whether the underlying service logic and the intermediate planning scheme truly satisfy the top-level functional intent in the current environment. If not, it returns to S1-1 to regenerate.

5. The method for automatically generating IoT service logic according to claim 3, characterized in that, S2 specifically includes: S2-1, Environmental Assessment and Intent Generation: The built-in environmental perception tool is invoked to obtain the specific devices in the current IoT environment, and the preset quality template is instantiated into quality intent and logical planning scheme. The agent will assess whether the current environmental resources can realize the preset quality template. If the environmental resources are limited and the realization fails, the degradation reasoning mechanism is triggered. The preset quality template is used as the starting point for dynamic modification, and a suboptimal quality intent and planning scheme that matches the current resources is inferred. S2-2, Service Logic Generation: When mapping the planning scheme to the service logic of specific IoT devices, the built-in device protocol mapping tool is called to map the abstract planning instructions to the underlying protocol code that can be executed by the target physical device, so as to form the underlying service logic. S2-3 Satisfaction Check: A bottom-up reverse verification mechanism is adopted. The generated initial quality branch is used as input and the output is the verified quality branch. The large model guides the check to see whether the underlying service logic and the intermediate planning scheme truly satisfy the top-level quality intent in the current environment. If not, it returns to S2-1 for forced degradation reasoning.

6. The method for automatically generating IoT service logic according to claim 3, characterized in that, S3 specifically includes: S3-1, Branch Synthesis: Read the functional requirement branches and quality requirement branches in the workspace, associate them at the top level of the model, and synthesize a unified three-layer requirement model; during the synthesis process, identify duplicate service logic and perform logic fusion to remove duplicates; S3-2, Conflict Detection: Perform physical conflict detection on the synthesized three-layer requirement model to determine whether there is a conflict of hardware resource contention between the underlying service logics; if a conflict exists, the conflict information is fed back to the functional implementation agent, which re-plans the generation logic for the conflict point, eliminates the conflict through cooperation between agents, and finally generates a conflict-free three-layer requirement model. S3-3, Solution Extraction: Taking a conflict-free three-layer requirement model as input, extract all service logic and output as a deployable underlying physical control script; the agent calls the built-in environmental awareness tool to verify the real-time online status of physical devices. If the device is found to be offline, causing the solution to be unavailable, the self-healing mechanism is immediately triggered. The agent backtracks along the unavailable service logic to the nearest alternative related branch, automatically switches to other alternative solutions available in other environments, and re-extracts the script; if it is still unavailable after backtracking through all alternative related branches, a global execution failure warning is thrown.

Images