A local replanning method for agent task execution exception

Abstract

The present application relates to the technical field of artificial intelligence, in particular to a local replanning method for agent task execution exception, comprising: in response to an execution exception when an agent executes a target task, determining an exception type, a task graph of the target task and a target skill node where the exception occurs, determining an affected node set and a connection boundary between the affected node set and other nodes in the task graph, according to the exception type and the connection boundary, obtaining a candidate scheme from a preset capability directory and performing a hard constraint check, determining the candidate scheme that passes the check as an available scheme and compiling a local graph patch, and after confirming that a current task graph version is consistent with a source graph version when the local graph patch is compiled and meets timeliness and validity constraints, hanging the local graph patch to the current task graph. The present application realizes accurate and safe agent task execution exception recovery through local range replacement, state certificate verification, hard constraint screening and atomic hanging.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically to a local replanning method for handling task execution anomalies in intelligent agents. Background Technology

[0002] In recent years, intelligent agent technology has made significant progress and has been widely applied in various task scenarios such as automated information processing, business process execution, content generation, and data analysis. Intelligent agent systems typically break down user-defined tasks into multiple dependent execution steps. Each step calls upon corresponding model services, tool interfaces, knowledge bases, or business systems, completing the overall task through sequential execution, conditional branching, or parallel processing. With the rapid development of large language models and complex task orchestration technologies, the tasks undertaken by intelligent agents are becoming increasingly complex, involving a significant increase in the number of skill nodes and external system dependencies, placing higher demands on the ability to handle exceptions during task execution.

[0003] In related technologies, intelligent agent systems typically handle task execution anomalies by re-executing the entire task chain, pre-setting failure branches, or manual intervention. While re-executing the entire task chain ensures the integrity of the results, it involves repeatedly executing a large number of successful nodes, wasting computational resources and time. Pre-setting failure branches only works in limited scenarios foreseen during the design phase and is insufficient to handle complex failure scenarios. Manual intervention is usually independent of the execution process, and its returned results are difficult to integrate into the task graph in a structured way, resulting in the recovery process requiring continuous human intervention rather than automatic continuation. Therefore, related technologies cannot accurately locate the affected scope when task execution anomalies occur, and lack an anomaly recovery mechanism that can both reuse unaffected execution results and enable task continuation through partial replacement, often leading to high additional overhead in the anomaly recovery process.

[0004] Therefore, there is an urgent need for a local replanning method that can determine the scope of affected nodes, reuse existing execution results, generate local graph patches, and attach them to the current task graph when an anomaly occurs. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a local replanning method for intelligent agent task execution anomalies, in order to solve the technical problem in related technologies that it is impossible to accurately locate the affected range when a task execution anomaly occurs, and to only perform local replacement and reuse the unaffected execution results to enable the task to continue execution.

[0006] In a first aspect, embodiments of the present invention provide a local replanning method for handling task execution anomalies in intelligent agents, the method comprising: In response to an execution exception when the agent is performing a target task, the exception type of the execution exception, the task graph corresponding to the target task, and the target skill node in the task graph where the exception occurred are determined. The task graph includes multiple skill nodes and dependency edges between the skill nodes, and the task graph has a current task graph version. Starting from the target skill node, determine the set of affected nodes in the task graph, and determine the connection boundary between the set of affected nodes and other nodes in the task graph, wherein the other nodes include reusable skill nodes in the task graph that meet preset conditions; A status certificate is generated for each of the reused skill nodes. The status certificate is used to record the timeliness and validity constraints of the execution results of the reused skill nodes. Based on the anomaly type and the connection boundary, candidate solutions are obtained from a preset capability catalog, hard constraint verification is performed on the candidate solutions, the candidate solutions that pass the verification are determined as usable solutions, and a local graph patch is compiled and generated based on the usable solutions. After confirming that the current task graph version is consistent with the source graph version used to compile the local graph patch, and that the state credential satisfies the timeliness and validity constraints, the local graph patch is attached to the current task graph.

[0007] In conjunction with the first aspect, in one implementation, determining the exception type of the execution exception in response to an execution exception when the agent performs a target task includes: Obtain the exception signal corresponding to the execution exception; The abnormal signal is matched with the corresponding abnormal type in the preset abnormal type mapping relationship. The abnormal type includes at least one of the following: missing parameters, restricted permissions, execution timeout, service unavailability, capability mismatch, output contract abnormality, and business rule failure.

[0008] In conjunction with the first aspect, in one implementation, determining the set of affected nodes in the task graph, starting from the target skill node, includes: Mark each output field of the target skill node that has an anomaly as unavailable, and propagate the unavailable status along the dependency edge to the node to be filtered, wherein the node to be filtered is the downstream node in the task graph that is connected to the target skill node; When any input field of a node to be filtered depends on a field that is in the unavailable state, the node to be filtered is included in the set of affected nodes, and the corresponding output field of the node to be filtered is marked as the unavailable state. This process is repeated iteratively until the set of affected nodes is in a stable state.

[0009] In conjunction with the first aspect, in one implementation, determining the connection boundaries between the affected node set and other nodes in the task graph includes: For each affected node in the set of affected nodes, if the input port of the affected node has at least one upstream node that does not belong to the set of affected nodes, then the input port is determined as the input-side connection boundary, and the upstream node is the skill node that the affected node depends on. For each affected node in the set of affected nodes, if the output port of the affected node has at least one downstream node that does not belong to the set of affected nodes, then the output port is determined as the output-side connection boundary, and the downstream node is a skill node that depends on the affected node. The input-side connection boundary and the output-side connection boundary together constitute the connection boundary.

[0010] In conjunction with the first aspect, in one embodiment, the method further includes: If the current task graph version is inconsistent with the source graph version used to compile the local graph patch, or if the state credential fails to meet the timeliness and validity constraints, the affected node set and connection boundaries are re-determined based on the current task graph version, and the local graph patch is recompiled.

[0011] In conjunction with the first aspect, in one implementation, generating a status credential for each of the reused skill nodes includes: For each of the reused skill nodes, the execution result of the reused skill node, as well as the generation timestamp, permission context, idempotency flag, and side effect confirmation status of the execution result are obtained. The idempotency flag is used to characterize whether the same result is produced when the skill call action corresponding to the reused skill node is executed multiple times. The side effect confirmation status is used to characterize whether the impact on the external system during the execution of the skill call action corresponding to the reused skill node has actually occurred. The validity period constraint of the execution result is determined based on the generated timestamp, and the validity period constraint is used to limit the validity period of the execution result; The validity constraints of the execution result are determined based on the permission context, the idempotency identifier, and the side effect confirmation status. The validity constraints are used to limit the conditions under which the execution result is considered valid. The timeliness constraint and the validity constraint are encapsulated with the execution result of the reused skill node to generate a status credential of the execution result.

[0012] In conjunction with the first aspect, in one implementation, the step of obtaining candidate solutions from a preset capability catalog based on the exception type and the connection boundary, performing hard constraint verification on the candidate solutions, and determining the candidate solutions that pass the verification as available solutions includes: The input and output interfaces of the local graph patch are determined based on the connection boundaries; Based on the anomaly type, the candidate solution is obtained by retrieving skill node combinations that match the input interface and the output interface from the capability catalog. For each skill node in the candidate solution, a hard constraint check is performed. The hard constraint check includes at least one of the following: input field type matching check, resource availability check, and permission check. Candidate solutions that pass all hard constraint checks are identified as available solutions.

[0013] In conjunction with the first aspect or its corresponding implementation, in one implementation, the method further includes: If there are multiple available solutions that pass the hard constraint verification, calculate the soft constraint scores corresponding to each of the multiple available solutions. The soft constraint scores include at least one of the following: execution time score, resource consumption score, and historical success rate score. Based on the soft constraint score, the multiple available solutions are ranked, and the highest-ranked available solution is selected for compilation to generate the local graph patch.

[0014] In conjunction with the first aspect, in one implementation, the local graph patch includes at least one alternative skill node, and attaching the local graph patch to the current task graph further includes: Obtain the historical execution success rate for each of the aforementioned alternative skill nodes; Based on the historical execution success rate, multiple execution branches are configured for the local graph patch. Each execution branch corresponds to a combination of alternative skill nodes. Different execution branches have different execution orders and different combinations of alternative skill nodes. In response to a failure of the current execution branch of the local graph patch during execution, determine whether there is an unexecuted backup execution branch in the local graph patch: If there is an unexecuted backup execution branch, then the execution will switch from the current execution branch to the backup execution branch to continue execution. The alternative skill node combination method of the backup execution branch is different from that of the current execution branch. If there is no alternative execution branch that has not yet been executed, the recovery process of the target task is terminated or transferred to manual processing.

[0015] In conjunction with the first aspect or its corresponding implementation, in one implementation, before switching from the current execution branch to the backup execution branch, the method further includes: Obtain the external impact status of the executed portion of the current execution branch, wherein the external impact status is used to characterize whether the changes made to the external system by the executed portion during execution have taken effect; When the external influence status indicates that an external influence has taken effect, a compensation operation is performed before switching to the standby execution branch. The compensation operation is used to undo or correct the external influence generated by the executed part.

[0016] This invention determines the set of affected nodes and connection boundaries, requiring only local replacement within the affected area, thus avoiding the re-execution of the entire task chain and significantly reducing the overhead of anomaly recovery. By constraining candidate solutions together with anomaly types and connection boundaries and filtering them with hard constraints, it ensures that necessary conditions such as permissions and resources are met after patch integration, guaranteeing the security of the recovery process. By verifying version consistency and credential validity before attaching, it avoids state mismatch caused by concurrent modifications, ensuring the rollbackability and data consistency of the recovery operation.

[0017] Secondly, embodiments of the present invention provide a local replanning device for handling task execution anomalies in intelligent agents, the device comprising: An anomaly detection module is used to respond to execution anomalies when an agent performs a target task, and to determine the anomaly type of the execution anomaly, the task graph corresponding to the target task, and the target skill node in the task graph where the anomaly occurred. The task graph includes multiple skill nodes and dependency edges between the skill nodes. The scope of influence determination module is used to determine the set of affected nodes in the task graph, starting from the target skill node, and to determine the connection boundary between the set of affected nodes and other nodes in the task graph, wherein the other nodes include reusable skill nodes in the task graph that meet preset conditions. The status credential generation module is used to generate a status credential for each of the reused skill nodes. The status credential is used to record the timeliness constraints and validity constraints of the execution results of the reused skill nodes. The candidate solution processing module is used to obtain candidate solutions from a preset capability catalog according to the exception type and the connection boundary, perform hard constraint verification on the candidate solutions, determine the candidate solutions that pass the verification as available solutions, and compile and generate local graph patches based on the available solutions. The patch attaching module is used to attach the local graph patch to the current task graph after confirming that the current task graph version is consistent with the source graph version on which the local graph patch was compiled, and that the status credential satisfies the timeliness constraint and validity constraint.

[0018] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform a local replanning method for intelligent agent task execution anomalies as described in the first aspect or any corresponding embodiment.

[0019] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions for causing a computer to execute a local replanning method for handling agent task execution anomalies as described in the first aspect or any corresponding embodiment. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating a local replanning method for handling agent task execution anomalies according to an embodiment of the present invention. Figure 2 This is a structural block diagram of a local replanning device for handling intelligent agent task execution anomalies according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] The existing solutions handle task execution anomalies by re-executing the entire task chain, pre-setting failed branches, or manual intervention. However, they cannot accurately locate the affected scope when an anomaly occurs. They lack an anomaly recovery mechanism that can both reuse unaffected execution results and allow the task to continue execution through partial replacement, which often results in high additional overhead during the anomaly recovery process.

[0024] In view of this, embodiments of the present invention provide a local replanning method for intelligent agent task execution anomalies, to solve the technical problem in related technologies that it is impossible to accurately locate the affected scope when a task execution anomaly occurs, perform only local replacement, and reuse the unaffected execution results to allow the task to continue execution. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] This embodiment provides a local replanning method for handling agent task execution anomalies. Figure 1 This is a flowchart of a local replanning method for handling agent task execution anomalies according to an embodiment of the present invention, as follows: Figure 1 As shown, the process includes the following steps: Step S101: In response to an execution exception when the agent is performing a target task, determine the exception type of the execution exception, the task graph corresponding to the target task, the target skill node in the task graph where the exception occurred, the task graph includes multiple skill nodes and the dependency edges between skill nodes, and the task graph has the current task graph version.

[0026] Execution anomalies refer to unexpected errors that occur when an agent invokes skill nodes to complete a target task. Anomaly types are used to distinguish different causes of failure. The task graph is a directed graph structure composed of multiple skill nodes and their dependencies, used to describe the execution flow of the target task. Skill nodes are the basic execution units in the task graph, each corresponding to a skill invocation action. Dependencies between skill nodes represent the execution order or data transfer relationships. The current task graph version is a version identifier maintained at runtime, used to characterize the current state of the task graph.

[0027] In the specific implementation of this invention, when a skill node fails to be invoked or the execution result is abnormal during the execution of a target task by an intelligent agent, the execution exception is first captured, and the exception is classified to determine its exception type. At the same time, the specific skill node where the exception occurred is located as the target of subsequent recovery operations, and the currently executing task graph and its version information are obtained to provide basic data for subsequent determination of the affected scope and state reuse.

[0028] Taking the report generation task as an example, the task graph for this task includes an intent recognition node, an outline generation node, a retrieval node, a result organization node, and a report generation node. These nodes are connected in a dependency order, and the task graph has a version number, V3. When the retrieval node is reached, the agent initiates an interface call. However, due to a missing interface key, an error code is returned, and the retrieval fails. The agent captures this error, determines the exception type as missing parameters based on the error code, identifies the retrieval node as the target skill node, and obtains the current task graph version, V3.

[0029] By simultaneously determining the exception type, task graph, target skill node, and current task graph version when an exception occurs, a complete input information foundation is provided for subsequent local replanning. This enables the exception recovery process to accurately pinpoint the fault location and cause, avoiding indiscriminate re-execution of the entire task chain and laying a data foundation for achieving precise local recovery.

[0030] In some embodiments of the present invention, step S101, "in response to an execution exception when the agent performs a target task, determining the exception type of the execution exception," specifically includes the following sub-steps: Obtain the exception signal corresponding to the execution exception; The abnormal signal is matched with the corresponding abnormal type in the preset abnormal type mapping relationship. The abnormal type includes at least one of the following: missing parameters, restricted permissions, execution timeout, service unavailability, capability mismatch, output contract abnormality, and business rule failure.

[0031] Among them, exception signals are raw error information carriers returned by the execution environment or skill call interface when an execution exception occurs, including error codes, error description text, HTTP status codes, or exception stack information. The preset exception type mapping relationship is a pre-configured set of matching rules used to map exception signals from different sources and in different formats to a unified exception type classification system. Exception types include missing parameters, restricted permissions, execution timeout, service unavailability, capability mismatch, output contract exception, and business rule failure.

[0032] Taking the report generation task in step S101 as an example, when the agent calls the data retrieval node, the database connection times out, returning an HTTP 504 error code and a timeout message. The agent captures this returned information as an anomaly signal, inputs the anomaly signal into a preset anomaly type mapping relationship for matching, and the matching result is execution timeout, which is then determined as the anomaly type of the data retrieval node.

[0033] By uniformly converting raw anomaly signals from different sources and in different formats into standardized anomaly types, subsequent candidate solution recall and local replanning can be processed based on a unified fault classification, avoiding fragmentation of processing logic caused by differences in anomaly signal formats. Simultaneously, the pre-defined anomaly type mapping relationship limits anomaly types to a finite range of classifications, ensuring the predictability and completeness of the mapping from failure types to recovery actions, and improving the versatility and maintainability of the anomaly handling process.

[0034] Step S102: Starting from the target skill node, determine the set of affected nodes in the task graph, and determine the connection boundary between the set of affected nodes and other nodes in the task graph. Other nodes include reusable skill nodes in the task graph that meet preset conditions.

[0035] The affected node set is the set of skill nodes in the task graph that are directly or indirectly affected by the target skill node's anomaly. The connection boundary is the data interaction interface between the affected node set and other nodes in the task graph, including input-side and output-side connection boundaries. The input-side connection boundary consists of the ports of the affected node whose upstream nodes are not part of the affected node set, used to determine the patch's data entry point. The output-side connection boundary consists of the ports of the affected node whose downstream nodes are not part of the affected node set, used to determine the patch's data exit point. Other nodes are all skill nodes in the task graph that are not part of the affected node set. Reused skill nodes are skill nodes among the other nodes that have been successfully executed and whose execution results meet preset conditions; their execution results can be used as data input for subsequent patch executions.

[0036] In the specific implementation of this invention, the target skill node that has an anomaly is taken as the propagation starting point, and the influence propagation is carried out along the dependency edges in the task graph. All skill nodes in the task graph affected by the target skill node are identified and included in the affected node set. Then, the data connection boundary between this set and other nodes in the task graph is determined, where other nodes include reused skill nodes in the task graph that have been successfully executed and meet the reuse conditions.

[0037] Using the report generation task example, the task graph includes intent recognition node A, outline generation node B, retrieval node C, result organization node D, and report generation node E, with dependencies as follows: E depends on D, D depends on C, C depends on B, and B depends on A. Retrieval node C malfunctions due to a missing interface key; therefore, the target skill node is C. Propagation begins from C and proceeds downstream along the dependency edges. The input of result organization node D depends on the output of C, and the input of report generation node E depends on the output of D. Therefore, D and E are included in the affected node set, which is {C, D, E}. Intent recognition node A and outline generation node B are unaffected and are retained as other nodes. B has already been executed successfully, and its output meets the reuse condition, making it a reused skill node. Next, the connection boundaries are determined. In the affected node set, node D's input port has an upstream node B that is not part of the affected node set; therefore, this input port is determined as the input-side connection boundary. Node E's output port connects to the final task result and is not part of the affected node set; therefore, this output port is determined as the output-side connection boundary. The input-side and output-side connection boundaries together constitute the connection boundaries.

[0038] This step determines the set of affected nodes by propagating along dependency edges from the target skill node, achieving precise localization of the anomaly's impact range and avoiding indiscriminate re-execution of the entire task chain. Simultaneously, by defining connection boundaries, the data interaction interface between subsequent local patches and externally retained nodes is clarified. This allows patches to access the task graph simply by connecting to boundary ports, preserving successfully executed nodes and their execution results while providing precise access points for subsequent patch compilation. This reduces the intrusiveness of patches to the original task graph structure and lowers the complexity and resource consumption of anomaly recovery.

[0039] In some embodiments of the present invention, step S102, "determining the set of affected nodes in the task graph starting from the target skill node," specifically includes the following sub-steps: Mark each output field of the target skill node that has an anomaly as unavailable, and propagate the unavailable status along the dependency edges to the nodes to be filtered. The nodes to be filtered are the downstream nodes in the task graph that are connected to the target skill node. When any input field of a node to be filtered depends on a field that is unavailable, the node to be filtered is added to the set of affected nodes, and the corresponding output field of the node to be filtered is marked as unavailable. This process is repeated until the set of affected nodes is in a stable state.

[0040] In this system, output fields are the smallest data units in the structured data returned after a skill node completes execution, each with a name and value. An unavailable state is a status marker on a field indicating that the data in that field is unreliable or unreusable. Nodes to be filtered are downstream skill nodes currently being checked to determine if they should be included in the affected node set. Downstream nodes obtain the output fields of upstream nodes as their own input fields through dependency edges. Input fields are the smallest data units in the structured data required for skill node execution, with each input field corresponding to one or more output fields from upstream nodes. A stable state occurs when no new skill nodes are added to the affected node set during a complete propagation iteration, indicating that the set has converged.

[0041] In the specific implementation of this invention, the status flag bit corresponding to each output field of the target skill node that has an anomaly is set to an unavailable value to complete the marking of the unavailable state. Then, starting from the target skill node, the task graph is traversed along the direction of the dependency edge, and the downstream nodes connected to the target skill node are visited one by one. The unavailable state is passed from the upstream field to the corresponding input field of the downstream node. When the upstream field on which any input field of a downstream node depends is in an unavailable state, the downstream node is included in the set of affected nodes, and the status flag bit of the corresponding output field of the downstream node is also set to an unavailable value. The above traversal, judgment and marking process is repeated until the set of affected nodes no longer changes.

[0042] Following the report generation task example, if retrieval node C encounters an anomaly, its output fields include retrieval result data and a status flag. The status flag bits corresponding to these two output fields are set to unavailable values. Starting from C, traverse downstream nodes along the dependency edges. First, visit result processing node D. D's input fields include outline data from outline generation node B and retrieval result data from retrieval node C. The upstream field upon which the retrieval result data depends is unavailable; therefore, D is added to the affected node set, and the status flag bit corresponding to D's output field is set to unavailable values. Continue traversing along the dependency edges to report generation node E. E's input field includes processed data from D. The upstream field upon which this field depends is unavailable; therefore, E is added to the affected node set, and the status flag bit corresponding to E's output field is set to unavailable values. At this point, all downstream nodes have been traversed without any new nodes being added, and the affected node set {C, D, E} reaches a stable state. The status flag bit corresponding to the output field of outline generation node B remains available; therefore, B is not included in the affected node set.

[0043] This step achieves precise location of the scope of anomaly impact through field-level pollution marking and iterative traversal propagation along the dependency edge direction. This ensures that only downstream nodes that truly depend on unavailable fields are included in the affected set, while downstream nodes that depend on unpolluted fields are retained and reused. This avoids the problem of excessive re-execution caused by node-level fault propagation in traditional solutions, effectively narrowing the recovery scope and reducing recovery overhead.

[0044] In some embodiments of the present invention, step S102, "determining the connection boundary between the affected node set and other nodes in the task graph," specifically includes the following sub-steps: For each affected node in the set of affected nodes, if the input port of the affected node has at least one upstream node that does not belong to the set of affected nodes, then the input port is determined as the input-side connection boundary, and the upstream node is the skill node that the affected node depends on. For each affected node in the set of affected nodes, if the output port of the affected node has at least one downstream node that does not belong to the set of affected nodes, then the output port is determined as the output-side connection boundary, and the downstream node is a skill node that depends on the affected node. The input-side connection boundary and the output-side connection boundary together constitute the connection boundary.

[0045] In this context, input ports are the interfaces through which skill nodes receive output data from upstream nodes, and output ports are the interfaces through which skill nodes send output data to downstream nodes. An upstream node is a skill node that the current skill node depends on; that is, the current skill node's input data originates from this node. A downstream node is a skill node that depends on the current skill node; that is, the downstream node's input data originates from the current skill node. The input-side connection boundary is the set of all input ports in the affected node set where there are ports whose upstream nodes are not part of the affected node set. These ports are where data enters the affected area when a patch is applied. The output-side connection boundary is the set of all output ports in the affected node set where there are ports whose downstream nodes are not part of the affected node set. These ports are where data leaves the affected area when a patch is applied.

[0046] In the specific implementation of this invention, for each affected node in the affected node set, each input port of that node is checked. If at least one upstream node among all the source nodes of that input port does not belong to the affected node set, then that input port is determined as a member of the input-side connection boundary. After traversal, the complete input-side connection boundary is obtained. For each affected node in the affected node set, each output port of that node is checked. If at least one downstream node among all the downstream nodes pointed to by that output port does not belong to the affected node set, then that output port is determined as a member of the output-side connection boundary. After traversal, the complete output-side connection boundary is obtained. The input-side connection boundary and the output-side connection boundary are used together as the connection boundary between the affected node set and other nodes in the task graph.

[0047] Following the report generation task example, the set of affected nodes is {C, D, E}. For each node in the set, its input port is examined: Node C's input port comes from its upstream node B, and B is not part of the affected node set; therefore, node C's input port is determined as the input-side connection boundary. Node D's input port comes from both node C and node B, where node B is not part of the affected node set; therefore, node D's input port is determined as the input-side connection boundary. Node E's input port comes from node D, and D is part of the affected node set. There are no upstream nodes not belonging to this set; therefore, node E's input port is not determined as the input-side connection boundary. The input-side connection boundaries are now determined.

[0048] For each node in the set, its output port is examined. Node C's output port points to node D, which belongs to the affected node set and is therefore not identified as an output-side connection boundary. Node D's output port points to node E, which also belongs to the affected node set and is therefore not identified as an output-side connection boundary. Node E's output port points to the final task result, which does not belong to the affected node set; therefore, node E's output port is identified as an output-side connection boundary. The input-side connection boundary is formed by the input ports of node C and node D, and the output-side connection boundary is formed by the output port of node E; together, they constitute the connection boundary.

[0049] This step, by examining the input and output ports of each node in the affected node set, can accurately identify all data interaction interfaces between the affected area and the external preserved nodes. This provides clear access and exit points for the local graph patch, ensuring that the patch only needs to make connections at the boundary ports to complete the replacement of the affected area. This preserves the execution status and data of all nodes outside the boundary and avoids the patch from intruding on and modifying irrelevant parts of the task graph.

[0050] Step S103: Generate a status certificate for each reused skill node. The status certificate is used to record the timeliness and validity constraints of the execution results of the reused skill node.

[0051] Among them, the status certificate is a structured data object used to record the validity information of the execution results of the reused skill node, the time limit constraint is used to limit the validity period of the execution result, and the validity constraint is used to limit the conditions under which the execution result is considered valid.

[0052] In some embodiments of the present invention, step S103, "generating a status certificate for each reused skill node," may specifically include the following sub-steps: For each reused skill node, obtain the execution result of the reused skill node, as well as the timestamp of the execution result, permission context, idempotency flag, and side effect confirmation status. The idempotency flag is used to characterize whether the same result is produced when the skill call action corresponding to the reused skill node is executed multiple times. The side effect confirmation status is used to characterize whether the impact on the external system during the execution of the skill call action corresponding to the reused skill node has actually occurred. The validity period of the execution result is determined based on the timestamp generated. The validity period constraint is used to limit the validity period of the execution result. The validity constraints of the execution result are determined based on the permission context, idempotency flag, and side effect confirmation status. The validity constraints are used to limit the conditions under which the execution result is considered valid. The timeliness and validity constraints are encapsulated with the execution results of the reused skill nodes to generate a status certificate of the execution results.

[0053] The permission context is a record of the permission status when the execution result is generated, including tenant information, user authorization scope, and data domain permissions; the idempotency flag is used to characterize whether the skill call action corresponding to the reused skill node produces the same result when it is executed multiple times; the side effect confirmation status is used to characterize whether the impact on the external system during the execution of the skill call action corresponding to the reused skill node has actually occurred.

[0054] In the specific implementation of this invention, for each reused skill node, the execution result of the reused skill node and the corresponding generation timestamp of the execution result are obtained from the task graph execution record. At the same time, the permission context, idempotency flag, and side effect confirmation status recorded when the reused skill node is executed are obtained. The timeliness constraint of the execution result is calculated and determined based on the generation timestamp. Based on the permission context, it is determined whether the execution result is still within the authorized scope. Based on the idempotency flag, it is determined whether the skill call action corresponding to the execution result is repeatable. Based on the side effect confirmation status, it is determined whether the external impact corresponding to the execution result has actually occurred. Based on the above three judgments, the validity constraint of the execution result is comprehensively determined. The timeliness constraint and validity constraint are structurally encapsulated with the execution result to form the status certificate of the execution result.

[0055] Following the example of the report generation task, the outline generation node B has been successfully executed and meets the reuse conditions, thus belonging to the reused skill node category. The execution result of B and its generation timestamp (June 27, 2025, 10:00 AM) are obtained from the task graph's execution record. Simultaneously, the permission context of B's ​​execution is obtained: tenant A, user X, and data domain is financial data; idempotency flag: the skill call action corresponding to B produces the same result when executed multiple times; and side effect confirmation status: B's execution did not affect write operations to external systems. Based on the generation timestamp, the validity period of this execution result is determined to be 24 hours, meaning the result is valid until 10:00 AM on June 28, 2025. The validity constraints are determined based on the permission context, idempotency flag, and side effect confirmation status: the tenant, user, and data domain in the permission context have not changed, the idempotency flag is valid, and the side effect status is not occurred; all three conditions must be met simultaneously for the execution result to be considered valid. The validity constraints and validity constraints are structurally encapsulated with the execution result of B to generate a status credential for the execution result of B.

[0056] This step obtains the execution results and related attribute information of the reused skill nodes and encapsulates them into status credentials, thus solidifying the reuse conditions in the form of structured data. This allows the subsequent patch compilation and attachment stages to independently verify the reuse results, ensuring that only results that are not expired, have not changed permissions, are idempotent, and have definite side effect status are read and used by the patch. This avoids secondary exceptions caused by reusing expired, unauthorized, or uncertain execution results, and improves the reliability of exception recovery.

[0057] Step S104: Based on the exception type and connection boundary, obtain candidate solutions from the preset capability catalog, perform hard constraint verification on the candidate solutions, determine the candidate solutions that pass the verification as usable solutions, and compile and generate local graph patches based on the usable solutions.

[0058] The capability catalog is a pre-built skill node registry that stores capability information for various skill nodes that can be invoked. Each capability entry includes at least the skill node's input / output mode, permission requirements, resource requirements, and runtime constraints. Candidate solutions are combinations of skill nodes recalled from the capability catalog that are theoretically suitable for replacing the affected node set. Hard constraint verification is a mandatory condition check performed on candidate solutions; if any hard constraint is not met, the candidate solution is eliminated. The hard constraint verification result is not offset by other factors; available solutions are candidate solutions that pass all hard constraint verifications. Local graph patches are local execution graph structures compiled based on available solutions and used to replace the affected node set. They include the replacement skill nodes, the connections between nodes, and the data mapping between the patch and external nodes.

[0059] In some embodiments of the present invention, step S104, "obtaining candidate solutions from a preset capability catalog based on the exception type and connection boundary, performing hard constraint verification on the candidate solutions, and determining the candidate solutions that pass the verification as available solutions," may specifically include the following sub-steps: The input and output interfaces of the local graph patch are determined based on the connection boundaries; Based on the anomaly type, the candidate solution is obtained by retrieving skill node combinations that match the input interface and the output interface from the capability catalog. For each skill node in the candidate solution, a hard constraint check is performed. The hard constraint check includes at least one of the following: input field type matching check, resource availability check, and permission check. Candidate solutions that pass all hard constraint checks are identified as available solutions.

[0060] The input interface is the patch data entry point defined by the input-side connection boundary within the connection boundary, specifying which fields the patch receives as input from external multiplexing nodes. The output interface is the patch data exit point defined by the output-side connection boundary within the connection boundary, specifying which fields the patch needs to provide as output to external downstream nodes. A skill node combination is an execution sequence composed of one or more skill nodes from the capability catalog arranged in a specific order. The input of this combination matches the input interface, and the output matches the output interface, enabling it to completely replace the functionality of the affected node set. Input field type matching verification checks whether the input field types of the candidate solution are consistent with the field types required by the input interface; resource availability verification checks whether the computing resources, storage resources, or external service resources required for the execution of the candidate solution are currently available; and permission verification checks whether the executing entity of the candidate solution has the tenant permissions, user permissions, and data domain permissions required to call each skill node.

[0061] In the specific implementation of this invention, the input interface of the patch is determined according to the input-side connection boundary in the connection boundary, and the output interface of the patch is determined according to the output-side connection boundary in the connection boundary. Skill node combinations that simultaneously satisfy input interface matching and output interface matching are retrieved from the capability catalog according to the exception type. The retrieved skill node combinations are used as candidate solutions. Hard constraint verification is performed on each skill node in the candidate solution, including at least one of input field type matching verification, resource availability verification, and permission verification. Only candidate solutions that pass all hard constraint verifications are determined as available solutions.

[0062] Following the report generation task example, the affected node set is {C, D, E}. The input-side connection boundary is determined to be the input ports of node C and node D, and the output-side connection boundary is the output port of node E. Based on the input-side connection boundary, the patch's input interface is determined to receive outline data from outline generation node B. Based on the output-side connection boundary, the patch's output interface is determined to output a complete report to the final task result. Based on the exception type being parameter missing, skill node combinations that simultaneously satisfy the above input and output interfaces are retrieved from the capability directory, resulting in three candidate solutions: Candidate Solution 1: Parameter supplementation node plus original retrieval node plus original result processing node plus original report generation node; Candidate Solution 2: Authorized retrieval node plus result processing node plus report generation node; Candidate Solution 3: Internal knowledge retrieval node plus result processing node plus report generation node. Precondition hard constraint checks are performed on each skill node in Candidate Solution 1. The input field type of the parameter supplementation node matches the input interface and the resources are available, but the permission check of the original retrieval node fails. Candidate Solution 1 fails all hard constraint checks and is eliminated. Hard constraint validation was performed on candidate scheme two. The permission validation of the authorized retrieval node passed and the input and output matched. The resource availability validation and permission validation of subsequent nodes also passed. Candidate scheme two was determined to be a usable scheme. Hard constraint validation was performed on candidate scheme three. The permission validation of the internal knowledge retrieval node passed and the input and output matched. The resource availability validation and permission validation of subsequent nodes also passed. Candidate scheme three was also determined to be a usable scheme.

[0063] This step determines the input / output interfaces by connecting boundaries, achieving precise matching between the input / output conditions of candidate solutions and the patch access location, ensuring seamless integration of candidate solutions into the task graph. Filtering the capability catalog by exception type narrows the search scope of candidate solutions, improving recall efficiency. Hard constraint verification of the preconditions for each skill node in the candidate solutions ensures that each execution step in the patch meets the execution conditions at the skill level, preventing the entire patch from failing due to a single skill node's unmet hard constraint, thus improving the quality and success rate of patch generation.

[0064] In some embodiments of the present invention, the following sub-steps may be included after the above sub-steps: If there are multiple available solutions that pass the hard constraint verification, calculate the soft constraint scores corresponding to each of the multiple available solutions. The soft constraint scores include at least one of the following: execution time score, resource consumption score, and historical success rate score. Based on the soft constraint score, multiple available solutions are ranked, and the highest-ranked available solution is selected for compilation to generate the local graph patch.

[0065] Among them, the soft constraint score is a quantitative evaluation score of available solutions that have passed the hard constraint verification, used to distinguish the merits of multiple available solutions on non-mandatory indicators. The execution time score is an evaluation score of the time required for a candidate solution to complete the execution of all skill nodes. The resource consumption score is an evaluation score of the computing resources, storage resources, or external service calls used by the candidate solution during execution. The historical success rate score is an evaluation score generated based on the success rate of skill nodes in the candidate solution in past executions.

[0066] In the specific implementation of this invention, when there are multiple available solutions that pass the hard constraint verification, a soft constraint score is calculated for each available solution. This soft constraint score is quantified based on at least one of execution time, resource consumption, and historical success rate. The multiple available solutions are then ranked according to the calculated soft constraint scores, and the highest-ranked available solution is selected as the solution used to compile and generate the local graph patch. In one embodiment of this invention, the scores corresponding to these three indicators can be directly summed; in another embodiment, the scores corresponding to these three indicators can be weighted and summed. The weight of each indicator can be adjusted according to actual needs. In scenarios where latency is more critical, the weight of the execution time score is increased; in scenarios where success rate is more critical, the weight of the historical success rate score is increased.

[0067] Using the report generation task example, two solutions were determined to be usable after passing the hard constraint verification: Solution 2 consists of an authorized retrieval node, a result processing node, and a report generation node; Solution 3 consists of an internal knowledge retrieval node, a result processing node, and a report generation node. The soft constraint scores for each usable solution were calculated. For Solution 2, the estimated execution time is 120 seconds, resource consumption is medium, and the historical success rate is 95%. The execution time score is 8 points, the resource consumption score is 9 points, and the historical success rate score is 9.5 points. These three scores are weighted and summed with weights of 0.3, 0.3, and 0.4, respectively, resulting in a soft constraint score of 8.9 points. For Solution 3, the estimated execution time is 180 seconds, resource consumption is high, and the historical success rate is 88%. The execution time score is 6 points, the resource consumption score is 7 points, and the historical success rate score is 8.8 points. These three scores are weighted and summed with weights of 0.3, 0.3, and 0.4, resulting in a soft constraint score of 7.4 points. Based on the soft constraint score, the two available solutions were ranked. Solution 2 ranked higher than Solution 3, and Solution 2 was selected for compilation to generate the local graph patch.

[0068] In one embodiment of the present invention, the local graph patch is generated using Agint's graph compilation method. Agint is an intelligent agent graph compiler capable of combining skill nodes in available solutions into a typed code DAG (Directed Acyclic Graph). Specifically, each alternative skill node in the available solutions is treated as a node in the DAG, and directed edges are constructed between nodes according to the dependency order between nodes in the solution, forming the execution flow within the patch. Agint achieves incremental compilation through explicit type flooring: nodes are sequentially parsed from natural language descriptions into nodes with type signatures, reduction nodes with preconditions and postconditions, and finally into executable code. During compilation, each alternative node inherits the output type of its upstream node as an input constraint and passes its own output type to downstream nodes, ensuring input-output matching between nodes within the patch through the type system. Simultaneously, Agint supports hierarchical compilation, and patch modifications are localized to the newly added node and its adjacent range, without triggering a full graph recompilation.

[0069] In another embodiment of the invention, a graph difference method is used to generate local patches. Specifically, the graph difference method extracts a graph difference operation set by comparing the original subgraph structure corresponding to the affected node set with the target subgraph structure corresponding to the available solutions. This graph difference operation set is then converted into micro-operation instructions and mapped back to the task graph level to generate local graph patches. After compilation, the patch becomes an independent, complete, and verifiable execution unit, awaiting atomic attachment to the current task graph.

[0070] This step introduces a soft constraint scoring mechanism among available solutions after hard constraint verification. While ensuring safety and legitimacy, it also considers optimization goals such as execution efficiency, resource utilization, and reliability, resulting in a final selected solution with superior overall performance while meeting all mandatory conditions. Furthermore, the soft constraint scoring only ranks candidates that have passed hard constraint verification, without interfering with the pass / fail status of hard constraint checks, ensuring that safety always takes precedence over performance optimization.

[0071] Step S105: After confirming that the current task graph version is consistent with the source graph version used when compiling the local graph patch, and that the status credential meets the timeliness and validity constraints, the local graph patch is attached to the current task graph.

[0072] The current task graph version is the version identifier of the task graph at the current runtime, used to represent the current state version of the task graph; the source graph version is the task graph version identifier used when compiling the local graph patch, used to represent the task graph state targeted by the patch. Version consistency verification compares whether the current task graph version is consistent with the source graph version, and state credential validity verification checks whether the timeliness constraints and validity constraints recorded in the state credential are still satisfied. Atomic attachment refers to attaching the local graph patch as an indivisible whole to the current task graph; this operation either succeeds entirely or fails entirely, with no intermediate states.

[0073] In the specific implementation of this invention, before performing the atomic attachment operation, the current task graph version is obtained and compared with the source graph version recorded when compiling the local graph patch to confirm that the two are consistent. At the same time, the status credentials of each reused skill node are verified to confirm that the timeliness constraint and validity constraint still meet the requirements. When both of the above confirmations are passed, the local graph patch is atomically attached to the current task graph, and the scheduling cursor is switched to the entry node of the patch. The scheduling cursor is a control pointer in the task graph execution engine used to indicate the current execution position.

[0074] Continuing with the previous report generation task example, the source graph version recorded during the compilation of the local graph patch is V3. The validity constraint recorded in the status certificate is valid until 10:00 AM on June 28, 2025, and the validity constraint is that the permission context remains unchanged, the idempotency flag is valid, and the side effect status is "not occurred." Upon reaching the attachment stage, the current task graph version is still V3, consistent with the source graph version V3. The validity constraint of the status certificate is checked, and the current time has not exceeded the validity period. The validity constraint is also checked, and the permission context has not changed, the idempotency flag is valid, and the side effect status is still "not occurred," meaning the status certificate still satisfies all constraints. After both confirmations pass, an atomic attachment operation is performed, connecting all the alternative skill nodes and their dependent edges in the patch to the current task graph at once. The original nodes C, D, and E in the affected node set are marked as unexecutable historical versions. The scheduling cursor is switched to the patch entry node, i.e., the authorized retrieval node, allowing the task to continue execution from the patch entry point.

[0075] By performing a consistency check between the current task graph version and the source graph version before atomic attachment, it is ensured that the task graph state upon which the patch is based is the same as the current task graph state. This avoids state mismatches or duplicate side effects caused by changes in the task graph due to other concurrent operations during patch compilation. Secondary checks on the timeliness and validity constraints of state credentials ensure that the reused execution results remain valid at the time of attachment, preventing secondary anomalies caused by reusing expired or invalid results. The atomic attachment operation integrates the patch into the task graph as a whole, guaranteeing the rollback capability and data consistency of the attachment operation, ensuring that the task graph remains in a complete and executable state after patch integration.

[0076] In some embodiments of the present invention, the local graph patch includes at least one alternative skill node, and step S105, after "attaching the local graph patch to the current task graph", may further include the following steps: Obtain the historical execution success rate for each alternative skill node; Based on historical execution success rates, multiple execution branches are configured for local graph patches. Each execution branch corresponds to an alternative skill node combination. Different execution branches have different execution orders and different alternative skill node combination methods. If the current execution branch of a local graph patch fails again during execution, determine if there is an unexecuted backup execution branch in the local graph patch: If there is an unexecuted alternative execution branch, the execution will switch from the current execution branch to the alternative execution branch to continue execution. The alternative execution branch has a different combination of alternative skill nodes than the current execution branch. If there is no alternative execution branch that has not yet been executed, the recovery process of the target task is terminated or transferred to manual processing.

[0077] An execution branch is an executable path within a local graph patch. Each execution branch corresponds to a combination of alternative skill nodes, containing at least one alternative skill node and the execution order relationship between the nodes. The historical execution success rate is based on the ratio of the number of times an alternative skill node has been successfully executed in the historical execution record to the total number of executions. A backup execution branch is an alternative execution branch that can be switched to when the current execution branch fails.

[0078] In the specific implementation of this invention, after the local graph patch is attached to the current task graph, the historical execution success rate of each alternative skill node in the patch is obtained. Based on the historical execution success rate, multiple backup execution branches are configured as the default execution branch in the patch. Each backup execution branch corresponds to a usable scheme that passed the hard constraint verification during the patch compilation stage but was not selected as the default execution branch. This usable scheme has an execution order and skill node combination method different from the default execution branch. When the default execution branch of the local graph patch fails again during execution, it is determined whether there is a backup execution branch in the patch that has not yet been executed. If there is, the execution is switched from the default execution branch to the backup execution branch to continue execution. If there is no backup execution branch, the recovery process of the target task is terminated or manual processing is initiated.

[0079] Following the report generation task example, the patch has been attached and the system has switched to the patch entry point. During the patch compilation phase, three available solutions passed the hard constraint verification: Solution 1, with the highest soft constraint score, was selected as the default execution branch. Its specific node sequence is: authorized retrieval node, result processing node, and report generation node. Solution 2, with the second highest soft constraint score, has the specific node sequence: backup retrieval node, result processing node, and backup report generation node. Solution 3, with the third highest soft constraint score, has the specific node sequence: internal knowledge retrieval node, result processing node, and report generation node. After obtaining the historical execution success rate of each alternative skill node, Solutions 2 and 3 were configured as backup execution branches in the patch. During the execution of the current default execution branch, the authorized retrieval node failed again due to network timeout. At this point, it was determined whether there were any unexecuted backup execution branches in the patch. Since Solutions 2 and 3 had not yet been executed, the system switched from Solution 1 to Solution 2 to continue execution.

[0080] This step preserves available solutions that passed hard constraint checks during the patch compilation phase but were not selected as the default execution branch as backup execution branches. This eliminates the need for patch execution failures to degenerate into re-executing the entire task chain or retrying in an unbounded loop, nor does it require re-performing influence domain calculations and patch compilation. Execution can continue simply by switching to the pre-compiled backup execution branch within the patch itself, reducing recovery latency and computational overhead. Prioritizing backup branch configuration based on historical execution success rates ensures that solutions with higher success rates are selected first, increasing the probability of successful patch execution. When all backup branches fail, the recovery process is terminated or transferred to manual handling, ensuring the termination and controllability of the recovery process.

[0081] In some embodiments of the present invention, before the aforementioned step "switching from the current execution branch to the standby execution branch to continue execution", the following steps may also be included: Get the external impact status of the executed part of the current execution branch. The external impact status is used to characterize whether the changes made to the external system by the executed part during the execution process have taken effect. When an external impact status indicates that an external impact has taken effect, a compensation operation is performed before switching to the standby execution branch. The compensation operation is used to undo or correct the external impact generated by the executed part.

[0082] Among them, the external impact status refers to the status information used to characterize whether the changes made to the external system by the executed part of the current execution branch have taken effect during the execution process; the compensation operation refers to the reverse operation of undoing or correcting the effective impact of the executed part on the external system.

[0083] In the specific implementation of this invention, before switching from the current execution branch to the standby execution branch, the external impact status of the executed part of the current execution branch is obtained. When the external impact status indicates that the changes made by the executed part to the external system have taken effect, a compensation operation is performed before switching to the standby execution branch to revoke or correct the effective impact of the executed part on the external system.

[0084] Continuing with the report generation task example, the default execution branch for the patch is Scheme 1, which includes the authorized retrieval node, result processing node, and report generation node. The authorized retrieval node in this branch has executed successfully, completing the data read operation from the external database. This operation has no write impact, and the external impact status indicates that no effective external impact has occurred. Failure occurs when continuing to execute the result processing node, requiring a switch to the backup execution branch, Scheme 2. Before switching, the external impact status of the executed portions of Scheme 1 is obtained, i.e., the external impact status of the executed portions of the authorized retrieval node and the result processing node. The status indicates that no effective external impact has occurred, so no compensation operation is needed; the process can directly switch to Scheme 2 to continue execution. If the current execution branch is Scheme 2 and the backup retrieval node within it has successfully executed and completed the write operation to the external database, and a subsequent node fails and needs to switch to Scheme 3, then before switching, the external impact status is obtained. This status indicates that the write operation has taken effect. Since this write operation will affect the data consistency of subsequent branches, before switching to Scheme 3, compensation operations are performed, such as rolling back the write or marking the write as invalid, and canceling the effective impact of the backup retrieval node on the external system. This ensures that the external system status is restored to a consistent state before switching, and then switching to Scheme 3 to continue execution.

[0085] This step avoids conflicts between data generated by the currently executed branch and the expected data of the standby execution branch by acquiring the external impact status before switching to the standby execution branch and performing compensation operations when external impacts have already occurred and taken effect. This ensures the integrity and consistency of data in external systems such as databases. At the same time, it avoids the accumulation of dirty data caused by repeated writing of data to the same location by the current branch and subsequent branches, preventing irreversible consequences of data pollution. By restoring the external system to a consistent state through compensation operations before switching branches, the traceability and rollback of the external state before and after the switch are ensured, reducing the risk of secondary anomalies caused by residual side effects and improving the safety of the recovery process.

[0086] In some embodiments of the present invention, the method further includes: If the current task graph version is inconsistent with the source graph version used when compiling the local graph patch, or if the state credentials cannot meet the timeliness and validity constraints, the set of affected nodes and connection boundaries are redefined based on the current task graph version, and the local graph patch is recompiled.

[0087] In the specific implementation of this invention, when performing an atomic attachment operation, if the current task graph version is inconsistent with the source graph version used to compile the local graph patch, or if the state credentials of any reused skill node cannot meet its timeliness and validity constraints, then attaching the current local graph patch is prohibited. The process of determining the affected node set and connection boundaries is re-executed based on the current task graph version, and a new local graph patch is recompiled based on the newly determined connection boundaries.

[0088] Following the aforementioned report generation task example, the source graph version recorded during the compilation of the local graph patch is V3, and the validity constraint recorded in the state certificate is valid until 10:00 AM on June 28, 2025. Upon reaching the attachment stage, the current task graph version is found to be V4, which is inconsistent with the source graph version V3, indicating that the task graph has been modified by other operations during patch compilation. In one embodiment of the invention, the current patch is not attached at this point. Instead, steps S102 to S104 are re-executed based on the current task graph version V4. That is, the affected node set and connection boundaries are redefined starting from the search node C, the state certificate is regenerated, candidate solutions are re-obtained and hard constraint checks are performed, and a new local graph patch is recompiled.

[0089] By verifying the consistency between the current task graph version and the source graph version before attaching, patches compiled based on older task graph versions are avoided from being attached to modified newer task graphs, preventing state mismatches and execution anomalies. When versions are inconsistent or state credentials expire, instead of directly abandoning recovery or rerunning the entire task chain, local calculations are recalculated based on the latest task graph, maintaining the continuity and adaptability of the recovery process and improving the success rate and robustness of anomaly recovery.

[0090] The technical solution of this invention has at least the following beneficial effects: By determining the set of affected nodes and connection boundaries starting from the target skill node, only local replacement is needed within the affected range, avoiding the re-execution of the entire task chain and significantly reducing the overhead of anomaly recovery; by generating state credentials for reused nodes, it is ensured that the execution results of reuse remain valid in terms of version, permissions, validity period, idempotency, and side effects, avoiding secondary anomalies caused by reuse failure; by constraining candidate solutions together with anomaly types and connection boundaries and filtering with hard constraints, it is ensured that necessary conditions such as permissions and resources are met after patch access, guaranteeing the security of the recovery process; by verifying version consistency and credential validity before atomic attachment, it avoids state mismatch caused by concurrent modifications, ensuring the rollbackability and data consistency of the recovery operation.

[0091] This embodiment also provides a local replanning device for handling agent task execution anomalies. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0092] This embodiment provides a local replanning device for handling task execution anomalies in intelligent agents, such as... Figure 2 As shown, it includes: An anomaly perception module 201 is used to respond to an execution anomaly when the agent is performing a target task, and to determine the anomaly type of the execution anomaly, the task graph corresponding to the target task, and the target skill node in the task graph where the anomaly occurred. The task graph includes multiple skill nodes and dependency edges between the skill nodes. The scope of influence determination module 202 is used to determine the set of affected nodes in the task graph starting from the target skill node, and to determine the connection boundary between the set of affected nodes and other nodes in the task graph, wherein the other nodes include reusable skill nodes in the task graph that meet preset conditions; The status credential generation module 203 is used to generate a status credential for each of the reused skill nodes. The status credential is used to record the timeliness constraints and validity constraints of the execution results of the reused skill nodes. The candidate solution processing module 204 is used to obtain candidate solutions from a preset capability catalog according to the exception type and the connection boundary, perform hard constraint verification on the candidate solutions, determine the candidate solutions that pass the verification as usable solutions, and compile and generate local graph patches based on the usable solutions. The patch attaching module 205 is used to attach the local graph patch to the current task graph after confirming that the current task graph version is consistent with the source graph version on which the local graph patch was compiled, and that the status credential satisfies the timeliness constraint and validity constraint.

[0093] In this embodiment, a local replanning device for intelligent agent task execution anomalies is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0094] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0095] This invention also provides a computer device having the above-described features. Figure 3The diagram illustrates a local replanning device for handling abnormalities in agent task execution.

[0096] The following is a detailed reference. Figure 3 The diagram illustrates a structural schematic suitable for implementing a computer device according to embodiments of the present invention. The computer device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes based on a program stored in a read-only memory (i.e., ROM 302) or a program loaded from memory 308 into random access memory (i.e., RAM 303). The RAM 303 also stores various programs and data required for the operation of the computer device. The processor 301, ROM 302, and RAM 303 are interconnected via a bus 304. Input / output (i.e., I / O interface 305) is also connected to the bus 304.

[0097] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows the computer device to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 Computer equipment with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0098] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 309, or installed from a memory 308, or installed from a ROM 302. When the computer program is executed by the processor 301, it performs the functions defined in a local replanning method for intelligent agent task execution anomalies according to embodiments of the present invention.

[0099] Figure 3 The computer device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0100] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, it implements a local replanning method for intelligent agent task execution anomalies as shown in the above embodiments.

[0101] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0102] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A local replanning method for handling agent task execution anomalies, characterized in that, The method includes: In response to an execution exception when the agent is performing a target task, the exception type of the execution exception, the task graph corresponding to the target task, and the target skill node in the task graph where the exception occurred are determined. The task graph includes multiple skill nodes and dependency edges between the skill nodes, and the task graph has a current task graph version. Starting from the target skill node, determine the set of affected nodes in the task graph, and determine the connection boundary between the set of affected nodes and other nodes in the task graph, wherein the other nodes include reusable skill nodes in the task graph that meet preset conditions; A status certificate is generated for each of the reused skill nodes. The status certificate is used to record the timeliness and validity constraints of the execution results of the reused skill nodes. Based on the anomaly type and the connection boundary, candidate solutions are obtained from a preset capability catalog, hard constraint verification is performed on the candidate solutions, the candidate solutions that pass the verification are determined as usable solutions, and a local graph patch is compiled and generated based on the usable solutions. After confirming that the current task graph version is consistent with the source graph version used to compile the local graph patch, and that the state credential satisfies the timeliness and validity constraints, the local graph patch is attached to the current task graph.

2. The method according to claim 1, characterized in that, The response to an execution exception when the agent performs a target task, determining the exception type of the execution exception, includes: Obtain the exception signal corresponding to the execution exception; The abnormal signal is matched with the corresponding abnormal type in the preset abnormal type mapping relationship. The abnormal type includes at least one of the following: missing parameters, restricted permissions, execution timeout, service unavailability, capability mismatch, output contract abnormality, and business rule failure.

3. The method according to claim 1, characterized in that, The step of determining the set of affected nodes in the task graph, starting from the target skill node, includes: Mark each output field of the target skill node that has an anomaly as unavailable, and propagate the unavailable status along the dependency edge to the node to be filtered, wherein the node to be filtered is the downstream node in the task graph that is connected to the target skill node; When any input field of a node to be filtered depends on a field that is in the unavailable state, the node to be filtered is included in the set of affected nodes, and the corresponding output field of the node to be filtered is marked as the unavailable state. This process is repeated iteratively until the set of affected nodes is in a stable state.

4. The method according to claim 1, characterized in that, Determining the connection boundaries between the affected node set and other nodes in the task graph includes: For each affected node in the set of affected nodes, if the input port of the affected node has at least one upstream node that does not belong to the set of affected nodes, then the input port is determined as the input-side connection boundary, and the upstream node is the skill node that the affected node depends on. For each affected node in the set of affected nodes, if the output port of the affected node has at least one downstream node that does not belong to the set of affected nodes, then the output port is determined as the output-side connection boundary, and the downstream node is a skill node that depends on the affected node. The input-side connection boundary and the output-side connection boundary together constitute the connection boundary.

5. The method according to claim 1, characterized in that, The method further includes: If the current task graph version is inconsistent with the source graph version used to compile the local graph patch, or if the state credential fails to meet the timeliness and validity constraints, the affected node set and connection boundaries are re-determined based on the current task graph version, and the local graph patch is recompiled.

6. The method according to claim 1, characterized in that, The step of generating a status credential for each of the reused skill nodes includes: For each of the reused skill nodes, the execution result of the reused skill node, as well as the generation timestamp, permission context, idempotency flag, and side effect confirmation status of the execution result are obtained. The idempotency flag is used to characterize whether the same result is produced when the skill call action corresponding to the reused skill node is executed multiple times. The side effect confirmation status is used to characterize whether the impact on the external system during the execution of the skill call action corresponding to the reused skill node has actually occurred. The validity period constraint of the execution result is determined based on the generated timestamp, and the validity period constraint is used to limit the validity period of the execution result; The validity constraints of the execution result are determined based on the permission context, the idempotency identifier, and the side effect confirmation status. The validity constraints are used to limit the conditions under which the execution result is considered valid. The timeliness constraint and the validity constraint are encapsulated with the execution result of the reused skill node to generate a status credential of the execution result.

7. The method according to claim 1, characterized in that, The step of obtaining candidate solutions from a preset capability catalog based on the anomaly type and the connection boundary, performing hard constraint verification on the candidate solutions, and determining the candidate solutions that pass the verification as usable solutions includes: The input and output interfaces of the local graph patch are determined based on the connection boundaries; Based on the anomaly type, the candidate solution is obtained by retrieving skill node combinations that match the input interface and the output interface from the capability catalog. For each skill node in the candidate solution, a hard constraint check is performed. The hard constraint check includes at least one of the following: input field type matching check, resource availability check, and permission check. Candidate solutions that pass all hard constraint checks are identified as available solutions.

8. The method according to claim 7, characterized in that, The method further includes: If there are multiple available solutions that pass the hard constraint verification, calculate the soft constraint scores corresponding to each of the multiple available solutions. The soft constraint scores include at least one of the following: execution time score, resource consumption score, and historical success rate score. Based on the soft constraint score, the multiple available solutions are ranked, and the highest-ranked available solution is selected for compilation to generate the local graph patch.

9. The method according to claim 1, characterized in that, The local graph patch includes at least one alternative skill node, and attaching the local graph patch to the current task graph also includes: Obtain the historical execution success rate for each of the aforementioned alternative skill nodes; Based on the historical execution success rate, multiple execution branches are configured for the local graph patch. Each execution branch corresponds to a combination of alternative skill nodes. Different execution branches have different execution orders and different combinations of alternative skill nodes. In response to a failure of the current execution branch of the local graph patch during execution, determine whether there is an unexecuted backup execution branch in the local graph patch: If there is an unexecuted backup execution branch, then the execution will switch from the current execution branch to the backup execution branch to continue execution. The alternative skill node combination method of the backup execution branch is different from that of the current execution branch. If there is no alternative execution branch that has not yet been executed, the recovery process of the target task is terminated or transferred to manual processing.

10. The method according to claim 9, characterized in that, Before switching from the current execution branch to the backup execution branch, the process also includes: Obtain the external impact status of the executed portion of the current execution branch, wherein the external impact status is used to characterize whether the changes made to the external system by the executed portion during execution have taken effect; When the external influence status indicates that an external influence has taken effect, a compensation operation is performed before switching to the standby execution branch. The compensation operation is used to undo or correct the external influence generated by the executed part.

Images