Fault diagnosis methods and devices, storage media and electronic equipment

Abstract

This application discloses a fault diagnosis method and apparatus, storage medium, and electronic device, relating to the field of artificial intelligence technology. The method is applied to a container platform and includes: obtaining context information of the container scheduling unit from a front-end page, and generating first request information based on the context information and natural language instructions input by the target object; querying associated information corresponding to the first request information from a database to obtain query results; executing an execution instruction determined based on the first request information and the query results to obtain execution results, wherein the execution results include container scheduling unit status information and fault log information; and inputting the first request information, the query results, and the execution results into a large language model to obtain fault diagnosis results output by the large language model. This solves the technical problem of low operational efficiency in container platforms and achieves the technical effect of improving the operational efficiency of container platforms.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a fault diagnosis method and apparatus, storage medium and electronic device. Background Technology

[0002] With the widespread adoption of cloud computing and the rise of microservice architecture, container orchestration platforms, with their powerful declarative APIs (Application Programming Interfaces) and scalable architecture, have become the cornerstone of modern application deployment and operation. However, behind this powerful capability lies a dramatic increase in system complexity. A typical cloud-native environment usually contains dozens of interrelated resource objects, hundreds of configuration parameters, and a vast toolchain consisting of multiple subsystems such as monitoring, logging, tracing, and security. When a system fails, the troubleshooting process often involves tedious analysis across multiple tools and data sources, heavily relying on the intuition and experience of senior experts, resulting in low efficiency and difficulty in scaling. Existing knowledge, whether official documentation or internal knowledge bases, is usually static and fragmented, failing to provide immediate and interactive guidance in the scenarios where operations personnel need it most.

[0003] This shows that container platform operation and maintenance efficiency is low in related technologies. Summary of the Invention

[0004] This application provides a fault diagnosis method and apparatus, storage medium and electronic device to at least solve the problem of system anomalies that easily occur when distributed storage systems are upgraded concurrently in the related art.

[0005] This application provides a fault diagnosis method applied to a container platform, which manages containers through a container scheduling unit. The method includes: obtaining context information of the container scheduling unit from a front-end page, and generating first request information based on the context information and natural language instructions input by a target object; querying associated information corresponding to the first request information from a database to obtain query results; executing an execution instruction determined based on the first request information and the query results to obtain execution results, wherein the execution results include container scheduling unit status information and fault log information; and inputting the first request information, the query results, and the execution results into a large language model to obtain fault diagnosis results output by the large language model.

[0006] This application also provides a fault diagnosis device, comprising: an acquisition module, configured to acquire context information of the container scheduling unit from a front-end page, and generate first request information based on the context information and natural language instructions input by a target object; a query module, configured to query associated information corresponding to the first request information from a database to obtain query results; an execution module, configured to execute an execution instruction determined based on the first request information and the query results to obtain execution results, wherein the execution results include the container scheduling unit status information and fault log information; and a obtaining module, configured to input the first request information, the query results, and the execution results into a large language model to obtain fault diagnosis results output by the large language model.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described fault diagnosis methods.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described fault diagnosis methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described fault diagnosis methods.

[0010] This application generates request information based on natural language input from the target object and contextual information of the container scheduling unit captured from the front-end page. It then queries the database for relevant content based on the request information to obtain query results. Next, it generates and executes planned execution instructions based on the request information and the queried content, yielding execution results including container scheduling unit status information and fault log information. Finally, the request information, query results, and execution results are all input into a large language model for fault diagnosis, resulting in a fault diagnosis result. This solves the technical problem of low operational efficiency in container platforms and achieves the technical effect of improving container platform operational efficiency. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram illustrating an application scenario of a fault diagnosis method according to an embodiment of this application;

[0013] Figure 2 This is a flowchart illustrating an optional fault diagnosis method according to an embodiment of this application;

[0014] Figure 3 This is a schematic diagram of an optional fault diagnosis system according to an embodiment of this application;

[0015] Figure 4 This is a structural block diagram of an optional fault diagnosis device according to an embodiment of this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0017] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0018] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] According to one aspect of the embodiments of this application, a fault diagnosis method is provided. Optionally, in this embodiment, the above-described fault diagnosis method may be applied, but is not limited to, to applications such as... Figure 1 The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0020] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity) and Bluetooth. Terminal device 102 may be, but is not limited to, PC (Personal Computer), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0021] The fault diagnosis method of this application embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the fault diagnosis method of this application embodiment can be executed by a client installed on the terminal device 102.

[0022] Taking the fault diagnosis method in this embodiment as an example, which is executed by terminal device 102, here, terminal device 102 can be a physical host. The fault diagnosis method in this embodiment is applied to the physical host. The memory that the physical host can call is divided into multiple memory levels. One of the multiple memory levels contains at least one type of memory. The multiple memory levels include the first memory level corresponding to the physical memory of the physical host. Here, physical hosts can be enterprise-level servers, cluster servers, office computers, embedded devices, or other physical devices that serve as underlying hardware support in a virtualization environment. Physical memory, on the other hand, is a physical memory module directly connected to the host hardware. It is the core and foundation of the memory architecture. Physical memory is usually composed of Dynamic Random Access Memory (DRAM), which has extremely fast read and write speeds and can respond to the processor's memory access requests with nanosecond-level response times. This makes physical memory suitable for carrying the core code of the virtual machine operating system, frequently called system function libraries, and critical process data that are running at high speeds. For example, at the beginning of virtual machine startup, the operating system kernel needs to quickly load and initialize various hardware drivers and establish a basic system operating environment. At this time, physical memory can complete data read and write operations with extremely high efficiency, ensuring that the virtual machine can start quickly and stably. During the operation of the virtual machine, application parts that have extremely demanding requirements for memory read and write performance, such as the transaction processing module of the database management system and the real-time rendering engine, also rely on physical memory to ensure their efficient operation, thereby maintaining the smoothness and responsiveness of the entire virtual machine system.

[0023] Figure 2 This is a flowchart illustrating an optional fault diagnosis method according to an embodiment of this application, such as... Figure 2As shown, the process of this method may include the following steps:

[0024] Step S202: Obtain the context information of the container scheduling unit from the front-end page, and generate the first request information based on the context information and the natural language instructions input by the target object;

[0025] Optionally, in step S202 above, the container scheduling unit is the smallest scheduling unit in the container platform. For example, a developer is viewing the details page of a Pod (a container scheduling unit, the smallest scheduling unit in Kubernetes, also called a container group) in the console page of the Kubernetes container platform and finds that its status is abnormal. He then activates the built-in fault diagnosis system in the container platform and asks, "This Pod seems to have a problem; can you help me take a look?" The intelligent assistant immediately captures the context of the current page and automatically identifies that the user is viewing the Pod with the ID "shopping-cart-7f..." in the namespace "dev". This context information and the user's question are sent to the backend as initial data to generate request information.

[0026] Step S204: Query the database for the associated information corresponding to the first request information to obtain the query results;

[0027] Step S206: Execute the execution instruction determined based on the first request information and the query result to obtain the execution result, wherein the execution result includes container scheduling unit status information and fault log information;

[0028] Optionally, in step S206 above, the execution instructions include a series of tool call requests. Executing the above execution instructions means obtaining container scheduling unit status information and fault log information by calling tools.

[0029] Step S208: Input the first request information, query results and execution results into the large language model to obtain the fault diagnosis results output by the large language model.

[0030] Through the above steps, request information is generated based on the natural language input from the target object and the context information of the container scheduling unit captured from the front-end page. Query results are obtained by retrieving relevant content from the database based on the request information. Then, planned execution instructions are generated and executed based on the request information and the retrieved content to obtain execution results including container scheduling unit status information and fault log information. Finally, the request information, query results, and execution results are all input into a large language model for fault diagnosis to obtain the fault diagnosis results. This solves the technical problem of low operational efficiency of container platforms and achieves the technical effect of improving the operational efficiency of container platforms.

[0031] In one exemplary embodiment, the database includes a knowledge base and an experience base. Querying the database to obtain the associated information corresponding to the first request information and obtaining query results includes: querying the knowledge base based on the first request information to obtain knowledge base query results, wherein the knowledge base query results include technical document information corresponding to the first request information; and querying the experience base based on the first request information to obtain experience base query results, wherein the experience base query results include fault case information corresponding to the first request information; and determining the query result based on the knowledge base query results and the experience base query results.

[0032] Optionally, in the above embodiments, for example, if the user's question in the first request information contains the keyword "Pod restart", then the relevant technical documents related to Pod restart will be queried from the knowledge base, and the relevant failure cases related to Pod restart will be queried from the experience base.

[0033] Through the above embodiments, a dual-drive mechanism of knowledge base and experience base has been implemented, achieving a shift from blind exploration to experience-guided diagnosis. When encountering complex problems, the system can instantly access previously successfully resolved cases, directly pinpoint the most probable cause, and formulate the optimal diagnostic path. This shortens the troubleshooting process, which might have taken tens of minutes or even hours and involved multiple rounds of manual checks, to one or two rounds of automated diagnosis within minutes. This experience-based reasoning acceleration capability is unmatched by simple tools or documents, saving enterprises significant time in troubleshooting.

[0034] In an exemplary embodiment, querying a knowledge base based on a first request to obtain a knowledge base query result includes: vectorizing the first request to obtain a first vector; determining a first index vector based on the similarity between the first vector and each knowledge base index vector in the knowledge base, wherein the similarity between the first index vector and the first vector is greater than a first preset similarity; and determining the document information in the knowledge base corresponding to the first index vector as the knowledge base query result.

[0035] In an exemplary embodiment, before querying the knowledge base according to the first request information and obtaining the knowledge base query result, the method further includes: performing text segmentation on all the acquired technical documents according to text semantics to obtain multiple text blocks; performing semantic vectorization on each text block to obtain a semantic vector; determining the semantic vector as the knowledge base index vector; and determining the text block corresponding to the semantic vector as the document information corresponding to the knowledge base index vector.

[0036] Optionally, in the above embodiments, the container platform's built-in fault diagnosis system provides a separate, configurable data processing pipeline. This pipeline connects to different data sources, such as Markdown documents in remote code repositories (Git) or documentation on the Kubernetes official website. It uses text segmentation algorithms to divide technical documents into semantically complete blocks, converts these text blocks into vectors by calling the API of a text vectorization model, and stores them along with the original text and metadata in a dedicated vector database. When processing user requests, it vectorizes the key information extracted from the request information and performs an efficient approximate nearest neighbor search in the vector database to retrieve the most relevant text blocks.

[0037] In an exemplary embodiment, querying the experience base according to the first request information to obtain the experience base query result includes: vectorizing the first request to obtain a second vector; determining a second index vector based on the similarity between the second vector and each experience base index vector in the experience base, wherein the similarity between the second index vector and the second vector is greater than a second preset similarity; and determining the fault case information in the experience base corresponding to the second index vector as the experience base query result.

[0038] In an exemplary embodiment, after obtaining the fault diagnosis result output by the large language model, the method further includes: generating structured data based on the first request information, query result, execution result and fault diagnosis result; vectorizing the structured data to obtain a third vector; determining the third vector as the experience base index vector; and determining the structured data as the fault case information corresponding to the experience base index vector.

[0039] Optionally, in the above embodiments, after a complex fault problem is successfully resolved, the system encapsulates the complete interaction process into an "experience case." This case is a structured object containing an initial problem description, key resource status characteristics, a complete "LLM (Large Language Model) thinking-tool invocation-result feedback" sequence, and the final solution. These cases are vectorized and stored in a dedicated experience library. When processing new user requests, the system performs a similarity search in the experience case library. If a highly similar case is recalled, its successful resolution path is given high priority.

[0040] Through the above embodiments, various scattered tacit knowledge can be structured and computationally accumulated through document knowledge bases and experience case libraries. It is not merely a static query system, but also a dynamic knowledge engine that proactively pushes relevant knowledge based on the problems users encounter in real time. More importantly, by continuously accumulating successful solutions into new experience cases, the system builds a self-improving and continuously evolving knowledge system, continuously empowering all users of the platform.

[0041] In one exemplary embodiment, executing an execution instruction determined based on the first request information and the query result to obtain an execution result includes: obtaining a tool list of the container platform, wherein the tool list includes multiple tools, each tool corresponding to an encapsulated executable operation unit; inputting the first request information, the query result, the tool list, and a first prompt word into a large language model, obtaining the execution instruction output by the large language model, wherein the first prompt word is used to instruct the large language model to directly determine the execution result through the tools in the tool list, and the execution instruction is used to initiate a tool call request to the tools in the tool list; initiating a tool call request to the tools in the tool list according to the execution instruction, obtaining a call result, and determining the call result as the execution result.

[0042] Optionally, in the above embodiments, the tools in the tool list are all obtained by standardizing and encapsulating application programming interfaces, system commands, database commands, etc. through MCP (Model Context Protocol). For example, initiating a tool call request includes viewing Pod details through Kubernetes' "get_pod_details" command and viewing Pod log information through the "get_pod_logs" command.

[0043] Optionally, in the above embodiments, for example, the first request information includes user question information, context information captured by the page, and query results include technical documents from the knowledge base and similar cases from the case library. Then, all the above information and tool list are sent to the large language model. The large language model understands the user's intent based on multi-source information and then generates an action plan, which includes specific execution steps. Then, it determines the tools that need to be called for each step and thus determines the specific execution instructions. Finally, it executes the instructions and obtains the execution results.

[0044] In one exemplary embodiment, executing an execution instruction determined based on the first request information and the query result to obtain an execution result includes: obtaining a tool list of the container platform, wherein the tool list includes multiple tools, each tool corresponding to an encapsulated executable operation unit; inputting the first request information, the query result, the tool list, and a second prompt word into a large language model, obtaining a data acquisition instruction and a data processing script output by the large language model, wherein the second prompt word is used to instruct the large language model to process the target data to obtain the execution result; initiating a tool call request to a tool in the tool list according to the data acquisition instruction to obtain the target data; and determining the execution result based on the target data and the data processing script.

[0045] In one exemplary embodiment, determining the execution result based on the target data and the data processing script includes: creating a sandbox code interpreter, which is an independent temporary code execution environment; inputting the target data and the data processing script into the sandbox code interpreter; and executing the data processing script on the target data in the sandbox code interpreter to obtain the execution result.

[0046] Optionally, in the above embodiments, for analytical queries requiring aggregation calculations, such as calculating the total CPU requests for each namespace, there are no readily available tools. In this case, the LLM generates a tool call chain. First, it calls the "get_all_pods_with_metrics" tool to obtain the raw data for all Pods, and then passes this data to a built-in, sandboxed code interpreter. Simultaneously, the LLM generates a data processing script to perform data aggregation, calculation, and sorting in a secure execution environment, and returns the final result.

[0047] In one exemplary embodiment, before initiating a tool call request to a tool in the tool list according to the execution instruction, the method further includes: determining whether the tool call request requires approval according to a preset approval strategy; if approval is required, pushing an approval request to the target object on the front-end page; after receiving the approval instruction from the target object, obtaining the target object's identity credentials; and initiating the tool call request using the identity credentials.

[0048] Optionally, in the above embodiments, the system supports configuring policies for different tools or operations to determine whether manual approval is required, and all tool call requests in the system must pass through a unified security gateway. This gateway enforces the use of the identity token of the end user initiating the operation and executes the operation as that user through Kubernetes' user impersonation function.

[0049] Through the above embodiments, and by deeply integrating with the platform's existing role-based access control system, it is ensured that all AI operations strictly adhere to the end-user's own permission boundaries, preventing the abuse of permissions. The approval strategy provides a security guarantee for high-risk operations such as deletion and modification, ensuring that critical changes are made under human supervision.

[0050] In an exemplary embodiment, after generating the first request information based on the context information of the container scheduling unit obtained from the front-end page and the natural language instructions input by the target object, the method further includes: determining a progress display area in the front-end page; and displaying the processing progress of the first request information to the target object in real time in the progress display area.

[0051] Optionally, in the above embodiments, throughout the entire lifecycle of task execution, the backend proactively pushes structured messages with clearly defined event types. For example, it pushes a "Tool call started" event to notify the frontend that a tool is being called, with the event payload containing the name and parameters of the called tool. After the call is completed, it pushes a "Tool call completed" event, with the event payload containing the tool call result. Based on this, the frontend page can render rich and dynamic interface elements, such as displaying "Calling 'kubectl get pod'..." in a card window.

[0052] The above embodiments break the black-box waiting of the traditional request-to-response model, greatly enhancing users' understanding and trust in the system's behavior.

[0053] The following describes an optional fault diagnosis method of this application embodiment with reference to optional embodiments. In one optional embodiment, the fault diagnosis method can be implemented by integrating a fault diagnosis system built into a container platform, such as... Figure 3 As shown, the above fault diagnosis system is logically divided into 5 clearly defined and highly decoupled levels:

[0054] Context-aware interaction layer: a portal for users to collaborate with the system, deeply integrated into the container platform's web console, serving as the place for intent input and result presentation.

[0055] Intent understanding and strategy generation layer: responsible for transforming natural language, context, and external knowledge into structured action plans.

[0056] Unified Capability Scheduling and Governance Layer: Responsible for dynamic connection, management, authentication, and invocation of all backend tools.

[0057] Persistent Memory and Experience Base Layer: Responsible for persistent storage of sessions, configurations, checkpoints, and success cases, and provides the foundation for future auditing and reasoning acceleration.

[0058] External tools and knowledge sources: All external content that the system can perceive and manipulate, including all Kubernetes APIs encapsulated by the MCP protocol, as well as various vectorized technical documents and troubleshooting cases.

[0059] Optional, such as Figure 3 As shown, the context-aware interaction layer includes the following modules:

[0060] 1. Visualized Cognitive Process Interface: This is not just a chat box, but also a window for users to observe the system's thought process. Its core technology lies in real-time streaming communication established by the backend through server-side events. In the system, the API controller responsible for handling chat requests returns a streaming response. Throughout the task's lifecycle, the backend proactively pushes structured messages with clearly defined event types. For example, it pushes a "Tool Invocation Started" event to notify the frontend that a tool is being invoked, with the event payload containing the name and parameters of the invoked tool. After the invocation is complete, it pushes a "Tool Invocation Completed" event, with the event payload containing the tool invocation result. The frontend can then render rich, dynamic interface elements, such as displaying "Invoking 'kubectl get pod'..." in a card window.

[0061] 2. Automatic Context Capture: As a component deeply embedded in the container platform's web console, it possesses the ability to perceive the user's current operational context. By listening to routing changes in the web application or accessing its global state manager, the front-end plugin can automatically extract key information about the resource the user is viewing, such as Pod name, namespace, and resource type. When the user activates the intelligent assistant of the troubleshooting system, this contextual information will be automatically sent to the backend as part of the initial payload, along with the user's first question (e.g., "What's wrong with this Pod?"). This capability allows users to ask questions very naturally and concisely without manually specifying the target, greatly improving the smoothness and efficiency of the interaction.

[0062] 3. Interactive Clarification Mechanism: When the intent understanding and strategy generation layer encounters uncertainty, such as a user saying "create a Pod" but not specifying an image, it generates a special "clarification_required" event. The event payload contains a question (e.g., "Please select a container image") and a data structure (e.g., a JSON object containing a list of recommended images). Upon receiving this event, the frontend renders the corresponding interactive component, such as a dropdown menu or a set of option buttons. The user's selection is sent back to the backend as supplementary information for the current plan, thus driving a multi-turn dialogue.

[0063] 4. High-Risk Operation Approval Card: When an operation initiated by the backend requires user approval, an "approval_required" event will be pushed. The frontend renders a card containing operation details and an "Approve / Reject" button. The user's decision will determine the subsequent process.

[0064] 5. Deeply integrated Web console interface: As an embedded sidebar of the Web console, it provides accompanying assistance and can also be maximized into an independent window for handling complex issues, providing an immersive dialogue experience.

[0065] Optional, such as Figure 3 As shown, the intent understanding and policy generation layer includes the following modules:

[0066] 1. Retrieval Enhancement Engine: The system provides a standalone, configurable data processing pipeline. This pipeline connects to different data sources (such as Markdown documents in Git repositories and Confluence pages), uses text segmentation algorithms to divide long documents into semantically complete text blocks, converts these text blocks into vectors by calling the text vectorization model's API, and stores them along with the original text and metadata in a dedicated vector database. When processing user requests, the engine vectorizes the user's original question or extracted key error information, performs an efficient approximate nearest neighbor search in the vector database, and retrieves the K most relevant text blocks. These retrieved text blocks, as "immediate knowledge," are dynamically injected into the contextual scaffolding of prompt words to improve the accuracy and depth of LLM responses.

[0067] 2. Multi-turn Dialogue and State Management Module: To support continuous tasks such as creating virtual machines or step-by-step debugging, the system maintains a state object for each dialogue session in the persistent memory and experience base layer. This object is stored in memory cache or database in JSON format, recording key information for each round of dialogue, such as confirmed parameters, questions to be clarified, and results of historical tool calls. In each round of interaction, this state object is loaded into the context, enabling the LLM to understand the continuity of the dialogue.

[0068] 3. Complex Query Inference Engine: This engine is the core for solving complex problems that are not directly related and require in-depth analysis.

[0069] 3.1 Query Decomposition: When a complex query is received (e.g., “List all Deployments to which Pods in the production environment have been restarted more than 5 times”), the primary task of LLM is to decompose it into a sub-task graph with logical dependencies. For example, the nodes of the graph may include: (1) List all Pods; (2) Filter out Pods in the production environment; (3) Filter out Pods with more than 5 restarts; (4) Get the parent ReplicaSet of each Pod; (5) Get the parent Deployment of each ReplicaSet; (6) Deduplicate and output the list of Deployments.

[0070] 3.2 Execution Coordinator: An execution coordinator is responsible for executing the above task graph sequentially. It calls the appropriate tools to execute each node and saves the execution results (such as a list of Pods) in the current session's state object as input for the next node.

[0071] 4. Code Interpreter: For analytical queries requiring aggregation calculations, such as calculating the total CPU requests for each namespace, there are no readily available tools. In this case, the LLM generates a tool call chain. First, it calls the "get_all_pods_with_metrics" tool to retrieve the raw data for all Pods. Then, it passes this data to a built-in, sandboxed code interpreter. Simultaneously, the LLM generates a data processing script to perform data aggregation, computation, and sorting in a secure execution environment, and returns the final result. This capability allows the system to answer virtually unlimited, open-ended analytical questions.

[0072] 5. LLM-Driven Intent-to-Plan Transformer: This component is responsible for parsing action plans generated by LLM and containing MCP tags. A key enhancement is that when a user's question does not match any available tools and the knowledge base does not return a high-confidence answer, the system is designed to return a clear message: "Sorry, I cannot match your question to any known operational tools or knowledge base entries. My capabilities are primarily focused on assisting you in managing and querying container platform resources." This tool-matching limitation ensures that the system focuses on its core task.

[0073] Optional, such as Figure 3 As shown, the unified capability scheduling and governance layer includes the following modules:

[0074] 1. Dynamic Capability Discovery and Configuration Center: Administrators manage all MCP tool servers through a visual interface. Each registered tool has a status switch. When this layer provides the list of available capabilities to the intent understanding and policy generation layer, it filters out all disabled tools. The system provides a policy configuration module to manage the approval process for tool calls. Administrators can fine-tune whether approval is required for each tool; this configuration is stored along with the tool's metadata.

[0075] 2. Unified Security and Permission Execution Gateway: This is the necessary path for all tools to call, and it enforces security checks before execution.

[0076] 3. Approval Process Executor: When an upper-layer service sends a tool call request, the gateway first checks the tool's approval policy. If approval is required, it pauses execution, pushes an "approval_required" event to the context-aware interaction layer, and persists the current execution process status as "pending_approval".

[0077] 4. Access Control and User Impersonation: Integration of the system with the container platform's authentication system. When a user logs in, the system obtains their identity token. Each time a tool call is initiated, this token is passed along with the request to the MCP protocol scheduling hub that ultimately executes the operation. The MCP protocol scheduling hub must use this token for user impersonation when interacting with Kubernetes API services. This means that all operations are executed as the end user, naturally inheriting the platform's existing RBAC (Role-Based Access Control) permission policy, ensuring that users can only operate on resources within their authorized scope.

[0078] 5. MCP Protocol Scheduling Center: Responsible for scheduling tool invocation requests and distributing the requests to the corresponding service providers.

[0079] Optional, such as Figure 3 As shown, the persistent memory and experience base layer includes the following modules:

[0080] 1. Structured session storage and audit logs:

[0081] Dialogue persistence: All user interactions with the agent, including every message, every tool call, every knowledge base retrieval, and every approval decision, are modeled using object-relational mapping and persisted as structured data to a relational database. Users can view and restore historical conversations.

[0082] Audit logs: Persistent and detailed logs form a complete audit trail for security administrators to query.

[0083] 2. Dialogue Checkpoints and Rollback Mechanism: This feature is implemented through snapshots and restoration of the session state. At critical points in a multi-turn dialogue, the system automatically creates a snapshot of the current session state. When the user requests rollback, the system retrieves the latest state snapshot and restores it to the current active session state, allowing the user to safely explore complex sequences of actions.

[0084] 3. Experience case library and accelerated reasoning:

[0085] Case Generation and Storage: When a complex problem is successfully resolved, the system encapsulates the entire interaction process into an "experience case." This case is a structured object containing an initial problem description, key resource status characteristics, a complete "LLM (Large Language Model) thinking - tool invocation - result feedback" sequence, and the final solution. These cases are vectorized and stored in a dedicated experience library. When processing new user requests, the system performs a similarity search in the experience case library. If a highly similar case is recalled, its successful solution path is given high priority.

[0086] Case-based reasoning: When the intent understanding and policy generation layer receives a new question, it simultaneously performs a similarity search in both the document knowledge base and the experience case base. If a highly similar case is recalled, its successful solution path (i.e., the tool call sequence) is provided to the LLM as a high-priority reference. This allows the LLM to skip many exploratory intermediate steps and directly propose a validated and efficient solution, thereby shortening the reasoning process and accelerating inference.

[0087] Optional, such as Figure 3 As shown, external tools and knowledge sources can access Kubernetes APIs, container image repository tools, monitoring system tools, documentation knowledge base tools, and other tools. All tools are encapsulated using the MCP protocol.

[0088] In an optional embodiment, the fault determination method of this application is described using the fault diagnosis system described in the above embodiments, combined with a specific application scenario.

[0089] This will be illustrated using the complete lifecycle of a user from asking a question to resolving it.

[0090] Step 1: Initialization and Context Information Capture.

[0091] In this embodiment, the system is deployed as a front-end plugin and a back-end service cluster of a container management web platform used by the user. When the user logs into the web platform and navigates to the details page of a resource (e.g., a Pod named api-gateway-xyz in the namespace production), the context-aware interaction layer (front-end plugin) of this invention is activated. This plugin automatically obtains and temporarily stores the current context information by listening to the routing events of the front-end application or accessing its global state management library. Its data structure can be represented as: {"context_type":"resource_view","resource":{"kind":"Pod","name":"api-gateway-xyz","namespace":"production"}}. At this time, an interactive smart assistant icon or sidebar is displayed on the interface.

[0092] Step 2: User intent initiation and initial processing.

[0093] The user clicks the assistant icon and enters the question: "Why does this Pod keep restarting?". The front-end plugin packages the user's natural language question with the context information captured in the previous step and sends it to the backend's "intent understanding and policy generation layer" via a secure HTTPS request. An example of the request payload is as follows: {"session_id": "session-12345", "query": "Why does this Pod keep restarting?", "context": {...}}. The backend entry point is an API service built on a Python asynchronous framework. It first creates or loads a session state object for the session_id, which is stored in an in-memory cache such as Redis to support multi-turn conversations.

[0094] Step 3: Understanding the intent and planning actions for knowledge enhancement.

[0095] Once the intent understanding and strategy generation layer receives a request, its internal "complex query reasoning engine" is activated.

[0096] 1. Knowledge Base Retrieval: The engine first extracts keywords from user questions, such as "Pod restart". These keywords are vectorized and then fed into a document knowledge base built on a vector database for similarity searching. For example, it might retrieve an official documentation snippet describing the "CrashLoopBackOff" state, explaining its possible causes (e.g., the program crashes immediately after startup, configuration errors, etc.).

[0097] 2. Experience Base Retrieval: Simultaneously, the engine vectorizes the more specific problem feature "Pod 'api-gateway-xyz'in 'production' restarting" and searches within the experience case library. Assuming a highly similar case is found, its summary would be: "Case 78: The 'billing-service' Pod experienced a 'CrashLoop-BackOff' state due to a database 'ConfigMap' configuration error. Checking the logs revealed a 'connection refused' error, which was resolved by correcting the 'ConfigMap'."

[0098] 3. LLM-driven planning generation: The engine constructs a rich prompt and submits it to the LLM. This prompt includes the following parts:

[0099] System role definition: You are a senior Kubernetes SRE assistant.

[0100] List of available tools (compliant with MCP specifications): obtained by querying the unified capability scheduling and governance layer, such as "k8s_tools.get_pod_details", "k8s_tools.get_pod_logs", etc.

[0101] Injected knowledge: includes text retrieved from the document knowledge base and experience case library.

[0102] Conversation history and current context: Includes the history of "session_id" and the current Pod's context.

[0103] User instruction: Based on the information above, please develop the most efficient diagnostic plan for the user's question "Why does this Pod keep restarting?"

[0104] After receiving this hint containing prior knowledge, LLM's reasoning process is significantly optimized. Instead of generating a generic plan, it generates a highly targeted, structured action plan (output in JSON format) based on the experience base hints: {"plan": [{"step": 1, "thought": "User reports Pod restart, which is usually CrashLoopBackOff. The experience base hints this might be configuration-related. First, I need to call get_pod_details to confirm the exact status of the Pod and the number of restarts.", "action": {"tool_name": "k8s_tools.get_pod_details", "parameters": {"name": "api-gatew ay-xyz","namespace":"production"}}},{"step":2,"thought":"If the status is confirmed as CrashLoopBackOff, both the experience base and knowledge base point to checking the logs to find the direct cause of the startup failure. I will get the latest logs for this Pod.","action":{"tool_name":"k8s_tools.get_pod_logs","parameters":{"name":"api-gateway-xyz","namespace":"production","lines":200}}}]}.

[0105] Step 4: Controlled and auditable execution of actions.

[0106] The system's stateful execution coordinator parses the above plan and executes it one by one.

[0107] 1. The coordinator sends a request to the unified capability scheduling and governance layer to call "k8s_tools.get_pod_details".

[0108] 2. Security and Authorization Gateway: The request first passes through the gateway. The gateway checks the tool's metadata and finds that this is a read-only operation, requiring no approval. The gateway extracts the user's identity token from the user session and appends this token to the request header sent to the "k8s_tools" tool server.

[0109] 3. Tool Server Execution: The "k8s_tools" server is a standalone microservice. Upon receiving a request, it uses the received user token to interact with the Kubernetes API Server via the Kubernetes client library, setting a "user impersonation" header in its request. This means the operation is executed as the end user, fully restricted by that user's existing RBAC permissions in Kubernetes. If the user does not have permission to view Pods in the "production" namespace, the API Server will directly reject the request.

[0110] 4. Result Return and Log Recording: The "k8s_tools" server returns the Pod configuration description obtained from the APIServer to the coordinator. Simultaneously, the persistent memory and experience base layer's auditing module records this call (caller, tool, parameters, timestamp) in the database.

[0111] Step 5: Iterative analysis and expert-level result translation.

[0112] The coordinator updates the session state with the results of the first step (Pod configuration, confirmation status as CrashLoopBackOff, restart count as 15) and continues with the second step of the plan: retrieving logs. The execution flow is the same as above. Assume the returned log fragment contains the critical error message: Error: Invalid connection string in config file / etc / config / db.conf. The coordinator resubmits all execution results (Pod status, restart count, critical logs) along with the original problem and retrieved knowledge to the LLM, and issues a final translation instruction: "Task complete. Please synthesize all information and provide the user with a complete root cause analysis report and clear remediation recommendations." The LLM ultimately generates a user-friendly natural language response and pushes it to the front end.

[0113] "I noticed that the Pod 'api-gateway-xyz' you are looking at is in a state of repeated restarts (CrashLoopBackOff), and has restarted 15 times."

[0114] Root cause analysis: According to the Pod's logs, the program failed to resolve the database connection string located in ` / etc / config / db.conf` at startup. Based on information I found in the knowledge base, this is usually because a key-value pair in this configuration file (likely from a ConfigMap named `api-gateway-config`) has a malformed format or is referencing a non-existent key.

[0115] Repair suggestions:

[0116] 1. Please check the ConfigMap resource named api-gateway-config associated with this Pod.

[0117] 2. Please check the db.conf file to ensure that the database address, port, and username are in the correct format.

[0118] 3. Operation: You can directly modify this ConfigMap using the platform's YAML editor. After saving the changes, the relevant Pods will be automatically recreated and the new configuration will be loaded. Do you need me to retrieve the contents of this ConfigMap for you?

[0119] Step 6: Accumulate experience.

[0120] After the problem is resolved, the system can prompt the user or administrator: "This troubleshooting seems to have been successfully resolved. Would you like to save it as an experience case to help quickly resolve similar problems in the future?" If the user agrees, the system background will start a task to package the key elements of this session (initial problem, resource characteristics, successful diagnostic steps sequence, final solution) into a structured JSON object, vectorize it, and store it in the experience case library, completing a closed loop of self-learning and evolution.

[0121] Through the above implementation methods, users are freed from tedious and error-prone configuration writing and complex command-line memorization. Developers and junior operations personnel no longer need to delve into the details and command parameters of dozens of resource objects; they only need to describe their intentions in natural language, and the system can intelligently translate them into accurate configurations and operations. This significantly reduces the learning curve of cloud-native technologies and the mental burden of daily use, enabling a wider range of technical personnel to efficiently and confidently leverage the capabilities of the container platform, thereby improving the productivity of the entire R&D team. It also significantly improves the usability, operational efficiency, knowledge management level, and security governance capabilities of the container platform.

[0122] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (e.g., read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0123] According to another aspect of the embodiments of this application, a fault diagnosis device is also provided, which can be used to implement the fault diagnosis method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0124] Figure 4 This is a structural block diagram of an optional fault diagnosis device according to an embodiment of this application, such as... Figure 4 As shown, the fault diagnosis device includes:

[0125] The acquisition module 42 is used to obtain the context information of the container scheduling unit from the front-end page, and generate the first request information based on the context information and the natural language instructions input by the target object;

[0126] Query module 44 is used to query the database for related information corresponding to the first request information and obtain the query results;

[0127] The execution module 46 is used to execute the execution instructions determined according to the first request information and the query results, and obtain the execution results, wherein the execution results include container scheduling unit status information and fault log information;

[0128] Module 48 is used to input the first request information, query results and execution results into the large language model to obtain the fault diagnosis results output by the large language model.

[0129] The fault diagnosis device provided in this application generates request information based on the natural language input from the target object and the context information of the container scheduling unit captured from the front-end page. It then queries the database for content related to the request information to obtain query results. Next, it generates and executes planned execution instructions based on the request information and the queried content, resulting in execution results including container scheduling unit status information and fault log information. Finally, the request information, query results, and execution results are all input into a large language model for fault diagnosis to obtain the fault diagnosis result. This solves the technical problem of low operational efficiency of container platforms and achieves the technical effect of improving the operational efficiency of container platforms.

[0130] In an exemplary embodiment, the database includes a knowledge base and an experience base. The query module 44 is configured to query the knowledge base according to the first request information to obtain a knowledge base query result, wherein the knowledge base query result includes technical document information corresponding to the first request information; and to query the experience base according to the first request information to obtain an experience base query result, wherein the experience base query result includes fault case information corresponding to the first request information; and to determine a query result based on the knowledge base query result and the experience base query result.

[0131] In an exemplary embodiment, the query module 44 is configured to vectorize the first request to obtain a first vector; determine a first index vector based on the similarity between the first vector and each knowledge base index vector in the knowledge base, wherein the similarity between the first index vector and the first vector is greater than a first preset similarity; and determine the document information in the knowledge base corresponding to the first index vector as the knowledge base query result.

[0132] In an exemplary embodiment, the query module 44 is configured to perform text segmentation on all the acquired technical documents according to the text semantics to obtain multiple text blocks; to perform semantic vectorization on each text block to obtain a semantic vector; to determine the semantic vector as a knowledge base index vector; and to determine the text block corresponding to the semantic vector as the document information corresponding to the knowledge base index vector.

[0133] In an exemplary embodiment, the query module 44 is used to vectorize the first request to obtain a second vector; determine a second index vector based on the similarity between the second vector and each experience library index vector in the experience library, wherein the similarity between the second index vector and the second vector is greater than a second preset similarity; and determine the fault case information in the experience library corresponding to the second index vector as the experience library query result.

[0134] In an exemplary embodiment, module 48 is configured to generate structured data based on the first request information, query results, execution results, and fault diagnosis results; vectorize the structured data to obtain a third vector; determine the third vector as an experience base index vector; and determine the structured data as fault case information corresponding to the experience base index vector.

[0135] In an exemplary embodiment, the execution module 46 is configured to obtain a tool list of the container platform, wherein the tool list includes multiple tools, each tool corresponding to an encapsulated executable operation unit; input the first request information, query results, tool list, and first prompt word into the large language model, obtain the execution instructions output by the large language model, wherein the first prompt word is used to instruct the large language model to directly determine the execution result through the tools in the tool list, and the execution instructions are used to initiate tool call requests to the tools in the tool list; initiate tool call requests to the tools in the tool list according to the execution instructions, obtain the call results, and determine the call results as the execution results.

[0136] In an exemplary embodiment, the execution module 46 is configured to obtain a tool list of the container platform, wherein the tool list includes multiple tools, each tool corresponding to an encapsulated executable operation unit; input the first request information, query results, tool list, and second prompt word into the large language model; obtain the data acquisition instruction and data processing script output by the large language model; wherein the second prompt word is used to instruct the large language model to process the target data to obtain the execution result; initiate a tool call request to the tools in the tool list according to the data acquisition instruction to obtain the target data; and determine the execution result based on the target data and the data processing script.

[0137] In an exemplary embodiment, execution module 46 is configured to create a sandbox code interpreter, which is an independent temporary code execution environment; input target data and data processing script into the sandbox code interpreter; execute the data processing script on the target data in the sandbox code interpreter to obtain the execution result.

[0138] In an exemplary embodiment, the execution module 46 is configured to determine whether the tool call request requires approval based on a preset approval strategy; if approval is required, push the approval request to the target object on the front-end page; after receiving the approval instruction from the target object, obtain the target object's identity credentials; and initiate the tool call request using the identity credentials.

[0139] In one exemplary embodiment, the apparatus is further configured to determine a progress display area in the front-end page; and to display the processing progress of the first request information to the target object in real time in the progress display area.

[0140] The description of the features in the embodiments corresponding to the above-mentioned fault diagnosis device can be found in the relevant descriptions of the embodiments corresponding to the fault diagnosis method, and will not be repeated here.

[0141] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described fault diagnosis method embodiments.

[0142] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described fault diagnosis method embodiments when it is run.

[0143] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0144] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described fault diagnosis method embodiments.

[0145] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described fault diagnosis method embodiments.

[0146] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The foregoing has provided a detailed description of the method, apparatus, storage medium, and electronic device of a distributed storage system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A fault diagnosis method, characterized in that, Applied to a container platform, the container platform is used to manage containers through a container scheduling unit; include: The context information of the container scheduling unit is obtained from the front-end page, and the first request information is generated based on the context information and the natural language instructions input by the target object. Retrieve the associated information corresponding to the first request information from the database to obtain the query results; Execute the execution instruction determined based on the first request information and the query result to obtain the execution result, wherein the execution result includes container scheduling unit status information and fault log information; The first request information, the query result, and the execution result are input into the large language model to obtain the fault diagnosis result output by the large language model; The execution of the execution instruction determined based on the first request information and the query result to obtain the execution result includes: obtaining a tool list of the container platform, wherein the tool list includes multiple tools, each tool corresponding to a packaged executable operation unit; inputting the first request information, the query result, the tool list, and a first prompt word into the large language model, obtaining the execution instruction output by the large language model, wherein the first prompt word is used to instruct the large language model to directly determine the execution result through the tools in the tool list, and the execution instruction is used to initiate a tool call request to the tools in the tool list; initiating a tool call request to the tools in the tool list according to the execution instruction, obtaining a call result, and determining the call result as the execution result.

2. The fault diagnosis method according to claim 1, characterized in that, The database includes a knowledge base and an experience base. The database is used to query the associated information corresponding to the first requested information to obtain query results, including: The knowledge base is queried according to the first request information to obtain the knowledge base query results, wherein the knowledge base query results include technical document information corresponding to the first request information; And query the experience base according to the first request information to obtain the experience base query results, wherein the experience base query results include fault case information corresponding to the first request information; The query result is determined based on the query results from the knowledge base and the query results from the experience base.

3. The fault diagnosis method according to claim 2, characterized in that, The knowledge base is queried based on the first request information to obtain the knowledge base query results, including: The first request is vectorized to obtain a first vector; The first index vector is determined based on the similarity between the first vector and each knowledge base index vector in the knowledge base, wherein the similarity between the first index vector and the first vector is greater than a first preset similarity. The document information in the knowledge base corresponding to the first index vector is determined as the knowledge base query result.

4. The fault diagnosis method according to claim 2, characterized in that, Before querying the knowledge base based on the first request information and obtaining the knowledge base query results, the method further includes: Based on text semantics, all the acquired technical documents are segmented into multiple text blocks; Each text block is semantically vectorized to obtain a semantic vector; The semantic vector is determined as the knowledge base index vector, and the text block corresponding to the semantic vector is determined as the document information corresponding to the knowledge base index vector.

5. The fault diagnosis method according to claim 2, characterized in that, The experience base is queried based on the first request information to obtain the experience base query results, including: The first request is vectorized to obtain the second vector; The second index vector is determined based on the similarity between the second vector and each experience base index vector in the experience base, wherein the similarity between the second index vector and the second vector is greater than a second preset similarity. The fault case information in the experience base corresponding to the second index vector is determined as the query result of the experience base.

6. The fault diagnosis method according to claim 1, characterized in that, After obtaining the fault diagnosis results output by the large language model, the method further includes: Structured data is generated based on the first request information, the query results, the execution results, and the fault diagnosis results; The structured data is vectorized to obtain a third vector; The third vector is determined as the experience base index vector, and the structured data is determined as the fault case information corresponding to the experience base index vector.

7. The fault diagnosis method according to claim 1, characterized in that, Execute the execution instructions determined based on the first request information and the query result to obtain the execution result, including: Obtain the tool list of the container platform, wherein the tool list includes multiple tools, each tool corresponding to a packaged executable operation unit; The first request information, the query result, the tool list, and the second prompt word are input into the large language model to obtain the data acquisition instruction and data processing script output by the large language model. The second prompt word is used to instruct the large language model to process the target data to obtain the execution result. According to the data acquisition instruction, a tool call request is initiated to the tool in the tool list to obtain the target data; The execution result is determined based on the target data and the data processing script.

8. The fault diagnosis method according to claim 7, characterized in that, Determining the execution result based on the target data and the data processing script includes: Create a sandbox code interpreter, which is an independent temporary code execution environment; Input the target data and the data processing script into the sandbox code interpreter; The data processing script is executed on the target data in the sandbox code interpreter to obtain the execution result.

9. The fault diagnosis method according to claim 1, characterized in that, Before initiating a tool invocation request to a tool in the tool list according to the execution instruction, the method further includes: Determine whether the tool call request requires approval based on a preset approval strategy; If approval is required, an approval request is pushed to the target object on the front-end page. After receiving the approval instruction from the target object, obtain the target object's identity credentials; The tool invocation request is initiated using the identity credentials.

10. The fault diagnosis method according to claim 1, characterized in that, After generating the first request information based on the context information of the container scheduling unit obtained from the front-end page and the natural language instructions input by the target object, the method further includes: Determine the progress display area in the front-end page; The processing progress of the first request information is displayed to the target object in real time in the progress display area.

11. A fault diagnosis device, characterized in that, include: The acquisition module is used to acquire context information of the container scheduling unit from the front-end page, and generate first request information based on the context information and the natural language instructions input by the target object; The query module is used to query the database for associated information corresponding to the first request information and obtain the query results; An execution module is used to execute the execution instructions determined based on the first request information and the query result, and obtain the execution result, wherein the execution result includes container scheduling unit status information and fault log information; The module is used to input the first request information, the query result and the execution result into the large language model to obtain the fault diagnosis result output by the large language model; The execution module is further configured to obtain a tool list of the container platform, wherein the tool list includes multiple tools, each tool corresponding to an encapsulated executable operation unit; input the first request information, the query result, the tool list, and the first prompt word into the large language model, obtain the execution instruction output by the large language model, wherein the first prompt word is used to instruct the large language model to directly determine the execution result through the tools in the tool list, and the execution instruction is used to initiate a tool call request to the tools in the tool list; initiate a tool call request to the tools in the tool list according to the execution instruction, obtain the call result, and determine the call result as the execution result.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the fault diagnosis method as described in any one of claims 1 to 10 when executing the computer program.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the fault diagnosis method as described in any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the fault diagnosis method as described in any one of claims 1 to 10.

Images