An operation and maintenance system and method based on predictive alarm and intelligent agent execution

Abstract

The application provides an operation and maintenance system and method based on predictive alarm and intelligent agent execution. A full-link data collection module collects system performance index data, log data and link tracking data. A predictive alarm engine inputs the above data into a time series prediction model, outputs a comprehensive risk score based on the deviation of the prediction result from the normal baseline, and generates a hierarchical early warning information. An intelligent analysis module clusters and merges homologous alarms based on the semantics of the early warning information, locates the fault root cause node in combination with an operation and maintenance knowledge graph, and retrieves a repair strategy. An AI Agent execution module generates an operation and maintenance execution plan by using a large language model, executes the plan in stages according to the early warning level after constraint verification, creates a system snapshot before execution, verifies the system state after execution, and automatically rolls back when there is a discrepancy. A learning and optimization module writes the execution result into a historical fault library, and updates the prediction model and the knowledge graph. The application can shorten the fault response delay and improve the operation and maintenance automation level.

Description

Technical Field

[0001] This application relates to the field of intelligent operation and maintenance technology, and in particular to an operation and maintenance system and method based on predictive alarms and intelligent agent execution. Background Technology

[0002] With the rapid expansion of enterprise digital businesses, the number of server nodes, microservice instances, and data processing tasks in the operation and maintenance environment has increased dramatically, leading to a continuous rise in system architecture complexity. Traditional operation and maintenance monitoring systems, centered on static thresholds and post-event alarms, not only fail to identify risks before failures actually occur but are also prone to triggering a large number of cascading alarms due to single-point failures, creating an alarm storm that drowns out alarms that truly require urgent attention. When faced with massive alarms, operation and maintenance personnel must rely on personal experience for manual troubleshooting and root cause location. The efficiency of handling these issues is highly dependent on key individuals, resulting in structural defects such as single-point knowledge risk and long response cycles.

[0003] In scenarios such as quantitative trading, where latency and system stability are extremely sensitive, these problems are even more pronounced. While existing intelligent O&M solutions incorporate anomaly detection algorithms and can identify some anomaly patterns, they generally remain at the stage of alarm noise reduction or handling suggestions, lacking the closed-loop execution capability to directly translate alarm analysis into repair operations. Simultaneously, O&M work order systems still rely primarily on manual assignment and operation, resulting in slow work order processing and failing to meet the timeliness requirements of production environment fault response. Summary of the Invention

[0004] To address the aforementioned issues, this application provides an operation and maintenance system and method based on predictive alarms and intelligent agent execution. It acquires multi-dimensional monitoring data of the operation and maintenance environment through end-to-end data collection, uses a time-series prediction model to predict future trends of system performance indicators and generate tiered early warnings, achieves alarm compression and root cause localization through semantic clustering and an operation and maintenance knowledge graph, and uses an AI agent to generate operation and maintenance execution plans based on a large language model and execute them according to the early warning level. Furthermore, it uses closed-loop learning to feed back handling experience to a historical fault database to continuously optimize the prediction model and knowledge graph, thereby shortening fault response latency and reducing manual intervention.

[0005] The first aspect of this application proposes an operation and maintenance system based on predictive alarms and intelligent agent execution, comprising: The system includes a full-link data acquisition module, a predictive alarm engine, an operations and maintenance knowledge graph, an intelligent analysis module, an AI Agent execution module, and a learning and optimization module. The end-to-end data acquisition module is used to continuously collect system performance metrics, log data, and link tracing data in the operation and maintenance environment. The system performance metrics include server CPU utilization, memory usage, disk I / O rate, network traffic, as well as queue depth, execution latency, and data processing latency of operation and maintenance tasks. The predictive alarm engine is connected to the end-to-end data acquisition module and is used to input the system performance index data, the log data, and the link tracing data into the time-series prediction model. The time-series prediction model is trained based on historical operation and maintenance data and is used to predict the future trend corresponding to the system performance index data, and output a comprehensive risk score of the operation and maintenance environment based on the degree of deviation of the prediction result from the normal baseline. The predictive alarm engine is also used to generate warning information carrying corresponding warning levels based on the risk score and preset level thresholds; the warning levels include first-level warning, second-level warning and third-level warning; The operation and maintenance knowledge graph stores system components, inter-component dependencies, fault propagation paths, and handling strategies in a graph structure. It is composed of static knowledge imported from the configuration management database and dynamic knowledge extracted from the historical fault database. The intelligent analysis module is connected to the predictive alarm engine and the operation and maintenance knowledge graph, respectively. It is used to perform semantic clustering on the early warning information to merge alarms from the same source and generate alarm events from the same source. The alarm events from the same source are associated with the operation and maintenance knowledge graph. A reverse search is performed along the fault propagation path to locate the root cause node of the fault. The repair strategy corresponding to the root cause node of the fault is retrieved from the operation and maintenance knowledge graph. The AI ​​Agent execution module, connected to the intelligent analysis module, is used to receive the root cause node of the fault and the repair strategy. A large language model generates an operation and maintenance execution plan based on the repair strategy and the current system state. The operation and maintenance execution plan undergoes constraint verification, and the operation and maintenance execution plan that passes the constraint verification is determined as the target plan. When the warning level is the first level, the module autonomously executes the operation steps in the target plan; when the warning level is the second level, the module executes the operation steps after receiving an external confirmation signal. The AI ​​Agent execution module is also used to create a system snapshot before executing each operation step, verify the system state after the operation step is executed, and perform a rollback using the system snapshot when the verification result does not match the expectation, generate an audit log for the execution process of the operation step, and output the execution result of the operation step and the verification result. The learning and optimization module is connected to the AI ​​Agent execution module and is used to write the execution results, the verification results and the audit logs into the historical fault database to update the historical operation and maintenance data and the dynamic knowledge.

[0006] An operation and maintenance system based on predictive alarms and intelligent agent execution according to the first aspect of the embodiments of this application has at least the following beneficial effects: The predictive alarm engine uses the NBEATS model to jointly predict the future trends of multiple system performance indicators. Combined with a tiered early warning mechanism, alarms caused by a single fault are compressed into alarms from the same source, and different notification strategies are adopted according to the early warning level to alleviate alarm fatigue. The intelligent analysis module uses BERT semantic clustering and knowledge graph reverse search to automatically locate the root cause, shortening the fault diagnosis time. The AI ​​Agent execution module performs constraint verification after generating the operation and maintenance execution plan, executes according to the early warning level, and forms a rollback-safe execution mechanism through pre-operation system snapshots and post-operation status verification, keeping autonomous operations within a controllable range. The learning and optimization module continuously feeds the handling results back to the historical fault database, driving the predictive model and knowledge graph to iteratively update, improving the system's prediction accuracy and handling efficiency for known fault types. This embodiment realizes the autonomous execution of fault risk prediction and repair operations.

[0007] In one possible implementation, the predictive alarm engine includes: an N-BEATS prediction unit, a risk calculation unit, and a graded early warning unit; The N-BEATS prediction unit is used to predict the trend of the system performance index data; The risk calculation unit is used to compare the prediction results with the historical normal fluctuation range and calculate the joint risk probability corresponding to the system performance index data. The graded early warning unit is used to generate a first-level early warning, a second-level early warning, or a third-level early warning based on a preset interval where the joint risk probability is located; when the early warning level is the first-level early warning, an alarm notification is sent to the operation and maintenance terminal immediately; when the early warning level is the second-level early warning, the early warning information is summarized and periodically pushed to the operation and maintenance terminal; when the early warning level is the third-level early warning, the early warning information is written to the early warning log. The predictive alarm engine is also used to configure corresponding target sensitivity parameters for the system components; the system components include core components and auxiliary components; a first sensitivity parameter is configured for the core components, and a second sensitivity parameter is configured for the auxiliary components; the first sensitivity parameter is higher than the second sensitivity parameter.

[0008] In one possible implementation, the intelligent analysis module includes: a semantic clustering unit and a root cause localization unit; The semantic clustering unit has a built-in BERT model, which is used to extract the semantic vector of the warning information and merge the warning information describing the same fault into the same source alarm event by vector similarity. The root cause localization unit is used to match the same source alarm events with component nodes in the operation and maintenance knowledge graph, and perform a reverse search along the fault propagation path to locate the fault root cause node.

[0009] In one possible implementation, the AI ​​Agent execution module includes: a perception layer, a planning layer, an execution layer, and a verification layer; The perception layer is used to receive the root cause node of the fault and the repair strategy; The planning layer is used to call the large language model, generate the operation and maintenance execution plan based on the repair strategy, the operation and maintenance knowledge graph and the current system status, and dynamically adjust the subsequent steps corresponding to the operation steps based on the execution results during the execution of the target plan. The execution layer is used to interact with the protocol adaptation service of each target system through a unified tool call protocol; the protocol adaptation service encapsulates the system interfaces of each target system into a set of tool descriptions that conform to the unified tool call protocol, so that the decision logic of the planning layer is isolated from each system interface; The verification layer is used to verify the post-execution system state after each of the operation steps is completed, and to perform the rollback using the system snapshot when the verification result does not match the expectation.

[0010] In one possible implementation, the system further includes a work order processing module; the work order processing module is connected to the work order system via a standardized adapter interface, and is used to receive new work orders pushed by the work order system, perform semantic parsing and urgency assessment on the new work orders, determine the target handling entity by combining the historical response database of the handling entity and the current load status, and send the work order status information to the target handling entity through a message push interface; and write the handling result of the new work order into the historical response database of the handling entity.

[0011] The second aspect of this application proposes an operation and maintenance method based on predictive alarms and intelligent agent execution, including the following steps: Collect system performance metrics, log data, and trace data from the operation and maintenance environment; The system performance index data, the log data, and the link tracing data are input into the time series prediction model. The time series prediction model predicts the future trend corresponding to the system performance index data and outputs a comprehensive risk score of the operation and maintenance environment based on the degree of deviation of the prediction result from the normal baseline. Based on the comprehensive risk score and preset level thresholds, warning information carrying corresponding warning levels is generated; the warning levels include first-level warning, second-level warning, and third-level warning. The warning information is semantically clustered to merge alarms from the same source and generate alarm events from the same source. The alarm events from the same source are associated with the operation and maintenance knowledge graph, and a reverse search is performed along the fault propagation path to locate the root cause node of the fault. The repair strategy corresponding to the root cause node of the fault is retrieved from the operation and maintenance knowledge graph. The operation and maintenance knowledge graph stores system components, inter-component dependencies, fault propagation paths and handling strategies in a graph structure. It is composed of static knowledge imported from the configuration management database and dynamic knowledge extracted from the historical fault database. The large language model generates an operation and maintenance execution plan based on the repair strategy and the current system status. The operation and maintenance execution plan is then subject to constraint verification, and the operation and maintenance execution plan that passes the constraint verification is determined as the target plan. When the warning level is the first level warning, the operation steps in the target plan are executed autonomously; when the warning level is the second level warning, the operation steps are executed after receiving an external confirmation signal. Before performing each of the above operation steps, a system snapshot is created. After the operation steps are performed, the system status after the execution is verified. If the verification result does not match the expectation, the system snapshot is used to perform a rollback. An audit log is generated for the execution process of the operation steps, and the execution result of the operation steps and the verification result are output. The execution results, the verification results, and the audit logs are written into the historical fault database to update the historical operation and maintenance data and the dynamic knowledge of the time series prediction model.

[0012] In one possible implementation, generating warning information carrying the corresponding warning level includes: The N-BEATS model is used to predict the trend of the system performance index data. The predicted results of the trend forecast are compared with the historical normal fluctuation range to calculate the joint risk probability corresponding to the system performance index data. Based on the preset range in which the joint risk probability lies, generate a first-level warning, a second-level warning, or a third-level warning. When the warning level is the first level, an alarm notification is sent to the operation and maintenance terminal immediately; when the warning level is the second level, the warning information is summarized and pushed to the operation and maintenance terminal periodically; when the warning level is the third level, the warning information is written to the warning log.

[0013] In one possible implementation, the step of semantically clustering the warning information to merge similar alarms and generate similar alarm events includes: The semantic vector of the warning information is extracted using the BERT model; By calculating the similarity between the semantic vectors, the warning information describing the same fault is merged into the same-source alarm event.

[0014] In one possible implementation, it also includes: When a new work order is received, semantic parsing and urgency assessment are performed on the new work order. The corresponding target handling entity is determined by combining the historical response database of the handling entity and the current load status. The work order status information is then sent to the target handling entity through the message push interface. The processing result of the new work order is written into the historical response database of the processing entity.

[0015] The operation and maintenance method based on predictive alarms and intelligent agent execution according to the second aspect of the embodiments of this application has at least the following beneficial effects: By combining multivariate time-series prediction with multi-level confidence alerts, potential risks are identified before actual failures occur, providing the operations and maintenance team with a sufficient intervention window and shifting the operations and maintenance model from passive response to proactive defense. Through semantic clustering and correlation analysis with the operations and maintenance knowledge graph, alarm storms are compressed into homogeneous alarm events, and the root cause of failures is automatically located, reducing the reliance on personal experience in root cause analysis. A large language model dynamically generates operations and maintenance execution plans based on repair strategies and the current system state. After constraint verification, these plans are autonomously executed according to the alert level, with system snapshots and state verification mechanisms introduced before and after each operation. Repair operations are performed within safety boundaries, and failure rollback is supported. Through a learning and optimization module, each handling experience is written back to the historical fault database, ensuring continuous updates to the predictive model and knowledge graph, improving the system's adaptability to new faults and its handling efficiency.

[0016] A third aspect of this application provides a readable medium including executable instructions, which, when executed by a processor of an electronic device, cause the electronic device to perform any of the methods described in the second aspect. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of the structure of an operation and maintenance system based on predictive alarms and intelligent agent execution, provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a predictive alarm engine in an operation and maintenance system based on predictive alarms and intelligent agent execution, provided in an embodiment of this application. Figure 3 This is a schematic diagram of the structure of an intelligent analysis module in an operation and maintenance system based on predictive alarms and intelligent agent execution, provided in an embodiment of this application. Figure 4 This is a schematic diagram of the structure of an AI Agent execution module in an operation and maintenance system based on predictive alarms and intelligent agent execution, provided in an embodiment of this application; Figure 5 This is a flowchart illustrating an operation and maintenance method based on predictive alarms and intelligent agent execution, provided in one embodiment of this application. Detailed Implementation

[0019] The embodiments of this implementation are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this implementation, and should not be construed as limiting this implementation.

[0020] In the description of this embodiment, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this embodiment and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this embodiment.

[0021] In the description of this embodiment, "several" means one or more, "multiple" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0022] In the description of this embodiment, unless otherwise explicitly limited, terms such as setting, installing, and connecting should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this embodiment in conjunction with the specific content of the technical solution.

[0023] Please refer to Figure 1 The diagram illustrates the structure of an operation and maintenance system based on predictive alerting and intelligent agent execution according to one embodiment of this application. The system includes a full-link data acquisition module 101, a predictive alerting engine 102, an operation and maintenance knowledge graph 103, an intelligent analysis module 104, an AI Agent execution module 105, and a learning and optimization module 106.

[0024] In this embodiment, the end-to-end data acquisition module 101, the predictive alarm engine 102, the operation and maintenance knowledge graph 103, the intelligent analysis module 104, the AI ​​Agent execution module 105, and the learning and optimization module 106 work together to form an end-to-end operation and maintenance closed loop covering fault prediction, alarm analysis, autonomous execution, and continuous optimization.

[0025] The end-to-end data acquisition module 101 is responsible for continuously acquiring raw data from the operation and maintenance environment and sending it to the predictive alarm engine 102 for anomaly trend prediction. The early warning information generated by the predictive alarm engine 102 is transmitted to the intelligent analysis module 104, which combines the operation and maintenance knowledge graph 103 to complete alarm clustering and root cause localization, and transmits the localization results along with the repair strategy to the AI ​​Agent execution module 105. The AI ​​Agent execution module 105 performs repair operations autonomously or waits for external confirmation according to hierarchical permissions, and outputs the execution process and results to the learning and optimization module 106. The learning and optimization module 106 writes new fault handling experience back to the historical fault database, forming a continuous iterative self-optimization capability.

[0026] The end-to-end data acquisition module 101 is used to continuously collect system performance metrics, log data, and link tracing data in the operation and maintenance environment. The system performance metrics include server CPU utilization, memory usage, disk I / O rate, network traffic, as well as queue depth, execution latency, and data processing latency of operation and maintenance tasks.

[0027] In this embodiment, the end-to-end data acquisition module 101 deploys acquisition probes in the operation and maintenance environment to continuously sample system performance index data, log data and link tracing data at fixed time intervals, and unifies the collected raw data into a data buffer queue for downstream modules to read as needed.

[0028] System performance metrics reflect the real-time consumption of server hardware resources, log data records the structured and unstructured event information output by each service component during operation, and tracing data describes the transmission path and time distribution of requests between microservice nodes.

[0029] Taking data processing tasks as an example, the continuous accumulation of queue depth often precedes a significant increase in task execution latency. By collecting two types of indicators simultaneously and establishing their temporal correlation, potential risk signals can be identified before the latency problem worsens.

[0030] The predictive alarm engine 102, connected to the end-to-end data acquisition module 101, is used to input system performance index data, log data, and link tracing data into the time-series prediction model. The time-series prediction model is trained based on historical operation and maintenance data and is used to predict the future trend corresponding to the system performance index data. Based on the degree of deviation of the prediction result from the normal baseline, it outputs a comprehensive risk score of the operation and maintenance environment. The predictive alarm engine 102 is also used to generate warning information carrying the corresponding warning level according to the risk score and preset level threshold. The warning levels include first-level warning, second-level warning, and third-level warning.

[0031] In this embodiment, the normal baseline is automatically established by the time-series prediction model during the training phase based on the normal fluctuation distribution of various indicators in historical operation and maintenance data. It reflects the expected value range of each indicator under different time windows, replacing the static thresholds manually set by operation and maintenance personnel. Compared with static thresholds, the normal baseline can adapt to the periodic fluctuations of indicators between business peaks and troughs, thereby reducing false alarms caused by normal business fluctuations.

[0032] The comprehensive risk score is calculated by jointly assessing the deviation of multiple indicator predictions from the normal baseline. A slight deviation in a single indicator will not directly trigger a high-level warning; only when multiple indicators simultaneously show abnormal trends will the comprehensive risk score exceed a higher level threshold. This mechanism improves the accuracy of warnings. The classification of warning levels allows the system to adopt differentiated notification strategies for anomalies of varying urgency, avoiding the frequent push of irrelevant warnings.

[0033] Please refer to Figure 2 The diagram illustrates the structure of a predictive alarm engine 102 in an operation and maintenance system based on predictive alarms and intelligent agent execution, according to an embodiment of this application. The predictive alarm engine 102 includes: an N-BEATS prediction unit 1021, a risk calculation unit 1022, and a graded early warning unit 1023.

[0034] The N-BEATS prediction unit 1021, risk calculation unit 1022, and graded early warning unit 1023 are connected in series to complete the entire transformation process from raw data to graded early warning information. The N-BEATS prediction unit 1021 is responsible for extrapolating the time series data of various indicators. The risk calculation unit 1022 compares the extrapolation results with the historical normal fluctuation range and quantifies the degree of deviation. The graded early warning unit 1023 determines the early warning level based on the quantification results and executes the corresponding notification action.

[0035] The N-BEATS prediction unit 1021 is used to predict the trend of system performance index data.

[0036] The N-BEATS prediction unit 1021 employs an N-BEATS neural network architecture to model the historical time series of various system performance indicators and extrapolate trends to several future time steps. The N-BEATS architecture consists of multiple stacked residual blocks, each of which decomposes and fits the trend and periodic components of the time series data, giving the prediction results strong adaptability to operational indicators with periodic fluctuations. Taking CPU utilization as an example, the N-BEATS prediction unit 1021 can not only capture its periodic upward trend during peak business periods but also identify abnormal upward trends that deviate from the periodic pattern.

[0037] The risk calculation unit 1022 is used to compare the prediction results with the historical normal fluctuation range and calculate the joint risk probability corresponding to the system performance index data.

[0038] The historical normal fluctuation range is determined by the statistical distribution of each indicator in the training dataset, reflecting the confidence interval boundary of the indicator under normal operating conditions. The risk calculation unit 1022 compares the predicted value output by the N-BEATS prediction unit 1021 with the historical normal fluctuation range, calculates the probability that the predicted value falls outside the normal range, and jointly calculates the individual risk probabilities of multiple indicators, outputting a comprehensive risk score reflecting the overall degree of anomaly in the operation and maintenance environment. The purpose of the joint calculation is to avoid the occasional fluctuations of a single indicator having an excessive impact on the comprehensive score; only when multiple related indicators simultaneously show abnormal trends will the comprehensive risk score increase significantly.

[0039] The graded early warning unit 1023 is used to generate a first-level early warning, a second-level early warning, or a third-level early warning based on the preset interval where the joint risk probability is located. When the early warning level is a first-level early warning, an alarm notification is sent to the operation and maintenance terminal immediately. When the early warning level is a second-level early warning, the early warning information is summarized and pushed to the operation and maintenance terminal periodically. When the early warning level is a third-level early warning, the early warning information is written to the early warning log.

[0040] The preset intervals are configured by operations and maintenance personnel according to the actual scenario, dividing the range of values ​​for the joint risk probability into intervals corresponding to three warning levels. The first-level warning corresponds to the interval with the highest joint risk probability, indicating that there is a serious abnormal risk in the system that requires immediate intervention. The graded warning unit 1023 will immediately push an alarm notification to the operations and maintenance terminal, requiring operations and maintenance personnel to respond immediately.

[0041] The second-level warning corresponds to a medium combined risk probability range, indicating that there are noteworthy but not urgent abnormal trends in the system. The tiered warning unit 1023 will collect warning information of the same level within a preset time period, summarize it, and then push it out uniformly to avoid frequently disturbing maintenance personnel. The third-level warning corresponds to the range with the lowest combined risk probability, indicating that there are slight deviations in system indicators, but they are still within an acceptable range. The tiered warning unit 1023 only writes the warning information to the warning log for maintenance personnel to refer to in post-event analysis, without triggering active notifications.

[0042] The predictive alarm engine 102 is also used to configure corresponding target sensitivity parameters for system components; the system components include core components and auxiliary components; a first sensitivity parameter is configured for the core components, and a second sensitivity parameter is configured for the auxiliary components; the first sensitivity parameter is higher than the second sensitivity parameter.

[0043] Sensitivity parameters determine the lower limit of the joint risk probability threshold corresponding to each system component when an early warning is triggered. The first sensitivity parameter corresponds to a lower trigger threshold, allowing core components to trigger early warnings when the overall risk score is low, thus providing maintenance personnel with a more ample intervention window. The second sensitivity parameter corresponds to a higher trigger threshold, ensuring that auxiliary components only trigger early warnings when the overall risk score reaches a high level, thereby reducing early warning information generated by low-impact components.

[0044] Operations and maintenance knowledge graph 103 stores system components, inter-component dependencies, fault propagation paths, and handling strategies in a graph structure. It is composed of static knowledge imported from the configuration management database and dynamic knowledge extracted from the historical fault database.

[0045] In this embodiment, the operation and maintenance knowledge graph 103 organizes operation and maintenance domain knowledge in the form of a directed graph. Each node in the graph corresponds to a system component, and the directed edges between nodes represent the dependencies between components or the direction of fault propagation.

[0046] Static knowledge originates from the configuration management database and includes attribute information and topological connections of various system components, reflecting the objective structure of the operation and maintenance environment under the current configuration. Dynamic knowledge is extracted from the historical fault database by the learning and optimization module 106, including the propagation paths of historical faults, corresponding handling strategies, and evaluation of handling effects, and is continuously enriched as the historical fault database is continuously accumulated.

[0047] The combination of static and dynamic knowledge enables the operation and maintenance knowledge graph 103 to accurately describe the current topology of the system while also preserving practically verified handling experience. Taking a network component failure as an example, the operation and maintenance knowledge graph 103 stores the dependency edges between the component and downstream data processing services. The intelligent analysis module 104 can trace along these dependency edges to determine whether the alarms of downstream services are caused by the failure of the network component.

[0048] The intelligent analysis module 104 is connected to the predictive alarm engine 102 and the operation and maintenance knowledge graph 103 respectively. It is used to perform semantic clustering on the early warning information to merge alarms with the same source and generate alarm events with the same source. The alarm events with the same source are associated with the operation and maintenance knowledge graph 103, and a reverse search is performed along the fault propagation path to locate the root cause node of the fault. The repair strategy corresponding to the root cause node of the fault is retrieved from the operation and maintenance knowledge graph 103.

[0049] In this embodiment, a single fault often triggers warning messages from multiple related components within a short period of time, forming a warning storm and increasing the difficulty of root cause localization. The intelligent analysis module 104 first merges multiple warning messages describing the same fault into a common-source alarm event through semantic clustering, thereby compressing the warning storm into a controllable set of fault events, and then independently performs the root cause localization process for each common-source alarm event.

[0050] Root cause localization employs a graph search approach, starting from the component nodes involved in the same source alarm event and tracing backward along the fault propagation path in the operation and maintenance knowledge graph 103, gradually converging to the upstream trigger node, i.e., the root cause node. After determining the root cause node, the intelligent analysis module 104 retrieves historically associated handling strategies from the operation and maintenance knowledge graph 103 and transmits the root cause node and remediation strategies to the AI ​​Agent execution module 105.

[0051] Please refer to Figure 3 The illustration shows a schematic diagram of the structure of an intelligent analysis module 104 in an operation and maintenance system based on predictive alarms and intelligent agent execution, according to an embodiment of this application. The intelligent analysis module 104 includes a semantic clustering unit 1041 and a root cause localization unit 1042.

[0052] The semantic clustering unit 1041 and the root cause localization unit 1042 are executed sequentially. The semantic clustering unit 1041 is responsible for compressing the early warning information into alarm events from the same source, and the root cause localization unit 1042 is responsible for locating the root cause node of the fault in the operation and maintenance knowledge graph 103 and retrieving the corresponding repair strategy. Together, they complete the analysis and transformation from early warning information to executable repair strategy.

[0053] The semantic clustering unit 1041 incorporates a BERT model to extract semantic vectors from early warning information. It then merges early warning information describing the same fault into a common-source alarm event based on vector similarity.

[0054] The BERT model encodes the text content of each warning message into a high-dimensional semantic vector, making semantically similar warning messages closer together in the vector space. The semantic clustering unit 1041 calculates the cosine similarity between the semantic vectors of each warning message, grouping warning messages with similarity exceeding a preset clustering threshold into the same cluster. Each cluster corresponds to a single, shared alarm event. This method can identify warning messages that use different textual expressions but describe the same underlying fault.

[0055] For example, "memory allocation failure" and "insufficient memory" are different in wording, but their semantic vectors are highly similar. The semantic clustering unit 1041 can correctly classify the two into the same alarm event from the same source, thus avoiding the same fault being analyzed and handled repeatedly.

[0056] The root cause localization unit 1042 is used to match alarm events from the same source with component nodes in the operation and maintenance knowledge graph 103 and perform reverse search along the fault propagation path to locate the root cause node of the fault.

[0057] The root cause localization unit 1042 first maps the system components involved in the same source alarm event to nodes in the operation and maintenance knowledge graph 103 to determine the initial set of affected nodes in the graph for this fault. Then, the root cause localization unit 1042 traverses the reverse edges of the fault propagation path using a breadth-first search, tracing upstream from the affected node to each predecessor node until a node with no upstream dependencies or whose upstream components are all in normal condition is found, which is then identified as the root cause node. If multiple convergence paths exist, the root cause localization unit 1042 combines the frequency weights of historical fault records on each path to perform a comprehensive score, selecting the node with the highest score as the final root cause node output.

[0058] The AI ​​Agent execution module 105, connected to the intelligent analysis module 104, receives the root cause node of the fault and the repair strategy. A large language model generates an operation and maintenance execution plan based on the repair strategy and the current system state. The execution plan undergoes constraint verification, and the execution plan that passes the constraint verification is designated as the target plan. When the warning level is Level 1, the module autonomously executes the operation steps in the target plan. When the warning level is Level 2, the module executes the operation steps after receiving an external confirmation signal. The AI ​​Agent execution module 105 also creates a system snapshot before executing each operation step and verifies the system state after execution. When the verification result does not match the expectation, it uses the system snapshot to perform a rollback, generates an audit log of the operation step execution process, and outputs the execution result and verification result of the operation step.

[0059] In this embodiment, constraint verification is a static security check mechanism performed by the AI ​​Agent execution module 105 before the operation and maintenance execution plan is transformed into actual operation. It is used to ensure that the operation steps generated by the large language model meet the preset security constraints before execution.

[0060] The constraint verification process uses a pre-configured rule base to progressively check each step in the operation and maintenance execution plan. The checks include whether the step is within the whitelist of operations allowed for automatic execution, whether the current time is within the protection window for that type of operation, and whether the number of system components expected to be affected exceeds a preset limit. Operation and maintenance execution plans that pass the constraint verification are designated as the target plan; those that fail will not proceed to the execution phase and will instead be handled by external personnel.

[0061] System snapshots are automatically created before each operation step, recording the system configuration and state before that step. If the verification result of the system state after execution does not match the expectation, the AI ​​Agent execution module 105 calls the system snapshot to restore the system to the state before the operation step, enabling system recovery in the event of a single-step operation failure and reducing the impact of the failure. Audit logs record the execution time, operation content, comparison of system state before and after execution, and verification results of each operation step in a structured format, providing a complete operation record for fault review.

[0062] Please refer to Figure 4 The diagram illustrates the structure of an AI Agent execution module 105 in an operation and maintenance system based on predictive alarms and intelligent agent execution, according to an embodiment of this application. The AI ​​Agent execution module 105 includes: a perception layer 1051, a planning layer 1052, an execution layer 1053, and a verification layer 1054.

[0063] The perception layer 1051, planning layer 1052, execution layer 1053, and verification layer 1054 constitute the four-layer processing architecture of the AI ​​Agent execution module 105. Each layer has independent responsibilities and collaborates sequentially. The perception layer 1051 is responsible for receiving and structuring upstream inputs, the planning layer 1052 is responsible for generating and dynamically adjusting the execution plan based on the inputs, the execution layer 1053 is responsible for converting the operation steps in the plan into actual calls to the target system, and the verification layer 1054 is responsible for verifying the status of the execution results of each step and triggering rollback when necessary.

[0064] The perception layer 1051 is used to receive the root cause nodes of the fault and the repair strategy.

[0065] The perception layer 1051 performs structured parsing on the received root cause nodes and repair strategies, extracts the component identifiers, anomaly types and severity of the root cause nodes, and serializes the handling steps in the repair strategy into an input format that the planning layer 1052 can directly read.

[0066] The planning layer 1052 is used to call the large language model to generate an operation and maintenance execution plan based on the repair strategy, operation and maintenance knowledge graph and the current system status, and dynamically adjust the subsequent steps corresponding to the operation steps based on the execution results during the execution of the target plan.

[0067] When generating an operation and maintenance execution plan, the large language model takes the repair strategy, the topological information related to the root cause node of the fault in the operation and maintenance knowledge graph, and the current system status as context inputs, and infers to generate an operation and maintenance execution plan that includes the sequence of operation steps, the execution conditions of each step, and the expected results.

[0068] During the execution of the target plan, the planning layer 1052 continuously receives the execution results of each step returned by the execution layer 1053. When the execution result of a certain step triggers the preset adjustment conditions, the planning layer 1052 calls the large language model again to dynamically revise the subsequent steps.

[0069] For example, if disk usage still exceeds the target threshold after the disk cleanup operation is completed, the planning layer 1052 will add a log archiving step; when disk usage has dropped below the target threshold, the planning layer 1052 will terminate the execution of subsequent steps.

[0070] The execution layer 1053 is used to interact with the protocol adaptation service of each target system through the unified tool call protocol. The protocol adaptation service encapsulates the system interfaces of each target system into a set of tool descriptions that conform to the unified tool call protocol, so as to isolate the decision logic of the planning layer from the interfaces of each system.

[0071] The unified tool invocation protocol defines a standardized format for tool descriptions, invocation requests, and response results, enabling the planning layer 1052 to trigger corresponding system operations simply by using a tool invocation request in a standard format without needing to be aware of the specific implementation details of the underlying interfaces of each target system.

[0072] Each target system deploys an independent protocol adaptation service, which is responsible for converting the standardized tool call request issued by the planning layer 1052 into the format required by the native interface of the target system, and converting the native response result back into the standard format and returning it to the execution layer 1053.

[0073] When the interface of a target system changes due to a version upgrade, only the corresponding protocol adaptation service needs to be updated. The decision logic of the planning layer 1052 does not need to be changed, thereby reducing the impact of external system interface changes on the overall architecture stability.

[0074] Verification layer 1054 is used to verify the system state after each operation step is completed, and to perform a rollback using a system snapshot if the verification result does not match the expectation.

[0075] After each operation step is completed, the verification layer 1054 queries the target system for the post-execution system status and compares the query result with the expected status of that step preset in the operation and maintenance execution plan by the planning layer 1052. If they match, the verification layer 1054 returns a signal indicating that the step was successfully executed to the planning layer 1052, triggering the execution of subsequent steps. If they do not match, the verification layer 1054 calls the system snapshot created by the perception layer 1051 before the execution of that step, restores the target system to the state before the execution of that step, and returns a signal indicating that the step failed to execute to the planning layer 1052, which then decides whether to retry or terminate the execution plan.

[0076] The learning and optimization module 106, connected to the AI ​​Agent execution module 105, is used to write execution results, verification results, and audit logs into the historical fault database to update historical operation and maintenance data and dynamic knowledge.

[0077] In this embodiment, the learning and optimization module 106 organizes the execution results and verification results output by the AI ​​Agent execution module 105 in a structured manner, extracts the fault characteristics, execution path and final handling effect in this fault handling process, and writes them into the historical fault database in the form of a new fault handling record.

[0078] The newly added handling records in the historical fault database serve two purposes: firstly, they are used as historical operation and maintenance data for incremental training of the time-series prediction model, enabling the model to adapt to newly emerging fault precursor patterns; secondly, the operation and maintenance knowledge graph 103 extracts data from the historical fault database to update the dynamic knowledge of the corresponding fault root cause nodes in the graph, enriching the set of repair strategies associated with that node and their success rate assessment. The accumulation of the historical fault database helps improve the system's accuracy in predicting known fault types and its handling efficiency.

[0079] It also includes a work order processing module; the work order processing module connects to the work order system through a standardized adapter interface, and is used to receive new work orders pushed by the work order system, perform semantic parsing and urgency assessment on the new work orders, determine the target handling entity by combining the historical response database of the handling entity and the current load status, and send the work order status information to the target handling entity through the message push interface; and write the handling result of the new work order into the historical response database of the handling entity.

[0080] In this embodiment, the standardized adapter interface encapsulates the authentication mechanism and interface protocol of the work order system, thereby isolating the core processing logic of the work order processing module from the specific implementation of the work order system. When the work order system interface changes due to version upgrades, only the corresponding configuration of the standardized adapter interface needs to be updated, and the work order processing module does not need to be modified.

[0081] After receiving a new work order, the work order processing module performs semantic parsing on the text description of the work order, extracts structured attributes such as fault type, scope of impact, and urgency, and combines this with the historical response rate and success rate of each handling entity on different types of work orders recorded in the historical response database of the handling entity, as well as the current load status of each handling entity, to comprehensively determine the target handling entity most suitable for handling this work order.

[0082] When a work order status changes, the work order processing module sends a status update notification to the target handling entity via a message push interface, replacing the target handling entity's method of actively polling the work order system, thus reducing information transmission delays. After a work order is processed, the processing result is written to the handling entity's historical response database for use in matching and calculating the handling entity for subsequent work orders.

[0083] like Figure 5 The image shown is a specific embodiment of an operation and maintenance method based on predictive alerts and intelligent agent execution according to this application.

[0084] In this embodiment, an operation and maintenance method based on predictive alerts and intelligent agent execution includes the following steps: Step 501: Collect system performance metrics, log data, and link tracing data in the operation and maintenance environment.

[0085] System performance metrics, log data, and link tracing data describe the real-time operational status of the maintenance environment from different dimensions. The synchronous collection of these three types of data provides a complete input foundation for the subsequent multi-dimensional joint analysis of time series prediction models. The collection process is carried out continuously at fixed time intervals, and the collected raw data is uniformly merged into a data buffer queue.

[0086] Step 502: Input the system performance index data, log data and link tracing data into the time series prediction model. The time series prediction model will predict the future trend corresponding to the system performance index data and output a comprehensive risk score of the operation and maintenance environment based on the degree of deviation of the prediction results from the normal baseline.

[0087] The normal baseline is automatically established by the time-series prediction model during the training phase based on the normal fluctuation distribution of various indicators in historical operation and maintenance data, without requiring operation and maintenance personnel to manually set static thresholds. The comprehensive risk score is obtained by jointly calculating the degree to which the prediction results of multiple indicators deviate from the normal baseline. A slight deviation of a single indicator will not directly increase the comprehensive risk score. Only when multiple related indicators show abnormal trends simultaneously will the comprehensive risk score increase significantly, thereby reducing the probability of false alarms caused by occasional fluctuations.

[0088] Step 503: Based on the comprehensive risk score and the preset level threshold, generate warning information carrying the corresponding warning level; the warning levels include Level 1 warning, Level 2 warning and Level 3 warning.

[0089] The preset threshold values ​​divide the range of the comprehensive risk score into intervals corresponding to three warning levels. When the comprehensive risk score falls into different intervals, a warning message of the corresponding level is generated. The division of warning levels enables the system to adopt differentiated follow-up strategies for anomalies of different urgency levels, avoiding the push and handling of all abnormal signals with the same urgency.

[0090] The N-BEATS model is used to predict the trend of system performance index data. The prediction results are compared with the historical normal fluctuation range to calculate the joint risk probability corresponding to the system performance index data. Based on the preset interval where the joint risk probability is located, a first-level warning, a second-level warning, or a third-level warning is generated. When the warning level is a first-level warning, an alarm notification is sent to the operation and maintenance terminal immediately. When the warning level is a second-level warning, the warning information is summarized and pushed to the operation and maintenance terminal periodically. When the warning level is a third-level warning, the warning information is written to the warning log.

[0091] The N-BEATS model models the trend and periodic components of time-series data separately using multiple residual blocks, demonstrating strong predictive adaptability for operational indicators exhibiting periodic fluctuations. The historical normal fluctuation range is determined by the statistical distribution of each indicator in the training data, and the joint risk probability is derived through the joint calculation of the individual deviation probabilities of multiple indicators.

[0092] The first-level warning corresponds to the range with the highest probability of combined risk. Upon triggering, an alarm notification is immediately sent to the operations and maintenance terminal, requiring an immediate response. The second-level warning corresponds to the range with a medium probability of combined risk. Upon triggering, warning information of the same level is aggregated and pushed out uniformly within a preset time period to avoid frequent interruptions. The third-level warning corresponds to the range with the lowest probability of combined risk. Upon triggering, the warning information is only written to the warning log for post-event analysis and reference, and no active notification is triggered.

[0093] Step 504: Perform semantic clustering on the early warning information to merge alarms from the same source and generate alarm events from the same source.

[0094] The semantic vectors of the warning information are extracted using the BERT model; by calculating the similarity between the semantic vectors, the warning information describing the same fault is merged into a common-source alarm event.

[0095] The BERT model encodes the text content of each warning message into a high-dimensional semantic vector. Then, by calculating the cosine similarity between these semantic vectors, warning messages with similarity exceeding a preset clustering threshold are grouped into the same cluster and corresponding source-related alarm events are generated. This approach can identify warning messages that use different textual expressions but describe the same underlying fault, allowing subsequent root cause localization to focus on the compressed set of fault events rather than analyzing each original warning message individually, thus reducing the overhead of repetitive analysis.

[0096] Step 505: Associate the alarm events from the same source with the operation and maintenance knowledge graph, perform a reverse search along the fault propagation path to locate the root cause node of the fault, and retrieve the repair strategy corresponding to the root cause node from the operation and maintenance knowledge graph; the operation and maintenance knowledge graph stores system components, inter-component dependencies, fault propagation paths and handling strategies in a graph structure, and is composed of static knowledge imported from the configuration management database and dynamic knowledge extracted from the historical fault database.

[0097] After mapping the system components involved in the same source alarm event to the nodes in the operation and maintenance knowledge graph, the predecessor node is traced layer by layer along the reverse edge of the fault propagation path in a breadth-first search manner until it converges to a node with no upstream dependency or whose upstream components are all in normal state, and this node is identified as the root cause node of the fault.

[0098] If multiple convergence paths exist, a comprehensive score is calculated by combining the frequency weights of historical fault records on each path, and the node with the highest score is selected as the final root cause node. After determining the root cause node, remediation strategies historically associated with that node are retrieved from the operations and maintenance knowledge graph.

[0099] Step 506: The large language model generates an operation and maintenance execution plan based on the repair strategy and the current system status. The operation and maintenance execution plan is then subject to constraint verification. The operation and maintenance execution plan that passes the constraint verification is determined as the target plan.

[0100] The large language model takes the repair strategy, the topological information related to the root cause node of the fault in the operation and maintenance knowledge graph, and the current system state as context inputs, and infers to generate an operation and maintenance execution plan that includes the sequence of operation steps, the execution conditions of each step, and the expected results.

[0101] The constraint verification checks each operation step in the operation and maintenance execution plan against a pre-configured rule base. The checks include whether the operation step is within the whitelist of operations allowed for automatic execution, whether the current time is within the protection time window for that type of operation, and whether the expected number of system components affected exceeds a preset limit. Operation and maintenance execution plans that fail the constraint verification do not proceed to the execution phase but are handled by external personnel. Operation and maintenance execution plans that pass the constraint verification are designated as the target plan.

[0102] Step 507: When the warning level is Level 1, the operation steps in the target plan are executed autonomously; when the warning level is Level 2, the operation steps are executed after receiving an external confirmation signal.

[0103] The warning level determines the preconditions that must be met for the target plan to enter the execution phase. Level 1 warnings correspond to severe anomalies requiring immediate intervention. After passing constraint verification, the operational steps in the target plan are executed autonomously by the system without waiting for external input. Level 2 warnings correspond to anomalies with relatively low urgency. After passing constraint verification, the target plan enters a waiting state, and the system sends a confirmation request externally. The corresponding operational steps are only executed after receiving external confirmation, thus preserving the decision-making space for human intervention. Level 3 warnings are recorded in the warning log but do not generate an operation and maintenance execution plan.

[0104] Step 508: Create a system snapshot before executing each operation step, verify the system status after the operation step is executed, and perform a rollback using the system snapshot when the verification result does not match the expectation. Generate an audit log for the execution process of the operation step, and output the execution result and verification result of the operation step.

[0105] System snapshots are automatically created before each operation step is executed, recording the system configuration and running status before that step. After the operation step is completed, the system status after execution is queried from the target system, and the query results are compared with the expected status of that step preset in the target plan.

[0106] If the two are consistent, a signal indicating successful execution of the step is returned to the planning layer, triggering the execution of subsequent operations. If they are inconsistent, a system snapshot created before the execution of the operation step is invoked to restore the target system to its state before execution, and a signal indicating failure of the step execution is returned. The planning layer then decides whether to retry or terminate the execution of the target plan. The audit log records the execution time, operation content, comparison of system states before and after execution, and verification results of each operation step in a structured format.

[0107] Step 509: Write the execution results, verification results, and audit logs to the historical fault database to update the historical operation and maintenance data and dynamic knowledge of the time series prediction model.

[0108] The execution and verification results can extract the fault characteristics, execution paths, and final handling effects during the fault handling process, and write them into the historical fault database as new fault handling records. These newly added handling records in the historical fault database serve two purposes: firstly, they act as historical maintenance data for incremental training of the time-series prediction model, enabling the model to continuously adapt to newly emerging fault precursor patterns; secondly, they are extracted from the historical fault database by the maintenance knowledge graph, updating the dynamic knowledge of the corresponding fault root cause nodes in the graph, enriching the set of repair strategies associated with that node and their success rate assessment, thereby gradually improving the system's prediction accuracy and handling efficiency for known fault types as historical data accumulates.

[0109] When a new work order is received, semantic parsing and urgency assessment are performed on the new work order. The corresponding target handling entity is determined by combining the handling entity's historical response database and the current load status. The work order status information is sent to the target handling entity through the message push interface. The handling result of the new work order is written into the handling entity's historical response database.

[0110] In this embodiment, after semantic parsing of the new work order text, structured attributes such as fault type, scope of impact, and urgency are extracted. Combined with the historical response rate and success rate of each handling entity on different types of work orders recorded in the historical response database of the handling entity, as well as the current load status of each handling entity, the target handling entity is comprehensively determined.

[0111] When a work order status changes, a status update notification is sent to the target handling entity via a message push interface, replacing the target handling entity's method of actively polling the work order system to reduce information transmission delays. After handling is completed, the handling result is written to the handling entity's historical response database for use in the target handling entity matching calculation of subsequent work orders, thereby improving the matching accuracy of subsequent work orders.

[0112] This application also proposes a readable medium storing execution instructions. When these instructions are executed by the processor of an electronic device, the electronic device can perform an operation and maintenance method based on predictive alarms and intelligent agent execution provided in any embodiment of this application, specifically for performing, for example... Figure 5 The method shown.

[0113] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this implementation. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0114] Although embodiments of this implementation have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this implementation, the scope of which is defined by the claims and their equivalents.

Claims

1. An operation and maintenance system based on predictive alarms and intelligent agent execution, characterized in that, include: The system includes a full-link data acquisition module, a predictive alarm engine, an operations and maintenance knowledge graph, an intelligent analysis module, an AI Agent execution module, and a learning and optimization module. The end-to-end data acquisition module is used to continuously collect system performance metrics, log data, and link tracing data in the operation and maintenance environment. The system performance metrics include server CPU utilization, memory usage, disk I / O rate, network traffic, as well as queue depth, execution latency, and data processing latency of operation and maintenance tasks. The predictive alarm engine is connected to the end-to-end data acquisition module and is used to input the system performance index data, the log data, and the link tracing data into the time-series prediction model. The time-series prediction model is trained based on historical operation and maintenance data and is used to predict the future trend corresponding to the system performance index data, and output a comprehensive risk score of the operation and maintenance environment based on the degree of deviation of the prediction result from the normal baseline. The predictive alarm engine is also used to generate warning information carrying corresponding warning levels based on the risk score and preset level thresholds; the warning levels include first-level warning, second-level warning and third-level warning; The operation and maintenance knowledge graph stores system components, inter-component dependencies, fault propagation paths, and handling strategies in a graph structure. It is composed of static knowledge imported from the configuration management database and dynamic knowledge extracted from the historical fault database. The intelligent analysis module is connected to the predictive alarm engine and the operation and maintenance knowledge graph, respectively, and is used to perform semantic clustering on the early warning information to merge alarms from the same source and generate alarm events from the same source. The alarm events from the same source are associated with the operation and maintenance knowledge graph. A reverse search is performed along the fault propagation path to locate the root cause node of the fault, and the repair strategy corresponding to the root cause node of the fault is retrieved from the operation and maintenance knowledge graph. The AI ​​Agent execution module is connected to the intelligent analysis module and is used to receive the root cause node of the fault and the repair strategy. The large language model generates an operation and maintenance execution plan based on the repair strategy and the current system status. The operation and maintenance execution plan is subject to binding verification, and the operation and maintenance execution plan that passes the binding verification is determined as the target plan; When the warning level is the first level warning, the operation steps in the target plan are executed autonomously; when the warning level is the second level warning, the operation steps are executed after receiving an external confirmation signal. The AI ​​Agent execution module is also used to create a system snapshot before executing each operation step, verify the system state after the operation step is executed, and perform a rollback using the system snapshot when the verification result does not match the expectation, generate an audit log for the execution process of the operation step, and output the execution result of the operation step and the verification result. The learning and optimization module is connected to the AI ​​Agent execution module and is used to write the execution results, the verification results and the audit logs into the historical fault database to update the historical operation and maintenance data and the dynamic knowledge.

2. The system according to claim 1, characterized in that, The predictive alert engine includes: N-BEATS prediction unit, risk calculation unit, and graded early warning unit; The N-BEATS prediction unit is used to predict the trend of the system performance index data; The risk calculation unit is used to compare the prediction results with the historical normal fluctuation range and calculate the joint risk probability corresponding to the system performance index data. The graded early warning unit is used to generate a first-level early warning, a second-level early warning, or a third-level early warning based on a preset interval where the joint risk probability is located; when the early warning level is the first-level early warning, an alarm notification is sent to the operation and maintenance terminal immediately; when the early warning level is the second-level early warning, the early warning information is summarized and periodically pushed to the operation and maintenance terminal; when the early warning level is the third-level early warning, the early warning information is written to the early warning log. The predictive alarm engine is also used to configure corresponding target sensitivity parameters for the system components; the system components include core components and auxiliary components; a first sensitivity parameter is configured for the core components, and a second sensitivity parameter is configured for the auxiliary components; the first sensitivity parameter is higher than the second sensitivity parameter.

3. The system according to claim 1, characterized in that, The intelligent analysis module includes: Semantic clustering units and root cause localization units; The semantic clustering unit has a built-in BERT model, which is used to extract the semantic vector of the warning information and merge the warning information describing the same fault into the same source alarm event by vector similarity. The root cause localization unit is used to match the same source alarm events with component nodes in the operation and maintenance knowledge graph, and perform a reverse search along the fault propagation path to locate the fault root cause node.

4. The system according to claim 1, characterized in that, The AI ​​Agent execution module includes: Perception layer, planning layer, execution layer, and verification layer; The perception layer is used to receive the root cause node of the fault and the repair strategy; The planning layer is used to call the large language model, generate the operation and maintenance execution plan based on the repair strategy, the operation and maintenance knowledge graph and the current system status, and dynamically adjust the subsequent steps corresponding to the operation steps based on the execution results during the execution of the target plan. The execution layer is used to interact with the protocol adaptation service of each target system through a unified tool call protocol; the protocol adaptation service encapsulates the system interfaces of each target system into a set of tool descriptions that conform to the unified tool call protocol, so that the decision logic of the planning layer is isolated from each system interface; The verification layer is used to verify the post-execution system state after each of the operation steps is completed, and to perform the rollback using the system snapshot when the verification result does not match the expectation.

5. The system according to claim 1, characterized in that, It also includes a work order processing module; the work order processing module is connected to the work order system through a standardized adapter interface, and is used to receive new work orders pushed by the work order system, perform semantic parsing and urgency assessment on the new work orders, determine the target handling entity by combining the historical response database of the handling entity and the current load status, and send the work order status information to the target handling entity through a message push interface; and write the handling result of the new work order into the historical response database of the handling entity.

6. An operation and maintenance method based on predictive alarms and intelligent agent execution, characterized in that, The method is applied to the system according to any one of claims 1-5, and the method includes: Collect system performance metrics, log data, and trace data from the operation and maintenance environment; The system performance index data, the log data, and the link tracing data are input into the time series prediction model. The time series prediction model predicts the future trend corresponding to the system performance index data and outputs a comprehensive risk score of the operation and maintenance environment based on the degree of deviation of the prediction result from the normal baseline. Based on the comprehensive risk score and preset level thresholds, warning information carrying corresponding warning levels is generated; the warning levels include first-level warning, second-level warning, and third-level warning. The warning information is semantically clustered to merge alarms from the same source and generate alarm events from the same source. The alarm events from the same source are associated with the operation and maintenance knowledge graph, and a reverse search is performed along the fault propagation path to locate the root cause node of the fault. The repair strategy corresponding to the root cause node of the fault is retrieved from the operation and maintenance knowledge graph. The operation and maintenance knowledge graph stores system components, inter-component dependencies, fault propagation paths and handling strategies in a graph structure. It is composed of static knowledge imported from the configuration management database and dynamic knowledge extracted from the historical fault database. The large language model generates an operation and maintenance execution plan based on the repair strategy and the current system state. The operation and maintenance execution plan is then subject to constraint verification, and the operation and maintenance execution plan that passes the constraint verification is determined as the target plan. When the warning level is the first level warning, the operation steps in the target plan are executed autonomously; when the warning level is the second level warning, the operation steps are executed after receiving an external confirmation signal. Before performing each of the above operation steps, a system snapshot is created. After the operation step is performed, the system state after the execution is verified. If the verification result does not match the expectation, the system snapshot is used to perform a rollback. The execution process of the operation step is used to generate an audit log, and the execution result of the operation step and the verification result are output. The execution results, the verification results, and the audit logs are written into the historical fault database to update the historical operation and maintenance data and the dynamic knowledge of the time series prediction model.

7. The method according to claim 6, characterized in that, The generation of warning information carrying the corresponding warning level includes: The N-BEATS model is used to predict the trend of the system performance index data. The predicted results of the trend forecast are compared with the historical normal fluctuation range to calculate the joint risk probability corresponding to the system performance index data. Based on the preset range in which the joint risk probability lies, generate a first-level warning, a second-level warning, or a third-level warning. When the warning level is the first level, an alarm notification is sent to the operation and maintenance terminal immediately; when the warning level is the second level, the warning information is summarized and pushed to the operation and maintenance terminal periodically; when the warning level is the third level, the warning information is written to the warning log.

8. The method according to claim 6, characterized in that, The step of semantically clustering the early warning information to merge alarms from the same source and generate alarm events from the same source includes: The semantic vector of the warning information is extracted using the BERT model; By calculating the similarity between the semantic vectors, the warning information describing the same fault is merged into the same-source alarm event.

9. The method according to claim 6, characterized in that, Also includes: When a new work order is received, semantic parsing and urgency assessment are performed on the new work order. The corresponding target handling entity is determined by combining the historical response database of the handling entity and the current load status. The work order status information is then sent to the target handling entity through the message push interface. The processing result of the new work order is written into the historical response database of the processing entity.

10. A computer-readable storage medium storing a computer program, characterized in that, The computer program is used to execute the operation and maintenance method based on predictive alarms and intelligent agent execution as described in any one of claims 6-9.

Images