Intelligent change risk assessment method and system based on multi-agent, electronic device, program product

Abstract

The application provides a multi-agent-based intelligent change risk assessment method. The method can include: receiving a change request and forming a change data object; packaging the change data object as a message and publishing the message to a topic of a message bus, which is subscribed by a task distribution controller; based on the change assessment task involved in the message, distributing it to multiple different agents; each agent receiving the change assessment task performs specific analysis on the change data object involved in the message and generates a preliminary analysis report, the specific analysis being analysis of specific aspects of the change data object; each agent publishes the preliminary analysis report generated by it to an aggregation topic of the message bus; fusion processing is performed on the analysis reports from different agents on the aggregation topic to generate a final assessment result; wherein, when there is a conflict between the analysis reports from different agents, a conflict point is marked and a conflict resolution mechanism is triggered; wherein, each agent is configured with a large language model. The corresponding system, electronic equipment and program product are also provided.

Description

Technical Field

[0001] This application relates to the maintenance of financial data centers, and more specifically, to intelligent change risk assessment technology based on multi-agent systems. Background Technology

[0002] As a core infrastructure supporting enterprise business operations, the primary responsibility of data centers is to ensure the continuous, stable, and secure operation of the production environment. With the continuous expansion of business and the widespread application of technologies such as cloud computing, distributed systems, and big data, the scale of data center operation and maintenance management systems is increasing, and the complexity of their architecture is also rising. Against this backdrop, data centers are undertaking increasingly heavy production change management tasks in their daily operations. Even minor oversights in change implementation can lead to system anomalies or service interruptions. Therefore, avoiding the impact of change implementation on the stable operation of production business has become one of the main challenges for data center operations. Summary of the Invention

[0003] According to one aspect of this application, a multi-agent-based intelligent change risk assessment method is provided to address at least one of the problems mentioned herein.

[0004] According to one aspect of this application, a multi-agent-based intelligent change risk assessment method is provided. The method may include: receiving a change request and forming a change data object; encapsulating the change data object into a message and publishing the message on a topic of a message bus, which is subscribed to by a task distribution controller; distributing the message to multiple different agents based on the change assessment task involved in the message; each agent receiving the change assessment task performing a specific analysis on the change data object involved in the message and generating a preliminary analysis report, the specific analysis being an analysis of a specific aspect of the change data object; each agent publishing its generated preliminary analysis report to an aggregation topic of the message bus; fusing the analysis reports from different agents on the aggregation topic to generate a final assessment result; wherein, when there is a conflict in the analysis reports from different agents, the conflict point is marked and a conflict resolution mechanism is triggered; wherein each agent is configured with a large language model.

[0005] As an example, additionally, each agent receiving the change assessment task performs a specific analysis on the changed data object involved in the message and generates a preliminary analysis report, including: each agent receiving the change assessment task performs a specific analysis on the changed data object through its included large language model, wherein, during the analysis process, the agent calls a data verification module to enable the agent to perform vectorized matching retrieval with a dedicated knowledge base, thereby obtaining accurate knowledge to ensure the consistency between the analysis results and the facts; wherein, the data verification module employs retrieval-enhanced generation technology.

[0006] According to one embodiment of this application, a multi-agent-based intelligent change risk assessment system is provided. The system may include: a data acquisition module configured to form a change data object based on a received change request, encapsulate the change data object into a message, and publish the message to a topic on a message bus; a task distribution controller configured to subscribe to the topic and distribute the task to multiple different agents based on the change assessment task involved in the message; a data analysis module including the multiple different agents, each agent receiving the change assessment task performing a specific analysis on the change data object involved in the message and generating a preliminary analysis report, wherein the specific analysis is an analysis of a specific aspect of the change data object; the data analysis module is configured to publish the preliminary analysis report generated by each agent to an aggregation topic on the message bus; an aggregation module configured to fuse the analysis reports from different agents on the aggregation topic to generate a final assessment result; wherein the aggregation module is configured to mark conflict points and trigger a conflict resolution mechanism when there are conflicts in the analysis reports from different agents; wherein each agent is configured with a large language model.

[0007] As an example, the system may additionally include a data verification module configured to receive query requests from different agents, search for text matching the query request from a dedicated knowledge base based on retrieval enhancement generation techniques, combine them into a coherent context, and return the query request to the agent that issued the query request, wherein the query request includes a question described in natural language and related context.

[0008] As an example, the system may additionally include a persistence module configured to store data during each change risk assessment process, generating natural language causal chain summaries.

[0009] The intelligent change risk assessment method or system based on multi-agent technology, as exemplified in this application, can understand the natural language semantics of changes and the implicit cascading relationships across systems, thus avoiding missed and false alarms caused by insufficient coverage of complex or novel changes. Furthermore, the intelligent change risk assessment method or system based on multi-agent technology, as exemplified in this application, can also perform dynamic assessments based on historical data and continuous changes in the real-time operating status of the system, and in some examples can output explanatory causal chains, forming an efficient and consistent change decision-making mechanism. Attached Figure Description

[0010] This application will be more fully understood by referring to the following detailed description of specific embodiments in conjunction with the accompanying drawings, wherein the same reference numerals in the drawings refer to the same elements, wherein: Figure 1 This is a flowchart of a multi-agent-based intelligent change risk assessment method according to some embodiments of this application; Figure 2 This is a schematic diagram of the structure of a multi-agent intelligent change risk assessment system according to an embodiment of this application; Figure 3 This illustrates the quantitative evaluation process during the fusion processing of the aggregation module 26; Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described implementation methods are only a part of the implementation methods of the technical solutions of this application, and not all of them.

[0012] An intelligent agent is an artificial intelligence proxy that can be software, hardware, or a combination thereof. An intelligent agent can perceive changes in its environment (e.g., through sensors or data input), make judgments and decisions based on its learned knowledge and algorithms, and then perform actions to influence the environment or achieve predetermined goals. Intelligent agents based on Large Language Models (LLMs) utilize LLMs and multimodal foundational models to achieve flexible and adaptive decision-making. They can process text, images, and audio, enabling them to perform interactions including natural language understanding, autonomous problem-solving, planning, and reasoning.

[0013] Retrieval Augmentation (RAG) is an artificial intelligence architecture that combines information retrieval with large language model generation. It enables models to retrieve relevant and up-to-date information from external knowledge bases when answering questions and generate answers based on this information. This overcomes the shortcomings of traditional large models that rely solely on internal training data and may produce "illusions" (fabricated information) or outdated knowledge.

[0014] Figure 1 This is a flowchart of a multi-agent-based intelligent change risk assessment method according to some embodiments of this application. The method can be executed by a data processing device, such as a laptop, tablet, smartphone, smart wearable device, etc., and can also be executed in the cloud.

[0015] In step S10, a change request is received and a change data object is formed. Specifically, a change request is received; based on the identifier of the change request, different data sources are connected via adapters; the data required for the change is collected from the data sources; and the collected data is processed to form a change data object. For example, a change request is received from a change management platform, and this request contains a change identifier ID used to identify it. The data acquisition operation is activated upon receiving the change request. During the data acquisition phase, based on the change identifier ID, multiple heterogeneous data sources are connected via preset adapters, i.e., standardized interface conversion and data compatibility components, to collect the data required for the change. These multiple heterogeneous data sources include, for example, configuration management databases (CMDB), application monitoring systems, automated task libraries, knowledge bases, change modules, event modules, etc. The collected data required for the change includes basic change data, change implementation step data, and change impact data. The basic change data can be queried from the change management platform to obtain complete change form information, including but not limited to change type (standard or urgent), detailed text description of the change plan, test reports, rollback plans, etc. Change implementation steps can be obtained by parsing the step descriptions in the change plan. If the steps involve automated scripts, the original script content can be retrieved from the automation platform. Change impact data can include direct impact and related impact data. Direct impact can be determined by obtaining the impact radius to identify the scope of directly affected configuration items. Related impact can be determined by querying the service topology interface of the configuration management database, analyzing the service call chain relationship of the target application configuration item (ConfigurationItem, CI), and identifying its upstream and downstream calls. After collecting all the data required for the change, the collected data is processed, specifically by transforming unstructured data into structured data. For example, the data can be formatted according to predefined JSON rules to form a unified, structured change data object.

[0016] In step S12, the changed data object is encapsulated into a message and published to a topic on the message bus that the task distribution controller has subscribed to. For example, the changed data object, i.e., structured data, is encapsulated according to the message bus protocol specifications. Through a three-layer encapsulation of data carrier, metadata, and protocol header, a complete message that can be transmitted in the message bus and parsed by subscribers is finally formed. The message is published to a message bus topic, such as a specified topic, and the task distribution controller, having subscribed to that topic, will receive the message. In this example, the task distribution controller is configured to obtain messages by subscribing to topics, allowing it to simply listen to the topic, reducing its dependence on the upstream module that publishes messages. Furthermore, if the upstream module directly publishes messages to the distribution controller, it needs to know the distribution controller's address, calling method, parameter format, etc. If these configuration details of the distribution controller are upgraded, the upstream module needs to be upgraded synchronously, leading to increased maintenance costs.

[0017] In step S14, based on the analysis task involved in the message, it is distributed to multiple different agents. Upon receiving the message, the task distribution controller parses the message and, according to the parsed message content and preset routing rules, distributes the change assessment task to be performed to one or more specialized agents that have subscribed to the relevant task messages. These agents are thus activated and enter the task analysis state. As an example, these agents may include solution analysis agents, script analysis agents, correlation analysis agents, historical case analysis agents, etc.

[0018] In step S16, each agent that receives the change assessment task performs a specific analysis on the changed data object involved in the message and generates a preliminary analysis report. The specific analysis focuses on specific aspects of the changed data object. Each agent is configured with a large language model and dedicated tools, which are related to the specific analysis to be performed by the agent, such as the dedicated knowledge base mentioned below.

[0019] In this embodiment, each agent used to evaluate the change task is a pre-trained agent designed for specific analysis. Each agent has built-in logic for calling a large language model and is given instructions and tools specific to the task; in short, each agent is an independent microservice. Upon receiving the task, the agent is activated. Each activated agent utilizes its included large language model and specialized tools to analyze specific aspects of the changed data object. For example, a script analysis agent can review the syntax and logic of the code line by line, while a correlation analysis agent can analyze the scope of the change's impact based on CMDB dependencies. During the analysis, the agent can call a data verification module to perform vectorized matching and retrieval of the analysis against a dedicated knowledge base, thereby obtaining accurate indications to ensure the consistency of the analysis results with the facts. After each agent completes the analysis, it generates a structured preliminary assessment report containing risk findings, quantitative scores, confidence levels, and supporting evidence links, which may be in JSON format, for example.

[0020] Based on some examples in this application, when the agent needs to make judgments based on internal standards or historical knowledge, it will actively invoke the data verification module. This module uses Retrieval Enhancement Generation (RAG) technology to perform vectorized matching retrieval of the agent's analytical queries against a dedicated knowledge base (such as a standard operating procedure document library, system encyclopedia, historical event recaps, etc.). The most relevant text fragments retrieved are used as contextual information and injected into the agent's prompts, which are then submitted to the large language model. This provides the large language model with accurate, context-relevant background knowledge to ensure the factual consistency of its analysis results and avoid the large language model generating "illusions" that do not conform to internal standards.

[0021] For example, during training, the solution analysis agent is tasked with simulating a senior operations manager, evaluating the rationality, completeness, and clarity of change requests. More specifically, it evaluates the rationality, completeness, and clarity of the change plan itself. In implementation, the agent receives text information such as change descriptions, implementation plans, and rollback plans. Pre-defined prompts for this role guide the larger model to determine whether the change plan includes clear objectives, detailed steps, sufficient validation items, and a feasible rollback path. For instance, prompts might include: "You are a senior data center operations expert. Please evaluate the quality of the change plan, scoring it across three dimensions: completeness of steps (0-10 points), risk statement (0-10 points), and rollback feasibility (0-10 points). Return your findings in JSON format, pointing out any ambiguous or missing parts." The solution analysis agent can then output its analysis results according to a predefined format.

[0022] For example, the role of a script analysis agent is to simulate a database administrator or system engineer, statically analyzing high-risk operations in the execution scripts contained within changes. In this process, the script analysis agent first uses regular expressions or a syntax tree parser to quickly identify explicit high-risk instructions (such as destructive deletion instructions like `rm -rf` or `DROP TABLE`); then, it submits the script fragments and contextual information to a large language model to analyze their operational intent and potential unintended consequences. The script analysis agent can then output the analysis results according to a predefined format.

[0023] For example, the role of the correlation analysis agent is to simulate an application architect, assessing the potential impact range (explosion radius) and cascading failure risk of changes based on CMDB data. In implementation, the correlation analysis agent receives the CI list and dependencies from the change impact information. It uses a large language model to understand the business meaning of these dependencies and judges the potential cross-system and cross-business chain reactions caused by the change. For example, the target of the change, "Order Service," is a critical node in the core transaction chain, with its upstream dependent on the payment gateway and its downstream dependent on the settlement service. The agent assesses the potential impact level (low / medium / high) of a 30-minute service interruption on upstream and downstream businesses. The correlation analysis agent can output analysis results according to a predefined format.

[0024] For example, the historical case analysis agent's responsibility is to simulate an experienced engineer and search historical data for successful or failed cases similar to the current change. In implementation, the agent vectorizes the key features of the current change (such as CI type, change type, and keywords), then calls the vector retrieval interface of the persistence module to find the most similar historical change records. The execution results (success / failure / failure) of these historical records are analyzed as a reference for this risk assessment. The historical case analysis agent can output the analysis results according to a predefined format.

[0025] It should be noted that the above examples are merely illustrations of intelligent agents. In practical applications, the number of agents, the specific tasks they perform, and the input and output data formats may all differ from the examples described above.

[0026] In step S18, each agent publishes its generated preliminary analysis report to the aggregation topic of the message bus. In step S20, the analysis reports from different agents on the aggregation topic are fused to generate the final evaluation result; wherein, when there are conflicts in the analysis reports from different agents, the conflict points are marked and the conflict resolution mechanism is triggered.

[0027] Specifically, preliminary assessment reports generated by all agents are published to the same aggregation topic on the message bus. Based on this topic, inputs from each agent are aggregated. A weighted fusion algorithm can be used to comprehensively calculate risk scores from different dimensions, generating an overall risk score and a suggested risk level. When assessment results from different agents conflict, the conflict point is marked and a conflict resolution mechanism is triggered. For example, the solution analysis agent assesses the risk as low, but the script analysis agent assesses it as high risk due to detecting database deletion risk. This conflict in risk level can be marked and the conflict resolution mechanism triggered. One example of a conflict resolution mechanism is outputting conflict details for user processing. For example, a "human-machine collaboration" process can be selectively initiated, pushing conflict details and awaiting domain expert intervention for decision-making. In some examples, the types of conflicts that trigger the conflict resolution mechanism can be predefined. For example, only significant conflicts trigger the conflict resolution mechanism, such as conflicts between high and low risk ratings, or conflicts between factual right and wrong statements.

[0028] As an example, in the process of generating the final evaluation result in step S20, the structured evaluation result, including risk score, level, risk causal chain, optimization suggestions, and supporting evidence list, can be further rendered into a readable comprehensive evaluation report. This comprehensive evaluation report can then be pushed back to the change management platform through an interface callback mechanism and embedded into the approval interface of the change request for decision-making reference by the change approver, implementer, and other relevant stakeholders.

[0029] In a further example, Figure 1 The multi-agent-based intelligent change risk assessment method shown may also include storing data from each change risk assessment process. After each change risk assessment is completed, a causal chain summary describing the cause and effect in natural language is generated, and a structured JSON format is output.

[0030] When storing the evaluation report, all cited evidence (referenced files, scripts, knowledge bases, historical similar events) is stored as attributes of the agent at the corresponding evaluation node (i.e., the evaluation phase). After each evaluation, the system generates a structured JSON object containing complete source information. Simultaneously, by using a large model to connect these structured findings and evidence, a coherent natural language summary is generated, which can explain the causal chain. For example, the risk rating for this change is high, mainly due to the following reasons: 1) A high-risk 'DROP TABLE' instruction was detected in the execution script (evidence: migrate.sql:15); 2) This change affects the core service 'Order Service', which may lead to transaction interruption (evidence: CMDB dependency path); 3) A similar change last month (CHG0011998) caused a database connection pool exhaustion failure (evidence: INC0056789).

[0031] Figure 2 This is a schematic diagram of the structure of a multi-agent intelligent change risk assessment system according to an embodiment of this application. Figure 2 As shown, the system includes a data acquisition module 20, a task distribution controller 22, a data analysis module 24, and an aggregation module 26. In a further example, the system also includes a display module 28. The data acquisition module 20 is configured to form a change data object based on a received change request, encapsulate the change data object into a message, and publish the message to a topic on the message bus. The task distribution controller 22 is configured to subscribe to the topic and distribute the message to multiple different agents based on the change evaluation task involved in the message. The data analysis module 24 includes the multiple different agents. Each agent receiving the change evaluation task performs a specific analysis on the change data object involved in the message and generates a preliminary analysis report. The specific analysis is an analysis of a specific aspect of the change data object. The data analysis module is configured to publish the preliminary analysis report generated by each agent to an aggregation topic on the message bus. The aggregation module 26 is configured to fuse the analysis reports from different agents based on the aggregation topic to generate a final evaluation result. The aggregation module is configured to mark the conflict points and trigger a conflict resolution mechanism when there are conflicts in the analysis reports from different agents. Display module 28 is used to display information such as the final risk report and conflict information. In some cases, display module 28 can also be used to display key milestones in the risk assessment process.

[0032] As an example, the data acquisition module 20 receives change requests from the change platform 30. Each change request is configured with a unique identifier (ID). Based on the identifier of the change request, the data acquisition module 20 determines which data sources should be accessed and connects to these heterogeneous data sources through adapters to collect the data required for the change. Data sources include, for example, configuration management databases (CMDB), application monitoring systems, automated task libraries, knowledge bases, change modules, event modules, etc. For simplicity, only the configuration management database 40 and the automated task library 42 are shown in the figure. The information obtained by the data acquisition module 20 from the heterogeneous data sources includes basic change data, change implementation step data, and change impact data.

[0033] Basic change data refers to the core attribute data recorded during change plan registration and planning, including but not limited to change type, change scheme, implementation strategy, testing and verification status, inspection and verification arrangements, rollback operations, risk response plans, and extreme situation assessments. Change implementation step data includes the manual and automated steps required for each change, involving information such as the planned start and end times of each step, as well as the associated operational risk level, automated task content, and manual step content. Change impact information can include three key impact categories: first, the change blast radius, i.e., the direct impact range of the change on application services, objectively identified based on change implementation operation configuration items and the topological relationships between configuration items in the CMDB; second, the impact of inter-application calls, analyzing the potential impact of a change in one application on other applications; and third, the inter-version impact, considering the interdependencies between different version deployment plans.

[0034] Specifically, the change platform 30 sends a change request to the data acquisition module 20 via an interface call. This request includes a change ID. The data acquisition module 20 parses the change request to obtain key fields such as change title, change description, planned implementation time, and a list of major configuration items (CI). The data acquisition module 20 also collects necessary data from various data sources, such as obtaining complete change form information from the change platform 30, including but not limited to change type (standard, urgent), detailed text description of the change plan, test report, and rollback plan. If the steps in parsing the change plan involve automated scripts, the data acquisition module 20 obtains the original script content from the automated task library 42 through the platform. The data acquisition module 20 can also directly obtain the blast radius through the change platform 30 to determine the scope of all directly affected configuration items, thereby obtaining the direct impact. In addition, the data acquisition module 20 can also analyze the inter-service call chain relationship of the target application CI through the service topology interface of the CMDB system to determine the upstream caller and downstream callee, thereby obtaining the related impact. The data acquisition module 20 can also integrate data from different data sources into a unified document that follows a predefined JSON format, for example: { "changeId": "CHG0012345", "metadata": { "title": "Upgrade Order Service to v1.2","type": "Standard Change"}, "content": { "description": "Deploy a new version to cope with increased load……", "implementationPlan": "1. Stop the application……", "rollbackPlan": "1. Redeploy the previous artifact version……"}, "artifacts": [{"type": "sql_script", "source":"pay / script.sql","content": "ALTER TABLE orders ADD COLUMN new_featureVARCHAR(255);"}], "context": { "primaryCis": ["Application: Order Service"],"impactedCis": ["..."], "serviceDependencies": {"upstream": ["Application: Payment Service"],"downstream": ["Application: Clearing Service"]}}}.

[0035] Furthermore, the data acquisition module 20 serializes the final JSON object and publishes it as a message body to a topic on the message bus, such as a topic named "New Change Analysis".

[0036] Task distribution controller 22 subscribes to topics on the message bus, such as the "New Change Analysis" topic, thereby obtaining messages by receiving structured change information output by data acquisition module 20, for example, through listening. Task distribution controller 22 then distributes the message to multiple different agents.

[0037] Each agent has been described above and will not be repeated here. In this example, each agent is comprised of the data analysis module 24. Each agent is configured with a large language model and is assigned a specific role, instruction set, and toolset, enabling them to perform different or specific analysis tasks. In this example, the agents communicate asynchronously via a message bus. The messages transmitted on the message bus are in a predefined JSON format. After each agent completes its task, it publishes the preliminary analysis results along with the corresponding change request ID for tracking and aggregation. According to the example in this application, each message should contain all the context information required to process the request, so that the agent itself does not need to store session state, and all relevant messages of a change request from start to finish can be linked together through a globally unique identifier, facilitating monitoring, debugging, etc.

[0038] According to the examples in this application, each agent subscribes to a designated topic on the message bus, for example, named "New Change Analysis." Each time a change is generated, each agent retrieves the change content. After completing its specific analysis, each agent publishes its evaluation report to an aggregated topic on the bus. As an example, the name of the aggregated topic might be, for example, "Preliminary Change Risk Assessment."

[0039] Once the data analysis module 24 has received all the risk assessment reports published by the agents on the message bus, it triggers the final assessment process. The aggregation module 26 collects all assessment results from each stage of the process from the agents based on their associated IDs, through subscribed aggregation topics, such as an aggregation topic named "Preliminary Risk Assessment of Change." When all expected preliminary reports have been received or have timed out, the aggregation module 26 performs the final analysis and weighted fusion calculation. This is an example, not a limitation. Figure 3The diagram illustrates the quantitative evaluation process of the aggregation module 26 during the fusion processing. In step S30, the output content of each agent is scored for standardization, for example, by scoring according to a numerical value of 0-10. Specifically, the risk level presented in the evaluation result is scored based on the evaluation result output by the agent. In step S32, the weighted average method is used to calculate the final comprehensive risk score according to formula (1), where the weighting coefficient is specified in advance for each agent. In step S34, the risk level is mapped. Specifically, the calculated comprehensive risk score is a continuous numerical value. To facilitate decision-making, the aggregation module 26 will map it to a discrete, easily understandable risk level according to a configurable range. Each risk level is represented by a threshold range. For example, the high-risk threshold range is [8.0, 10.0], the medium-risk threshold range is [5.0, 8.0], and the low-risk threshold range is [0, 5.0]. For example, a comprehensive risk value of 9 falls within the high-risk threshold range, indicating a high-risk level. It should be noted that this is just an example and not a limitation. For example, the threshold range for "medium risk" can also be (5.0, 8.0), and correspondingly, the threshold range for low risk is [0, 5.0], that is, when the comprehensive risk score is 5.0, it is considered low risk.

[0040] The formula (1) used in step S32 is shown below: Where i represents the i-th agent, n is the total number of agents participating in the evaluation, and i and n are both integers greater than 0; W is the standardized score output by the i-th agent. i is the pre-determined weight corresponding to the i-th agent, where the sum of all weights is 1.

[0041] During the fusion process, if conflict arises in the analysis reports from different agents, the aggregation module 26 marks the conflict point and triggers the conflict resolution mechanism. For example, if there is a conflict in the evaluation results between agents, such as a significant conflict, the aggregation module 26 can generate a conflict alarm in the final report after recognizing the conflict. According to preset rules, it can automatically set the change status to require manual review and call the interface of the change management platform through a synchronous interface callback to achieve human-machine collaborative intervention.

[0042] Based on the examples in this application, Figure 2The system shown may also include a data verification module 25. To ensure that the large language models of each agent can perform analysis and reasoning based on accurate and up-to-date factual data from the application party using the system or methods of this application, a data verification module 25 is set up to improve the reliability and credibility of the evaluation results, acting as a fact verifier. The data verification module 25 is configured to receive query requests from different agents, search for text matching the query request from a dedicated knowledge base based on retrieval enhancement generation technology, combine them into a coherent context, and return the query request to the agent that issued the query request. The query request includes a question described in natural language and related context. Here, the dedicated knowledge base can be a business-related knowledge base of the application party using the system or methods of this application. For example, it can be used in a background batch processing job to periodically parse internal documents of the application party, slice the parsed data into small segments, convert them into high-dimensional vectors through an embedding model, and store them in a vector database. When this application is used for data center maintenance, the internal documents of the application party may include operation and maintenance manuals, standard operating procedures (SOPs), architecture design documents, post-event review reports, etc. When an agent needs to verify whether items in a change plan conform to standards, it can query this dedicated database via an interface. For example, the agent sends a query question to the data validation module 25, which vectorizes the question and then performs a cosine similarity search in the vector database to find the document fragments most similar to the question vector. The most relevant text fragments are then combined into coherent context text and returned to the calling agent. In this way, the agent can use these fragments as context, together with the original question, to construct a new, more informative prompt, which is then sent to the larger model, guiding the model to answer based on its internal knowledge.

[0043] Based on the examples in this application, Figure 2The system shown may also include a persistence module 29, configured to store data from each change risk assessment process and generate a natural language causal chain summary. Specifically, the persistence module 29 stores data from each change risk assessment, such as full-process data, and generates a natural language causal chain summary, outputting structured data, such as JSON format. When storing the assessment report, the persistence module 29 stores all cited evidence as attributes of the assessment node. Cited evidence may include referenced files, scripts, knowledge bases, historical similar event IDs, etc. After each assessment, the persistence module 29 generates a structured JSON object containing complete source information. Simultaneously, it uses a large language model to connect these structured findings and evidence to generate a coherent natural language summary, thus explaining the causal chain. For example: This change is rated as high risk, mainly for the following reasons: 1) A high-risk 'DROPTABLE' command was detected in the execution script (evidence: migrate.sql:15); 2) This change affects the core service 'Order Service', which may lead to transaction interruption (evidence: CMDB dependency path); 3) A similar change last month (CHG0011998) caused a database connection pool exhaustion failure (evidence: INC0056789). The multi-agent-based intelligent change risk assessment system according to embodiments of this application can be used to execute the multi-agent-based intelligent change risk assessment method according to embodiments of this application. For example, the data acquisition module 20 executes steps S10 and S12. The task distribution controller 22 executes step S14. The data analysis module 24 executes steps S16 and S18. The fusion module executes step S20. During execution, the data acquisition module 20 can communicate with the data verification module 25 to search for the required knowledge. Furthermore, the persistence module 29 can perform data storage and generate natural language causal chain summaries for each change risk assessment process.

[0044] It should be noted that, in combination Figure 1 Possible embodiments and combinations of the described method Figure 2 The features in the various embodiments of the system described may be combined with each other without contradiction.

[0045] Combination Figure 2 The modules in the described system can be implemented through software, hardware, or a combination of both. For example, the system can be implemented by implementing the functions of each module in a programming language and then loading that programming language into hardware such as a processor.

[0046] This application also provides an electronic device. Figure 4This is a schematic diagram of the electronic device 5, which includes a memory 50 and a processor 52. The memory 50 is used to store instructions, and the processor 52 is used to process these instructions. In some examples, the processor 52 can implement any of the methods described herein during the execution of these instructions.

[0047] This application also provides a program product comprising instructions. In some cases, during the execution of these instructions, any of the methods described herein can be implemented. This application also provides a non-volatile storage medium storing instructions that, during the execution of these instructions, can implement any of the methods described herein.

[0048] By implementing the methods or systems according to the embodiments of this application, improvements to existing change assessment technologies can be achieved through a multi-agent collaborative architecture, large language model semantic understanding, dynamic evaluation mechanisms, and interpretable design. Compared with existing technologies that mainly rely on static rules, preset fields, limited risk databases, and difficulty in understanding the natural language semantics of changes, resulting in insufficient coverage for the identification of complex or novel changes and a high risk of missed detections, the method provided according to the embodiments of this application, through deep fusion of multiple agents, overcomes the limitations of static rules and achieves accurate analysis based on semantic understanding. For example, the solution analysis agent can use LLM to parse the natural language descriptions in the change solution (including text information such as implementation steps, rollback plans, and test reports), and combine it with a dedicated knowledge base (standard operating procedure document library, system operation and maintenance manual, etc.) for compliance verification. This allows for flexible adaptation to complex or new change scenarios, avoiding the problem of insufficient coverage of unknown scenarios by static rules. The correlation analysis agent obtains the upstream and downstream dependencies of the target application configuration items (CI) by calling the CMDB service interface, and uses a large language model to infer the business meaning behind the dependencies, accurately identifying implicit dependencies and cascading failure risks across systems. The script analysis agent uses a combination of syntax tree parser, regular expressions, and a large language model to first quickly locate explicit high-risk commands such as rm-rf and DROP TABLE, and then deeply analyze the script operation intent and potential unintended impacts through a large language model, significantly reducing the probability of false negatives and false positives compared to static rules.

[0049] Furthermore, the method or system according to the embodiments of this application generates a risk report through multi-agent collaborative risk assessment from different perspectives, thereby quantitatively assessing and comprehensively judging multi-dimensional risks. For example, the solution analysis agent assesses the completeness of the change plan, the sufficiency of the risk statement, and the feasibility of rollback; the script analysis agent assesses the complexity of executing the script and the risk of high-risk operations; the correlation analysis agent assesses the criticality of the business involved in the change and the scope of impact (explosion radius); the historical case analysis agent matches similar historical change records through vector retrieval technology and refers to their execution results (such as success, failure, or failure) to provide a basis for the current assessment. After the assessment results of all agents are comprehensively calculated by a weighted fusion algorithm, an overall risk score and a suggested risk level are generated, realizing a unified assessment of multiple dimensions such as solution rationality, execution complexity, and business criticality, breaking the limitations of single-indicator assessment.

[0050] Furthermore, the method or system according to the embodiments of this application employs a message bus-driven automated triggering mechanism and continuous data storage, meeting the needs of dynamic evaluation and multi-scenario adaptation. After being encapsulated, the changed data object is published to a designated topic on the message bus. The task distribution controller listens to this topic, thereby receiving messages in real time and automatically triggering agent evaluation. This eliminates the need for manual intervention, facilitating efficient adaptation to high-frequency change scenarios. Simultaneously, storing complete data from each change risk assessment process, including analysis reports from each agent, cited evidence (files, scripts, knowledge base entries, historical cases), evaluation node information, etc., not only provides sufficient historical data for subsequent continuous evaluation but also adapts to the continuous tracking and evaluation needs of changes over multiple days and in multiple windows, enabling iterative optimization of the evaluation model.

[0051] Furthermore, according to the method or system of this application embodiment, an automated decision-making closed loop is constructed by generating a structured report including information such as risk causal chains and a conflict resolution mechanism. After each agent completes the analysis, it outputs a JSON-formatted structured report containing risk discovery points, quantitative scores, confidence levels, and supporting evidence links, avoiding the ambiguity of information in singular assessments; using a large language model, the analysis results of each agent are linked with the evidence to generate an interpretable causal chain described in natural language (e.g., the risk rating of this change is high, the main reasons include high-risk DROPTABLE instructions in the execution script, cross-system dependencies affecting core order services, and fault records caused by similar historical changes), clearly presenting the logic of risk generation; when the assessment results of different agents conflict, the conflict points can be automatically marked and the conflict resolution mechanism can be triggered, and a human-machine collaboration process can be selectively initiated to push conflict details and wait for domain experts to intervene in the decision-making, reducing the subjectivity of manual review; the final comprehensive assessment report is pushed back to the change management platform through an interface callback mechanism, embedded in the approval interface of the change request, and directly provides decision-making references for stakeholders such as approvers and implementers, improving the consistency and processing efficiency of change decisions.

[0052] The technical features in the various embodiments of this application can be combined with each other to form new implementation methods without departing from the spirit of this application and without conflicting with each other. Although specific embodiments of this application have been shown and described in detail to illustrate the principles of this application, it should be understood that this application can be implemented in other ways without departing from such principles.

Claims

1. A method for intelligent change risk assessment based on multi-agent systems, characterized in that, The method includes: Receive change requests and create change data objects; The changed data object is encapsulated as a message and the message is published to a topic on the message bus, which is subscribed to by the task dispatch controller; Based on the change assessment task involved in the message, it is distributed to multiple different agents; Each agent that receives the change assessment task performs a specific analysis on the changed data object involved in the message and generates a preliminary analysis report. The specific analysis is an analysis of a specific aspect of the changed data object. Each of the agents publishes its generated preliminary analysis report to the aggregated topic of the message bus; The analysis reports from different agents on the aggregated topic are fused to generate the final evaluation result; wherein, when there is a conflict in the analysis reports from different agents, the conflict point is marked and the conflict resolution mechanism is triggered. Each of these agents is equipped with a large language model.

2. The method according to claim 1, characterized in that, Receive change requests and create change data objects, including: Receive change requests; Based on the identifier of the change request, connect to different data sources via adapters; Collect the data required for the change from the aforementioned data source; The collected data is processed to form the changed data object.

3. The method according to claim 1, characterized in that, Each agent receiving the change assessment task performs specific analysis on the changed data object involved in the message and generates a preliminary analysis report, including: Each agent that receives the change assessment task performs a specific analysis on the change data object using its large language model. During the analysis, the agent calls a data verification module to enable the agent to perform vectorized matching and retrieval with a dedicated knowledge base, thereby obtaining accurate knowledge to ensure the consistency between the analysis results and the facts. The data verification module employs retrieval enhancement generation technology.

4. The method according to claim 1, characterized in that, After completing the analysis, each of the intelligent agents generates a structured preliminary assessment report that includes risk discovery points, quantitative scores, confidence levels, and supporting evidence chains. The preliminary assessment report is, for example, in JSON format.

5. The method according to claim 1, characterized in that, The conflict resolution mechanism includes outputting the conflict details so that the user can resolve them.

6. The method according to claim 1, characterized in that, The various intelligent agents include a solution analysis agent, a script analysis agent, a correlation analysis agent, and a historical case analysis agent.

7. A multi-agent-based intelligent change risk assessment system, characterized in that, The system includes: The data acquisition module is configured to form a change data object based on the received change request, encapsulate the change data object into a message, and publish the message to the topic of the message bus. A task distribution controller is configured to subscribe to the topic and evaluate tasks based on changes involved in the message, and distribute them to multiple different agents; The data analysis module includes the plurality of different agents; each agent receiving the change assessment task performs a specific analysis on the changed data object involved in the message and generates a preliminary analysis report, wherein the specific analysis is an analysis of a specific aspect of the changed data object; the data analysis module is also configured to publish the preliminary analysis report generated by each agent to an aggregation topic of the message bus; An aggregation module is configured to fuse analysis reports from different agents on the aggregation topic to generate a final evaluation result; wherein, the aggregation module is configured to mark the conflict points and trigger a conflict resolution mechanism when there are conflicts in the analysis reports from different agents. Each of these agents is equipped with a large language model.

8. The system according to claim 7, characterized in that, The data acquisition module is configured to generate modified data objects through the following process: Receive change requests; Based on the identifier of the change request, connect to different data sources via adapters; Collect the data required for the change from the aforementioned data source; The collected data is processed to form the changed data object.

9. The system according to claim 7, characterized in that, The system also includes: The data verification module is configured to receive query requests from different agents, search for text matching the query request from a dedicated knowledge base based on retrieval enhancement generation technology, combine them into a coherent context, and return the query request to the agent that issued the query request. The query request includes a question described in natural language and related context.

10. The system according to claim 9, characterized in that, Each agent receiving the change assessment task is configured to generate a preliminary analysis report through the following process: Each agent that receives the change assessment task performs a specific analysis on the change data object using its included large language model. During the analysis, the agent can send the query request to the data verification module.

11. The system according to claim 7, characterized in that, The system also includes: The persistence module is configured to store data from each change risk assessment process and generate natural language causal chain summaries.

12. The system according to claim 7, characterized in that, The conflict resolution mechanism includes: outputting the conflict details so that the user can resolve them.

13. The system according to claim 7, characterized in that, The various intelligent agents include a solution analysis agent, a script analysis agent, a correlation analysis agent, and a historical case analysis agent.

14. The system according to claim 7, characterized in that, Each of the aforementioned agents is configured to generate a structured preliminary assessment report, for example in JSON format, after completing the analysis, including risk discovery points, quantitative scores, confidence levels, and supporting evidence chains.

15. An electronic device, characterized in that, The electronic device includes: Memory, used to store instructions; A processor configured to implement the method according to any one of claims 1 to 6 when executing the instructions.

16. A program product, characterized in that, The program product includes instructions that, when executed, enable the implementation of the method according to any one of claims 1 to 6.

17. A non-volatile storage medium, characterized in that, Instructions are stored on the non-volatile storage medium, and when executed, the instructions are capable of implementing the method according to any one of claims 1 to 6.

Images