Intelligent function calling method and system with error self-repairing capability

Abstract

This application discloses an intelligent function call method and system with error self-correction capabilities, relating to the interdisciplinary fields of artificial intelligence and software engineering. The method includes: acquiring user task requirement text and determining function call information; verifying and executing the function call information; capturing exceptions and generating structured error description information if failure occurs; querying an experience knowledge base based on corrective tags and error signatures as keys to obtain historical successful correction information; reusing the corrected information directly if it exists, and generating a correction scheme through a multi-level correction strategy if it does not exist, returning the correction scheme as new input to the verification steps until success or a circuit breaker is triggered. This application achieves intelligent perception, accurate diagnosis, and adaptive repair of function call errors by constructing a closed-loop feedback mechanism of "execution-analysis-decision-correction," and avoids invalid retries through an intelligent circuit breaker mechanism, thereby significantly improving the task success rate and robustness of the intelligent system in complex environments.

Description

Technical Field

[0001] This application relates to the interdisciplinary field of artificial intelligence and software engineering, and in particular to an intelligent agent task execution system based on a Large Language Model (LLM). More specifically, it relates to an intelligent function call method and system with error self-correction capabilities, which achieves closed-loop error repair during function calls through automated semantic analysis, multi-level adaptive correction strategies, and knowledge-based experience learning. Background Technology

[0002] With the rapid development of large language model technology based on the Transformer architecture, building intelligent agents using large language models has become a mainstream technical solution for automating complex tasks. In intelligent agent systems, intelligent function calls serve as a key mechanism connecting large language models with external tools. By converting users' natural language commands into structured function call information, they drive external components to perform specific operations.

[0003] Intelligent function call systems in related technologies typically employ a unidirectional linear execution flow: the system generates function call information based on user input, parses and verifies it, and then executes the corresponding operation. However, due to the inherent probabilistic generation characteristics of large language models, the output function call information often contains errors such as parameter type mismatches, out-of-bounds parameter values, and missing components or actions, leading to task execution failure. The system lacks an effective error self-correction mechanism and cannot automatically analyze and repair anomalies generated during execution, making it difficult to guarantee task success rates.

[0004] Therefore, there is an urgent need for an intelligent function call method with error self-correction capabilities to solve the problem of function call failures caused by errors generated by large language models and the inability to automatically repair them, thereby improving the success rate of task execution and the robustness of the system. Summary of the Invention

[0005] The purpose of this application is to provide an intelligent function call method and system with error self-correction capabilities. When a function call fails, it can automatically capture and analyze error information, generate a correction scheme through the reuse of an experience knowledge base or a multi-level correction strategy, and achieve automatic error repair, thereby improving the success rate of task execution and the robustness of the system.

[0006] To achieve the above objectives, this application provides the following solution: In a first aspect, this application provides an intelligent function call method with error self-correction capability, comprising: acquiring task requirement text described by a user in natural language form, and determining function call information based on the task requirement text; the function call information includes a target component identifier, operation action type, and a call parameter dictionary; verifying the function call information, and executing the function call information after successful verification; if verification fails or an exception is thrown when executing the function call information, capturing the verification failure information or exception information, and generating structured error description information; the structured error description information includes error type, severity level, corrective flag, error signature, number of attempts, and historical attempt records; based on the corrective flag, querying an experience knowledge base using the error signature as the key to obtain reusable correction results; the experience knowledge base includes the error signature and corresponding historical successful correction information; the... Historical successful correction information includes the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary. If the reusable correction result indicates the existence of historical successful correction information, the corresponding historical successful correction information is directly used as the corrected function call information. If the reusable correction result indicates the absence of historical successful correction information, corrected function call information is generated based on the structured error description information through a multi-level correction strategy. The multi-level correction strategy includes parameter fine-tuning strategy, component or action replacement strategy, and function call information reconstruction strategy. The corrected function call information is used as the function call information, and the process returns to the step "Based on the function call information, obtain the verification result through a preset verification method, and execute the function call information when the verification result is passed," until the function call information is successfully executed or the circuit breaker condition is triggered. The circuit breaker condition includes the cumulative number of occurrences of the same error signature reaching a preset threshold.

[0007] Secondly, this application provides an intelligent function call system with error self-correction capabilities, comprising: an intent parsing module, used to acquire task requirement text described by a user in natural language form, and determine function call information based on the task requirement text; the function call information includes target component identifier, operation action type, and call parameter dictionary; an execution verification module, used to verify the function call information, and execute the function call information after successful verification; an error semantic analysis module, used to capture verification failure information or exception information if verification fails or an exception is thrown when executing the function call information, and generate structured error description information; the structured error description information includes error type, severity level, corrective flag, error signature, number of attempts, and historical attempt records; and an experience knowledge base module, used to query the experience knowledge base based on the corrective flag and the error signature as the key to obtain reusable correction results; the experience knowledge base includes the error signature and the corresponding historical records. The system includes: a function call information module; historical successful correction information including the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary; an intelligent correction decision module, used to directly use the corresponding historical successful correction information as the correction function call information if the reusable correction result indicates the existence of historical successful correction information; if the reusable correction result indicates the absence of historical successful correction information, it generates correction function call information based on structured error description information through a multi-level correction strategy; the multi-level correction strategy includes parameter fine-tuning strategy, component or action replacement strategy, and function call information reconstruction strategy; and a retry management and circuit breaker module, used to use the correction function call information as function call information and return to the step "Based on the function call information, obtain the verification result through a preset verification method, and execute the function call information when the verification result is passed", until the function call information is successfully executed or the circuit breaker condition is triggered; the circuit breaker condition includes the cumulative number of occurrences of the same error signature reaching a preset threshold.

[0008] According to the specific embodiments provided in this application, this application has the following technical effects: This application provides an intelligent function call method and system with error self-correction capabilities. By acquiring user task requirements and determining initial function call information, it solves the problem of error-prone initial output of large language models in existing technologies, achieving preliminary accurate conversion of task intent. By verifying and executing function call information and capturing and structurally analyzing failure information, it solves the problem of existing systems only reporting errors without fixing them and providing unusable feedback information, realizing the transformation of underlying program errors into machine-understandable semantic feedback and the standardization and semantic understanding of error information. By querying an experience knowledge base based on corrective tags and error signatures and reusing historical correction schemes, it solves the problems of system "forgetfulness," repetitive errors requiring complete re-analysis of reasoning, and the inability to learn from historical experience, achieving... This approach enables rapid and low-cost correction of recurring errors. By generating new correction schemes using a layered correction strategy when the knowledge base is not hit, it solves the problems of static retry strategies failing to distinguish error types and severity, existing retry mechanisms being simplistic, and significant resource waste. It achieves adaptive correction by intelligently allocating computing resources based on error severity, realizing a dynamic balance between computing resources and correction depth. By returning the correction scheme as new input to the verification execution step and setting circuit breaker conditions to terminate invalid retries, it solves the defects of the existing architecture being unidirectional and open-loop, and the problem of the system getting stuck in an infinite retry loop. It realizes closed-loop intelligent control of "perception-analysis-decision-execution-learning", enabling the system to iterate autonomously until success or safe exit, thereby significantly improving the robustness, success rate, and resource efficiency of intelligent function calls. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the 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.

[0010] Figure 1 This is a data flow diagram of an intelligent function call method with error self-correction capability according to an embodiment of this application.

[0011] Figure 2 for Figure 1 A detailed flowchart illustrating the steps of the error semantic analysis module.

[0012] Figure 3 for Figure 1 A detailed flowchart illustrating the steps of the intelligent correction decision module.

[0013] Figure 4 for Figure 1 A detailed flowchart illustrating the steps involved in retrieving knowledge from the Chinese experience knowledge base.

[0014] Figure 5 for Figure 1 A detailed flowchart illustrating the steps involved in storing knowledge in a knowledge base.

[0015] Figure 6 for Figure 1 A detailed flowchart illustrating the steps involved in the retry management and circuit breaker module.

[0016] Figure 7 for Figure 1 A detailed flowchart illustrating the steps of the feedback coordination control module. Detailed Implementation

[0017] First, some technical terms involved in the embodiments of this application will be introduced.

[0018] In related technologies, intelligent function call processes typically follow linear logic: the system receives natural language commands from the user (using LLM for semantic reasoning to parse the target tool (Module), action, and parameters), and then drives external components such as calculators, search tools, or databases to perform operations. This approach greatly improves the efficiency of human-computer interaction, enabling non-professional users to manipulate complex software systems through natural language. However, despite the widespread application of intelligent function call technology, significant technical bottlenecks still exist in practical engineering implementations, making it difficult for the system's robustness and availability to meet production environment requirements.

[0019] Existing intelligent function call technologies face four core challenges: ① Insufficient robustness: The "illusion" of probabilistic models leads to high-frequency errors in call instructions, lacking effective error defense mechanisms. ② Lack of feedback mechanisms: Open-loop architecture prevents the system from perceiving and understanding execution-level errors, resulting in a loss of self-correction capabilities. ③ Inappropriate resource allocation: Static retry strategies do not distinguish between error types and severity, leading to ineffective consumption of computing resources. ④ Lack of learning capabilities: Stateless design prevents the system from accumulating experience, hindering continuous optimization and self-evolution. These technical bottlenecks severely limit the practicality and reliability of intelligent function call systems in production environments, necessitating an innovative technical solution to overcome the limitations of the existing architecture.

[0020] Therefore, this application provides an intelligent function call method and system with error self-correction capabilities, constructing a bidirectional feedback control loop between the task scheduling layer and the large language model. The system comprises four core components: error analysis, knowledge retrieval, hierarchical correction, and execution retry.

[0021] Specifically, when a call instruction generated by the large language model fails in the actual execution environment, the system no longer simply throws an exception or blindly performs mechanical retries. Instead, this application first transforms the underlying program error into a machine-understandable structured description through semantic analysis; then, it prioritizes searching the historical experience base to find verified solutions for similar errors; if no historical experience is available, a hierarchical correction strategy is initiated, guiding the large language model to gradually attempt repair from three dimensions—"fine-tuning parameters," "replacing tool components," and "reconstructing execution strategies"—based on the severity and type characteristics of the error. This process achieves an unmanned closed loop from error perception to automatic healing, and avoids invalid retries through an intelligent circuit breaker mechanism, significantly improving the robustness and task success rate of the intelligent system in complex environments.

[0022] Solution principle: 1. Addressing the vulnerability of calls caused by model "illusion": A "structured semantic verification and mapping" mechanism is adopted. Unlike related technologies that passively accept the output of large models, this application introduces an active verification mechanism at the execution layer: the system does not directly regard execution failure as the end point, but uses an error analyzer to act as a "translator." This component captures unstructured exception information thrown by the underlying runtime and maps ambiguous "illusion" errors into deterministic structured error objects through pattern matching and feature extraction techniques. This structuring process includes: ① Error type classification: identifying whether the error belongs to a parameter type problem, parameter value problem, component non-existence problem, or logical conflict problem; ② Severity level assessment: assessing the severity level of the error based on the error type and the number of historical attempts; ③ Repairability determination: analyzing whether the error has the feasibility of automatic correction; ④ Correction suggestion generation: for repairable errors, extracting key error features for subsequent correction decisions.

[0023] Results: It can accurately identify the specific types and characteristics of "illusions," thereby constraining the uncertain output of large models within a controllable semantic framework. This proactive error structuring provides accurate "targets" for subsequent intelligent correction, enabling targeted correction operations.

[0024] 2. Addressing the rigidity of exception handling caused by "open-loop" control: A "closed-loop exception semantic feedback" mechanism is adopted. To address the open-loop defect of existing systems that "kill without burying," this application constructs an information feedback mechanism: the system re-encapsulates structured error information, original user intent, failed call parameters, and execution environment context, constructing a correction prompt text containing "error context." The core of this mechanism lies in converting low-level program errors into natural language descriptions that the large model can understand, and feeding them back to the decision-making layer of the large model through specific prompting engineering techniques. The construction of feedback information follows these principles: ① Preserving the user's original intent: ensuring that the corrected solution still meets the user's actual needs; ② Providing error context: clearly stating which component, which action, and which parameters failed during execution; ③ Adding error diagnosis: including semantic descriptions of error type and cause; ④ Providing correction direction: hinting at the correction dimensions that the large model should focus on based on the error type.

[0025] Effects: This mechanism establishes a two-way information link from the "execution end" to the "decision-making end," enabling large models to "perceive" the execution effects of their generated instructions and perform logical reasoning and parameter adjustments based on feedback information. The system implements a closed-loop debugging process similar to that of human developers: "write—run—report errors—modify—retry," transforming the one-way "command issuance" into a two-way "collaborative optimization."

[0026] 3. Addressing the issue of blind retries due to a lack of layered strategies: A multi-level, progressive adaptive correction mechanism is adopted. To address resource waste and blind retries, this application abandons the flat retry logic and designs a layered processing mechanism: The system dynamically selects the depth of the repair strategy based on the severity and type of the error: Level 1 (Shallow Correction): For simple parameter errors, only the large model is requested to correct the parameter values, keeping the call chain unchanged (low cost, fast response); Level 2 (Medium Correction): For errors where components or actions are unavailable, the large model is requested to recommend alternative components or actions (medium cost); Level 3 (Deep Correction): For logical fallacies or continuous correction failures, the large model is requested to overturn the original plan and re-plan the execution strategy (high cost).

[0027] Results: This layered, progressive strategy achieves optimal allocation of computing resources. The system avoids using expensive global inference to solve simple parameter spelling errors, while also being able to handle complex logical errors. Through intelligent hierarchical selection and upgrade mechanisms, the system achieves an optimal balance between correction success rate and resource consumption. Furthermore, the system integrates an intelligent circuit breaker mechanism, identifying recurring error patterns through error signature identification. When the same error is detected to occur consecutively to a threshold (usually 3 times), the system automatically truncates the retry chain, avoiding getting stuck in an invalid infinite loop, and provides the user with user-friendly degradation suggestions.

[0028] 4. Addressing the "forgetfulness" problem due to a lack of experiential memory: This application employs feature-matching-based experience reuse. To address the repetitive computation problem in stateless systems, a long-term memory mechanism is introduced: the system establishes a persistent experiential knowledge base. Whenever a loop closure is successfully corrected, the system automatically extracts the error signature and the corresponding successful correction solution and stores them in the knowledge base. In subsequent tasks, once a similar error signature is detected, the system prioritizes directly retrieving the correction solution from the knowledge base, skipping the large model inference step.

[0029] Results: This mechanism endows the system with the ability to learn by analogy. As the system's runtime increases, the coverage of the knowledge base gradually improves, and more and more common errors can be quickly identified and corrected. The system's average response time and the number of large model calls will be significantly reduced, achieving an intelligent evolution from "computation-intensive" to "retrieval-intensive." More importantly, the knowledge base has cross-task versatility. A user's successful experience accumulated in a specific scenario can be applied to subsequent similar scenarios, forming a positive feedback loop of "the more you use it, the faster and more accurate it becomes."

[0030] 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 skilled in the art without creative effort are within the scope of protection of this application.

[0031] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] In one exemplary embodiment, a smart function call method with error self-correction capability is provided, including the following steps S1 to S7. Wherein: Step S1: Obtain the task requirement text described by the user in natural language, and determine the function call information based on the task requirement text; the function call information includes the target component identifier, operation action type, and call parameter dictionary.

[0033] Step S2: Verify the function call information, and execute the function call information after successful verification.

[0034] Step S3: If verification fails or an exception is thrown when executing function call information, capture the verification failure information or exception information and generate structured error description information; the structured error description information includes error type, severity level, corrective flag, error signature, number of attempts and historical attempt records.

[0035] Step S4: Based on the corrective tag, query the experience knowledge base using the error feature signature as the key to obtain the reusable correction result; the experience knowledge base includes the error feature signature and the corresponding historical successful correction information; the historical successful correction information includes the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary.

[0036] Step S5: If the reusability correction result indicates the existence of historical successful correction information, then the corresponding historical successful correction information is directly used as the correction function call information.

[0037] Step S6: If the reusability correction result is that there is no historical successful correction information, then based on the structured error description information, correction function call information is generated through a multi-level correction strategy; the multi-level correction strategy includes parameter fine-tuning strategy, component or action replacement strategy, and function call information reconstruction strategy.

[0038] Step S7: Use the corrected function call information as the function call information, and return to step "Based on the function call information, obtain the verification result through a preset verification method, and execute the function call information when the verification result is passed", until the function call information is successfully executed or the circuit breaker condition is triggered; the circuit breaker condition includes the cumulative number of occurrences of the same error signature reaching a preset threshold.

[0039] By implementing steps S1 to S7 above, this application can automatically capture and structurally analyze error information when function call execution fails, realize the rapid reuse of historical correction schemes through an experience knowledge base, or perform layered repair for different types of errors through a multi-level correction strategy, thereby effectively improving the success rate of task execution and the robustness of the system, and realizing the self-evolution and continuous optimization of the intelligent function call system.

[0040] In another exemplary embodiment of this application, step S2 is further included prior to: The experience knowledge base is queried using the target component identifier and operation action type as keys. The retrieved historical task requirement texts and historical successful correction information are added to the preventive correction scheme set. The experience knowledge base also includes historical target component identifiers, historical operation action types, historical task requirement texts, and corresponding historical successful correction information.

[0041] If the set of preventive correction schemes is not empty, then calculate the semantic similarity between the task requirement text and each historical task requirement text in the set of preventive correction schemes to obtain the semantic similarity set.

[0042] If the highest semantic similarity in the semantic similarity set exceeds the preset similarity threshold, the function call information is updated using the historical successful correction information corresponding to the highest semantic similarity.

[0043] If the set of preventive correction schemes is empty, or the highest semantic similarity in the set of semantic similarities does not exceed the preset similarity threshold, then the function call information remains unchanged.

[0044] In another exemplary embodiment of this application, step S2, which verifies the function call information, specifically includes: Step 201: Verify the function call information according to the following steps using a preset verification method; the preset verification method includes existence verification, availability verification, integrity verification, and legality verification.

[0045] Step 201-1: Perform an existence verification on the target component identifier in the function call information to obtain the existence verification result; the existence verification is used to verify whether the target component identifier exists in the preset system component registry; the preset system component registry is used to store the mapping relationship between the component identifiers of registered components and component instances.

[0046] Step 201-2: If the existence verification result is yes, then obtain the component instance corresponding to the target component identifier according to the preset system component registry, and perform availability verification on the operation action type to obtain the availability verification result; the availability verification is used to verify whether the component instance supports the operation action type.

[0047] Step 201-3: If the availability verification result is yes, then perform integrity verification on the call parameter dictionary to obtain the integrity verification result; the integrity verification is used to verify whether the call parameter dictionary contains all the necessary parameters required for the operation action type.

[0048] Step 201-4: If the integrity verification result is yes, then perform a validity verification on each parameter in the call parameter dictionary to obtain a validity verification result; the validity verification is used to verify whether each parameter meets the parameter signature constraints of the operation action type; the parameter signature constraints include the parameter value type, value range and format specification.

[0049] Step 202: If the existence verification result, availability verification result, integrity verification result, or legality verification result are all yes, then the verification is successful.

[0050] Step 203: If any of the existence verification result, availability verification result, integrity verification result, or legality verification result is negative, the verification fails.

[0051] In another exemplary embodiment of this application, step S3, which involves capturing verification failure information or exception information and generating structured error description information, specifically includes: Step 301: Classify errors based on verification failure information or exception information to obtain error types; the error types include parameter-level errors, component-level errors, logic-level errors, or unknown type errors.

[0052] Step 302: Based on the error type and the number of attempts, obtain the severity level using a severity assessment method; the severity assessment method includes determining a baseline severity based on the error type; calculating an attempt penalty based on the number of attempts; adding the baseline severity to the attempt penalty to obtain a comprehensive severity; and determining the severity level based on the comprehensive severity; the severity level includes minor, moderate, severe, and fatal.

[0053] Step 303: Based on the error type and the severity, obtain a repairability flag using a repairability determination method; the repairability determination method includes: if the severity level is not fatal and the error type belongs to a preset set of repairable errors, then it is determined to be repairable; if the severity level is fatal, or the error type does not belong to the preset set of repairable errors, then it is determined to be unrepairable; the preset set of repairable errors includes parameter-level errors and component-level errors.

[0054] Step 304: Based on the key error features, construct a feature string and perform normalization processing to generate an error feature signature; the key error features include target component identifier, operation action type, error type, error parameter name, and error message keywords; the normalization processing includes converting to lowercase, removing special characters, and sorting by alphabetical order.

[0055] In another exemplary embodiment of this application, step S4 specifically includes: Step 401: If the corrective flag is correctable, then query the experience knowledge base using the error feature signature as the key, and add the historical successful correction information obtained from the query to the reuse candidate scheme set.

[0056] Step 402: If the set of reuse candidate solutions is not empty, the reuse correction result is that there is historical successful correction information, and the historical successful correction information with the highest number of successful applications in the set of reuse candidate solutions is used as the correction function call information.

[0057] Step 403: If the set of candidate reuse schemes is empty, the edit distance algorithm is used to calculate the signature similarity between the error feature signature and each historical error feature signature in the experience knowledge base, and the historical successful correction information corresponding to the signature similarity exceeding the preset signature similarity threshold is added to the set of similar candidate schemes.

[0058] Step 404: If the set of similar candidate schemes is not empty, the reusability correction result is that there is historical successful correction information, and the historical successful correction information corresponding to the highest signature similarity in the set of similar candidate schemes is used as the correction function call information.

[0059] Step 405: If the repairability is marked as unrepairable, or the set of similar candidate solutions is empty, then the reusability correction result is that there is no historical successful correction information.

[0060] In another exemplary embodiment of this application, step S6 specifically includes: Step 601: Determine the target correction level based on the error type and number of attempts in the structured error description information; the target correction level includes a first level, a second level, and a third level.

[0061] Step 602: When the target correction level is the first level, a parameter fine-tuning strategy is adopted; the parameter fine-tuning strategy includes keeping the target component identifier and operation action type unchanged, correcting the call parameter dictionary based on the error type and error description according to the large language model, generating a corrected call parameter dictionary, and using the target component identifier, operation action type and corrected call parameter dictionary as correction function call information.

[0062] Step 603: When the target correction level is the second level, a component or action replacement strategy is adopted. The component or action replacement strategy includes calculating the cosine similarity between the task requirement text and the functional descriptions of all available components from the preset system component registry, selecting the component or action corresponding to the highest cosine similarity as the corrected target component identifier and the corrected operation action type; adjusting the call parameter dictionary accordingly based on the corrected target component identifier and the corrected operation action type to obtain the corrected call parameter dictionary; and using the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary as the correction function call information.

[0063] Step 604: When the target correction level is the third level, a function call information reconstruction strategy is adopted. The function call information reconstruction strategy includes replanning the execution path based on historical attempt records, task requirement text, and preset system component registry through a large language model, generating a reconstruction target component identifier, reconstruction operation action type, and reconstruction call parameter dictionary, and using the reconstruction target component identifier, reconstruction operation action type, and reconstruction call parameter dictionary as correction function call information. The historical attempt records include the target component identifier, operation action type, call parameter dictionary, and failure reason for each attempt.

[0064] In another exemplary embodiment of this application, step 601 specifically includes: Step 601-1: If the error type is a parameter-level error and the number of attempts is less than or equal to the first attempt threshold, then the target correction level is determined to be the first level; the parameter-level error includes parameter name error, parameter value error, type error, or parameter missing error.

[0065] Step 601-2: If the error type is a parameter-level error, and the number of attempts is greater than the first attempt threshold and less than or equal to the second attempt threshold, or the error type is a component-level error, then the target correction level is determined to be the second level; the component-level error includes errors such as component non-existence or action not supported.

[0066] Step 601-3: If the error type is a logical error, or the error type is an unknown type error, or the number of attempts is greater than the second attempt threshold, then the target correction level is determined to be the third level; the logical error includes business logic conflict error, precondition failure error, or calculation abnormality error.

[0067] In another exemplary embodiment of this application, the method for updating and maintaining the experience knowledge base specifically includes: After the correction function call information is executed successfully, query the experience knowledge base to see if there is an error signature before the execution of the correction function call information.

[0068] If it already exists, update the number of successful applications and the last time of use corresponding to the error signature before executing the correction function call information.

[0069] If it does not exist, then determine whether the current capacity of the experience knowledge base is less than the preset capacity threshold.

[0070] If the current capacity is less than the preset capacity threshold, the error signature before executing the correction function call information, the target component identifier in the correction function call information, the operation action type, and the call parameter dictionary will be directly added to the experience knowledge base as new historical successful correction information.

[0071] If the current capacity is greater than or equal to the preset capacity threshold, then first delete the historical successful correction information that has not been used for a preset number of days and has a success count lower than the preset success count threshold, and then add the error signature before executing the correction function call information, the target component identifier in the correction function call information, the operation action type and the call parameter dictionary as new historical successful correction information to the experience knowledge base.

[0072] In another exemplary embodiment of this application, after triggering the circuit breaker condition in step S7, the method further includes: generating a user-friendly prompt message to provide feedback to the user; the user-friendly prompt message includes a failure reason explanation generated based on the error type; an attempt history summary generated based on the number of attempts and historical attempt records; similar historical successful correction information obtained by querying an experience knowledge base based on the task requirement text; and a next step operation suggestion generated based on the error type and similar historical successful correction information.

[0073] The following example illustrates this application using a specific intelligent function call process with error self-correction capabilities.

[0074] This application adopts a layered modular architecture design, constructing the intelligent function call system as a closed-loop system with self-awareness, self-analysis, self-correction, and self-learning capabilities. The overall architecture comprises five core functional modules that work collaboratively through standardized interfaces to achieve a complete closed-loop process from error capture to intelligent correction. The core idea of ​​this invention is to establish a closed-loop feedback mechanism of "perception-analysis-decision-execution-learning." Unlike the traditional unidirectional linear execution process (user input → intent parsing → task execution → return result), this application establishes a bidirectional information channel between the execution layer and the decision-making layer, enabling the execution result to influence the decision-making process in reverse, forming a continuously optimizing cycle.

[0075] Key innovations include: ① Perception capability: Through structured error analysis, the system can understand the reasons for execution failure; ② Decision-making capability: Utilizing the reasoning ability of a large language model, the system can think about how to correct errors; ③ Learning capability: Through an experience knowledge base, the system can memorize successful correction schemes; ④ Evolutionary capability: With increased usage, the system performance continues to improve.

[0076] like Figure 1 As shown, a data flow diagram of an intelligent function call method with error self-correction capability is provided. The system architecture of this application adopts a layered collaborative approach, forming a forward data flow from the user layer to the execution layer, and a feedback data flow from the execution layer to the correction layer. The experience knowledge base serves the entire system horizontally. The core feature of this architecture is the establishment of a two-way information channel between the execution layer and the decision layer, enabling error information after execution failure to trigger a series of intelligent analysis and correction processes, ultimately forming a closed loop.

[0077] Data flows through the system following these paths: Forward flow: User input → Intent parsing → Instruction execution → Function execution → Result output; Feedback flow: Execution exception → Error analysis → Correction decision → New instruction execution → Re-execution; Knowledge flow: Correction success → Experience storage → Subsequent retrieval → Rapid application.

[0078] This application comprises five core modules and their interaction relationships are as follows: Module 1: Error Semantic Analysis Module. Input: Raw exception object, execution context (component, action, parameters, user intent, number of attempts); Output: Structured error object (including error type, severity, repairability, suggestions, etc.); Interaction: Receives exceptions from the execution layer and outputs them to the retry management and circuit breaker module.

[0079] Module 2: Intelligent Correction Decision Module. Input: Structured error objects, information on available system components; Output: Correction result objects (including corrected components, actions, parameters, and confidence levels); Interaction: Receives structured errors from the error analysis module, interacts with the experience knowledge base module to obtain historical solutions, and outputs them to the feedback coordination and control module.

[0080] Module 3: Experience Knowledge Base Module. Input: Error pattern query request, successful correction solution storage request; Output: Matched historical correction solutions, similar successful cases; Interaction: Called by the intelligent correction decision module and feedback coordination control module to provide historical experience support.

[0081] Module 4: Retry Management and Circuit Breaker Module. Input: Structured error object, current retry status; Output: Retry decision (whether to continue, which level to use, delay time), circuit breaker signal; Interaction: Receive error analysis results, control the pace and termination conditions of the entire correction process.

[0082] Module 5: Feedback Coordination and Control Module. Input: User intent, initial execution command; Output: Final task execution result (success or failure); Interaction: Coordinates all other modules to achieve a complete closed-loop process.

[0083] The five modules form a close collaborative relationship. The execution coordination module acts as a central scheduler, detects problems through the error analysis module, controls the pace through the retry management module, generates solutions through the intelligent correction module, and reuses historical experience through the experience knowledge base module, ultimately forming a self-optimizing closed-loop system.

[0084] The complete workflow of this application can be divided into seven main stages, forming a cycle of "execution-feedback-correction-re-execution": Phase 1: User Intent Parsing. The system's feedback coordination and control module receives the user's natural language input and uses a large language model for semantic understanding. The parsing process includes: identifying the user's core needs and operational goals, extracting key entity and parameter information, mapping them to specific components and operational actions in the system, and generating structured call instruction triples (target component identifier, operation action type, and call parameter dictionary).

[0085] Phase Two: Knowledge Base Pre-Search Optimization. Before actually executing the invocation command, the system prioritizes querying the experience knowledge base. The retrieval strategies include: semantic similarity matching based on user intent, precise matching based on components and actions, and preventative application of known high-frequency error correction schemes (module name, action name, error type, error signature, successful correction scheme, corrected module, corrected action, corrected parameters, number of successful applications of the correction scheme, and last usage time). This step significantly improves the success rate of the first execution and avoids repeating known errors.

[0086] Phase Three: Task Execution and Error Capture. Based on the parsed call instructions, the system follows a strict verification-execution process: component existence verification → action availability verification → parameter integrity verification → parameter validity verification → business logic execution. If an error occurs at any stage, the system will capture complete exception information.

[0087] As an optional implementation method, the specific details are as follows: First layer: Component existence verification. Verification content: Check whether the corresponding module is a system component. Verification logic: Look up its key value in the dictionary of the module registry and return a boolean value: True (exists) / False (does not exist).

[0088] Second layer: Component instance acquisition. Verification content: Attempt to load the component instance from the registry. Verification logic: Call the module's initialization method to instantiate the component; check if the instantiation was successful; verify if the instance conforms to the module's interface specification.

[0089] Third layer: Action support validation. Validation content: Check if the action name is in the component instance's supported action list. Validation logic: Query the module's action dictionary; check if the action is a registered action; return a boolean value.

[0090] The fourth layer: Parameter integrity and validity verification. This includes multiple sub-checks: Sub-check 1: Required parameter check: Obtain the list of required parameters for the action; check if the parameter list contains all required parameters. Sub-check 2: Parameter type check: Check if the actual type of each parameter conforms to the definition. Sub-check 3: Parameter value range check: Check if the parameter value is within the valid range. Sub-check 4: Parameter value validity check: Check if the parameter value meets the business rules. This business rule is situational; numbers that are impossible in this business logic are not satisfied, such as a division calculation where the denominator cannot be 0. Sub-check 5: Parameter combination logic check: Check the logical relationship between multiple parameters.

[0091] Phase Four: Error Semantic Analysis and Structuring. Upon capturing complete exception information, the system does not immediately report an error to the user. Instead, it initiates a deep error semantic analysis process: error classification, severity assessment, repairability determination, semantic transformation, and context encapsulation. The output structured error object provides a complete information foundation for subsequent corrective decisions.

[0092] As an optional implementation method, the analysis process proposed above is as follows: (1) Error classification algorithm. Classification basis: A two-layer classification strategy of "abnormal type feature matching + error message pattern recognition" is adopted.

[0093] First-level classification: direct mapping based on exception type.

[0094] The system first performs a preliminary classification based on the types of exceptions thrown during program execution. Mapping functions are then defined. ,in A collection of exception types, This is a set of error types. Example mapping rules: Type error exception → parameter type mismatch; Value range error exception → parameter value out of valid range; Missing key exception → required parameter missing; Missing attribute exception → component does not exist or is unavailable.

[0095] Second-level classification: Pattern recognition based on error messages.

[0096] When the first-level classification cannot accurately determine the category, the system refines the classification by performing pattern matching on the error message text. Define the pattern matching function: .

[0097] in: This is the error message string; A predefined error mode library; For pattern-type pairs, It's a regular expression. This corresponds to the error type; This is a regular expression matching function; If the collection is traversed If none of the patterns in the test pattern are matched, an unknown error type is returned.

[0098] The error type system defines nine basic error types: Parameter name error: The parameter name is misspelled or not recognized; Parameter value error: The parameter value is not within the expected range; Type error: The parameter type does not match the function definition; Missing parameters: Required input parameters are missing; Module error: The target module does not exist or is not registered; Action error: The specified action is not supported in this module; Runtime error: Other runtime exceptions that occur during execution; Logical errors: Business logic conflicts (such as division by zero, date reversal, etc.); Unknown error: Other errors that cannot be identified.

[0099] The complete process of a classification algorithm: .

[0100] in, For the original exception object, Extract its error message text. The condition is: if If the returned result is not unknown, then the result is directly adopted. This represents the "type-first" strategy.

[0101] (2) Severity assessment algorithm. Assessment principle: Error severity is not statically fixed, but dynamically adjusted with the number of retries. The basic idea is: for the same type of error, if it is not resolved after multiple attempts, its severity should be increased.

[0102] Severity rating function: .

[0103] in, Severity level; Error type; This represents the current number of attempts. The threshold for the number of occurrences (default is 4); This is the baseline severity based on the error type.

[0104] Baseline severity mapping: .

[0105] Severity level definition: Minor: The cause of the error is clear, the direction of correction is clear, the success rate of correction is high, and shallow correction is applicable; Moderate: Requires some semantic understanding, may require component replacement, the success rate of correction is moderate, and mid-level correction is required; Critical: The success rate of automatic correction is low, may require strategy refactoring, and deep correction or manual intervention is required; Fatal: Cannot be resolved by automatic correction and manual intervention is required.

[0106] Design rationale: Initially, a baseline assessment is provided based on the error type, reflecting the inherent difficulty of repairing that type of error; as the number of attempts increases, even simple errors will escalate into critical errors, triggering stronger correction strategies or circuit breaker protection; this dynamic assessment mechanism avoids the system getting bogged down in ineffective and repeated corrections of the same error.

[0107] (3) Corrective determination algorithm. Not all errors are suitable for automatic correction. The system needs to determine whether the error is feasible for automatic correction before attempting to correct it.

[0108] Decision function: .

[0109] in: This is a corrective assessment result; Error type; Severity level; This is a set of repairable error types.

[0110] Set of fixable errors: .

[0111] Judgment rules: Forced exclusion rule: Errors of any fatal level cannot be automatically repaired, regardless of their type; Type inclusion rule: Error types belonging to the repairable set can usually be repaired; Fallback rule: Errors that do not meet the above conditions are unrepairable by default.

[0112] Special Note: Although a module may be considered severe if it does not exist, it can be "fixed" in some cases by recommending alternative modules (actually, the target is changed); if an action is not supported, it can be fixed by recommending other actions of that module.

[0113] (4) Semantic conversion process. Conversion purpose: to convert the underlying, technical exception stack into a natural language description that can be understood by a large language model.

[0114] Conversion function: .

[0115] in: The original exception object; For the execution context (including module, action, parameters, user intent); Error type; Severity level; A semantic error description; To revise the recommendations.

[0116] Semantic description generation: For each error type, the system maintains a mapping table from technical description to semantic description. For example: Technical description: "TypeError: unsupported operand type(s) for+: 'int' and 'str'". Semantic description: "Parameter type mismatch: Attempt to perform an operation on an integer and a string."

[0117] (5) Context encapsulation process. Encapsulation purpose: to integrate scattered error information with the execution context to form a complete structured error object.

[0118] Structured error object definition: .

[0119] in, Error type; A semantic error description; Severity level; The name of the failed module; The name of the failed action; This is the set of parameters to be used in case of failure. For the user's original intent; This represents the current number of attempts. The original exception object; This is a corrective assessment result; To revise the recommendations.

[0120] Encapsulation algorithm: Given the original exception and execution context The encapsulation process is as follows: Error classification: Severity level assessment: Repairability assessment: Semantic conversion: Object construction: .

[0121] The value of encapsulation: Structured error objects provide a unified information interface for subsequent decision-making, enabling modules such as retry management, correction engine, and knowledge base to process based on standardized data structures without having to repeatedly parse the original exception.

[0122] Phase 5: Correction Strategy Selection and Solution Generation. Based on the error analysis results, the system enters the intelligent correction decision-making process. First, it determines the correctability of the error, and then queries the experience knowledge base. If the knowledge base matches, the verified correction solution is applied directly; if the knowledge base does not match, intelligent correction based on a large language model is initiated, the correction strategy depth is selected according to the current retry level, and a new corrected invocation instruction is generated.

[0123] 1. Read the repairability assessment results generated in Phase 4.

[0124] 2. According to The value determines whether to enter the correction process: if It returns an error directly without attempting to correct it; if Continue with subsequent knowledge base queries and intelligent corrections.

[0125] Error mode signature definition: .

[0126] in: The name of the failed module (string); The name of the failed action (string); Error type (ErrorType).

[0127] Query algorithm: Define the knowledge base as a mapping ,in, Includes successful corrective measures.

[0128] Query process: .

[0129] If the query finds a match, the returned value is... Includes: the revised module name, the revised action name, the revised parameter set, and the number of times the solution has been successfully applied. Last usage time .

[0130] The specific process of intelligent correction based on the large language model: When the knowledge base is not matched, the system initiates an intelligent correction process based on the large language model. This is the core of the system's self-correction capability, generating a correction plan through AI's semantic understanding and reasoning abilities.

[0131] Based on the error type and the current retry level, the system selects a correction strategy of varying depth: Policy mapping function: .

[0132] in, , This is the current retry level; This represents the current number of attempts. This is the threshold for policy upgrades.

[0133] Strategy 1: Parameter Adjustment Applicable scenarios: Errors at the parameter level, where the root cause lies in the parameter's name, type, value, or absence. Correction principle: Keep the calling module and action unchanged, only adjust the parameters.

[0134] Prompt word construction: The system builds structured and corrected prompt words. Input to the large language model: .

[0135] in, This indicates a template filling operation. This is a template for parameter correction tasks. Its structure is as follows: ① Original User Intent ② Current invocation configuration: , ,parameter ;③No. Execution failed: Error type and error description .

[0136] The large language model returns a formatted correction scheme, namely: .

[0137] in, This is the revised parameter dictionary; The adjusted confidence level; A natural language description of the reasons for the correction.

[0138] Strategy 2: Module Switching Applicable scenarios: When the target module does not exist or is unavailable, and a similar functional alternative module needs to be found. Correction principle: Analyze user intent and search for an alternative module that can achieve the same or similar functionality within the set of available modules.

[0139] Available module information for construction: First, the system compiles the capability descriptions of all currently available modules: .

[0140] in, Let i be the name of the i-th available module; This describes the functionality of the i-th available module. This is the set of actions supported by the i-th available module; This indicates the total number of available modules.

[0141] Prompt word construction: .

[0142] Template structure: Original user requirements Failed module (This module does not exist or is unavailable); List of currently available modules in the system: , , .

[0143] Strategy 3: Action Switching ( Applicable scenario: The module is available, but the specified action is not supported by the module. Correction principle: Find a similar alternative action within the set of actions supported by the module.

[0144] Prompt word construction: .

[0145] in, For module All supported actions and their descriptions, The task template recommended for the action is structured as follows: original user requirements, target module, and failed actions. (This action is not supported), List of actions supported by the target module: Action name for each action. Function description and parameter list.

[0146] Large model output: .

[0147] in, It is an optional, similar alternative action, that is, from The closest one selected The function's actions. The large model will be based on the original user needs I, The functions, and The functional descriptions of each action are used to select the closest alternative through semantic similarity calculation, while adjusting... To adapt to the new actions.

[0148] Strategy 4: Strategy Restructuring Applicable scenario: If all the aforementioned strategies fail, or if too many retries are attempted, it indicates a possible misunderstanding of user needs. Correction principle: Reanalyze user needs, discard the original execution path, and generate a completely new execution strategy.

[0149] The system organizes information from all historical attempts. : .

[0150] in, Indicates the first The module, action, parameters, and reason for failure of the first attempt.

[0151] Prompt word construction: .

[0152] in, The task template was restructured for the strategy, with the following structure: Original User Intent Historical attempts to record .

[0153] Analysis: After All attempts failed, which may be due to a misunderstanding of the requirements.

[0154] Available modules in the system: .

[0155] Large model output: .

[0156] in, For a completely new call configuration; These are optional alternatives or task breakdown suggestions; The confidence level for correction is usually low (because it is a deep reconstruction, which has higher uncertainty).

[0157] Phase Six: Retrying Execution and Dynamic Adjustment. After applying the corrected solution, the system re-enters the execution process. If the execution is successful after correction, the complete process of this correction is recorded, and the successful correction solution is stored in the experience knowledge base; if the execution still fails after correction, new error information is captured for a new round of error analysis. This phase forms an iterative cycle of "execution → analysis → correction → re-execution".

[0158] Phase Seven: Results Feedback and Experience Accumulation. Regardless of whether the task ultimately succeeds or fails, the system will summarize the experience. When a task succeeds, a user-friendly explanation of the result is generated, corrective actions are recorded as success stories, and the experience knowledge base is updated. When a task fails, a detailed error report is generated, similar historical success stories are retrieved for reference and suggestions, and user-friendly error messages are returned to the user.

[0159] I. Error Semantic Analysis Module: This is the perception layer and starting point of the entire self-correction mechanism. The core responsibility of this module is to transform the unstructured, technical exception information generated during the runtime of the underlying program into structured, semantic error objects that can be understood and reasoned about by the upper-level large language model.

[0160] The core idea of ​​this module is "semantic interpretation and intelligent understanding of errors." It achieves the leap from "machine error reporting" to "semantic understanding" through three layers of processing: classification layer (establishing a unified error classification system), evaluation layer (conducting multi-dimensional evaluation), and conversion layer (converting to natural language description and attaching context).

[0161] like Figure 2 As shown, the error semantic analysis module adopts a seven-step pipeline processing architecture, which gradually transforms the original exception object into a structured error object rich in semantic information. The entire processing flow starts with a coarse-grained initial judgment of the exception type, goes through pattern matching, precise type localization, multi-dimensional evaluation (severity and repairability), and finally generates a complete error description that can be understood and reasoned by a large language model through semantic transformation and context encapsulation.

[0162] (1) The input and output of the error semantic analysis module and its relationship with the module.

[0163] Input information: original exception object (exception type, error message, stack trace, source module: feedback coordination and control module), execution context information (failed component, action, parameters, user intent, number of attempts, source module: feedback coordination and control module).

[0164] Output information: A structured error object containing complete information such as error type, error description, severity, fixability, and suggested fixes.

[0165] Receive module: Retry management and circuit breaker module (for retry decision-making); Intelligent correction decision-making module (for generating correction schemes).

[0166] Module Relationship: Called by the feedback coordination and control module, it receives exceptions from the function execution layer; the output is passed to the retry management module and the intelligent correction decision module.

[0167] (2) Error Classification System. This application establishes a complete and hierarchical error classification system, systematically summarizing various errors that may occur during program execution into four categories: ① Parameter-level errors, including parameter type errors (data type does not match function definition), parameter value range errors (parameter value exceeds the valid range), parameter missing errors (missing required parameters), and parameter naming errors (incorrect parameter name spelling or use of a non-existent parameter name). These errors are highly repairable and can usually be automatically corrected through type conversion, with the correction direction being parameter fine-tuning strategy. ② Component-level errors, including component non-existence errors (calling an unregistered or removed functional component), action unsupported errors (the specified component does not provide the requested operation action), and component initialization errors (the component's initialization process fails before execution). These errors are low to medium repairable; components cannot be created out of thin air, but alternative components with similar functions can be tried, with the correction direction being component replacement strategy. ③ Logic-level errors, including business logic conflicts (parameter combinations are legal individually but conflict in business semantics), unmet preconditions (environmental conditions or dependent resources required for execution are unavailable), and calculation anomalies (arithmetic anomalies occurring during execution, such as division by zero or overflow). These types of errors have a medium to low fixability, requiring an understanding of the business semantics, and the direction of correction should be chosen based on the specific circumstances. ④ Unknown type errors are used to handle abnormal situations that the system cannot identify or classify. They usually require more in-depth manual analysis, and the system will record them for subsequent model training and rule optimization.

[0168] Through this complete classification system, the system can accurately classify more than 99% of common errors, providing clear guidance for subsequent intelligent correction.

[0169] (3) Error analysis core algorithm.

[0170] ① Error message pattern matching algorithm: This is the core step in error analysis. It accurately identifies the error type by performing feature matching within a predefined error pattern library. The system maintains an error pattern library. Each mode Includes a set of characteristic keywords Corresponding error types Severity baseline Restorative markings .

[0171] Let the error message be First, it is preprocessed: converted to lowercase and segmented to obtain a word set. Remove stop words and punctuation. Calculate the matching score for the j-th model. : .

[0172] This score indicates the proportion of characteristic keywords for that pattern contained in the error message. Select the pattern with the highest score: .

[0173] if If a custom threshold is set, the classification result of that mode will be used. If the score is insufficient, the initial judgment result will be retained and a conservative correctability setting will be applied.

[0174] ② Severity rating algorithm. The severity of an error depends not only on the error type itself, but also on the history of attempted corrections. If an error has been repeatedly and unsuccessfully corrected, its severity should be increased.

[0175] Final severity score : .

[0176] in, It is based on the base severity of the error type (from pattern matching). This is a severity penalty based on the number of attempts. The attempt penalty is calculated as follows: .

[0177] in, This is the current number of attempts. The design philosophy of this formula is: no penalty for the first attempt, a slight penalty (+0.25) for the second attempt, a moderate penalty (+0.5) for the third attempt, and a severe penalty (+0.75 maximum) for the fourth attempt and beyond.

[0178] Based on the final severity score, it is divided into four levels: LOW (0-0.25), MEDIUM (0.25-0.5), HIGH (0.5-0.75), and CRITICAL (0.75-1.0). This dynamic adjustment mechanism ensures that the system does not waste too many resources on an unsolvable error.

[0179] ③ Repairability determination algorithm. Based on rule-based reasoning: fatal errors are unrepairable; parameter-related errors are repairable; component-related errors can be addressed by trying alternative solutions; logical conflicts are judged based on severity; unknown types are queried using historical statistics.

[0180] For unknown types, consult the experience knowledge base to obtain historical correction success rates. : .

[0181] in, Number of successful type error repairs This represents the total number of bug fixes.

[0182] like If so, it is determined to be repairable.

[0183] ④ Semantic conversion algorithm.

[0184] Conversion strategy: Extract core information → Apply conversion template → Populate context → Add explanations → Provide suggestions.

[0185] Taking the intelligent diagnostic scenario of a vision testing device as an example, the specific operation flow and calculation process of the above seven stages are as follows: User input example: "Please generate a vision screening diagnosis report. The patient is 12 years old, with visual acuity of 0.8 in both eyes."

[0186] Intent parsing module: The system converts natural language into function call instructions. The parsed target component is AdolescentVisionEvaluator (a component for assessing adolescent vision), the action type is generate a report, and the parameter dictionary is {"age":"12","left_vision":"0.8","right_vision":"0.8"}.

[0187] The execution verification module verifies the call information. Existence and availability verifications pass. During parameter validity verification, the system finds that `left_vision` and `right_vision` are strictly defined as floating-point types in the component signature for numerical comparison, but the large model passes strings, causing verification to fail and throwing a type exception.

[0188] Error semantic analysis module: Captures the anomaly, classifies it as a "parameter-level error (Type Error)"; assesses the number of attempts as 1, determines the severity level as "minor"; and classifies it as "repairable". Then, it extracts key features and generates an error signature: AdolescentVisionEvaluator:generate_report:type_error.

[0189] Experience Knowledge Base Module: Query the knowledge base using the above signature as the key. Assuming this is the first time the system has encountered this error, the set of reuse candidate solutions is empty, and "No historical successful correction information exists" is returned.

[0190] Intelligent Correction Decision Module: Based on the severity level of "minor" and the first retry, the system adopts a first-level "parameter fine-tuning strategy". After receiving structured error feedback, the large model analyzes the parameter constraints and corrects the output, forcibly converting the parameter type to floating-point: {"age":"12","left_vision":"0.8","right_vision":"0.8"}.

[0191] Retry management and circuit breaker module: The call was re-initiated with the corrected parameters. All four verifications passed, and the business logic execution phase began. The component's built-in medical logic determined that for a 12-year-old child, a visual acuity of 0.8 is within the normal visual development range for that age group, and the warning for the adult normal visual acuity threshold of 1.0 was not triggered. Execution was successful, and the circuit breaker was not triggered.

[0192] Experience knowledge base update: The system has bound the correction strategy of "converting parameters from strings to floating-point numbers" to the feature signature and stored it persistently. The next time a similar error is encountered, the experience knowledge base module will directly hit and reuse it, skipping the large model inference stage.

[0193] The corrected execution result: The system successfully executed the call and output a professional diagnostic conclusion: "Visual acuity of 0.8 in both eyes, which meets the normal visual development standard for a 12-year-old child", and finally rendered a vision screening and diagnostic report with a clear hierarchical structure (the main title does not have a number prefix, and the sub-points retain number sequence numbers).

[0194] Example: The original error "invalid literal for int() with base 10:'abc'" is transformed into "Failed to convert the text 'abc' to an integer. The argument needs to be a valid integer (such as 123, -5, etc.), but the provided value 'abc' is not in numeric format. Recommendation: Please check if the argument value is correct, or check if the argument type matches."

[0195] a. The semantic markup process extracts the core information of the original exception object. The original exception object is a program exception thrown by Python at runtime, containing: the exception type (such as TypeError, ValueError, KeyError, etc.), the error message string (such as "invalid literal for int() with base 10:'abc'"), and the exception stack trace (call chain information). This information is a machine-oriented technical description, and the goal of semantic markup is to transform it into a natural language description oriented towards a large language model.

[0196] b. Semantic transformation extracts and generates the following six types of core information: Information 1: The root cause of the error, extracting the essential reason for the problem from the exception type and error message.

[0197] Extraction algorithm example: .

[0198] in, The pattern matching function for error messages (defined in the error classification algorithm).

[0199] Example: Original exception: TypeError: unsupported operand type(s) for+:'int' and 'str'.

[0200] The root cause of the error was: "Attempt to perform addition on an integer and a string, type mismatch". Message 2: Detailed description of the failed operation. Describe the specific operation the user attempted to perform, considering the execution context.

[0201] Describe the generation formula: .

[0202] The template format is as follows: When executing {User Intent I}, call {Action A} of {Module M}, using parameter {P}.

[0203] Information 3: Incorrect semantic interpretation. Convert technical error messages into natural language interpretations. Directly provide the technical error messages to the LLM (Local Language Module) to generate semantic interpretations.

[0204] Message 4: Detailed explanation of parameter issues. When the error involves parameters, provide a detailed explanation of the parameter problem.

[0205] Parameter problem description generation: for parameter set If the parameter If a problem exists, provide a parameter error description according to the error type.

[0206] Message 5: Suggested Correction Directions. Based on the error type, possible correction directions are provided. A custom template matching method is used to generate corresponding suggestions for each type. For example, a type error might generate "Check parameter types to ensure type matching," while a module error might generate "Try using other available modules," etc.

[0207] Information 6: Supplementary Context Information. Provides additional execution context information to help understand the scenario in which the error occurred.

[0208] Context information structure: .

[0209] in: The user's original intent (natural language string); The name of the failed module; The name of the failed action; Parameter configuration for failure; This represents the current number of attempts. To attempt to record history.

[0210] II. Intelligent Correction Decision Module. The Intelligent Correction Decision Module is the "brain" of the self-correcting system. Based on error analysis results, it utilizes the reasoning capabilities of the large language model to generate targeted correction solutions. The core value of this module lies in transforming error correction—a traditionally intellectual activity requiring human intervention—into a reasoning process that can be automatically completed by artificial intelligence. Through carefully designed prompting engineering techniques, the module converts structured error information and system states into reasoning tasks understandable by the large language model, and rigorously verifies and quality-controls the model's output.

[0211] The core idea of ​​this module is "layered progressive intelligent correction." This idea comprises three key elements: layering (dividing correction strategies into three levels based on the type and severity of the error, with each level corresponding to different correction depths and resource consumption); progressiveness (the correction process starts with the lightest strategy and gradually upgrades to a more robust strategy, only escalating to the next level after the current level's correction fails); and intelligence (unlike traditional rule-based correction, this module utilizes the semantic understanding and logical reasoning capabilities of a large language model to handle open-domain, semantic-level errors). The key innovation lies in expanding the large language model from a simple "intent parser" role to that of an "error diagnosis doctor" and a "correction solution designer."

[0212] like Figure 3As shown, the intelligent correction decision module adopts a four-stage processing flow of "pre-inspection-layering-decision-verification". This process first performs a repairability pre-inspection to quickly eliminate uncorrectable errors, then selects the corresponding correction strategy depth according to the current retry level, then achieves rapid reuse of correction solutions through querying the experience knowledge base, and if the knowledge base is not matched, intelligent reasoning based on a large language model is initiated, and finally the generated correction solution is verified in multiple dimensions to ensure its feasibility and effectiveness.

[0213] (1) The input and output of the intelligent correction decision module and its module relationship.

[0214] Input information: Structured error object (generated by the error semantic analysis module, containing complete error diagnosis information, source module: error semantic analysis module); System available component information (including a list of all registered components, a list of actions supported by each component, parameter signatures and function descriptions for each action, source module: component registry).

[0215] Output information: Correction result object, including correction success flag, correction strategy type, corrected component flag, corrected action flag, corrected parameter configuration, confidence level, correction reason, and possible alternatives. Receiving module: Feedback coordination and control module.

[0216] Relationships with other modules: Receives structured errors from the error analysis module, receives hierarchical instructions from the retry management module, collaborates with the experience knowledge base module to query historical solutions, and interacts with the large language model service for reasoning.

[0217] (2) Layered correction strategy system.

[0218] ① First level: Parameter fine-tuning strategy. Applicable scope: parameter type, value range, missing parameters, naming errors; Correction scope: only corrects parameter configuration, does not change components and actions; Correction targets: type conversion, value range adjustment, parameter supplementation, naming correction; Resource consumption: low.

[0219] Parametric Constraint Inference Algorithm: Let the parameter set be... Each parameter has constraints. Check for constraint violations: For each constraint violation, reason about a corrective solution: .

[0220] That is, to find a new value that is closest to the original value and satisfies the constraints.

[0221] ② Second level: Component replacement strategy. Applicable scope: Components do not exist, actions are not supported; Correction scope: Components and actions can be changed, and parameters can be adjusted to adapt to the new component; Correction target: Component replacement, action replacement, parameter adaptation; Resource consumption: Medium.

[0222] Similarity matching mechanism for component replacement: Similarity calculation formula: .

[0223] in, A semantic vector representing the user's intent. For components Semantic vectors describing the function; Let be the cosine similarity.

[0224] Component selection algorithm: Select the component with the highest similarity as the replacement. .

[0225] in, Indicates the highest similarity. This is the collection of all available components.

[0226] Threshold filtering: Only filters filters when the similarity exceeds a threshold. (usually set) A component is considered a viable alternative only when it achieves a 60% similarity. .

[0227] Semantic similarity matching algorithm: Define intent parsing function : .

[0228] in, This represents the user's natural language input. System prompts that contain formatting constraints. This indicates a context concatenation operation. This represents the temperature parameter during inference. This indicates a call to the large language model function, along with its parameters. This refers to a JSON extraction function that includes a regular expression fallback mechanism: .

[0229] Let the user intent semantic vector be... Components Functional description vector .

[0230] Similarity: .

[0231] Select the component with the highest similarity: .

[0232] like (For custom thresholds), this component is used as an alternative.

[0233] ③ Third level: Strategy restructuring strategy (avoiding repeated failures and guiding the direction of strategy restructuring). The following key data from the previous level needs to be referenced: Data 1: Historical attempt records, which record complete information about all previous attempts: Each record contains: For the first The module to be tried for the first time; For the first The action to be attempted for the first time; For the first The parameters to be tried next; For the first Error type and description for each attempt; For the first The level at which this attempt takes place.

[0234] Data 2: Results of parameter adjustments / component / action attempts from the previous step. This includes the set of parameter configurations tried and the component-action combinations tried. This is used when refactoring strategies to identify which parameter configurations and component / action combinations have been tried but failed, thus avoiding duplication of these configurations.

[0235] Data 3: Evolution sequence of error types across all levels. Trends in error type changes. Used to analyze whether errors are converging (error types gradually lessen, measured by the severity mentioned earlier) or diverging (error types become increasingly severe), guiding the strategy direction at the current level.

[0236] Data 4: Semantic information of user intent. The original user intent may differ from the previous understanding because it needs to be reinterpreted. By tracing back to the original intent, we can try entirely new perspectives for interpretation.

[0237] Data 5: Complete information on available resources. All available components and actions of the system; due to the need for a global perspective, previously unconsidered components may be selected. Applicable scope: Continuous correction of failures, fundamental logical fallacies; Correction scope: All variable, replanning execution paths; Correction goals: Reinterpreting intent, task decomposition, redesigning execution paths; Resource consumption: High.

[0238] Task decomposition algorithm: Let the original task be The goal is Decomposed into: .

[0239] Each subtask Must satisfy: atomicity ( It is a basic operation that can be completed by a single component, and it is executable (there is something in the system that can execute it). Components), dependencies ( The input can be The output forms an execution chain.

[0240] Detailed explanation of data reference relationships: Data required for the first-level strategy (parameter fine-tuning): Data source: the complete context of the current error; Specific data items: user's original intent (text), name of the currently failed component, name of the currently failed action, parameter configuration of the currently failed action, error message and error type, current number of attempts, and parameter constraints (obtained from system component information).

[0241] Data flow: Error semantic analysis module → Layered correction strategy system → Large language model correction inference mechanism.

[0242] The second-level strategy (component replacement) requires the following data: Data source: Results of the first-level attempts + system global information (specific content mentioned in the new data). Specific data items: Data inherited from the first level: original user intent, names of failed components (proving that the component is unavailable), set of parameter configurations tried (to avoid duplication), and new data: a list of all available components in the system, a functional description of each component, a list of actions supported by each component, and a semantic vector of the user intent (for semantic matching).

[0243] Data flow: First-level results + component registry → hierarchical correction strategy system → large language model correction inference mechanism.

[0244] The third-level strategy (strategy refactoring) requires the following data: Data source: Complete attempt history of the first two levels + user intent. Specific data items: Data 1 - Historical attempt record: Components, actions, parameters, error type and description of each attempt, and the level at which each attempt occurred; Data 2 - Correction attempt results of previous levels: Set of parameter configurations tried, combination of components and actions tried; Data 3 - Error type evolution sequence: Trend of error type changes across all levels, measuring whether errors converge or diverge using severity; Data 4 - Semantic information of user intent: Original user intent (needs to be reinterpreted), trying new interpretation angles by tracing back to the original intent; Data 5 - Complete information on available resources: All available components and actions of the system, requiring a global perspective, and possibly selecting previously unconsidered components.

[0245] Data flow: First-level results + Second-level results + Component registry + History records → Layered correction strategy system → Large language model correction inference mechanism.

[0246] (3) Correction reasoning mechanism based on large language model.

[0247] The large language model correction inference mechanism, as the core execution engine of the intelligent correction decision module, is invoked after a specific strategy is selected in the hierarchical correction strategy system. This mechanism and the strategy system exhibit a progressive execution relationship.

[0248] Triggering condition: After the hierarchical correction strategy system determines the correction strategy level (parameter fine-tuning / component replacement / strategy reconstruction) based on the error type and severity, the strategy type and corresponding data are passed to the large language model correction inference mechanism.

[0249] Data transmission rules: The range of data required for different levels of strategy increases in ascending order: Level 1 (parameter fine-tuning): only complete context information of the current error is required; Level 2 (component replacement): the attempt results of Level 1 + global component information of the system are required; Level 3 (strategy reconstruction): complete historical records of the first two levels + deep semantic analysis of user intent are required.

[0250] Division of responsibilities: Hierarchical adjustment strategy system: responsible for decision-making and selection, determining which level of strategy to adopt.

[0251] Large language model correction reasoning mechanism: responsible for strategy execution, performing specific reasoning and correction based on the selected strategy.

[0252] This design decouples strategy selection from strategy execution, enabling the system to make decisions quickly and reason deeply.

[0253] ① Construction of correction prompts. The prompt structure includes: error context (user requirements, failed call, number of attempts), error diagnosis (type, description, severity, fixability), correction task (strategy, goal, available resources), and output requirements (JSON format).

[0254] Different strategies have different hint variations: parameter fine-tuning emphasizes parameter-level analysis, component replacement emphasizes functional similarity matching, and strategy reconstruction emphasizes a renewed understanding of intent.

[0255] ② The reasoning chain of the large language model. Reasoning steps: error cause identification → user intent backtracking → solution generation → solution feasibility verification → confidence self-evaluation.

[0256] The reasoning process of the large language model adopts a chain reasoning mode, where each step is based on the output of the previous step, gradually refining the complete path from problem diagnosis to solution generation.

[0257] Step 1: Error Root Cause Identification. This step receives a structured error object and the call context, and performs in-depth root cause analysis. The system not only identifies the surface error type (such as "parameter type error"), but also locates the root cause through error message pattern matching and semantic analysis. For example, for "parameter type error," the system will further identify whether the user entered an incorrect value or whether a type misjudgment occurred during the intent parsing stage. This step outputs three key pieces of information: a detailed description of the root cause of the error, an error severity rating (1-5), and a determination of whether it can be automatically corrected. This information will serve as the basis for all subsequent steps.

[0258] Step 2: User Intent Backtracking. Based on the error causes identified in Step 1, this step re-examines the user's original needs. The system extracts the user's natural language input and re-parses the intent using a large language model. This step pays particular attention to multiple levels of intent understanding: literal understanding (the content explicitly stated by the user), contextual understanding (the implicit needs in the context), and goal understanding (the ultimate purpose the user hopes to achieve). By comparing the current failed call configuration with the re-parsed intent, the system calculates the degree of intent deviation. If the deviation is large (e.g., the calculator component should have been called but the time component was), it is marked as requiring strategy reconstruction. This step outputs: the re-parsed user intent description, the confidence level of intent understanding (0-1), and the degree of deviation from the original call configuration (0-1).

[0259] Step 3: Remedial Solution Generation. This step is the core of the reasoning chain, generating a specific remedial solution based on the analysis results of the first two steps. The generation process employs different remedial strategies depending on the error type and the degree of intent deviation: a. For parameter-level errors with small intent deviations, a parameter fine-tuning strategy is used: through parameter constraint derivation and parameter correction reasoning, a remedial solution that only modifies parameter configurations is generated. b. For component or action-level errors with moderate intent deviations, a component replacement strategy is used: through candidate component screening, functional semantic matching, and action and parameter adaptation, a remedial solution containing new components is generated. c. For cases with large intent deviations or continuous remedial failures, a strategy reconstruction strategy is used: through redefining task objectives, task decomposition planning, and execution path design, a reconstruction solution containing multiple execution steps is generated. This step outputs: the specific remedial solution (including component name, action name, and parameter configuration), the type of remedial strategy used, and detailed reasons for the remediation.

[0260] Step 4: Feasibility Verification. Before implementing the modified solution, this step involves rigorous logical verification. Verification consists of five sub-steps: component existence check (verifying whether the components involved are registered and available in the system), action support check (verifying whether the components support the specified actions), parameter validity check (verifying parameter integrity, type, value range, and format), dependency check (for multi-step solutions, verifying the data flow and execution order between steps), and historical repeatability check (avoiding repeating failed attempts). Based on the verification results, the solution is categorized into three types: feasible (passes all verifications), risk-controllable (some uncertainty exists but it can be attempted), and infeasible (exhibits obvious logical errors). This step outputs: feasibility assessment, specific reasons for verification failure (if any), and descriptions of potential risk points.

[0261] Step 5: Confidence Self-Assessment. This step quantifies the likelihood of success of the corrected solution. The confidence calculation considers four dimensions: clarity of the error cause (weight 0.25), certainty of the corrective logic (weight 0.25), solution validation pass rate (weight 0.3), and historical success rate reference (weight 0.2). Each dimension has a score range of 0-1, and the overall confidence score is obtained by weighted summation. The system categorizes solutions into four levels based on confidence: High confidence [0.8, 1.0] - direct adoption recommended; Medium confidence [0.6, 0.8] - adoption and monitoring recommended; Low confidence [0.4, 0.6] - cautious adoption recommended; Very low confidence [0, 0.4] - no adoption recommended. This step outputs: confidence score value, confidence level, recommended actions, and detailed explanations of the scores for each dimension.

[0262] Data Flow and Dependencies in the Inference Chain: The entire inference chain exhibits a strict sequential dependency: the root causes and severity of errors identified in step 1 form the basis for intent backtracking in step 2; the re-analyzed intent and degree of bias output in step 2 determine the corrective strategy selected in step 3; the corrective solution generated in step 3 requires feasibility verification in step 4; the verification results in step 4, along with the evaluation information from previous steps, jointly influence the confidence calculation in step 5. This chain dependency ensures that each step's decision is supported by sufficient information, and the final corrective solution is a high-quality result that has undergone multi-level analysis and verification.

[0263] ③ Multi-dimensional verification of the correction results. Format verification (JSON format correctness) → Integrity verification (all required fields are present) → Logic verification (existence of components / actions) → Confidence threshold verification.

[0264] The verification of the corrected results employs a four-layer progressive inspection mechanism, with each layer verifying different dimensions to ensure the usability and reliability of the corrected solution. The verification process progresses step by step, from format to content, and from local to global aspects.

[0265] Layer 1: Format Validation (JSON Format Correctness). This layer validates the basic format validity of the response returned by the large language model. The system first attempts to parse the response text using a JSON parser. If parsing is successful, it proceeds to the next layer of validation. If parsing fails, the system executes a fallback strategy: it uses regular expressions to extract possible JSON parts, removes Markdown code block tags (such as ```json), and then attempts to parse again. Simultaneously, it verifies that the JSON data structure conforms to expectations (it should be an object type, not an array or primitive type). If format validation fails, the corrected result is rejected outright, the confidence level is set to 0, and it does not proceed to subsequent validation.

[0266] The second layer: Integrity verification (all required fields are present). This layer verifies whether the correction plan contains all required fields. Depending on the correction strategy type, the system defines different lists of required fields: parameter fine-tuning strategies require three fields: corrected_params, confidence, and reasoning; component replacement strategies require five fields: alternative_module, alternative_action, params, confidence, and reasoning; and strategy refactoring strategies require three fields: execution_plan, confidence, and reasoning. The system iterates through the list of required fields, checking that each field exists and is not empty, and performs a preliminary check of the field type. If a key field is missing, the system records the missing field name, marks the plan as incomplete, and lowers the confidence level by 0.3. For missing fields that can be completed (such as reasoning, which can use the default value "AI-generated correction plan"), the system attempts to complete them and continues verification.

[0267] The third layer: Logic Validation (Component / Action Existence). This layer verifies the logical rationality of the remediation plan, including six sub-validations: a. Component Existence Validation: Query the component registry to check if the components in the remediation plan are registered and currently available. b. Action Support Validation: Query the component's action list to verify if the component supports the specified action. c. Parameter Signature Validation: Obtain the parameter signature of the target action and check if the parameters in the remediation plan meet the signature requirements (whether all required parameters are provided, whether there are any redundant parameters, and whether the parameter types match). d. Parameter Value Range Validation: For parameters with value range constraints, check if the parameter values ​​are within the allowed range (numerical range, string length, enumeration values, etc.). e. Parameter Format Validation: Use regular expressions or a format validator to check the parameter format (date and time, email, URL, etc.). f. Execution Plan Validation (only for strategy refactoring): For multi-step execution plans, verify the validity of each step, the rationality of data dependencies between steps, and the correctness of the execution order.

[0268] If the component or action does not exist, the solution is rejected directly, and the confidence level is set to 0; if the parameter signature does not match, the confidence level is reduced by 0.4; if the parameter value range or format is incorrect, the confidence level is reduced by 0.2.

[0269] The fourth layer: Confidence threshold verification. This layer makes the final decision based on the confidence score. The system first extracts the confidence value from the correction result (the specific calculation method is further explained in the quality assessment system of the correction scheme below) and verifies whether it is within the valid range [0.0, 1.0]. Then, it performs a comprehensive confidence adjustment based on the results of the first three layers of verification: the confidence is set to zero when the format verification fails; the confidence is multiplied by 0.7 when the integrity verification fails; and the confidence is multiplied by (0.6 - number of failed items × 0.1) when the logic verification fails. Finally, it makes a decision based on the adjusted confidence: if it is greater than or equal to 0.6, it is adopted directly; if it is in the range of [0.4, 0.6), it is adopted but monitoring is increased; if it is less than 0.4, the scheme is rejected and a detailed reason for failure is returned (including the original confidence, verification deduction items, final confidence, and reason for failure).

[0270] This four-layer verification system ensures the quality of the correction scheme, from basic format to deep logic, from local fields to global consistency, comprehensively guaranteeing the executability and success rate of the correction scheme.

[0271] (4) Quality assessment system for the revised plan.

[0272] Confidence calculation method and process: The confidence assessment of the revised scheme adopts a multi-dimensional weighted scoring mechanism, which comprehensively considers four dimensions: error diagnosis quality, strategy fit, scheme verification results and historical experience.

[0273] Formula for calculating overall confidence level: .

[0274] in, This represents the overall confidence score, ranging from [0, 1]. These represent the weight coefficients of each dimension, satisfying the normalization condition that the sum of the weights is 1; , , , These represent the confidence levels for error diagnosis, policy adaptation, validation success, and historical experience, respectively.

[0275] Dimension 1: Calculation of Confidence for Error Diagnosis. Confidence for error diagnosis (…) The evaluation system's accuracy and clarity in identifying error causes is based on a weighted combination of two sub-factors: error clarity score and pattern matching success rate. .

[0276] in, The error clarity score is divided into four levels based on the clarity of the error message: 1.0 when the error message contains specific parameter names and error types, 0.7 when it indicates the approximate location of the error but lacks details, 0.4 when the error message is vague and requires inference, and 0.2 when the error message is missing or completely unclear. This indicates the success rate of pattern matching, evaluating whether an error matches a known error pattern: 1.0 for an exact match, 0.7 for a partial match, 0.5 for a no-match but inferenceable match, and 0.3 for a completely unknown error type.

[0277] Dimension 2: Policy fit reliability calculation. Policy fit reliability ( The evaluation assesses the suitability of the selected correction strategy to the error type, using different calculation methods for different strategies: For parameter fine-tuning strategies: ,in The baseline confidence level for parameter fine-tuning (this strategy is based on explicit constraints and has high determinism). To determine the degree of intent deviation, the current call configuration semantic vector is calculated. With re-parsing the intent semantic vector The cosine distance is obtained as follows: .

[0278] in, This represents the vector dot product operation. This represents the Euclidean norm of a vector.

[0279] Regarding component replacement strategies: ,in The baseline confidence level for component replacement (based on semantic matching, which involves uncertainty) Given the set of semantic similarities for all candidate components, the similarity of each candidate component is calculated as follows: .

[0280] in, A semantic vector representing the user's intent. For the first Semantic vectors describing the functionalities of each candidate component.

[0281] For strategy restructuring strategies: .

[0282] in, The underlying confidence level for strategy reconstruction (involves a reinterpretation, with high uncertainty). The number of times a strategy has been successfully reconstructed in history. This represents the total number of attempts to refactor the strategy throughout history.

[0283] Dimension 3: Calculation of validation pass confidence score. Validation pass confidence score ( The feasibility of the scheme is evaluated based on the results of the four-layer validation: .

[0284] in, Indicates the first The pass rate of layer validation (0 or 1, or the proportion of partial passes). Indicates the first Importance weights for layer verification.

[0285] Passing criteria for each layer of validation: When the first layer of format validation passes completely. ,otherwise The pass rate for the second-level integrity verification was [percentage missing]. ,in, The number of required fields that exist. The total number of required fields; the pass rate of the third-level logic validation. ,in The number of logical verification violations (maximum 5); in the fourth-level confidence threshold verification, when the large language model reports its confidence level... Greater than or equal to the threshold hour ,otherwise .

[0286] Dimension 4: Calculation of historical experience confidence level. Historical experience confidence level ( This provides experience-based references based on historical success rates. If the experience knowledge base contains historical records of similar scenarios: .

[0287] in, Weighted for the overall success rate; For the overall historical success rate, This represents the number of times this error mode has been successfully corrected historically. This represents the total number of attempts. For recent success rates, It represents the number of successful attempts in the most recent N attempts (usually N=10). The most recent attempt count. If no similar record is found in the knowledge base, a neutral score is given. .

[0288] After calculating the initial overall confidence level, the system makes adjustments based on special circumstances: Consecutive failure penalty: If the current error has already experienced multiple failed corrections, a penalty factor is applied. ,in This represents the number of consecutive failures for the current error.

[0289] Freshness Bonus: If the historical experience used is very recent (last used no more than 7 days ago), the application will receive a bonus. .

[0290] Confidence range normalization: ensures the final confidence level is within the valid range. .

[0291] Based on the final confidence level The system categorizes the solutions into four levels: high confidence. Based on clear logical reasoning, it is recommended to adopt the suggestion directly, with a medium confidence level. It may be effective but there are uncertainties. It is recommended to use it and monitor it. Low confidence level. High uncertainty suggests caution is advised; extremely low confidence level. Potentially invalid suggestions should not be adopted. The confidence scoring mechanism is shown in Table 1 below.

[0292] Table 1 Confidence Scoring Mechanism

[0293] Semantic fidelity assessment: .

[0294] in, A semantic vector representing a user's original intent is a high-dimensional vector representation of the user's initial natural language input after vectorization encoding. This is obtained by a vector-specific semantic encoding model that converts the user's input text into a fixed-dimensional vector. This represents the intent semantic vector corresponding to the correction scheme, reflecting the semantic representation of the actual operation to be performed by the correction scheme. Obtaining this vector involves two steps: first, converting the correction scheme into a natural language description (this step involves feeding the correction scheme to the LLM and having it output a natural language description), and then vectorizing this description. The dimension of this vector is... The same applies to ensure that vector operations can be performed.

[0295] like This indicates that the proposed solution deviates from the user's intention and requires user confirmation.

[0296] III. Experience Knowledge Base Module. The experience knowledge base module is a key component that enables the system to have self-learning and continuous evolution capabilities. This module persistently stores error correction experience accumulated during system operation and quickly retrieves and reuses this experience in subsequent tasks, realizing the transformation from relearning every time to learning once and benefiting for life.

[0297] The core idea of ​​this module is that experience reuse is better than re-reasoning. Key innovations include: feature-based storage (extracting key features to form a searchable knowledge representation), multi-level matching (supporting precise and fuzzy matching), and dynamic evolution (continuously updating, optimizing, and eliminating outdated knowledge).

[0298] like Figure 4 As shown, the retrieval process of the experience knowledge base module adopts a two-level matching strategy of "precise priority and fuzzy fallback". The process first generates an error feature signature and attempts to match it precisely. If the precise match is successful, a known correction scheme with high confidence is returned directly. If the precise match fails, a fuzzy feature matching algorithm is started to find similar historical error patterns by calculating the edit distance and return a candidate scheme with medium confidence. If both levels of matching fail, a "no match" result is returned and handed over to the intelligent correction module for inference from scratch.

[0299] like Figure 5 As shown, the storage process of the experience knowledge base module implements an incremental learning mechanism. This process extracts error features from successful correction schemes and generates error patterns, then checks whether the pattern already exists in the knowledge base: if it already exists, its statistics (such as the number of successes and the last time it was used) are updated; if it does not exist, it is added to the knowledge base as a new pattern. At the same time, the complete correction process is recorded as a success case, and finally, the knowledge is written to disk through an asynchronous persistence mechanism to ensure that the experience is not lost after the system restarts.

[0300] (1) Input and output of the experience knowledge base module and its relationship with the module.

[0301] Input information: Query request (component, action, error type, user intent, source module: intelligent correction decision module), storage request (structured error object, successful correction scheme, source module: feedback coordination control module).

[0302] Output information: Query response (error pattern object or list of similar patterns or empty result, receiving module: intelligent correction decision module), storage response (storage success confirmation, receiving module: feedback coordination control module).

[0303] Module Relationship: Passive service module, which is called by intelligent correction decision module and feedback coordination control module.

[0304] (2) Two-layer knowledge representation model.

[0305] ① Error Pattern Library: An error pattern is an abstract representation of a certain type of error, which includes: pattern identifier (generated by hashing "component + action + error type"), component name, action name, error type, error signature, successful fix, number of successful applications, last used time, and creation time.

[0306] Pattern identifier generation: .

[0307] Establish multi-level indexes: the first-level index is grouped by component name, the second-level index is grouped by action name, and the third-level index is grouped by error type.

[0308] ② Success Case Library: Success cases record the complete correction process, including: case identifier, user's original intent, user intent semantic vector, original call configuration, error message, corrected call configuration, correction strategy type, and creation time.

[0309] A circular queue structure is used, which only retains the most recent N cases and automatically discards the oldest cases.

[0310] (3) Core algorithm for knowledge retrieval.

[0311] ① Exact match retrieval algorithm. Based on pattern identifiers. Search the error pattern library. If a match is found, update the usage statistics (number of successful applications +1, update the last usage time), and return the correction solution.

[0312] ② Fuzzy feature matching algorithm.

[0313] Error signature generation method: Error signatures are structured representations of errors, used for fast matching and retrieval in an experience-based knowledge base. The signature generation process includes six steps: Step 1: Extract key error features. Extract four key features from the structured error object: component name (identifier of the failed call), action name (identifier of the failed call), error type (classification of errors, such as parameter error, component error, action error), and error subtype (more granular classification, such as parameter error can be further subdivided into type error, range error, and missing value error).

[0314] Step 2: Extract parameter features. For parameter-related errors, further extract parameter features: erroneous parameter name (the specific parameter name that caused the error), parameter type, and special patterns of parameter values ​​(such as zero, null, negative, etc.).

[0315] Step 3: Extract keywords from the error message. Use natural language processing (NLP) techniques to segment the original error message, remove stop words, and extract nouns and verbs as keywords. Also extract special patterns, including numerical ranges, format requirements, and type requirements.

[0316] Step 4: Construct the feature string. Concatenate the extracted features into a feature string according to a fixed format.

[0317] Step 5: Feature signature normalization. Normalize the feature string to ensure that similar errors produce the same signature: convert all letters to lowercase to avoid case differences, remove special characters such as spaces and punctuation marks (retain separators :: and |), and sort keywords alphabetically to ensure consistent order.

[0318] Step 6: Generate signature hash. To improve retrieval efficiency, calculate the hash value of the normalized signature feature. Use a hash function (such as MD5 or SHA256) to generate a fixed-length signature identifier: .

[0319] in, For the signature hash value, This is the normalized feature string. The generated signature hash serves as a unique identifier for this error pattern, used for fast retrieval and precise matching.

[0320] The error signature generated through the above six steps contains structured error feature information and is comparable and searchable, which is the key foundation for the experience knowledge base to achieve intelligent matching.

[0321] Set the current error signature. The first in the knowledge base Feature signature of each pattern .

[0322] Similarity is calculated using edit distance: .

[0323] in, Using the standard Levenstein distance algorithm, defined as the distance between strings... Convert to Minimum number of insert, delete, or replace operations required. Select similarity. Candidates with a custom similarity threshold are sorted in descending order of similarity, and the top K (usually 3) are returned.

[0324] ③ Semantic similarity retrieval algorithm.

[0325] Keyword extraction based on TF-IDF: TF-IDF (Term Frequency-Inverse Document Frequency) takes into account both term frequency and inverse document frequency, and can identify the words that are most representative of a document.

[0326] Step 1: Word Segmentation. Perform Chinese word segmentation on the user intent text: a. Use a word segmentation tool (such as the jieba segmentation library) to segment the text into words. b. Retain nouns, verbs, and adjectives as candidate words. c. Remove stop words (such as "de", "shi", "zai", "zhege", "nage", etc.).

[0327] Step 2: Calculate Term Frequency (TF). Term frequency indicates the importance of a word in a document: .

[0328] Among them, is the term frequency of the word ; is the number of times the word appears in the document; is the total number of words in the document.

[0329] Step 3: Calculate Inverse Document Frequency (IDF). Inverse document frequency measures the discrimination of a word: .

[0330] Among them, is the inverse document frequency of the word ; is the total number of documents in the knowledge base (the number of all successful cases); is the number of documents containing the word , and +1 is for smoothing to prevent the denominator from being 0.

[0331] Step 4: Calculate TF-IDF Weight: .

[0332] Step 5: Select Top-K Keywords. Sort in descending order of TF-IDF weight and select the K words with the highest weight (usually K = 5 - 10) as keywords.

[0333] Simplified algorithm based on keywords: Segment the user intent to extract keywords and calculate the overlap degree of keywords with successful cases.

[0334] Similarity: .

[0335] Among them, is the keyword set of the current task. Meaning: The keyword list obtained after the system performs word segmentation on the natural language input by the current user. Example: If the user inputs "Generate a random number", the set may be {"Generate", "Random number"}. is the keyword set of historical cases. Meaning: The original intent keyword set corresponding to a certain historical successful correction case stored in the knowledge base. (Intersection symbol): Represents elements that exist in both sets.

[0336] Semantic vector-based algorithms: .

[0337] in, This is the semantic vector of the current user intent. Meaning: This is obtained by a vector-specific semantic encoding model, which converts the user input text into a fixed-dimensional vector. This is the semantic vector of a historical success case. Meaning: A pre-computed vector corresponding to the intent of a historical case stored in the knowledge base.

[0338] (4) Knowledge update and maintenance mechanism.

[0339] ① Knowledge Incremental Learning Algorithm. Each successful correction triggers a knowledge update: Generate a pattern identifier → Check if it already exists → If it already exists, update the statistics; if it does not exist, create a new pattern → Add successful cases → Maintain the case library size → Persist to disk.

[0340] Implementing this method using hash-based exact lookup includes the following steps: Step 1: Generate the current error pattern identifier. Generate the pattern identifier using the same method as at store time. .

[0341] Step 2: Search in the knowledge base index. The experience knowledge base maintains a hash index based on pattern identifiers, that is, a hash table is built using the pattern identifier as the key and the location of its complete error information. If the pattern identifier is found in the index, it means that the pattern already exists, and the existing pattern object is returned directly; otherwise, it does not exist.

[0342] ② Knowledge Quality Assessment Algorithm. Periodic assessment: Executed at fixed time intervals. Typical configuration: Executed once daily at midnight for high-frequency scenarios (active systems), once weekly for medium-frequency scenarios (normal systems), and once monthly for low-frequency scenarios (low-load systems). Execution time is chosen during periods of low system load (e.g., 2:00-4:00 AM) to avoid impacting normal business operations. Triggering is achieved using a scheduled task (e.g., Linux cron).

[0343] Quality rating: .

[0344] in, (Success rate): ; (Frequency of use): ; (Timeliness): ; , and These represent the weighting coefficients for successful application rate, usage frequency, and time freshness, respectively.

[0345] ③ Knowledge obsolescence and cleanup algorithm. Cleanup strategy: Delete low-frequency (success count < 3) and low-quality (Quality < 0.3) records that have not been used for more than a threshold number of days (usually 30 days). The success case library uses a fixed-size circular queue to automatically evict the oldest records.

[0346] V. Retry Management and Circuit Breaker Module. The retry management and circuit breaker module is responsible for controlling the pace, intensity, and termination conditions of the entire correction and retry process. The core responsibility of this module is to strike a balance between "best-effort correction" and "avoiding unnecessary resource consumption." On the one hand, the system should provide sufficient opportunities for correction to improve task success rate; on the other hand, the system should also be able to promptly identify unrecoverable errors or retries stuck in infinite loops, decisively stopping them to conserve resources. This module achieves this delicate balance through a layered, progressive retry strategy, an intelligent delayed backoff algorithm, and a circuit breaker protection mechanism.

[0347] The core idea of ​​this module is "intelligent retry control," which includes three key principles: layered gradual adjustment (not all errors are corrected with the same intensity; simple errors are quickly corrected using lightweight methods, while complex errors are gradually escalated in terms of correction intensity. This gradual strategy ensures both efficiency and success rate); dynamic adjustment (the retry rhythm and strategy are not fixed but dynamically adjusted according to the evolution of the error. If the error is rapidly converging, the system will maintain the current strategy; if the error is diverging or stalling, the system will escalate the strategy or trigger a circuit breaker); and protective circuit breaker (when an invalid retry pattern is detected, the system will decisively break the circuit breaker to avoid resource waste. This is an engineering practice of "fail fast." The key innovation lies in upgrading retry management from a simple "loop counter" to an intelligent "process controller," enabling it to make optimal decisions based on the context.

[0348] like Figure 6 As shown, the retry management and circuit breaker module adopts a four-stage control process of "decision-leveling-delay-circuit breaker". The process first determines whether to continue retrying based on a comprehensive judgment of multiple conditions (number of retries, repairability, severity, and circuit breaker status). Then, it selects the corresponding retry level (L1 / L2 / L3) based on the current number of attempts. Next, it applies the exponential backoff algorithm to calculate and execute the delay waiting, while updating the circuit breaker status to detect and prevent the continued occurrence of invalid retry modes. Finally, it outputs a complete decision object containing the retry decision, level, and delay time.

[0349] (1) Input and output of retry management and circuit breaker module and module relationship.

[0350] Input information: Structured error object (source module: error semantic analysis module), current retry status (number of attempts, retry history, source module: feedback coordination and control module).

[0351] Output information: Retry decision object (whether to continue, retry level, delay time, retry record; receiving module: feedback coordination and control module).

[0352] Module Relationship: Receives structured error objects from the error analysis module, outputs retry decisions to the feedback coordination and control module, and outputs retry hierarchy to the intelligent correction decision module.

[0353] (2) Policy-aware dynamic quota retry mechanism. This embodiment innovatively proposes a "policy-oriented dynamic quota" retry mechanism. Unlike the single-dimensional linear retries in the prior art, this embodiment deeply decouples the retry manager from the intelligent correction decision module, and dynamically allocates execution quotas and time windows according to the "target correction level" triggered by the error type.

[0354] Step 1: Construct a hierarchical quota vector space. The system first defines a configuration vector that strictly corresponds to the hierarchy of correction strategies, pre-setting resource boundaries for correction strategies at different depths. Let the retry configuration set be... The definition is as follows: .

[0355] in, Indicates the first The maximum number of trials allowed by the tiered correction strategy (i.e., the quota). For example, Level 1 is allocated 2 times, Level 2 is allocated 2 times, and Level 3 is allocated 1 time. Indicates the first The base backoff time for the layer correction strategy.

[0356] Step 2: Policy Mapping and Initial Hierarchy Determination. When a structured error object is captured... At this time, the system first determines the initial target level based on the classification logic of the intelligent correction decision module. A hierarchical mapping function is then defined. : .

[0357] Technical effect: This step ensures that retries are targeted. For example, if "component does not exist" is detected, the system directly retrieves the relevant data from the system. Start with levels, skipping invalid ones. Fine-tuning of hierarchical parameters avoids resource waste.

[0358] Step 3: Dynamic Decision-Making and Strategy Upgrade. The system combines the currently consumed number of attempts... Through decision function This function determines the next action to take. It not only determines whether to retry, but also includes a policy escalation mechanism—that is, when a lower-level policy runs out of quota, it is automatically escalated to a higher-level policy.

[0359] The mathematical expression of the decision function is as follows: .

[0360] in, Indicates execution of the first Hierarchical correction strategy, This represents the total number of retries allowed. .

[0361] Strategy logic: If the initial judgment is (Parameter error), but after... The second attempt still failed; the condition in the second row of the formula was met, and the system will be forcibly upgraded. (Component replacement).

[0362] Step 4: Exponential backoff delay calculation. To prevent continuous high-cost correction requests from overwhelming the server, the system applies a hierarchical exponential backoff algorithm to calculate the actual waiting time after determining the execution level. : .

[0363] in, Indicates the current level The formula specifies the number of local attempts within a given level. This formula implements the control logic of "the higher the level, the longer the cool-off period," ensuring that the system has sufficient state synchronization time before performing deep policy refactoring (Level 3) and automatically reducing the request rate when there are high-frequency failures.

[0364] (3) Retry decision algorithm.

[0365] The comprehensive evaluation criteria include: number of retries Error repairability ; (output by the error semantic analysis module); error severity (Output from the error semantic analysis module); The circuit breaker was not triggered; Retry will continue only if all conditions are met, otherwise stop and return the corresponding reason.

[0366] (4) Fuse Mechanism. A fuse is a protection mechanism used to detect and prevent invalid repeated retries. The core idea is: if the same error occurs repeatedly, it means that the current correction strategy is ineffective, and continuing to retries is just a waste of resources, so it should be stopped in time.

[0367] ① Error signature generation: A unique signature is generated for each error to identify "identical errors": .

[0368] ② Circuit breaker triggering algorithm, maintaining an error counter Dictionary and trigger threshold When an error occurs, a signature is generated. If the signature is not in the counter, it is initialized to 1; otherwise, the counter is incremented by 1. If the counter reaches the threshold, the circuit breaker is triggered, returning True (retry should stop); otherwise, False (retry can continue). Circuit breaker conditions: .

[0369] ③ Post-fuse handling: stop retrying → record the fuse event → generate a detailed error report → provide user-friendly explanations and suggestions → optionally provide similar success cases for reference.

[0370] As an optional implementation method, the detailed process of post-fuse handling includes: Step 1: Stop Retrying. Execution Module: Retry Management and Circuit Breaker Module. Trigger Condition: The circuit breaker's trigger condition returns True, indicating that the same error signature has appeared consecutively, reaching the threshold (usually 3 times). Execution Process: a. Circuit Breaker Flag Setting: The retry manager sets its internal circuit breaker status flag to True and records the error signature that triggered the circuit breaker. b. Terminating the Retry Loop: The retry manager stops the loop. Upon receiving the stop loop signal, the feedback coordination control module immediately exits the "execution-analysis-correction" loop iteration. c. Retry Statistics Update: Update the circuit breaker statistics counter (number of circuit breaker triggers + 1) and record the timestamp of the circuit breaker trigger. d. Output Data: Return the stop loop signal to the feedback coordination control module.

[0371] Step 2: Record the circuit breaker event. Execution Module: Feedback Coordination and Control Module. Collaboration Module: Retry Management and Circuit Breaker Module (provides historical data). Execution Process: ① Create a circuit breaker event record object: Record the trigger time (current timestamp), record the error signature (obtained from the circuit breaker), record the attempt history (obtain the complete retry history from the retry manager), and record the user's original intent (save the user's request description). ② Write to the event log: The log content includes complete information such as time, error signature, number of consecutive failures, user intent, and attempt history. ③ Persist the circuit breaker record: Save the circuit breaker event to the system monitoring database for subsequent fault analysis and system optimization. Output Data: The circuit breaker event record object contains complete information such as time, signature, and history.

[0372] Step 3: Generate a detailed error report. Execution Module: Feedback Coordination and Control Module. Collaboration Module: Retry Management and Circuit Breaker Module (provides statistical data). Execution Process: ① Summarize Failure Information: Extract detailed information of all failed attempts from the retry history, count the number of attempts at each level (Layer 1 attempts X times, Layer 2 attempts Y times, Layer 3 attempts Z times), and collect the error type and error message for each failure. ② Construct the Error Report Structure: Task Status: Failed (Circuit Breaker Triggered); User Request: [User's Original Intent]; Total Number of Attempts: X times; Reason for Failure: Repeated occurrence of the same error, ineffective correction strategy; Detailed Failure Records: List the configuration and reason for failure for each attempt; Failure Mode Analysis: Identify recurring errors and diagnose the root cause (e.g., "The system may have a misunderstanding of parameter b" or "The add action of the Calculator component may have a bug"). ③ Format Report Output: Convert the report into a structured dictionary object containing fields: Current Status (Failure), Reason for Failure (Circuit Breaker Triggered), Number of Attempts, Error History List, and Root Cause Analysis of Failure (i.e., the root cause diagnosis result from the failure mode analysis in the previous step). Output data: Detailed error report object, containing complete failure information and analysis.

[0373] Step 4: Provide user-friendly instructions and suggestions. Execution Module: Feedback Coordination and Control Module. Execution Process: Generate user-friendly error descriptions, that is, convert technical error reports into user-understandable natural language descriptions. The technical error reports are then fed to the LLM (User Model) for semantic transformation according to its design principles and displayed on the UI (User Interface). Output Data: User-friendly error description text and a list of suggested actions.

[0374] Principles for constructing user-friendly instructions: a. Avoid technical jargon: Instead of saying "PARAMETER_ERROR", say "parameter configuration error"; b. Explain the cause of the problem: Not only say it failed, but also why it failed; c. Express the system's efforts: Inform the user that the system has attempted to fix the problem multiple times; d. Provide next steps: Tell the user what they can do.

[0375] Step 5: Optional: Provide similar success case references. Execution Module: Experience Knowledge Base Module; Collaboration Module: Feedback Coordination and Control Module (Initiates query request); Execution Process: ① Query similar success cases: The Feedback Coordination and Control Module calls the success case library of the Experience Knowledge Base Module, which contains high-similarity success cases. Input parameters: Description of the current user's intent, limit on the number of cases returned. Query logic: Use a keyword matching algorithm to calculate the similarity between the user's intent and historical success cases. Filter cases with similarity ≥ threshold. Sort by similarity in descending order and return the top K cases. ② Filter high-quality cases: Perform a secondary filter on the queried similar cases. Filtering criteria: The case's correction strategy has a high success rate (the strategy has been successful ≥ 2 times in history), the case's scenario is not exactly the same as the current failure scenario (avoid recommending solutions destined to fail), and the case is not too old (prioritize cases within the last month). ③ Format case information: Convert the filtered success cases into user-understandable reference information, that is, concatenate the cases to the LLM, allowing it to translate them into user-understandable information. ④ Handling cases without similar cases: If no similar successful cases are found in the knowledge base, the message "No similar successful cases are available for reference" will be returned.

[0376] (5) Retry Statistics and Monitoring. Statistical indicators: total number of retries, number of retries at each level, average number of retries, retry success rate, number of circuit breaker triggers, average correction time, and average time at each level. Used for performance monitoring, strategy optimization, problem diagnosis, and resource planning.

[0377] VI. Feedback Coordination and Control Module. The Feedback Coordination and Control Module is the central coordinator and commander-in-chief of the entire self-correcting system. It is responsible for integrating all modules to achieve a complete closed-loop feedback process. This module does not directly perform error analysis, corrective decisions, or knowledge management; instead, it coordinates the work of these specialized modules, ensuring the correct flow of information and controlling the rhythm and termination conditions of the execution-correction cycle.

[0378] The core idea of ​​this module is orchestration and coordination. Key responsibilities include: process orchestration (defining the sequence and conditional branches of each step), data transfer (transferring structured data between modules), state management (maintaining execution status and retry history), exception handling (implementing degradation strategies), and resource control (controlling the initiation and termination of retry loops).

[0379] like Figure 7As shown, the feedback coordination and control module implements a complete "execution-analysis-correction-re-execution" closed-loop control process. This process employs a cyclical iterative architecture. In each iteration, it first attempts to execute the currently configured task. If successful, the experience is recorded and the result is returned. If it fails, error analysis, retry decision-making, delayed application, knowledge base query, and intelligent correction are performed sequentially. Then, the configuration is updated and the next iteration begins. The entire loop uses the retry management module's decision-making mechanism to control termination conditions, ensuring timely exit upon successful correction, reaching the maximum number of retries, or triggering a circuit breaker, thus avoiding infinite loops.

[0380] (1) The relationship between the input and output of the feedback coordination control module and the module.

[0381] Input information: Task execution request (components, actions, parameters, user intent, source module: external to the system (user interface layer)).

[0382] Output information: Task execution result (success indicator, execution result / error information, number of corrections, etc.; receiving module: external system (user interface or API response)).

[0383] Module relationships: It interacts with all other modules and acts as the hub of the entire system.

[0384] (2) Execution of the verification process. Before actually executing the task, the system performs multi-layered verification to ensure the legitimacy of the call. The verification layers include: first layer component existence verification (checking whether the component name is in the system component registry), second layer obtaining the component instance (attempting to load the component from the registry), third layer action support verification (checking whether the action name is in the supported action list of the component instance), fourth layer parameter integrity and legality verification (calling the verification method of the component instance), and fifth layer executing business logic (calling the execution method of the component instance). Each verification failure generates detailed error information, including the failed verification layer, the specific reason for the failure, and possible correction suggestions. This multi-layered verification ensures that errors can be detected and located at the earliest stage.

[0385] (3) Failure Degradation and Friendly Feedback. When all corrective attempts fail, the system needs to gracefully report the failure to the user. The failure result construction algorithm includes: constructing a basic error message (including the number of attempts and the reason for stopping), adding error details (error type and error description), adding corrective suggestions (if any), finding similar success cases for reference (retrieving from the knowledge base and adding reference information if found: similar requests, components used, and actions used), and optionally providing ways to contact support. The design principles for friendly feedback are: complete information (informing the user what happened, why it failed, and what was tried), user-friendly language (using natural language that the user can understand and avoiding technical jargon), providing suggestions (not only saying "it won't work" but also "what can be done"), maintaining hope (providing similar success cases to give the user confidence), and a clear path (informing the user what to do next).

[0386] (4) System fault tolerance and exception handling. The system has a multi-layer fault tolerance mechanism: module-level fault tolerance (the operation of each module is wrapped in exception handling, and after capture, logs are recorded and default values ​​are returned or encapsulated exceptions are thrown), process-level fault tolerance (the degradation strategy when key process steps fail, such as skipping knowledge base retrieval and continuing to use AI to correct if knowledge base access fails, and recording the error and triggering retry termination if AI correction fails), and system-level fault tolerance (the protection mechanism of the entire system, the outermost exception capture, recording detailed error stacks, attempting recovery or safe termination, performing cleanup operations, and returning system error results).

[0387] Degradation strategy: When certain non-core functions fail, the system degrades its operation. If the knowledge base module fails, knowledge retrieval is skipped and AI correction is used directly. If the correction engine fails, simple rule correction is attempted or the system fails directly. If statistical recording fails, statistics are skipped without affecting the main process. If persistent storage fails, only logs are recorded without affecting the current task. The degradation strategy ensures that core functions (task execution and correction) remain available as much as possible.

[0388] (5) System Statistics and Monitoring. The coordination and control module provides comprehensive monitoring of the system's operating status. Statistical information collection includes: retry statistics (provided by the retry manager), knowledge base statistics (provided by the knowledge base), task statistics (total number of tasks, number of successful tasks, number of failed tasks, number of successful corrections), success rate (first-time success rate, overall success rate), performance statistics (average execution time, average number of corrections, average correction time), circuit breaker statistics (number of circuit breaker triggers), knowledge base efficiency (knowledge base hit rate, knowledge base time saved), and error distribution (error type distribution, high-frequency errors).

[0389] The system provides the following key metrics for real-time monitoring: availability metrics (current success rate, i.e., the success rate of the most recent N tasks; system health, i.e., a comprehensive assessment of the status of each module of the system), performance metrics (average response time, response time, throughput, i.e., the number of tasks processed per minute), and quality metrics (correction success rate, i.e., the proportion of tasks that succeed after correction to the number of tasks that need correction; knowledge base contribution rate, i.e., the proportion of errors directly resolved by the knowledge base to the total number of errors).

[0390] This application also provides an application scenario in which the aforementioned intelligent function call method with error self-correction capability is applied. Specifically, the intelligent function call method provided in this embodiment can be applied in the scenario of vision screening and health record management for children and adolescents. The complete business processing scenario includes a screening data collection stage, an intelligent diagnosis and self-correction stage, and a diagnostic report rendering and distribution stage. First, in the screening data collection stage, the patient's basic information and vision parameters (such as age, uncorrected visual acuity, etc.) are obtained through a vision testing instrument or a front-end input system, and sent to the downstream intelligent system through natural language or semi-structured instructions. The solution of this application is applied to the intelligent diagnosis and self-correction stage, which calls the local medical knowledge base and vision assessment component through a large language model. When the large model generates incorrect parameter types due to "illusion" or calls a mismatched assessment function, the system will trigger closed-loop self-correction, automatically correcting parameters or reconstructing strategies to ensure the rigor of the final diagnostic logic. Then, in the diagnostic report rendering and distribution stage, after self-correction and successful execution, the system outputs a standard diagnostic conclusion, renders it into a formatted children and adolescents vision screening diagnostic report, and distributes it to the client or stores it in the health record.

[0391] Based on the same inventive concept, this application also provides an intelligent function call system with error self-correction capability for implementing the intelligent function call method with error self-correction capability described above. The solution provided by this system is similar to the implementation scheme described in the above method. Therefore, the specific limitations of one or more embodiments of the intelligent function call system with error self-correction capability provided below can be found in the limitations of the intelligent function call method with error self-correction capability described above, and will not be repeated here.

[0392] In one exemplary embodiment, a smart function call system with error self-correction capability is provided, comprising: The intent parsing module is used to obtain the task requirement text described by the user in natural language, and determine the function call information based on the task requirement text; the function call information includes the target component identifier, the operation action type, and the call parameter dictionary.

[0393] The execution verification module is used to verify function call information and execute the function call information after successful verification.

[0394] The error semantic analysis module is used to capture verification failure information or exception information and generate structured error description information if verification fails or an exception is thrown when executing function call information. The structured error description information includes error type, severity level, corrective flag, error signature, number of attempts and historical attempt records.

[0395] The experience knowledge base module is used to query the experience knowledge base based on corrective tags and using error signatures as keys to obtain reusable correction results. The experience knowledge base includes error signatures and corresponding historical successful correction information. The historical successful correction information includes the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary.

[0396] The intelligent correction decision module is used to directly use the corresponding historical successful correction information as the correction function call information if the reusable correction result shows that there is historical successful correction information; if the reusable correction result shows that there is no historical successful correction information, it generates correction function call information based on the structured error description information through a multi-level correction strategy; the multi-level correction strategy includes parameter fine-tuning strategy, component or action replacement strategy, and function call information reconstruction strategy.

[0397] The retry management and circuit breaker module is used to take the corrected function call information as the function call information and return to the step "Based on the function call information, obtain the verification result through the preset verification method, and execute the function call information when the verification result is passed", until the function call information is successfully executed or the circuit breaker condition is triggered; the circuit breaker condition includes the cumulative number of occurrences of the same error signature reaching a preset threshold.

[0398] In summary, this application has the following significant advantages and beneficial effects: 1. Significantly improve task execution success rate: By constructing a closed-loop error correction mechanism, the system can transform low-level program errors into semantic feedback that can be understood by the large model, automatically correct errors such as parameter type and out-of-bounds errors, and realize the transformation from "termination upon error" to "correction upon error".

[0399] 2. Intelligent optimal allocation of computing resources: The hierarchical progressive correction strategy dynamically selects the correction depth according to the severity of the error. Simple parameter errors are corrected with lightweight correction, while complex logic errors are corrected with a reconstruction strategy, which effectively avoids the waste of computing power caused by blind retries.

[0400] 3. Possesses continuous self-evolution capability: The experience knowledge base based on error signatures enables the system to have long-term memory. Successful correction experiences are accurately stored and reused. As the running time increases, the response time for correcting recurring errors is significantly reduced.

[0401] 4. Provides intelligent system security circuit breaker protection: By identifying consecutive invalid retry patterns through an error signature counter, the system can automatically cut off the retry link and perform friendly degradation to prevent system-level cascading failure.

[0402] 5. Semantic decoupling between the execution layer and the decision layer: The middleware layer cleans unstructured exceptions into structured semantic objects, which lowers the threshold for understanding errors in large models and gives the system good adaptability to large model bases.

[0403] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0404] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0405] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0406] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0407] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A smart function call method with error self-correction capability, characterized in that, include: Obtain the task requirement text described by the user in natural language, and determine the function call information based on the task requirement text; The function call information includes the target component identifier, the operation action type, and a call parameter dictionary; Verify the function call information, and execute the function call information if the verification is successful; If verification fails or an exception is thrown when executing function call information, the verification failure information or exception information is captured, and a structured error description is generated; the structured error description includes error type, severity level, corrective flag, error signature, number of attempts, and historical attempt records; Based on the corrective tagging, the experience knowledge base is queried using the error signature as the key to obtain reusable correction results; the experience knowledge base includes the error signature and the corresponding historical successful correction information; the historical successful correction information includes the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary; If the reusability correction result indicates the existence of historical successful correction information, then the corresponding historical successful correction information will be directly used as the correction function call information. If the reusability correction result indicates that there is no historical successful correction information, then correction function call information is generated based on the structured error description information through a multi-level correction strategy. The multi-level correction strategy includes parameter fine-tuning strategy, component or action replacement strategy, and function call information reconstruction strategy. The corrected function call information is used as the function call information, and the process returns to the step "Based on the function call information, a verification result is obtained through a preset verification method, and the function call information is executed when the verification result is passed", until the function call information is executed successfully or the circuit breaker condition is triggered; the circuit breaker condition includes the cumulative number of occurrences of the same error signature reaching a preset threshold.

2. The intelligent function call method with error self-correction capability according to claim 1, characterized in that, The function call information is validated, and the function call information is executed only after successful validation. This process includes the following steps: The experience knowledge base is queried using the target component identifier and operation action type as keys. The retrieved historical task requirement texts and historical successful correction information are added to the preventive correction scheme set. The experience knowledge base also includes historical target component identifiers, historical operation action types, historical task requirement texts, and corresponding historical successful correction information. If the set of preventive correction schemes is not empty, then calculate the semantic similarity between the task requirement text and each historical task requirement text in the set of preventive correction schemes to obtain the semantic similarity set. If the highest semantic similarity in the semantic similarity set exceeds the preset similarity threshold, the function call information is updated using the historical successful correction information corresponding to the highest semantic similarity. If the set of preventive correction schemes is empty, or the highest semantic similarity in the set of semantic similarities does not exceed the preset similarity threshold, then the function call information remains unchanged.

3. The intelligent function call method with error self-correction capability according to claim 1, characterized in that, Verification of function call information includes: The function call information is verified according to the following steps using a preset verification method; the preset verification method includes existence verification, availability verification, integrity verification, and legality verification. The existence of the target component identifier in the function call information is verified to obtain the existence verification result; the existence verification is used to verify whether the target component identifier exists in the preset system component registry; the preset system component registry is used to store the mapping relationship between the component identifiers of registered components and component instances; If the existence verification result is yes, then the component instance corresponding to the target component identifier is obtained according to the preset system component registry, and the availability verification is performed on the operation action type to obtain the availability verification result; the availability verification is used to verify whether the component instance supports the operation action type. If the availability verification result is yes, then the integrity verification of the call parameter dictionary is performed to obtain the integrity verification result; the integrity verification is used to verify whether the call parameter dictionary contains all the necessary parameters required for the operation action type; If the integrity verification result is yes, then the validity verification of each parameter in the call parameter dictionary is performed to obtain the validity verification result; the validity verification is used to verify whether each parameter meets the parameter signature constraints of the operation action type; the parameter signature constraints include the parameter value type, value range and format specification; If the existence verification result, availability verification result, integrity verification result, or legality verification result are all yes, then the verification is successful; If any of the existence verification result, availability verification result, integrity verification result, or legality verification result is negative, the verification fails.

4. The intelligent function call method with error self-correction capability according to claim 1, characterized in that, Capture verification failure or exception information and generate structured error description information, specifically including: Errors are classified based on verification failure or exception information to obtain error types; the error types include parameter-level errors, component-level errors, logic-level errors, or unknown types of errors. Based on the error type and the number of attempts, a severity level is obtained through a severity assessment method. The severity assessment method includes determining a baseline severity based on the error type; calculating an attempt penalty based on the number of attempts; adding the baseline severity to the attempt penalty to obtain a comprehensive severity; and determining the severity level based on the comprehensive severity. The severity levels include minor, moderate, severe, and fatal. Based on the error type and the severity, a repairability flag is obtained through a repairability determination method; the repairability determination method includes: if the severity level is not fatal and the error type belongs to a preset set of repairable errors, it is determined to be repairable; if the severity level is fatal, or the error type does not belong to the preset set of repairable errors, it is determined to be unrepairable; the preset set of repairable errors includes parameter-level errors and component-level errors; Based on the key error features, a feature string is constructed and normalized to generate an error feature signature; the key error features include target component identifier, operation action type, error type, error parameter name, and error message keywords; the normalization process includes converting to lowercase, removing special characters, and sorting by alphabetical order.

5. The intelligent function call method with error self-correction capability according to claim 1, characterized in that, Based on corrective tags, the experience knowledge base is queried using error signatures as keys to obtain reusable correction results, specifically including: If the corrective flag is correctable, then the experience knowledge base is queried using the error signature as the key, and the historical successful correction information obtained from the query is added to the set of reuse candidate solutions. If the set of reuse candidate solutions is not empty, the reuse correction result is that there is historical successful correction information, and the historical successful correction information with the highest number of successful applications in the set of reuse candidate solutions is used as the correction function call information. If the set of reuse candidate schemes is empty, the edit distance algorithm is used to calculate the signature similarity between the error feature signature and each historical error feature signature in the experience knowledge base, and the historical successful correction information corresponding to the signature similarity exceeding the preset signature similarity threshold is added to the set of similar candidate schemes. If the set of similar candidate solutions is not empty, the reusability correction result is that there is historical successful correction information, and the historical successful correction information corresponding to the highest signature similarity in the set of similar candidate solutions is used as the correction function call information; If the repairability is marked as unrepairable, or the set of similar candidate solutions is empty, then the reusability correction result is that there is no historical successful correction information.

6. The intelligent function call method with error self-correction capability according to claim 4, characterized in that, If the reusability correction result indicates the absence of historical successful correction information, then correction function call information is generated based on the structured error description information through a multi-level correction strategy, specifically including: The target correction level is determined based on the error type and number of attempts in the structured error description information; the target correction level includes a first level, a second level, and a third level; When the target correction level is the first level, a parameter fine-tuning strategy is adopted. The parameter fine-tuning strategy includes keeping the target component identifier and operation action type unchanged, correcting the call parameter dictionary based on the error type and error description according to the large language model, generating a corrected call parameter dictionary, and using the target component identifier, operation action type, and corrected call parameter dictionary as correction function call information. When the target correction level is the second level, a component or action replacement strategy is adopted. The component or action replacement strategy includes calculating the cosine similarity between the task requirement text and the functional descriptions of all available components from the preset system component registry, selecting the component or action corresponding to the highest cosine similarity as the corrected target component identifier and the corrected operation action type; adjusting the call parameter dictionary accordingly based on the corrected target component identifier and the corrected operation action type to obtain the corrected call parameter dictionary; and using the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary as the corrected function call information. When the target correction level is the third level, a function call information reconstruction strategy is adopted. The function call information reconstruction strategy includes replanning the execution path based on historical attempt records, task requirement text, and preset system component registry through a large language model, generating a reconstruction target component identifier, reconstruction operation action type, and reconstruction call parameter dictionary, and using the reconstruction target component identifier, reconstruction operation action type, and reconstruction call parameter dictionary as the correction function call information. The historical attempt records include the target component identifier, operation action type, call parameter dictionary, and failure reason for each attempt.

7. The intelligent function call method with error self-correction capability according to claim 6, characterized in that, The target correction level is determined based on the error type and number of attempts in the structured error description information, specifically including: If the error type is a parameter-level error and the number of attempts is less than or equal to the first attempt threshold, then the target correction level is determined to be the first level; the parameter-level error includes parameter name error, parameter value error, type error, or parameter missing error; If the error type is a parameter-level error, and the number of attempts is greater than the first attempt threshold and less than or equal to the second attempt threshold, or if the error type is a component-level error, then the target correction level is determined to be the second level; the component-level error includes errors such as the component not existing or the action not supporting the function. If the error type is a logical error, or an unknown error, or the number of attempts exceeds the second attempt threshold, then the target correction level is determined to be the third level; the logical errors include business logic conflict errors, precondition failure errors, or calculation anomaly errors.

8. The intelligent function call method with error self-correction capability according to claim 1, characterized in that, The methods for updating and maintaining the experience knowledge base specifically include: After the correction function call information is executed successfully, query the experience knowledge base to see if the error signature before the execution of the correction function call information already exists. If it already exists, update the number of successful applications and the last time of use corresponding to the error signature before executing the correction function call information; If it does not exist, then determine whether the current capacity of the experience knowledge base is less than the preset capacity threshold. If the current capacity is less than the preset capacity threshold, the error signature before executing the correction function call information, the target component identifier in the correction function call information, the operation action type and the call parameter dictionary will be directly added to the experience knowledge base as new historical successful correction information. If the current capacity is greater than or equal to the preset capacity threshold, then first delete the historical successful correction information that has not been used for a preset number of days and has a success count lower than the preset success count threshold, and then add the error signature before executing the correction function call information, the target component identifier in the correction function call information, the operation action type and the call parameter dictionary as new historical successful correction information to the experience knowledge base.

9. The intelligent function call method with error self-correction capability according to claim 1, characterized in that, After the circuit breaker condition is triggered, the process also includes: generating a user-friendly prompt message; the user-friendly prompt message includes a failure reason explanation generated based on the error type; an attempt history summary generated based on the number of attempts and historical attempt records; similar historical successful correction information obtained by querying the experience knowledge base based on the task requirement text; and next step operation suggestions generated based on the error type and similar historical successful correction information.

10. An intelligent function call system with error self-correction capability, characterized in that, The intelligent function call system with error self-correction capability applies the intelligent function call method with error self-correction capability according to any one of claims 1-6, wherein the intelligent function call system with error self-correction capability comprises: The intent parsing module is used to obtain the task requirement text described by the user in natural language, and determine the function call information based on the task requirement text; the function call information includes the target component identifier, the operation action type, and the call parameter dictionary; The execution verification module is used to verify function call information and execute the function call information after successful verification. The error semantic analysis module is used to capture verification failure information or exception information if verification fails or an exception is thrown when executing function call information, and generate structured error description information. The structured error description information includes error type, severity level, corrective flag, error signature, number of attempts, and historical attempt records. The experience knowledge base module is used to query the experience knowledge base based on corrective tags and using error signatures as keys to obtain reusable correction results; the experience knowledge base includes error signatures and corresponding historical successful correction information; the historical successful correction information includes the corrected target component identifier, the corrected operation action type, and the corrected call parameter dictionary; The intelligent correction decision module is used to directly use the corresponding historical successful correction information as the correction function call information if the reusable correction result shows that there is historical successful correction information; if the reusable correction result shows that there is no historical successful correction information, it generates correction function call information based on the structured error description information through a multi-level correction strategy; the multi-level correction strategy includes parameter fine-tuning strategy, component or action replacement strategy, and function call information reconstruction strategy. The retry management and circuit breaker module is used to take the corrected function call information as the function call information and return to the step "Based on the function call information, obtain the verification result through a preset verification method, and execute the function call information when the verification result is passed", until the function call information is successfully executed or the circuit breaker condition is triggered; the circuit breaker condition includes the cumulative number of occurrences of the same error signature reaching a preset threshold.

Images