Building equipment management method and device, storage medium and electronic device

Abstract

The application discloses a building equipment management method and device, a storage medium and an electronic device. The method comprises the following steps: determining a task difficulty mode corresponding to user input information; determining a target processing path matched with the task difficulty mode from a preset processing path set; when the target processing path is a model processing path, executing a corresponding building equipment management task according to the user input information based on a created target state machine instance, and the target state machine instance is configured to call an inference node and a tool node to execute at least one round of inference and tool calling operation based on a preset node flow transfer cycle rule; and when the target processing path is a rule processing path, calling and executing a tool corresponding to the user input information from an equipment management tool library based on a preset tool calling rule to execute the corresponding building equipment management task. The method can realize the management of the building equipment without relying on a fixed command mode, and effectively improves the management reliability and accuracy.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more particularly to a building equipment management method, apparatus, storage medium, and electronic device in the field of artificial intelligence technology. Background Technology

[0002] With the rapid development of IoT and AI technologies, the functions of intelligent building management systems are becoming increasingly diverse. An intelligent building management system is an integrated management and control platform built upon IoT sensing devices, building terminal execution hardware, and cloud-based scheduling computing power. It has multiple management functions such as environmental monitoring, equipment control, and meeting scheduling, enabling unified monitoring, scheduling, and automated management of electromechanical equipment such as air conditioning, lighting, meeting rooms, security, and ventilation within the building.

[0003] Traditional intelligent building management systems use a fixed command model for device management. This means users need to memorize specific commands (such as "SET A101 TEMP 25") to perform device queries or control operations. These commands are standardized instructions that strictly adhere to fixed syntax, device numbers, and parameter order. This fixed command model has a high learning curve, is only suitable for professionals, and is prone to errors such as incorrect command order, missing parameters, or format discrepancies, leading to command failures. Summary of the Invention

[0004] This application provides a building equipment management method, apparatus, storage medium, and electronic device, which can manage equipment without relying on a fixed command pattern, effectively improving management reliability and accuracy. The above technical solution is as follows: In a first aspect, embodiments of this application provide a building equipment management method, the method comprising: In response to the received user input information, determine the task difficulty mode corresponding to the user input information; Determine the target processing path that matches the task difficulty mode from the preset set of processing paths; When the target processing path is the model processing path, based on the created target state machine instance, the corresponding building equipment management task is executed according to the user input information. The target state machine instance is configured to call the inference node and tool node to perform at least one round of inference and tool call operation based on the preset node flow loop rules. The inference node is configured to call the target large language model to perform semantic inference and instruction generation. The tool node is configured to call and execute the tools in the preset equipment management tool library. When the target processing path is a rule processing path, based on the preset tool invocation rules, the tool corresponding to the user input information is invoked and executed from the device management tool library to perform the corresponding building equipment management task.

[0005] In conjunction with the first aspect, in some possible implementations, the step of executing corresponding building equipment management tasks based on the user input information, according to the created target state machine instance, includes: Based on the created target state machine instance, the target large language model is invoked through the inference node to perform semantic reasoning and instruction generation based on the user input information, so as to obtain the tool invocation instruction; Through the tool node, the tool corresponding to the tool call instruction is called and executed from the preset device management tool library to complete a round of reasoning and tool call operation; The execution result of the tool node is sent back to the inference node, so that the inference node calls the target large language model to determine whether it is necessary to continue calling the tool. When it is determined that it is necessary to continue calling the tool, the next round of inference and tool calling operation is performed through the inference node and the tool node.

[0006] In conjunction with the first aspect, in some possible implementations, the step of invoking the target large language model through the inference node to perform semantic reasoning and instruction generation based on the user input information to obtain tool invocation instructions includes: Through the inference node, model input information is generated based on the user input information and preset tooltips; The model input information is input into the target large language model for processing, so that the target large language model can determine whether a tool needs to be called, and when it is determined that a tool needs to be called, a corresponding tool call instruction is generated.

[0007] In conjunction with the first aspect, in some possible implementations, the step of invoking the target large language model through the inference node to perform semantic reasoning and instruction generation based on the user input information to obtain tool invocation instructions includes: Based on the preset scheduling scoring function and the user input information, the scheduling score of each tool in the device management tool library is determined through the inference node. The target large language model is invoked, and the scheduling score is used to determine whether a tool needs to be invoked. If it is determined that a tool needs to be invoked, a corresponding tool invocation instruction is generated.

[0008] In conjunction with the first aspect, in some possible implementations, the step of calling and executing the tool corresponding to the tool call instruction from a preset device management tool library via the tool node includes: The tool node is used to parse the tool invocation command to extract the tool identifier and the first parameter; The system queries a preset device management tool library for a first target tool that matches the tool identifier, and runs the tool function of the first target tool based on the first parameter.

[0009] In conjunction with the first aspect, in some possible implementations, the preset tool invocation rules include tool keyword groups and parameter extraction templates for each tool. The step of invoking and executing the tool corresponding to the user input information from the device management tool library based on the preset tool invocation rules includes: The user input information and the keyword groups of each tool are matched with keywords, and the tool corresponding to the matching keyword group is used as the second target tool; The second parameter is obtained by extracting parameters from the user input information using the parameter extraction template of the second target tool. The tool function that runs the second target tool based on the second parameter.

[0010] In conjunction with the first aspect, in some possible implementations, the method further includes: Each time a building equipment management task is completed, the corresponding task information is stored in the equipment management log. In response to a pattern mining instruction for the device management logs, determine device management patterns and / or user preference patterns based on the device management logs; Based on the aforementioned equipment management rules and / or user preference rules, control the management operations of the corresponding building equipment.

[0011] In conjunction with the first aspect, in some possible implementations, after each inference node invokes the target large language model, the method further includes: Based on the preset model health scoring rules, the current health score of the target large language model is updated according to the result of this call. The model health scoring rules include a score decay function and a score increment function. When the health score is lower than the preset score or the call result indicates that the call failed, the candidate large language model with the highest health score is selected from the preset candidate large language model library, and the current target large language model is switched to the selected candidate large language model.

[0012] Secondly, embodiments of this application provide a building equipment management device, the device comprising: The first determining unit is configured to determine the task difficulty mode corresponding to the received user input information in response to the received user input information. The second determining unit is used to determine a target processing path that matches the task difficulty mode from a preset set of processing paths; The first execution unit is used to execute corresponding building equipment management tasks based on the user input information, according to the created target state machine instance, when the target processing path is the model processing path. The target state machine instance is configured to call inference nodes and tool nodes to perform at least one round of inference and tool call operations based on preset node flow loop rules. The inference node is configured to call the target large language model for semantic inference and instruction generation. The tool node is configured to call and execute tools in the preset equipment management tool library. The second execution unit is used to, when the target processing path is a rule processing path, call and execute the tool corresponding to the user input information from the device management tool library based on the preset tool call rule, so as to perform the corresponding building equipment management task.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory; The processor is connected to the memory. The aforementioned memory is used to store executable program code; The processor reads the executable program code stored in the memory to run the program corresponding to the executable program code, so as to execute the method provided by the first aspect of the embodiments of this application or any possible implementation of the first aspect.

[0014] Fourthly, embodiments of this application provide a computer storage medium storing a plurality of instructions, which are adapted to be loaded by a processor and executed by the method steps provided in the first aspect of the embodiments of this application or any possible implementation thereof.

[0015] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to execute the method steps provided by the first aspect of the embodiments of this application or any possible implementation thereof.

[0016] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: In one or more embodiments of this application, on the one hand, by designing differentiated dedicated processing paths for different task difficulties in advance, lightweight rule processing paths are designed for simple tasks, and model processing paths that rely on large model inference operations are designed for complex tasks. This enables differentiated processing of building equipment management tasks of different difficulties, ensuring low latency and high throughput execution efficiency for simple tasks while ensuring the execution reliability of complex tasks. On the other hand, by relying on the semantic reasoning and generation capabilities of large language models in the model processing path, and combining state machine instances for automated multi-round loop interaction, branching flow, and iterative scheduling mechanisms between inference nodes and tool nodes, the dependence on fixed command patterns is eliminated. This enables automatic decomposition, step arrangement, and tool iterative invocation of complex building equipment management tasks, effectively improving the execution accuracy, completion rate, and system robustness of complex tasks under multiple constraints.

[0017] The above description is merely an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 An exemplary system architecture diagram of a building equipment management method provided for an exemplary embodiment of this application; Figure 2 A flowchart illustrating a building equipment management method provided for an exemplary embodiment of this application; Figure 3 A schematic diagram of the framework structure of an intelligent building management and control platform provided for an exemplary embodiment of this application; Figure 4 A flowchart illustrating another building equipment management method provided as an exemplary embodiment of this application; Figure 5 A schematic diagram of the processing flow of the model processing path provided for an exemplary embodiment of this application; Figure 6 A schematic diagram of the structure of a building equipment management device provided for an exemplary embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. Detailed Implementation

[0020] To make the features and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The terms "first," "second," "third," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0022] This application provides a building equipment management method, apparatus, electronic device, storage medium, and computer program product.

[0023] Please refer to Figure 1 , Figure 1 An exemplary system architecture diagram of a building equipment management method provided for an exemplary embodiment of this application is shown. Figure 1 As shown, the system architecture may include a platform server 101, a network 102, and a lower-level control system 103. The platform server 101 is the server of the target management platform, and the lower-level control system 103 is used to control the terminal devices accessing the target management platform. The network 102 is used to provide a communication link between the platform server 101 and the lower-level control system 103. The network 102 may include various types of wireless communication links and wired communication links. The wireless communication links include Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, etc., and the wired communication links include Controller Area Network (CAN), LIN bus, FlexRay bus, MOST bus, and Ethernet bus, etc.

[0024] Specifically, the platform server 101 interacts with the underlying control system 103 via network 102, receiving various messages from and sending relevant instructions and data to the underlying control system 103. The underlying control system 103 can collect user input information such as voice and text and send it to the platform server 101, and can also receive and execute control instructions issued by the platform server 101. The platform server 101 is used to execute the following processes: In response to received user input, the system determines the task difficulty mode (e.g., simple or complex task) corresponding to the user input. It then selects a target processing path from a pre-defined set of processing paths that matches the task difficulty mode. When the target processing path is a model processing path, it invokes a target state machine instance to execute the corresponding building equipment management task (e.g., querying building ambient temperature and humidity, or raising the building air conditioning temperature) based on the user input. This target state machine instance is configured to invoke inference nodes and tool nodes based on pre-defined node flow loop rules to perform at least one round of inference and tool invocation operations. The inference node is configured to invoke the target large language model for semantic inference and instruction generation, and the tool node is configured to invoke and execute tools from a pre-defined equipment management tool library. When the target processing path is a rule-based processing path, it invokes and executes the tool corresponding to the user input based on pre-defined tool invocation rules from the equipment management tool library to perform the corresponding building equipment management task.

[0025] Understandably, Figure 1 The number and type of platform server 101, network 102 and underlying control system 103 in the system architecture shown are only examples. In specific implementations, any number of platform servers 101, network 102 and underlying control system 103 may be included. This specification does not specifically limit this.

[0026] Based on the above system architecture, this application provides a building equipment management method. Please refer to... Figure 2 and Figure 3 , Figure 2 This is a flowchart illustrating a building equipment management method as an exemplary embodiment of this application. Figure 3This is a schematic diagram of the framework structure of an intelligent building management platform provided as an exemplary embodiment of this application. The executing entity of the building equipment management method can be the platform server in the above system architecture. The platform server can be the server of the intelligent building management platform. The intelligent building management platform can manage the various terminal devices (building equipment) connected to the platform. The terminal devices include, but are not limited to: supporting equipment in each office area of ​​the building, including but not limited to office computers, central air conditioning, lighting fixtures, fresh air systems, security access control and monitoring equipment, etc.; supporting equipment in each conference room, including but not limited to conference room central control terminals, voice interactive speakers, projectors, conference screens, etc.; environmental data acquisition equipment, including but not limited to various sensing devices such as environmental temperature sensors, humidity sensors, and air quality sensors.

[0027] Specifically, the building equipment management method includes the following steps S201-S204, wherein: S201. In response to the received user input information, determine the task difficulty mode corresponding to the user input information.

[0028] User input information refers to natural language information entered by the user through a terminal device, which can be expressed in various modalities such as speech and text, for example... Figure 3 In this process, users can input voice commands via voice interaction or text commands via text boxes in the user interface. These inputs are then transmitted to the platform server for processing. The platform server serves as the hardware execution carrier for this method and can internally deploy at least three types of independent logical functional modules: the main intelligent agent, the mining intelligent agent, and the device management intelligent agent. Each type of intelligent agent operates independently, performs its respective duties, and cooperates with the platform server's computing power and storage resources to complete the entire chain of business operations, including underlying device control and historical log pattern mining.

[0029] The task difficulty mode is used to characterize the semantic understanding complexity, parameter complexity, and execution chain complexity of user input commands. Optionally, the task difficulty mode includes at least two modes: simple task mode and complex task mode. The simple task mode is suitable for tasks with clear semantics, single parameters, no task decomposition required, and which can be completed with a single tool call. Such tasks include, but are not limited to: device status query, environmental parameter query, and simple single-device adjustment. The complex task mode is suitable for combined tasks with multiple constraints, complex semantics, and multi-dimensional restrictions or multi-device linkage requirements. These tasks require semantic decomposition and iterative execution through multiple tool calls. Such tasks include, but are not limited to: meeting room booking with multiple filtering conditions (covering the entire process of meeting room query, filtering, recommendation, and booking), intelligent multi-device linkage control, and adaptive parameter adjustment based on multi-dimensional environmental data.

[0030] Specifically, the task difficulty mode can be identified based on preset mode determination rules or through a trained classification model, which is not limited herein. The identification and determination of the task difficulty mode generally follows the following core principles: when the user input information contains clear tool keywords with complete parameters, it is determined as the simple task mode; when the user input information contains complex logic (such as a combination of elements including time, number of people, equipment requirements, etc.) or recommendation-related words (such as keywords like "recommend", "help me", "how", etc.), it is determined as the difficult task mode; fallback rule: except for the above explicit scenarios, other cases are default determined as the complex task mode, so as to ensure the instruction understanding accuracy in complex and fuzzy semantic scenarios.

[0031] For example, if the user input information is: help me book a conference room that can accommodate 10 people and is equipped with a projector from 2 p.m. to 4 p.m. tomorrow, then due to the multi-element combination of time, number of people and equipment requirements, it can be determined as the complex task mode. If the user input information is: adjust the temperature of A101 to 24 degrees Celsius, or turn on the light of A101, it has the basic call information of a single tool: object, action and parameter, so it can be determined as the simple task mode.

[0032] S202. Determine the target processing path matching the task difficulty mode from a preset processing path set.

[0033] Wherein, different task difficulty modes can be configured with different processing paths, and different processing paths correspond to different task parsing and tool scheduling logics. A one-to-one mapping matching relationship between task difficulty modes and processing paths can be established in advance, and subsequently in the actual task execution process, an adapted processing path is selected as the target processing path based on the mapping matching relationship, so as to implement differentiated processing for tasks of different difficulties.

[0034] Optionally, the processing path set at least includes a rule processing path corresponding to the simple task mode, and a model processing path corresponding to the complex task mode. Wherein, the rule processing path mainly completes tool selection and parameter parsing relying on fixed rules, does not require large language model inference, can quickly respond to simple tasks with fixed sentence patterns, clear parameters and single scenarios, and has the characteristics of low latency, high stability and low computing power consumption. The model processing path mainly relies on the semantic understanding and generation capabilities of large language models, can be adapted to complex tasks with flexible sentence patterns, multiple constraints and requirements for linked execution of multiple tools, and has stronger semantic generalization capability and complex scenario adaptation capability.

[0035] S203. When the target processing path is the model processing path, based on the created target state machine instance, execute the corresponding building equipment management task according to the user input information. The target state machine instance is configured to call the inference node and tool node to perform at least one round of inference and tool call operation based on the preset node flow loop rules. The inference node is configured to call the target large language model to perform semantic inference and instruction generation. The tool node is configured to call and execute the tools in the preset equipment management tool library.

[0036] The target state machine instance is a process control program that leverages the conditional transitions, state switching, and iterative loop capabilities of state machines to achieve intelligent task orchestration and execution. It enables automatic task breakdown, step orchestration, branch jumps, and multi-round tool iteration calls for complex tasks. The preset node flow loop rule is the core scheduling constraint rule of the state machine, used to clarify the execution order between inference nodes and tool nodes, branch flow triggering conditions, loop retry mechanisms, and task termination judgment logic, ensuring that complex tasks can stably achieve at least one round of "inference-tool call" closed-loop iteration. The instructions generated by the target large language model are standardized tool call instructions. The core fields carried by these instructions include: the tool identifier of the tool to be called (e.g., tool name), the device operation type, and the execution input parameters. For example, for an air conditioning control tool, the device operation type could be temperature adjustment, and the execution input parameters could be specific temperature values, adjustment modes, and other control parameters.

[0037] Optionally, there are two deployment options for the target state machine instance: one is to build it from scratch based on a self-developed native state machine framework, which allows for deep customization of scheduling logic; the other is to reuse mature open-source / commercial frameworks for rapid development and delivery, adapting to different project development cycles and deployment environments. Optional frameworks include, but are not limited to, Stateflow and StateMachine.

[0038] The equipment management toolkit can be configured to cover all scenarios based on the type of equipment connected to the building platform, equipment functions, data processing requirements, and operation and maintenance management needs. Figure 3 The tools shown include meeting room scheduling recommendation tools, meeting room query and reservation tools, preference and pattern update tools, and preference and pattern query tools. Among these, each tool in the equipment management tool library is bound to a unique tool function. All tool functions are uniformly encapsulated, standardized in definition, and centrally managed, serving as the underlying functional carrier for realizing building equipment management capabilities through model processing paths and rule processing paths.

[0039] The equipment management toolkit includes at least two types of tools: equipment query tools and equipment control tools. Equipment query tools are used to query equipment operating parameters. For example, an environmental status query tool queries data collected by environmental temperature and humidity sensors; an equipment operating status query tool queries operating parameters such as start / stop, operating speed, and fault status of electromechanical equipment like air conditioners, lighting fixtures, and fresh air systems; and a meeting room occupancy query tool queries recorded data from the meeting room control terminal to determine meeting room usage status and reservation status. Equipment control tools are used to adjust equipment operating parameters, such as adjusting air conditioning temperature, switching lighting fixtures on and off, and starting / stopping meeting room audio-visual equipment.

[0040] S204. When the target processing path is a rule processing path, based on the preset tool call rule, the tool corresponding to the user input information is called and executed from the device management tool library to perform the corresponding building equipment management task.

[0041] The preset tool invocation rules are pre-configured static business rules that do not require large-scale model inference. They are configured with tool matching rules and parameter extraction rules for each tool in the equipment management tool library, and are used to complete tool matching and parameter extraction processing in a layered manner. After tool matching and parameter parsing are completed, the tool function of the corresponding tool is called and the extracted valid parameters are substituted to generate standardized equipment control commands. The commands are then sent to the underlying control system, which drives the corresponding operations to be performed on the building equipment.

[0042] Furthermore, in some embodiments, the building equipment management method further includes: Each time a building equipment management task is completed, the corresponding task information is stored in the equipment management log. In response to a pattern mining command targeting the device management log, determine device management patterns and / or user preference patterns based on the device management log; Based on the management rules of the equipment and / or the user preference rules, control the management and operation of the corresponding building equipment.

[0043] Please continue to see Figure 3After each management task is completed, the main AI will collect all the complete task information and write it to the device management log in the database. The device management log will retain all interaction data, including historical periodic patterns, user preference records, and historical tool call records, as the data base for pattern mining. When a pattern mining command is triggered (e.g., user-initiated or system-automatically triggered periodically), the mining AI will read all historical task sequence data from the device management log and perform two types of pattern mining operations in parallel: periodic pattern discovery and user preference discovery. Periodic pattern discovery is used to extract recurring periodic device control requests from the log to generate device management periodic patterns; preference discovery is used to extract device operation habits and tool selection preferences formed by users over a long period of use to generate user preference patterns.

[0044] After completing the pattern mining operation, the results can be output and verified with the user. If the verification confirms that valid equipment management cycle patterns and user preference patterns have been obtained, the two types of pattern data are synchronously written back to the equipment management log and pushed to the platform's main intelligent agent. After receiving the mined cycle patterns and user preference patterns, the platform's main intelligent agent prioritizes reading the stored historical cycle pattern and user preference pattern records when receiving new voice / text commands from the user and when performing task difficulty analysis and processing path selection. If it recognizes that the current user's needs match an existing cycle pattern, it can directly reuse the corresponding historical equipment management solution to complete tool scheduling and equipment control. At the same time, it prioritizes matching the equipment management tools and parameter configurations that the user is accustomed to using, without repeating the complete reasoning or rule matching process. It directly outputs a natural voice response and issues control commands to automatically complete the management operation of the corresponding building equipment, simplifying the single task processing link and improving the equipment management response efficiency.

[0045] As described above, the building equipment management method provided in this embodiment determines the task difficulty mode corresponding to the received user input information in response to the user input information, and determines the target processing path matching the task difficulty mode from a preset set of processing paths. Then, when the target processing path is a model processing path, the created target state machine instance is invoked to execute the corresponding building equipment management task according to the user input information. The target state machine instance is configured to invoke inference nodes and tool nodes to perform at least one round of inference and tool invocation operations based on preset node flow loop rules. The inference node is configured to invoke the target large language model for semantic inference and instruction generation, and the tool node is configured to invoke and execute tools in the preset equipment management tool library. When the target processing path is a rule processing path, the tool corresponding to the user input information is invoked and executed from the equipment management tool library based on preset tool invocation rules to execute the corresponding building equipment management task. In other words, on the one hand, by designing differentiated processing paths for different task difficulties in advance, lightweight rule processing paths are designed for simple tasks, while model processing paths that rely on large model inference operations are designed for complex tasks. This enables differentiated processing of building equipment management tasks of varying difficulty, ensuring low latency and high throughput execution efficiency for simple tasks while ensuring the execution reliability of complex tasks. On the other hand, by relying on the semantic reasoning and generation capabilities of large language models in the model processing path, and combining state machine instances with automated multi-round loop interaction, branching flow, and iterative scheduling mechanisms for inference nodes and tool nodes, the dependence on fixed command patterns is eliminated. This enables the automatic decomposition, step arrangement, and iterative tool invocation of complex building equipment management tasks, effectively improving the execution accuracy, completion rate, and system robustness of complex tasks under multiple constraints.

[0046] Based on the building equipment management method described in the above embodiments, please refer to Figure 4 , Figure 4 This is a flowchart illustrating another building equipment management method provided as an exemplary embodiment of this application. The building equipment management method specifically includes the following steps S301-S307, wherein: S301. In response to the received user input information, determine the task difficulty mode corresponding to the user input information.

[0047] S302. Determine the target processing path that matches the difficulty mode of the task from the preset set of processing paths.

[0048] The steps S301-S302 and S201-S202 are the same as those described above, and will not be repeated here.

[0049] S303. When the target processing path is the model processing path, based on the created target state machine instance, the target large language model is called through the inference node to perform semantic reasoning and instruction generation based on the user input information, so as to obtain the tool call instruction.

[0050] Please see below. Figure 5 , Figure 5 This is a schematic diagram of the processing flow of the model processing path provided for an exemplary embodiment of this application. Figure 5 The system uses a LangGraph state machine as the target state machine instance. The LangGraph workflow relies on a unified session state to complete the entire data flow and management. Agent nodes are inference nodes, and Tools nodes are tool nodes. LangGraph is responsible for maintaining and updating the global session state throughout the process. The global session state is used to uniformly store all interaction data, including original user input, real-time model inference output, tool call trigger events, tool execution return data, and historical dialogue context. All nodes read and write the same state instance for their input and output data, effectively ensuring that data is not lost and the context logic remains coherent during multi-round loop inference, achieving end-to-end data persistence.

[0051] Specifically, users interact using natural language through the system's execution engine, which collects user input. Once the system selects a model processing path based on the user input, it first initializes the session state. This initialized state carries the original user input, an empty historical context, and the system's initial runtime configuration. This session state is then passed to the LangGraph workflow, driving the inference node to initiate the first round of inference using the target large language model. During inference, the target large language model continuously generates incremental token text (i.e., fragmented content such as words and short sentences output in a single instance). Utilizing the workflow's built-in streaming output mechanism, this incremental token text is pushed to the front end in real-time for dynamic display. Simultaneously, the inference node parses the model's output in real-time. Once a tool identifier (such as a tool name) is identified, the corresponding parameters are extracted and encapsulated into standardized tool call instructions recognizable by the workflow, completing the semantic inference and instruction generation operations for a single inference node.

[0052] It's important to note that this streaming output mechanism is a built-in, proprietary interactive capability of the LangGraph workflow. It eliminates the need to wait for the large language model to complete full inference and generate complete results before outputting them uniformly. Instead, it can break down and generate fragmented response content segment by segment during the model's real-time inference computation. For more details, please refer to... Figure 5The system continuously monitors various output events from the state machine's dedicated output stream and executes differentiated push logic for different types of output events: For incremental token text generated by the model, it is pushed to the front end for display immediately without buffering after each incremental content segment is generated; for tool invocation start events, only summary information such as the tool name and key core parameters is pushed to the front end, along with an interactive prompt to inform the user of the current tool invocation progress, while shielding lengthy raw tool data; for tool execution result events, the result data is automatically cached to the global session state, providing data support for subsequent multi-round iterative inference of the model; for process completion events, a task completion marker is simultaneously pushed to the front end, along with complete statistical information such as task time and token usage. Simultaneously, this streaming output mechanism supports immediate push of abnormal error information without waiting for the overall process to finish. Compared to traditional batch output modes, this mechanism completely solves the problems of latency and lag, allowing users to view segmented response content in real time without waiting for the entire process to complete, significantly improving the real-time performance and smoothness of human-computer interaction.

[0053] Furthermore, the above step of "calling the target large language model through the inference node to perform semantic reasoning and instruction generation based on the user input information to obtain tool invocation instructions" specifically includes: The inference node generates model input information based on the user input and preset tooltips. The input information of the model is fed into the target large language model for processing, so that the target large language model can determine whether a tool needs to be called, and when it is determined that a tool needs to be called, the corresponding tool call instruction is generated.

[0054] The inference node combines user input with preset tooltips to generate complete model input information, which is then fed into the target large language model. The large language model then autonomously determines whether the current task requires tool invocation and outputs standardized tool invocation commands. The preset tooltips comprehensively include the functional descriptions, input / output parameter specifications, applicable business scenarios, and other unified usage constraints of all tools in the device management tool library, providing a benchmark for the large language model to identify tools and make invocation logic judgments.

[0055] In other embodiments, the above step "calling the target large language model through the inference node to perform semantic reasoning and instruction generation based on the user input information to obtain tool invocation instructions" specifically includes: Based on the preset scheduling scoring function and the user input information, the scheduling score of each tool in the device management tool library is determined by the inference node. The target large language model is invoked, and the scheduling score determines whether a tool needs to be invoked. If it is determined that a tool needs to be invoked, the corresponding tool invocation instruction is generated.

[0056] The inference node first relies on a preset scheduling scoring function, combined with user input information, to comprehensively calculate the scheduling score of each tool in the device management tool library from three dimensions: The first dimension is the semantic relevance between the tool and the current user task, which can be obtained through text semantic similarity quantification. There are two quantification methods: one is rule matching, which uses keyword matching, regular expression matching, and the overlap between the tool's function description and the user's input text to weighted scores, resulting in a relevance score; the other is training a model to directly determine the relevance score between each tool and the user's input information. The second dimension is the tool's historical execution success rate, which can be calculated as the ratio of the number of successful calls to the total number of calls in the historical runtime of the corresponding tool, and then linearly mapped to the 0-1 range as the basis for tool stability scoring. The higher the tool's historical success rate, the higher the corresponding score. The third dimension is the tool's average response time. This is calculated by statistically analyzing the execution time of each single call in the tool's entire historical record, taking the arithmetic mean to obtain the tool's own average response time, then statistically analyzing the average time of all tools in the device management tool library, extracting the global maximum average time as a benchmark, and calculating the average response time using an inverse normalization formula. The calculation result automatically converges to the 0-1 range. The shorter the tool's average time, the higher the final response time score, thus quantifying the tool's execution response efficiency.

[0057] Specifically, the preset scheduling scoring function can adopt a weighted summation form, fusing three indicators with fixed weights to obtain the final scheduling score. For example, the preset scheduling scoring function can be: Scheduling Score = 0.5 × Relevance + 0.3 × Historical Execution Success Rate + 0.2 × Historical Response Speed. After calculation, the scheduling scores corresponding to all tools and the basic description information of the tools are sent as auxiliary context to the target large language model. The large language model has a built-in score judgment threshold and automatically filters the candidate tool set whose scheduling scores are higher than the preset threshold, thereby comprehensively judging whether the current task needs to call the tool. If the candidate tool set is empty, it is determined that no tool needs to be called. If the candidate tool set contains a valid tool, it is determined that the tool needs to be called. At this time, the target large language model further generates a tool calling instruction based on the tools in the candidate tool set and the user's task requirements.

[0058] S304. Through the tool node, the tool corresponding to the tool call instruction is called and executed from the preset device management tool library to complete a round of reasoning and tool call operation.

[0059] In some embodiments, step S304 specifically includes: The tool call command is parsed through the tool node to extract the tool identifier and the first parameter; The system queries the preset device management tool library for a first target tool that matches the tool identifier, and runs the tool function of the first target tool based on the first parameter.

[0060] Please continue to see Figure 5 LangGraph monitors the output of inference nodes in real time. Once a tool invocation command is detected, it first pushes a tool start event through the output stream, displaying the name of the tool to be executed and the operation type to the front end, allowing users to keep track of the task's progress. Subsequently, LangGraph schedules the tool node to execute the tool according to the tool invocation command. This involves parsing the tool invocation command to extract the tool identifier and parameters (i.e., the first parameter mentioned above). Then, based on the tool identifier, it accurately matches the corresponding tool (the first target tool) in the device management tool library and runs the tool function of the first target tool based on the first parameter.

[0061] The utility function is a standardized, encapsulated business logic that integrates unified calling rules and adaptation logic for the underlying device service interfaces. When a utility function is triggered, it automatically connects to and calls the underlying device service interfaces to perform corresponding device management operations (such as device data querying and device operating parameter adjustment). After the underlying device service completes its operation, it returns the tool execution result data to the utility node. Upon receiving the returned data, the utility node synchronously writes the data to the global session state of LangGraph and simultaneously pushes the tool execution result and running status (tool execution result event) to the front end via the output stream. At this point, the entire linkage process between semantic reasoning at the inference node and tool execution at the utility node is completed, forming a complete inference-tool call closed loop.

[0062] S305. The execution result of the tool node is sent back to the inference node so that the inference node calls the target large language model to determine whether it is necessary to continue calling the tool. When it is determined that it is necessary to continue calling the tool, the next round of inference and tool calling operation is performed through the inference node and the tool node.

[0063] After each update of the global session state, LangGraph automatically synchronizes the latest global session state to the inference node, triggering the target large language model to perform secondary semantic inference. This secondary inference process also utilizes a streaming output mechanism, supporting real-time dynamic display of the inferred content. During secondary inference, the target large language model, based on the latest global session state, determines whether the current task requires further tool invocation. If the model determines that tool invocation is necessary, the aforementioned inference-tool invocation closed-loop process is repeated. The inference node generates a new tool invocation command based on the latest session state, and the tool node then invokes the corresponding tool to perform device management operations. After execution, the results are returned and the session state is updated, thus achieving multi-round iterative inference and tool invocation.

[0064] Furthermore, if the model determines that it is no longer necessary to call the tool, the execution of the target state machine instance can be terminated, the inference and tool call loop logic of the state machine can be terminated, and at the same time, the target large language model can be called to integrate all historical dialogues, inference content and tool execution data in the global session state, sort out and generate a logically complete and comprehensive final response result, and push the final response result and task completion mark to the front end together to complete the background processing flow of the entire round of device management tasks.

[0065] After the background task is completed, the system can visually display the final response result to the user based on a preset front-end display strategy. This preset front-end display strategy consists of pre-defined multimodal display rules that support various interactive display formats, including text and voice display. The preset front-end display strategy adapts to user interaction scenarios, allowing it to use either the system's default display method or the user's original input method. For example, if the user inputs information via voice, the final response result will be displayed primarily as a voice message; if the user inputs information via text, the final response result will be displayed as a text pop-up by default, ensuring consistency between input and output interaction modalities and improving the user experience.

[0066] It's easy to understand that during system startup, the initialization phase requires the creation of the target state machine instance, the selection of the target large language model, and the registration and binding of utility functions. The complete system initialization process consists of the following four steps: 1. Global configuration loading: The system reads the local configuration file and completes the loading of all parameters. The parameters cover the list of accessible large language models, configuration of various model abstract call interfaces, basic information of tool registry, system running performance thresholds and other core running parameters. The configuration file synchronously records the priority order of the preferred large language model and the backup large language model.

[0067] 2. Key Security Module Initialization and Target Large Language Model Selection: The built-in key manager is started, and the authentication keys of all large language models are read from the encrypted secure storage medium. The key validity verification and de-identification processing are completed automatically to avoid the risk of plaintext key leakage.

[0068] The key verification during the initialization phase employs a tiered and downgraded selection logic: the system prioritizes verifying the key of the preferred large language model specified in the configuration file (the preferred key). If the preferred key passes verification, it is directly used as the target large language model without traversing the backup models. If the preferred key fails verification, the backup large language models are traversed sequentially according to a preset priority, and the key availability is verified one by one. The first backup large language model with a valid key is set as the target large language model. If all model keys fail verification, the system outputs a fault error and terminates the startup process.

[0069] 3. Batch Registration of Tool Functions: Automatically scans all tool function code definitions and, relying on a unified decorator, batch registers various tools to the global tool registry (device management tool library), establishing a one-to-one mapping between tool identifiers and underlying implementation functions (tool functions). The platform pre-configured tool types include at least: environment query tools, equipment control tools (air conditioning, lighting, curtain control), meeting room management tools (meeting room recommendation, reservation, cancellation), user preference management tools (user preference query, user preference update), and periodic pattern management tools (device periodic management pattern query, pattern update).

[0070] The utility functions can be registered using standardized decorators. Each utility function is equipped with complete input / output, exception handling, and security control specifications. Specific constraints are as follows: Standardized Input Parameter Specifications: All utility input parameters are uniformly defined with parameter names, data types, and valid value ranges, and fields are clearly marked as required or optional to ensure consistent parameter parsing; Standardized Output Format Specifications: The tool execution return results consistently include three core fields: execution status code (success / failure), business result dataset, and exception description information, facilitating unified parsing by upper-level processes; Execution Timeout Control: An independent execution timeout threshold is configured for each type of tool. The system default threshold is 5 seconds. Tools exceeding this timeout threshold will be subject to timeout. The system features several safety features: Automatic interruption and timeout error return upon reaching a timeout threshold; Tiered retry fault tolerance strategy: For tools relying on network requests, a maximum of two retries are automatically triggered after execution failure, with the retry interval gradually extended using an exponential backoff strategy to reduce the probability of execution failure caused by instantaneous service fluctuations; Idempotent interface design constraints: All tool functions adhere to idempotent development specifications, ensuring that repeated calls to the same parameters do not generate duplicate business operations, thus avoiding issues such as duplicate device control and duplicate data writing; Pre-access permission verification mechanism: Before the tool officially executes business logic, it verifies the current user's device access and function call permissions. If the verification fails, the tool's execution is directly intercepted and an unauthorized message is returned.

[0071] It should be noted that when the platform adds new device categories or expands its business service capabilities, developers only need to write utility functions for the corresponding business logic and add standardized registration decorators to complete the dynamic registration and launch of tools through a unified interface. The entire process does not require any changes to the core business code of the engine, making tool expansion lightweight and highly compatible.

[0072] 4. Target State Machine Instance Construction and Binding: Create a target state machine instance, and sequentially complete the mounting and deployment of inference nodes and tool nodes, configure the branch jump conditions and loop flow logic between nodes; at the same time, bind the functional descriptions and input parameter specifications of all tools in the tool registry to the large language model to ensure that the model can autonomously identify and match the corresponding tools.

[0073] S306. When the target processing path is a rule processing path, perform keyword matching on the user input information and each tool keyword group in the preset tool call rule, and take the tool corresponding to the matching tool keyword group as the second target tool.

[0074] The rule processing path is a lightweight approach that bypasses large language model inference and relies on pre-defined fixed rules for rapid tool matching, eliminating the need for model semantic inference. This step achieves precise tool routing through a tool keyword traversal and matching mechanism. The system systematically traverses the text content in the user input information and performs comprehensive matching and filtering against various pre-configured tool keyword groups in the preset tool call rules. It accurately hits the keyword group that corresponds to the user's input semantics and operational needs, and finally identifies the device management tool uniquely corresponding to the hit keyword group as the second target tool, quickly completing tool location. This approach offers higher response efficiency compared to model inference methods.

[0075] S307. Extract parameters from the user input information using the parameter extraction template of the second target tool in the preset tool call rules to obtain the second parameter, and run the tool function of the second target tool based on the second parameter.

[0076] After identifying the second target tool, the system retrieves its dedicated preset parameter extraction template. Using the template's built-in regular expression rules, it performs structured parsing and precise extraction of user input information. Through regular expression matching, filtering, and cleaning of valid data fields in the user input text, invalid and redundant content is eliminated, and standardized output of valid input parameter data that meets the tool's operational requirements becomes the second parameter. After parameter extraction and format validation, the system uses the compliant second parameter to drive the corresponding tool function of the second target tool to start and run. This automatically connects to the underlying device service interface, executing device management tasks such as device data querying, parameter adjustment, and status management, thus automating the implementation of user device management needs under the defined rules.

[0077] In addition, to ensure the continuous and stable execution of the model inference task, after each inference node calls the target large language model, the building equipment management method may also include: Based on the preset model health scoring rules, the health score of the current target large language model is updated according to the result of this call. The model health scoring rules include a score decay function and a score increment function. When the health score is lower than the preset score or the call result indicates that the call failed, the candidate large language model with the highest health score is selected from the preset candidate large language model library, and the current target large language model is switched to the selected candidate large language model.

[0078] The system maintains a separate health score for each large language model in the model registration list, with all models' health scores initialized to a baseline of 1.0. The model health scoring rules can be: Each time the call is successful, the health score is updated using a score increment function, for example, health = health × 0.9 + 1.0 × 0.1 (gradually restoring to 1.0); Each time the call fails, the health score is updated using a score decrement function, for example, health = health × 0.9 + 0.0 × 0.1 (gradually decaying to 0.0).

[0079] In other words, the health score is updated using a weighted smooth iteration mechanism to avoid misjudgment due to single fluctuations. This corresponds to two scenarios: successful call and failed call. If the large language model call process is completed normally and returns a valid inference result, the score increment update logic is executed. The original health score is retained with a weight of 0.9, and a full score gain of 0.1 is added, so that the health score can gradually recover to the baseline value of 1.0. If the large language model call fails due to timeout, error, or no valid output, the score decay update logic is executed. Only the historical score with a weight of 0.9 is retained, and no gain value is added, so that the health score continues to gradually decay towards 0.0.

[0080] When the updated health score of the target large language model falls below the switching threshold (e.g., 0.3), or when a single call fails, the system immediately triggers a model switching process, executing four steps: First, it iterates through the real-time health scores of all candidate large language models and selects the candidate large language model with the highest score as the replacement object; second, it updates the currently effective model identifier in the system's global configuration, completing the switching of the target large language model; third, it generates a standardized model switching log, recording the switching trigger reason, the original model identifier, the new model identifier, the switching timestamp, and other information, and stores it persistently; fourth, it schedules the inference node to use the new target large language model after the switch to re-initiate the inference operation of the unfinished user request, ensuring that the device management task is not interrupted.

[0081] Based on the methods described in the above embodiments, this application also provides a building equipment management device for performing the steps in the above building equipment management method. Please refer to... Figure 6 , Figure 6 This is a schematic diagram of a building equipment management device provided for an exemplary embodiment of this application. Specifically, the building equipment management device 400 includes: a first determining unit 401, a second determining unit 402, a first execution unit 403, and a second execution unit 404, wherein: The first determining unit 401 is used to determine the task difficulty mode corresponding to the received user input information in response to the user input information. The second determining unit 402 is used to determine a target processing path that matches the task difficulty mode from a preset set of processing paths; The first execution unit 403 is used to execute the corresponding building equipment management task based on the user input information, according to the created target state machine instance, when the target processing path is the model processing path. The target state machine instance is configured to call the inference node and tool node to perform at least one round of inference and tool call operation based on the preset node flow loop rules. The inference node is configured to call the target large language model to perform semantic inference and instruction generation. The tool node is configured to call and execute the tools in the preset equipment management tool library. The second execution unit 404 is used to, when the target processing path is a rule processing path, call and execute the tool corresponding to the user input information from the device management tool library based on the preset tool call rule, so as to perform the corresponding building equipment management task.

[0082] In some embodiments, the first execution unit 403 is specifically used for: Based on the created target state machine instance, the target large language model is invoked through this inference node to perform semantic reasoning and instruction generation based on the user input information, so as to obtain the tool invocation instruction; This tool node allows you to call and execute the tool corresponding to the tool call command from the preset device management tool library to complete a round of reasoning and tool call operation. The execution result of the tool node is sent back to the inference node, so that the inference node can call the target large language model to determine whether it is necessary to continue calling the tool. When it is determined that it is necessary to continue calling the tool, the next round of inference and tool calling operations is performed through the inference node and the tool node.

[0083] In some embodiments, the first execution unit 403 is specifically used for: Through this inference node, model input information is generated based on the user input information and preset tooltips; The input information of the model is fed into the target large language model for processing, so that the target large language model can determine whether a tool needs to be called, and when it is determined that a tool needs to be called, the corresponding tool call instruction is generated.

[0084] In some embodiments, the first execution unit 403 is specifically used for: Through this inference node, based on the preset scheduling scoring function and the user input information, the scheduling score of each tool in the device management tool library is determined; The target large language model is invoked, and the scheduling score determines whether a tool needs to be invoked. If it is determined that a tool needs to be invoked, the corresponding tool invocation instruction is generated.

[0085] In some embodiments, the first execution unit 403 is specifically used for: The tool node is used to parse the tool invocation command to extract the tool identifier and the first parameter; The system queries the preset device management tool library for a first target tool that matches the tool identifier, and runs the tool function of the first target tool based on the first parameter.

[0086] In some embodiments, the second execution unit 404 is specifically used for: The user input information and the keyword groups of each tool are matched with keywords, and the tool corresponding to the matching tool keyword group is used as the second target tool; The second parameter is obtained by extracting parameters from the user input information using the parameter extraction template of the second target tool. The tool function that runs the second target tool based on the second parameter.

[0087] In some embodiments, the building equipment management device 400 further includes a digging unit for: Each time a device management task is completed, the corresponding task information is stored in the device management log. In response to a pattern mining command targeting the device management log, determine device management patterns and / or user preference patterns based on the device management log; Control the management operations of the corresponding equipment based on the equipment management rules and / or user preference rules.

[0088] In some embodiments, the building equipment management device 400 further includes a switching unit for: After each inference node calls the target large language model, the health score of the current target large language model is updated based on the result of the current call according to the preset model health scoring rules. The model health scoring rules include a score decay function and a score increment function. When the health score is lower than the preset score or the call result indicates that the call failed, the candidate large language model with the highest health score is selected from the preset candidate large language model library, and the current target large language model is switched to the selected candidate large language model.

[0089] As described above, the building equipment management device 400 provided in this embodiment determines the task difficulty mode corresponding to the received user input information through the first determining unit 401; the second determining unit 402 determines the target processing path matching the task difficulty mode from the preset processing path set; then, when the target processing path is a model processing path, the first execution unit 403 calls the created target state machine instance to execute the corresponding building equipment management task according to the user input information. The target state machine instance is configured to call the inference node and tool node to perform at least one round of inference and tool call operation based on the preset node flow loop rules; the inference node is configured to call the target large language model for semantic inference and instruction generation, and the tool node is configured to call and execute the tools in the preset equipment management tool library; when the target processing path is a rule processing path, the second execution unit 404 calls and executes the tool corresponding to the user input information from the equipment management tool library based on the preset tool call rules to execute the corresponding building equipment management task. In other words, on the one hand, by designing differentiated processing paths for different task difficulties in advance, lightweight rule processing paths are designed for simple tasks, while model processing paths that rely on large model inference operations are designed for complex tasks. This enables differentiated processing of tasks of different difficulties, ensuring low latency and high throughput execution efficiency for simple tasks while ensuring the execution reliability of complex tasks. On the other hand, by relying on the semantic reasoning and generation capabilities of large language models in the model processing path, and combining state machine instances with automated multi-round loop interaction, branching flow, and iterative scheduling mechanisms for inference nodes and tool nodes, the dependence on fixed command patterns is eliminated. This enables the automatic decomposition, step arrangement, and iterative tool invocation of complex tasks, effectively improving the execution accuracy, completion rate, and system robustness of complex tasks under multiple constraints.

[0090] It should be noted that the division of the building equipment management device 400 into various unit modules is only for illustrative purposes. In other embodiments, the building equipment management device 400 can be divided into different unit modules as needed to complete all or part of the functions of the building equipment management device 400. The implementation of each unit module in the building equipment management device 400 provided in the embodiments of this specification can be in the form of a computer program. This computer program can run on a terminal or server. The program modules constituted by this computer program can be stored in the memory of the terminal or server. When the computer program is executed by a processor, it implements all or part of the steps of the building equipment management method described in the embodiments of this specification.

[0091] Please see below. Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. For example... Figure 7 As shown, the electronic device 500 may include at least one processor 510, at least one network interface 520, user interface 530, memory 540, and at least one communication bus 550.

[0092] The communication bus 550 is used to enable communication between these components.

[0093] The network interface 520 may include, but is not limited to, a Bluetooth Low Energy module, a Near Field Communication (NFC) module, a Wireless Fidelity (Wi-Fi) module, etc.

[0094] The user interface 530 may include a display screen and a camera. Optionally, the user interface 530 may also include a standard wired interface and a wireless interface.

[0095] The processor 510 may include one or more processing cores. The processor 510 connects to various parts within the electronic device 500 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 540, and by calling data stored in the memory 540. Optionally, the processor 510 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 510 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 510 and may be implemented as a separate chip.

[0096] The memory 540 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 540 may include a non-transitory computer-readable storage medium. The memory 540 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 540 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as voiceprint direction recognition, voice separation, personalized data storage, etc.), and instructions for implementing the various method embodiments described above. The data storage area may store data involved in the various method embodiments described above. Optionally, the memory 540 may also be at least one storage device located remotely from the aforementioned processor 510. Figure 7 As shown, the memory 540, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and program instructions.

[0097] exist Figure 7In the illustrated electronic device 500, the user interface 530 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 510 can be used to call program instructions stored in the memory 540. The aforementioned electronic device 500 can, but is not limited to, [the following functions / functions]... Figure 7 The building equipment management device 500 shown herein, and the building equipment management method described in any of the above embodiments.

[0098] This application also provides a computer storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform one or more steps of any of the above methods. If the constituent modules of the above-described building equipment management device are implemented as software functional units and sold or used as independent products, they can be stored in this storage medium.

[0099] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0100] It should be noted that the information (including but not limited to UI screenshots, requirement descriptions, image data, user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the modification record information involved in this specification was obtained under full authorization.

[0101] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks. Unless otherwise specified, the technical features of this embodiment and its implementation can be combined arbitrarily.

[0102] The above embodiments are merely descriptions of preferred embodiments of this application and are not intended to limit the scope of this application. Any modifications and improvements made by those skilled in the art to the technical solutions of this application without departing from the spirit of this application should fall within the protection scope defined by the claims of this application.

Claims

1. A building equipment management method, characterized in that, The method includes: In response to the received user input information, determine the task difficulty mode corresponding to the user input information; Determine the target processing path that matches the task difficulty mode from the preset set of processing paths; When the target processing path is the model processing path, based on the created target state machine instance, the corresponding building equipment management task is executed according to the user input information. The target state machine instance is configured to call the inference node and tool node to perform at least one round of inference and tool call operation based on the preset node flow loop rules. The inference node is configured to call the target large language model to perform semantic inference and instruction generation. The tool node is configured to call and execute the tools in the preset equipment management tool library. When the target processing path is a rule processing path, based on the preset tool invocation rules, the tool corresponding to the user input information is invoked and executed from the device management tool library to perform the corresponding building equipment management task.

2. The method according to claim 1, characterized in that, The step of executing corresponding building equipment management tasks based on the created target state machine instance and the user input information includes: Based on the created target state machine instance, the target large language model is invoked through the inference node to perform semantic reasoning and instruction generation based on the user input information, so as to obtain the tool invocation instruction; Through the tool node, the tool corresponding to the tool call instruction is called and executed from the preset device management tool library to complete a round of reasoning and tool call operation; The execution result of the tool node is sent back to the inference node, so that the inference node calls the target large language model to determine whether it is necessary to continue calling the tool. When it is determined that it is necessary to continue calling the tool, the next round of inference and tool calling operation is performed through the inference node and the tool node.

3. The method according to claim 2, characterized in that, The step of invoking the target large language model through the inference node to perform semantic reasoning and instruction generation based on the user input information to obtain tool invocation instructions includes: Through the inference node, model input information is generated based on the user input information and preset tooltips; The model input information is input into the target large language model for processing, so that the target large language model can determine whether a tool needs to be called, and when it is determined that a tool needs to be called, a corresponding tool call instruction is generated.

4. The method according to claim 2, characterized in that, The step of invoking the target large language model through the inference node to perform semantic reasoning and instruction generation based on the user input information to obtain tool invocation instructions includes: Based on the preset scheduling scoring function and the user input information, the scheduling score of each tool in the device management tool library is determined through the inference node. The target large language model is invoked, and the scheduling score is used to determine whether a tool needs to be invoked. If it is determined that a tool needs to be invoked, a corresponding tool invocation instruction is generated.

5. The method according to claim 2, characterized in that, The step of calling and executing the tool corresponding to the tool call instruction from a preset device management tool library through the tool node includes: The tool node is used to parse the tool invocation command to extract the tool identifier and the first parameter; The system queries a preset device management tool library for a first target tool that matches the tool identifier, and runs the tool function of the first target tool based on the first parameter.

6. The method according to claim 1, characterized in that, The preset tool invocation rules include tool keyword groups and parameter extraction templates for each tool. The step of invoking and executing the tool corresponding to the user input information from the device management tool library based on the preset tool invocation rules includes: The user input information and the keyword groups of each tool are matched with keywords, and the tool corresponding to the matching keyword group is used as the second target tool; The second parameter is obtained by extracting parameters from the user input information using the parameter extraction template of the second target tool. The tool function that runs the second target tool based on the second parameter.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Each time a building equipment management task is completed, the corresponding task information is stored in the equipment management log. In response to a pattern mining instruction for the device management logs, determine device management patterns and / or user preference patterns based on the device management logs; Based on the aforementioned equipment management rules and / or user preference rules, control the management operations of the corresponding building equipment.

8. The method according to any one of claims 1-6, characterized in that, After each inference node invokes the target large language model, the method further includes: Based on the preset model health scoring rules, the current health score of the target large language model is updated according to the result of this call. The model health scoring rules include a score decay function and a score increment function. When the health score is lower than the preset score or the call result indicates that the call failed, the candidate large language model with the highest health score is selected from the preset candidate large language model library, and the current target large language model is switched to the selected candidate large language model.

9. A building equipment management device, characterized in that, The device includes: The first determining unit is configured to determine the task difficulty mode corresponding to the received user input information in response to the received user input information. The second determining unit is used to determine a target processing path that matches the task difficulty mode from a preset set of processing paths; The first execution unit is used to execute corresponding building equipment management tasks based on the user input information, according to the created target state machine instance, when the target processing path is the model processing path. The target state machine instance is configured to call inference nodes and tool nodes to perform at least one round of inference and tool call operations based on preset node flow loop rules. The inference node is configured to call the target large language model for semantic inference and instruction generation. The tool node is configured to call and execute tools in the preset equipment management tool library. The second execution unit is used to, when the target processing path is a rule processing path, call and execute the tool corresponding to the user input information from the device management tool library based on the preset tool call rule, so as to perform the corresponding building equipment management task.

10. An electronic device, characterized in that, include: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the electronic device to perform the building equipment management method as described in any one of claims 1-8.

11. A computer storage medium, characterized in that, The computer storage medium stores multiple instructions, which are adapted to be loaded by a processor and executed as described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes computer program code, which, when run on a computer, causes the computer to perform the building equipment management method as described in any one of claims 1-8.

Images