Agent skill failure mode memory method based on tool execution feedback

Abstract

The application discloses an agent skill failure mode memory method based on tool execution feedback, and comprises the following steps: when agent calling external tool execution fails, corresponding failure context information is collected, is structured and coded into a failure mode unit, and is stored in a failure memory storage subsystem; before the agent generates a new tool calling plan and executes a target tool, a pre-check engine is triggered to retrieve a matched historical failure mode unit, and a comprehensive risk score is calculated; according to the comprehensive risk score, a corresponding intervention strategy is determined, and the intervention strategy is executed on the target tool; according to feedback information generated after the execution of the intervened target tool, the confidence and the matching count of the corresponding failure mode unit in the failure memory storage subsystem are updated; the application solves the problem that the same type of failure repeatedly occurs when the agent calls external tools, and the failure experience is not precipitated and the pre-risk prediction mechanism is lacking, resulting in a low tool calling success rate.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically to a method for memorizing agent skill failure patterns based on tool execution feedback. Background Technology

[0002] With the rapid development of large language model agent technology, tool invocation has become the core mechanism for agents to extend their capabilities and interact with the outside world. Agents complete complex tasks beyond plain text generation by calling external tools such as API interfaces, database queries, code executors, and file systems. The reliability of the tool invocation chain has become a key factor affecting agent execution efficiency, task success rate, and operational security.

[0003] Current mainstream agent memory systems primarily use dialogue history or facts extracted from it as core memory objects, focusing on hierarchical storage and retrieval of known information. They fail to structurally store the condition-anomaly mapping of tool calls as an independent memory type. Even some self-reflective solutions only store failure reflections in unstructured natural language, lacking precise structured representations of key information such as failure parameter combinations, environment snapshots, and anomaly signatures, thus failing to support fast and accurate conditional matching retrieval. In terms of failure handling, existing technologies generally adopt a passive paradigm of recovery after execution failure. They often rely on exponential backoff retries, parameter format correction, and dynamic injection of auxiliary context after failure for post-event remediation. The error correction process is only triggered after the agent actually encounters failure, failing to proactively avoid potential risks based on historical experience during the planning phase. This trial-and-error model poses significant security risks in high-cost, irreversible operation scenarios such as financial transactions and data deletion.

[0004] Meanwhile, because failure experiences are mostly stored in unstructured form, agents can only perform fuzzy searches based on semantic similarity when faced with new tasks. They cannot achieve precise matching based on structured conditions such as specific parameter values ​​and environmental indicators, making it difficult to accurately map historical failure experiences to the current execution scenario. This leads to the recurrence of similar failures, resulting in low reuse value of failure experiences. In addition, current technologies have not yet formed a complete engineering closed loop from failure detection, condition structuring, memory storage, pre-detection matching, proactive intervention to effect feedback. The valuable experience gained from failure handling cannot effectively feed back into subsequent planning and decision-making. Agents cannot continuously learn from failures and strengthen their risk avoidance capabilities, and cannot achieve self-iterative optimization of the system.

[0005] In summary, the existing Agent tool invocation system lacks structured failure mode memory, proactive risk prediction, and closed-loop iteration mechanisms, making it difficult to effectively reduce tool invocation failure rates and failing to meet the high reliability and high security requirements of Agent tool invocation chains in production environments. Summary of the Invention

[0006] This invention provides a method for remembering agent skill failure patterns based on tool execution feedback to solve the aforementioned technical problems, specifically employing the following technical solution: The Agent Skill Failure Pattern Memory Method based on Tool Execution Feedback includes the following steps: When the Agent receives feedback that the execution of an external tool has failed, the Agent collects the corresponding failure context information of the external tool call. The failure context information is structured and encoded into failure mode units and stored in the failure memory storage subsystem; After the Agent generates a new tool invocation plan and before the target tool is executed, the pre-inspection engine is triggered to retrieve historical failure mode units that match the current invocation context of the target tool from the failure memory storage subsystem, and calculates the comprehensive risk score of the target tool invocation based on the retrieved historical failure mode units; Based on the comprehensive risk score, the corresponding intervention strategy is determined, and the intervention strategy is implemented on the target tool; Based on the feedback information generated after the target tool is executed following the intervention, the confidence level and match count of the corresponding failure mode unit in the failure memory storage subsystem are updated.

[0007] Furthermore, the failure context information is structured and encoded into failure mode units, including: Perform multi-level error classification on the failure context information to determine the major error category, sub-error category, exception type, and attribution label of the failure of external tool calls; Extract key condition combinations from failure context information to generate standardized conditional expressions; The standardized conditional expressions, the classification results of multi-level error classification, and the preset repair suggestion information are assembled into a failure mode unit.

[0008] Furthermore, key condition combinations are extracted from the failure context information using a large language model condition extractor to generate standardized conditional expressions, specifically including: Construct constraint prompts and input them into a large language model, and perform format validation on the raw output of the large language model; The atomic conditions that pass the verification are combined and normalized according to the logical relationship in the original output to generate standardized conditional expressions. When the confidence level of the original output is lower than the preset threshold or the number of condition items discarded during format validation exceeds the preset proportion, the rule rollback mechanism is triggered, and the classification results of multi-level error classification are mapped to the preset general condition template by looking up the table.

[0009] Furthermore, the failure memory storage subsystem employs a hybrid storage architecture to index failure mode units, including: Store the structured fields of the failure mode unit in a structured storage layer and create a structured index; The description text of the failure mode unit is encoded into a semantic vector and stored in the vector storage layer, and a semantic similarity index is established. An inverted index and a Bloom filter are built for the preset high-frequency retrieval dimensions as an index acceleration layer.

[0010] Furthermore, the pre-detection engine calculates a comprehensive risk score, specifically including: Using the current calling context of the target tool as the query condition, retrieve the K most similar historical failure pattern units from the failure memory storage subsystem as a candidate set; The historical matching degree is calculated based on the mixed similarity score and ranking weight of each candidate failure mode unit in the candidate set; Expand the conditional expression of the failure mode unit with the highest similarity in the candidate set into disjunctive normal form, decompose it into multiple conjunctive clauses, calculate the satisfaction of each conjunctive clause in the current calling context, and take the maximum value of the satisfaction of all conjunctive clauses as the condition triggering degree. The environmental risk level is calculated by weighting system load, network latency, and dependent service health indicators in the current environment. The comprehensive risk score is obtained by weighting and summing the historical matching degree, condition triggering degree, and environmental risk degree.

[0011] Furthermore, the satisfaction of each conjunction clause in the current calling context is calculated, including: For each atomic condition in the conjunction clause, extract the actual value of the corresponding field in the current calling context, match the actual value with the threshold of the atomic condition according to the operator type of the atomic condition, and output the degree of satisfaction of the atomic condition. The satisfaction of each atomic condition within the conjunction clause is weighted and aggregated to determine the satisfaction of the conjunction clause in the current calling context.

[0012] Furthermore, the triggering timing of the pre-detection engine includes: Plan-level pre-inspection is triggered after the Agent generates a new tool invocation plan and before the first tool is executed, and is used to perform batch risk scanning on all tool invocations; Step-level pre-inspection is triggered momentarily before each tool invocation step is executed, and is used to perform a final interception check on the target tool; Dynamic pre-check is triggered when an unexpected change in the environment is detected during the execution of a new tool call plan. It is used to predict the risk of re-executing subsequent tool calls that have been planned but not yet executed.

[0013] Furthermore, dynamic pre-detection also includes: Before the Agent initiates the execution of a new tool invocation plan, the new tool invocation plan is divided into transaction groups, and execution checkpoints are generated and persisted before the execution of each transaction group. When dynamic pre-detection determines that there is a risk of blocking subsequent steps and that the executed steps have produced side effects, rollback compensation or suspension of manual review will be performed according to the configuration type of the transaction group to which the executed steps belong. Once the abnormal conditions that triggered the dynamic pre-check are resolved, the execution environment is restored from the execution checkpoint, and the completed steps are skipped to continue execution.

[0014] Furthermore, based on the comprehensive risk score, corresponding intervention strategies are determined, specifically including: When the comprehensive risk score is higher than the first preset threshold, the execution strategy is determined to block the execution of the target tool, a blocking prediction report is generated, and the Agent is triggered to execute the replanning process. When the comprehensive risk score is higher than the second preset threshold but not higher than the first preset threshold, the tool switching strategy is determined, the target tool is switched to a similar alternative tool, parameter mapping is performed and then execution continues. When the comprehensive risk score is higher than the third preset threshold but not higher than the second preset threshold, it is determined to be a prompt injection strategy, and risk prompt information is injected into the Agent's current execution context; When the overall risk score is not higher than the third preset threshold, it is determined to be a no-intervention strategy, allowing the target tool to be executed normally.

[0015] Furthermore, the target tool can be switched to a functionally similar alternative, including: Calculate the initial functional similarity between tools based on the metadata of the registered tools, and construct a tool similarity graph; The system queries alternative tools with similar functions to the target tool using a tool similarity graph, converts the target tool's call parameters into a parameter format recognizable by the alternative tools, performs the switch, and dynamically updates the weights of the edges in the tool similarity graph based on the actual execution results of the tool switch.

[0016] Furthermore, the confidence level and match count of the corresponding failure mode unit in the failure memory storage subsystem are updated, including: When the feedback information generated after the intervention strategy is executed indicates that the execution was successful and the intervention strategy is adopted, the confidence of the corresponding failure mode unit is positively adjusted and its matching count is incremented. When the intervention strategy is blocked and the Agent successfully executes the replanning process triggered after the blocking, the matching count of the corresponding failure mode unit is incremented. When feedback information generated after the intervention strategy is executed indicates that the execution has failed and the intervention strategy has been executed, failure attribution arbitration is triggered. The responsibility attribution category is determined based on three dimensions: the agent's compliance with the intervention strategy, the condition coverage of the failure mode unit by the execution failure context, and the degree of environmental anomaly.

[0017] Furthermore, differentiated feedback is implemented based on the category of responsibility attribution, specifically as follows: If it falls under the category of Agent non-compliance, a new failure mode unit with the associated non-compliance tag will be generated; If the condition coverage is insufficient, the original cell is retained and a new cell is generated to record the current failure condition. If the prediction is accurate but the strategy is ineffective, the confidence level should be reduced. If it belongs to an unexpected environmental anomaly, then the conditional expression of the original unit is expanded.

[0018] The advantages of this invention are: This solution can proactively identify and avoid high-risk tool calls during the planning phase, effectively reducing the tool call failure rate and minimizing retry overhead and time waste caused by call failures. This solution targets irreversible operations such as data deletion, fund transfer, and configuration changes. It can block high-risk calls before execution through blocking strategies, fundamentally avoiding irreversible losses. This solution relies on a complete failure learning and prevention closed loop, enabling the agent to extract knowledge from each failure and optimize subsequent decisions. As usage time increases, the system's risk prediction accuracy continues to improve, achieving continuous self-evolution of the agent.

[0019] Meanwhile, this solution achieves proactive failure prevention through lightweight retrieval and scoring, eliminating the need for multiple calls to the large language model for reflection and replanning, significantly reducing the token consumption and API call costs of the large language model. Structured failure mode records construct a clear and traceable failure mode knowledge base, facilitating administrators to query historical failure types, frequencies, and remediation strategies, providing data support for system optimization and enhancing system interpretability. Furthermore, this solution is not dependent on specific agent frameworks or tool types, seamlessly integrating with mainstream agent frameworks and supporting failure prevention for various tools such as API calls, database operations, and code execution, demonstrating good versatility and scalability. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the Agent Skill Failure Pattern Memory Method based on Tool Execution Feedback of the present invention; Detailed Implementation

[0022] Embodiments of the present invention are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0023] like Figure 1 The diagram illustrates the Agent Skill Failure Mode Memory Method based on Tool Execution Feedback of this Application, which includes the following steps: Step 1: When the Agent receives feedback that the execution failed after calling an external tool, collect the corresponding failure context information of the external tool call; Step 2: The failure context information is structured and encoded into failure mode units and stored in the failure memory storage subsystem; Step 3: After the Agent generates a new tool invocation plan and before the target tool is executed, the pre-inspection engine is triggered to retrieve historical failure mode units that match the current invocation context of the target tool from the failure memory storage subsystem, and calculates the comprehensive risk score of the target tool invocation based on the retrieved historical failure mode units; Step 4: Determine the corresponding intervention strategy based on the comprehensive risk score, and implement the intervention strategy for the target tool; Step 5: Based on the feedback information generated after the target tool is executed, update the confidence level and matching count of the corresponding failure mode unit in the failure memory storage subsystem.

[0024] This invention provides an Agent skill failure mode memory method based on tool execution feedback, which can be deployed in various LLM Agent runtime engines and is adaptable to multiple tool call scenarios such as API calls, database operations, code execution, and file system interactions. Addressing the technical problems of existing Agent systems where tool call failure experience is difficult to reuse in a structured manner and failure handling can only be passively recovered afterward, this invention constructs a complete closed loop of structured failure memory storage, pre-inspection and prediction during the planning phase, hierarchical intervention execution, and effect feedback iteration. This transforms Agent tool call failure handling from passive error correction to proactive prevention, enabling the computational, retrieval, reusability, and continuous self-evolution of failure experience. The method as a whole uses failure mode units as the core memory carrier, a failure memory storage subsystem as the knowledge foundation, a pre-inspection engine as the risk prediction core, and an intervention router as the strategy execution unit. Combined with a differentiated feedback update mechanism, it forms a continuously evolving failure learning closed loop, significantly improving the reliability and security of Agent tool calls while ensuring task execution efficiency. The following details the above steps.

[0025] For step 1, when the feedback information after the Agent calls the external tool is that the execution failed, the corresponding failure context information of the external tool call is collected.

[0026] Specifically, this data collection process is triggered by the execution monitoring module embedded in the Agent runtime engine. When the monitoring module detects a failure in a tool call, it first captures the complete exception information returned by the tool, including the exception type, exception message, timeout flag, and stack summary. The exception type can correspond to a Python exception class name or an HTTP status code for the API call. This allows for preliminary identification of the failure attribute from an error classification perspective. It preserves the core characteristics of the exception scenario immediately after a failure occurs, preventing the loss of failure information due to execution chain resets. This provides the most direct and original basis for subsequent error classification and cause attribution, ensuring complete traceability for every failure event.

[0027] Based on this, the execution monitoring module synchronously collects the full-link execution context at the moment of failure, specifically covering the Agent's original task input, target tool identifier, actual call parameter values, current environment variables and system operation indicators, the sequence of executed preceding tools and their output summaries. This fully reconstructs the overall execution environment and task chain at the time of failure, breaking through the limitation of only collecting abnormal information. It also covers the direct manifestations of failure and indirect influencing factors such as task objectives, parameter configurations, operating environment, and preceding execution status. This supports the subsequent accurate extraction of failure triggering conditions and the construction of structured failure mode units, avoiding one-sided failure attribution and omission of key variables in condition extraction due to missing context information.

[0028] For sensitive fields that may contain user privacy or system secrets in the collected actual parameter values, such as user ID, phone number, token, and file path, the system performs deterministic desensitization processing based on hashing during the collection phase. The system calculates the SHA-256 hash value of the original value of the sensitive field and uses the calculated hash value to replace the original value in subsequent storage and matching calculations. This processing method ensures that the original sensitive information will not appear in any operation logs or failure storage units, avoiding the risk of sensitive information leakage from the source of data collection. It adapts to data security management standards in production environments and meets compliance requirements for data security and privacy protection. Simultaneously, relying on the deterministic characteristics of hash operations, the same original parameter value will generate completely consistent hash results in different failure events. The system can still identify matching scenarios with the same parameter value based on the hash value. For example, in scenarios where the same user identity repeatedly triggers call failures due to insufficient permissions, accurate matching can be achieved through hash value consistency. This process retains the ability to determine parameter identity while completing desensitization, achieving a balance between data security and the accuracy of failure mode identification.

[0029] For conditions involving numerical ranges (such as timeout > 30000), threshold comparisons, and data structure patterns (such as array length > 10), the system does not perform desensitization processing, retaining the original numerical values ​​of the fields. This ensures that numerical comparisons and logical operations in structured conditional expressions are not affected by the numerical mapping of desensitization processing, guaranteeing the matching accuracy of quantitative conditions such as timeout thresholds and data volume, and providing an accurate numerical basis for subsequent condition trigger degree calculations and risk scoring.

[0030] The above steps, as the initial data collection stage of the entire failure mode memory method, provide complete, accurate, and compliant raw data input for the subsequent construction of structured failure mode units through the synchronous collection of anomalies and contextual information across all dimensions and the sensitive data anonymization processing of hierarchical classification. This ensures the comprehensiveness of failure experience extraction and the compliance of data processing from the source, and is the basic prerequisite for realizing structured storage, accurate retrieval, and proactive prediction of failure experience, supporting the stable and reliable operation of the entire failure learning closed loop.

[0031] For step 2, the failure context information is structured and encoded into failure mode units and stored in the failure memory storage subsystem. This includes: performing multi-level error classification on the failure context information to determine the error category, error subcategory, exception type, and attribution label of the failure of external tool calls; extracting key condition combinations from the failure context information to generate standardized condition expressions; and assembling the standardized condition expressions, the classification results of multi-level error classification, and the preset repair suggestion information into failure mode units.

[0032] Furthermore, the key condition combinations are extracted from the failure context information by the large language model condition extractor to generate standardized condition expressions. Specifically, this includes: constructing constraint prompts and inputting them into the large language model; performing format validation on the original output of the large language model; combining and normalizing the validated atomic conditions according to the logical relationships in the original output to generate standardized condition expressions; and triggering a rule fallback mechanism when the confidence level of the original output is lower than a preset threshold or the number of condition items discarded by format validation exceeds a preset proportion, based on the classification results of multi-level error classification, by looking up a table to map to a preset general condition template.

[0033] Furthermore, the failure memory storage subsystem adopts a hybrid storage architecture to index failure mode units, including: storing the structured fields of failure mode units in a structured storage layer and building a structured index; encoding the description text of failure mode units into semantic vectors and storing them in a vector storage layer and building a semantic similarity index; and constructing inverted indexes and Bloom filters as index acceleration layers for preset high-frequency retrieval dimensions.

[0034] Specifically, the multi-level error classification adopts a four-level progressive classification system, gradually converging the causes of failure from macro to micro levels.

[0035] The first level is the error categories, which include four types: parameter errors, environment errors, logic errors, and external errors, covering the four core causes of tool call failures.

[0036] The second level consists of error subcategories. The parameter error category includes missing parameters, type or format mismatch, parameter value out of bounds, and parameter dependency conflict; the environment error category includes insufficient resources, abnormal runtime configuration, abnormal dependent environment, and abnormal local network; the logic error category includes abnormal control flow, abnormal data processing, abnormal state consistency, and abnormal tool orchestration; and the external error category includes timeout, authentication failure, rate limiting, and service unavailability.

[0037] The third level represents specific exception types, corresponding to the specific exception behaviors under each subclass. Under the parameter error category, the missing parameter subclass includes missing required parameters and empty parameter values; the type or format mismatch subclass includes data type mismatch, incorrect date or encoding format, and serialization failure; the parameter value out of bounds subclass includes values ​​exceeding the allowed range, string length exceeding the limit, and illegal enumeration values; and the parameter dependency conflict subclass includes the simultaneous occurrence of mutually exclusive parameters, missing prerequisite parameters, and parameter combinations not meeting tool call constraints. Under the environment error category, the insufficient resource subclass includes insufficient memory, insufficient disk space, excessive CPU load, and connection pool exhaustion; the runtime configuration exception subclass includes missing environment variables, non-existent file paths, occupied ports, and insufficient local access permissions; the dependency environment exception subclass includes missing dependency libraries, dependency version conflicts, runtime version incompatibility, and container startup failure; and the local network exception subclass includes network disconnection, domain name resolution failure, and proxy configuration errors. Under the category of logical errors, the control flow exception subclasses include infinite loops, recursion depth exceeding limits, and branch condition errors; the data processing exception subclasses include null object references, array out-of-bounds errors, non-existent key-value pairs, and data conversion failures; the state consistency exception subclasses include state conflicts, duplicate execution, transaction conflicts, and cached state expiration; and the tool orchestration exception subclasses include incomplete prerequisite steps, incorrect tool execution order, and incompatibility between the output of the previous tool and the input of the next tool. Under the category of external errors, the timeout subclasses include connection timeouts, read timeouts, query timeouts, and execution timeouts; the authentication failure subclasses include unauthenticated, invalid credentials, expired credentials, signature verification failure, and insufficient authorization scope; the rate limiting subclasses include exceeding the request frequency limit per unit time, exceeding the concurrent request limit, and exhausting the call quota; and the service unavailability subclasses include external service downtime, gateway errors, unavailability of upstream dependencies, and interface return exceptions.

[0038] The fourth level is the error attribution label, which indicates the root cause of a specific exception. Error attribution labels include: missing required fields, inconsistent parameter schemas, incorrect units of measurement, illegal enumeration values, conflicting parameter combinations, insufficient memory quota, insufficient disk space, unconfigured environment variables, missing dependencies, incompatible dependency versions, incorrect proxy addresses, circular references, missing termination conditions, unvalidated null values, out-of-sync status, duplicate submissions, incorrect tool dependency configuration, missing indexes, network congestion, excessively short timeout settings, expired credentials, insufficient permission scope, excessive call frequency, exhausted account quotas, and upstream service failures.

[0039] The system determines the major error category, subcategory, and specific exception type based on the exception class name, HTTP status code, tool return error code, exception message keywords, tool parameter schema, and environmental indicators at the time of failure, according to a preset classification mapping table. It then generates one or more error attribution tags by combining the actual call parameters, execution stack, and environmental state, forming a standardized classification path: major error category - subcategory - specific exception type - error attribution tag. For example, when a database query times out due to a missing index, the corresponding classification path is: External Error - Timeout - Query Timeout - Missing Index; when a third-party interface returns an HTTP 401 status code due to expired access credentials, the corresponding classification path is: External Error - Authentication Failure - Unauthenticated - Expired Credentials; when code execution continues due to a circular reference in the input data, the corresponding classification path is: Logical Error - Control Flow Anomaly - Infinite Loop - Circular Reference. This four-level classification system forms a coarse-to-fine failure cause localization link, providing a unified classification benchmark for subsequent condition extraction and rule rollback, and providing standardized dimensional support for failure mode classification retrieval, statistical analysis, and remediation suggestion matching.

[0040] The large language model condition extractor uses a three-stage pipeline architecture to achieve accurate extraction of key conditions.

[0041] First, constraint prompt words are constructed. Specifically, the extractor dynamically generates system-level prompt words based on the target tool's metadata, including the tool name and parameter schema definition, combined with predefined conditional expression syntax. Three mandatory constraints are set in the prompt words: The first is an output format constraint, which mandates that the large language model output structured data conforming to the JSON schema, and must include three top-level fields: condition list, logical relationship, and confidence score, thus locking in structured results from the output format. The second is a field whitelist constraint, which restricts the large language model to only refer to parameter names and environment variable names defined in the tool schema, prohibiting the creation of non-existent condition fields, thereby compressing the illusion space of the large language model from the root. The third is a few-sample example injection, injecting 3 to 5 typical failure scenario condition extraction examples related to the current tool type into the prompt words, covering common failure types such as timeout, permission, and data format, guiding the large language model to accurately identify the core condition combinations that lead to failure through contextual learning, reducing interference from irrelevant information.

[0042] After constructing the prompt words and obtaining the raw output of the large language model, structured output parsing and constraint decoding are performed. Specifically, the decoder first verifies whether the raw output is in a valid JSON format. Then, it verifies each condition object in the condition list, confirming that it contains three required subfields: field name, operator, and threshold. The operators must belong to a predefined set of valid operators, covering common operation types such as eq (equal to), ne (not equal to), gt (greater than), lt (less than), gte (greater than or equal to), lte (less than or equal to), contains, matches, exists, and empty. For output content that does not conform to the schema specification, such as field names not being in the whitelist or operators having spelling errors, the decoder automatically performs nearest-neighbor correction, mapping semantically similar illegal operators to valid operators. For example, the symbol > is corrected to the standard operator gt. Uncorrectable abnormal conditions are discarded, and correction logs are recorded synchronously. This process constrains the freely generated results of the large language model within a standard grammar system, preventing format errors from causing subsequent condition matching logic to fail. Simultaneously, by performing nearest-neighbor correction, it preserves as much valid condition information as possible, improving the information utilization rate of the raw output.

[0043] Once the atomic conditions pass validation, they proceed to the condition expression compilation and normalization stage. Based on the logical relationship fields in the original output, the system combines all atomic conditions into a standard condition expression string and simultaneously performs three normalization processes: First, it merges semantically equivalent conditions, for example, unifying `timeout<=30000` and `timeout_ms<30001` into `timeout_mslte 30000`, eliminating semantic redundancy caused by differences in expression; second, it removes redundant conditions, for example, when the same field has both `exists` and `empty` conditions, only the `empty` condition is retained to avoid duplicate constraints; third, it unifies the units of numerical conditions, for example, converting the time unit 5 minutes to 300 seconds, eliminating matching errors caused by unit differences. After normalization, failure conditions with the same semantics will correspond to a unified expression form, effectively avoiding duplicate storage of the same failure mode due to different expressions, improving the accuracy of subsequent condition matching, and providing a unified judgment standard for deduplication and merging of failure modes.

[0044] The extraction process synchronously incorporates confidence assessment and rule fallback mechanisms. The large language model outputs conditional expressions along with a confidence score ranging from 0 to 1. When the confidence score falls below a preset threshold of 0.6, or when the number of conditional items discarded during format validation exceeds 50% of the original input conditional items, the system determines that the large language model extraction result is unreliable and automatically triggers the rule fallback mechanism. Based on the aforementioned four-level error classification results, a lookup table maps the corresponding category's preset general condition template. For example, when the fourth-level attribution label is timeout, the fallback template is (execution_time gt historical_avg *2) OR (data_volume gt threshold), ensuring that even when the large language model output fails, the failure mode unit still possesses basic condition matching capabilities and will not generate empty or erroneous conditions due to the large language model's illusion, effectively improving the robustness of the entire extraction mechanism. Taking the database query timeout scenario as an example, the standardized conditional expression output after the complete extraction process is: (timeout_ms lte 30000 AND table_rows gt 10000000 AND join_count gte 3) OR (execution_plan_cost gt 5000). The confidence level of the large language model can reach 0.92, which meets the database entry criteria.

[0045] After generating the conditional expression, the system assembles the standardized conditional expression, the four-level error classification results, and the preset repair suggestion information into a complete failure mode unit. The preset repair suggestion information includes the repair strategy type, target adjustment object, repair action, suggested parameter values ​​or adjustment rules, execution priority, applicable conditions, repair result verification conditions, and repair failure rollback strategy. The preset repair suggestion information is indexed by a four-level error classification path consisting of error category, error subcategory, specific exception type, and error attribution label, and is pre-stored in the repair suggestion mapping table. For parameter errors, the repair actions include supplementing missing parameters, converting parameter types or formats, adjusting out-of-bounds parameters to a legal range, and deleting or adjusting conflicting parameters. For environmental errors, the repair actions include releasing system resources, supplementing environment variables, installing missing dependencies, switching dependency versions, correcting file paths, and switching execution nodes. For logical errors, the repair actions include adding loop termination conditions, limiting recursion depth, adding null values ​​or boundary checks, synchronizing execution status or rolling back transactions, and adjusting tool call order. For external errors, the repair actions include extending timeout periods, reducing the amount of data requested per request, using pagination, refreshing access credentials, requesting necessary permissions, retrying according to preset backoff times, reducing request frequency or concurrency, switching to backup service endpoints, and switching to alternative tools with similar functions. When multiple preset repair suggestions correspond to the same level four error classification path, the system sorts the candidate repair suggestions according to execution priority, historical repair success rate, and current execution environment adaptability, and selects at least one repair suggestion with the highest ranking to write into the failure mode unit. When no automatic repair suggestion meets the applicable conditions, manual intervention or execution blocking is set as the repair failure rollback strategy. The system generates a globally unique identifier for each failure mode unit, records the timestamp of the failure, and sets an initial confidence score and an initial match count. The assembled failure mode unit first undergoes a deduplication check, comparing its conditional expressions and error classifications with existing failure modes in storage. Once confirmed to be unique, it is stored in the failure memory storage subsystem.

[0046] The failure memory storage subsystem adopts a three-layer hybrid storage architecture, simultaneously considering structured precise retrieval, semantic similarity retrieval, and query performance. The first layer is the structured storage layer, which uses a relational database to store structured fields such as metadata, conditional expression JSON, and error classification information for failure mode units. It supports precise queries and range searches based on tool identifiers, error categories, and conditional field names, meeting the needs of scenarios requiring precise condition matching. The second layer is the vector semantic layer, which encodes the failure description, repair suggestions, and conditional expression text of failure mode units into semantic vectors through an embedding model and stores them in a vector database. This supports semantic similarity retrieval, matching failure scenarios with different descriptions but similar semantics, compensating for the insufficient generalization ability of pure structured matching. The third layer is the index acceleration layer, which builds inverted indexes and Bloom filters for high-frequency retrieval dimensions such as tool identifiers, primary error categories, and conditional field names, achieving sub-millisecond fast filtering, significantly improving retrieval efficiency, and adapting to the high real-time requirements of the planning phase pre-check. The three-layer architecture works in concert to ensure the accuracy of condition matching through structured storage, cover semantically similar scenarios through the vector semantic layer, and ensure retrieval performance through the index layer, providing a stable and efficient knowledge foundation for the subsequent pre-detection engine to quickly predict risks.

[0047] The aforementioned structured encoding and storage mechanism achieves standardized hierarchical localization of failure causes through a four-level error classification system, providing a unified judgment benchmark for condition extraction, classification retrieval, and problem statistics. This solution combines a large language model condition extraction pipeline with constraint decoding and rule backoff, accurately identifying failure trigger conditions while avoiding model illusions and output failure risks. Furthermore, condition normalization eliminates redundancy and matching errors caused by expression differences, efficiently transforming unstructured failure contexts into standardized, computable failure mode units. The three-layer hybrid storage architecture simultaneously considers structured precise matching, semantic similarity retrieval, and high-frequency query performance, ensuring both the accuracy of condition matching and coverage of semantically similar generalized scenarios. Ultimately, it achieves the structured accumulation and efficient reuse of failure experience, providing a stable and reliable knowledge foundation for proactive risk pre-detection in the subsequent planning phase.

[0048] For step 3, after the Agent generates a new tool invocation plan and before the target tool is executed, the pre-inspection engine is triggered to retrieve historical failure mode units that match the current invocation context of the target tool from the failure memory storage subsystem, and calculates the comprehensive risk score of the target tool invocation based on the retrieved historical failure mode units.

[0049] The aforementioned pre-detection engine is the core component of this invention, enabling a shift from passive error correction to proactive prevention. Its core function is to predict risks based on historical failure experience before the tool is actually executed, thus avoiding known failure scenarios at their source. This step follows an execution chain of trigger initiation, retrieval and matching, quantitative scoring, and output results. Specifically: first, the pre-detection process is initiated according to preset trigger rules; then, the retrieval capabilities of the failure memory storage subsystem are invoked to match historical failure patterns; subsequently, a comprehensive risk score is calculated using a multi-dimensional quantitative model; and finally, the score result is output to the intervention router, providing a quantitative basis for the selection of subsequent tiered intervention strategies. This step connects the front-end failure memory storage with the back-end proactive intervention, and is the core execution link for knowledge reuse in the entire failure learning closed loop.

[0050] The pre-inspection engine is triggered at the following times: Plan-level pre-inspection, triggered after the Agent generates a new tool invocation plan and before the first tool is executed, performing a batch risk scan of all tool invocations; Step-level pre-inspection, triggered instantaneously before each tool invocation step is executed, allowing for final interception checks of the target tool; and Dynamic pre-inspection, triggered when an unexpected change in the environment is detected during the execution of a new tool invocation plan, allowing for re-evaluation of risks for planned but not yet executed subsequent tool invocations. This three-tiered pre-inspection mechanism forms a progressive risk defense line of coarse screening, fine inspection, and dynamic adaptation. Each level has clearly defined trigger conditions to ensure the accuracy and necessity of pre-inspection triggering. Specifically: As a preliminary screening step for global risks, the plan-level pre-screening has three triggering scenarios: First, the plan contains at least one tool (n≥1), satisfying the basic pre-screening prerequisite; second, the plan contains at least one high-risk tool identifier with historical failure records, and a batch scan is triggered by querying the failure mode unit count of the corresponding tool in the failure memory storage subsystem if the count>0; third, there are data dependencies between preceding and subsequent steps in the plan, i.e., the input of subsequent steps depends on the output of preceding steps, triggering a cascading risk scan to prevent single-step failures from causing anomalies in the entire chain. A single round of plan-level pre-screening typically takes <200ms, quickly identifying high-risk steps and cascading risk paths before task startup, providing a basis for the agent to adjust its planning scheme in advance, reducing path changes during execution, lowering the overall failure risk at the task-wide level, and avoiding efficiency losses caused by frequent planning adjustments during execution.

[0051] Step-level pre-checks, as the final fine-tuning step before execution, are triggered instantaneously before each tool call step. The criteria for judgment also include three categories: First, the tool identifier for the current step has a matching failure mode unit in the failure memory storage subsystem, and the structured or semantic similarity threshold is >0.4, providing historical failure reference data; second, external environmental indicators that the current step relies on, such as network latency and the number of available connections in the database connection pool, trigger a preset fluctuation alarm threshold, indicating a deteriorating environmental state; third, the current step involves mandatory pre-check flags configured for irreversible operations, such as high-risk interfaces like data deletion and fund transfers, which are forcibly executed regardless of whether historical failure records are matched. Each step-level pre-check takes less than 50ms, capturing subtle contextual changes and environmental fluctuations from plan generation to actual execution, forming the final risk interception defense line before tool execution.

[0052] Dynamic pre-detection is an event-driven, real-time adaptation mechanism that is triggered when the environment changes unexpectedly during the execution of a plan. It allows for the re-assessment of risks for all planned but not yet executed subsequent steps without waiting for the next planning cycle. The triggering events are mainly divided into three categories: First, variable mutation events, where key variable values ​​in the Agent context are unexpectedly modified by preceding steps, such as resetting pagination offsets in SQL statements or unexpected changes in parameter formats; second, external system alarm events, such as unavailability of monitoring middleware push dependent services, high response latency, and interface quota throttling; and third, timeout reassessment events, triggered when the actual execution time of a preceding step exceeds 150% of the expected value, leading to a reassessment of timeout risks for subsequent dependent steps. Dynamic pre-detection has the highest priority, with a response latency of <100ms. When triggered simultaneously with step-level pre-detection, the system pauses all ongoing step-level pre-detection tasks, prioritizes dynamic risk assessment, and then decides whether to continue execution or trigger transaction rollback based on the assessment results. This allows for rapid response to runtime environment mutations and avoids batch execution failures caused by environmental anomalies.

[0053] For tool call plans involving numerous steps, a three-tiered elastic acceleration strategy is implemented to prevent pre-checking from becoming a performance bottleneck. This optimizes pre-check efficiency in high-volume scenarios, ensuring comprehensive risk coverage while keeping pre-check overhead within acceptable limits, thus adapting to the production deployment needs of large-scale task plans. Specifically: The first category is parallel pre-checking and asynchronous batch processing: For parallel branch steps in the plan that do not have data dependencies, the system uses a coroutine pool to concurrently execute the failure memory storage subsystem for retrieval and risk scoring. The default concurrency is set to 16, which compresses the originally linearly increasing time consumption into a stepped time consumption that matches the concurrency. According to actual tests, the total pre-checking time of 50 independent steps can be compressed from 4.5s of sequential execution to less than 0.7s, which greatly improves the pre-checking efficiency of multi-parallel branch plans and avoids pre-checking becoming a performance bottleneck for task execution.

[0054] The second type is early termination pruning: In an execution chain with sequential dependencies, if the pre-inspection result of a certain step is extremely high risk and the corresponding intervention strategy is blocking, the system immediately terminates the pre-inspection calculation for all subsequent steps, directly returns the blocking report, and records the blocking prefix point so that the steps that have been evaluated can be skipped during subsequent recovery, avoiding unnecessary calculation overhead. In a sequentially dependent chain, the subsequent evaluation of high-risk paths is quickly terminated, which significantly shortens the pre-inspection response time of high-risk plans. At the same time, retaining the breakpoint information also saves the cost of repeated calculations for subsequent recovery execution.

[0055] The third category is pre-inspection result caching: For the same tool and parameter signature calls that have completed pre-inspection within the last 5 minutes, the system directly reuses the cached risk score results, skipping the storage retrieval and condition evaluation stages. When the cache is hit, the single-step pre-inspection time can be reduced to 0.1ms, which greatly reduces the performance loss in high-frequency repeated call scenarios. For business scenarios that frequently call the same tool and parameter, it can largely offset the additional overhead brought by pre-inspection.

[0056] As a further solution, dynamic pre-check also includes: before the Agent starts executing a new tool invocation plan, dividing the new tool invocation plan into transaction groups, and generating and persistently storing execution checkpoints before each transaction group is executed; when the dynamic pre-check determines that there is a risk of blocking subsequent steps and that the executed steps have produced side effects, performing rollback compensation or suspending manual review according to the configuration type of the transaction group to which the executed steps belong; when the abnormal conditions that triggered the dynamic pre-check are resolved, restoring the execution environment from the execution checkpoint and skipping the completed steps to continue execution.

[0057] Specifically, the preemptive triggering characteristic of dynamic pre-detection requires the system to have robust state consistency guarantees. The accompanying transaction grouping and checkpointing mechanisms ensure data consistency and recoverability before and after interruption. Before the Agent initiates the tool call plan execution, the system divides the entire plan into several transaction groups. By default, each atomic tool call is an independent transaction group. Users can also configure steps with strong data relationships to be bound to the same transaction group, such as combinations of operations requiring atomicity, like deductions and shipments. Before each transaction group executes, the system automatically generates execution checkpoints and persists them to a dedicated state table in the failure memory storage subsystem. Checkpoint records include the plan identifier, the index of currently completed steps, a snapshot of all context variables, and a summary of the output of executed steps. When dynamic pre-detection is triggered, the system immediately serializes the current execution progress into checkpoints and writes them to disk, ensuring that execution progress is not lost due to interruption.

[0058] When dynamic pre-inspection determines that subsequent steps pose a risk of blocking and that executed steps have already caused side effects such as data writing or configuration changes, the system will execute differentiated compensation strategies based on the transaction group's configuration type. For rollbackable transaction groups, the system queries a predefined compensation action mapping table to match the corresponding reverse operation for the executed operation. For example, if a temporary file has been created, the compensation action is to delete the temporary file; if a verification code has been sent, the compensation action is to mark the verification code as invalid. Compensation actions are queued and executed asynchronously to ensure eventual data consistency. For non-rollbackable transaction groups, such as sending formal notifications or writing audit logs—operations that cannot be undone—the system will not automatically roll back. Instead, it will mark the current checkpoint as pending manual review, suspend the planned execution, and push an alert to the operations console, awaiting manual decision-making or intervention from a preset approval process. For tools configured for irreversible operations, the system will force them to execute as a separate transaction group during the planned pre-inspection phase, and when dynamic pre-inspection is triggered, a blocking priority strategy will be adopted for such steps to minimize the risk of irreversible operations being mistakenly executed.

[0059] Once the abnormal conditions triggering the dynamic pre-check are resolved, such as the recovery of dependent services or the refresh of rate limiting rules, the system does not need to re-execute the entire plan from scratch. Instead, it restores the execution environment from the most recent valid execution checkpoint. The specific process consists of four steps: First, it verifies that the output of completed steps in the checkpoint is still valid and has not been modified externally, ensuring the reliability of the recovery foundation. Second, each execution step in the system is assigned a consecutive step index according to the execution order. The index corresponding to the last step that was successfully completed before the exception occurred is denoted as `last_completed_index`. The system skips all completed steps with an index ≤ `last_completed_index` and directly resets the current execution pointer to `last_completed_index + 1`, meaning it continues execution from the next pending step after the completed step, avoiding the duplication of completed tasks. Next, it loads the snapshot of context variables saved in the checkpoint to restore the execution environment before the interruption. Finally, after re-performing the pre-check for subsequent pending steps, it continues to advance the task. This breakpoint continuation mechanism can significantly reduce the overhead of repeated execution caused by environmental anomalies, and is especially suitable for long-cycle, high-cost task processes.

[0060] As a specific implementation method, the pre-detection engine calculates a comprehensive risk score, which includes: using the current calling context of the target tool as the query condition, retrieving the K most similar historical failure pattern units from the failure memory storage subsystem as a candidate set; calculating the historical matching degree based on the mixed similarity score and ranking weight of each candidate failure pattern unit in the candidate set; expanding the conditional expression of the most similar failure pattern unit in the candidate set into disjunctive normal form, decomposing it into multiple conjunctive clauses, calculating the satisfaction degree of the current calling context for each conjunctive clause, and taking the maximum value of the satisfaction degree of all conjunctive clauses as the condition trigger degree; calculating the environmental risk degree based on the system load, network latency, and dependent service health indicators of the current environment; and weighting and summing the historical matching degree, condition trigger degree, and environmental risk degree to obtain the comprehensive risk score.

[0061] Calculate the satisfaction of each conjunctive clause in the current calling context, including: for each atomic condition in the conjunctive clause, extract the actual value of the corresponding field in the current calling context, match the actual value with the threshold of the atomic condition according to the operator type of the atomic condition, and output the satisfaction of the atomic condition; weight and aggregate the satisfaction of each atomic condition in the conjunctive clause to obtain the satisfaction of the conjunctive clause in the current calling context.

[0062] Specifically, in actual execution, the pre-detection engine first calls the hybrid similarity retrieval interface of the failure memory storage subsystem to complete the retrieval and matching of candidate failure mode units. The failure memory storage subsystem has three built-in similarity calculation modes to adapt to different retrieval scenario requirements, specifically: The first type is Structured Similarity (Struct_Sim), which calculates the overlap of the set of conditional expressions based on the Jaccard coefficient. It combines the weights of the conditional fields with the operator matching degree to output a similarity score in the range of 0 to 1. It is suitable for scenarios where parameter values ​​can be precisely matched. Its calculation formula is as follows: , Among them, c i For the i-th atomic condition in the historical failure mode unit, c' i For the i-th atomic condition in the current tool invocation context, w i The field weights are the corresponding conditions, and match(*) is the condition satisfaction matching function, used to evaluate the degree to which the current actual value satisfies the historical atomic conditions.

[0063] The second method is semantic similarity, which calculates the semantic similarity between the failure description, repair suggestions and conditional expression text based on vector cosine similarity. After encoding the text content of the failure mode unit into a semantic vector through an embedding model, the cosine similarity between the current query vector and the historical vector is calculated as the semantic similarity score. It is suitable for generalization scenarios with rich natural language descriptions and different parameter expressions. It can capture the commonalities of failure modes at the semantic level and make up for the lack of generalization ability of pure structured matching.

[0064] The third type is hybrid similarity, which combines the accuracy of structured similarity matching with the generalization of semantic similarity matching. This is the default calculation mode for pre-detection retrieval, and the calculation formula is as follows: Score_mix=0.6×Struct_Sim+0.4×Sem_Sim, Here, Score_mix is ​​the comprehensive similarity score, and Sem_Sim is the semantic similarity score. The weight allocation of 0.6 and 0.4 reflects a retrieval strategy that prioritizes structured exact matching and supplements it with semantic similarity matching. Based on this, the self-confidence and time-related decay factor of the failure mode unit are further introduced to calculate the final similarity score Score_final. This gives higher reference weights to failure modes with higher confidence and more recent generation times. The calculation formula is as follows: Score_final=Score_mix×confidence×exp(-λ×days), In the formula, confidence is the confidence score of the corresponding failure mode unit, ranging from 0 to 1, obtained by iterative updates of historical matching success rates and feedback results; days is the number of days since the failure mode was generated; and λ is the time decay coefficient, with a value of 0.01 / day. This decay coefficient is determined based on the engineering mapping of the empirical half-life. Substituting it into the exponential decay model, the theoretical half-life of the failure memory effectiveness is approximately 69.3 days, which is compatible with the quarterly change rhythm of enterprise-level system toolchains. This allows for the retention of long-term stable system defect experience while gradually forgetting outdated records caused by temporary environmental drift, achieving a dynamic balance in memory effectiveness.

[0065] The failure memory storage subsystem is equipped with a complete memory maintenance mechanism to ensure the quality and timeliness of the memory bank. The confidence level is dynamically updated as follows: when a successful match prevents a failure, the confidence level is increased by 0.05; if a similar execution failure still occurs after pre-checking, the confidence level is decreased by 0.1; failure mode units with a confidence level < 0.3 are placed in a cleanup queue. The intelligent deduplication and merging rule is triggered when the structural similarity of two failure mode units is > 0.85, updating the match count, taking the union of the fusion condition expression, and retaining higher confidence levels to reduce duplicate memory usage. The periodic cleanup rule is to periodically clean up failed units with a confidence level < 0.3, a retention period > 90 days, and zero match counts, optimizing storage resource usage and retrieval efficiency.

[0066] After completing the similarity retrieval, the units are sorted in descending order of the final similarity score. The top K failure mode units are taken as the candidate set, with K set to 5 by default. Based on this, the scores of the three dimensions of historical matching degree, condition triggering degree and environmental risk degree are calculated respectively.

[0067] The historical matching score weight mentioned above is 0.4, used to quantify the overall similarity between the current tool call and all historical failure mode units. The calculation process consists of three steps. The first step is to retrieve Top-K candidates. Using the current tool call context as the query condition, the mixed similarity retrieval interface is called to obtain the candidate set, with each candidate accompanied by a final mixed similarity score. The second step is ranking-weighted aggregation. To prioritize matching more similar historical failure modes, ranking weights are introduced. The weight of the j-th ranked candidate is 1 / (j+1), that is, the weight of the first ranked candidate is 1 / 2, the weight of the second ranked candidate is 1 / 3, and so on. The ranking-weighted average of the similarity scores of the candidate set is used to obtain the raw historical matching score Raw_HS. The calculation formula is as follows: , Where, sim j For the final mixed similarity score of the j-th candidate, rank_weight jThis refers to the weighting coefficients for the corresponding rankings. The third step is confidence correction, which adjusts the original values ​​based on the average confidence of the candidate set. The final historical matching score (HS) is calculated using the following formula: HS=Raw_HS×min(1.0,conf_avg+0.1), Here, conf_avg represents the average confidence level of all failure mode units in the candidate set. This correction mechanism ensures that the higher the average confidence level of the candidates, the closer the historical matching degree is to the upper limit of the original value and does not exceed 1.0; when the average confidence level is <0.3, the historical matching degree will be significantly suppressed to avoid low-quality failure modes dominating the risk score and improve the reliability of the evaluation results.

[0068] The aforementioned condition triggering degree weight is 0.4, used to evaluate the degree to which the current combination of call parameters satisfies historical failure conditions. During calculation, the failure mode unit with the highest similarity from the candidate set is selected. First, the composite condition expression containing AND, OR, and NOT logic within the failure mode unit is expanded into disjunctive normal form, decomposed into a set of multiple mutually exclusive conjunctive clauses. Each conjunctive clause consists of several atomic conditions connected by AND logic, corresponding to a set of conditions that can independently trigger failure. Decomposing composite conditions into a disjunctive normal form structure allows complex multi-condition logic to be broken down into independently computable condition groups, clearly corresponding to different failure triggering paths, providing a structured foundation for subsequent precise matching group by group.

[0069] When calculating the satisfaction of a single conjunction clause, all atomic conditions within the clause are first traversed, and the actual values ​​of the corresponding fields are extracted from the current context. If a corresponding field is missing, the satisfaction of the atomic condition is directly returned as 0. Subsequently, differentiated matching is performed based on the operator type of the atomic condition, outputting the satisfaction of the atomic condition in the range of 0 to 1, where 1 represents complete satisfaction of the constraint and 0 represents complete non-satisfaction of the constraint. The system adopts a categorical exact matching algorithm, performing differentiated judgment logic based on the type of operator, comprehensively covering various failure condition judgment scenarios. Specifically: The numerical comparison class includes four operators: gt, gte, lt, and lte. It outputs the judgment result by comparing the current actual value with the threshold. The gt and gte operators are suitable for judgment scenarios such as timeout threshold and data volume threshold, while the lt and lte operators are suitable for judgment scenarios such as available memory and remaining timeout time. The exact matching class includes two operators: eq and ne. The eq operator performs a case-sensitive exact comparison of strings and a floating-point precision comparison of numerical values. It is suitable for judgment scenarios with specific error codes and fixed parameter values. The ne operator performs a reverse judgment. If the actual value is not equal to the threshold, it is judged as a complete match. It is suitable for judgment scenarios that exclude specific states. The collection and string processing class includes two operators: contain and matches. The contain operator determines whether the threshold substring exists in the actual value. If it exists, it is considered to be fully satisfied. It is suitable for error message keyword and stack feature recognition scenarios. The matches operator performs pattern matching through the regular expression engine. If the actual value matches the regular expression rules, it is considered to be fully satisfied. It is suitable for format validation scenarios. The existence check class includes two operators: exist and empty. The exist operator checks if the corresponding field is not empty and actually exists. If it does, it is considered to be completely satisfied. It is suitable for scenarios where required parameters are missing. The empty operator checks if the actual value is None, an empty string, an empty list, or an empty dictionary. If it does, it is considered to be completely satisfied. It is suitable for scenarios where empty result sets are detected.

[0070] The aforementioned precise classification logic can adopt appropriate matching rules for failure conditions of different attributes. Compared with single semantic matching, it has higher judgment accuracy and can accurately restore the constraint logic of different types of failure conditions.

[0071] To avoid misjudgments caused by score jumps at threshold boundaries, the system also supports enabling a fuzzy matching mode. For numerical comparison operators, a sigmoid-type smoothing function is introduced to replace hard threshold judgment. Taking the gt operator as an example, the formula for calculating the matching function is: , Where k is the steepness coefficient, with a value of 5.0, v is the actual value of the current field, and threshold is the threshold of the atomic condition. The smoothing function allows for a continuous transition in the matching degree near the threshold, eliminating score fluctuations caused by abrupt changes and avoiding frequent shifts in intervention strategies due to sudden changes in risk level at the critical value. For the eq operator in exact string matching, the normalized edit distance is used to calculate the partial matching score in fuzzy mode: , In this function, `edit_distance(v, threshold)` represents the edit distance between the current actual string `v` and the threshold string `threshold`, `len(v)` is the length of the current actual string, `len(threshold)` is the length of the threshold string, and `max(*)` takes the larger of the two. A match is considered valid when this value is greater than 0.8. The fuzzy mode is disabled by default but can be flexibly enabled through system configuration to adapt to dynamic operating environments with large parameter fluctuations.

[0072] After matching all atomic conditions within a single conjunctive clause, the overall satisfaction score of the clause is obtained by a weighted average of the satisfaction scores of the atomic conditions. The atomic condition weights are assigned by the large language model during the expression extraction stage, with a default weight of 1. This aggregation method naturally adapts to the bottleneck effect of AND logic; the failure of a single key condition will significantly lower the overall clause score, accurately reflecting the actual pattern of failure triggered by multiple conditions. Finally, the maximum score of all conjunctive clauses is taken as the condition trigger score, corresponding to the OR logic of the condition expression; that is, if any combination pattern is matched, the condition is satisfied. If the condition expression of the failure pattern unit is empty, the condition trigger score is directly defined as 0. This aggregation method strictly corresponds to the logical semantics of the condition expression, ensuring that the scoring result is consistent with the actual logic of failure triggering, improving the accuracy and interpretability of the condition trigger score calculation. Taking a database query timeout scenario as an example, if the historical condition is (timeout_ms lte30000 AND table_rows gt 10000000) OR (connection_pool_usage gt 80), and the current actual value is {timeout_ms: 25000, table_rows: 12000000, connection_pool_usage: 65}, then the first set of conditions is fully satisfied and scores 1.0, while the second set is not satisfied and scores 0. The final condition trigger degree takes the maximum value of 1.0, which can accurately reflect the risk status of the current condition hitting the failure mode.

[0073] The aforementioned environmental risk weight is 0.2, used to quantify the severity of the current system environment deviating from the historical failure state. The assessment is based on three core indicators: system load, network latency, and dependent service health. All three indicators have clear definitions and data sources: the system load factor L is the larger of CPU utilization or system average load, normalized to the 0-1 range, and the data comes from system operation indicator collection; the network latency factor D is the median of the most recent three probes of the round-trip latency of the target dependent service request, in milliseconds, and the data comes from active probing or API call tracking; the dependent service health H has values ​​of 1.0 (normal), 0.5 (degraded), and 0.0 (unavailable), and the data comes from the service registry or circuit breaker status data. This multi-dimensional indicator collection covers three core environmental factors: computing resources, network links, and service availability, comprehensively depicting the operating environment state of the tool call and providing a reliable data foundation for environmental risk assessment.

[0074] The risk contribution of each indicator is calculated using a piecewise linear function, with an output range of [0,1]. The system load risk_L takes the system load factor L as input, and the piecewise calculation rule is as follows: , This means there is no risk when the load is below 50%, the risk increases linearly with the load between 50% and 80%, and the highest risk level is reached when the load exceeds 80%, which closely reflects the actual impact of system load on the success rate of tool calls. The piecewise linear calculation design ensures that there is no additional risk weight in low-load scenarios, while smoothly increasing the warning level during load increases and promptly triggering the highest level of risk protection during high loads, which conforms to the actual operating rules of the production environment.

[0075] Network latency risk (risk_D) is calibrated based on historical baselines, using the P50 and P99 quantiles of latency for the dependent service over the past 7 days. p50 D p99 As a baseline, the network latency factor is D, and the segmented calculation rule is as follows: , Calibration based on the service's own latency baseline avoids the compatibility issues of fixed thresholds across different services. Using the service's own historical latency quantile as the judgment benchmark, rather than a uniform fixed threshold, can adapt to the normal latency differences of different interfaces and services, avoiding misjudgments of services with inherently high latency, and significantly improving the scenario adaptability of network latency risk assessment.

[0076] The formula for calculating the health risk (risk_H) of dependent services is: risk_H = 1.0 - H Where H represents the health of the dependent service, with a maximum health value of 1.0 indicating a risk of 0, a degraded state of 0.5 indicating a risk of 0.5, and an unavailable state of 0.0 indicating a risk of 1.0. This directly maps the risk level corresponding to the service's availability state. This direct mapping calculation method can quickly respond to service status changes such as circuit breaking and degradation, ensuring zero-latency judgment of service availability risks and timely interception of calls to unavailable services.

[0077] After the three indicators are calculated, the final Environmental Risk Level (ERS) is obtained through adaptive weight aggregation. The calculation formula is as follows: ERS=α×risk_L+β×risk_D+γ×risk_H, Wherein, α is the weight coefficient of the system load risk item, with a value of 0.3; β is the weight coefficient of the network latency risk item, with a value of 0.3; and γ is the weight coefficient of the service health risk item, with a value of 0.4. The health risk item has the highest weight, reflecting the priority of service availability as a hard constraint, and satisfies α + β + γ = 1.0. The system supports an adaptive weight mode, which can read the environmental sensitivity configuration from the metadata according to the tool type and automatically adjust the weight allocation: computationally intensive tools such as code executors and data processing tools focus on the impact of system load, and correspondingly increase the value of α; network I / O intensive tools such as API calls and database queries focus on the impact of network and service availability, and correspondingly increase the values ​​of β and γ; core transaction tools such as payment interfaces further increase the weight of γ to prioritize the availability of dependent services. Differentiated configuration makes the environmental risk assessment more in line with the operating characteristics of different tools.

[0078] Finally, the scores from the three dimensions are weighted and summed to obtain the comprehensive risk score, Risk_Score, calculated as follows: Risk_Score=0.4×HS+0.4×CTS+0.2×ERS, The default weights are 0.4, 0.4, and 0.2. The system supports adjusting the weight ratios through configuration to adapt to different risk preferences in different scenarios. For example, in security-sensitive scenarios, the weight of environmental risk can be appropriately increased. Since the values ​​of HS, CTS, and ERS are all in the range of [0,1], the value range of the comprehensive risk score, Risk_Score, is also uniformly [0,1]. The three-dimensional weighted comprehensive scoring system takes into account historical matching similarity, condition triggering degree, and operating environment risk. It can comprehensively quantify the risk level of tool calls from three levels: historical experience, current parameters, and real-time environment, resulting in more comprehensive and interpretable scoring results.

[0079] The system is equipped with a data calibration and closed-loop feedback mechanism. The risk score and actual execution result of each pre-inspection are recorded in the prediction log of the failure memory storage subsystem. The system calculates the calibration curve of the score and the actual result offline every day. If the system deviation exceeds the predetermined threshold (e.g., Brier Score > 0.15), the system will automatically trigger the fine-tuning and optimization of the weight vector to keep the risk score in a calibrated state and avoid the distortion of the score due to long-term environmental evolution, thus forming a continuous iterative closed loop for risk assessment.

[0080] The aforementioned pre-inspection mechanism realizes a paradigm shift from post-event error correction to pre-event prevention. It covers all scenarios, including task planning, pre-execution interception, and runtime environment mutations, through a three-level progressive triggering system. Combined with a hybrid similarity retrieval that integrates structured and semantic data, and a quantitative scoring system that weights historical matching degree, conditional triggering degree, and environmental risk degree, it ensures the accuracy and generalization of risk assessment while providing performance optimization and transaction breakpoint protection mechanisms. This balances the control effect, execution efficiency, and data consistency in the production environment, and can reduce the probability of tool call failure from the source.

[0081] For step 4, the corresponding intervention strategy is determined based on the comprehensive risk score, and the intervention strategy is executed on the target tool. The intervention strategy determined based on the comprehensive risk score specifically includes: when the comprehensive risk score is higher than the first preset threshold, the execution is blocked, the execution of the target tool is blocked, a blocking prediction report is generated, and the Agent is triggered to execute the replanning process; when the comprehensive risk score is higher than the second preset threshold but not higher than the first preset threshold, the tool switching strategy is determined, the target tool is switched to a similar alternative tool, parameter mapping is performed, and execution continues; when the comprehensive risk score is higher than the third preset threshold but not higher than the second preset threshold, the prompt injection strategy is determined, risk prompt information is injected into the Agent's current execution context; when the comprehensive risk score is not higher than the third preset threshold, the no-intervention strategy is determined, and the target tool is allowed to execute normally. Switching the target tool to a similar alternative tool involves: calculating the initial functional similarity between tools based on the metadata of the registered tools, and constructing a tool similarity graph; querying alternative tools with similar functions to the target tool through the tool similarity graph, converting the calling parameters of the target tool into a parameter format recognizable by the alternative tool, and then performing the switch; and dynamically updating the weights of the edges in the tool similarity graph based on the actual execution results of the tool switch.

[0082] Specifically, the system sets three preset thresholds based on the range of the comprehensive risk score, corresponding to four risk levels and tiered intervention strategies. As an example, the third preset threshold is 0.5, the second preset threshold is 0.65, and the first preset threshold is 0.75. Specifically, the thresholds can be flexibly configured according to the risk preferences of the scenario. The tiered classification mechanism can match different levels of risk scenarios, avoiding failure while preventing excessive intervention that could affect execution efficiency.

[0083] When the comprehensive risk score is in the range of 0.0 to 0.5 and is judged to be of low risk level, there is no intervention strategy. The target tool is allowed to be scheduled and executed normally. Only the pre-inspection access log is recorded for subsequent score calibration analysis. The execution process and context state are not changed. This avoids unnecessary pre-inspection overhead, ensures the execution efficiency of routine tasks, and retains all data to support the iterative optimization of the subsequent scoring model.

[0084] When the overall risk score is between 0.5 and 0.65, classifying it as a medium-risk level, a corresponding policy is injected. This policy is suitable for medium-to-high-risk scenarios. Instead of blocking the execution process, the intervention router injects risk warning information into the Agent context, using natural language to inform the Agent of past failures caused by similar conditions and suggested preventative measures, such as increasing timeouts, adding verification steps, or adjusting parameter ranges. The advantage of this policy is that it does not interrupt the task and maintains the Agent's execution autonomy, while transforming historical failure experiences into proactive warnings, reducing the probability of failure with minimal process overhead. It is suitable for scenarios where failure modes are uncertain and task timeliness requirements are high.

[0085] When the overall risk score is in the range of 0.65 to 0.75 and is judged as a high-risk level, the corresponding tool switching strategy is applicable to medium-to-high risk scenarios where there are alternative solutions. When the current tool calls a high-risk tool but there are similar alternative tools in the system, the router intervention suggests or forces a switch to the alternative tool. This replaces the high-risk execution path without interrupting the overall task flow, ensuring the continuity of the task.

[0086] The core of the aforementioned tool switching relies on a tool similarity graph, which is a directed graph describing the functional substitution relationship between tools. Nodes represent available tools in the system, and directed edges indicate that the corresponding tool can be replaced by another tool. The edge weight ranges from [0,1], representing the expected success rate of the substitution path. The graph structure can clearly quantify the substitution relationship between tools, providing support for quickly finding the optimal alternative tool.

[0087] The construction of the graph integrates two stages: static initialization and dynamic evolution. Specifically: The first phase is static initialization, which involves pre-calculating semantic similarity based on tool metadata. At startup, the system scans the metadata of all registered tools, including tool name, function description, input / output schema, and operational semantic tags, calculating the functional similarity between tools as a candidate set for initial substitution relationships. The specific calculation method is as follows: The tool's functional description text is encoded into vectors using an embedding model, and the cosine similarity between each pair is calculated to obtain the semantic similarity sim_embedding; the tool's input and output schemas are parsed, and the consistency score of parameter type signatures is calculated to obtain the schema similarity sim_schema; the initial functional similarity is generated by combining the two. sim_init=0.5×sim_embedding+0.5×sim_schema, When the initial functional similarity sim_init > 0.7, the system establishes a bidirectional candidate edge between the two tools, with the initial edge weight set to sim_init. This static initialization method enables the construction of basic substitution relationships during system startup, providing a reliable benchmark for subsequent runtime iterations and avoiding the problem of having no alternatives available during the cold start phase.

[0088] The second stage is dynamic evolution, based on runtime execution data-driven edge weight updates. After the initial candidate edges undergo actual switching attempts, the edge weights are dynamically adjusted according to the switching results. The system maintains a statistical triplet for each pair of tool switching, namely, attempt_count, success_count, and last_attempt_time. The edge weight update formula is w. {ij} for: , Among them, the confidence factor is: confidence_factor=1-exp(-attempt_count / 10), When the number of attempts is small (attempt_count < 5), the edge weights shrink back to the initial similarity sim_init to avoid overfitting from small sample statistics. When the number of attempts is sufficient (attempt_count ≥ 10), the edge weights approximate the actual historical success rate, truly reflecting the actual effect of the alternative path. The runtime dynamic update mechanism allows the accuracy of the graph to continuously improve with use, becoming more and more in line with the actual running state and adapting to the dynamic changes in the toolchain.

[0089] The third aspect is incremental maintenance of the graph. When a new tool is registered in the system or an old tool is taken offline, the graph is updated incrementally. The new tool calculates the initial functional similarity with all existing tools and establishes candidate edges. The outgoing and incoming edges of offline tools are marked as unavailable (the weights are reset to 0, but historical statistics are retained for quick re-entry after the tool is restored). Incremental maintenance eliminates the need to rebuild the entire graph when a tool changes, significantly improving update efficiency. At the same time, retaining historical data avoids the cold start problem after a tool is relaunched.

[0090] When a router switches from the original tool to the target tool, the parameters invoked by the original tool need to be converted into a parameter format recognizable by the target tool. This invention designs a three-layer parameter mapping architecture, covering different parameter difference scenarios layer by layer: The first layer is precise field mapping. For parameters with different field names but the same semantics, the system maintains a global field thesaurus. When switching, the system searches for the synonyms of each field in the target tool schema in the dictionary and automatically completes the field name mapping. It can adapt fields with the same semantics but different names at zero cost and complete the basic parameter conversion without additional configuration. The second layer is unit and format conversion. For parameters with the same data type but different units or formats, the system automatically performs numerical conversion and format conversion based on the unit annotations or format constraints declared in the target tool's schema. It automatically handles differences in units and formats, avoids errors in manual conversion, and improves the accuracy of parameter conversion. The third layer is the structural reconstruction mapping. For scenarios where parameter structures differ and the system cannot automatically infer the conversion logic, it queries the predefined parameter conversion template in the tool's registry. This template is manually provided by the tool developer upon deployment, ensuring conversion efficiency for high-frequency scenarios. If no predefined template exists, the original parameters and the schemas of both tools are injected into the large language model. The model generates candidate conversion scripts, which are executed after syntax validation. The generated mapping rules are cached, eliminating the need for repeated model calls upon a match. This covers conversion scenarios with complex structures and reduces the performance overhead of subsequent calls through the caching mechanism. After each parameter mapping conversion, the system records whether the converted parameters are successfully received by the target tool. Accumulated statistics form a mapping confidence score. When the mapping confidence score is below 0.5, the tool's priority in the switching strategy is automatically downgraded by the system. By automatically filtering low-quality mapping paths, the overall success rate of tool switching is continuously improved.

[0091] The dynamic update of edge weights forms a complete closed loop. This update depends not only on the success or failure of the switch itself but also on three types of feedback signals. This multi-dimensional feedback allows for a more comprehensive evaluation of edge weights, avoiding the bias of a single indicator. Specifically: the first type of feedback signal is the direct feedback of the switch result. After each switch attempt, the statistical triplet is updated based on the execution result. Success increments `success_count` by 1, while failure increments `attempt_count` by 1 (only `attempt_count` increases), and `w` is recalculated. {ij} The first type of feedback signal directly reflects the actual effect of the alternative path; the second type of feedback signal is the failure mode unit confidence linkage. If the alternative tool fails and generates a new failure mode unit, and this failure mode records the failure mode on the alternative tool, then the system associates the failure mode with the tool pair. When querying the switching path again in the future, it will be used as a negative signal to reduce the confidence level. {ij} The effective value, with a multiplier factor of 0.9, i.e., w_effective=w×0.9, incorporates the failure risk of the tool itself into the evaluation of alternative paths, avoiding the neglect of known defects in the alternative tool itself; the third type of feedback signal is time decay, consistent with the time decay mechanism in the failure memory storage subsystem, and the edge weights also introduce time decay, with a half-life of 90 days, so that long-unverified alternative relationships gradually return to the initial value, avoiding outdated high success rates dominating decision-making, and adapting to changes in the effectiveness of alternative relationships caused by tool version iterations and interface changes.

[0092] When the comprehensive risk score is higher than 0.75 and is judged to be of extremely high risk level, the corresponding blocking execution strategy is applied. This strategy is applicable to extremely high risk scenarios. The intervention router directly blocks the execution of the current tool call step or the entire plan, returns a blocking signal and failure prediction report to the Agent planning module, and triggers a replanning process by the planning module to prevent the execution of high-risk operations from the source and avoid irreversible losses.

[0093] The blocking report employs a dual-track format, combining machine-readable structured data with human-readable natural language summaries. This format simultaneously meets the automated decision-making needs of the planning module and the interpretability requirements of operations and maintenance personnel, balancing machine processing efficiency with the readability of manual investigation. The report consists of six core data domains: The first is the blocking metadata field, which includes the report's unique identifier, timestamp, index position of the blocking step, and tool name. This allows the planning module to pinpoint the precise execution point where the blocking occurred and associate it with the checkpoint record in the status table of the failure memory storage subsystem, enabling precise location of the blocking position and status tracing. The second is the risk scoring domain, which outputs a comprehensive risk score, a risk level label (extremely high risk), and detailed scores in three dimensions: historical matching degree, condition triggering degree, and environmental risk degree. This allows the planning module to determine the severity of the blockade and the main sources of risk during replanning, and assists in targeted adjustments during replanning. The third part is the matching of historical failure patterns. A dual-track system is used to list the Top-K historical failure pattern records that are most similar to the current blocking step. Each record contains both a machine-readable identifier and a natural language summary. The machine-readable identifier is a unique identifier for each matched failure pattern, which is used by the caching layer of the planning module and the source tracing module for subsequent confidence updates and deduplication and merging judgments. The identifier can also be used to query the complete metadata of the failure pattern. The natural language summary merges the structured conditional expressions, error classifications and repair suggestions into a concise natural language description, which is directly injected into the context by the large language model inference component in the Agent planning module. This allows the Agent to understand the reasons for failure and make semantic adjustments during replanning, rather than just mechanically replacing parameters. The dual-track design supports both automated and rapid processing and deep semantic optimization. The fourth is the root cause analysis domain, which includes four levels of error classification and root cause hypothesis text. It explains the root cause of failure in a structured form, so that the planning module can identify the essence of the problem during replanning rather than just staying at the symptom level, and avoid similar failures from the root cause. The fifth is the alternative solution domain, which provides 1 to 3 executable replanning suggestions in the form of a structured list. Each suggestion is clearly labeled with its type, specific operation description and estimated success rate, so that the planning module can directly adopt and execute it without having to call the large language model again for open generation, which greatly improves the response efficiency of replanning. The sixth is the execution constraint domain, which marks whether the blocking step involves irreversible operations. This allows the planning module to perform a safety check before executing automatic retries. If the flag is true, all automatic retry strategies are skipped, and the process directly enters the manual intervention process. This mechanism ensures the safety of high-risk operations and avoids irreversible losses caused by automatic retries.

[0094] In a dual-track collaborative workflow, when a blocking report reaches the planning module, the replanning processor first parses the machine-readable failure mode identifier and alternative structure, attempting to execute either a first-level parameter correction or a second-level tool switch, without requiring the involvement of the large language model to ensure response speed. If the first two levels of automated strategies fail to resolve the issue, natural language summarization and root cause analysis are injected into the context of the large language model, triggering a model-driven third-level task degradation decision. This approach maintains automation efficiency while preserving the flexibility of semantic understanding for complex scenarios, achieving a balance between efficiency and effectiveness. In other words, after receiving a blocking report, the Agent planning module executes a three-level progressive replanning decision logic, attempting solutions sequentially according to priority, escalating from low-cost to high-cost, prioritizing the fastest method to resolve the problem, and balancing replanning efficiency and problem-solving rate. Specifically: The first level is parameter correction retry. The trigger condition is that the alternative solution field of the blocking report contains a parameter correction type suggestion, and the current step does not involve irreversible operations. The execution logic is that the planning module directly adopts the suggested parameters, replaces the high-risk parameters in the original call with the suggested values, keeps the tool unchanged, does not need to re-execute the top-level planning, and directly enters the step-level pre-check with the corrected parameters. If it passes, it will be executed. If the risk score drops below 0.5 after correction, it will be executed. Otherwise, it will continue to try the second level. The parameter correction method has the least modification and the least time consumption, which can quickly solve parameter-related risk problems.

[0095] The second level is tool switching retry. The trigger condition is that the alternative solution field of the blocking report contains a tool switching type suggestion, and there is an available alternative tool in the tool similarity graph. The execution logic is that the planning module queries the tool similarity graph, tries alternative tools in descending order of estimated success rate, automatically performs parameter mapping conversion, and replaces the tool implementation while keeping the business semantics unchanged. If the alternative tool passes the pre-check, it is executed; otherwise, the third level is tried to bypass the defects of the tool itself by changing the execution path.

[0096] The third level involves task degradation or step rollback, triggered by failures in both of the previous levels, marking the blocked step as irreversible, or a comprehensive risk score higher than 0.95. The execution logic involves the planning module abandoning the tool call, marking the step as permanently blocked, and propagating the failure to the upper-level task coordinator. If the step is an optional enhancement step, it is skipped, and subsequent plans are continued to ensure the main process progresses as much as possible. If it is a critical step in the main process, the entire plan is suspended, a failure prediction report is returned to the user or operations console, and recovery is achieved through a breakpoint resume mechanism after manual adjudication or changes in external conditions, ensuring the rigor of decision-making in critical scenarios. The replanning execution process is attempted serially by the built-in replanning processor in the order of level one to level two to level three. After a previous level's strategy is successfully executed, the replanning process immediately exits without proceeding to subsequent levels. If the pre-check fails after the current level's execution, it automatically degrades to the next level. Each level's attempt is recorded in the execution log for feedback on the intervention effect of subsequent failure modes.

[0097] To clearly define system boundaries and interaction protocols, this invention defines a standard interface specification for blocking signals, which can be seamlessly integrated with mainstream agent frameworks. The interface interaction employs a three-phase handshake mechanism of interruption, response, and submission. Clear interface boundaries allow this system to be plugged into different agent architectures, providing excellent engineering compatibility. Specifically: The first stage involves throwing an interrupt signal. When the intervention router detects an extremely high risk, it does not directly modify the internal state of the Agent planning module. Instead, it throws a standardized pre-detection interruption anomaly signal. The signal carrier contains a complete blocking report. This non-intrusive design avoids disrupting the original planning logic and reduces integration and modification costs.

[0098] The second phase is the takeover interface of the planning module. The Agent planning module needs to implement the predefined takeover interface, which includes two core methods: one is the blocking signal reception method, which is automatically called when the signal arrives. The input parameter is the blocking report and the output parameter is the revised execution plan; the other is the blocking status query method, which queries whether a certain step is in a blocking suspended state. This is used for status synchronization when dynamic pre-detection is triggered. The standardized interface definition reduces the integration cost.

[0099] The third stage involves revised plan submission and secondary pre-check. After the planning module completes the replanning decision, it submits the revised steps or the entire plan to the dedicated replanning entry point of the pre-check engine. This entry point performs a rapid secondary pre-check, shortening the timeout threshold. It only performs step-level pre-checks, skipping the full retrieval of plan-level pre-checks, thus improving the verification efficiency after replanning. If the secondary pre-check result is passed (i.e., the risk score is below 0.5), execution is allowed. If it still fails, the blocking process is restarted. If the blocking occurs three times consecutively, it forces entry into the third-level manual intervention state to prevent infinite retries and ensure system stability. The fourth stage involves state persistence and breakpoint association. The plan snapshot at the time of the blockage is automatically written to the status table of the failure memory storage subsystem and associated with the unique identifier of the report. When manual intervention or environmental recovery occurs, the system can accurately restore to the blockage point through this identifier, avoiding re-execution and reducing the time cost of anomaly recovery.

[0100] After each intervention, the system records the execution effect and feeds it back to the failure memory storage subsystem. The core of this process is the failure attribution arbitration mechanism. When the intervention still fails, the system must determine whether the failure is due to inaccurate prediction conditions of the failure mode or because the agent did not follow the intervention recommendations. The two attributions correspond to completely different feedback actions. Accurate attribution avoids incorrect confidence updates, ensures the quality of the memory bank, and forms a reliable continuous iteration closed loop.

[0101] The aforementioned tiered intervention mechanism achieves precise handling at different risk levels through a gradient risk management strategy. It ranges from low-cost, no-intervention to strong protection by blocking execution, matching the risk level step by step. This not only blocks execution and avoids irreversible losses under extremely high risks, but also reduces the probability of failure through lightweight methods such as prompt injection and tool switching, thus balancing the security and continuity of task execution. The accompanying dynamically iterative tool similarity graph, three-level progressive replanning, and standardized interface mechanism ensure the effectiveness of risk management while possessing good engineering feasibility and framework compatibility, effectively improving the overall fault tolerance and execution success rate of the tool call chain.

[0102] For step 5, based on the feedback information generated after the execution of the target tool following the intervention, the confidence level and match count of the corresponding failure mode unit in the failure memory storage subsystem are updated, including: when the feedback information generated after the execution of the intervention strategy indicates successful execution and the intervention strategy is adopted, the confidence level of the corresponding failure mode unit is positively adjusted and its match count is increased; when the intervention strategy is blocked and the Agent ultimately executes successfully according to the replanning process triggered after the blocking, the match count of the corresponding failure mode unit is increased; when the feedback information generated after the execution of the intervention strategy indicates execution failure and the intervention strategy is executed, failure attribution arbitration is triggered, and the responsibility attribution category is determined based on three dimensions: the Agent's compliance with the intervention strategy, the condition coverage of the failure context of the failure mode unit, and the degree of environmental anomaly.

[0103] Based on the above scheme, differentiated feedback is performed according to the responsibility attribution category. Specifically: if it belongs to Agent non-compliance, a new failure mode unit with associated non-compliance label is generated; if it belongs to insufficient condition coverage, the original unit is retained and a new unit is generated to record the current failure condition; if it belongs to accurate prediction but ineffective strategy, the confidence level is reduced; if it belongs to unexpected environmental anomaly, the condition expression of the original unit is expanded.

[0104] This feedback mechanism is the core iterative link in the entire failure learning loop. It updates the failure memory storage subsystem in reverse with the results of each intervention, thereby achieving continuous self-optimization of failure modes and intervention strategies. Its core innovation lies in the introduction of a failure attribution arbitration mechanism, which avoids the problem of updating confidence levels in a one-size-fits-all manner when failure occurs after intervention. It can accurately distinguish the responsibility for failure, match differentiated feedback actions, and ensure the accuracy of memory bank iteration.

[0105] The basic feedback logic of the above scheme is divided into three categories of actions based on the intervention results. The first category is successful prevention of failure after intervention. When the intervention strategy is implemented, and the Agent adopts the suggestion and actually executes it successfully without failure, the confidence level of the corresponding failure mode unit is positively adjusted by +0.05, and the match count is incremented by 1, positively reinforcing the accurately predicted failure mode. The second category is successful replanning after blocking. When the blocking report is returned, and the Agent ultimately executes successfully after replanning, the match count of the corresponding failure mode unit is incremented by 1, while the confidence level remains unchanged, confirming the predictive validity of the failure mode and acknowledging the effectiveness of the replanning. The third category is still failure after intervention. When the system takes prompting or switching intervention measures, but the actual execution still fails, the confidence level is not directly updated. Instead, the attribution arbitration process is initiated, and different operations are performed based on the attribution results to avoid incorrectly penalizing effective failure modes.

[0106] The failure attribution arbitrator is a key middleware connecting the intervention router and the failure memory storage subsystem. It is responsible for determining the fundamental responsibility for failure when it occurs after intervention. The arbitrator adopts a three-factor attribution model, which judges from three dimensions: agent compliance, condition coverage, and environmental anomaly, and then combines them to obtain the final attribution result.

[0107] The first dimension mentioned above is the agent's compliance with the intervention strategy. The data comes from the actual parameter values ​​of the agent recorded in the execution log and the suggested values ​​in the intervention suggestions. The judgment logic is to compare the consistency between the actual execution parameters and the suggested parameters. If the relative deviation of numerical parameters is >20%, or if key suggested fields are not adopted, such as not increasing the timeout time as suggested, then it is judged that the agent has not complied.

[0108] The second dimension mentioned above is the condition coverage of the failure mode unit. It compares the context parameters at the time of the current actual failure with the condition expressions recorded in the historical failure mode, and calculates the degree to which the actual failure parameters meet the conditions. If the condition triggering degree calculated based on the actual failure parameters is >0.8, it means that the failure does fall within the predicted risk range, and it is judged as accurate prediction but not effectively avoided; if the actual condition triggering degree is <0.5, it means that the failure deviates from the predicted condition range, and it is judged as insufficient condition coverage.

[0109] The third dimension mentioned above is the environmental anomaly. The data comes from environmental indicators such as system load, network latency, and health of dependent services at the time of failure. If the environmental risk level is ≥0.7 and the environmental condition is not recorded in the original failure mode, it is judged as an unexpected new environmental anomaly.

[0110] Based on the judgment results across three dimensions, the system obtains the final attribution conclusion and corresponding execution action through an attribution decision matrix combination. When it is determined that the Agent has not followed the intervention recommendations, regardless of the coverage and environmental anomaly results, it is attributed to the Agent's failure to follow the intervention recommendations. In this case, the original failure mode unit is not penalized to avoid the failure caused by the Agent's failure to adopt the recommendations weakening the effective memory. At the same time, a new failure mode unit with a non-compliance label is generated to record this type of failure mode, making it a stronger early warning signal in subsequent pre-detection and automatically increasing the corresponding risk level. When the Agent has followed the recommendations, the condition coverage is ≥0.8 and the environmental anomaly is <0.5, it is attributed to accurate prediction but ineffective strategy. In this case, the confidence level of the original failure mode unit is reduced by 0.1, and a corresponding sub-failure mode is generated to record the scenario where the strategy is ineffective, decoupling the evaluation of the two dimensions of condition prediction and strategy effectiveness. When the agent has followed the recommendations, the condition coverage is <0.5, and the environment anomaly score is <0.5, the failure is attributed to insufficient condition coverage. In this case, the original failure mode unit remains unchanged, while a new failure mode unit is generated, adding the current failure parameter conditions as new condition modes to the library to supplement the coverage of failure modes. When the agent has followed the recommendations and the environment anomaly score is ≥0.7, the failure is attributed to unexpected environmental anomalies. In this case, the confidence level of the original failure mode unit remains unchanged, while a new failure mode unit is generated, adding the current environmental indicators as new preconditions to the condition expression of the original failure mode to expand the applicable scenarios of the existing failure modes, rather than creating a new independent entry.

[0111] When the three-factor determination results conflict and it is difficult to distinguish the primary cause, the attribution arbitrator automatically triggers the large language model-assisted adjudication mode. The system organizes the complete execution context, including intervention reports, agent decision logs, actual failure stack traces, and environmental time-series data, into structured text, calls the large language model for attribution reasoning, and requires the output of the primary attribution category, confidence score, and a summary of attribution evidence within a preset word limit. The model output, after format validation, serves as the final attribution result. Simultaneously, this attribution case is cached for rapid matching in subsequent similar scenarios, gradually reducing reliance on model calls and balancing the accuracy of determinations in complex scenarios with the execution efficiency in routine scenarios.

[0112] Through the aforementioned arbitration mechanism, the system forms a complete closed loop of failure attribution, differentiated feedback, and precise evolution of failure modes, achieving a three-tiered self-evolution effect: First, the quality of failure mode units continuously improves, accurate predictions are positively reinforced, inaccurate predictions are negatively penalized, insufficiently covered conditions are supplemented and expanded, and the prediction accuracy of the memory bank iterates continuously with operation; Second, agent behavior patterns are incorporated into modeling. Through the accumulation of non-compliance failure modes, the system gradually constructs a behavioral risk profile of agents, which can identify the degree of compliance of different agents with suggestions, dynamically adjust the risk score weight in subsequent pre-inspections, and automatically increase the warning weight of prompt-type strategies for agents with low compliance rates; Third, the effectiveness of strategies is independently evaluated. Through the decoupling of condition prediction and strategy effectiveness, the system can independently evaluate the effectiveness of blocking, prompting, and switching strategies in different scenarios, providing data support for subsequent strategy selection.

[0113] The aforementioned attribution feedback mechanism breaks through the limitations of traditional simple positive and negative feedback. It achieves differentiated memory updates through multi-dimensional and accurate attribution, which not only ensures the accumulation and reinforcement of effective failure experiences, but also avoids memory degradation caused by incorrect attribution. At the same time, it realizes the accumulation of multi-dimensional data on strategy effectiveness and agent behavioral characteristics, enabling the entire risk prediction system to have the ability to continuously self-optimize and evolve.

[0114] To more clearly illustrate the actual implementation effect of this solution, the following will provide a detailed explanation using three typical tool usage scenarios.

[0115] In the scenario of preventing timeout failures in database query tools, data analysis agents frequently encounter database timeouts when executing complex SQL queries. The system constructs corresponding failure mode units based on historical failure data. The tool is identified as sql_query_executor, the exception type is DatabaseTimeoutError, and the parameters include a three-table JOIN and an SQL statement without index filtering. The environment conditions correspond to a target table with 12 million rows and a connection pool utilization of 85%. The corresponding condition expression is "timeout_ms le 30000 AND table_rows gt 10000000 AND join_count ge 3". The corresponding remediation suggestions are to increase the timeout to 60000ms, add an index, and switch to paginated queries. When the Agent plans a similar query, sets a timeout of 25,000 ms, and involves multi-table JOINs, the pre-detection engine retrieves a matching failure mode unit with a mixed similarity of 0.92, a condition triggering degree of 0.95, and a comprehensive risk score of 0.85. This is classified as an extremely high-risk level, and a blocking strategy is executed. A blocking prediction report with historical failure warnings and repair suggestions is returned to the Agent. After the Agent adopts the suggestions and adjusts its parameters, it performs a pre-detection again, and the comprehensive risk score drops to 0.2. The task is eventually successfully executed.

[0116] Regarding API call permission errors, when an enterprise automation agent calls a third-party HR system API to retrieve employee information, it repeatedly returns a 401 Unauthorized error due to expired tokens. In the corresponding failure mode unit, the tool identifier is hr_api_client, and the error signature matches 401 + "Invalid or expired access token". The key conditional expression is "token_age_gt 3600 OR scope_not_contains employee:read". The suggested fix is ​​to automatically refresh the token or request higher permissions. Before the agent plans to call the HR API, the pre-detection engine detects that the current token has been used for 3200 seconds, close to the 3600-second threshold. It matches a corresponding historical failure mode with a similarity of 0.88, a conditional triggering degree of 0.82, and a comprehensive risk score of 0.72, classifying it as a high-risk level. A risk warning injection strategy is then implemented, injecting a risk warning into the agent context, informing the agent that the current token has 89% of its validity period expired and that a similar historical state has triggered a 401 error. The suggestion is to refresh the token before execution. After the agent adopts the suggestion and refreshes the token, the call succeeds, avoiding known failures with minimal process overhead.

[0117] Regarding the infinite loop risk scenario in code executors, when the programming agent executed user-submitted Python code, it triggered an infinite loop due to a data structure containing circular references in the input. The tool identifier for the corresponding failure mode unit was `python_executor`, the error signature was `TimeoutError + CPU 100%`, and the key conditional expression was: `"input_datacontains circular_reference OR recursive_depth gt 1000"`. The suggested remediation was to add loop detection and limit the recursion depth. When the agent planned to execute the user's Python code, the pre-detection engine detected a circular reference pattern in the input data structure through static analysis, matched the corresponding failure mode unit, with a similarity of 0.90, a conditional triggering degree of 1.0, and a comprehensive risk score of 0.92. This was determined to be an extremely high risk level, and a blocking strategy was implemented, returning a safe code template. The agent used the template to replace the original plan for execution, and the task was ultimately successful with a total time of only 3 seconds, preventing the execution of high-risk operations from the source.

[0118] The implementation verification in three scenarios shows that the present invention can proactively identify and avoid high-risk tool calls during the planning stage, effectively reducing the tool call failure rate. At the same time, by matching different risk levels through a tiered intervention strategy, it takes into account both the efficiency and security of task execution, and has good practical application value.

[0119] Overall, this invention represents a paradigm shift in the Agent tool call chain from post-event failure investigation and repair to pre-event risk prediction and avoidance. Through a three-level pre-inspection mechanism covering planning initiation, pre-execution verification, and runtime environment mutations, combined with a hybrid similarity retrieval capability integrating structured and semantic data, it constructs a three-dimensional weighted quantitative scoring system based on historical matching degree, conditional triggering degree, and environmental risk degree. This enables accurate identification and generalized matching of known failure patterns. A tiered, graded intervention strategy is provided, matching different levels of intervention intensity—no intervention, prompt injection, tool switching, and execution blocking—based on risk level, maximizing task execution continuity while avoiding known failure risks. Furthermore, this invention achieves differentiated feedback updates through a failure attribution arbitration mechanism, forming a complete self-evolving closed loop of failure accumulation, risk prediction, intervention, and attribution iteration. During operation, the accuracy of the failure pattern library and the effectiveness of intervention strategies are continuously optimized. Simultaneously, it includes mechanisms such as tool similarity graphs, breakpoint continuation, and standardized interfaces, demonstrating good engineering feasibility and compatibility with mainstream Agent frameworks. The overall solution can effectively reduce the failure rate of tool calls, reduce manual operation and maintenance costs, and significantly improve the fault tolerance, execution stability and overall execution efficiency of the Agent tool call chain.

[0120] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the above embodiments do not limit the present invention in any way, and all technical solutions obtained by equivalent substitution or equivalent transformation fall within the protection scope of the present invention.

Claims

1. A method for memorizing agent skill failure patterns based on tool execution feedback, characterized in that, Includes the following steps: When the Agent receives feedback that the execution of an external tool has failed, the failure context information corresponding to the external tool call is collected. The failure context information is structured and encoded into failure mode units and stored in the failure memory storage subsystem; After the Agent generates a new tool invocation plan and before the target tool is executed, the pre-detection engine is triggered to retrieve historical failure pattern units that match the current invocation context of the target tool from the failure memory storage subsystem, and calculates the comprehensive risk score of the target tool invocation based on the retrieved historical failure pattern units; Based on the comprehensive risk score, a corresponding intervention strategy is determined, and the intervention strategy is executed on the target tool; Based on the feedback information generated after the target tool is executed following intervention, the confidence level and match count of the corresponding failure mode unit in the failure memory storage subsystem are updated.

2. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 1, characterized in that, The step of structurally encoding the failure context information into failure mode units includes: The failure context information is classified into multiple levels to determine the major error category, sub-category, exception type, and attribution label of the failed external tool call; Extract key condition combinations from the failure context information to generate standardized condition expressions; The standardized conditional expression, the classification results of the multi-level error classification, and the preset repair suggestion information are assembled into a failure mode unit.

3. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 2, characterized in that, The large language model condition extractor extracts key condition combinations from the failure context information to generate standardized condition expressions, specifically including: Construct constraint prompts and input them into a large language model, and perform format validation on the original output of the large language model; The validated atomic conditions are combined and normalized according to the logical relationships in the original output to generate standardized conditional expressions. When the confidence level of the original output is lower than a preset threshold or the number of condition items discarded during format validation exceeds a preset proportion, a rule rollback mechanism is triggered, and a preset general condition template is mapped by looking up the classification results of the multi-level error classification.

4. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 1, characterized in that, The failure memory storage subsystem employs a hybrid storage architecture to index the failure mode units, including: The structured fields of the failure mode unit are stored in the structured storage layer and a structured index is created; The description text of the failure mode unit is encoded into a semantic vector and stored in the vector storage layer, and a semantic similarity index is established. An inverted index and a Bloom filter are built for the preset high-frequency retrieval dimensions as an index acceleration layer.

5. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 1, characterized in that, The pre-detection engine calculates a comprehensive risk score, specifically including: Using the current calling context of the target tool as the query condition, retrieve the K most similar historical failure pattern units from the failure memory storage subsystem as a candidate set; The historical matching degree is calculated based on the mixed similarity score and ranking weight of each candidate failure mode unit in the candidate set; The conditional expression of the failure mode unit with the highest similarity in the candidate set is expanded into disjunctive normal form, decomposed into multiple conjunctive clauses, and the satisfaction degree of the current calling context for each conjunctive clause is calculated. The maximum value of the satisfaction degree of all conjunctive clauses is taken as the conditional trigger degree. The environmental risk level is calculated by weighting system load, network latency, and dependent service health indicators in the current environment. The comprehensive risk score is obtained by weighting and summing the historical matching degree, the condition triggering degree, and the environmental risk degree.

6. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 5, characterized in that, The calculation of the satisfaction degree of each conjunction clause in the current calling context includes: For each atomic condition in the conjunction clause, the actual value of the corresponding field in the current calling context is extracted. Based on the operator type of the atomic condition, the actual value is matched with the threshold of the atomic condition, and the atomic condition satisfaction is output. The satisfaction of each atomic condition within the conjunction clause is weighted and aggregated to determine the satisfaction of the conjunction clause in the current calling context.

7. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 1, characterized in that, The triggering timing of the pre-detection engine includes: The planned pre-inspection is triggered after the Agent generates a new tool invocation plan and before the first tool is executed, and is used to perform a batch risk scan of all tool invocations. Step-level pre-inspection is triggered instantaneously before each tool invocation step is executed, and is used to perform a final interception check on the target tool; Dynamic pre-detection is triggered when an unexpected change in the environment is detected during the execution of the new tool invocation plan. It is used to predict the risk of re-executing subsequent tool invocations that have been planned but not yet executed.

8. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 7, characterized in that, The dynamic pre-detection also includes: Before the Agent initiates the execution of the new tool invocation plan, the new tool invocation plan is divided into transaction groups, and an execution checkpoint is generated and persisted before the execution of each transaction group. When the dynamic pre-detection determines that there is a risk of blocking subsequent steps and that the executed steps have produced side effects, rollback compensation or suspension of manual review is performed according to the configuration type of the transaction group to which the executed steps belong. Once the abnormal conditions that triggered the dynamic pre-check are resolved, the execution environment is restored from the execution checkpoint, and the completed steps are skipped to continue execution.

9. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 1, characterized in that, The step of determining the corresponding intervention strategy based on the comprehensive risk score specifically includes: When the comprehensive risk score is higher than the first preset threshold, it is determined to be an execution blocking strategy, which blocks the execution of the target tool, generates a blocking prediction report, and triggers the Agent to execute a replanning process; When the comprehensive risk score is higher than the second preset threshold but not higher than the first preset threshold, it is determined to be a tool switching strategy. The target tool is switched to a similar alternative tool and parameter mapping is performed before execution continues. When the comprehensive risk score is higher than the third preset threshold but not higher than the second preset threshold, it is determined to be a prompt injection strategy, and risk prompt information is injected into the current execution context of the Agent; When the comprehensive risk score is not higher than the third preset threshold, it is determined to be a no-intervention strategy, allowing the target tool to execute normally.

10. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 9, characterized in that, The step of switching the target tool to a functionally similar alternative tool includes: Calculate the initial functional similarity between tools based on the metadata of the registered tools, and construct a tool similarity graph; The tool similarity graph is used to query alternative tools with similar functions to the target tool. The calling parameters of the target tool are converted into a parameter format that the alternative tool can recognize before switching is performed. The weights of the edges in the tool similarity graph are dynamically updated according to the actual execution results of the tool switching.

11. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 1, characterized in that, Updating the confidence level and match count of the corresponding failure mode unit in the failure memory storage subsystem includes: When the feedback information generated after the intervention strategy is executed indicates that the execution was successful and the intervention strategy is adopted, the confidence of the corresponding failure mode unit is positively adjusted and its matching count is increased. When the intervention strategy is blocked and the Agent successfully executes the replanning process triggered after the blocking, the matching count of the corresponding failure mode unit is incremented. When the feedback information generated after the intervention strategy is executed indicates that the execution has failed and the intervention strategy is executed, the failure attribution arbitration is triggered. The responsibility attribution category is determined based on three dimensions: the Agent's compliance with the intervention strategy, the condition coverage of the failure mode unit by the execution failure context, and the degree of environmental anomaly.

12. The Agent Skill Failure Pattern Memory Method Based on Tool Execution Feedback according to claim 11, characterized in that, Differential feedback is performed based on the stated responsibility category, specifically as follows: If it falls under the category of Agent non-compliance, a new failure mode unit with the associated non-compliance tag will be generated; If the condition coverage is insufficient, the original cell is retained and a new cell is generated to record the current failure condition. If the prediction is accurate but the strategy is ineffective, the confidence level should be reduced. If it belongs to an unexpected environmental anomaly, then the conditional expression of the original unit is expanded.

Images