An agent workflow self-healing fault-tolerant method based on metacognition feedback regulation

Abstract

The application relates to an intelligent agent workflow self-recovery fault-tolerant method based on meta-cognition feedback regulation, belonging to the field of artificial intelligence and automatic repair, and comprising the following steps: after fault type identification, the order of fault processing is determined based on a fault processing priority scheduling mechanism; if there is "incomplete output", a multi-factor weighted scoring mechanism is used to select a repair strategy with the highest comprehensive score from a repair strategy set as a current repair action, and an effectiveness perception decision mechanism is used to arbitrate between continuing to wait for upstream repair and allowing downstream to execute in advance; if there is no "incomplete output", a repair strategy with the highest comprehensive score is directly selected as a repair action for the current fault; and finally, it is judged whether the repair action involves a retry operation. The application can make adaptive decisions based on the meta-cognition theory in combination with fault types, tool interdependence and recovery cost, and can improve fault recovery efficiency, reduce invalid retry and cascade blocking risk under the premise of ensuring final consistency.

Description

Technical Field

[0001] This invention relates to a self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation, belonging to the field of artificial intelligence and automated repair technology. Background Technology

[0002] With the rapid development of large language model technology, the research focus of intelligent agents is shifting from simple text generation to enhancing their ability to invoke external tools. By integrating external application programming interfaces (APIs), databases, and computing engines, intelligent agents can overcome the static knowledge limitations of large language models and perform complex real-world tasks, such as automated office work, financial analysis, and cross-platform resource scheduling. In these application scenarios, intelligent agents complete user instructions by planning and sequentially invoking external tools. Multiple tools often form workflows according to specific topologies, combining natural language understanding, logical reasoning, and the execution of specific software functions to form a long-chain reasoning and execution process. This is widely used in key business scenarios such as intelligent customer service, automated R&D, data analysis and report generation, and intelligent operation and maintenance.

[0003] However, unlike traditional, predefined, and structurally stable business processes, agent-driven workflows are characterized by distinct dynamism and uncertainty. Agents plan tool call sequences in real-time based on their understanding of the context; their execution paths, tool combinations, and data dependencies depend on task requirements and may dynamically adjust based on intermediate results. While this characteristic grants agents high flexibility, it also introduces new risks and reliability challenges. Any tool call may fail due to network jitter, service overload, permission changes, insufficient resources, input errors, or inherent defects. Due to the inherent fragility of agent workflows, the failure of a single tool call can easily trigger a cascading effect, amplifying the failure as it spreads throughout the workflow, leading to task interruptions, resource waste, impaired user experience, and even overall task failure, severely limiting the application of agent systems in production environments.

[0004] In recent years, researchers have conducted detailed investigations into failures during the tool invocation phase of intelligent agents, proposing improvement solutions from different perspectives. Agent trackers (AgenTracer) address failure localization in multi-agent or long execution trajectories by automatically annotating key error steps through counterfactual replay and programmatic fault injection, providing clear evidence for subsequent debugging and self-correction. AgenTracer automates the process of locating where and by whom errors occur, but its output remains at the attribution level, failing to further address how to select recovery strategies, prioritize repair actions, and achieve consistent recovery under concurrent and dynamic dependency conditions. Retrieval-driven recovery methods, represented by PALADIN, construct a relatively systematic training and inference framework for tool failure recovery. Through fault injection, recovery-annotated trajectories, and a fault example library, agents can retrieve similar cases and execute corresponding recovery actions after runtime errors occur, significantly improving recovery rate, task success rate, and generalization ability to unseen APIs. However, PALADIN relies heavily on example libraries and labeled trajectories, primarily optimizing the recovery effect itself, without addressing workflow-dependent topology, fault propagation impact, and global scheduling issues between different recovery actions. Structured reflection, a representative approach, makes the error diagnosis and correction process in tool calls explicit and trainable. Through a reflection chain of diagnosis, correction, and re-calling, it improves the success rate of multi-round tool interactions and alleviates the problem of models repeating errors after a single failed call. Structured reflection mainly focuses on error correction at the local call level, emphasizing parameter, format, and semantic consistency issues, but it hasn't yet covered fault propagation, parallel recovery, speculative execution under idempotency constraints, and maintaining post-recovery state consistency in complex workflows.

[0005] Existing technologies face three major gaps in handling fault tolerance issues related to agent tool invocation workflows: First, existing recovery mechanisms often emphasize task completion rates while giving less consideration to fault propagation risks, node position importance, and the cost differences of recovery actions. Second, the static nature of strategies is disconnected from dynamic workflows; existing fault tolerance mechanisms cannot adapt to the unpredictable dynamic dependency structures generated by agent workflows during runtime. Third, there is a lack of blind decision-making and risk awareness; fault tolerance decisions lack quantitative assessment support for the impact of faults. For issues such as parallel recovery, idempotent retries, speculative execution, and rollback verification, existing research still lacks systematic fault tolerance mechanisms for agent workflows.

[0006] Therefore, there is a lack of a method that can make adaptive decisions based on metacognitive theory, combined with fault type, inter-tool dependency relationship and recovery cost, for various faults that occur during the dynamic execution of intelligent agent workflow. Under the premise of ensuring eventual consistency, we should focus on improving fault recovery efficiency, reducing the risk of invalid retries and cascading blocking, and further adapting to the recovery scheduling requirements in multi-workflow concurrent scenarios. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a self-healing fault-tolerant method for agent workflows based on metacognitive feedback regulation. Based on fault identification reports, it makes adaptive recovery decisions according to fault type, idempotency, and topological impact, and rolls back when posterior verification fails. This invention not only selects repair strategies based on the type of fault in the agent workflow, but also continuously monitors the execution effect of the strategies, automatically updates strategy selection parameters, and adjusts the strategy execution effect, thereby forming a closed-loop fault-tolerant mechanism of perception, monitoring, and regulation.

[0008] The present invention adopts the following technical solution:

[0009] A self-healing and fault-tolerant method for agent workflow based on metacognitive feedback regulation includes the following steps:

[0010] S1. After completing the fault type identification, the order of fault handling in the same workflow or multiple concurrent execution workflows is determined based on the fault handling priority scheduling mechanism.

[0011] S2, determine whether there is a "incomplete output" fault type among the fault types;

[0012] For the fault type of "incomplete output", a set of repair strategies is mapped according to the fault type. A multi-factor weighted scoring mechanism is used to select the repair strategy with the highest comprehensive score from the set of repair strategies as the repair action for the current fault. A utility-aware decision-making mechanism is used to conduct controlled arbitration between continuing to wait for upstream repair and allowing downstream to execute first, so as to reduce the risk of global blocking caused by local faults.

[0013] S3. For fault types other than "incomplete output", the fault type is directly mapped to the set of repair strategies. A multi-factor weighted scoring mechanism is used to select the repair strategy with the highest comprehensive score from the set of repair strategies as the repair action for the current fault.

[0014] S4. Determine whether the repair actions in steps S2 and S3 involve retry operations. If not, execute the repair actions.

[0015] If applicable, before executing the repair action, determine whether the retry requirements are met. If they are met, execute the retry operation; if not, select the latest repair action based on a multi-factor weighted scoring mechanism.

[0016] S5: Repeat S4 for new repair actions until a repair action is performed or a retry operation is performed.

[0017] Preferably, after fault identification, the self-healing fault-tolerant module perceives the fault status, extracts the fault's topological location, upstream and downstream dependencies, fault propagation range, and the degree of impact of the fault on the overall task chain, thereby providing a basis for subsequent repair path selection. Limited by computing resources, execution bandwidth, and state dependencies, when multiple workflows are executed concurrently in a multi-agent system and multiple faults occur simultaneously, the handling of faults should be prioritized according to their urgency. In step S1, the implementation process of the fault handling priority scheduling mechanism is as follows:

[0018] For each tool node to be repaired The fault handling priority scheduling mechanism is based on the tool node. The location on the path, the impact of downstream congestion, the recoverable work retention value, and the ability to advance the overall task completion, are all factors to consider when calculating tool nodes. Task efficiency score :

[0019]

[0020] in, Downstream blocking degree, which is the proportion of downstream nodes that are blocked by the fault to downstream nodes that have not executed the tool; Recoverable value for work retention indicates how much of the completed computations, intermediate results, or valid information can be retained after the fault is fixed; that is, the proportion of all successfully executed tool nodes out of the total number of tool nodes in the entire workflow. The importance of a workflow is determined by its business priority, SLA urgency, and task importance. It is mainly used for fault handling and scheduling when multiple workflows fail simultaneously. If the number of failures in a multi-agent system is small and does not exceed its fault handling capacity, The default value is 0; , , These are weighted coefficients for downstream congestion, recoverable job retention value, and the importance of the associated workflow, set according to the execution status of the agent system's workflow. + + =1;

[0021] Based on task effectiveness score The nodes to be repaired are ranked according to their task effectiveness score. The process proceeded smoothly from high to low.

[0022] Preferably, in step S2, for a certain fault There exists a set of repair strategies consisting of multiple repair strategies. , Indicates the first There are several candidate remediation strategies, which differ in terms of remediation success rate, response latency, resource consumption, and recovery risk. Therefore, a multi-factor weighted scoring mechanism is needed to compare and select the best remediation strategy from the set. Specifically:

[0023] Calculate the overall score for each candidate repair strategy. :

[0024]

[0025] in, Indicates candidate repair strategies The expected success probability is estimated based on the results of historical successful fault repair execution records; Indicates candidate repair strategies The expected repair time is estimated based on the average repair time of historical faults; Indicates candidate repair strategies The expected resource overhead is defined as the normalized execution load caused by executing the strategy, including external interaction load and context replay load. External interaction load represents the normalized result of the number of call rounds initiated to external tools, external services or registry centers when executing the strategy. Context replay load represents the scale of historical context that needs to be replayed, reconstructed or passed when executing the strategy, which is obtained by normalizing the number of tokens, messages or state fields. Indicates candidate repair strategies The recovery risk cost is estimated based on factors such as whether the strategy may cause state pollution or link blockage; , , , These represent the weighting coefficients for the expected success probability, expected repair delay, expected resource overhead, and recovery risk cost, respectively. They characterize the current agent system's preference for these four factors during strategy selection, and their values ​​are independently determined by system requirements. Specifically, during peak business periods or when critical path tasks dominate, the system can increase the weighting of the expected success probability. And the weight of expected repair delay Prioritizing successful recovery and minimizing blocking time. In resource-constrained scenarios, the system can increase the weight of expected resource overhead. This reduces computational and communication overhead during the recovery process. In high-risk links or scenarios involving irreversible operations, the system can increase the weighting of recovery risk costs. Prioritize the suppression of potential state contamination or cascading errors. Weights can be set based on current business priorities, resource availability, task urgency, and risk tolerance, and adjusted as system requirements change while maintaining normalization constraints.

[0026] Candidate strategies Sort the strategies and select the one with the highest score as the priority repair action for the current fault.

[0027] It is worth noting that, Instead of being statically fixed, the self-healing fault-tolerant module continuously updates based on historical execution results. After each recovery strategy is executed, the module monitors and adjusts itself, recording the success or failure of the execution, the actual repair latency, resource consumption, and the risk impact of the strategy on subsequent links. This data is then incorporated into the historical sample set for the corresponding fault type. As historical samples accumulate, the statistical values ​​of the above four indicators are continuously revised, ensuring that the comparison criteria for subsequent candidate strategies always reflect the actual recovery performance of the current agent system, rather than relying on one-time experience or fixed initial values. Therefore, the strategy selection process can dynamically evolve with the actual execution situation, making subsequent recovery actions more aligned with the current fault mode, execution environment, and recovery results.

[0028] Preferably, traditional fault-tolerant logic typically treats "incomplete output" as a total failure, thus forcibly blocking all downstream tool nodes until the failed node successfully re-executes before resuming workflow. This approach can easily amplify local failures in long-link, high-concurrency workflows. On the one hand, the repair process itself has time costs, causing the workflow to stall for extended periods due to the partial incompleteness of a single node; on the other hand, some downstream nodes actually only depend on a specific subset of the upstream output. If this subset is sufficient to meet the input requirements, implementing a global blockade on the entire link will significantly reduce parallel execution efficiency. This invention introduces a utility-aware decision-making mechanism. The core of this mechanism is to identify the data portions in the incomplete output that still have usable value, and, under the premise of meeting safety constraints, allow eligible downstream nodes to proceed first. This allows self-healing retries and effective computation to partially overlap in time, reducing the risk of global blocking caused by local failures and improving the overall throughput efficiency and response determinism of the workflow.

[0029] In step S2, the utility perception decision-making mechanism consists of execution access hard constraints and a metacognitive evaluation model. The execution access hard constraints include input completeness judgment and instrument idempotency judgment. Only downstream tool nodes that simultaneously satisfy completeness and instrument idempotency can pass the execution access hard constraints and proceed to the next step of utility evaluation based on the metacognitive evaluation model.

[0030] Preferred tool nodes that generate "incomplete output" errors Its downstream tool node set is Based on the workflow structure, determine one by one whether the set B of all required input parameters for downstream tool nodes is completely contained within the tool node. If the output data set A is completely contained, then the downstream tool node satisfies the input completeness requirement.

[0031] Subsequently, it is determined whether each downstream tool node with complete input possesses tool idempotency. If it is idempotent, the downstream tool node performs a utility evaluation based on a metacognitive evaluation model. Otherwise, the downstream tool node cannot be triggered and waits for the upstream faulty node to be repaired, in order to prevent non-idempotent tools such as transfers, asset changes, physical equipment operations, or data deletion from being prematurely triggered under uncertain conditions.

[0032] The idempotency assessment mechanism determines whether repeated triggering of a candidate tool under the same input and execution context will produce unacceptable new side effects or final state shifts. Idempotency determination is implemented through the following methods:

[0033] ① By retrieving the API specifications, function descriptions, and request parameter definitions of the retrieval tool, extract the action predicate, resource operation mode, and whether there is an idempotency control field. If the tool protocol explicitly supports idempotency keys, trial run parameters (dry_run or test_mode), or equivalent duplicate request deduplication mechanisms, then under the same parameters and the same context, the tool is determined to be logically idempotent at the protocol layer and possesses idempotency.

[0034] If the tool's protocol explicitly states that repeated execution will result in new side effects, repeated writes and appends, repeated billing, repeated order placement, or other state changes, then the tool is directly determined to be non-idempotent.

[0035] If the tool protocol does not explicitly provide semantic information regarding the constraints on duplicate request deduplication, trial runs, or repeated execution side effects, i.e., static semantic heuristic identification cannot provide a clear conclusion, then the idempotency of the tool is determined to be unknown.

[0036] ② For tools with unknown idempotency, idempotency is further determined through sandbox simulation. First, a baseline snapshot containing the target tool and its minimum necessary dependencies is constructed. Then, two or more identical isolated execution instances are derived from the baseline snapshot, and the same operation is performed in each instance using the same input parameters. During execution, the observed side effects of the tool are recorded through runtime monitoring, including file system changes, network requests, process creation, database writes, and external state updates. Subsequently, the results after execution of each instance are compared. If the final external state is consistent after multiple executions under the same baseline snapshot and the same input conditions, and repeated execution does not introduce new side effects, then the tool is determined to be idempotent. If repeated execution leads to new writes, duplicate commits, state drift, or other unacceptable side effects, then the tool is determined to be non-idempotent. When the target tool cannot build a reproducible baseline snapshot in an isolated environment, or cannot stably reproduce the execution behavior under the same input conditions, then the tool does not meet the sandbox simulation verification conditions and is conservatively marked as having unknown idempotency.

[0037] To balance accuracy and security, the tool's idempotency identification mechanism employs a two-stage strategy: static semantic heuristic identification as the primary method and empirical verification in an isolated environment as a secondary method. It avoids initiating exploratory calls directly in the production environment to prevent data contamination or resource misoperation caused by black-box testing.

[0038] Preferably, after completing the hard constraint judgment for execution access, a metacognitive evaluation model is constructed based on the time-resource equivalence principle to compare the relative benefits of speculative execution and conservative blocking. The time-resource equivalence principle states that in constrained systems, execution time and computational resources are exchangeable; that is, the system can shorten execution time by increasing computational resources or reduce resource consumption by extending execution time. This model maps the computational resource consumption, semantic conflict risk, and cascading rollback cost of speculative execution to opportunity costs in the time dimension, while mapping the link stagnation loss caused by conservative blocking to waiting costs, thus establishing a comparable relationship between the two. Specifically, when speculative execution can significantly shorten the overall recovery time, and the expected cost of triggering semantic conflicts or cascading rollback is lower than the loss caused by continued blocking, this mechanism allows eligible downstream nodes to execute first. Otherwise, conservative blocking is maintained, waiting for the upstream faulty node to complete repair before proceeding. This mechanism achieves differentiated recovery and dynamic scheduling for some execution scenarios while ensuring eventual consistency.

[0039] Specifically, in the utility evaluation process based on the metacognitive evaluation model, the expected risk of execution is inferred by calculation. Conservative blocking expected loss Arbitration should be conducted. The cost of ineffective computation caused by logical inversion due to incomplete semantics is quantified by the following formula:

[0040]

[0041] in, The probability of tool failure is determined by calculating the proportion of historical failures to the total number of historical calls. Risk of semantic conflict; To estimate the cost of cascading rollback, we calculate the computational resources and time overhead required to undo or replay all affected downstream nodes if the speculative execution fails. This is positively correlated with the topology impact range in the workflow, as shown in the following formula:

[0042]

[0043] Physical rollback time is the actual time required to perform compensating actions such as deleting dirty data and resetting the state. The equivalent time of loss is that due to the failure of speculative execution, all the downstream computing tasks that have been completed are rendered useless. The time originally consumed by these tasks is regarded as the system idle time loss, also known as the equivalent time of loss.

[0044] Semantic conflict risk By calculating the similarity between the output data and the template data, the probability of a logical reversal between the output data and potentially missing data is determined, i.e., whether subsequent logic will correct or negate the current instruction. In the calculation... When considering all downstream tool nodes, whether they are direct or indirect downstream tool nodes, Unchanging, only and It varies depending on the tool node.

[0045] Semantic conflict risk The calculation process is as follows:

[0046] First, semantic templates for the corresponding output items are abstracted from the tool documentation and historical correct outputs. Then, the actual output data items of the tool and the semantic templates are converted into semantic vectors. , The cosine similarity between the actual output data item and the semantic template is calculated to dynamically assess the risk of semantic conflict. The formula is shown below:

[0047]

[0048] in, express The second norm; express The 2-norm.

[0049] Preferred conservative blocking expected loss The global response latency cost caused by waiting for tool retries is quantified, as shown in the following formula:

[0050]

[0051] in, The repair time is the weighted sum of the repair time and the trigger probability of each repair measure segment. The topology impact factor is defined as the total number of downstream tool nodes directly or indirectly blocked by a faulty tool node. Total number of nodes in the workflow The ratio reflects the extent to which blocking behavior drags down the overall progress, and the formula is as follows:

[0052]

[0053] The utility-perceived decision-making mechanism performs the final policy determination through the following inequality:

[0054]

[0055] If the inequality is true, the speculative flow strategy is executed, driving downstream branches that meet the conditions to start first; otherwise, the conservative waiting strategy is executed, forcing the synchronization waiting tool to retry and complete.

[0056] Preferably, after the upstream faulty node completes self-healing repair, the output used by speculative execution is subjected to secondary auditing and state calibration:

[0057] First, from the tool nodes Extract the data set corresponding to the input parameter data set B that previously flowed into the downstream tool node from the latest output data. Then set B and set These two sets of data are compared in a multi-dimensional semantic way, with the comparison dimensions including field consistency, logical constraint satisfaction, and context dependency continuity.

[0058] If any of the following conditions are not met: field consistency, logical constraint satisfaction, or context dependency continuity, a rollback mechanism is triggered. Otherwise, the previous speculative execution is considered accurate, and no rollback mechanism is needed for downstream paths, thus maximizing the retention of the task latency reduction and efficiency gains brought by speculative execution. If the rollback mechanism is triggered, the temporary results, cached intermediate states, local computation contexts, and temporary resource occupations generated by the speculative execution branch are first revoked, and the downstream states generated by speculative execution are invalidated. Subsequently, the tool node... The execution inputs of the downstream tool nodes are rebound to the fixed version. The relevant downstream nodes are re-triggered to execute based on the latest input. Since speculative execution only applies to tool nodes with idempotency, repeated execution does not introduce cumulative side effects. Therefore, the rollback process mainly involves resetting the logical state and invalidating the result, without the need for compensatory rollback of the external persistent state. This maintains eventual consistency while avoiding unnecessary rollback costs.

[0059] Preferably, in step S4, if the repair action involves a retry operation, an idempotency determination is performed; if the determination is idempotent, a retry operation is performed.

[0060] If the operation is determined to be non-idempotent, retrying is prohibited, and the repair strategy is switched according to the multi-factor weighted scoring mechanism.

[0061] If the idempotency is determined to be unknown, manual judgment is used. If the retry operation is confirmed by the manual judge to be free from side effects, the retry operation is executed. Otherwise, it is considered non-idempotent, the retry operation is prohibited, and the repair strategy is switched according to the multi-factor weighted scoring mechanism.

[0062] For any details not covered in this invention, please refer to the prior art.

[0063] The beneficial effects of this invention are as follows:

[0064] 1. This invention enables automatic repair based on fault type after fault identification. If multiple candidate repair strategies exist, they are compared using a multi-factor weighted scoring mechanism to select the repair scheme that best matches the current fault scenario. Simultaneously, by incorporating an idempotency identification mechanism, blind retries in non-idempotent scenarios are limited, reducing ineffective recovery, repetitive side effects, and recovery mismatch risks, thereby improving the timeliness, accuracy, and security of fault repair.

[0065] 2. This invention employs a utility-aware decision-making mechanism to predictively execute downstream nodes that meet the hard constraints of execution admission. This breaks away from the rigid all-or-nothing execution paradigm of traditional automated processes, allowing the self-healing process and efficient computation to proceed in parallel. This reduces link congestion and recovery latency, while improving workflow execution efficiency. When the upstream repair result differs from the predicted execution result, consistency is restored through verification and rollback mechanisms, thus balancing efficiency improvement and result accuracy. This shortens the overall task latency while ensuring eventual consistency.

[0066] 3. This invention can learn from historical recovery results through an adaptive control module, continuously adjust the weights and execution control parameters in the comprehensive score, and support fault sorting within the same workflow and between multiple workflows by combining a fault handling priority scheduling mechanism. This reduces the additional overhead caused by ineffective recovery and resource contention, and enhances the adaptive control and concurrent scheduling capabilities in complex dynamic environments. Attached Figure Description

[0067] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0068] Figure 1 This is a schematic diagram of the framework of the intelligent agent workflow self-healing fault-tolerant method based on metacognitive feedback regulation of the present invention.

[0069] Figure 2 This is a schematic diagram of the utility perception decision-making mechanism of the present invention. Detailed Implementation

[0070] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. However, this is not the only description; all aspects not described in detail herein are based on conventional techniques in the art.

[0071] Example 1

[0072] A self-healing and fault-tolerant method for agent workflow based on metacognitive feedback regulation, such as Figure 1 As shown, it includes the following steps:

[0073] S1. After completing the fault type identification, the order of fault handling in the same workflow or multiple concurrent execution workflows is determined based on the fault handling priority scheduling mechanism.

[0074] S2, determine whether there is a "incomplete output" fault type among the fault types;

[0075] For the fault type of "incomplete output", a set of repair strategies is mapped according to the fault type. A multi-factor weighted scoring mechanism is used to select the repair strategy with the highest comprehensive score from the set of repair strategies as the repair action for the current fault. A utility-aware decision-making mechanism is used to conduct controlled arbitration between continuing to wait for upstream repair and allowing downstream to execute first, so as to reduce the risk of global blocking caused by local faults.

[0076] S3. For fault types other than "incomplete output", the fault type is directly mapped to the set of repair strategies. A multi-factor weighted scoring mechanism is used to select the repair strategy with the highest comprehensive score from the set of repair strategies as the repair action for the current fault.

[0077] S4. Determine whether the repair actions in steps S2 and S3 involve retry operations. If not, execute the repair actions.

[0078] If applicable, before executing the repair action, determine whether the retry requirements are met. If they are met, execute the retry operation; if not, select the latest repair action based on a multi-factor weighted scoring mechanism.

[0079] S5: Repeat S4 for new repair actions until a repair action is performed or a retry operation is performed.

[0080] Example 2

[0081] A self-healing fault-tolerant method for agent workflow based on metacognitive feedback regulation, as described in Example 1, differs in that, after fault identification, the self-healing fault-tolerant module perceives the fault status, extracts the fault's topological location, upstream and downstream dependencies, fault propagation range, and the degree of impact of the fault on the overall task chain, thereby providing a basis for subsequent repair path selection. Limited by computing resources, execution bandwidth, and state dependencies, when multiple workflows are executed concurrently in a multi-agent system and multiple faults occur simultaneously, the handling of faults should be prioritized according to their urgency. In step S1, the implementation process of the fault handling priority scheduling mechanism is as follows:

[0082] For each tool node to be repaired The fault handling priority scheduling mechanism is based on the tool node. The location on the path, the impact of downstream congestion, the recoverable work retention value, and the ability to advance the overall task completion, are all factors to consider when calculating tool nodes. Task efficiency score :

[0083]

[0084] in, Downstream blocking degree, which is the proportion of downstream nodes that are blocked by the fault to downstream nodes that have not executed the tool; Recoverable value for work retention indicates how much of the completed computations, intermediate results, or valid information can be retained after the fault is fixed; that is, the proportion of all successfully executed tool nodes out of the total number of tool nodes in the entire workflow. The importance of a workflow is determined by its business priority, SLA urgency, and task importance. It is mainly used for fault handling and scheduling when multiple workflows fail simultaneously. If the number of failures in a multi-agent system is small and does not exceed its fault handling capacity, The default value is 0; , , These are weighted coefficients for downstream congestion, recoverable job retention value, and the importance of the associated workflow, set according to the execution status of the agent system's workflow. + + =1;

[0085] Based on task effectiveness score The nodes to be repaired are ranked according to their task effectiveness score. The process proceeded smoothly from high to low.

[0086] Example 3

[0087] A self-healing fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation, as described in Example 1, differs in that, in step S2, for a certain fault... There exists a set of repair strategies consisting of multiple repair strategies. , Indicates the first There are several candidate remediation strategies, which differ in terms of remediation success rate, response latency, resource consumption, and recovery risk. Therefore, a multi-factor weighted scoring mechanism is needed to compare and select the best remediation strategy from the set. Specifically:

[0088] Calculate the overall score for each candidate repair strategy. :

[0089]

[0090] in, Indicates candidate repair strategies The expected success probability is estimated based on the results of historical successful fault repair execution records; Indicates candidate repair strategies The expected repair time is estimated based on the average repair time of historical faults; Indicates candidate repair strategies The expected resource overhead is defined as the normalized execution load caused by executing the strategy, including external interaction load and context replay load. External interaction load represents the normalized result of the number of call rounds initiated to external tools, external services or registry centers when executing the strategy. Context replay load represents the scale of historical context that needs to be replayed, reconstructed or passed when executing the strategy, which is obtained by normalizing the number of tokens, messages or state fields. Indicates candidate repair strategies The recovery risk cost is estimated based on factors such as whether the strategy may cause state pollution or link blockage; , , , These represent the weighting coefficients for the expected success probability, expected repair delay, expected resource overhead, and recovery risk cost, respectively. They characterize the current agent system's preference for these four factors during strategy selection, and their values ​​are independently determined by system requirements. Specifically, during peak business periods or when critical path tasks dominate, the system can increase the weighting of the expected success probability. And the weight of expected repair delay Prioritizing successful recovery and minimizing blocking time. In resource-constrained scenarios, the system can increase the weight of expected resource overhead. This reduces computational and communication overhead during the recovery process. In high-risk links or scenarios involving irreversible operations, the system can increase the weighting of recovery risk costs. Prioritize the suppression of potential state contamination or cascading errors. Weights can be set based on current business priorities, resource availability, task urgency, and risk tolerance, and adjusted as system requirements change while maintaining normalization constraints.

[0091] Candidate strategies Sort the strategies and select the one with the highest score as the priority repair action for the current fault.

[0092] It is worth noting that, Instead of being statically fixed, the self-healing fault-tolerant module continuously updates based on historical execution results. After each recovery strategy is executed, the module monitors and adjusts itself, recording the success or failure of the execution, the actual repair latency, resource consumption, and the risk impact of the strategy on subsequent links. This data is then incorporated into the historical sample set for the corresponding fault type. As historical samples accumulate, the statistical values ​​of the above four indicators are continuously revised, ensuring that the comparison criteria for subsequent candidate strategies always reflect the actual recovery performance of the current agent system, rather than relying on one-time experience or fixed initial values. Therefore, the strategy selection process can dynamically evolve with the actual execution situation, making subsequent recovery actions more aligned with the current fault mode, execution environment, and recovery results.

[0093] Example 4

[0094] A self-healing fault-tolerant method for intelligent agent workflows based on metacognitive feedback regulation, as described in Example 1, differs from traditional fault-tolerant logic, which typically treats "incomplete output" as a total failure, thus forcibly blocking all downstream tool nodes until the failed node successfully re-executes before resuming workflow. This approach easily leads to the amplification of local faults in long-link, high-concurrency workflows. On the one hand, the repair process itself has time costs, causing the workflow to stagnate for a long time due to the partial incompleteness of a single node; on the other hand, some downstream nodes actually only depend on a specific subset of the upstream output. If this subset is sufficient to meet the input requirements, implementing global blocking of the entire link will significantly reduce parallel execution efficiency. This invention introduces a utility-aware decision-making mechanism. The core of this mechanism is to identify the data parts in the incomplete output that still have usable value, and, under the premise of meeting safety constraints, allow eligible downstream nodes to proceed first. This allows self-healing retries and effective computation to partially overlap in time, reducing the risk of global blocking caused by local faults and improving the overall throughput efficiency and response determinism of the workflow.

[0095] In step S2, the utility perception decision-making mechanism consists of execution access hard constraints and a metacognitive evaluation model, such as... Figure 2 As shown, the execution of hard access constraints includes input completeness judgment and tool idempotency judgment. Only downstream tool nodes that simultaneously satisfy completeness and tool idempotency can pass the execution of hard access constraints and proceed to the next step of utility evaluation based on the metacognitive evaluation model.

[0096] Tool nodes that encounter "incomplete output" errors Its downstream tool node set is Based on the workflow structure, determine one by one whether the set B of all required input parameters for downstream tool nodes is completely contained within the tool node. If the output data set A is completely contained, then the downstream tool node satisfies the input completeness requirement.

[0097] Subsequently, it is determined whether each downstream tool node with complete input possesses tool idempotency. If it is idempotent, the downstream tool node performs a utility evaluation based on a metacognitive evaluation model. Otherwise, the downstream tool node cannot be triggered and waits for the upstream faulty node to be repaired, in order to prevent non-idempotent tools such as transfers, asset changes, physical equipment operations, or data deletion from being prematurely triggered under uncertain conditions.

[0098] Example 5

[0099] A self-healing and fault-tolerant workflow method for intelligent agents based on metacognitive feedback regulation is presented, as described in Example 4. The difference lies in the idempotency identification mechanism used to determine whether repeated triggering of a candidate tool under the same input and execution context will produce unacceptable new side effects or final state shifts. Idempotency determination is achieved through the following method:

[0100] ① By retrieving the API specifications, function descriptions, and request parameter definitions of the retrieval tool, extract the action predicate, resource operation mode, and whether there is an idempotency control field. If the tool protocol explicitly supports idempotency keys, trial run parameters (dry_run or test_mode), or equivalent duplicate request deduplication mechanisms, then under the same parameters and the same context, the tool is determined to be logically idempotent at the protocol layer and possesses idempotency.

[0101] If the tool's protocol explicitly states that repeated execution will result in new side effects, repeated writes and appends, repeated billing, repeated order placement, or other state changes, then the tool is directly determined to be non-idempotent.

[0102] If the tool protocol does not explicitly provide semantic information regarding the constraints on duplicate request deduplication, trial runs, or repeated execution side effects, i.e., static semantic heuristic identification cannot provide a clear conclusion, then the idempotency of the tool is determined to be unknown.

[0103] ② For tools with unknown idempotency, idempotency is further determined through sandbox simulation. First, a baseline snapshot containing the target tool and its minimum necessary dependencies is constructed. Then, two or more identical isolated execution instances are derived from the baseline snapshot, and the same operation is performed in each instance using the same input parameters. During execution, observed side effects of the tool are recorded through runtime monitoring, including file system changes, network requests, process creation, database writes, and external state updates. Subsequently, the results of each instance are compared. If, under the same baseline snapshot and the same input conditions, the final external state is consistent after multiple executions, and repeated executions do not introduce new side effects, the tool is determined to be idempotent. If repeated executions lead to new writes, duplicate commits, state drift, or other unacceptable side effects, the tool is determined to be non-idempotent. When the target tool cannot build a reproducible baseline snapshot in an isolated environment, or cannot stably reproduce its execution behavior under the same input conditions, the tool does not meet the sandbox simulation verification conditions and is conservatively marked as having unknown idempotency.

[0104] To balance accuracy and security, the tool's idempotency identification mechanism employs a two-stage strategy: static semantic heuristic identification as the primary method and empirical verification in an isolated environment as a secondary method. It avoids initiating exploratory calls directly in the production environment to prevent data contamination or resource misoperation caused by black-box testing.

[0105] Example 6

[0106] A self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation is presented in Example 5. The difference lies in that, after completing the hard constraint judgment for execution admission, a metacognitive evaluation model is constructed based on the time-resource equivalence principle to compare the relative benefits of speculative execution and conservative blocking. The time-resource equivalence principle states that in constrained systems, execution time and computational resources are exchangeable; that is, the system can shorten execution time by increasing computational resources or reduce resource consumption by extending execution time. This model maps the computational resource consumption, semantic conflict risk, and cascading rollback cost of speculative execution to opportunity costs in the time dimension, while mapping the link stagnation loss caused by conservative blocking to waiting costs, thus establishing a comparable relationship between the two. Specifically, when speculative execution can significantly shorten the overall recovery time, and the expected cost of triggering semantic conflicts or cascading rollback is lower than the loss caused by continued blocking, this mechanism allows eligible downstream nodes to execute first. Otherwise, conservative blocking is maintained, waiting for the upstream faulty node to complete repair before proceeding. This mechanism enables differentiated recovery and dynamic scheduling for certain execution scenarios while ensuring eventual consistency.

[0107] Specifically, in the utility evaluation process based on the metacognitive evaluation model, the expected risk of execution is inferred by calculation. Conservative blocking expected loss Arbitration should be conducted. The cost of ineffective computation caused by logical inversion due to incomplete semantics is quantified by the following formula:

[0108]

[0109] in, The probability of tool failure is determined by calculating the proportion of historical failures to the total number of historical calls. Risk of semantic conflict; To estimate the cost of cascading rollback, we calculate the computational resources and time overhead required to undo or replay all affected downstream nodes if the speculative execution fails. This is positively correlated with the topology impact range in the workflow, as shown in the following formula:

[0110]

[0111] Physical rollback time is the actual time required to perform compensating actions such as deleting dirty data and resetting the state. The equivalent time of loss is that due to the failure of speculative execution, all the downstream computing tasks that have been completed are rendered useless. The time originally consumed by these tasks is regarded as the system idle time loss, also known as the equivalent time of loss.

[0112] Semantic conflict risk By calculating the similarity between the output data and the template data, the probability of a logical reversal between the output data and potentially missing data is determined, i.e., whether subsequent logic will correct or negate the current instruction. In the calculation... When considering all downstream tool nodes, whether they are direct or indirect downstream tool nodes, Unchanging, only and It varies depending on the tool node.

[0113] Semantic conflict risk The calculation process is as follows:

[0114] First, semantic templates for the corresponding output items are abstracted from the tool documentation and historical correct outputs. Then, the actual output data items of the tool and the semantic templates are converted into semantic vectors. , The cosine similarity between the actual output data item and the semantic template is calculated to dynamically assess the risk of semantic conflict. The formula is shown below:

[0115]

[0116] in, express The second norm; express The 2-norm.

[0117] Preferred conservative blocking expected loss The global response latency cost caused by waiting for tool retries is quantified, as shown in the following formula:

[0118]

[0119] in, The repair time is the weighted sum of the repair time and the trigger probability of each repair measure segment. The topology impact factor is defined as the total number of downstream tool nodes directly or indirectly blocked by a faulty tool node. Total number of nodes in the workflow The ratio reflects the extent to which blocking behavior drags down the overall progress, and the formula is as follows:

[0120]

[0121] The utility-perceived decision-making mechanism performs the final policy determination through the following inequality:

[0122]

[0123] If the inequality is true, the speculative flow strategy is executed, driving downstream branches that meet the conditions to start first; otherwise, the conservative waiting strategy is executed, forcing the synchronization waiting tool to retry and complete.

[0124] Example 7

[0125] A self-healing fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation, as described in Example 6, differs in that, after the upstream fault node completes self-healing repair, a secondary audit and state calibration are performed on the output used by speculative execution:

[0126] First, from the tool nodes Extract the data set corresponding to the input parameter data set B that previously flowed into the downstream tool node from the latest output data. Then set B and set These two sets of data are compared in a multi-dimensional semantic way, with the comparison dimensions including field consistency, logical constraint satisfaction, and context dependency continuity.

[0127] If any of the following conditions are not met: field consistency, logical constraint satisfaction, or context dependency continuity, a rollback mechanism is triggered. Otherwise, the previous speculative execution is considered accurate, and no rollback mechanism is needed for downstream paths, thus maximizing the retention of the task latency reduction and efficiency gains brought by speculative execution. If the rollback mechanism is triggered, the temporary results, cached intermediate states, local computation contexts, and temporary resource occupations generated by the speculative execution branch are first revoked, and the downstream states generated by speculative execution are invalidated. Subsequently, the tool node... The execution inputs of the downstream tool nodes are rebound to the fixed version. The relevant downstream nodes are re-triggered to execute based on the latest input. Since speculative execution only applies to tool nodes with idempotency, repeated execution does not introduce cumulative side effects. Therefore, the rollback process mainly involves resetting the logical state and invalidating the result, without the need for compensatory rollback of the external persistent state. This maintains eventual consistency while avoiding unnecessary rollback costs.

[0128] Example 8

[0129] A self-healing fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation, as described in Example 7, except that in step S4, if the repair action involves a retry operation, an idempotency determination is performed; if the determination is idempotent, a retry operation is executed.

[0130] If the operation is determined to be non-idempotent, retrying is prohibited, and the repair strategy is switched according to the multi-factor weighted scoring mechanism.

[0131] If the idempotency is determined to be unknown, manual judgment is used. If the retry operation is confirmed by the manual judge to be free from side effects, the retry operation is executed. Otherwise, it is considered non-idempotent, the retry operation is prohibited, and the repair strategy is switched according to the multi-factor weighted scoring mechanism.

[0132] Example 9

[0133] A self-healing and fault-tolerant intelligent agent workflow system based on metacognitive feedback regulation, used to implement the self-healing and fault-tolerant intelligent agent workflow method based on metacognitive feedback regulation described in Example 1, includes:

[0134] The fault type identification module is used to identify fault types and determine whether there is "incomplete output";

[0135] The decision-making module is used to employ a utility-aware decision-making mechanism to conduct controlled arbitration between continuing to wait for upstream repair and allowing downstream to proceed first, in order to reduce the risk of global blockage caused by local failures.

[0136] The self-healing fault-tolerant module is used to determine the order of fault handling in the same workflow or multiple concurrent execution workflows based on the fault handling priority scheduling mechanism.

[0137] The repair strategy decision module is used to select the repair strategy with the highest comprehensive score from the repair strategy set as the repair action for the current fault using a multi-factor weighted scoring mechanism; and to determine whether the repair action involves a retry operation.

[0138] The adaptive control module learns from historical recovery results and continuously adjusts the weights and execution control parameters in the overall score of candidate repair strategies.

[0139] Example 10

[0140] An electronic device includes a memory, a processor, and a computer program. The processor is connected to the memory, and the computer program is stored in the memory. When the electronic device is running, the processor executes the computer program stored in the memory to implement the steps of the self-healing fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation in Embodiment 1.

[0141] Example 11

[0142] A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the self-healing fault-tolerant intelligent agent workflow method based on metacognitive feedback regulation as described in Embodiment 1 above.

[0143] Example 12

[0144] A computer program product includes a computer program that, when executed by a processor, implements the steps of the self-healing fault-tolerant intelligent agent workflow method based on metacognitive feedback regulation of Embodiment 1.

[0145] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation, characterized in that, Includes the following steps: S1. After completing the fault type identification, the order of fault handling in the same workflow or multiple concurrent execution workflows is determined based on the fault handling priority scheduling mechanism. S2, determine whether there is a "incomplete output" fault type among the fault types; For the "incomplete output" fault type, a set of repair strategies is mapped according to the fault type. A multi-factor weighted scoring mechanism is used to select the repair strategy with the highest comprehensive score from the set of repair strategies as the repair action for the current fault. A utility-aware decision-making mechanism is used to conduct controlled arbitration between continuing to wait for upstream repair and allowing downstream to execute first, so as to reduce the risk of global blocking caused by local faults. S3. For fault types other than "incomplete output", the fault type is directly mapped to the set of repair strategies. A multi-factor weighted scoring mechanism is used to select the repair strategy with the highest comprehensive score from the set of repair strategies as the repair action for the current fault. S4. Determine whether the repair actions in steps S2 and S3 involve retry operations. If not, execute the repair actions. If applicable, before executing the repair action, determine whether the retry requirements are met. If they are met, execute the retry operation; if not, select the latest repair action based on a multi-factor weighted scoring mechanism. S5: Repeat S4 for new repair actions until a repair action is performed or a retry operation is performed.

2. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 1, characterized in that, In step S1, the implementation process of the fault handling priority scheduling mechanism is as follows: For each tool node to be repaired The fault handling priority scheduling mechanism is based on the tool node. The location on the path, the impact of downstream congestion, the recoverable work retention value, and the ability to advance the overall task completion, are all factors to consider when calculating tool nodes. Task efficiency score : in, Downstream blockage degree; Preserve value for recoverable work; The importance of the workflow to which it belongs; , , These are the weighting coefficients for downstream congestion, recoverable job retention value, and the importance of the associated workflow, respectively. + + =1; Based on task effectiveness score The nodes to be repaired are ranked according to their task effectiveness score. The process proceeded smoothly from high to low.

3. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 2, characterized in that, In step S2, for a certain fault There exists a set of repair strategies consisting of multiple repair strategies. , Indicates the first For each of the candidate repair strategies, a comprehensive score is calculated. : in, Indicates candidate repair strategies The expected probability of success; Indicates candidate repair strategies The estimated repair time; Indicates candidate repair strategies Projected resource expenditure; Indicates candidate repair strategies The risks and costs of recovery; , , , These represent the weighting coefficients for the expected success probability, expected repair delay, expected resource consumption, and recovery risk cost, respectively.

4. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 3, characterized in that, In step S2, the utility perception decision-making mechanism consists of execution access hard constraints and a metacognitive evaluation model. The execution access hard constraints include input completeness judgment and instrument idempotency judgment. Only downstream tool nodes that simultaneously satisfy completeness and instrument idempotency can pass the execution access hard constraints and proceed to the next step of utility evaluation based on the metacognitive evaluation model.

5. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 4, characterized in that, Tool nodes that encounter "incomplete output" errors Its downstream tool node set is Based on the workflow structure, determine one by one whether the set B of all required input parameters for downstream tool nodes is completely contained within the tool node. If the output data set A is completely contained, then the downstream tool node satisfies the input completeness requirement. Subsequently, it is determined whether each downstream tool node with complete input possesses tool idempotency. If it is idempotent, the downstream tool node performs a utility evaluation based on a metacognitive evaluation model; otherwise, the downstream tool node cannot be triggered and waits for the upstream faulty node to be repaired.

6. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 5, characterized in that, Idempotency is determined using the following method: ① By retrieving the API specifications, function descriptions, and request parameter definitions of the retrieval tool, extract the action predicate, resource operation mode, and whether there is an idempotent control field. If the tool protocol explicitly supports idempotent keys, trial run parameters, or equivalent duplicate request deduplication mechanisms, then the tool is idempotent under the same parameters and the same context. If the tool's protocol explicitly states that repeated execution will result in new side effects, repeated writes and appends, repeated billing, repeated order placement, or other state changes, then the tool is directly determined to be non-idempotent. If the tool protocol does not explicitly provide semantic information regarding the constraints on duplicate request deduplication, trial runs, or repeated execution side effects, i.e., static semantic heuristic identification cannot provide a clear conclusion, then the idempotency of the tool is determined to be unknown. ② For tools with unknown idempotency, further idempotency determination is carried out through sandbox simulation verification. First, a baseline snapshot containing the target tool and its minimum necessary dependencies is constructed. Then, two or more completely identical isolated execution instances are derived based on the baseline snapshot. The same operation is performed in each instance using the same input parameters. During execution, the observed side effects of the tool are recorded through runtime monitoring, including file system changes, network requests, process creation, database writes, and external state updates. Subsequently, the results of each instance are compared. If the final external state is consistent after multiple executions under the same baseline snapshot and the same input conditions, and repeated executions do not introduce new side effects, the tool is determined to be idempotent. If repeated executions result in new writes, repeated commits, or state drift, the tool is determined to be non-idempotent. When the target tool cannot build a reproducible baseline snapshot in an isolated environment, or cannot stably reproduce the execution behavior under the same input conditions, the tool does not meet the sandbox simulation verification conditions and is conservatively marked as having unknown idempotency.

7. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 6, characterized in that, In the utility evaluation process based on the metacognitive evaluation model, the expected risk of performance is inferred by calculation. Conservative blocking expected loss Arbitration should be conducted. The cost of ineffective computation caused by logical inversion due to incomplete semantics is quantified by the following formula: in, The probability of tool failure is determined by calculating the proportion of historical failures to the total number of historical calls. Risk of semantic conflict; The formula for cascading rollback cost is as follows: Physical rollback time is the actual time required to perform compensating actions such as deleting dirty data and resetting the state. This is the equivalent time for the loss; Semantic conflict risk The calculation process is as follows: First, semantic templates for the corresponding output items are abstracted from the tool documentation and historical correct outputs. Then, the actual output data items of the tool and the semantic templates are converted into semantic vectors. , The cosine similarity between the actual output data item and the semantic template is calculated to dynamically assess the risk of semantic conflict. The formula is shown below: in, express The second norm; express The 2-norm.

8. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 7, characterized in that, Conservative blocking expected loss The global response latency cost caused by waiting for tool retries is quantified, as shown in the following formula: in, The repair time is the weighted sum of the repair time and the trigger probability of each repair measure segment. The topology impact factor is defined as the total number of downstream tool nodes directly or indirectly blocked by a faulty tool node. Total number of nodes in the workflow The ratio reflects the extent to which blocking behavior drags down the overall progress, and the formula is as follows: The utility-perceived decision-making mechanism performs the final policy determination through the following inequality: If the inequality is true, the speculative flow strategy is executed, driving downstream branches that meet the conditions to start first; otherwise, the conservative waiting strategy is executed, forcing the synchronization waiting tool to retry and complete.

9. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 8, characterized in that, After the upstream faulty node completes its self-healing repair, a secondary audit and status calibration are performed on the output used by speculative execution: First, from the tool nodes Extract the data set corresponding to the input parameter data set B that previously flowed into the downstream tool node from the latest output data. Then set B and set These two sets of data are compared in a multi-dimensional semantic way, with the comparison dimensions including field consistency, logical constraint satisfaction, and context dependency continuity. If any of the following conditions are not met: field consistency, logical constraint satisfaction, or context dependency continuity, a rollback mechanism is triggered; otherwise, the previous speculation is considered to be accurate.

10. The self-healing and fault-tolerant method for intelligent agent workflow based on metacognitive feedback regulation according to claim 9, characterized in that, In step S4, if the repair action involves a retry operation, an idempotency determination is performed. If the determination is idempotent, the retry operation is executed. If the operation is determined to be non-idempotent, retrying is prohibited, and the repair strategy is switched according to the multi-factor weighted scoring mechanism. If the idempotency is determined to be unknown, manual judgment is used. If the retry operation is confirmed by the manual judge to be free from side effects, the retry operation is executed. Otherwise, it is considered non-idempotent, the retry operation is prohibited, and the repair strategy is switched according to the multi-factor weighted scoring mechanism.

Images