Autonomous inspection method of intelligent agent, electronic device and storage medium

Abstract

The application relates to the technical field of intelligent inspection, and discloses an agent autonomous inspection method, an electronic device and a storage medium. The method comprises the following steps: in response to a received inspection request, calling a large language model agent to perform intention analysis on the inspection request and obtaining a corresponding inspection intention; based on the inspection intention, activating a plurality of target tools from a plurality of preset tool domains; capturing calling exception information and calling result information generated in calling execution of the target tools, and injecting the calling exception information and the calling result information into the large language model agent; and obtaining an inspection report generated by the large language model agent. According to the application, the matched target tools can be dynamically activated according to the inspection intention, and the inspection efficiency and the result reliability are improved.

Description

Technical Field

[0001] This application relates to the field of intelligent inspection technology, and in particular to an intelligent agent autonomous inspection method, electronic device and storage medium. Background Technology

[0002] In modern operations and maintenance (O&M) environments where cloud-native architectures are widely used, intelligent agent-based autonomous inspection solutions, based on large language models, are gradually becoming a key technical means to improve system reliability. However, existing solutions have revealed core flaws in practical implementation, such as insufficient static binding of tools and inadequate domain isolation. Specifically, O&M toolsets are forcibly associated with fixed inspection scenarios, failing to adapt to dynamically changing inspection objectives. When inspection needs shift from service health checks to different scenarios like front-end performance analysis, the system lacks the ability to identify intents in real time and match the optimal tool combination, leading to redundant or missing tool calls, resulting in a significant decrease in inspection efficiency and compromised result reliability. A deeper problem lies in the lack of structured semantic grouping of O&M tools; for example, service health check tools and front-end performance analysis tools are deployed interchangeably without a clear definition of domain boundaries. This mixed state causes cognitive ambiguity when the large language model parses tool functions, making it difficult to accurately plan call sequences and ultimately resulting in chaotic tool orchestration paths. Such chaos not only increases the risk of abnormal calls but also causes logical contradictions in key aspects of the generated inspection report, such as health status assessment and abnormal indicator attribution, severely weakening the diagnostic value and O&M guidance significance of the report. Summary of the Invention

[0003] The purpose of this application is to provide an intelligent agent autonomous inspection method, electronic device and storage medium, which can dynamically activate the matching target tool according to the inspection intention, thereby improving inspection efficiency and result reliability.

[0004] This application provides an intelligent agent autonomous inspection method, including: In response to the received inspection request, the large language model agent is invoked to perform intent parsing on the inspection request and obtain the corresponding inspection intent. Based on the inspection intent, several target tools are activated from a set of preset tool domains; the target tools are tools within the tool domains that match the inspection intent. Capture the call exception information and call result information generated by the target tool during call execution, and inject the call exception information and call result information into the large language model agent; Obtain the inspection report generated by the large language model agent; the inspection report is generated based on the call exception information and the call result information.

[0005] In some embodiments, activating several target tools from a preset set of tool domains based on the inspection intent includes: Based on the preset task dependencies, the target tool domain corresponding to the inspection intention is determined; Determine the tool-intent correlation between the tools in the target tool domain and the inspection intent; Based on the tool-intent correlation, several target tools are identified and activated.

[0006] In some embodiments, when the target tool includes a data query tool, the agent autonomous inspection method further includes: Obtain the target service identifier of the target service to be queried by the inspection intention; The target service identifier is matched with a preset service whitelist using fuzzy matching to verify the query permissions of the target service identifier; After successful verification, the pre-compiled parameterized query template is invoked, and the target service identifier is filled into the parameterized query template to generate the query instruction of the data query tool.

[0007] In some embodiments, the method for capturing the call exception information includes: Invoke the global exception catcher to encapsulate the tool call function of the target tool; Intercept exceptions thrown by the encapsulated tool's function call during execution; Based on the aforementioned exception information, the call exception information is generated; the call exception information includes an error field describing the exception type and a prompt field for prompting the large language model agent.

[0008] In some embodiments, the method for capturing the call result information includes: Obtain the original call result information returned by the target tool after the call is executed; Determine whether the original call result information meets the preset truncation trigger condition; If the condition is not met, the original call result information will be used as the call result information. If satisfied, the original call result information is truncated, and a truncation identifier field is added to the truncated information to obtain the call result information; the truncation process includes at least one of recursion depth limitation, array length truncation, and string truncation.

[0009] In some embodiments, before injecting the invocation result information into the large language model agent, the method further includes: Semantic metadata is appended to the call result information; the semantic metadata includes data source tool information, technical field information, and status tag information. Based on preset service dependencies, the cross-domain association relationships between the various cross-domain call result information are identified; the cross-domain call result information refers to call result information from different tool domains. Based on the semantic meta-information and the cross-domain association, the association information between the cross-domain call result information is aggregated, and semantic conflict information in the aggregated information is identified. Based on the aggregated information and the semantic conflict information, priority-ranked comprehensive diagnostic summary information is generated and injected into the large language model agent.

[0010] In some embodiments, before injecting the invocation result information into the large language model agent, the method further includes: Based on the call result information, a multidimensional health status evaluation is performed on the target inspection object to obtain the corresponding health score and corresponding health status label. The health score and the health status label are injected into the large language model agent.

[0011] In some embodiments, a method for generating the inspection report includes: Get the preset report structure template; The call exception information and the call result information are assembled into a prompt word project context; The prompt word engineering context and the report structure template are injected into the large language model agent to instruct the large language model agent to fill the prompt word engineering context according to the preset fields in the report structure template to generate the inspection report; the preset fields include the inspection object identifier field, the health status conclusion field, the key abnormal indicator list field, and the executable suggestion field.

[0012] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described intelligent agent autonomous inspection method.

[0013] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described intelligent agent autonomous inspection method.

[0014] The beneficial effects of this application are as follows: Upon receiving an inspection request, the large language model agent parses the corresponding inspection intent from the request. Based on this intent, several target tools are activated from multiple preset tool domains. During the execution of the target tools, relevant call exception and result information is captured and injected into the large language model agent. Finally, an inspection report generated by the large language model agent is obtained. Therefore, by parsing the inspection intent from the request using the large language model agent, the subsequent tool selection process can be based on semantic intent, rather than relying on a preset fixed process. Activating several target tools from multiple preset tool domains based on the parsed inspection intent avoids invalid searches or activation of mismatched tools in irrelevant tool domains, improving the accuracy and efficiency of tool selection. By capturing call exception information and call result information generated during the execution of the target tool, a large language model agent generates an inspection report based on the call exception information and call result information, realizing centralized processing of information. By utilizing the reasoning and language generation capabilities of the large language model agent, the raw information is transformed into a report with insight and guidance, improving the quality and interpretability of the inspection report. Attached Figure Description

[0015] Figure 1 This is a flowchart of the intelligent agent autonomous inspection method provided in the embodiments of this application.

[0016] Figure 2 This is a flowchart of a method for activating several target tools from a set of preset tool domains, as provided in an embodiment of this application.

[0017] Figure 3 This is a flowchart of a method for capturing call exception information provided in an embodiment of this application.

[0018] Figure 4 This is a flowchart of a method for capturing call result information provided in an embodiment of this application.

[0019] Figure 5 This is a flowchart of the method for generating inspection reports provided in the embodiments of this application.

[0020] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0022] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and drawings are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0023] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application. Furthermore, the information, data, and signals involved in the embodiments of this application are all authorized by relevant parties or have been fully authorized by all parties, and the collection, use, and processing of related data comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0024] In traditional intelligent agent autonomous inspection schemes based on large language models, toolsets are fixedly bound to specific scenarios, lacking dynamic adaptability. This makes it impossible to dynamically select or combine toolsets when the inspection target type changes. At the same time, the lack of clear semantic grouping and boundary definition of operation and maintenance tools makes it difficult for large language model intelligent agents to identify the functional scope of tools when planning and calling them, resulting in chaotic tool call orchestration paths. This, in turn, affects inspection efficiency and result accuracy. The reduction in inspection efficiency is manifested in the delay in generating tool call sequences, while the impairment of result accuracy is reflected in the decreased matching degree between inspection data and target scenarios. As a result, the quality and interpretability of reports are systematically constrained. For example, during the operation and maintenance of a cloud-native environment, when the inspection request switches from service health check to front-end performance analysis, the existing system cannot dynamically distinguish between the tool sets of the service health check tool domain and the front-end check tool domain, resulting in service health check tools and front-end performance tools being mixed in the same tool pool; the large language model agent incorrectly calls the middleware health check tool to perform front-end resource loading tests due to the ambiguity of the tool's semantic boundaries, generating an invalid call sequence, in which the call result information contains indicator data from non-target domains, causing the key abnormal indicator list fields in the inspection report to be disconnected from the actual front-end performance problems, and logical contradictions to appear in the health status conclusion fields.

[0025] If the above problems are not resolved, the inspection process will continue to generate redundant calls due to tool selection mismatch, and the semantic consistency of the call result information cannot be guaranteed. Ultimately, this will reduce the reliability of the operation and maintenance decision-making basis and pose a potential risk to the overall stability of the system. In particular, the chaotic state of tool call orchestration will exacerbate the uncertainty of the output of the large language model agent, causing the executable suggestion field of the inspection report to deviate from the actual operation and maintenance needs, thereby affecting the continuous operation and maintenance capabilities of the cloud-native environment.

[0026] Based on this, embodiments of this application provide an intelligent agent autonomous inspection method, electronic device, and storage medium. The method uses a large language model intelligent agent to parse the inspection intent in the inspection request, dynamically activates the matching tool, captures the call exception information and call result information generated by the target tool during the call execution, and then generates an inspection report. It can dynamically activate the matching target tool according to the inspection intent, avoids tool call redundancy or missing, and improves inspection efficiency and result reliability.

[0027] Figure 1 This is a flowchart of the intelligent agent autonomous inspection method provided in the embodiments of this application. (See attached document.) Figure 1 In one embodiment, the method includes, but is not limited to, steps S101 to S104.

[0028] Step S101: In response to the received inspection request, the large language model agent is invoked to perform intent parsing on the inspection request and obtain the corresponding inspection intent.

[0029] A large language model agent refers to an intelligent entity built upon a large language model, capable of understanding natural language, reasoning, planning actions, and interacting with external tools. In this method, the large language model agent is used to parse inspection intentions, select tools, process results, and generate reports.

[0030] Inspection intent refers to the explicit and structured inspection purpose obtained after intent parsing. This intent guides subsequent tool selection and execution processes. For example, an inspection intent might indicate the need to check the CPU utilization of a certain service.

[0031] Upon receiving an inspection request, the large language model agent is invoked to parse the request's intent and obtain the corresponding inspection intent. For example, when a text-based inspection request, such as "Check the running status of service A," is received, the request is passed to the pre-configured large language model agent. This agent can use keyword matching to identify "service A" as the inspection object and "running status" as the inspection focus from the request text, combining them to form a structured inspection intent. Alternatively, the large language model agent can use a rule engine-based approach, pre-setting a series of parsing rules. When the request text matches specific rules, the corresponding intent elements are extracted. For example, if the request contains "Check the [indicators] of [service name]", then [service name] and [indicators] will be extracted as the intent.

[0032] Step S102: Based on the inspection intent, activate several target tools from multiple preset tool domains.

[0033] A tool domain refers to a collection of inspection tools logically divided according to their function or technical field. Each tool domain contains a set of tools with similar functions or serving a specific technical field. For example, a service health check tool domain might contain tools for checking service operation status and resource utilization. In some embodiments, a tool domain may include a service health check tool domain, an active probing and SLA compliance analysis tool domain, a front-end check tool domain, an application check tool domain, and a middleware health check tool domain.

[0034] Target tools are tools within a tool domain that match the inspection intent. In other words, target tools are tools selected and activated from multiple tool domains based on the inspection intent to perform specific inspection tasks. These tools can be API interfaces, scripts, diagnostic programs, etc., and are designed to acquire specific types of data or perform specific operations.

[0035] Based on the inspection intent, several target tools can be activated from multiple preset tool domains. One approach is to maintain a simple intent-tool mapping table, directly searching for the corresponding target tool based on the inspection intent. For example, the intent "CPU utilization" directly maps to "get CPU metrics tool". Another implementation method is to manually add tags to tools within each tool domain, then match keywords in the inspection intent with the tool tags to activate tools with a high degree of matching. For example, if the intent includes "front-end performance", then tools in the front-end inspection tool domain tagged with "performance monitoring" will be activated.

[0036] Step S103: Capture the call exception information and call result information generated by the target tool during call execution, and inject the call exception information and call result information into the large language model agent.

[0037] Error messages refer to errors or exceptions that occur during the execution of the target tool, indicating that the tool has failed to complete its task correctly. This information typically includes the error type, error code, and error description, and is used to help diagnose the problem.

[0038] Call result information refers to the data returned by the target tool after successful execution, reflecting the status or performance of the inspected object. This information forms the basis for generating inspection reports; for example, a call result message might contain response time data for a particular service.

[0039] When a target tool is activated and executed, its execution process may generate two types of information. One is call exception information; for example, when the "Get CPU Metrics Tool" fails to connect to service A, a connection timeout exception will be generated. The other is call result information; for example, when the "Get CPU Metrics Tool" successfully obtains that service A's CPU utilization is 80%, this data is the call result information. This information can be collected through standard output or log files. One method of capture is for a separate monitoring module to periodically scan the tool's execution logs after the tool call is completed, extracting exception and result information. Another method is that each tool is designed to write exception and result information to a pre-defined shared storage area after execution, for subsequent modules to read.

[0040] Step S104: Obtain the inspection report generated by the large language model agent.

[0041] The inspection report is generated based on call anomaly information and call result information. In essence, an inspection report is a document generated by the large language model agent based on captured call anomaly and call result information, summarizing and analyzing the inspection process and results. This report typically includes inspection conclusions, identified problems, health status assessments, and possible recommendations.

[0042] This inspection report is generated based on the call exception information and the call result information. For example, when the large language model agent receives information such as "connection timeout exception" and "CPU utilization 80%", it will use its language generation capabilities to organize these raw data and exception events into a highly readable report. One generation method is that the large language model agent is preset with a simple report template containing fixed fields such as "exception summary" and "result summary". The agent directly fills the received information into the corresponding fields. Another generation method is that the large language model agent is trained to identify different types of information, sort and summarize them according to their importance, and then generate the report content in free text form. For example, if an exception exists, the exception information will be mentioned first and a brief analysis will be given.

[0043] The following example will provide a more detailed explanation of the above technical solution: Suppose in a cloud-native environment, user A wants to perform a comprehensive health check on a microservice named "OrderService". User A submits a check request through an operations and maintenance platform, with the content "Please perform a health check on OrderService".

[0044] First, the inspection request is received. Then, a large language model agent is invoked. Upon receiving the request "Please perform a health check on OrderService," the large language model agent parses its intent. Specifically, by analyzing the keywords "OrderService" and "health check" in the request, the agent identifies the inspection object as "OrderService" and the inspection intent as "service health check." Thus, a structured inspection intent is generated, for example, represented as {object: "OrderService", intent type: "service health check"}.

[0045] Next, based on the inspection intent, several target tools are activated from a set of preset tool domains. Since the inspection intent is "service health check," tools matching this intent are prioritized for search and activation in the "service health check tool domain." For example, this tool domain might contain "service liveness detection tool," "CPU utilization query tool," and "memory usage query tool." These tools are identified as target tools and activated, ready for execution. For example, a one-to-one match is performed between the "service health check" intent and all tools in the "service health check tool domain," and all matching tools are activated.

[0046] Subsequently, the call exception information and call result information generated by these target tools during the execution process are captured. For example, the "Service Liveness Detection Tool" is called to check the running status of "OrderService". If "OrderService" is currently down, the tool may throw a "Service Unreachable" exception during execution, and this exception information is captured as call exception information. At the same time, the "CPU Utilization Query Tool" and the "Memory Utilization Query Tool" are successfully called, returning data showing that the CPU utilization of "OrderService" is 15% and the memory utilization is 30%, respectively. This data is captured as call result information. These captured call exception information and call result information are then injected into the aforementioned large language model agent.

[0047] Finally, the large language model agent generates a detailed inspection report based on the injected call exception information and call result information. In this example, the agent receives the "service unreachable" exception information as well as normal CPU and memory usage data. The agent integrates this information, identifies a serious service availability problem with "OrderService," and combines it with other normal indicators to generate an inspection report. This report may contain a health status conclusion that "OrderService is currently unavailable," list the key exception indicators of "service unreachable," and may provide actionable suggestions such as "Please check the running status of OrderService and restart it." This inspection report is ultimately obtained and presented to user A. Through the above process, this method achieves autonomous and intelligent inspection of "OrderService" and provides clear diagnostic results.

[0048] Based on the above examples, the intelligent agent autonomous inspection method proposed in this embodiment demonstrates significant technical contributions.

[0049] In existing technologies, when user A submits a request to "perform a health check on OrderService", traditional inspection systems may require pre-configuration of a fixed toolset or manual intervention to select appropriate tools. This static binding and manual intervention approach often results in poor flexibility when inspection targets or types change, failing to dynamically adapt to new inspection needs and thus affecting inspection efficiency. In contrast, this embodiment responds to inspection requests and invokes a large language model agent for intent parsing, transforming unstructured requests into explicit inspection intents. For example, "perform a health check on OrderService" is parsed as {object: "OrderService", intent type: "service health check"}, allowing the tool selection process to be based on semantic intents rather than relying on a preset fixed process.

[0050] Furthermore, existing technologies often lack clear semantic grouping and boundary definitions in the organization of operation and maintenance tools, leading to a jumble of tools and making it difficult for large language models to understand when planning and calling tools, easily causing orchestration chaos. This embodiment, however, activates several target tools from multiple preset tool domains based on the parsed inspection intent. These tool domains, such as the service health check tool domain and the front-end check tool domain, achieve domain isolation and semantic grouping of tools. In the example above, when the intent is parsed as "service health check," it can accurately activate tools such as "service liveness detection tool" and "CPU utilization query tool" in the "service health check tool domain," avoiding invalid searches or activation of mismatched tools in irrelevant tool domains. This dynamic selection mechanism based on tool domains significantly improves the accuracy and efficiency of tool selection, solving the problems of insufficient static tool binding and domain isolation.

[0051] Furthermore, in existing solutions, post-execution information processing is often fragmented. Anomaly and result information may be scattered across different log or monitoring systems, making unified collection and utilization difficult, thus affecting the quality and interpretability of the final report. This embodiment achieves centralized information processing by capturing call anomaly and result information generated during the execution of the target tool and injecting them uniformly into a large language model agent.

[0052] Ultimately, existing technologies may only generate inspection reports that are essentially a compilation of raw data, lacking in-depth analysis and actionable recommendations. In this embodiment, however, a large language model agent generates inspection reports based on injected call exception and result information. In the example, the agent not only reports the fact that "OrderService is currently unavailable," but also incorporates other metrics and provides an actionable recommendation: "Please check the running status of OrderService and restart it." This report generation method leverages the reasoning and language generation capabilities of the large language model agent to transform raw data into insightful and guiding reports, improving the quality and interpretability of inspection reports and effectively addressing the problems of low report quality and poor interpretability.

[0053] In summary, this embodiment constructs a highly flexible, efficient, and intelligent autonomous inspection method by introducing a large language model intelligent agent for intent parsing, dynamically activating target tools based on tool domains, uniformly capturing and injecting tool execution information, and intelligently generating inspection reports. This effectively overcomes the technical problems of static tool binding, insufficient domain isolation, poor flexibility, and chaotic orchestration in existing technologies.

[0054] See Figure 2 In one embodiment, the method for activating several target tools from a plurality of preset tool domains includes, but is not limited to, steps S201 to S203.

[0055] Step S201: Based on the preset task dependency relationship, determine the target tool domain corresponding to the inspection intention.

[0056] Step S202: Determine the tool-intent correlation between tools in the target tool domain and inspection intents.

[0057] Step S203: Based on the tool-intent correlation, identify and activate several target tools.

[0058] Task dependencies refer to a pre-established knowledge base that indicates the correspondence between a specific inspection intent and one or more related tool domains. It can be represented as a structured data table, configuration file, or rule-based knowledge graph. For example, when the inspection intent involves "database performance," this task dependency can point it to the service health check tool domain and the middleware health check tool domain. This task dependency aims to initially narrow down the range of tool selections and improve the efficiency of subsequent tool matching. Determining the target tool domain corresponding to the inspection intent involves using the task dependency to identify the set of tool domains most likely to contain the required tools, based on the inspection intent parsed from the current inspection request. For example, a pre-defined mapping table can be queried, using the inspection intent as the key to obtain a list of corresponding tool domains. Alternatively, a semantic matching algorithm can be used to analyze the text content of the inspection intent and compare it with the descriptions of each tool domain to determine the target tool domain with the highest relevance.

[0059] Tool-intent relevance is an indicator that measures the degree of relevance between a specific tool and the current inspection intent. It can be a quantitative value, such as calculating the semantic similarity between the tool description and the intent text, or a score based on keyword matching. Alternatively, it can be a qualitative assessment, such as the degree of matching between tool tags and intent tags pre-set based on expert experience. This relevance provides an objective basis for evaluating the applicability of a tool. Identifying and activating several target tools aims to select the tools that best match the inspection intent from the identified target tool domain based on the calculated tool-intent relevance and make them executable. For example, a relevance threshold can be set, activating only tools with a relevance higher than that threshold; or, tools can be ranked according to relevance, and the top N tools can be activated. Activation operations may include loading the tool's execution module, initializing the tool's runtime environment, configuring the tool's input parameters, etc., preparing for subsequent tool invocation and execution.

[0060] This application's solution effectively addresses the challenge of efficiently and accurately activating the most relevant tools from a multitude of options in complex inspection scenarios by introducing a hierarchical and refined tool selection mechanism. Specifically, upon receiving an inspection request and parsing the inspection intent, a pre-defined task dependency relationship is first used to associate the abstract inspection intent with specific tool domains, quickly narrowing down the range of potentially relevant tools. This initial screening process avoids blind searching across all tool domains, significantly improving efficiency. Based on this, within the identified target tool domains, the tool-intent correlation between each tool and the inspection intent is quantitatively evaluated. Finally, based on these correlations, several target tools that best match the inspection intent are intelligently identified and activated. Through this two-stage screening and evaluation mechanism, this application ensures that the activated tools not only come from the correct domain but are also the tools within that domain with the highest matching degree to the current inspection intent. This makes the subsequently captured call anomaly and call result information more targeted and effective, thereby improving the accuracy and practicality of the inspection report generated by the large language model agent.

[0061] The following is a concrete example to illustrate this. Upon receiving an inspection request, the large language model agent parses the request and obtains the inspection intent as "check the response time of the web server." First, based on the preset task dependency relationship, the intent "check the response time of the web server" is queried. This task dependency relationship may be preset to map this intent to the front-end inspection tool domain and the proactive probing and SLA compliance analysis tool domain. Therefore, these two tool domains are identified as the target tool domains. Next, all tools in these two target tool domains are traversed, and the tool-intent correlation degree between each tool and the inspection intent "check the response time of the web server" is calculated. For example, in the front-end inspection tool domain, there may be a tool called "HTTP Response Time Detection Tool," whose description highly matches the inspection intent, so its correlation degree may be calculated as 0.95. Another tool called "Page Element Loading Analysis Tool," although also belonging to front-end inspection, has a lower direct correlation degree with the response time intent, and may be calculated as 0.6. In the proactive probing and SLA compliance analysis tool domain, there may be an "SLA Performance Metric Collection Tool," whose correlation degree may be 0.88. Finally, a correlation threshold can be set, such as 0.8. Based on this threshold, the "HTTP Response Time Detection Tool" and the "SLA Performance Metric Collection Tool" will be activated, as their correlation scores are both higher than 0.8. The "Page Element Loading Analysis Tool," however, will not be activated.

[0062] In some embodiments, when the target tool includes a data query tool, the intelligent agent autonomous inspection method further includes: obtaining the target service identifier of the target service to be queried by the inspection intention; performing fuzzy matching between the target service identifier and a preset service whitelist to verify the query permission of the target service identifier; after successful verification, calling a pre-compiled parameterized query template and filling the parameterized query template with the target service identifier as a parameter to generate the query instruction of the data query tool.

[0063] Data query tools are software modules or services used to retrieve and extract information from various data sources (such as databases, API interfaces, log files, monitoring systems, etc.). Their function is to obtain the required data based on specific query conditions to support the realization of inspection intentions. For example, a data query tool can be an SQL client used to connect to a relational database and execute SQL queries; or it can be an HTTP client used to call a RESTful API to obtain data in JSON or XML format.

[0064] This application's solution ensures the security and accuracy of the query process through a series of collaborative steps. First, the target service identifier to be queried is precisely obtained from the parsed inspection intent. To prevent unauthorized access or malicious queries, this target service identifier is not directly used to construct the query; instead, it is compared against a pre-defined service whitelist. This comparison process employs fuzzy matching technology, which can identify the legitimacy of the target service identifier even if there are subtle differences between it and entries in the whitelist, thereby improving the system's robustness and user experience. Once the target service identifier passes query permission verification, a pre-compiled parameterized query template is invoked. Subsequently, the verified target service identifier is securely filled into these parameter placeholders, rather than being directly concatenated into the query string. Finally, a structured and secure query instruction is generated and delivered to the data query tool for execution. In this way, the proposed solution effectively isolates user input from query logic, fundamentally eliminating security risks such as SQL injection, while ensuring that only legitimate services in the whitelist can be queried. This greatly improves the data query security and system stability of the autonomous inspection process, enabling the large language model agent to generate subsequent inspection reports based on reliable data.

[0065] The following example illustrates this. Suppose a user initiates an inspection request, requesting to "check the running status of the core database service." Upon receiving this request, the large language model agent parses it as an inspection intent and identifies "core database service" as the target service identifier. At this point, a data query tool, such as a database connector module, is activated. Before generating the actual query command, the target service identifier "core database service" is compared with a preset service whitelist. This whitelist may be stored in a JSON configuration file, containing legitimate service names such as `["core database", "order service", "user authentication service"]`. A fuzzy matching algorithm, such as the Jaccard similarity algorithm, is used to calculate the similarity between "core database service" and each item in the whitelist. If the similarity reaches a preset threshold (e.g., 0.8), the query permission verification is considered successful. Subsequently, a pre-compiled SQL query template suitable for querying service status is selected from a preset template library, such as `SELECT status, last_heartbeat FROM service_monitor WHERE service_name = ?`. Next, "Core Database Service" is safely populated as a parameter into the `?` placeholder in the template. Finally, a complete, parameterized SQL query is generated, such as `SELECT status,last_heartbeat FROM service_monitor WHERE service_name = 'Core Database Service'`, which is executed by the database connector module to retrieve the corresponding service status data.

[0066] See Figure 3 In one embodiment, the method for capturing call exception information includes, but is not limited to, steps S301 to S303.

[0067] Step S301: Invoke the global exception catcher to encapsulate the tool call function of the target tool.

[0068] Step S302: Intercept the exception information thrown by the encapsulated tool calling function during the execution of the call.

[0069] Step S303: Based on the exception information, generate call exception information; the call exception information includes an error field describing the exception type and a prompt field for prompting the large language model agent.

[0070] A global exception catcher is a system-level mechanism or component that centrally handles exceptions in an application that are not caught by a specific code block. By invoking this catcher, the tool's call function can be encapsulated, meaning the original tool call logic is wrapped within a unified exception handling framework. This encapsulation ensures that regardless of how exceptions are thrown internally by the tool, they can be detected and handled by a unified external mechanism. This can be implemented using decorator patterns or proxy patterns provided by the programming language, or by dynamically weaving exception handling logic at runtime using an AOP (Aspect-Oriented Programming) framework. Another approach is to register callback functions or event listeners before the tool is invoked, so that a pre-defined exception handling process is automatically triggered when an exception occurs during tool execution.

[0071] This application's solution introduces a global exception capture mechanism to uniformly encapsulate the tool call functions of the target tool. When the encapsulated tool call function throws any exception during execution, the global exception catcher can immediately intercept these raw exception messages, which may vary in format. Subsequently, based on these raw exception messages, standardization and structuring processing are performed to generate call exception information containing error fields and prompt fields. The error field precisely identifies the exception type, while the prompt field provides the exception's context and potential handling suggestions in a way that is easier for the large language model agent to understand. This mechanism ensures that regardless of how the underlying tool implements its exception throwing logic, the upper-level large language model agent receives unified, clear, and semantically rich exception data. In this way, the large language model agent can more accurately understand the problems encountered during tool execution, thus providing more accurate exception diagnosis and actionable suggestions when generating inspection reports, significantly improving the intelligence level and report quality of the agent's autonomous inspection.

[0072] The following example illustrates this. When an agent needs to invoke a target tool (e.g., an API client for querying service status), the tool's invocation function is encapsulated by a global exception handling module. For example, in a Python programming environment, a decorator function can be defined and applied to all target tool invocation functions. When the decorated tool invocation function (such as `query_service_status()`) is executed, if an exception such as `ConnectionError` or `TimeoutError` occurs internally, the decorator will immediately catch these exceptions. After catching the raw `ConnectionError` object, its attributes are parsed to extract the error type (e.g., `ConnectionError`) and error message (e.g., "Max retries exceeded with url: ..."). Then, according to preset rules, this raw information is converted into structured invocation exception information. For example, the error field could be set to "Network connection failed," while the message field could be generated as "The target service may have a network failure or be unreachable; please check your network configuration or service status." Ultimately, this call exception information, which includes the error field "Network connection failed" and the prompt field "The target service may have a network failure or be unreachable. Please check the network configuration or service status," will be injected into the large language model agent for subsequent analysis and report generation.

[0073] See Figure 4 In one embodiment, the method for capturing call result information includes, but is not limited to, steps S401 to S404.

[0074] Step S401: Obtain the original call result information returned by the target tool after the call is executed.

[0075] Step S402: Determine whether the original call result information meets the preset truncation triggering conditions.

[0076] If not satisfied, proceed to step S403; if satisfied, proceed to step S404.

[0077] Step S403: Use the original call result information as the call result information.

[0078] Step S404: Truncate the original call result information and add a truncation identifier field to the truncated information to obtain the call result information.

[0079] Pruning processes include at least one of recursion depth limiting, array length pruning, and string truncation.

[0080] The proposed solution, through the steps described above, first obtains the raw call result information generated after the target tool is executed. Then, it intelligently evaluates this raw information to determine if it meets preset truncation trigger conditions. This judgment process acts as an intelligent filter, ensuring that only data that might reduce the processing efficiency of the large language model agent or overburden the analysis burden is further processed. If the raw data volume is moderate and meets the requirements, it is directly used as the call result information, thus preserving the integrity of the data to the maximum extent. Conversely, if the raw data volume is too large or the structure is too complex, it is simplified according to preset strategies (such as recursion depth limits, array length pruning, or string truncation). During the simplification process, a truncation identifier field is added to the processed information. This identifier field is crucial; it clearly indicates to the large language model agent that the received data has been optimized and is not the original complete data. In this way, the large language model agent can receive refined, focused call result information with a clear processing status, thereby avoiding inefficiency and analysis bias caused by processing redundant data, enabling it to generate inspection reports more efficiently and accurately. This, combined with basic inspection methods, significantly improves the operational efficiency and reporting quality of the entire intelligent agent autonomous inspection system.

[0081] The following example illustrates this. Suppose that during a "service health check" request for a microservice, the target tool returns a raw JSON-formatted call result containing service configuration, dependency graph, and the most recent 1000 access log entries. The JSON object has a nesting depth of 7 levels, and the access log array has a length of 1000. The preset truncation trigger condition is: JSON depth exceeding 5 levels or array length exceeding 200. First, the complete raw JSON-formatted call result is obtained. Next, the raw call result is evaluated. Since its JSON depth is 7 levels (exceeding 5 levels) and the access log array length is 1000 (exceeding 200), the preset truncation trigger condition is met. Subsequently, the raw call result is truncated. Specifically, a recursion depth limit can be applied to restrict the nesting depth of the JSON object to within 5 levels. For parts exceeding 5 levels, placeholders such as `"..."` or `"truncated_object"` are used. Simultaneously, the access log array is pruned, for example, keeping only the most recent 200 log records. After these pruning steps are completed, a truncation flag field, such as `"__truncated__": true`, is added to the root of the processed JSON object. Finally, this condensed call result with the truncation flag field is injected into the large language model agent.

[0082] In some embodiments, before injecting the call result information into the large language model agent, the method further includes: attaching semantic meta-information to the call result information; the semantic meta-information includes data source tool information, technical field information, and status label information; identifying cross-domain association relationships between different domain call result information based on preset service dependencies; the different domain call result information is call result information from different tool domains; aggregating the association information between different domain call result information according to the semantic meta-information and cross-domain association relationships, and identifying semantic conflict information in the aggregated information; generating priority-ranked comprehensive diagnostic summary information based on the aggregated information and semantic conflict information, and injecting it into the large language model agent.

[0083] In this application's autonomous inspection method for intelligent agents, to enhance the ability of large language model agents to handle complex and heterogeneous inspection results, an intelligent preprocessing stage is introduced before injecting the call result information generated by the target tool into the large language model agent. First, the raw call result information captured from different tool domains is enhanced by adding semantic meta-information such as data source tool information, technical field information, and status label information. This meta-information provides rich context for subsequent data analysis, making each call result no longer an isolated data point, but structured information with a clear source, domain, and status. Based on this, using pre-defined service dependencies, this heterogeneous call result information with added semantic meta-information is analyzed in depth to identify potential cross-domain relationships. For example, if the front-end tool domain reports a slow user interface response, while the application inspection tool domain reports a back-end service error, if a service dependency exists between the front-end and back-end, the causal or correlation between the two can be identified. This identification of relationships allows for the construction of a global view from local problems, understanding the mutual influence between different components. Subsequently, based on this semantic meta-information and the identified cross-domain relationships, all relevant cross-domain call results are aggregated. During aggregation, not only are relevant information integrated, but potential semantic conflicts within the aggregated information are also proactively identified. For example, one tool might report a normal service, while another tool that depends on that service reports an anomaly. This approach uncovers inconsistencies or potential contradictions in the data, providing a more accurate basis for subsequent diagnosis. Finally, based on this aggregated and conflict-identified information, a prioritized comprehensive diagnostic summary is generated. This summary is a highly refined and concise summary of complex inspection results; it not only contains key diagnostic conclusions but also prioritizes them according to the severity of the problems. This structured and focused summary is then injected into the large language model agent. Through this preprocessing mechanism, the large language model agent no longer receives raw, fragmented data, but rather intelligently analyzed and refined diagnostic clues with clear context and priority. This greatly reduces the difficulty of understanding and reasoning for large language model agents, enabling them to generate high-quality inspection reports more efficiently and accurately, thus effectively solving the problem that the original call result information is complex and diverse, and difficult to be directly and effectively utilized by large language model agents.

[0084] The following example illustrates this. Suppose an intelligent agent autonomous inspection system receives an inspection request for an e-commerce website. The system activates a page load performance tool from the service health check tool domain, an API response time tool from the application check tool domain, and a database connection status tool from the middleware health check tool domain. After capturing the call results from these tools, semantic metadata is appended to each result. For example, the "page load time too long" result returned by the page load performance tool is appended with "Data source tool information: WebPageLoadTool", "Technical field information: Front-end", and "Status label information: Warning". The "partial API response timeout" result returned by the API response time tool is appended with "Data source tool information: APIMonitorTool", "Technical field information: Back-end application", and "Status label information: Abnormal". The "database connection failed" result returned by the database connection status tool is appended with "Data source tool information: DBConnectionTool", "Technical field information: Database", and "Status label information: Critical". Next, based on preset service dependencies (e.g., front-end services depend on back-end APIs, and back-end APIs depend on databases), cross-domain relationships between these cross-domain call results are identified. In this example, it is identified that a database connection failure may cause API response timeouts, thus affecting front-end page loading performance. Then, this information is aggregated based on semantic metadata and cross-domain relationships. The aggregation result may show: front-end performance warnings, back-end API anomalies, and severe database anomalies, with a clear dependency chain among the three. During the aggregation process, semantic conflicts are identified; for example, if the database tool reports normal operation but the API tool reports anomalies, there may be other issues or data inconsistencies. Finally, based on the aggregated information and identified semantic conflicts (if any), a prioritized comprehensive diagnostic summary is generated. For example, the summary might read: "Database connection failure (severe) caused back-end API response timeouts (anomalies), thus affecting front-end page loading performance (warnings). The root cause of the problem is the database connection failure." This summary is then injected into the large language model agent, guiding it to generate a detailed and targeted inspection report, which may include specific diagnostic and remedial suggestions for the database connection problem.

[0085] In some embodiments, before injecting the call result information into the large language model agent, the method further includes: performing a multi-dimensional health status evaluation on the target inspection object based on the call result information to obtain a corresponding health score and a corresponding health status label; and injecting the health score and health status label into the large language model agent.

[0086] Upon receiving the call result information generated by the execution of the target tool, the proposed solution does not simply inject the raw call result information directly into the large language model agent. Instead, it first performs a multi-dimensional health status evaluation of the target inspection object based on this call result information. This evaluation process comprehensively analyzes various indicators contained in the call result information (e.g., service response time, error rate, resource usage, etc.) to quantitatively and qualitatively analyze the target inspection object from multiple dimensions such as performance, availability, and stability. In this way, a quantitative health score and a descriptive health status label can be obtained, which highly summarize the current health status of the target inspection object. Subsequently, these refined health scores and health status labels are injected into the large language model agent. When generating inspection reports, the large language model agent can directly utilize these structured, high-level health assessment results without having to infer the health status from massive amounts of raw call result information. This enables the large language model agent to understand the overall health status of the target inspection object more efficiently and accurately, thereby generating more insightful and health-focused inspection reports. By preprocessing the complex health assessment logic, the solution proposed in this application effectively reduces the burden on large language model agents and improves the efficiency and quality of their report generation. Its advantages are even more significant in scenarios where it is necessary to quickly judge and report the health status of the system.

[0087] The following example illustrates this. When inspecting a web service, the call result information returned by the target tool (e.g., a service health check tool) after execution may include data such as HTTP response status codes, average response time, CPU utilization, and memory usage. Based on this call result information, a health assessment module can be launched. This module can preset a series of assessment rules, such as: if the HTTP 5xx error rate exceeds 1%, the availability dimension is rated as "critical"; if the average response time consistently exceeds 500 milliseconds, the performance dimension is rated as "warning"; if CPU utilization exceeds 80% for 5 consecutive minutes, the resource dimension is rated as "warning". Combining these multi-dimensional evaluation results, the module can calculate an overall health score, such as 75 points (out of 100), and generate a corresponding health status label, such as "Warning: Performance Degradation". Subsequently, the health score of 75 and the health status label "Warning: Performance Degradation" will be injected into the large language model agent as structured data, such as in JSON format, so that the large language model agent can directly reference these high-level health assessment conclusions when generating inspection reports, thereby quickly and accurately summarizing the overall health status of the web service.

[0088] See Figure 5In one embodiment, the method for generating an inspection report includes, but is not limited to, steps S501 to S503.

[0089] Step S501: Obtain the preset report structure template.

[0090] Step S502: Assemble the call exception information and call result information into a prompt word project context.

[0091] Step S503: Inject the prompt word engineering context and the report structure template into the large language model agent to instruct the large language model agent to fill in the prompt word engineering context according to the preset fields in the report structure template to generate an inspection report.

[0092] The preset fields include the inspection object identifier field, the health status conclusion field, the key abnormal indicator list field, and the actionable suggestion field.

[0093] This application's solution introduces a pre-defined report structure template and combines it with a prompt word engineering context, enabling the large language model agent to adhere to clear structural and content requirements when generating inspection reports. Specifically, after capturing the call exception information and call result information generated by the target tool, this raw data is first intelligently assembled into a prompt word engineering context. This context not only contains the raw exception and result data but may also have undergone preliminary processing and semanticization to make it easier for the large language model agent to understand. Subsequently, the prompt word engineering context, along with the pre-defined report structure template, is injected into the large language model agent. The report structure template acts as a "blueprint" here, explicitly defining the pre-defined fields that the final inspection report should include, such as the inspection object identifier field, health status conclusion field, key exception indicator list field, and executable suggestion field. Upon receiving these two parts of information, the large language model agent no longer generates text freely but is precisely instructed to extract relevant information from the prompt word engineering context and intelligently fill it into the various fields defined in the report structure template. This mechanism enables large language model agents to transform unstructured or semi-structured inspection data into highly structured, easily understood, and analyzable inspection reports. In this way, the large language model agent can not only understand the intent and results of the inspection but also organize this information into a report with clear conclusions and actionable recommendations according to pre-defined specifications. This overcomes the problems of disorganized report structure and unclear focus that can result from directly injecting raw information into the large language model agent.

[0094] The following is a concrete example to illustrate this. Suppose a patrol request for "Order Service" is received. After the large language model agent parses the intent, it activates the service health check tool in the service health check tool domain and the application check tool in the application check tool domain. After these tools execute, they capture the "Order Service" having an excessively long response time (call result information) and intermittent timeouts in the database connection pool (call exception information). To generate a structured patrol report, a preset JSON format report structure template is first obtained. This template defines fields such as "service_id", "health_status", "critical_issues", and "recommendations". Next, the captured response time data and database connection timeout information, along with other relevant context (such as inspection time, service version, etc.), are assembled into a prompt word engineering context, for example: "The order service was inspected at 10:00 on October 26, 2023, and the average response time was found to be 500ms, with a peak of 2000ms. The database connection pool experienced intermittent timeouts with error code DB-001, affecting service availability." Subsequently, this prompt word engineering context and the JSON report structured template are injected into the large language model agent. The large language model agent is instructed to extract and populate the corresponding content from the context information based on the preset fields in the template. For example, it will populate "order service" into the inspection object identifier field, judge and populate the health status conclusion field as "abnormal" based on the response time and timeout situation, populate "excessive response time" and "database connection pool timeout" into the key abnormal indicator list field, and generate content such as "check database connection pool configuration, optimize SQL query" to populate the executable suggestion field. Finally, the large language model agent outputs a well-structured and complete inspection report.

[0095] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0096] The following reference Figure 6 To describe an electronic device 600 according to such an embodiment of the present disclosure. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0097] like Figure 6 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0098] The storage unit stores program code, which can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the above section of the intelligent agent autonomous inspection method according to various exemplary embodiments of this disclosure.

[0099] Storage unit 620 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include a read-only memory (ROM) 6203.

[0100] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0101] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0102] Electronic device 600 can also communicate with one or more external devices 600' (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0103] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0104] The intelligent agent autonomous inspection method, electronic device, and storage medium provided in this application, upon receiving an inspection request, parse the corresponding inspection intent from the inspection request using a large language model intelligent agent. Based on the inspection intent, several target tools are activated from multiple preset tool domains. When a target tool is invoked and executed, corresponding call exception information and call result information are captured and injected into the large language model intelligent agent. Finally, an inspection report generated by the large language model intelligent agent is obtained. Thus, by parsing the corresponding inspection intent from the inspection request using a large language model intelligent agent, the subsequent tool selection process can be based on semantic intent, rather than relying on a preset fixed process. Activating several target tools from multiple preset tool domains based on the parsed inspection intent avoids invalid searches or activation of mismatched tools in irrelevant tool domains, improving the accuracy and efficiency of tool selection. By capturing call exception information and call result information generated during the execution of the target tool, a large language model agent generates an inspection report based on the call exception information and call result information, realizing centralized processing of information. By utilizing the reasoning and language generation capabilities of the large language model agent, the raw information is transformed into a report with insight and guidance, improving the quality and interpretability of the inspection report.

[0105] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this disclosure.

[0106] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0107] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0108] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0109] Exemplary embodiments of this disclosure have been specifically shown and described above. It should be understood that this disclosure is not limited to the detailed structures, arrangements, or implementations described herein; rather, this disclosure is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A method for autonomous inspection by an intelligent agent, characterized in that, include: In response to the received inspection request, the large language model agent is invoked to perform intent parsing on the inspection request and obtain the corresponding inspection intent. Based on the inspection intent, several target tools are activated from a set of preset tool domains; the target tools are tools within the tool domains that match the inspection intent. Capture the call exception information and call result information generated by the target tool during call execution, and inject the call exception information and call result information into the large language model agent; Obtain the inspection report generated by the large language model agent; The inspection report is generated based on the call exception information and the call result information.

2. The intelligent agent autonomous inspection method according to claim 1, characterized in that, Based on the inspection intent, activating several target tools from a preset set of tool domains includes: Based on the preset task dependencies, the target tool domain corresponding to the inspection intention is determined; Determine the tool-intent correlation between the tools in the target tool domain and the inspection intent; Based on the tool-intent correlation, several target tools are identified and activated.

3. The intelligent agent autonomous inspection method according to claim 1, characterized in that, When the target tool includes a data query tool, the intelligent agent autonomous inspection method further includes: Obtain the target service identifier of the target service to be queried by the inspection intention; The target service identifier is matched with a preset service whitelist using fuzzy matching to verify the query permissions of the target service identifier; After successful verification, the pre-compiled parameterized query template is invoked, and the target service identifier is filled into the parameterized query template to generate the query instruction of the data query tool.

4. The intelligent agent autonomous inspection method according to claim 1, characterized in that, The method for capturing the call exception information includes: Invoke the global exception catcher to encapsulate the tool call function of the target tool; Intercept exceptions thrown by the encapsulated tool's function call during execution; Based on the aforementioned exception information, the call exception information is generated; the call exception information includes an error field describing the exception type and a prompt field for prompting the large language model agent.

5. The intelligent agent autonomous inspection method according to claim 1, characterized in that, The method for capturing the call result information includes: Obtain the original call result information returned by the target tool after the call is executed; Determine whether the original call result information meets the preset truncation trigger condition; If the condition is not met, the original call result information will be used as the call result information. If satisfied, the original call result information is truncated, and a truncation identifier field is added to the truncated information to obtain the call result information; the truncation process includes at least one of recursion depth limitation, array length truncation, and string truncation.

6. The intelligent agent autonomous inspection method according to claim 1, characterized in that, Before injecting the call result information into the large language model agent, the process also includes: Semantic metadata is appended to the call result information; the semantic metadata includes data source tool information, technical field information, and status tag information. Based on preset service dependencies, the cross-domain association relationships between the various cross-domain call result information are identified; the cross-domain call result information refers to call result information from different tool domains. Based on the semantic meta-information and the cross-domain association, the association information between the cross-domain call result information is aggregated, and semantic conflict information in the aggregated information is identified. Based on the aggregated information and the semantic conflict information, priority-ranked comprehensive diagnostic summary information is generated and injected into the large language model agent.

7. The intelligent agent autonomous inspection method according to claim 1, characterized in that, Before injecting the call result information into the large language model agent, the process also includes: Based on the call result information, a multidimensional health status evaluation is performed on the target inspection object to obtain the corresponding health score and corresponding health status label. The health score and the health status label are injected into the large language model agent.

8. The intelligent agent autonomous inspection method according to claim 1, characterized in that, The method for generating the inspection report includes: Get the preset report structure template; The call exception information and the call result information are assembled into a prompt word project context; The prompt word engineering context and the report structure template are injected into the large language model agent to instruct the large language model agent to fill the prompt word engineering context according to the preset fields in the report structure template to generate the inspection report; the preset fields include the inspection object identifier field, the health status conclusion field, the key abnormal indicator list field, and the executable suggestion field.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the intelligent agent autonomous inspection method according to any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the intelligent agent autonomous inspection method as described in any one of claims 1 to 8.

Images