Agent-based computing device automatic operation and maintenance method and system
Patent Information
- Application Number
- CN202611128528.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-28
- Publication Date
- 2026-10-23
AI Technical Summary
[0004]本发明提供一种基于智能体的计算设备自动化运维方法及系统,用以解决现有技术中“运维处理效率低下且对核心人员高度依赖,难以应对大规模及碎片化的运维需求”的缺陷
任务执行模块,用于根据并行评估指标将所述运维操作计划拆分为多个子任务,并将所述子任务分配至对应的智能体执行单元执行,汇总各所述子任务的执行结果得到总体执行结果。
Smart Images

Figure CN122963847A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of IT system operation and maintenance management technology, and in particular to an automated operation and maintenance method and system for computing devices based on intelligent agents. Background Technology
[0002] As enterprise IT infrastructure continues to expand, system operations and maintenance (O&M) face increasingly severe challenges. First, O&M knowledge is difficult to accumulate and reuse: the experience and troubleshooting skills of core O&M engineers often exist in the form of personal experience, lacking systematic knowledge management methods. When key personnel leave, the accumulated troubleshooting knowledge is lost, meaning the existing knowledge base system requires manual maintenance, resulting in untimely updates and low search efficiency. Second, there is a severe fragmentation of the O&M context: traditional O&M tools' alarm notifications only include abnormal values of current monitoring metrics and cannot automatically link historical events, change records, and fault handling logs. O&M personnel need to manually log into multiple systems to fully understand the cause of alarms, leading to a significant increase in mean time to repair (MTTR). Furthermore, single-point bottlenecks are prominent: core O&M engineers often handle more than 70% of the fault handling tasks. When multiple alarms occur simultaneously, they can only be processed sequentially, and alarm storms can easily lead to processing delays and human error. In addition, alarm channels are severely fragmented: enterprise operations and maintenance teams often use multiple communication tools such as WeChat Work, DingTalk, Slack, Telegram, email, and SMS at the same time. Each channel has different interface protocols, message formats, and interaction methods, and it is easy to miss key alarms when switching frequently.
[0003] This shows that the existing IT operations and maintenance system is fragmented, relies too much on manual coordination and decision-making, resulting in low efficiency in operations and maintenance and a high dependence on key personnel, making it difficult to cope with large-scale and fragmented operations and maintenance needs. Summary of the Invention
[0004] This invention provides an automated operation and maintenance method and system for computing devices based on intelligent agents, in order to solve the shortcomings of existing technologies that are "inefficient in operation and maintenance and highly dependent on key personnel, making it difficult to cope with large-scale and fragmented operation and maintenance needs".
[0005] This invention provides an automated operation and maintenance method for computing devices based on intelligent agents, comprising: In response to a received pending operation and maintenance event, the relevant operation and maintenance context is retrieved from the memory. The operation and maintenance skill scheme is determined based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill library; The operation and maintenance context and the operation and maintenance skill scheme are input into the target large language model of the intelligent agent system to generate an operation and maintenance plan. The operation and maintenance plan is divided into multiple sub-tasks based on parallel evaluation metrics, and the sub-tasks are assigned to the corresponding intelligent agent execution units for execution. The execution results of each sub-task are then summarized to obtain the overall execution result.
[0006] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents is provided, wherein the memory bank includes a horizontal three-class memory architecture, which includes a user preference memory layer, an environmental information memory layer, and a lesson learning memory layer; The user preference memory layer is used to store at least the notification preferences, operating habits and permission scope data of operation and maintenance personnel; the environment information memory layer is used to store at least the static configuration information and dynamic running status data of the operation and maintenance environment; and the lessons learned memory layer is used to store at least the processing records and experience summary data of historical operation and maintenance events. The operation and maintenance context is a comprehensive information set generated by fusing data obtained from the user preference memory layer, the environmental information memory layer, and the lesson learning memory layer.
[0007] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents includes, in the step of determining an operation and maintenance skill scheme based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill base, the step of determining the operation and maintenance skill scheme specifically includes: Calculate the semantic similarity between the semantic embedding vector of the operation and maintenance event to be processed and the semantic embedding vector of each candidate operation and maintenance skill in the skill base; A comprehensive score is obtained by comprehensively evaluating the semantic similarity, historical success rate information and timeliness information corresponding to each candidate operation and maintenance skill. The candidate operation and maintenance skills are sorted according to the comprehensive matching score to obtain the first preset number of candidate operation and maintenance skills, so as to determine the optimal operation and maintenance skill scheme.
[0008] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents is provided, wherein the large language model is invoked through a provider-independent architecture, and the provider-independent architecture selects the target large language model of the intelligent agent system from multiple available large language models based on the Pareto multi-objective optimization algorithm.
[0009] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents includes the following steps: dividing the operation and maintenance plan into multiple sub-tasks according to parallel evaluation indicators, assigning the sub-tasks to corresponding intelligent agent execution units for execution, and summarizing the execution results of each sub-task to obtain the overall execution result. The operation and maintenance plan is broken down into multiple sub-tasks based on parallel evaluation metrics; Create sub-agent instances with the same number of sub-tasks, and assign each sub-task to the corresponding sub-agent instance for execution to obtain the execution result for each sub-task; The main intelligent agent summarizes the execution results of each subtask to obtain the overall execution result of the operation and maintenance event to be processed; The parallel evaluation metrics include at least the number of affected servers, the number of operation steps, the complexity of dependencies between operations, and parallel feasibility related to the operation and maintenance plan.
[0010] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents is provided, wherein the subtasks are assigned to corresponding sub-intelligent agent instances for execution using a canary release strategy. The gray-scale release strategy is as follows: all the sub-agent instances are divided into multiple batches according to a preset batch size. Each sub-agent instance in the same batch executes its assigned sub-task in parallel. After the current batch is completed, it waits for a confirmation instruction or waits for a preset interval before executing the next batch. If the failure rate of the current batch exceeds the preset threshold during execution, a rollback operation is automatically triggered to stop the execution of subsequent batches and restore the state to that before execution.
[0011] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents, the steps prior to the received operation and maintenance event to be processed further include: The system receives maintenance messages from at least one message channel through a multi-channel gateway system and converts them into standardized internal message formats. Event identifiers are extracted from each of the standardized operation and maintenance messages, wherein the event identifiers are generated using the hash time slot method; Within a preset time window, duplicate operation and maintenance messages are deduplicated based on the event identifier, so that the first non-duplicate event received is taken as the operation and maintenance event to be processed.
[0012] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents includes a command approval security mechanism, which is further included in the step of splitting the operation and maintenance plan into multiple sub-tasks according to parallel evaluation indicators. The command approval security mechanism specifically involves: assessing the risk level of each operation instruction in the operation and maintenance plan to obtain a comprehensive risk score; Based on the comprehensive risk score, each of the operation instructions is classified into automatic execution level, single-person approval level, multi-person approval level, or manual intervention level. When the operation instruction is classified as requiring approval, an approval request is sent to the approval end through the multi-channel gateway system. The operation instruction is executed only when an approval response is received, and the corresponding operation record and approval record are written to the audit log.
[0013] According to the present invention, an automated operation and maintenance method for computing devices based on intelligent agents, the step after summarizing the execution results of each sub-task to obtain the overall execution result further includes: The execution process data and the overall execution result are written into the memory. The operation and maintenance skill solution is evaluated from multiple dimensions based on the overall execution results. When the comprehensive score meets the preset improvement conditions, the operation and maintenance skill solution is optimized and updated, and the optimized operation and maintenance skill solution is generated and stored in the skill library.
[0014] The present invention also provides an automated operation and maintenance system for computing devices based on intelligent agents, comprising: The context building module is used to retrieve the relevant operation and maintenance context from the memory in response to received pending operation and maintenance events; The skill matching module is used to determine the operation and maintenance skill scheme based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill library; The reasoning and decision-making module is used to input the operation and maintenance context and the operation and maintenance skill plan into the target large language model of the intelligent agent system to generate an operation and maintenance plan. The task execution module is used to break down the operation and maintenance plan into multiple sub-tasks according to the parallel evaluation indicators, assign the sub-tasks to the corresponding intelligent agent execution units for execution, and summarize the execution results of each sub-task to obtain the overall execution result.
[0015] The present invention provides an automated operation and maintenance method and system for computing devices based on intelligent agents. By retrieving the operation and maintenance context from a memory bank, the current event can be automatically associated with historical processing experience and environmental information, reducing reliance on the personal experience of core personnel and avoiding knowledge gaps. Simultaneously, by matching candidate operation and maintenance skills from a skill library based on semantic similarity, the system can understand the semantic meaning of the operation and maintenance event to be processed and automatically adapt the technical solution, further reducing human intervention. On this basis, the operation and maintenance context and operation and maintenance skill solutions are input into a large language model for reasoning and decision-making, generating an operation and maintenance plan, replacing the traditional manual analysis and judgment process, and improving the intelligence level of operation and maintenance decision-making. Based on parallel evaluation indicators, the operation and maintenance plan is broken down into multiple sub-tasks and assigned to corresponding intelligent agent execution units for execution, significantly shortening the overall processing time in large-scale operation and maintenance scenarios. Furthermore, multi-task processing effectively alleviates the single-point bottleneck problem of manual processing in the traditional serial mode, avoiding alarm backlog. Thus, through the synergistic effect of each step, the operation and maintenance process is made intelligent and efficient, reducing labor costs and reliance on core personnel. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0017] Figure 1 This is a flowchart illustrating the automated operation and maintenance method for computing devices based on intelligent agents provided by the present invention. Figure 2 This is a system-level modular implementation architecture diagram of each step of the intelligent agent-based automated operation and maintenance method for computing devices provided by the present invention. Figure 3 This is a flowchart of the skill self-evolution closed loop of the intelligent agent-based automated operation and maintenance method for computing devices provided by the present invention; Figure 4 This is a flowchart of the multi-agent parallel operation and maintenance process of the automated operation and maintenance method for computing devices based on intelligent agents provided by the present invention; Figure 5 This is a multi-channel event-driven operation and maintenance flowchart of the intelligent agent-based automated operation and maintenance method for computing devices provided by the present invention; Figure 6 This is a flowchart of the timed inspection and automatic repair process of the automated operation and maintenance method for computing devices based on intelligent agents provided by the present invention; Figure 7 This is a flowchart of the command approval security mechanism of the intelligent agent-based automated operation and maintenance method for computing devices provided by the present invention; Figure 8 This is a deployment architecture diagram of the intelligent agent-based automated operation and maintenance method for computing devices provided by the present invention. Detailed Implementation
[0018] The embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and should not be construed as limiting the scope of the invention.
[0019] In the description of this invention, it should be noted that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for 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 the invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0020] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.
[0021] See Figure 1 This application provides an automated operation and maintenance method for computing devices based on intelligent agents, comprising the following steps: S110: In response to the received pending operation and maintenance event, retrieve the relevant operation and maintenance context from the memory; S120: Determine the operation and maintenance skill scheme based on the semantic similarity between the operation and maintenance events to be processed and each candidate operation and maintenance skill in the skill library; S130: Input the operation and maintenance context and operation and maintenance skill plan into the target large language model of the intelligent agent system to generate an operation and maintenance plan; S140: The operation and maintenance plan is divided into multiple sub-tasks according to the parallel evaluation index, and the sub-tasks are assigned to the corresponding intelligent agent execution units for execution. The execution results of each sub-task are summarized to obtain the overall execution result.
[0022] This invention retrieves operational context from a memory bank, enabling current events to automatically associate with historical processing experience and environmental information, reducing reliance on the personal experience of key personnel and avoiding knowledge gaps. Simultaneously, it matches candidate operational skills from a skill library based on semantic similarity, understanding the semantic meaning of the operational events to be processed and automatically adapting technical solutions, further reducing human intervention. Building on this, the operational context and operational skill solutions are input into a large language model for reasoning and decision-making, generating operational operation plans that replace traditional manual analysis and judgment processes, improving the intelligence level of operational decision-making. Based on parallel evaluation indicators, the operational operation plan is broken down into multiple sub-tasks and assigned to corresponding intelligent agent execution units, significantly shortening the overall processing time in large-scale operational scenarios. Furthermore, multi-task processing effectively alleviates the single-point bottleneck problem of manual processing in traditional serial modes, avoiding alarm backlog. Thus, through the synergistic effect of each step, the operational process is made intelligent and efficient, reducing labor costs and reliance on key personnel.
[0023] In S110, maintenance events are received from at least one message channel through a multi-channel gateway system. These maintenance events include monitoring alarm events, scheduled task trigger events, Webhook push events, or operation instructions directly entered by the user.
[0024] The steps prior to receiving a pending maintenance event also include: receiving maintenance messages from at least one message channel through a multi-channel gateway system and converting them into standardized internal message formats; extracting event identifiers from each standardized maintenance message, wherein the event identifiers are generated using a hash time slot method; and, within a preset time window, performing deduplication on duplicate maintenance messages based on the event identifiers, so that the first non-duplicate event received is taken as the pending maintenance event.
[0025] Within the set time window, only the first of the duplicate alarms with the same event identifier is retained, while the rest are discarded, to ensure that the same fault triggers the subsequent processing procedure only once. The event identifier is generated using the hash time slot method, which is obtained by concatenating the event type, source identifier and time slot corresponding to the operation and maintenance message and then calculating it using a hash function.
[0026] Specifically, the multi-channel gateway system is responsible for unified access to various messaging channels, supporting WeChat Work, DingTalk, Lark, Slack, Discord, Telegram, Microsoft Teams, email, SMS, voice calls, Webhook REST API, Mattermost, IRC, and other channels. The gateway is designed with a plug-in architecture, with each channel encapsulated as an independent message adapter. When adding a new channel, only a unified Adapter interface needs to be implemented (defining three methods: send / receive / parse), without modifying the gateway's core code. The core of the gateway lies in its event deduplication mechanism—converting alarm messages from different channels into a standardized internal message format (IMF), extracting event identifiers from the message content (such as the alertname + instance combination in Prometheus alarms), and employing a two-layer deduplication strategy of "precise event_id matching + hash time slots." The first layer maintains a window cache in Redis using the event_id as the deduplication key (default window period 60 seconds), and the second layer uses the hash time slot method to generate the deduplication key. ; in, is the SHA-256 hash function, ⊕ is the concatenation operation, t is the event timestamp, and Δt is the deduplication time window (default 60 seconds). As an identifier for the type of event, It serves as a unique identifier for the source of the event.
[0027] It should be noted that the 60-second window is designed based on the following: Actual production environment measurements show that the time difference for the same alarm arriving through multiple channels is typically between 10 and 45 seconds. A 60-second window can cover 99.2% of duplicate arrivals, while keeping the probability of misclassifying a non-duplicate event as a duplicate below 0.3%. For alarms from different channels but pointing to the same underlying event (such as a Prometheus alarm sent simultaneously via WeChat and Slack), the system uses the alarm ID field for cross-channel association and deduplication.
[0028] In this application, the memory of the intelligent agent system is a three-dimensional operation and maintenance intelligent agent memory architecture of "three types of business memory + three layers of time-sensitive memory". It is divided into three professional operation and maintenance memory dimensions horizontally and three levels of time-sensitive memory vertically, realizing hierarchical storage, time-sharing update, hierarchical retrieval, and closed-loop accumulation of operation and maintenance data, and supporting cross-session, full-scenario, iterative intelligent operation and maintenance context generation.
[0029] The memory bank consists of three horizontally categorized layers: a user preference memory layer, an environmental information memory layer, and a lesson learned memory layer. The user preference memory layer stores at least the notification preferences, operating habits, and permission scope data of operations and maintenance personnel. The environmental information memory layer stores at least the static configuration information and dynamic operating status data of the operations and maintenance environment. The lesson learned memory layer stores at least the processing records and experience summary data of historical operations and maintenance events. The operations and maintenance context is a comprehensive information set generated by fusing data from the user preference memory layer, the environmental information memory layer, and the lesson learned memory layer.
[0030] Specifically, a three-tiered memory architecture is employed to achieve cross-session persistence of operational knowledge. The first tier is the user preference memory layer, stored in PostgreSQL in key-value pair format. It records the operational personnel's notification preferences (correspondence between alarm levels and notification channels), operational habits (frequently used commands, frequently used server groups), and permission scope (whitelist of executable commands, scope of operable services). This layer is automatically loaded each time the intelligent agent interacts. The second tier is the environment information memory layer, storing static information (server list, IP addresses, operating system versions, service dependency graphs, network topology, middleware configuration information) and dynamic information (real-time CPU utilization, memory utilization, disk I / O, network traffic, service running status) of the operational environment. This is kept up-to-date through scheduled tasks (hourly full synchronization) and event-driven updates (Webhook receiving Prometheus pushes). The third category is the lessons learned memory layer, which records the handling experience and lessons learned from historical operation and maintenance events. Each record includes event ID, event time, event type, problem description, root cause analysis, sequence of handling steps, handling results, and experience summary. It supports semantic retrieval through vectorized storage (using the BAAI / bge-large-zh-v1.5 embedding model and storing it in the Milvus vector database). When similar events are encountered, the cosine similarity between the current event vector and the historical lesson vector is automatically calculated, and the top 3 historical lessons with the highest similarity are returned as reference context (this number is based on the analysis of the operation and maintenance scenario: 1 may not be comprehensive, more than 5 will have a lot of redundant information, and 3 strikes a balance between comprehensiveness and conciseness).
[0031] In this application, the intelligent agent system's memory bank employs a three-layered vertical memory structure, comprising short-term working memory, medium-term episodic memory, and long-term semantic memory. This vertical division into three layers—recent, medium-term, and long-term—allows for hierarchical management and control of these three types of business memory throughout their entire lifecycle, with each layer operating independently yet iteratively in tandem. Specifically: 1. The Recent Memory Layer (0-24h short-term session memory) serves as a temporary high-speed memory for a single agent session and daily maintenance. It utilizes Redis memory caching for millisecond-level response times, retaining only short-term, temporary, and incremental data, and automatically clearing it upon timeout. Core storage content includes: user's temporary operations, temporary permissions, and temporary notification configurations for the day; real-time dynamic indicators at the second / minute level for the environment, and data on instantaneous changes during operations; and troubleshooting strategies for handling incomplete loop fault events. The core mechanism is full real-time incremental updates, prioritizing loading data from the current session, and automatically clearing data after 30 minutes or 24 hours of inactivity, ensuring the timeliness of real-time interactions.
[0032] 2. The intermediate memory layer (1-30 days of continuous scenario memory) is a multi-session continuous scenario transition memory, using PostgreSQL structured persistent storage to retain periodic and routine operation and maintenance scenario data, realizing the transition and accumulation of temporary behaviors into long-term knowledge. Core storage content includes: user's stable operating habits over the past 30 days, routine notification rules and regular permissions; hourly environment synchronization snapshots, short-term dynamic fluctuation data and static configuration snapshots; and closed-loop but non-standardized short-term operation and maintenance event records. Core mechanisms include: scheduled synchronization + incremental overwrite, automatic loading of scenario data across sessions; automatic identification of data value at the end of the cycle, with valid data being accumulated in long-term memory and invalid, incidental data being automatically discarded.
[0033] 3. The long-term memory layer (permanent semantic knowledge memory) is a globally standardized operation and maintenance knowledge accumulation layer. It adopts a dual-database linkage storage of PostgreSQL and Milvus vector databases to retain reusable, generalizable, and high-value standardized benchmark data and experience knowledge. Core storage content: user-fixed permission system, long-term fixed notification rules and routine operation baselines; fixed architecture of the operation and maintenance environment, static benchmark configuration and long-term operating baselines; a structured operation and maintenance fault case library that has been standardized and manually verified. Core mechanism: monthly batch accumulation + real-time iteration of major events; vector embedding based on the BAAI / bge-large-zh-v1.5 model in fault scenarios, matching the top 3 best historical lesson cases through cosine similarity calculation; outdated knowledge is only manually reviewed and removed, there is no automatic elimination.
[0034] In the above steps, the operational context is obtained using a collaborative memory attention weighting dynamic calculation mechanism. The retrieval quality of the three-class and three-layer three-dimensional memory system directly determines the accuracy of the LLM inference context. Traditional methods assign the same weight to all memory entries or sort them solely based on time decay, failing to dynamically adapt to the attention focus of the current operational scenario. This invention designs a memory weighting calculation mechanism based on multi-head attention, which calculates the weights of L memory records retrieved for the same event. Calculate the attention weight of each record relative to the current query q: ; in, This is the embedding vector for the operation and maintenance query q. and Projection matrix (dimensions) for query and key =128), It is a semantic relevance gating factor. The time decay factor, To remember the time from now, =0.01 is the decay coefficient, designed based on the following: memory decay to approximately 93% within 7 days and approximately 74% within 30 days. For memory confidence factors, in the training data, successfully processed memory records are labeled with 1, and failed records are labeled with 0.
[0035] The final context vector is calculated by a weighted sum: , Let denot 'i' be the attention weight corresponding to the i-th memory record. The core innovation of this mechanism lies in the dynamic combination of three gating factors (semantic relevance γ, time decay ρ, and confidence δ). When a successful lesson from 7 days ago and a failed lesson from 1 day ago are retrieved simultaneously, the attention mechanism automatically assigns weights based on the query semantics: if the current alert is highly similar to the root cause of a historical successful case, the γ factor gives the memory a higher weight; if the failed record comes from an alert with a different cause, the δ factor lowers its weight, rather than simply discarding it. In a test with 112 lesson memories, this mechanism improved retrieval relevance by 38% and reduced the LLM inference misjudgment rate by 52% compared to the uniform weight method.
[0036] In S120, the step of determining the operation and maintenance skill scheme based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill library specifically includes: calculating the semantic similarity between the semantic embedding vector of the operation and maintenance event to be processed and the semantic embedding vector of each candidate operation and maintenance skill in the skill library; performing a comprehensive score based on the semantic similarity, historical success rate information and timeliness information corresponding to each candidate operation and maintenance skill to obtain the corresponding comprehensive matching score; and sorting each candidate operation and maintenance skill according to the comprehensive matching score to obtain the first preset number of candidate operation and maintenance skills to determine the optimal operation and maintenance skill scheme.
[0037] Classic algorithms such as cosine similarity can be used as similarity quantification algorithms between the operation and maintenance event vectors to be processed and the candidate operation and maintenance skill vectors. Better, the vector embedding method uses a domain-specific embedding model obtained by fine-tuning training based on the operation and maintenance domain labeled knowledge base. This eliminates the semantic ambiguity of professional terms such as server, alarm, fault, operation and maintenance command, and middleware in the general text model, and greatly improves the matching accuracy of operation and maintenance scenarios.
[0038] The intelligent agent system's skill library provides complete lifecycle management for skills, including seven stages: skill creation, storage, retrieval, loading, execution, evaluation, and improvement. Each operation and maintenance skill plan is encapsulated in JSON format, containing metadata (skill name, description, version number, author, creation time), input parameter definitions (parameter name, type, description, required, default value), execution logic (Shell command sequence, API call sequence, function call sequence), output format definition, and evaluation criteria (success rate threshold, execution time threshold, output format validation rules). The description text of the operation and maintenance skill plan is converted into a high-dimensional vector using an embedding model such as BAAI / bge-large-zh-v1.5 (1024-dimensional vector, 326M model parameters, average score of 64.92 on the C-MTEB Chinese benchmark) and stored in a vector database such as Milvus. When an operation and maintenance event is received, the event description text is converted into a query vector using the same embedding model, and an approximate nearest neighbor search is performed in the vector database. To compensate for the shortcomings of pure vector retrieval in precise lexical matching, this application adopts a hybrid retrieval strategy of "prioritizing vector cosine similarity + complementing BM25 lexical matching". Semantic similarity can be calculated using the cosine similarity formula: ; in, This is the embedding vector for the operation and maintenance query q. Let be the embedding vector of skill s. The overall matching score is a weighted composite of three factors: ; Where α+β+γ=1, with default values of α=0.6, β=0.15, and γ=0.25. The weight design is based on the following: semantic matching is the core of retrieval accuracy (dominant weight 0.6), and historical success rate... This reflects the reliability (0.25) and timeliness of the skill. It plays a supporting role in ranking (0.15). This includes, for example, the timeliness score. =exp(-λ△t), where △t is the time since the last successful execution of the skill. Returns the top K best-matching skill modules. The default value of K is 5, based on the following: Analysis of 3000 historical operation and maintenance events shows that the hit rate of the first matching skill is 72%, the first three are 89%, and the first five are 97%. Further increasing the value of K significantly reduces the marginal benefit (only increasing to 99% when K=10), while the retrieval latency increases from 32ms when K=5 to 58ms when K=10. Therefore, K=5 achieves the optimal balance between coverage and efficiency.
[0039] In S130, the large language model is invoked through a provider-independent architecture. The provider-independent architecture supports dynamic switching between multiple large language model providers and automatically selects the optimal model provider based on task complexity, latency requirements, cost budget, and availability. The provider-independent architecture selects the target large language model from multiple available large language models based on the Pareto multi-objective optimization algorithm.
[0040] In this application, the core engine (Agent Loop) serves as the system's central hub. It collects inputs such as monitoring alarms, scheduled task triggers, and Webhook events in real time. Based on a Large Language Model (LLM), it performs inference and decision-making, calls upon maintenance skill solutions from the skill library to execute maintenance operations, and feeds the execution results back to the memory and skill library to achieve self-evolution. The core engine supports dynamic switching between multiple large language model providers through a provider-agnostic architecture, realizing intelligent routing functionality for large models. These providers include OpenAI (GPT-4 / GPT-4o), Anthropic (Claude-3 / Claude-3.5), Google (Gemini Pro / Ultra), Meta (Llama-3), Mistral AI, DeepSeek, Tongyi Qianwen, Wenxin Yiyan, Zhipu ChatGLM, Baichuan, Lingyi Wanwu, Yuezhi Anmian Kimi, Ollama local model, vLLM, Azure OpenAI, Amazon Bedrock, and Google VertexAI.
[0041] The optimal provider selection strategy uses the following formula: ; in, For the inference cost of provider p, The inference response latency of provider p is given by Availability(p), which is a comprehensive availability metric for provider p in the context of operations and maintenance intelligent agent scenarios. Its value ranges from [0,1]. A higher value indicates that the model service provider is currently more suitable to handle this operations and maintenance inference request. Constraints: ; For the collection of available providers, and This is a penalty coefficient for latency and availability; unlike the traditional narrow service online rate that only represents "whether the interface can be connected", this solution adopts a broad definition of availability, which includes three dimensions: link connectivity stability, interface service rate limiting / fault status, and functional capability matching degree (including multimodal, tool call and other built-in model functions), fully covering multimodal capability verification.
[0042] This design ensures that the system can switch models without modifying the core code when cloud service fluctuates or costs are adjusted. At the same time, it automatically selects the most cost-effective model based on the characteristics of the task. Lightweight models such as Qwen2-1.5B are used to save costs for simple tasks (the cost of inference per instance is about RMB 0.0003), while high-performance models such as GPT-4o are used to ensure quality for complex tasks (the cost of inference per instance is about RMB 0.03).
[0043] This invention employs a Pareto Frontier Provider Optimization algorithm for provider selection. Existing provider selection strategies simplify multiple objectives (cost, latency, availability) into a single objective using a weighted summation formula. However, different weight settings can lead to sensitive results and fail to intuitively demonstrate the trade-offs between multiple objectives. This invention introduces the Pareto Frontier method for multi-objective decision-making. For each available provider, a three-dimensional performance vector is defined: All three dimensions must be minimized. Provider p is Pareto dominant over provider q (denoted as p). If and only if: , Let p be the performance value of provider p in the i-th dimension. The Pareto optimal set is defined as follows: When making the final decision on the Pareto front, the principle of maximizing marginal utility is adopted: ; in, For lower-cost providers adjacent to the Pareto front The utility improvement brought by upgrading to provider p (measured by Euclidean distance of performance vector). This represents the cost increment. The physical meaning of this formula is: to find the "most cost-effective" upgrade path on the Pareto front, that is, the maximum performance improvement obtained for each additional unit of cost.
[0044] For example, in a typical scenario with 8 available providers, Pareto filtering retains 4 non-dominated providers: Lightweight Model A (cost 0.0003 yuan, latency 0.8 seconds), Medium Model B (cost 0.005 yuan, latency 1.2 seconds), High-Performance Model C (cost 0.03 yuan, latency 2.1 seconds), and Flagship Model D (cost 0.15 yuan, latency 3.5 seconds). Marginal utility calculations show that ΔU / ΔC from A to B is 184, from B to C is 8.3, and from C to D is 1.1. Therefore, for moderately complex tasks, Model B offers the best cost-performance ratio, Model C is used only for tasks requiring extremely high precision, and Model D is only enabled in special compliance scenarios. This algorithm avoids the blindness of manually setting weights and provides operations personnel with a visualized view of cost-performance trade-offs.
[0045] In S140, the steps of breaking down the operation and maintenance plan into multiple sub-tasks based on parallel evaluation metrics, assigning the sub-tasks to corresponding intelligent agent execution units for execution, and summarizing the execution results of each sub-task to obtain the overall execution result include: breaking down the operation and maintenance plan into multiple sub-tasks based on parallel evaluation metrics; creating sub-intelligent agent instances with the same number of sub-tasks, assigning each sub-task to the corresponding sub-intelligent agent instance for execution, and obtaining the execution result for each sub-task; and having the main intelligent agent summarize the execution results of each sub-task to obtain the overall execution result of the operation and maintenance event to be processed. Among these, the parallel evaluation metrics include at least the number of affected servers related to the operation and maintenance plan, the number of operation steps, the complexity of the dependency relationships between various operations, and parallel feasibility.
[0046] The master planning agent is responsible for task complexity assessment and decomposability analysis. Assessment metrics include the number of affected servers, the number of operation steps, dependency complexity, and parallel feasibility. For parallelizable tasks, the master planning agent decomposes the task into multiple independent subtasks, each containing a complete objective description, operation steps, and parameter configuration. The master agent dynamically creates sub-agent instances for each subtask. Each sub-agent inherits the master agent's core capabilities (LLM inference, tool invocation, and security control) but has its own independent execution context and resource quotas. Sub-agents execute their respective tasks in parallel without interference, each independently performing a perception → inference → action → learning loop.
[0047] During execution, a canary release strategy is supported: sub-agents are executed in batches according to a preset batch size. After each batch is completed, the system waits for confirmation from operations and maintenance personnel or waits for a preset interval before executing the next batch. A rollback operation is automatically triggered when the failure rate exceeds a preset threshold.
[0048] Preferably, the default size of the gray-scale batch is 5 servers, based on the following criteria: if the batch is too small (e.g., 1-2 servers), the total execution time will increase linearly, losing the advantage of parallelism; if the batch is too large (e.g., more than 20 servers), the impact will be too wide when problems occur; 5 servers achieve the optimal balance between risk and efficiency.
[0049] In this step, the core challenge of multi-agent parallel execution lies in minimizing the overall execution time while ensuring the independence of subtasks. This invention formalizes the task decomposition problem as a minimum weighted graph cut problem, that is, it adopts a weighted graph-cuttask decomposition algorithm. A directed weighted graph G=(V,E,w) is constructed, where the node set... Let represent n managed servers, and let E represent the dependencies between servers (e.g., server A's database depends on server B's API). The weight function is... This represents dependency strength (calculated by combining historical call frequency and call latency). The goal of task decomposition is to find a partitioning method that divides V into K disjoint subsets. This minimizes the following cost function: ; The constraints are: (Maximum number of servers per batch) and (Total execution time budget). Where c(v) is the operation execution cost of server v (related to operation type and server load), and λ is the cross-subset communication penalty coefficient (default λ=2.0, obtained by fitting data from typical operation and maintenance scenarios). t(v) is the upper limit of the grayscale batch size (default 20), and t(v) is the estimated execution time of server v.
[0050] To solve this optimization problem, this invention employs the Kernighan-Lin heuristic algorithm combined with a quadratic local search, achieving a time complexity of O(n log n). Compared with the traditional greedy partitioning method, in a test scenario with 50 servers, this algorithm reduced the number of cross-subset dependency calls by 47%, reduced the standard deviation of subtask execution time from 18.3 seconds to 4.7 seconds, and improved the load balancing of each sub-agent by 74%.
[0051] In this embodiment, the steps before breaking down the operation and maintenance plan into multiple sub-tasks based on parallel evaluation indicators also include a command approval security mechanism. Specifically, the command approval security mechanism involves: assessing the risk level of each operation instruction in the operation and maintenance plan to obtain a comprehensive risk score; classifying each operation instruction into automatic execution level, single-person approval level, multi-person approval level, or manual intervention level based on the comprehensive risk score; when an operation instruction is classified as requiring approval, an approval request is sent to the approval end through a multi-channel gateway system; the operation instruction is executed only upon receiving an approval response, and the corresponding operation record and approval record are written to the audit log.
[0052] Among them, each operation instruction in the operation and maintenance plan is comprehensively evaluated based on four dimensions: command type, operation object, scope of impact, and historical records.
[0053] Specifically, the Command Approval security mechanism embeds security controls into the intelligent agent's operational process. Each operational operation undergoes an automatic risk assessment, with assessment factors including command type (read-type: low risk; write-type: medium risk; delete-type: high risk), operation object (ordinary file: low risk; system configuration file: high risk; database: high risk), scope of impact (single server: low risk; cluster-wide: high risk), and historical records (historical success rate of the command and whether it has caused any failures). The risk scoring formula is as follows: ; in, These are the weighting coefficients for each dimension. Rate the type of operation. Score the scope of influence. Rate historical records Rate the object being operated on. . , , , The weights are set to 0.4, 0.3, 0.15, and 0.15 respectively. The weight allocation reflects the importance ranking of the risk sources. The degree of danger of the operation itself (0.4) and the scope of impact (0.3) are the core factors, while historical and permission information (0.15 each) play an auxiliary corrective role.
[0054] Overall score The system is categorized into four levels based on the S value: S<25 is L1 (automatic execution, such as viewing logs and querying status); 25≤S<50 is L2 (single-person approval, such as cleaning up non-system directory files); 50≤S<75 is L3 (multi-person approval, such as modifying system configuration files); and S≥75 is L4 (human intervention, such as formatting disks and deleting database tables). For operations requiring approval, an approval request message (including operation description, command, target server, risk level, impact assessment, and recommendations) is automatically sent through the original interaction channel. Approver completes the approval / rejection / conditional approval process via button interaction, and all operation and approval records are written to an immutable audit log.
[0055] The "illusion" problem of LLM in operation and maintenance scenarios (generating non-existent commands, incorrect parameters, or false execution results) is one of the core risks of automated operation and maintenance. Existing methods rely solely on the probability values of LLM outputs to determine confidence, but in operation and maintenance tasks, a high probability output by LLM does not equate to high correctness (for example, LLM may have a 99% token probability when outputting the command "rm -rf / ", but the command itself is incorrect). This invention proposes a confidence assessment method based on Bayesian calibration, which evaluates the confidence of each operation command generated by LLM. Perform independent confidence level calibration: ; in, Indicates operation instructions Correct binary events, This is a vector of four calibration features. The specific meanings of the four features are: (1) For LLM instructions The original output probability (obtained by softmax normalization of the output logits); (2) To score grammatical correctness, the instructions will be... Syntax is checked using a predefined shell command syntax parser (supporting 17 operational command syntaxes including bash, SQL, Kubernetes, and Ansible). If it passes the check... =1.0, otherwise take a value of 0~0.5 according to the severity of the error; (3) To determine the success rate of similar historical operations, the top 5 historical records with the highest semantic similarity are retrieved from the lesson memory, and the percentage of successful executions is calculated. If no reference record is available, the value is 0.5. (4) To score the reasonableness of parameters, the reasonableness of path parameters (such as / etc / nginx / nginx.conf), network parameters (such as IP address and port number), and database parameters (such as table name and field name) in the command are validated. This includes checking if the path exists, if the port range is valid, and if the table name is registered in the database. Calibration parameters. and The dataset was fitted using regularized logistic regression (L2 regularization coefficient λ=0.1) on a historical operations and maintenance dataset. The training samples consisted of 2000 manually labeled LLM operations and maintenance instructions (including positive and negative examples).
[0056] After calibration, set the confidence threshold. =0.85, when When this instruction is marked as "low confidence," it automatically triggers the approval process or requires the LLM to be regenerated. In testing, this Bayesian calibration method reduced the false execution rate of LLM instructions from 4.7% to 0.6% without calibration, while the false blocking rate (misclassifying correct instructions as low confidence) was only 1.2%. Specifically, the algorithm successfully blocked three instances of the LLM-generated instruction "rm -rf / "Dangerous Order ( =0.97 but =0.2 (due to obvious abnormalities in path parameters, the confidence level after calibration is only 0.32), which proves the unreliability of relying solely on the LLM output probability and the necessity of the calibration method of this invention.
[0057] In this embodiment of the application, the step after summarizing the execution results of each subtask to obtain the overall execution result further includes: The execution process data and overall execution results are written into the memory; the operation and maintenance skill plan is evaluated from multiple dimensions based on the overall execution results; when the comprehensive score meets the preset improvement conditions, the operation and maintenance skill plan is optimized and updated, and the optimized operation and maintenance skill plan is generated and stored in the skill library.
[0058] Furthermore, the skill execution results are evaluated from four dimensions: success rate, execution efficiency, result correctness, and operational safety. When the success rate in the comprehensive score is lower than the preset threshold, the rule engine matches the predefined improved rule template to adjust the default values of the operation and maintenance skill solution parameters, the operation execution order, or the exception handling branch, generating a new version of the operation and maintenance skill solution and storing it in the skill library.
[0059] This application employs a context-aware bandit skill evolution algorithm to perform the optimization process. Traditional skill improvement uses fixed rule templates (such as parameter tuning and order rearrangement), which cannot adaptively select the optimal improvement strategy under different operational scenarios. This invention models the optimization process of skill parameter configuration as a context-aware bandit problem. Let the skill... There are M adjustable parameters Each parameter have Given a set of candidate values, all possible parameter combinations constitute a parameter of size . The configuration space. Instead of exhaustively searching this exponential space directly, a hybrid strategy of "LinUCB + experience replay" is used to solve it: ; in, This is a set of candidate improvement strategies (parameter tuning, order rearrangement, exception completion, and condition expansion). This is the context feature vector for the t-th execution (containing 12 dimensions such as server size, fault type, and execution environment complexity). For strategy The linear regression coefficients, Let covariance matrix be the variance matrix. For exploration - utilizing balance coefficients (default) =0.3, which, as verified by grid search, represents the optimal trade-off between exploration coverage and utilization efficiency.
[0060] The intuitive meaning of this formula is: choose the option with the highest expected return (the first term). And the uncertainty is high (second item) The strategy is to try different approaches to achieve a balance between utilizing known optimal strategies and exploring unknown strategies. An experience replay buffer retains the most recent N=200 execution records; B=32 records are randomly sampled from the buffer for training each time the model is updated. It uses online gradient descent for updating the learning rate. Compared to the fixed rule template method, the advantage of this algorithm is that when the system faces different failure modes (disk alarms, CPU deadlock, service anomalies, etc.) during the 30-day test period, the accuracy of automatic selection of parameter tuning strategies increases from 73% to 91%, and the number of strategy switching times is reduced by 62%.
[0061] In this embodiment, there is a linkage mechanism between the memory and the skill library: the skill execution result is automatically written into the lesson memory layer; when an operation and maintenance event is received, historical processing experience is retrieved from the lesson memory layer as a reference context for skill execution; the user preference memory layer is used to influence the default parameter values of skill units; the environmental information memory layer is used for feasibility verification before skill execution; and the failure cases in the lesson memory layer are used to drive parameter adjustments in the skill improvement process.
[0062] In this embodiment, the system also includes timed inspection and automatic repair steps: a timed inspection task is configured based on the CRON expression, and after the inspection is started at a set time, the sub-agent entrusts the system to create multiple sub-agents to perform the inspection operation in parallel; when an anomaly is detected, the repair operation is automatically performed; when the repair operation fails, the alarm escalation process is executed, including generating a deep analysis report, sending an upgrade alarm through multiple channels, and generating operation suggestions for manual reference.
[0063] In summary, the method of this invention achieves a complete closed loop through the following steps: **Perception:** Obtain operational event information through monitoring system alarms, scheduled task triggers, Webhook events, or direct user input. **Context Construction:** Retrieve environmental information, user preferences, and historical lessons from the three-layer memory architecture to construct a complete operational context, while simultaneously calling the Prometheus API to obtain real-time monitoring data of the target server as dynamic supplementation. **Skill Matching:** Retrieve the most suitable operational skill solutions for the current operational scenario from the skill library based on a hybrid retrieval strategy. **Inference and Decision-Making:** The core engine concatenates the operational context, matched skills, and historical lessons into a structured Prompt template, which is submitted to the LLM for inference analysis. The Prompt template adopts a five-segment structure: system role definition segment, environmental information segment (server list and status), task description segment (current alarm or request content), available tool segment (matched skill modules and MCP tool definitions), and output format constraint segment (requiring the LLM to output an operation plan in JSON format, including the reasoning, operations sequence, and safety_checks fields). Based on this, the LLM generates an operational operation plan containing operation objectives, specific step sequences, and safety pre-check conditions. Task Decomposition and Distribution: For complex tasks, the core engine assesses the parallelizability of the task, decomposes the operation plan into multiple sub-tasks, and delegates them to the system through sub-agents for parallel distribution and execution using a canary deployment strategy. Tool Execution: The specific operation and maintenance tools are called through the MCP protocol integration layer to execute operation instructions. The MCP protocol defines three standardized interfaces: tool discovery (list_tools returns the tool name, description, and parameter schema), tool invocation (call_tool takes parameters and returns the execution result), and resource access (read_resource obtains structured resources such as monitoring data). It supports standardized integration of operation and maintenance tools such as Ansible, Terraform, Kubernetes, Docker, MySQL, Redis, Nginx, and Systemd. When adding a new operation and maintenance tool, only one MCP server program needs to be written to implement the above three interfaces to connect, reducing the development workload from several days in traditional integration to about 2 hours. Result Feedback and Memory: The execution process and results are written to a memory bank, including operation steps, execution status, output content, and exception information. At the same time, successful handling experiences are automatically written to the lesson learning memory. Skill evolution: The execution results are evaluated from four dimensions: success rate, execution efficiency, result accuracy, and operational safety. The scoring formula is as follows: ; in, Let be the success rate of the i-th execution. Let i be the execution time for the i-th execution. Score the correctness of the result of the i-th execution. , , These are the weighting coefficients.
[0064] When the score falls below a threshold (default 85%), the skill improvement process is automatically triggered. The 85% success rate threshold is based on the following: Statistical analysis of skills shows that when the overall skill score exceeds 85%, the failure probability of subsequent runs is only 3.2%, while below 85%, the failure probability jumps sharply to 18.7%. Therefore, 85% is a reasonable dividing line between reliable skills and skills that need optimization. Skill improvement adopts a hybrid strategy of "rule engine as the main method and template matching as a supplement." First, it matches predefined improvement rule templates (parameter tuning template, execution order reordering template, exception handling completion template, conditional branch expansion template) based on the failure type. If no matching rule is found, it uses the longest common subsequence algorithm to extract successful operation patterns from the 10 most recent execution records to generate improvement suggestions. Improved skills are saved with incremental version numbers (e.g., v3.2→v3.3), while older versions are retained for 31 days for rollback.
[0065] The present application will be further described below with reference to specific embodiments: The intelligent agent engine upon which this invention is based can be selected from intelligent agents such as Hermes-Agent, OpenClaw, and OpenHuman, or their variants, and can be optimized and improved in combination with the algorithm in this paper.
[0066] Automated closed-loop processing of server disk alarms: This embodiment describes the complete closed-loop process of automatically completing alarm reception, context awareness, skill matching, reasoning decision-making, execution repair, memory storage, and skill evolution when the monitoring system detects that the server disk usage exceeds the threshold.
[0067] Phase 1: Alert Detection and Context Building. Assume the Prometheus Alertmanager monitoring system detects that the root partition ( / ) of the server web-01.example.com has reached 92% disk usage, exceeding the 85% warning threshold. Alertmanager pushes an alert to the system via a webhook. The multi-channel gateway system receives the alert and performs deduplication using alertname + "|" + instance as the event_id. The core engine retrieves the context from the memory: Environment information memory shows that web-01 is an Nginx reverse proxy server (Ubuntu 22.04 LTS), with a total root partition capacity of 40GB, of which 36.8GB is used, running Nginx 1.24 and Node.js applications; Lessons learned memory retrieves that the server experienced a similar alert last week (85% disk usage), at which time the usage was reduced to 65% by cleaning up the Nginx access logs; User preference memory shows the operations administrator's preference: important logs must be backed up to a remote archive server before disk cleanup, and secondary confirmation is required when using the --no-preserve-root parameter.
[0068] Phase Two: Skill Matching and Inference Decision. The core engine converts the event description into a query vector using the BAAI / bge-large-zh-v1.5 embedding model and performs a mixed retrieval in the Milvus vector database. The top three skills with the highest cosine similarity in the search results are: Skill A "Disk Space Cleanup Skill" (similarity 0.92, version v3.2), Skill B "Log Rotation Configuration Skill" (similarity 0.78, version v1.5), and Skill C "Large File Search Skill" (similarity 0.65, version v2.0). The core engine selects Skill A, which has the highest matching degree, and concatenates the alarm information, server configuration, historical lessons, and matching skills into a structured Prompt template, which is then submitted to the LLM (in this embodiment, GPT-4o is used, and the inference temperature parameter t=0.2 to ensure output stability). The LLM inference conclusion is: the root cause of the problem is the accumulation of Nginx access logs, and it is recommended to execute the disk space cleanup skill, prioritizing the cleanup of compressed Nginx access logs, retaining logs from the last 7 days, and backing up the logs to the archive server before cleanup.
[0069] Phase 3: Operation Execution. The core engine transforms the LLM inference results into a sequence of specific operation instructions, invoking disk space cleanup skills for execution. The execution process includes checking disk space distribution (df -h / ), checking the log directory size (du -sh / var / log / nginx / ), and listing the log files to be cleaned up (ls -lh / var / log / nginx / access.log). The process involved seven steps: backing up the logs to the archive server (rsync), cleaning up the backed-up logs (rm -f), reloading the Nginx logs (kill-USR1), and verifying the cleanup results (df -h / ). The log backup operation automatically triggered L2-level approval, but because this operation had been performed previously and the risk was manageable, it was automatically approved based on the most recent successful execution record. After execution, disk usage dropped from 92% to 58%, approximately 13.6GB of log files were cleaned up, and the total execution time was 12 seconds.
[0070] Phase Four: Results Feedback and Skill Evolution. After execution, the process is written to the lessons learned memory (Event ID: disk_cleanup_20250520_001), and the disk usage in the environment information memory is updated. Skill evaluation is scored across four dimensions: 100% success rate, 12 seconds efficiency (threshold 60 seconds), correctness met, and no security triggers. This automatically generates skill improvement suggestions: A new sub-skill, "Automatic Nginx Log Rotation" (configured for weekly automatic rotation and cleanup), adjusting the retention period for compressed logs from the default 30 days to 7 days, and adding the parameter "server_role" to prioritize Nginx log cleanup when the server role is identified as nginx_reverse_proxy. These improvement suggestions are written into the skill library in the new version v3.3 draft. Overall score calculation: Q=(1.0×0.4+min(1,60 / 12)×0.3+1.0×0.3)=0.4+0.3+0.3=1.0, which exceeds the 85% threshold. The skill will remain in the current version as the recommended version, and the improvement suggestions will be added to the review queue.
[0071] Parallel operation and maintenance and scheduled inspection of large-scale clusters: This embodiment describes two typical scenarios: large-scale service restart and scheduled full inspection, demonstrating the ability of multi-agent parallel collaboration and automatic repair.
[0072] Scenario A: Canary rollout restart of 50 web servers. The operations and maintenance personnel enter "Help me rollout restart the Nginx service on all machines in the web cluster, using a canary strategy, 5 servers at a time" in the enterprise WeChat group. The core engine identifies the task elements through LLM semantic parsing: target web cluster (50 servers), operation command to restart Nginx service, execution strategy of rolling restart, canary batch of 5 servers at a time, and default batch interval of 30 seconds. The main agent divides the 50 servers into 10 batches based on the canary batch size. Each subtask contains a complete sequence of operation instructions: nginx -t pre-check configuration, call the HAProxy API via socat to remove nodes, sleep for 30 seconds to wait for connection exhaustion, systemctl restart nginx to restart, curl health check, and rejoin the load balancer. The main agent creates 10 sub-agent instances, each responsible for one batch of 5 servers, and the execution flow adopts a serial batch + intra-batch parallel strategy. After batch 1 is completed, the main agent summarizes the results (5 / 5 successful), pauses for 30 seconds according to the canary strategy, and sends a confirmation message. If the operations and maintenance personnel do not respond within 30 seconds, execution will automatically continue according to the default policy. During batch 3 execution, the web-13 health check returned an HTTP 503 error. The sub-agent automatically performed fault diagnosis, finding that Nginx was running normally but the upstream Node.js application had exited abnormally (Active: failed). After automatically executing `systemctl start node-app`, a second health check returned a 200 OK. After the repair was completed, the operation to add the load balancer continued. After all 10 batches were executed, the total time was approximately 11 minutes (650 seconds), an efficiency improvement of approximately 22 times compared to manual serial processing (estimated 250 minutes). Based on execution experience, the main agent automatically generated "Batch Nginx Rolling Restart Skill" v1.0, including parameters such as gray-scale batch size, batch interval, health check URL, automatic repair strategy, and rollback trigger conditions, and stored it in the skill library for future reuse.
[0073] Scenario B: Full scheduled inspection and automatic repair of 50 servers. The operations administrator configures a scheduled inspection task to be executed daily at 2:00 AM (cron_schedule: "0 2 The system covered 50 servers and performed 6 checks (disk usage, memory usage, CPU load, Nginx service status, SSL certificate expiration days, and journal log size). Each check had two threshold levels: Warning and Critical. At 2:00 AM, a scheduled task system triggered the inspection. After assessing the task scale, the core engine created 10 sub-agents, each responsible for a full check of 5 servers. The 10 sub-agents performed the inspection in parallel. The 6 checks on a single server took approximately 8 seconds, totaling 40 seconds for 5 servers sequentially, and approximately 40 seconds for all 10 agents in parallel. This inspection found 3 anomalies: web-33 had a disk usage of 87% (exceeding the Warning threshold of 80% but not exceeding the Critical threshold of 95%), web-28 had an inactive Nginx service status, and web-15 had a log size of 1.2GB (exceeding the Warning threshold of 1GB). Automatic repair operations were performed: web-33 was repaired via journalctl. The `--vacuum-time=3d` command cleaned up the Journal logs, and with the configuration `SystemMaxUse=500M`, the usage rate dropped to 73%. Web-28 diagnostics revealed a mismatch between the upstream PHP-FPMSocket path (` / var / run / php-fpm.sock`) referenced in the Nginx configuration and the actual path (` / run / php / php8.1-fpm.sock`). Automatic replacement with `sed` resolved the issue, and Nginx started successfully. Web-15, using `journalctl --vacuum-size=500M` with a permanent limit configured, reduced the log size to 498MB. All repairs were verified successfully, with a total time of 1 minute and 30 seconds. An inspection report was generated and sent to the operations and maintenance company's WeChat group via the gateway, containing statistics on 297 normal items, 3 abnormal items (all automatically repaired successfully), and 0 upgrade requests.
[0074] This embodiment also demonstrates an alarm escalation scenario for a failed repair. Assume that during a routine inspection, the web-45 disk usage reaches 97% (exceeding the critical threshold of 95%). Automatic repair attempts to clean up the MySQL binary logs (mysqlbinlog --expire-logs-seconds=86400), but the lock wait times out due to high load on the MySQL instance. After the repair fails, the alarm escalation process begins: a deep analysis report containing server information, exception details, and automatic repair logs is generated; multiple notifications are sent via WeChat Work, SMS, and telephone voice broadcast; the L4-level risk assessment only generates operational suggestions (expanding the disk, migrating part of the database, cleaning the Binlog), without automatically performing any write operations; and on-duty maintenance personnel confirm the approval via WeChat Work before manual intervention.
[0075] Cross-channel alarm linkage, high-risk command approval, and memory-driven evolution: This example describes three in-depth scenarios showcasing the core features of the system.
[0076] Scenario A: Cross-channel alarm reception, deduplication, and automatic response. Assume the same CPU utilization exceeding the limit alarm (web-42 CPU 95%, critical) is simultaneously pushed through three channels: Slack, email, and Telegram. The multi-channel gateway system extracts the same alertname and instance information from the fields field of the Slack attachment, the Subject field of the email, and the Telegram message text (using regular expressions), generating the same event_id="CPUUsageHigh|web-42.example.com". The Slack alarm arrives first and is written to Redis (event_id as the key, TTL=60 seconds). Approximately 3-5 seconds later, the email and Telegram alarms arrive, detect that the event_id already exists in Redis, determine it as a duplicate message, and discard it directly, preventing the same alarm from triggering three duplicate processing. The core engine retrieved lessons learned from its memory and found that the server had also experienced a CPU usage spike to 90% the previous week, caused by a Java thread infinite loop (historical event #20250513-003, resolved by locating the problematic thread using jstack and restarting Tomcat). The core engine input the alert information and historical lessons into the LLM (Gemini Pro was used in this example), and the LLM inference suggested executing the "CPU Usage Troubleshooting and Handling Skills". During execution, ps aux located PID 12345 (Java process using 850% CPU), top-H -p located thread ID 67890 (using 99% CPU), printf '%x\n' converted 67890 to hexadecimal 0x10932, and jstack 12345|grep -A 30 "0x10932" revealed that the thread was stuck in an infinite loop of while(true) in the com.example.OrderService.processOrder() method. After confirmation, execute `systemctl restarttomcat`. Verify service recovery after 10 seconds; CPU load dropped from 95% to 0.85%. Once repaired, reply with the processing result via Slack (the original alarm channel), and simultaneously send a unified notification (only one message after deduplication) to all channels through the multi-channel gateway, ensuring operations personnel can see the processing result on any channel.The skill assessment operation evaluation showed excellent success rate and efficiency. The "Automatic Detection of Java Thread Infinite Loops" submodule was automatically added to the "CPU Usage Troubleshooting and Handling Skills". When abnormal CPU usage of a Java process is detected, jstack is automatically executed and matched against the predefined infinite loop pattern library (currently including 12 common infinite loop patterns). The "auto_restart_tomcat" option (enabled by default) was added to the skill parameters. The new version v2.1 was written into the skill library.
[0077] Scenario B: Multi-level approval and audit trail for high-risk commands. An operations and maintenance personnel enters in a WeChat group, "Help me clean up all backup files older than 30 days in the / data directory on the web-50 server using the rm -rf command." After parsing the natural language, the core engine automatically generates the command to be executed: find / data -name "backup_ The command `rm -rf -mtime +30 -delete` is executed, and an automatic risk assessment is performed. The assessment results are as follows: command type `rm -rf` (high risk, score 80 / 100), target file ` / data` (non-system directory, medium risk, 40 / 100), affected single server (30 / 100), historical record of similar successful operations performed by this user last month (10 / 100), overall score 49 points, classified as Level 2 (requiring single-person approval). An approval request card is sent via WeChat Work group, including the initiator, risk level, operation description, target server, pre-executed command, and estimated impact. The approval request is simultaneously sent to WeChat Work (primary approval channel), DingTalk (backup channel), and email (formal backup). The operations manager clicks the "Agree" button in WeChat Work and records the approval information (approval). (Approver, Time, Channel, Remarks). After approval, a second confirmation is performed according to security policy requirements. A confirmation message is sent to the operations and maintenance personnel, who reply "Confirm Execution" before execution begins. A preview operation (list mode) is performed first to confirm the deletion of 120 files totaling approximately 15GB, before the actual deletion is executed. All operation and approval records are written to the audit log database, supporting multi-dimensional queries by time, personnel, risk level, approval result, and target server. This scenario also demonstrates two extended paths: approval rejection and conditional execution. When approval is rejected, a rejection reason notification is sent, suggesting verification of file integrity first; when executing conditionally, the approver inputs the condition "Only delete full_backup files older than 30 days". The file retains incremental_backup. The file will be automatically corrected, and the "correction executed" message will be added to the audit log.
[0078] Scenario C: The Positive Flywheel Effect of Skill Evolution Driven by the Memory Bank. This scenario demonstrates how the five interconnected links between the memory bank and the skill library generate a cumulative effect in actual operations and maintenance. Initially, the skill library contains 12 basic operations and maintenance skills (Disk Space Cleanup v1.0, CPU Troubleshooting v1.0, Service Restart v1.0, etc.), with an average comprehensive score of 73%. After 30 days of continuous operation, the processing results of each operations and maintenance event are written into the lessons learned memory through link ①, accumulating 112 valid records. When handling the disk alarm for the 15th time, link ② retrieves the complete processing records of the previous 14 times from the lessons learned memory and finds that 3 of the most recent 5 alarms are due to missing log rotation configuration rather than simple log accumulation. Based on this, LLM infers that "log rotation configuration needs to be installed simultaneously," rather than a simple cleanup operation. At the same time, the "Backup before each cleanup" preference setting in the user preference memory in link ③ is automatically injected into the default parameters of the skill, enabling the backup step automatically; the "This server is running a log-intensive application" flag in the environment information memory in link ④ prompts the skill to adjust the cleanup threshold from 85% to 80%. Following this execution, the overall skill score improved from 82% to 91%. Link ⑤ fed this successful experience into the skill improvement section, automatically adding a pre-check step of "checking and installing logrotate configuration" to the disk space cleanup skill v3.8. With continuous skill optimization, the skill library evolved from 12 basic skills to 47 optimized skill versions, and the average overall score increased from 73% to 92%, creating a positive flywheel effect of "more execution → more data → better skills → higher success rate → more execution".
[0079] The technical solution of this application is described below with reference to the accompanying drawings: See Figure 2 , Figure 2 The method demonstrates the modular implementation of each step at the system level, including a three-layer architecture: access layer (multi-channel gateway system, supporting unified access to multiple message channels), core engine layer (core engine connects skill library, memory library, provider-independent architecture), and execution layer (sub-agent delegation part, scheduled task part, Webhook event triggering part, MCP protocol integration layer, command approval security mechanism, etc.).
[0080] Figure 3 The system showcases the complete lifecycle of a skill, with multiple steps arranged clockwise: skill creation → skill storage → skill retrieval → skill loading → skill execution → skill evaluation → skill improvement → skill deployment, forming a self-evolving positive feedback loop. The center is the skill repository. A comprehensive skill rating is also provided. The improved process is automatically triggered when the value falls below a threshold, as calculated by the formula.
[0081] Figure 4After receiving an operation and maintenance task, the main intelligent agent decomposes the task into sub-tasks A / B / C / D, which are then distributed in parallel to four sub-intelligent agents through a sub-agent delegation system. Each sub-intelligent agent shares a skill library and memory library. The execution results are then aggregated to generate an operation and maintenance report. A canary release strategy is implemented in batches according to a preset batch size.
[0082] Figure 5 The system demonstrates the complete processing chain of alarm events through a multi-channel gateway system: alarms from monitoring systems such as Prometheus, Zabbix, and Grafana are accessed through the multi-channel gateway, and after event deduplication, they enter the processing pipeline of event classification → skill matching → intelligent decision-making → tool execution, and finally the processing results are fed back through the original channel.
[0083] Figure 6 This demonstrates CRON's scheduled full-scale inspection process (daily at 03:00). The system creates 10 sub-agents to inspect 50 servers in parallel, checking 6 items (disk / CPU / memory / service / certificate / logs). Upon anomaly detection, repair operations are automatically executed. Successful repairs are logged; unsuccessful repairs trigger an alarm escalation process, generating an in-depth analysis report and disseminating alerts through multiple channels.
[0084] Figure 7 This demonstrates the entire security approval process for operations and maintenance. The risk level assessment engine calculates a comprehensive risk score S based on a formula, classifying operations into four levels: L1 (automatic execution), L2 (single-person approval), L3 (multi-person approval), and L4 (manual intervention). L1 operations are automatically approved. L2-L4 operations distribute approval requests through multiple channels (Slack / Telegram / Email). Once approved, the operation is executed; otherwise, it is blocked and recorded in the audit log.
[0085] Figure 8 This demonstrates the system's deployment architecture in an enterprise environment. Users access the system via CLI / Web / mobile devices, reaching the core engine server (including LLM inference nodes) through a gateway server cluster. Support services are provided by the skill repository, memory database, and MCP tool server cluster. The provider selection strategy uses a Pareto optimization algorithm to calculate the optimal LLM provider. The managed server cluster can reach a scale of 50+ nodes.
[0086] Compared with the prior art, the present invention, based on the actual test data of the prototype system, can achieve the following technical effects: (1) Significantly reduced MTTR: In a test environment containing 50 servers, the average time for common faults such as server disk alarms was reduced from 45 minutes when handled manually to 1.5 minutes when handled automatically by the system, and the MTTR was reduced by about 96.7%. (2) More than 90% reduction in manpower input: In the actual operation and maintenance test for 30 consecutive days, 318 daily alarms and 4 scheduled inspection tasks were handled automatically, and only 7 required manual intervention (L3 / L4 level risk operations). After human-machine collaboration, the average daily intervention time of engineers was reduced from 6.2 hours to 0.4 hours. (3) Multi-agent parallel elimination of single-point bottlenecks: The total time for parallel inspection of 50 servers was only 40 seconds, close to the inspection time of a single server (6 seconds), and the processing time was reduced from linear growth to an approximately constant time. (4) Cross-session memory avoids repeated misoperations: During the 30-day test period, the lesson memory accumulated 112 valid records. When similar alarms are encountered, the historical solutions are automatically referenced, which improves the operation and maintenance accuracy from the initial 82% to 96%. (5) Automatic knowledge evolution forms positive feedback: The skill library automatically evolved from the initial 12 basic skills to 47 optimized skill versions. The average comprehensive skill score increased from the initial 73% to 92%, forming a positive flywheel effect. (6) Security approval mechanism ensures operational security: During the test period, the automatic execution of 3 high-risk commands was successfully intercepted (1 time the rm -rf path was mistakenly written, and 2 times the unauthorized operation was performed). The audit log fully recorded all 196 operation records.
[0087] The following describes an automated operation and maintenance system for computing devices based on intelligent agents provided by the present invention. The automated operation and maintenance system for computing devices based on intelligent agents described below and the automated operation and maintenance method for computing devices based on intelligent agents described above can be referred to in correspondence.
[0088] This application provides an automated operation and maintenance system for computing devices based on intelligent agents, including: The context building module is used to retrieve the relevant operation and maintenance context from the memory in response to received pending operation and maintenance events; The skill matching module is used to determine the operation and maintenance skill solution based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill library; The reasoning and decision-making module is used to input the operation and maintenance context and operation and maintenance skill solutions into the target large language model of the intelligent agent system to generate an operation and maintenance plan. The task execution module is used to break down the operation and maintenance plan into multiple sub-tasks based on parallel evaluation metrics, assign the sub-tasks to the corresponding intelligent agent execution units for execution, and summarize the execution results of each sub-task to obtain the overall execution result.
[0089] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A method for automated operation and maintenance of computing devices based on intelligent agents, characterized in that, include: In response to a received pending operation and maintenance event, the relevant operation and maintenance context is retrieved from the memory. The operation and maintenance skill scheme is determined based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill library; The operation and maintenance context and the operation and maintenance skill scheme are input into the target large language model of the intelligent agent system to generate an operation and maintenance plan. The operation and maintenance plan is divided into multiple sub-tasks based on parallel evaluation metrics, and the sub-tasks are assigned to the corresponding intelligent agent execution units for execution. The execution results of each sub-task are then summarized to obtain the overall execution result.
2. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 1, characterized in that, The memory bank includes three horizontal memory architectures: a user preference memory layer, an environmental information memory layer, and a lesson learning memory layer. The user preference memory layer is used to store at least the notification preferences, operating habits and permission scope data of operation and maintenance personnel; the environment information memory layer is used to store at least the static configuration information and dynamic running status data of the operation and maintenance environment; and the lessons learned memory layer is used to store at least the processing records and experience summary data of historical operation and maintenance events. The operation and maintenance context is a comprehensive information set generated by fusing data obtained from the user preference memory layer, the environmental information memory layer, and the lesson learning memory layer.
3. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 1, characterized in that, The step of determining the operation and maintenance skill scheme based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill library specifically includes: Calculate the semantic similarity between the semantic embedding vector of the operation and maintenance event to be processed and the semantic embedding vector of each candidate operation and maintenance skill in the skill base; A comprehensive score is obtained by comprehensively evaluating the semantic similarity, historical success rate information and timeliness information corresponding to each candidate operation and maintenance skill. The candidate operation and maintenance skills are sorted according to the comprehensive matching score to obtain the first preset number of candidate operation and maintenance skills, so as to determine the optimal operation and maintenance skill scheme.
4. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 1, characterized in that, The large language model is invoked through a provider-independent architecture, which selects the target large language model of the agent system from multiple available large language models based on the Pareto multi-objective optimization algorithm.
5. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 1, characterized in that, The steps of breaking down the operation and maintenance plan into multiple sub-tasks based on parallel evaluation metrics, assigning the sub-tasks to corresponding intelligent agent execution units for execution, and summarizing the execution results of each sub-task to obtain the overall execution result specifically include: The operation and maintenance plan is broken down into multiple sub-tasks based on parallel evaluation metrics; Create sub-agent instances with the same number of sub-tasks, and assign each sub-task to the corresponding sub-agent instance for execution to obtain the execution result for each sub-task; The main intelligent agent summarizes the execution results of each subtask to obtain the overall execution result of the operation and maintenance event to be processed; The parallel evaluation metrics include at least the number of affected servers, the number of operation steps, the complexity of dependencies between operations, and parallel feasibility related to the operation and maintenance plan.
6. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 5, characterized in that, The process of assigning each subtask to a corresponding sub-agent instance for execution adopts a canary release strategy. The gray-scale release strategy is as follows: all the sub-agent instances are divided into multiple batches according to a preset batch size. Each sub-agent instance in the same batch executes its assigned sub-task in parallel. After the current batch is completed, it waits for a confirmation instruction or waits for a preset interval before executing the next batch. If the failure rate of the current batch exceeds the preset threshold during execution, a rollback operation is automatically triggered to stop the execution of subsequent batches and restore the state to that before execution.
7. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 1, characterized in that, The steps prior to responding to the received pending maintenance event further include: The system receives maintenance messages from at least one message channel through a multi-channel gateway system and converts them into standardized internal message formats. Event identifiers are extracted from each of the standardized operation and maintenance messages, wherein the event identifiers are generated using the hash time slot method; Within a preset time window, duplicate operation and maintenance messages are deduplicated based on the event identifier, so that the first non-duplicate event received is taken as the operation and maintenance event to be processed.
8. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 1, characterized in that, The steps before breaking down the operation and maintenance plan into multiple sub-tasks based on parallel evaluation metrics also include a command approval security mechanism. The command approval security mechanism specifically involves: assessing the risk level of each operation instruction in the operation and maintenance plan to obtain a comprehensive risk score; Based on the comprehensive risk score, each of the operation instructions is classified into automatic execution level, single-person approval level, multi-person approval level, or manual intervention level. When the operation instruction is classified as requiring approval, an approval request is sent to the approval end through the multi-channel gateway system. The operation instruction is executed only when an approval response is received, and the corresponding operation record and approval record are written to the audit log.
9. The automated operation and maintenance method for computing devices based on intelligent agents according to claim 1, characterized in that, The step after summarizing the execution results of each subtask to obtain the overall execution result further includes: The execution process data and the overall execution result are written into the memory. The operation and maintenance skill solution is evaluated from multiple dimensions based on the overall execution results. When the comprehensive score meets the preset improvement conditions, the operation and maintenance skill solution is optimized and updated, and the optimized operation and maintenance skill solution is generated and stored in the skill library.
10. An automated operation and maintenance system for computing devices based on intelligent agents, characterized in that, include The context building module is used to retrieve the relevant operation and maintenance context from the memory in response to received pending operation and maintenance events; The skill matching module is used to determine the operation and maintenance skill scheme based on the semantic similarity between the operation and maintenance event to be processed and each candidate operation and maintenance skill in the skill library; The reasoning and decision-making module is used to input the operation and maintenance context and the operation and maintenance skill plan into the target large language model of the intelligent agent system to generate an operation and maintenance plan. The task execution module is used to break down the operation and maintenance plan into multiple sub-tasks according to the parallel evaluation indicators, assign the sub-tasks to the corresponding intelligent agent execution units for execution, and summarize the execution results of each sub-task to obtain the overall execution result.