Method for processing fault of multi-agent collaborative operator network based on large language model

Abstract

The application discloses a multi-agent collaborative operator network fault processing method based on a large language model and belongs to the technical field of network operation and maintenance. The method comprises the following steps: creating a current fault work order and constructing a fault context according to a network fault triggering signal of a monitoring system; obtaining an inference result obtained by a fault information processing agent based on a large language model from the inference of the fault context, and generating a task execution sequence based on the inference result; monitoring the execution feedback of each sub-agent in real time during the execution of the task execution sequence, generating a dynamic adjustment strategy based on the large language model when task execution abnormalities or process deviations from the preset path are monitored, and adjusting the tasks that have not been executed; and executing the adjusted task execution sequence until the work order is closed. The application can realize dynamic arrangement and real-time rearrangement of the fault processing process, and improves the fault tolerance and automatic processing capacity.

Description

Technical Field

[0001] This invention relates to the field of network operation and maintenance technology, and more specifically, to a multi-agent collaborative operator network fault handling method based on a large language model. Background Technology

[0002] With the continuous expansion of telecommunications operators' networks and the increasing complexity of their network architecture, network fault maintenance faces enormous challenges. Currently, the processing of network fault work orders by operators mainly relies on traditional Operations Support System (OSS) processes, which have achieved a certain degree of electronic workflow, but the following technical problems still exist in practical applications: I. The fault handling process is rigid and lacks dynamic scheduling capabilities. In existing technologies, the processing flow of fault work orders typically employs a pre-defined static workflow. Once triggered, the process executes according to a fixed sequence of steps, such as "alarm access - root cause analysis - work order dispatch - processing feedback - work order closure." This static workflow has significant drawbacks when facing abnormal situations: for example, if no confirmation of acceptance is received from the handler after the work order is dispatched, traditional systems often can only report an error and suspend the process or wait for manual intervention, unable to autonomously adjust subsequent processes based on the abnormal context. This leads to low efficiency in fault handling, especially in complex fault scenarios, where a large number of work orders require manual intervention for reassignment or escalation.

[0003] Second, the work order closed-loop system relies on manual feedback and lacks an objective verification mechanism. In existing technologies, the closed-loop determination of work orders mainly relies on manual feedback from operations and maintenance personnel. When operations and maintenance personnel click "processing complete" or "fault repaired" in the work order system, they usually only simply verify whether the alarm has been cleared and then directly close the work order, lacking objective verification of whether the service has truly been restored. This often leads to a false closed-loop phenomenon in practice, where "alarms are cleared but services are still unavailable," and the fault recurs immediately after the work order is closed, seriously affecting network quality.

[0004] Third, the fault context information is fragmented, and a unified maintenance mechanism is lacking. In existing technologies, fault handling involves multiple independent systems such as monitoring systems, resource management systems, scheduling systems, and notification platforms, with data fragmented between these systems. When it is necessary to obtain information across systems (such as querying the grid to which the faulty network element belongs, the current on-duty personnel, etc.), existing solutions cannot automatically associate and maintain a complete fault context, resulting in scattered information, difficulty in sharing, and inability to support intelligent collaborative decision-making.

[0005] In summary, how to provide a fault work order processing method that can dynamically adjust the processing flow based on abnormal situations during fault handling, objectively verify the fault repair results, and uniformly maintain fault context information has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a multi-agent collaborative operator network fault handling method based on a large language model, which aims to solve at least one of the above-mentioned technical problems.

[0007] Firstly, the technical solution of the present invention to solve the above-mentioned technical problems is as follows: a multi-agent collaborative operator network fault handling method based on a large language model, applied to a central control decision-making agent, the method comprising: Obtain and create the corresponding current fault work order based on the network fault trigger signal of the monitoring system, and construct the target fault context corresponding to the current fault work order; The reasoning results obtained by the fault information processing agent through semantic understanding and logical reasoning of the target fault context based on a large language model are obtained, and a task execution sequence is generated based on the reasoning results. The task execution sequence describes the calling order and calling method of at least one sub-agent. During the execution of the task execution sequence, the execution feedback of each sub-agent is monitored in real time. When any task execution abnormality or process deviation from the preset path is detected based on the execution feedback, the current fault context corresponding to the execution abnormality or process deviation from the preset path is reasoned based on the large language model to generate a dynamic adjustment strategy. The subsequent tasks that have not yet been executed in the task execution sequence are adjusted based on the dynamic adjustment strategy to obtain the adjusted task execution sequence. The adjusted task execution sequence is distributed to the corresponding sub-agents for execution until the current fault work order completes closed-loop processing.

[0008] The beneficial effects of this invention are as follows: Addressing the problem in existing technologies where static workflows suspend and fail to adjust autonomously upon encountering anomalies, this solution utilizes a central control decision-making agent to monitor the execution feedback of each sub-agent in real time during the task execution sequence. When any task execution anomaly or deviation from the preset path is detected, a dynamic adjustment strategy is generated based on a large language model to perform thought chain reasoning on the current fault context and anomaly information. This strategy is then adjusted before subsequent tasks that have not yet been executed are issued for execution. Because the large language model possesses the ability to understand fault context and anomaly information and has logical reasoning capabilities, it can autonomously generate adjustment strategies based on anomalies or deviations that occur during actual execution, without relying on preset static branches or waiting for manual intervention. This allows the fault handling process to be dynamically rearranged based on execution feedback, overcoming the anomaly suspension problem caused by rigid processes in existing technologies, and significantly improving the system's fault tolerance and flexibility in complex fault scenarios.

[0009] Based on the above technical solution, the present invention can be further improved as follows.

[0010] Furthermore, the process of acquiring and creating a corresponding current fault work order based on the network fault trigger signal from the monitoring system, and constructing the target fault context corresponding to the current fault work order, includes: Obtain the original alarm data from the network fault trigger signal, and create the current fault work order based on the original alarm data; The original alarm data is written into the initial fault context as the initial content, and the fault information processing agent is triggered to read the original alarm data from the initial fault context to extract key features and write the key features back into the initial fault context to obtain the target fault context.

[0011] Furthermore, the method also includes: During the processing of the current fault work order, supplementary information is obtained by calling sub-agents and / or querying external systems to update the target fault context.

[0012] Furthermore, when any task execution anomaly or process deviation from the preset path is detected based on various execution feedbacks, a dynamic adjustment strategy is generated by performing thought chain reasoning on the current fault context corresponding to the execution anomaly or process deviation from the preset path based on the large language model, including: When an execution anomaly is detected based on various execution feedbacks, the anomaly type and the first fault context at the time of the anomaly are obtained as the current fault context; or... When the process deviates from the preset path based on various execution feedbacks, the deviation information at the time of the deviation and the second fault context at the time of the deviation are obtained as the current fault context. The anomaly type and the first fault context, or the deviation information and the second fault context, are used as prompt words to input into the large language model for thought chain reasoning to obtain the reasoning results. The reasoning results include at least the cause analysis and one or more candidate adjustment actions. A dynamic adjustment strategy is generated based on the reasoning results.

[0013] Furthermore, the aforementioned sub-intelligent agents include a fault information processing intelligent agent, a work order dispatch intelligent agent, a message push intelligent agent, a fault processing result verification intelligent agent, and a fault report generation intelligent agent; During the execution of the task execution sequence, the execution feedback of the fault information processing agent includes: whether the root cause analysis was successful, the key feature data extracted, and the intermediate results generated during the analysis. The execution feedback of the work order dispatching agent includes: whether the dispatch was successful, the target processing object information, and the reason for the failure when the dispatch fails; The execution feedback of the message push agent includes: whether the message was successfully pushed, whether the target person has read or confirmed the order, and whether there was no response after timeout; The execution feedback of the fault handling result verification agent includes: whether the verification was successful, real-time performance index data of the network element, and the result of verification pass or fail; The execution feedback of the fault report generating agent includes: whether the report was successfully generated and the report storage path.

[0014] Furthermore, the aforementioned dynamic adjustment strategy includes at least one of the following: automatically expanding the resource search scope, changing the target processing object, or upgrading the notification object; adjusting subsequent tasks that have not yet been executed in the task execution sequence based on the dynamic adjustment strategy to obtain an adjusted task execution sequence, including: When the dynamic adjustment strategy is to automatically expand the resource search scope, the search scope of the first task executed by the work order dispatch agent in the subsequent tasks is expanded, and the query parameters in the first task are updated. When the dynamic adjustment strategy is to change the target processing object, the work order recipient determined by the second task executed by the work order dispatch agent in the subsequent task will be replaced with the new work order recipient. When the dynamic adjustment strategy is to upgrade the notification target, an upgrade notification task executed by the message push agent will be added in the subsequent tasks; Based on the adjusted tasks and execution order, generate the adjusted task execution sequence.

[0015] Furthermore, the method also includes: In response to the fault handling completion signal from the maintenance personnel, the verification agent executes the following steps based on the fault handling result to obtain verification information: Obtain real-time performance metrics data for relevant network elements; Compare real-time performance metrics with preset benchmark values; If the comparison passes, a verification pass message is returned to the central control decision-making intelligent agent; If the comparison fails, a verification failure message is returned to the central control decision-making agent; If the verification information is successful, the execution status of the current fault work order is determined to be completed. If the verification information is unsuccessful, the execution status of the current fault work order is determined to be in progress, and a message push agent is triggered to send a notification to the maintenance personnel to re-check.

[0016] Secondly, to solve the above-mentioned technical problems, the present invention also provides a multi-agent collaborative operator network fault handling device based on a large language model, applied to a central control decision-making agent, the device comprising: The acquisition module is used to acquire and create the corresponding current fault work order based on the network fault trigger signal of the monitoring system, and construct the target fault context corresponding to the current fault work order; The task execution sequence generation module is used to obtain the reasoning results obtained by the fault information processing agent through semantic understanding and logical reasoning of the target fault context based on the large language model, and to generate a task execution sequence based on the reasoning results. The task execution sequence describes the calling order and calling method of at least one sub-agent. The strategy adjustment module is used to monitor the execution feedback of each sub-agent in real time during the execution of the task execution sequence. When any task execution abnormality or process deviation from the preset path is detected based on the execution feedback, the module performs thought chain reasoning on the current fault context corresponding to the execution abnormality or process deviation from the preset path based on the large language model, generates a dynamic adjustment strategy, and adjusts the subsequent tasks that have not yet been executed in the task execution sequence based on the dynamic adjustment strategy to obtain the adjusted task execution sequence. The closed-loop processing module is used to distribute the adjusted task execution sequence to the corresponding sub-agents for execution until the current fault work order completes the closed-loop processing.

[0017] Thirdly, in order to solve the above-mentioned technical problems, the present invention also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the multi-agent cooperative operator network fault handling method based on a large language model of the present application.

[0018] Fourthly, in order to solve the above-mentioned technical problems, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the multi-agent cooperative operator network fault handling method based on a large language model of the present application.

[0019] Additional aspects and advantages of this application will be set forth in part in the description which follows, and will become apparent from the description or may be learned by practice of this application. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below.

[0021] Figure 1 This is a flowchart illustrating a multi-agent collaborative operator network fault handling method based on a large language model, as provided in one embodiment of the present invention. Figure 2 A system architecture diagram provided for one embodiment of the present invention; Figure 3 A closed-loop processing flowchart is provided in one embodiment of the present invention; Figure 4 This is a schematic diagram of a work order center interface provided in one embodiment of the present invention; Figure 5 A schematic diagram of intelligent analysis status provided in one embodiment of the present invention; Figure 6 A schematic diagram of a fault report is provided as an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of a multi-agent collaborative operator network fault handling device based on a large language model, provided in one embodiment of the present invention. Figure 8 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0022] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0023] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0024] The data acquisition process involved in this invention follows the principles of legality, legitimacy, and necessity. Based on obtaining the explicit authorization and consent of the user, only the minimum necessary information required to achieve the purpose is collected, and data security protection obligations are fulfilled in accordance with the law.

[0025] The solution provided in this invention can be applied to any application scenario that requires handling network faults of operators.

[0026] This invention provides a possible implementation, such as... Figure 1 As shown, a flowchart of a multi-agent collaborative operator network fault handling method based on a large language model is presented. This scheme can be applied to a central control decision-making agent. The following will use the central control decision-making agent as the execution subject as an example to illustrate the method provided in this embodiment of the invention. Figure 1 The flowchart shown indicates that the method may include the following steps: S10: Obtain and create the corresponding current fault work order based on the network fault trigger signal of the monitoring system, and construct the target fault context corresponding to the current fault work order; S20: Obtain the reasoning result obtained by the fault information processing agent through semantic understanding and logical reasoning of the target fault context based on the large language model, and generate a task execution sequence based on the reasoning result. The task execution sequence describes the calling order and calling method of at least one sub-agent. S30: During the execution of the task execution sequence, the execution feedback of each sub-agent is monitored in real time. When any task execution abnormality or process deviation from the preset path is detected based on the execution feedback, the current fault context corresponding to the execution abnormality or process deviation from the preset path is reasoned based on the large language model to generate a dynamic adjustment strategy. The subsequent tasks that have not yet been executed in the task execution sequence are adjusted based on the dynamic adjustment strategy to obtain the adjusted task execution sequence. S40 distributes the adjusted task execution sequence to the corresponding sub-agents for execution until the current fault work order completes closed-loop processing.

[0027] The method of this invention addresses the problem in existing technologies where static workflows suspend and fail to adjust autonomously upon encountering anomalies. This solution employs a central control decision-making agent that monitors the execution feedback of each sub-agent in real time during the task execution sequence. When any task execution anomaly or deviation from the preset path is detected, a dynamic adjustment strategy is generated based on a large language model, using thought chain reasoning to analyze the current fault context and anomaly information. This strategy is then adjusted before subsequent tasks that have not yet been executed are re-issued for execution. Because the large language model possesses the ability to understand fault context and anomaly information and its logical reasoning capabilities, it can autonomously generate adjustment strategies based on anomalies or deviations encountered during actual execution, without relying on preset static branches or waiting for manual intervention. This allows the fault handling process to be dynamically rearranged based on execution feedback, overcoming the anomaly suspension problem caused by rigid processes in existing technologies, and significantly improving the system's fault tolerance and flexibility in complex fault scenarios.

[0028] The present invention will be further described below with reference to the following specific embodiments. In these embodiments, the specific technical problems that the present invention aims to solve are as follows: 1. Solving the problem of accurate work order delineation and dispatch in complex fault scenarios. This invention aims to replace the traditional keyword matching mode with an intelligent agent architecture possessing semantic understanding and reasoning capabilities, to achieve deep analysis and root cause correlation of alarm information, thereby realizing accurate work order location and automatic dispatch, and reducing the mis-dispatch rate.

[0029] 2. To address the "false closed loop" problem caused by the inability to automatically verify fault repair results. This invention aims to establish an automated verification mechanism that links work order status with real-time network indicators. After a work order is repaired, it automatically collects network element performance data for comparison and verification, ensuring that the work order is only closed after network indicators meet the service recovery standards, thereby guaranteeing the authenticity and effectiveness of fault handling.

[0030] 3. Solving the problem of low efficiency in cross-system collaboration. This invention aims to achieve fully automated orchestration and data sharing of the entire process from fault diagnosis, message delivery, result verification to fault report generation through a multi-agent mechanism of overall control decision-making and division of labor and cooperation. This eliminates the breakpoints of manual cross-system operations and improves the timeliness of network fault handling and overall operation and maintenance efficiency.

[0031] Based on this, this embodiment uses a "5G base station outage in a certain city" as an example to describe the specific implementation of the present invention in detail with reference to the accompanying drawings. It should be noted that this specific embodiment is only used to explain the present invention and is not intended to limit the scope of the present invention.

[0032] The system architecture used in this embodiment is as follows: Figure 2 As shown, the system comprises an infrastructure layer, a multi-agent core layer, and a knowledge base layer. The infrastructure layer includes the operator's OSS / BSS system, a network alarm database, a resource management system (recording base station / optical cable location and affiliation), a scheduling system, DingTalk open platform APIs, and network management indicator query interfaces. The multi-agent core layer includes a central control decision-making agent, a fault information processing agent, a work order dispatch agent, a message push agent, a fault handling result verification agent, and a fault report generation agent. The central control decision-making agent maintains a global state blackboard, and all sub-agents share fault context information, current processing progress, and intermediate inference results by reading and writing to this global state blackboard. The knowledge base layer contains a historical fault case library (vector database) and standard operating procedure documents.

[0033] It should be noted that the global state blackboard in this embodiment implements a multi-agent collaborative mechanism. All agents share fault context, reasoning process, and intermediate results in real time by reading and writing to this global state blackboard, rather than using the traditional linear call method between module interfaces. This mechanism enables agents to achieve a human-like "thought chain" collaborative working mode, avoiding the problem of difficult context transmission caused by information fragmentation between modules in existing technologies.

[0034] The master agent is responsible for receiving external trigger signals, decomposing tasks, distributing instructions to sub-agents, and monitoring task status. It maintains a global blackboard where the execution results of all sub-agents are written back for other agents to access.

[0035] The fault information processing intelligent agent (Diagnosis Agent) is responsible for natural language understanding (NLU), reading the original alarm information, combining it with the knowledge base to perform alarm noise reduction and correlation analysis, and extracting key features (such as faulty network element ID, fault time, and fault type).

[0036] The dispatch agent is responsible for logical reasoning. Based on the fault location (administrative division), fault specialty (transmission / wireless / core network), and the current work schedule, it determines the optimal handling team or specific personnel for the corresponding city.

[0037] Notification Agent: Responsible for API calls. It encapsulates structured work order information into DingTalk card messages, calls the DingTalk API to push them to designated personnel, and listens for the message's "read / confirmed" callback status.

[0038] Fault Handling Result Verification Agent: Responsible for closed-loop detection. After the work order status changes to "processed", it automatically connects to the network management system to query the real-time KPI indicators of the network element (such as RRC connection success rate, optical power, etc.) to determine whether the fault has been truly eliminated.

[0039] Reporting Agent: Responsible for text generation. It summarizes data from the entire fault process and generates a structured report including the cause of the fault, the handling process, the verification results, and subsequent recommendations.

[0040] The overall closed-loop processing flow in this embodiment is as follows: Figure 3 As shown, this includes: fault detection and task initialization, information enrichment and root cause analysis, intelligent delimitation and dispatch, multi-channel reach and response, processing feedback and automatic verification, and hazard discovery and report archiving. The following combines... Figure 3 Each step is explained in detail.

[0041] The multi-agent cooperative operator network fault handling method based on a large language model provided in this embodiment may include the following steps: S10: Obtain and create the corresponding current fault work order based on the network fault trigger signal of the monitoring system, and construct the target fault context corresponding to the current fault work order; In this step, the central control decision-making agent refers to the central scheduling unit in the core layer of the multi-agent system. It is responsible for receiving external trigger signals, decomposing tasks, distributing instructions to sub-agents, monitoring task status, and maintaining the global state blackboard. The network fault trigger signal is a trigger message sent by the operator's network monitoring system to the central control decision-making agent when it detects an anomaly in network equipment. This signal is used to initiate the fault work order processing flow. The network fault trigger signal may include raw alarm data, which is the specific data content contained within the signal, including at least the faulty network element identifier, fault time, and alarm type. The current fault work order is a unique management unit created to record and manage the entire fault handling process, possessing a unique session identifier. The target fault context is a set of information bound to the current fault work order and dynamically updated as the fault handling process progresses. This information set serves as the carrier of the global state blackboard, allowing multiple agents to share and read it.

[0042] Alternatively, one possible implementation of S10 above is as follows: S101, Obtain the original alarm data from the network fault trigger signal, and create the current fault work order based on the original alarm data; Specifically, the central control decision-making agent acquires network fault trigger signals reported by the monitoring system. In this embodiment, the monitoring system captures a "cell out of service" alarm and sends the original alarm data to the central control decision-making agent.

[0043] S102, the original alarm data is written into the initial fault context as the initial content, and the fault information processing agent is triggered to read the original alarm data from the initial fault context to extract key features and write the key features back into the initial fault context to obtain the target fault context.

[0044] In this embodiment, key features may include: faulty network element ID (e.g., "a certain base station"), fault time (e.g., "14:00"), fault type (e.g., "cell out of service"), and fault level (e.g., "emergency"). After the fault information processing agent writes the extracted key features back to the initial fault context, the initial fault context is updated to the target fault context.

[0045] Optionally, such as Figure 4 The diagram shown illustrates the work order center interface. Users can view the intelligent analysis status at any time in the work order center of the monitoring system. After receiving a network fault trigger signal, the central control decision-making agent can create a unique session identifier as the identifier of the current fault work order and write the initial content of the current fault work order to the global status blackboard.

[0046] In addition, such as Figure 5The diagram illustrating the intelligent analysis state shows the analysis process performed by the fault information processing agent, including intermediate results such as alarm noise reduction, correlation analysis, and key feature extraction. During the processing of the current fault work order, the central control decision-making agent also obtains supplementary information by calling sub-agents and / or querying external systems to update the target fault context. For example, in subsequent steps, the work order dispatch agent queries the resource management system to obtain base station affiliation information, and the message push agent obtains notification receipt status; all of these continuously write to the target fault context, achieving dynamic updates.

[0047] S20: Obtain the reasoning result obtained by the fault information processing agent through semantic understanding and logical reasoning of the target fault context based on the large language model, and generate a task execution sequence based on the reasoning result. The task execution sequence describes the calling order and calling method of at least one sub-agent. The reasoning result refers to the conclusions drawn by the fault information processing agent after performing semantic analysis and root cause correlation on the original alarm data in the target fault context, including the root cause of the fault, associated network elements, fault type classification, and fault level. The task execution sequence refers to the set of instructions generated by the overall control decision agent based on the reasoning result, which calls each sub-agent to execute specific tasks in a specific order. This task execution sequence defines the calling order (e.g., diagnosis first, then scheduling) and calling method (e.g., serial or parallel, synchronous or asynchronous) of each sub-agent.

[0048] The current fault work order, defined in S10, is a unique management unit created to record and manage the entire fault handling process. In this step, the semantic understanding and logical reasoning of the fault information processing agent revolve around the target fault context corresponding to the current fault work order.

[0049] Prior to S20, the method also includes: when the overall control decision-making agent recognizes that fault processing is required for the current fault work order based on the preset prompt word template, the fault information processing agent is activated.

[0050] Subsequently, in S20, the process by which the fault information processing agent performs semantic understanding and logical reasoning on the target fault context based on a large language model to obtain the reasoning result includes: The fault information processing agent first reads the target fault context bound to the current fault work order from the global status blackboard. The target fault context contains the original alarm data written in S10. In this embodiment, the original alarm data is: fault network element identifier "a certain base station", fault time "14:00", alarm type "cell out of service", and fault level "emergency".

[0051] The fault information processing agent uses the original alarm data in the target fault context as a retrieval index to initiate a retrieval request to the knowledge base layer. The knowledge base layer contains a historical fault case library (vector database) and standard operating procedure documents for operation and maintenance. Specifically, the fault information processing agent converts key fields (such as "cell out of service" or "a certain base station") in the original alarm data into vectors, performs a similarity search in the historical fault case library, and recalls several historical cases most similar to the fault corresponding to the current fault work order, along with their corresponding solutions.

[0052] The fault information processing agent uses the recalled similar historical cases, the relevant rule knowledge in the operation and maintenance standard operating procedure document, and the original alarm data in the target fault context as components of the prompt words, and inputs them into the large language model.

[0053] The large language model is used to perform semantic understanding and logical reasoning on the above input: First, the semantic meaning of the current alarm is understood. Then, the correlation of the fault is judged by combining the similar historical cases recalled (such as whether "cell outage" is caused by upstream transmission interruption). Then, the root cause inference is performed by referring to the rule knowledge in the operation and maintenance standard operating procedure document. Finally, the reasoning result is output.

[0054] In this embodiment, the reasoning result output by the large language model after the above process is: the root cause of the alarm is "cell outage caused by transmission interruption", and the key information is extracted as follows: the network element name is "a certain base station", the fault time is "14:00", the fault level is "emergency", and the associated optical path is "a certain optical cable".

[0055] Optionally, the fault information processing agent can also write the above reasoning results into the global status blackboard and store them in association with the current fault work order.

[0056] After obtaining the above reasoning results, the overall control decision-making agent generates a task execution sequence based on these results. The specific method for generating the task execution sequence is as follows: The central control decision-making agent determines the types of sub-agents to be invoked and the execution order among them based on the root cause and fault type in the inference results. Specifically, the central control decision-making agent uses key information from the inference results (such as faulty network element identifiers, fault types, root cause conclusions, and associated resources) as input, and dynamically arranges the invocation order and method of each sub-agent in conjunction with a preset fault handling process template. Invocation methods include, but are not limited to: serial invocation (the next task can only be executed after the previous task is completed), parallel invocation (multiple tasks are executed simultaneously), conditional invocation (whether to execute subsequent tasks depends on the execution result of the previous task), and loop invocation (repeatedly executing a task until a condition is met).

[0057] In this embodiment, the reasoning result is: the root cause of the fault is "cell outage due to transmission interruption", the faulty network element identifier is "a certain base station", the fault type is "transmission interruption", and the associated optical path is "a certain optical cable". Based on this reasoning result, the overall control decision-making agent determines that the fault requires the sequential completion of the following steps: delimitation and dispatch, notification delivery, waiting processing, closed-loop verification, branch judgment, and report archiving. Therefore, the following task execution sequence is generated: The first step is to invoke the work order dispatch agent to execute the demarcation and dispatch task. This task is responsible for querying the resource management system and scheduling system based on the faulty network element identifier to determine the person responsible for handling the fault. This task is invoked serially, meaning that the next step can only proceed after it is completed.

[0058] The second step involves invoking the push notification agent to execute the notification delivery task. This task is responsible for pushing the fault details to the target personnel based on the responsible party information determined in the first step, and monitoring the receipt status. This task is invoked serially, depending on the execution result of the first step (the responsible party information).

[0059] The third step involves invoking the waiting module to listen for fault handling completion signals. This task is responsible for entering a synchronous waiting state after the message push agent delivers the notification, listening for processing completion signals sent by maintenance personnel via the work order mobile page or other feedback channels. This task is invoked using synchronous blocking waiting, and a preset time threshold (e.g., 30 minutes) can be set. If a processing completion signal is received within the preset threshold, the task completes and continues with subsequent steps; if no signal is received after the preset threshold, the task returns a timeout exception, triggering the exception handling mechanism in S30.

[0060] The fourth step involves invoking the fault handling result verification agent to execute a closed-loop verification task. This task, upon receiving the processing completion signal, collects real-time performance index data of the faulty network element and compares it with a preset benchmark value to generate a verification result. This task is invoked serially, depending on the completion signal from the third step.

[0061] The fifth step involves executing a branch processing task based on the verification result. This task reads the verification result from the fourth step: if the verification passes, it continues to the sixth step; if the verification fails, it triggers a message push agent to send a notification to the operations and maintenance personnel to re-check, and returns to the third step to wait for the processing completion signal again. This task is invoked conditionally, determining the subsequent branch based on the execution result of the previous task.

[0062] Step 6: Invoke the fault report generation agent to perform the report archiving task. This task is responsible for reading all data accumulated in the global state blackboard after successful verification, generating a structured fault analysis report, and archiving it. This task is invoked serially, depending on the branch result that passed verification in step 5.

[0063] The above task execution sequence describes the invocation order of five sub-agents (work order dispatch agent, message push agent, fault handling result verification agent, and fault report generation agent) and one waiting step: Step 1 - Step 2 - Step 3 - Step 4 - Step 5 (branch decision) - Step 6 (executed only if verification passes). The invocation methods in this sequence include: serial invocation (Steps 1 to 4 are executed sequentially), synchronous waiting (Step 3 waits for an external signal), conditional invocation (Step 5 determines the branch based on the verification result), and cyclic invocation (if verification fails, it returns to Step 3 and waits again).

[0064] The central control decision-making agent stores the generated task execution sequence in the global state blackboard, associates it with the current fault work order, and uses it for subsequent steps (S30 and S40).

[0065] S30: During the execution of the task execution sequence, the execution feedback of each sub-agent is monitored in real time. When any task execution abnormality or process deviation from the preset path is detected based on the execution feedback, the current fault context corresponding to the execution abnormality or process deviation from the preset path is reasoned based on the large language model to generate a dynamic adjustment strategy. The subsequent tasks that have not yet been executed in the task execution sequence are adjusted based on the dynamic adjustment strategy to obtain the adjusted task execution sequence. Execution feedback refers to the status information and result data returned by each sub-agent after completing its assigned task, including success or failure status, returned data, and error reasons. Task execution anomaly refers to any failure, timeout, or return of abnormal results during the execution of any task in the task execution sequence. Deviation from the preset path refers to situations where the actual execution order or conditional branches do not conform to the preset task execution sequence. Thought chain reasoning refers to the process of inputting the current fault context and anomaly information as prompts into the large language model, triggering the large language model to perform step-by-step logical reasoning to generate adjustment strategies.

[0066] Task execution anomalies include, but are not limited to: message push timeout without receiving order acceptance confirmation, order dispatch failure, and verification failure. When a message push timeout is detected, the central control decision-making agent can trigger an escalation notification strategy, such as automatically triggering a strong reminder via a voice call notification interface, or reporting to the central control decision-making agent for escalation and reassignment. When a verification failure is detected, the central control decision-making agent refuses to close the work order and triggers the message push agent to send a notification to the operations and maintenance personnel to re-check.

[0067] A deviation from the preset path refers to a situation where, during the actual execution of a task execution sequence, the execution order, conditional branches, or invocation methods do not conform to the preset order, preset branches, or preset invocation methods defined in the task execution sequence. This includes, but is not limited to: skipping steps, out-of-order execution, incorrect branch judgments, and incorrect invocation methods.

[0068] Optionally, in this embodiment, each sub-agent includes a fault information processing agent, a work order dispatch agent, a message push agent, a fault processing result verification agent, and a fault report generation agent; During the execution of the task execution sequence, the execution feedback of the fault information processing agent includes: whether the root cause analysis was successful, the key feature data extracted, and the intermediate results generated during the analysis. The execution feedback of the work order dispatching agent includes: whether the dispatch was successful, the target processing object information, and the reason for the failure when the dispatch fails; The execution feedback of the message push agent includes: whether the message was successfully pushed, whether the target person has read or confirmed the order, and whether there was no response after timeout; The execution feedback of the fault handling result verification agent includes: whether the verification was successful, real-time performance index data of the network element, and the result of verification pass or fail; The execution feedback of the fault report generating agent includes: whether the report was successfully generated and the report storage path.

[0069] The overall control decision-making agent monitors the execution feedback of each sub-agent in real time during the execution of the task execution sequence.

[0070] In this embodiment, when the third step above is executed, i.e., the message push agent is invoked to complete the notification delivery, the message push agent sends a DingTalk message to the operations and maintenance personnel Zhang San, and the central control decision agent starts polling and listening. When it is detected that no "confirmation of order acceptance" is received within 5 minutes, the central control decision agent determines that a task execution abnormality has occurred, and the abnormality type is "message push timeout".

[0071] In S30, when any task execution anomaly or process deviation from the preset path is detected based on various execution feedbacks, a dynamic adjustment strategy is generated by performing thought chain reasoning on the current fault context corresponding to the execution anomaly or process deviation from the preset path based on the large language model, including: S301, when any task execution exception is detected based on various execution feedbacks, the exception type at the time of the task execution exception (e.g., "message push timeout" in this embodiment) and the first fault context at the time of the exception are obtained as the current fault context; or... S302, when the process deviates from the preset path based on various execution feedback, the deviation information when the process deviates and the second fault context when the deviation occurs are obtained as the current fault context; S303, input the anomaly type and the first fault context, or the deviation information and the second fault context, as prompt words into the large language model to perform thought chain reasoning and obtain the reasoning result. The reasoning result includes at least the cause analysis and one or more candidate adjustment actions. As an example, the large language model outputs the reasoning analysis as "the target person may be offline or busy with other tasks", and the candidate adjustment actions include "escalate the notification to the team leader" and "trigger a strong voice call reminder".

[0072] S304, Generate a dynamically adjusted strategy based on the reasoning results.

[0073] As an example, the generated dynamic adjustment strategy is "upgrade notification object".

[0074] Optionally, the above dynamic adjustment strategy includes at least one of the following: automatically expanding the resource search scope, changing the target processing object, or upgrading the notification object; adjusting subsequent tasks that have not yet been executed in the task execution sequence based on the dynamic adjustment strategy to obtain an adjusted task execution sequence, including: S305, when the dynamic adjustment strategy is to automatically expand the resource search range, expand the search range of the first task executed by the work order dispatch agent in the subsequent tasks, and update the query parameters in the first task; for example, expand the search range from the current grid to the adjacent grid.

[0075] S306, When the dynamic adjustment strategy is to change the target processing object, the work order recipient determined by the second task executed by the work order dispatch agent in the subsequent task will be replaced with a new work order recipient; for example, the original recipient Zhang San will be replaced with the team leader.

[0076] S307, When the dynamic adjustment strategy is to upgrade the notification target, add an upgrade notification task executed by the message push agent in the subsequent tasks; as an example, the central control decision agent adds "call the message push agent to trigger a voice call notification to the team leader" as a new task after the third step and before the fourth step of the original task execution sequence.

[0077] S308, Generate the adjusted task execution sequence based on the adjusted tasks and execution order.

[0078] S40 distributes the adjusted task execution sequence to the corresponding sub-agents for execution until the current fault work order completes closed-loop processing.

[0079] In this context, "issuance" refers to the central control decision-making agent sending the instructions in the adjusted task execution sequence to the corresponding sub-agents in order, triggering the sub-agents to execute specific operations. "Closed-loop processing" refers to the state where, after the current fault work order has gone through a complete process including diagnosis, dispatch, processing, and verification, it is confirmed that the fault has been truly resolved and formally archived.

[0080] The central control decision-making agent distributes the adjusted task execution sequence to the corresponding sub-agents for execution. In this embodiment, the adjusted sequence includes: Step 1 (reusing root cause analysis results), Step 2 (work order transfer), Step 3 (message push), the newly added escalation notification task (voice call notification to the team leader), Step 3.5 (the newly added escalation notification task, i.e., voice call notification to the team leader), Step 4 (waiting for processing completion signal), Step 5 (fault verification), and Step 6 (report archiving).

[0081] The push notification agent executes an upgrade notification task, calling the TTS interface to send a strong voice call reminder to the team leader. After accepting the task, the team leader reassigns personnel to handle the fault.

[0082] After maintenance personnel Zhang San (or a reassigned person) repairs the fiber optic cable on-site, they click "Processing Completed" on the work order mobile page. Upon receiving the completion signal, the central control decision-making agent proceeds to the verification phase.

[0083] Optionally, the method further includes: In response to the fault handling completion signal from the maintenance personnel, the verification agent executes the following steps based on the fault handling result to obtain verification information: The real-time performance metrics of relevant network elements are obtained. In this embodiment, the verification agent logs into the network management system through the southbound interface, queries the real-time status of the base station, and obtains metrics such as wireless resource control connection success rate and optical power.

[0084] The real-time performance index data is compared with the preset benchmark value; in this embodiment, the collected real-time index is compared with the historical data before the fault occurred.

[0085] If the comparison passes, a verification pass message is returned to the central control decision-making intelligent agent; If the comparison fails, a verification failure message is returned to the central control decision-making agent; If the verification information is successful, the execution status of the current fault work order is determined to be completed. If the verification information is unsuccessful, the execution status of the current fault work order is determined to be in progress, and a message push agent is triggered to send a notification to the maintenance personnel to re-check.

[0086] Real-time performance metrics refer to key performance indicators generated by network elements during actual operation, such as the wireless resource control connection success rate and optical power of 5G base stations. Preset baseline values ​​refer to the standard range of network element performance indicators under normal operating conditions or historical data prior to a fault.

[0087] As an example, in this embodiment, if verification fails, the central control decision-making agent triggers the message push agent to send a notification to Zhang San stating "Verification failed, please check again," maintaining the work order execution status as "processing" and requesting reprocessing. The above verification steps are repeated until verification succeeds.

[0088] Finally, after confirming that the fault has been completely resolved, the central control decision-making agent activates the fault report generation agent. The fault report generation agent reads all interaction logs, operation records, and verification data accumulated in the global state blackboard and uses a large language model to generate a fault analysis report. For example... Figure 6 The diagram shown illustrates a fault report. The report includes the duration of the fault, the root cause (fiber optic cable interruption), the handling process, the efficiency evaluation of the person in charge, and suggestions for potential problems (such as "fiber optic cable interruptions have been frequent in this section recently, and it is recommended to include it in the technical upgrade project"). It is presented in HTML format and automatically sent to the operation and maintenance management system for archiving.

[0089] At this point, the current fault work order has been closed-loop processed.

[0090] Optionally, the above-mentioned fault analysis report can be presented in HTML format, including fault duration, root cause analysis, handling process, efficiency evaluation of the handlers, and suggestions for potential hazards.

[0091] After the verification result is passed, the method also includes: The central control decision-making agent invokes the fault report generation agent to execute the report archiving task. The fault report generation agent reads all data related to the current fault work order from the global status blackboard, including: raw alarm data (fault element identifier, fault time, alarm type, fault level), inference results output by the fault information processing agent (fault root cause, associated network elements, associated optical paths), work order dispatch records from the work order dispatch agent (dispatch object, dispatch time), notification receipts from the message push agent (push status, confirmation time, response time), verification results from the fault handling result verification agent (verification passed or failed, real-time performance metrics, comparison difference), and timestamp information for each step. The fault report generation agent uses the above data as input, employs a large language model to summarize and analyze the data and generate text, outputting a structured fault analysis report. The report should include at least the following: fault duration (total duration from triggering to closure), root cause analysis (the root cause and correlation of the fault), handling process (execution records of each step and responsible persons), efficiency evaluation of the handlers (response time, repair time), and potential risks recommendations (potential risks and improvement suggestions identified based on this fault). After the report is generated, the fault report generation agent writes the report content and storage path to the global status blackboard and automatically sends the report to the operation and maintenance management system for archiving.

[0092] like Figure 6 The diagram shown illustrates a fault report. In this embodiment, the generated fault report is presented in HTML format and includes the fault duration (e.g., "1 hour 20 minutes"), root cause analysis (e.g., "optical cable interruption caused base station outage"), handling process (e.g., "dispatch to Zhang San - Zhang San accepts the order - on-site repair of the optical cable"), worker efficiency evaluation (e.g., "response time 5 minutes, repair time 1 hour 15 minutes"), and potential hazard suggestions (e.g., "optical cable interruptions have been frequent in this section recently; it is recommended to include it in the technical upgrade project and replace it with armored optical cable"). This report is automatically sent to the operation and maintenance management system for archiving, completing the closed-loop processing of the current fault work order.

[0093] To better illustrate and understand the principle of the method provided by this invention, the following description uses an optional specific embodiment to illustrate the solution of this invention. It should be noted that the specific implementation of each step in this specific embodiment should not be construed as a limitation of the solution of this invention. Other implementations that can be conceived by those skilled in the art based on the principle of the solution provided by this invention should also be considered within the scope of protection of this invention.

[0094] In this embodiment, taking "5G base station outage in a certain city" as an example, the complete implementation process of the present invention is illustrated: A10: Fault detection and work order initialization; The monitoring system captures a "cell out of service" alarm, generates a network fault trigger signal, and sends it to the central control decision-making agent. The central control decision-making agent obtains this network fault trigger signal and parses the original alarm data, including: faulty network element identifier "a certain base station," fault time "14:00," alarm type "cell out of service," and fault level "emergency." Based on this original alarm data, the central control decision-making agent creates a current fault work order, assigns a unique session identifier to it, and writes the original alarm data as initial content into the initial fault context. Simultaneously, the central control decision-making agent initializes the global status blackboard to store all information related to the current fault work order. Based on a preset prompt template, the central control decision-making agent identifies that the current fault work order requires fault handling, thus activating the fault information processing agent. Furthermore, users can view the intelligent analysis status at any time in the system's work order center, such as... Figure 4 The diagram shown is of the work order center interface, and as follows: Figure 5 The diagram shows the state of intelligent analysis.

[0095] A20: Root Cause Analysis and Information Enrichment; The fault information processing agent reads the original alarm data from the initial fault context from the global state blackboard. Using this original alarm data as a retrieval index, it initiates a retrieval request to the knowledge base layer, recalling several historical cases most similar to the fault corresponding to the current fault work order and their corresponding solutions. The fault information processing agent uses the recalled similar historical cases, relevant rule knowledge from the operation and maintenance standard operating procedure document, and the original alarm data as components of the prompt words, inputting them into the large language model for semantic understanding and logical reasoning. The large language model outputs the reasoning result: the root cause of the alarm is "cell outage caused by transmission interruption," and extracts the following key features: network element name is "a certain base station," fault time is "14:00," fault level is "emergency," and associated optical path is "a certain optical cable." The fault information processing agent writes the reasoning result and extracted key features back to the global state blackboard, and the initial fault context is updated to the target fault context.

[0096] A30: Task execution sequence generation; The central control decision-making agent retrieves the above reasoning result from the global state blackboard and generates a task execution sequence corresponding to the current fault work order based on this reasoning result. This task execution sequence includes the following steps: The first step is to invoke the work order dispatching agent to execute the demarcation and dispatching task. This task is responsible for determining the person responsible for handling the fault based on the faulty network element identifier.

[0097] The second step is to invoke the message push agent to execute the notification delivery task. This task is responsible for pushing the fault details to the responsible person and listening for the receipt status.

[0098] The third step is to call the waiting module to perform the task of listening for the fault handling completion signal. This task is responsible for waiting for the handling completion signal from the operation and maintenance personnel.

[0099] The fourth step is to call the fault handling result verification agent to perform a closed-loop verification task. This task is responsible for collecting real-time performance index data for verification after receiving the processing completion signal.

[0100] The fifth step is to call the condition judgment module to execute the branch processing task of the verification result. This task is responsible for determining the subsequent process based on the verification result.

[0101] The sixth step is to invoke the fault report generation agent to perform the report archiving task. This task is responsible for generating and archiving the fault analysis report after verification.

[0102] A40: Demarcation and Dispatch Order; Following the generated task execution sequence, the central control decision-making agent first invokes the work order dispatch agent to execute the demarcation and dispatch task. The work order dispatch agent reads the faulty network element identifier "a certain base station" and the fault type "transmission interruption" from the inference results on the global status blackboard. It then queries the resource management system to confirm that "a certain base station" belongs to the "Maintenance Grid of District B, City A"; next, it queries the scheduling system to obtain the current on-duty optical cable maintenance team personnel list for District B, which is "Zhang San". The work order dispatch agent decides to dispatch the work order to "Transmission Maintenance Team of District B, City A - Zhang San" and writes the dispatch decision result to the global status blackboard.

[0103] A50: Notification delivery; The central control decision-making agent invokes the message push agent to execute the notification delivery task. The message push agent reads the dispatch decision result from the global status blackboard, identifies the target handler as "Zhang San," constructs a DingTalk message body containing information such as a fault summary ("base station cell out of service"), urgency level ("urgent"), and associated optical path ("optical cable"), and calls the DingTalk open platform API to push the message to Zhang San, while simultaneously starting polling to obtain the receipt status. The push status and receipt status are written to the global status blackboard in real time.

[0104] A60: Anomaly monitoring and dynamic adjustment; The central control decision-making agent monitors the execution feedback of each sub-agent in real time during the execution of the task execution sequence. In this embodiment, when the message push agent does not receive a "confirmation of order acceptance" receipt within 5 minutes, the central control decision-making agent determines that a task execution anomaly has occurred, with the anomaly type being "message push timeout". The central control decision-making agent obtains the anomaly type and the first fault context at the time of the anomaly as the current fault context, and inputs the anomaly type and the first fault context as prompt words into the large language model for thought chain reasoning. The large language model outputs the cause analysis as "the target personnel may be offline or busy with other tasks", and the candidate adjustment actions include "escalate the notification to the team leader" and "trigger a strong voice call reminder". The central control decision-making agent generates a dynamic adjustment strategy based on the reasoning result, which is "escalate the notification target". The central control decision-making agent adjusts the tasks that have not yet been executed in the task execution sequence based on this dynamic adjustment strategy: adding an escalation notification task executed by the message push agent in the subsequent tasks. Based on the adjusted tasks and execution order, an adjusted task execution sequence is generated.

[0105] A70: Upgrade Notice; The central control decision-making agent distributes the adjusted task execution sequence to the corresponding sub-agents. The message push agent executes the upgrade notification task, calling the TTS interface to send a strong voice call reminder to the team leader. After accepting the order, the team leader reassigns personnel to handle the fault.

[0106] A80: Handling feedback and closed-loop verification; After the maintenance personnel (Zhang San or the reassigned personnel) repair the optical cable on-site, they click "Processing Complete" on the work order mobile page. Upon receiving the processing complete signal, the central control decision-making agent invokes the fault handling result verification agent to execute a closed-loop verification task. The fault handling result verification agent reads the faulty network element identifier "a certain base station" from the global status blackboard, logs into the network management system via the southbound interface, queries the real-time status of the base station, collects real-time performance indicators such as RRC connection success rate and optical power, and compares the collected real-time data with historical data before the fault occurred. If the comparison passes, it returns verification pass information to the central control decision-making agent; if the comparison fails, it returns verification failure information. The central control decision-making agent processes the verification information: if it is verification pass information, it determines the current fault work order's execution status as completed; if it is verification failure information, it determines the current fault work order's execution status as in progress, and triggers the message push agent to send a "Verification failed, please check again" notification to the maintenance personnel, refusing to close the work order until verification passes.

[0107] A90: Report generation and archiving; After the verification result is passed, the central control decision-making agent calls the fault report generation agent to execute the report archiving task. The fault report generation agent reads all data related to the current fault work order from the global status blackboard, including raw alarm data, inference results, dispatch records, notification receipts, verification results, and timestamp information for each step. It then uses a large language model to summarize and analyze the data and generate text, outputting a structured fault analysis report. For example... Figure 6 The diagram shown illustrates a fault report. In this embodiment, the generated fault report is presented in HTML format and includes the fault duration (e.g., "1 hour 20 minutes"), root cause analysis (e.g., "optical cable interruption caused base station outage"), handling process (e.g., "dispatch to Zhang San - order accepted - on-site optical cable repair"), handler efficiency evaluation (e.g., "response time 5 minutes, repair time 1 hour 15 minutes"), and potential hazard suggestions (e.g., "optical cable in this section has recently experienced frequent interruptions; it is recommended to include it in the technical upgrade project and replace it with armored optical cable"). The report is automatically sent to the operation and maintenance management system for archiving, completing the closed-loop processing of the current fault work order.

[0108] Compared with the prior art, the solution proposed in this application has the following advantages: 1. This application utilizes a central control decision-making agent to monitor the execution feedback of each sub-agent in real time during the task execution sequence. When any task execution anomaly or deviation from the preset path is detected, a dynamic adjustment strategy is generated based on the thought chain reasoning of the current fault context and anomaly information using a large language model. The subsequent tasks that have not yet been executed are then adjusted and issued for execution. Because the large language model possesses the ability to understand fault context and anomaly information and has logical reasoning capabilities, it can autonomously generate adjustment strategies based on anomalies or deviations that occur during actual execution, without relying on preset static branches or waiting for manual intervention. This allows the fault handling process to be dynamically rearranged based on execution feedback, overcoming the problem of abnormal suspension caused by process rigidity in existing technologies, and significantly improving the system's fault tolerance and flexibility in complex fault scenarios.

[0109] 2. This application verifies the intelligent agent through fault handling results. After the maintenance personnel report the completion of the fault handling, it automatically collects real-time performance index data of relevant network elements and compares it with preset benchmark values. Based on the verification results, it determines the work order execution status as either completed or in progress. This mechanism uses objective network management index data to replace subjective human judgment as the basis for work order closure, avoiding the false closure phenomenon of "alarms cleared but services still unavailable" caused by only verifying whether alarms are cleared in existing technologies, thus ensuring the authenticity and thoroughness of fault repair.

[0110] 3. This application enables the central control decision-making agent to create a current fault work order upon receiving a network fault trigger signal, and to construct a fault context that is dynamically updated along with the work order processing flow. This fault context serves as a globally shared information carrier, and new information is continuously written into it during the execution of tasks by each sub-agent. This allows the central control decision-making agent to make decisions based on a complete and real-time fault context when performing thought chain reasoning, without the need for repeated cross-system queries or manual summarization. This solves the problem of information silos and improves the efficiency and accuracy of multi-agent collaborative decision-making.

[0111] In summary, this application achieves fully automated orchestration and data sharing of the entire process from fault perception, root cause analysis, boundary assignment, notification delivery, closed-loop verification to report archiving through the division of labor and cooperation mechanism between the overall control decision-making intelligent agent and each sub-intelligent agent. This eliminates the breakpoints of manual cross-system operations and significantly improves the timeliness of operator network fault handling and overall operation and maintenance efficiency.

[0112] Based on and Figure 1 The method shown in the example follows the same principle. This embodiment of the invention also provides a multi-agent collaborative operator network fault handling device 20 based on a large language model, such as... Figure 7 As shown, the multi-agent collaborative operator network fault handling device 20 based on a large language model may include an acquisition module 210, a task execution sequence generation module 220, a policy adjustment module 230, and a closed-loop processing module 240, wherein: The acquisition module 210 is used to acquire and create a corresponding current fault work order based on the network fault trigger signal of the monitoring system, and construct the target fault context corresponding to the current fault work order. The task execution sequence generation module 220 is used to obtain the reasoning result obtained by the fault information processing agent through semantic understanding and logical reasoning of the target fault context based on the large language model, and to generate a task execution sequence based on the reasoning result. The task execution sequence describes the calling order and calling method of at least one sub-agent. The strategy adjustment module 230 is used to monitor the execution feedback of each sub-agent in real time during the execution of the task execution sequence. When any task execution abnormality or process deviation from the preset path is detected based on the execution feedback, the module performs thought chain reasoning on the current fault context corresponding to the execution abnormality or process deviation from the preset path based on the large language model, generates a dynamic adjustment strategy, and adjusts the subsequent tasks that have not yet been executed in the task execution sequence based on the dynamic adjustment strategy to obtain the adjusted task execution sequence. The closed-loop processing module 240 is used to send the adjusted task execution sequence to the corresponding sub-intelligent agents for execution until the current fault work order completes the closed-loop processing.

[0113] Optionally, when the acquisition module 210 acquires and creates a corresponding current fault work order based on the network fault trigger signal of the monitoring system, and constructs the target fault context corresponding to the current fault work order, it is specifically used for: Obtain the original alarm data from the network fault trigger signal, and create the current fault work order based on the original alarm data; The original alarm data is written into the initial fault context as the initial content, and the fault information processing agent is triggered to read the original alarm data from the initial fault context to extract key features and write the key features back into the initial fault context to obtain the target fault context.

[0114] Optionally, the above-mentioned device further includes: The update module is used to update the target fault context by calling sub-agents and / or querying external systems to obtain supplementary information during the processing of the current fault work order.

[0115] Optionally, when the strategy adjustment module 230 detects any task execution anomaly or process deviation from the preset path based on various execution feedbacks, and generates a dynamic adjustment strategy by performing thought chain reasoning on the current fault context corresponding to the execution anomaly or process deviation from the preset path based on a large language model, it is specifically used for: When an execution anomaly is detected based on various execution feedbacks, the anomaly type and the first fault context at the time of the anomaly are obtained as the current fault context; or... When the process deviates from the preset path based on various execution feedbacks, the deviation information at the time of the deviation and the second fault context at the time of the deviation are obtained as the current fault context. The anomaly type and the first fault context, or the deviation information and the second fault context, are used as prompt words to input into the large language model for thought chain reasoning to obtain the reasoning results. The reasoning results include at least the cause analysis and one or more candidate adjustment actions. A dynamic adjustment strategy is generated based on the reasoning results.

[0116] Optionally, the above-mentioned sub-intelligent agents include a fault information processing intelligent agent, a work order dispatch intelligent agent, a message push intelligent agent, a fault processing result verification intelligent agent, and a fault report generation intelligent agent; During the execution of the task execution sequence, the execution feedback of the fault information processing agent includes: whether the root cause analysis was successful, the key feature data extracted, and the intermediate results generated during the analysis. The execution feedback of the work order dispatching agent includes: whether the dispatch was successful, the target processing object information, and the reason for the failure when the dispatch fails; The execution feedback of the message push agent includes: whether the message was successfully pushed, whether the target person has read or confirmed the order, and whether there was no response after timeout; The execution feedback of the fault handling result verification agent includes: whether the verification was successful, real-time performance index data of the network element, and the result of verification pass or fail; The execution feedback of the fault report generating agent includes: whether the report was successfully generated and the report storage path.

[0117] Optionally, the aforementioned dynamic adjustment strategy includes at least one of the following: automatically expanding the resource search scope, changing the target processing object, or upgrading the notification object. When the strategy adjustment module 230 adjusts subsequent tasks that have not yet been executed in the task execution sequence based on the dynamic adjustment strategy to obtain the adjusted task execution sequence, it is specifically used for: When the dynamic adjustment strategy is to automatically expand the resource search scope, the search scope of the first task executed by the work order dispatch agent in the subsequent tasks is expanded, and the query parameters in the first task are updated. When the dynamic adjustment strategy is to change the target processing object, the work order recipient determined by the second task executed by the work order dispatch agent in the subsequent task will be replaced with the new work order recipient. When the dynamic adjustment strategy is to upgrade the notification target, an upgrade notification task executed by the message push agent will be added in the subsequent tasks; Based on the adjusted tasks and execution order, generate the adjusted task execution sequence.

[0118] Optionally, the above-mentioned device further includes: The verification module is used to respond to the fault handling completion signal reported by the maintenance personnel. Based on the fault handling result, the verification agent performs the following steps to obtain verification information: acquire real-time performance index data of the relevant network elements; compare the real-time performance index data with preset benchmark values; if the comparison passes, return verification pass information to the central control decision agent; if the comparison fails, return verification failure information to the central control decision agent; if the verification information is verification pass, the execution status of the current fault work order is determined to be completed; if the verification information is verification failure, the execution status of the current fault work order is determined to be in progress, and a message push agent is triggered to send a notification for re-check to the maintenance personnel.

[0119] The multi-agent cooperative operator network fault handling device based on a large language model in this embodiment of the invention can execute the multi-agent cooperative operator network fault handling method based on a large language model provided in this embodiment of the invention. The implementation principle is similar. The actions performed by each module and unit in the multi-agent cooperative operator network fault handling device based on a large language model in each embodiment of the invention correspond to the steps in the multi-agent cooperative operator network fault handling method based on a large language model in each embodiment of the invention. For detailed functional descriptions of each module of the multi-agent cooperative operator network fault handling device based on a large language model, please refer to the descriptions in the corresponding multi-agent cooperative operator network fault handling methods based on a large language model shown above, which will not be repeated here.

[0120] The aforementioned multi-agent cooperative operator network fault handling device based on a large language model can be a computer program (including program code) running on a computer device. For example, the multi-agent cooperative operator network fault handling device based on a large language model is an application software. The device can be used to execute the corresponding steps in the method provided in the embodiments of the present invention.

[0121] In some embodiments, the multi-agent cooperative operator network fault handling device based on a large language model provided in this invention can be implemented using a combination of hardware and software. As an example, the multi-agent cooperative operator network fault handling device based on a large language model provided in this invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the multi-agent cooperative operator network fault handling method based on a large language model provided in this invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0122] In other embodiments, the multi-agent collaborative operator network fault handling device based on a large language model provided in this invention can be implemented in software. Figure 7A multi-agent cooperative operator network fault handling device based on a large language model, stored in a memory, is shown. It can be software in the form of programs and plug-ins, and includes a series of modules, including an acquisition module 210, a task execution sequence generation module 220, a policy adjustment module 230, and a closed-loop processing module 240, for implementing the multi-agent cooperative operator network fault handling method based on a large language model provided in the embodiments of the present invention.

[0123] The modules described in the embodiments of the present invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0124] Based on the same principles as the methods shown in the embodiments of the present invention, the embodiments of the present invention also provide an electronic device, which may include, but is not limited to: a processor and a memory; the memory for storing computer programs; and the processor for executing the methods shown in any embodiment of the present invention by invoking the computer programs.

[0125] In one alternative embodiment, an electronic device is provided, such as Figure 8 As shown, Figure 8 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0126] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0127] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0128] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0129] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0130] Among these, electronic devices can also be terminal devices. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0131] This invention provides a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to execute the corresponding content in the aforementioned method embodiments.

[0132] According to another aspect of the present invention, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various embodiments described above.

[0133] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0134] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0135] The computer-readable storage medium provided in this invention can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0136] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0137] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A multi-agent collaborative operator network fault handling method based on a large language model, characterized in that, The method, applied to a central control decision-making intelligent agent, includes: Obtain and create a corresponding current fault work order based on the network fault trigger signal of the monitoring system, and construct the target fault context corresponding to the current fault work order; The reasoning result obtained by the fault information processing agent through semantic understanding and logical reasoning of the target fault context based on a large language model is obtained, and a task execution sequence is generated based on the reasoning result. The task execution sequence describes the calling order and calling method of at least one sub-agent. During the execution of the task execution sequence, the execution feedback of each sub-agent is monitored in real time. When any task execution abnormality or process deviation from the preset path is detected based on the execution feedback, the current fault context corresponding to the execution abnormality or process deviation from the preset path is reasoned based on the large language model to generate a dynamic adjustment strategy. The subsequent tasks that have not yet been executed in the task execution sequence are adjusted based on the dynamic adjustment strategy to obtain the adjusted task execution sequence. The adjusted task execution sequence is sent to the corresponding sub-agents for execution until the current fault work order completes closed-loop processing.

2. The method according to claim 1, characterized in that, The process of acquiring and creating a corresponding current fault work order based on the network fault trigger signal from the monitoring system, and constructing the target fault context corresponding to the current fault work order, includes: Obtain the original alarm data from the network fault trigger signal, and create the current fault work order based on the original alarm data; The original alarm data is written into the initial fault context as initial content, and the fault information processing agent is triggered to read the original alarm data from the initial fault context to extract key features and write the key features back into the initial fault context to obtain the target fault context.

3. The method according to claim 2, characterized in that, The method further includes: During the processing of the current fault work order, supplementary information is obtained by calling sub-intelligent agents and / or querying external systems to update the target fault context.

4. The method according to any one of claims 1 to 3, characterized in that, When any task execution anomaly or process deviation from the preset path is detected based on the execution feedback, a dynamic adjustment strategy is generated by performing thought chain reasoning on the current fault context corresponding to the execution anomaly or process deviation from the preset path based on the large language model, including: When any task execution exception is detected based on the execution feedback, the exception type and the first fault context at the time of the exception are obtained as the current fault context; or... When a process deviation from a preset path is detected based on the execution feedback, the deviation information at the time of the process deviation and the second fault context at the time of the deviation are obtained as the current fault context. The anomaly type and the first fault context, or the deviation information and the second fault context, are used as prompt words to input into the large language model for thought chain reasoning to obtain reasoning results. The reasoning results include at least cause analysis and one or more candidate adjustment actions. The dynamic adjustment strategy is generated based on the reasoning results.

5. The method according to any one of claims 1 to 3, characterized in that, Each of the sub-intelligent agents includes a fault information processing intelligent agent, a work order dispatch intelligent agent, a message push intelligent agent, a fault processing result verification intelligent agent, and a fault report generation intelligent agent. During the execution of the task execution sequence, the execution feedback of the fault information processing agent includes: whether the root cause analysis was successful, the extracted key feature data, and the intermediate results generated during the analysis. The execution feedback of the work order dispatching agent includes: whether the dispatch was successful, the target processing object information, and the reason for failure when the dispatch fails. The execution feedback of the message push agent includes: whether the message was successfully pushed, whether the target person has read or confirmed the order, and whether there was no response after timeout; The execution feedback of the fault handling result verification agent includes: whether the verification was successful, real-time performance index data of the network element, and the result of verification passing or failing. The execution feedback of the fault report generating agent includes: whether the report was successfully generated and the report storage path.

6. The method according to any one of claims 1 to 3, characterized in that, The dynamic adjustment strategy includes at least one of the following: automatically expanding the resource search scope, changing the target processing object, or upgrading the notification object. The adjustment of subsequent tasks that have not yet been executed in the task execution sequence based on the dynamic adjustment strategy to obtain the adjusted task execution sequence includes: When the dynamic adjustment strategy is to automatically expand the resource search range, the search range of the first task executed by the work order dispatch agent in the subsequent tasks is expanded, and the query parameters in the first task are updated. When the dynamic adjustment strategy is to change the target processing object, the work order recipient determined based on the second task executed by the work order dispatch agent in the subsequent task will be replaced with a new work order recipient. When the dynamic adjustment strategy is to upgrade the notification target, an upgrade notification task executed by the message push agent is added to the subsequent tasks; Based on the adjusted tasks and execution order, generate the adjusted task execution sequence.

7. The method according to any one of claims 1 to 3, characterized in that, The method further includes: In response to the fault handling completion signal from the maintenance personnel, the verification agent executes the following steps based on the fault handling result to obtain verification information: Obtain real-time performance metrics data for relevant network elements; The real-time performance index data is compared with a preset benchmark value; If the comparison passes, a verification pass message is returned to the overall control decision-making intelligent agent; If the comparison fails, a verification failure message is returned to the overall control decision-making agent; If the verification information is a verification pass, the execution status of the current fault work order is determined to be completed. If the verification information is a verification failure, the execution status of the current fault work order is determined to be in progress, and a message push agent is triggered to send a notification to the maintenance personnel to re-check.

8. A multi-agent collaborative operator network fault handling device based on a large language model, characterized in that, The device, applied to a central control decision-making intelligent agent, includes: The acquisition module is used to acquire and create a corresponding current fault work order based on the network fault trigger signal of the monitoring system, and construct the target fault context corresponding to the current fault work order; The task execution sequence generation module is used to obtain the reasoning result obtained by the fault information processing agent through semantic understanding and logical reasoning of the target fault context based on a large language model, and to generate a task execution sequence based on the reasoning result. The task execution sequence describes the calling order and calling method of at least one sub-agent. The strategy adjustment module is used to monitor the execution feedback of each sub-agent in real time during the execution of the task execution sequence. When any task execution abnormality or process deviation from the preset path is detected based on the execution feedback, the module performs thought chain reasoning on the current fault context corresponding to the execution abnormality or process deviation from the preset path based on the large language model, generates a dynamic adjustment strategy, and adjusts the subsequent tasks that have not yet been executed in the task execution sequence based on the dynamic adjustment strategy to obtain the adjusted task execution sequence. The closed-loop processing module is used to distribute the adjusted task execution sequence to the corresponding sub-agents for execution until the current fault work order completes the closed-loop processing.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images