A multi-agent dynamic task graph evolution and state recovery method and system for long task execution

Abstract

The application provides a multi-agent dynamic task graph evolution and state recovery method and system for long task execution. After receiving a long task request, a long task execution instance is created, an initial task graph is generated, and a runtime state object is initialized; executable task nodes are determined according to task node dependency relationships, and agents are dynamically allocated based on task requirements, agent capabilities, tool states, current loads, and historical execution effects; task node execution results are collected and runtime states and shared memories are updated, task graph evolution is triggered according to new targets, node failures, result conflicts, user feedback, or resource over-limiting, a new task graph version and its difference record object are generated, and the corresponding runtime state snapshot is saved; when task execution fails, is interrupted, has a dependency exception, or a state recovery request is received, the task graph structure and the runtime state are recovered according to the task graph version difference record object and the runtime state snapshot, the set of executable task nodes is re-determined, and execution is continued.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent technology, specifically to a method and system for multi-agent dynamic task graph evolution and state recovery for long-term task execution. It can be applied to enterprise-level AI intelligent agent platforms, long-term task automatic execution systems, AI R&D collaboration platforms, automated software development platforms, intelligent operation and maintenance systems, knowledge base question and answer systems, digital employee systems, and multi-agent collaborative scenarios that require long-term state maintenance and anomaly recovery. Background Technology

[0002] An agent is a proxies capable of perceiving the environment and taking actions to achieve specific goals. It can be implemented through software, hardware, or a combination of both, and possesses a degree of autonomy, adaptability, and interactivity. Currently, multi-agent collaborative systems typically employ fixed workflows, static task chains, or simple message queues to execute tasks. A typical process is as follows: user inputs task → system generates a one-time task plan → task is assigned to fixed agents → agents execute sequentially → results are aggregated.

[0003] In existing technologies, common multi-agent cooperative methods include the following categories:

[0004] (1) Collaboration based on fixed workflow

[0005] This approach typically predefines multiple task nodes, such as "requirements analysis node," "document retrieval node," "code generation node," "testing node," and "summary node." During system runtime, the corresponding agents or tools are invoked in a fixed order. This type of solution is characterized by stable processes and simple implementation, but the task structure usually cannot be dynamically adjusted based on execution results during operation.

[0006] (2) Collaboration based on static role division

[0007] This approach predefines multiple agent roles, such as planning agent, research agent, programming agent, testing agent, and summarizing agent. Each agent has a fixed responsibility and collaborates according to a fixed calling relationship during task execution. This type of scheme can achieve a certain degree of role division, but the collaborative relationships between agents are usually preset and will not be dynamically adjusted based on task status, failure reasons, context changes, or agent performance.

[0008] (3) Message queue-based collaboration method

[0009] This approach achieves information exchange between agents through message queues or event notification mechanisms. For example, after one agent completes a task, it writes the result to a queue, and another agent reads the queue contents to continue processing. This type of solution solves the basic communication problem, but it typically only focuses on message passing and neglects task graph structure, state evolution, context compression, failure rollback, and cooperative strategy optimization.

[0010] (4) Collaborative approach based on single task planning

[0011] This approach involves the planning agent generating a complete task list at the start of the task and then executing the task according to the list. This type of solution is suitable for short tasks, but for long tasks, complex tasks, multi-stage tasks, or tasks that change continuously during execution, it is prone to problems such as task planning failure, context bloat, error accumulation, and loss of intermediate states.

[0012] The main defects of existing technology

[0013] (1) The task structure is fixed and cannot evolve dynamically according to the execution process.

[0014] In existing technologies, task flows are typically determined before execution. Once a task begins, the system usually proceeds only according to the predetermined flow. When the execution results reveal new subtasks, the current task complexity exceeds expectations, a task node fails, the output of a task node is inconsistent with expectations, the user adds new requirements midway, external tool calls fail, a certain agent's capabilities are insufficient, or task dependencies change, existing systems struggle to adjust the task structure in a timely manner. Therefore, existing systems are prone to problems such as task execution stagnation, continued error propagation, and the inability of tasks to self-correct.

[0015] (2) Lack of task graph version management mechanism

[0016] In existing technologies, tasks typically exist as linear lists or fixed process nodes, lacking a task graph version management mechanism. When tasks change during execution, the system cannot clearly record: when the task graph changed, which state triggered the addition of a new task node, why a task node was replaced, why a dependency was adjusted, and which task graph version the current execution result corresponds to. This leads to untraceable task processes, making auditing, review, rollback, and continuous optimization difficult.

[0017] (3) Lack of a unified runtime state management mechanism

[0018] Existing multi-agent systems typically only record simple logs, lacking a unified runtime state object. This results in the system's inability to fully manage the following states: current task graph state, task node state, agent running state, tool invocation state, context cache state, long-term memory state, error state, rollback point state, token consumption state, and user feedback state. Due to this incomplete runtime state, the system is prone to problems such as context loss, duplicate execution, unrecoverable errors, and inconsistencies in information between agents during long-running tasks.

[0019] (4) Multi-agent scheduling lacks state feedback

[0020] Existing systems typically assign agents to fixed roles; for example, research tasks always call a research agent, and coding tasks always call a programming agent. However, in real-world operation, the states of different agents may differ. For instance, an agent might be under excessive load, experience consecutive failures, have a low historical success rate for a certain type of task, lack the necessary context for the current task, or have insufficient ability to invoke tools. Without dynamic scheduling based on runtime states, task allocation can become inefficient, impacting execution efficiency and result quality.

[0021] (5) Long task contexts are prone to expansion.

[0022] In agent systems based on large language models, the following data is continuously generated during task execution: user input, intermediate analysis, tool return results, task logs, agent messages, historical context, error messages, and multi-round modification records. Existing technologies typically concatenate a large amount of historical information directly into the prompt words, resulting in increasingly longer contexts, high token consumption, distracted model attention, loss of key information, and decreased response speed.

[0023] (6) Lack of failure recovery and alternative path generation capabilities

[0024] Existing systems typically handle task failures by simply retrying or terminating the task. This approach lacks fine-grained processing based on the cause of the failure. For example, if a tool call fails, a different tool should be used or a delayed retry should be implemented; if the agent's capabilities are mismatched, the agent should be reassigned; if the task description is unclear, a clarifying subtask should be generated; if the context is insufficient, memory retrieval should be triggered; if the task is too large, it should be split into subtasks; and if there is a result conflict, a verification task should be generated. Therefore, existing systems lack state-based adaptive recovery capabilities.

[0025] (7) Insufficient ability to share memory among intelligent agents

[0026] In existing systems, different agents often only pass information through current messages, lacking a unified shared memory layer. This leads to: information already obtained by one agent not being fully utilized by other agents; multiple agents repeatedly searching and analyzing data; difficulty in inheriting historical conclusions in long-cycle tasks; and the inability of user preferences / project rules / execution constraints to remain effective.

[0027] Existing multi-agent-based task scheduling schemes typically include: receiving a natural language request input by a user; performing a structured task decomposition on the natural language request to generate a task graph containing multiple task nodes and their dependencies; matching a target execution agent from an agent registry based on the capability tags required by the task nodes; scheduling the target execution agent to execute the corresponding sub-task, obtaining structured execution results, and generating a task execution response based on all structured execution results.

[0028] The above solution can solve the fundamental automation problem of natural language requests to multi-agent task scheduling, but its focus remains on task decomposition, capability label matching, agent registry center selection, and structured result generation. For long-task execution scenarios, the above solution still has the following shortcomings:

[0029] (1) The task graph is mainly used as a task scheduling structure and lacks a continuous evolution loop based on runtime state as feedback.

[0030] (2) When the task graph changes during execution, there is a lack of task graph version difference record objects, and it is impossible to accurately record the node set, edge set, triggering reason, triggering node and running status before and after the task graph changes;

[0031] (3) There is a lack of binding between the task graph version and the runtime state snapshot, making it difficult to restore to a specific task graph version and corresponding runtime state after task interruption, exception failure or context loss;

[0032] (4) There is a lack of a unified handling mechanism for context bloat, token consumption, task round growth and key state retention during long task execution;

[0033] (5) The lack of execution trajectory auditing, state recovery and task graph rollback mechanisms for long tasks makes it difficult to support the continuous execution of multi-agent tasks that span rounds, time periods and are interruptible.

[0034] Therefore, while existing technologies can perform ordinary multi-agent task scheduling, they cannot solve the problems of continuous evolution of task graphs, maintenance of state consistency, recovery of state snapshots, and traceability of execution trajectories during the execution of complex and long tasks.

[0035] This invention aims to solve the following technical problems:

[0036] (1) How to dynamically adjust the task graph structure according to the running status during the execution of a multi-agent task;

[0037] (2) How to perform unified runtime state management for task nodes, intelligent agents, tool calls, context and memory;

[0038] (3) How to dynamically select a suitable agent based on the task state and the agent state;

[0039] (4) How to perform rollback, replacement, and recovery based on state snapshots when a task fails;

[0040] (5) How to compress the context and preserve critical states during the execution of long tasks;

[0041] (6) How to transform a multi-agent system from a fixed workflow into a dynamic collaborative system that is evolvable, recoverable, and traceable. Summary of the Invention

[0042] To address the problems existing in the background technology, this invention proposes a method and system for multi-agent dynamic task graph evolution and state recovery for long-term task execution.

[0043] A method for dynamic task graph evolution and state recovery of multi-agent systems for long-running tasks includes the following steps:

[0044] M100 receives a user's long task request, establishes a long task execution instance and generates a unique task identifier. The long task execution instance is used to associate the user's target, task graph version set, runtime state object, runtime state snapshot set, task graph version difference record set, shared memory index and execution trajectory.

[0045] M200 generates an initial task graph based on the long task execution instance, or loads a historical task graph version if a recoverable historical state exists, initializes a runtime state object, and saves an initial runtime state snapshot; the runtime state object includes a current task identifier, a current task graph version, a currently active task graph, a set of executable task nodes, a set of executing task nodes, a set of completed task nodes, a set of failed task nodes, a set of agent states, a set of tool states, a context cache, a memory index, an abnormal state, and a cost state;

[0046] M300: Based on the dependencies between task nodes in the currently active task graph, determine the executable task nodes whose dependency conditions have been met, and construct a node execution context for each executable task node. The node execution context includes the current node task objective, the output results of the preceding task nodes, the user's original objective, the current task graph summary, relevant shared memory, relevant tool descriptions, current constraints, and output format requirements.

[0047] M400 selects a target agent from the candidate agent set based on the capabilities required by the task node, the capabilities of the candidate agents, the degree of context matching, the degree of tool matching, historical execution results, current load, and recent failure status. It then locks the corresponding task node and assigns the target agent to the corresponding task node, which then executes the corresponding task node according to the node execution context.

[0048] M500 collects the execution results of task nodes, updates the runtime state object, and updates the shared memory based on the execution results of task nodes. Based on the updated runtime state object, it determines whether the task graph evolution conditions are met. If the task graph evolution conditions are met, it performs at least one of the following operations on the currently effective task graph: adding task nodes, deleting task nodes, splitting task nodes, merging task nodes, replacing task nodes, adjusting dependency edges, generating verification task nodes, or rolling back the task graph, generating a new task graph version and a task graph version difference record object.

[0049] M510. Generate a corresponding runtime state snapshot for the new task graph version, and establish a binding relationship between the task graph version difference record object and the runtime state snapshot; the task graph version difference record object records at least the task graph version before the change, the task graph version after the change, the set of changed task nodes, the set of changed dependency edges, the evolution triggering reason, the triggering task node, and the corresponding runtime state snapshot reference.

[0050] M520: When a task node fails to execute, task execution is interrupted, task graph dependency is abnormal, or a state recovery request is received, the target task graph version and the corresponding runtime state snapshot are located according to the task identifier and the binding relationship. The task graph structure, task node state, agent state, tool state, context summary, memory index, completed results and cost state are restored. The consistency between the restored task graph structure and the runtime state is verified. The set of executable task nodes is re-determined, and agents are continued to be scheduled based on the restored runtime state.

[0051] M600: When the currently active task graph meets the preset task completion conditions, integrate the output results of the completed necessary task nodes, generate the final result, and save the complete execution trajectory; the preset task completion conditions include the completion of necessary task nodes, the absence of unprocessed high-priority failed task nodes, the generation of the final output task node, and the absence of unprocessed task result conflicts.

[0052] Based on the above, in step M200, according to the task identifier, user identifier, or task recovery request, query whether there is a historical task graph version and runtime state snapshot corresponding to the current long task execution instance.

[0053] If a recoverable historical state exists, select the most recent stable runtime state snapshot from the recoverable historical state, load the task graph version corresponding to the stable runtime state snapshot, and restore the task node state, agent state, tool state, context summary, memory index, completed results, and cost state.

[0054] If no recoverable historical state exists, an initial task graph is generated, the initial task graph is marked as the initial task graph version, and an initial runtime state snapshot is generated.

[0055] The stable runtime state snapshot refers to a runtime state snapshot in which the task graph version corresponding to the snapshot is consistent with the task graph version recorded in the snapshot, the completed state of the executing task nodes has been solidified, the output results of the completed task nodes have been persisted, the incomplete tool calls have ended or have been marked as recoverable, and there are no unhandled dependency exceptions in the task graph.

[0056] Based on the above, the task graph evolution conditions in step M500 include at least one of the following:

[0057] When the execution result of a task node contains an unfinished target that does not exist in the current task graph, a new task node is generated and the corresponding dependency relationship is established;

[0058] When the complexity score of a task node exceeds the preset complexity threshold, the task node is split into multiple sub-task nodes, and the dependencies between the sub-task nodes are re-established according to the execution order of the sub-task nodes.

[0059] When the number of failed executions of a task node reaches a preset failure threshold, an alternative task node or recovery path is generated.

[0060] When the output results of multiple task nodes meet the preset conflict judgment conditions, a verification task node is generated.

[0061] When users add, delete, or modify task requirements during task execution, corresponding task nodes are added, deleted, or adjusted accordingly.

[0062] When the token consumption, execution time, or tool call cost reaches the corresponding resource threshold, perform at least one of the following operations on the current task graph: merge task nodes, pause low-priority task nodes, replace smart agents, or compress context.

[0063] Based on the above, step M510 establishes the binding relationship between the task graph version difference record object and the runtime state snapshot, including:

[0064] Generate a task graph version difference record identifier for this task graph evolution;

[0065] Generate a task diagram version difference record object based on the task diagram version before and after the change.

[0066] Generate a runtime state snapshot corresponding to the changed task graph version, and write the task graph version difference record identifier into the runtime state snapshot;

[0067] Write the snapshot identifier of the runtime state snapshot into the corresponding task graph version difference record object;

[0068] Save the correspondence between the task graph version, the task graph version difference record object, and the runtime state snapshot.

[0069] Based on the above, the runtime state snapshot is generated at at least one of the following times: after the initial task graph is generated, after the preset key task nodes are completed, after the task graph evolution is completed, before or after an abnormal event occurs, after the user modifies the task objective, and before the execution of a high-risk task node.

[0070] The runtime state snapshot includes a snapshot identifier, the task identifier to which it belongs, the task graph version corresponding to the snapshot, the task node state set, the agent state set, the tool state set, the context summary, the memory index reference, the completed result reference, the abnormal state, the cost state, the task graph version difference record reference, the recovery state information, and the snapshot generation time.

[0071] The runtime state snapshot is a state record formed by extracting preset state fields from the runtime state object, and does not include the runtime state snapshot set itself in the runtime state object.

[0072] Based on the above, the k-th task graph version is represented by a directed graph as follows:

[0073]

[0074] in, This represents the k-th task graph version. This represents the set of task nodes in the k-th task graph version. This represents the set of directed dependency edges between task nodes.

[0075] The runtime execution state corresponding to the k-th task graph version is represented as follows:

[0076]

[0077] in, This indicates the allocation relationship between task nodes and intelligent agents. It represents the set of runtime states consisting of task node state, agent state, tool state, context state, exception state, and recovery state. Represents a set of memory indexes. Indicates the cost status.

[0078] When the task graph evolves from the k-th task graph version to the (k+1)-th task graph version, a corresponding task graph version difference record object and a runtime state snapshot are generated.

[0079] Based on the above, in step M400, the agent matching and scoring method is as follows:

[0080] Score(agent,node)=

[0081] w1×CapabilityMatch+

[0082] w2×ContextMatch+

[0083] w3×ToolMatch+

[0084] w4×SuccessRate

[0085] -w5×CurrentLoad

[0086] -w6×RecentFailure

[0087] in:

[0088] CapabilityMatch represents the degree of match between the agent's capabilities and the task requirements;

[0089] ContextMatch indicates the degree of matching between the agent's current context and the task context;

[0090] ToolMatch represents the degree of matching between the tools available to the agent and the tool requirements of the task;

[0091] SuccessRate represents the agent's historical success rate;

[0092] CurrentLoad indicates the current load;

[0093] RecentFailure indicates the number of recent failures;

[0094] CapabilityMatch, ContextMatch, ToolMatch, SuccessRate, CurrentLoad, and RecentFailure are normalized to preset numerical ranges; w1 to w6 are non-negative weight parameters.

[0095] Before calculating the agent matching score, candidate agents that do not have the ability to enforce task nodes or access to necessary tools are excluded; when the highest agent matching score is lower than the preset admission threshold, at least one of the following is triggered: task splitting node, capability supplementing node, alternative tool node, or manual intervention request.

[0096] A multi-agent dynamic task graph evolution and state recovery system for long-running tasks includes:

[0097] The long task instance management module is used to receive long task requests, create long task execution instances, and assign a unique task identifier to the long task execution instances.

[0098] The task input parsing module is used to parse long task requests and generate structured task request objects;

[0099] The dynamic task graph construction module is used to generate an initial task graph based on a structured task request object, and to generate a new version of the task graph based on the task graph evolution operation.

[0100] The agent capability modeling module is used to maintain the capabilities, callable tools, current load, and historical execution results of candidate agents.

[0101] The multi-agent dynamic scheduling module is used to select target agents based on task node status, agent status, and tool status, lock executable task nodes, and assign target agents to corresponding task nodes.

[0102] The runtime state management module is used to maintain the currently active task graph, task node state, agent state, tool state, context state, memory state, exception state, and cost state.

[0103] The task graph evolution decision module is used to determine whether the task graph evolution conditions are met based on the runtime state, and when the task graph evolution conditions are met, to perform at least one of the following operations on the currently effective task graph: adding task nodes, deleting task nodes, splitting task nodes, merging task nodes, replacing task nodes, adjusting dependency edges, generating verification task nodes, or rolling back the task graph.

[0104] The Task Graph Version Difference Recording module is used to generate Task Graph Version Difference Recording objects when the task graph evolves.

[0105] The state snapshot management module is used to generate corresponding runtime state snapshots for the initial task graph version and the evolved task graph version, and to establish a binding relationship between the task graph version difference record object and the runtime state snapshot.

[0106] The state recovery control module is used to restore the target task graph version and its corresponding runtime state according to the binding relationship when the task execution fails, is interrupted, has a dependency exception, or a state recovery request is received; verify the consistency between the restored task graph structure and the runtime state; redetermine the set of executable task nodes; and continue to schedule the agent.

[0107] The results summary and output module is used to summarize the execution results of the necessary completed task nodes and generate the final output when the currently effective task graph meets the preset task completion conditions.

[0108] Based on the above, the system further includes:

[0109] The shared memory management module is used to update the short-term task context, medium-term task status, and long-term shared memory based on the execution results of task nodes.

[0110] The context compression module is used to compress historical context into a structured summary when the context length, token consumption, or task execution rounds reach the corresponding preset thresholds.

[0111] The fault analysis and recovery strategy module is used to determine the fault type based on tool abnormality, agent output abnormality, insufficient context, excessive task complexity, or conflicting task results, and generate recovery actions such as replacing the tool, replacing the agent, supplementing the context, splitting task nodes, generating alternative task nodes, or generating verification task nodes.

[0112] The state recovery control module is used to restore the target task graph version and its corresponding runtime state based on the recovery actions generated by the fault analysis and recovery strategy module, or based on task execution interruption and state recovery requests.

[0113] This invention has outstanding substantive features and significant progress compared to the prior art, specifically:

[0114] (1) Runtime state feedback closed-loop mechanism for long task execution: During task execution, this invention continuously collects the task node state, agent state, tool state, context state, memory state, abnormal state, and cost state, and writes the above states into the runtime state object. The system determines whether to trigger task graph evolution, fault recovery, context compression, or agent rescheduling based on the runtime state object, so that the long task execution process forms a state feedback closed loop;

[0115] (2) Task Graph Version Difference Recording and State Snapshot Binding Mechanism: This invention generates a new task graph version each time the task graph changes, and simultaneously generates a task graph version difference record object. This object records the task graph version before the change, the task graph version after the change, the set of changed nodes, the set of changed edges, the evolution triggering reason, the triggering node, the runtime state at the time of triggering, and the state snapshot reference. By binding the task graph version difference record object with the runtime state snapshot, the system can restore to the specified task graph version and corresponding runtime state after the task is interrupted or fails;

[0116] (3) Dynamic task graph evolution mechanism based on runtime state: This invention does not generate a fixed task graph all at once at the start of the task, but performs operations such as adding nodes, splitting nodes, merging nodes, replacing nodes, adjusting dependent edges, generating verification nodes, or rolling back the task graph according to the runtime state during the task execution process, so that the task graph can adapt to changes in requirements, result conflicts, missing context, and abnormal failures during the execution of long tasks.

[0117] (4) Task recovery and task graph rollback mechanism based on state snapshots: This invention saves runtime state snapshots after the initial task graph is generated, after key nodes are completed, after the task graph evolution is completed, before and after an exception occurs, and after the user modifies the task objective. When task execution is interrupted, fails, or a recovery request is received, the system restores the task graph version, task node state, agent state, tool state, context summary, memory index, and completed results based on the state snapshot, and continues to execute the task based on the restored state.

[0118] (5) Context compression and shared memory layering mechanism for long tasks: This invention determines whether to trigger context compression based on context length, token consumption, and task execution rounds, and compresses the historical context into a structured summary while retaining the task objective, key conclusions, user constraints, output results of preceding nodes, and the list of tasks to be executed. The system further divides the task process information into short-term context, medium-term task status, long-term shared memory, and disposable temporary logs to reduce context expansion during the execution of long tasks;

[0119] (6) Agent rescheduling mechanism based on runtime state: The agent scheduling in this invention is not a one-time matching based solely on task capability tags, but rather a dynamic rescheduling based on task node state, agent load, historical success rate, context matching degree, tool availability, and recent failure count. When an agent fails consecutively, has excessive load, or has a mismatched context, the system can reselect an agent to execute the task based on the runtime state. Attached Figure Description

[0120] Figure 1 This is a flowchart illustrating the process of this invention.

[0121] Figure 2 This is a schematic diagram of the structure of the multi-agent dynamic task graph evolution and state recovery system of the present invention.

[0122] Figure 3 This is a schematic diagram of the structure of the present invention during operation.

[0123] Figure 4 This is a schematic diagram illustrating the evolution of the task graph version and the binding relationship between the task graph version difference record object and the runtime state snapshot of the present invention. Detailed Implementation

[0124] 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, and 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.

[0125] M100 receives a user's long task request, establishes a long task execution instance and generates a unique task identifier. The long task execution instance is used to associate the user's target, task graph version set, runtime state object, runtime state snapshot set, task graph version difference record set, shared memory index and execution trajectory.

[0126] M200 generates an initial task graph based on the long task execution instance, or loads a historical task graph version if a recoverable historical state exists, initializes a runtime state object, and saves an initial runtime state snapshot; the runtime state object includes a current task identifier, a current task graph version, a currently active task graph, a set of executable task nodes, a set of executing task nodes, a set of completed task nodes, a set of failed task nodes, a set of agent states, a set of tool states, a context cache, a memory index, an abnormal state, and a cost state;

[0127] M300: Based on the dependencies between task nodes in the currently active task graph, determine the executable task nodes whose dependency conditions have been met, and construct a node execution context for each executable task node. The node execution context includes the current node task objective, the output results of the preceding task nodes, the user's original objective, the current task graph summary, relevant shared memory, relevant tool descriptions, current constraints, and output format requirements.

[0128] M400 selects a target agent from the candidate agent set based on the capabilities required by the task node, the capabilities of the candidate agents, the degree of context matching, the degree of tool matching, historical execution results, current load, and recent failure status. It then locks the corresponding task node and assigns the target agent to the corresponding task node, which then executes the corresponding task node according to the node execution context.

[0129] M500 collects the execution results of task nodes, updates the runtime state object, and updates the shared memory based on the execution results of task nodes. Based on the updated runtime state object, it determines whether the task graph evolution conditions are met. If the task graph evolution conditions are met, it performs at least one of the following operations on the currently effective task graph: adding task nodes, deleting task nodes, splitting task nodes, merging task nodes, replacing task nodes, adjusting dependency edges, generating verification task nodes, or rolling back the task graph, generating a new task graph version and a task graph version difference record object.

[0130] M510. Generate a corresponding runtime state snapshot for the new task graph version, and establish a binding relationship between the task graph version difference record object and the runtime state snapshot; the task graph version difference record object records at least the task graph version before the change, the task graph version after the change, the set of changed task nodes, the set of changed dependency edges, the evolution triggering reason, the triggering task node, and the corresponding runtime state snapshot reference.

[0131] M520: When a task node fails to execute, task execution is interrupted, task graph dependency is abnormal, or a state recovery request is received, the target task graph version and the corresponding runtime state snapshot are located according to the task identifier and the binding relationship. The task graph structure, task node state, agent state, tool state, context summary, memory index, completed results and cost state are restored. The consistency between the restored task graph structure and the runtime state is verified. The set of executable task nodes is re-determined, and agents are continued to be scheduled based on the restored runtime state.

[0132] M600: When the currently active task graph meets the preset task completion conditions, integrate the output results of the completed necessary task nodes, generate the final result, and save the complete execution trajectory; the preset task completion conditions include the completion of necessary task nodes, the absence of unprocessed high-priority failed task nodes, the generation of the final output task node, and the absence of unprocessed task result conflicts.

[0133] The intelligent agent in this invention can be implemented by a large language model, a rule engine, a dedicated algorithm model, a software robot, an API agent, or a combination thereof, and is not limited to a single large language model implementation.

[0134] It should be noted that this invention does not use a one-time generated task graph as a fixed execution basis. Instead, it uses the task graph as a dynamic control structure that can continuously evolve with changes in runtime state, and uses the runtime state object as the feedback basis for task graph evolution, agent scheduling, fault recovery, and context compression. After receiving a long task request, the system establishes a long task execution instance, generates or loads the task graph, and initializes the runtime state object. During task execution, the system continuously collects task node states, agent states, tool call states, context states, memory states, abnormal states, and cost states, and determines whether to trigger task graph evolution or state recovery based on these states.

[0135] When the conditions for task graph evolution are met, the system performs at least one of the following operations on the current task graph: adding nodes, splitting nodes, merging nodes, replacing nodes, adjusting dependent edges, generating verification nodes, or rolling back the task graph, and generates a new task graph version. Simultaneously, the system generates a task graph version difference record object to record the task graph version before the change, the task graph version after the change, the set of changed nodes, the set of changed edges, the reason for the evolution trigger, the triggering node, the running state at the time of triggering, and a reference to the corresponding state snapshot.

[0136] When a node fails, a tool malfunctions, an agent malfunctions, a missing context, a cost exceeding the limit, a task interruption, or a user requests a recovery during task execution, the system restores the task graph version, task node state, agent state, tool state, context summary, memory index, and completed results based on the runtime state snapshot, and continues to schedule agents to execute subsequent tasks based on the restored task graph and runtime state.

[0137] Thus, this invention forms a closed-loop control mechanism of "long task instance creation - runtime state acquisition - task graph evolution judgment - task graph version difference recording - state snapshot binding - anomaly recovery - continued execution", enabling multi-agent systems to maintain state continuity, task recoverability and execution process traceability in long-cycle, complex, multi-stage and interruptible task scenarios.

[0138] like Figure 2 As shown in this embodiment, a multi-agent dynamic task graph evolution and state recovery system for long-running tasks is also provided. This invention uses a runtime state management module as its core, and through a long-running task instance management module, a task input parsing module, a dynamic task graph construction module, an agent capability modeling module, a multi-agent dynamic scheduling module, a task graph evolution decision-making module, a task graph version difference recording module, a state snapshot management module, a state recovery control module, a shared memory management module, a context compression module, a fault analysis and recovery strategy module, and a result summary and output module, it achieves multi-agent dynamic task graph evolution, state snapshot binding, state recovery, and continuous collaborative execution for long-running tasks.

[0139] Specifically, the system includes the following modules:

[0140] (1) Task input parsing module: It is used to receive the long task execution instance output by the long task instance management module, and extract the user's original goal, input data, output requirements, constraints, task type, priority, deadline, user preferences, available tool range and available agent range from the long task execution instance, and parse it into a structured task request object.

[0141] The structured task request object includes at least: task objective, task type, input data, output requirements, constraints, priority, deadline, user preferences, range of available tools, and range of available agents.

[0142] (2) Dynamic task graph construction module: It is used to generate an initial task graph based on the structured task request object, and to perform node addition, deletion, splitting, merging, replacement or dependency edge adjustment on the currently effective task graph based on the task graph evolution operation output by the task graph evolution decision module, so as to generate a new task graph version.

[0143] The k-th task graph version is represented as a directed graph as follows:

[0144]

[0145] in, This represents the k-th task graph version. This represents the set of task nodes in the k-th task graph version. This represents the set of directed dependency edges between task nodes.

[0146] The runtime execution state corresponding to the k-th task graph version is represented as follows:

[0147]

[0148] in, This indicates the allocation relationship between task nodes and intelligent agents. It represents the set of runtime states consisting of task node state, agent state, tool state, context state, exception state, and recovery state. Represents a set of memory indexes. Indicates the cost status.

[0149] (3) Runtime status management module: used to uniformly maintain the running status during task execution.

[0150] Runtime state objects include: global task state, current task graph version number, set of currently executable task nodes, set of currently executing task nodes, set of completed task nodes, set of failed task nodes, agent state set, tool call state set, context cache set, long-term memory index set, exception event set, state snapshot set, rollback point set, and cost consumption state, etc.

[0151] (4) Agent capability modeling module: It is used to receive the registration information, capability tags, callable tool information, historical execution records, current load status and context access permissions of each agent in the candidate agent set, and generate and maintain the capability description object corresponding to each agent based on the above information, which is used by the subsequent multi-agent dynamic scheduling module to perform agent matching and scoring.

[0152] Each agent corresponds to a capability description object, which includes at least: agent identifier, agent role, capability tag, callable tools, types of tasks that can be processed, current load, historical success rate, average execution time, number of recent failures, context matching degree, and memory access permissions.

[0153] (5) Multi-agent dynamic scheduling module: used to dynamically select the executing agent based on the task node status and agent status.

[0154] The system does not call a fixed agent, but rather evaluates the agent based on a comprehensive assessment of the task type, agent capabilities, workload, historical performance, context matching, and tool availability, and selects the appropriate agent to execute the task.

[0155] (6) Task graph evolution decision module: used to determine whether the task graph needs to be adjusted based on the runtime state.

[0156] This module can perform the following task graph evolution operations: adding task nodes, deleting failed nodes, splitting complex nodes, merging similar nodes, replacing failed nodes, adjusting dependency edges, generating parallel task branches, generating verification tasks, generating supplementary retrieval tasks, and rolling back to historical task graph versions.

[0157] (7) Shared memory management module: used to share associated data during the task process among multiple intelligent agents.

[0158] Shared memories include: short-term task context, medium-term project status, long-term knowledge memory, user preferences, task execution history, key conclusions, error logs, and success strategies.

[0159] (8) Context compression module: used to compress historical context during the execution of long tasks.

[0160] The compressed results include: a summary of the task objectives, a summary of completed tasks, current bottlenecks, key decisions, a summary of tool call results, user constraints, and a list of tasks to be executed.

[0161] (9) Fault Analysis and Recovery Strategy Module: It is used to determine the fault type based on the tool anomaly, agent output anomaly, insufficient context, excessive task complexity, or task result conflict that occurs during the execution of the task node, and to generate at least one recovery action based on the fault type, such as replacing the tool, replacing the agent, supplementing the context, splitting the task node, generating a replacement task node, or generating a verification task node.

[0162] The fault analysis and recovery strategy module sends the generated recovery actions to the task graph evolution decision module or the state recovery control module. The task graph evolution decision module performs task graph adjustment, or the state recovery control module performs task graph version and runtime state recovery.

[0163] (10) Result summary output module: When the current effective task graph meets the preset task completion conditions, it summarizes the execution results of the necessary task nodes that have been completed and generates the final output, while saving the final version of the task graph, key running status, shared memory index and execution trajectory.

[0164] (11) Long task instance management module: used to create a long task execution instance when a long task request is received, and to assign a unique task identifier to the instance.

[0165] The long-running task execution instance is used to associate user goals, task graph version sets, runtime state objects, runtime state snapshot sets, task graph version difference record sets, shared memory indexes, and execution trajectories. For long-running tasks that are interrupted or paused, the long-running task instance management module is also used to load historical task graph versions and corresponding runtime state snapshots based on the task identifier.

[0166] (12) Task graph version difference record module: used to generate a task graph version difference record object each time the task graph evolves.

[0167] The task graph version difference record object includes at least the task graph version before the change, the task graph version after the change, the set of newly added nodes, the set of deleted nodes, the set of replaced nodes, the set of changed dependent edges, the evolution trigger reason, the trigger node identifier, the runtime state at the time of triggering, the state snapshot reference, and the change time. This module is used to support the backtracking, auditing, and recovery of the task graph evolution process.

[0168] (13) Status Snapshot Management Module: Used to extract preset status fields from the runtime status object and generate corresponding runtime status snapshots for the initial task graph version, the task graph version after the preset key task nodes are completed, and the task graph version after the task graph is evolved.

[0169] The state snapshot management module is also used to write the task graph version difference record identifier into the runtime state snapshot, and write the snapshot identifier of the runtime state snapshot into the corresponding task graph version difference record object, so as to establish the correspondence between the task graph version, the task graph version difference record object and the runtime state snapshot.

[0170] The runtime state snapshot does not include the runtime state snapshot collection itself in the runtime state object, nor does it include the complete task graph version difference record collection.

[0171] (14) State recovery control module: When a task node fails to execute, task execution is interrupted, task graph dependency is abnormal, or a state recovery request is received, it records the binding relationship between the object and the runtime state snapshot based on the task identifier and the difference between the task graph version, locates the target task graph version and the corresponding runtime state snapshot; restores the task graph structure, task node state, agent state, tool state, context summary, memory index, completed results and cost state; verifies the consistency between the restored task graph structure and the runtime state, redetermines the set of executable task nodes, and continues to schedule agents based on the restored runtime state.

[0172] In this invention, for the task node data structure, each task node includes: a unique task node identifier (NodeID), a parent task node identifier (ParentNodeID), a task type (TaskType, such as planning, retrieval, generation, encoding, testing, verification, summarizing, etc.), a goal that the current node needs to complete (TaskGoal), an input data reference (InputDataRef), an output data reference (OutputDataRef), a node required capability (RequiredCapability), a set of candidate agents (CandidateAgents), an agent that actually executes the node (AssignedAgent), preceding dependent nodes (DependencyNodes), successor nodes (SuccessorNodes), a task priority (Priority), a node status (Status), a number of retries (RetryCount), a timeout threshold (TimeoutLimit), a context reference (ContextRef), a shared memory reference (MemoryRef), a tool requirement (ToolRequirement), a node result evaluation rule (EvaluationRule), a failure reason (FailureReason), a status snapshot reference (SnapshotRef), and the task graph version to which the node belongs (GraphVersion).

[0173] Each task node status includes, but is not limited to: Pending, Ready (dependencies satisfied and waiting for scheduling), Running, Waiting for results from external tools or other nodes, Completed, Failed, Blocked, Suspended, Obsolete, Replaced, and Rolled Back.

[0174] By analyzing the status of task nodes, the system can clearly define the lifecycle of each task node during runtime.

[0175] like Figure 3 As shown, the runtime state object `RuntimeState` uniformly maintains the task state, agent state, tool state, context state, memory state, exception state, snapshot state, task graph version difference record state, recovery state, and cost state. The system uses this runtime state object to record key state information during the execution of long tasks and drives task graph evolution, agent scheduling, fault recovery, context compression, and state recovery based on state changes.

[0176] Runtime state objects include: current task ID (TaskID), user goal (UserGoal), current task graph version (CurrentGraphVersion), currently active task graph (ActiveGraph), set of executable nodes (ReadyNodeSet), set of executing nodes (RunningNodeSet), set of completed nodes (CompletedNodeSet), set of failed nodes (FailedNodeSet), agent state map (AgentStateMap), tool state map (ToolStateMap), context cache (ContextCache), memory index (MemoryIndex), event log (EventLog), error log (ErrorLog), set of state snapshots (SnapshotList), set of task graph version difference records (GraphDiffList), rollback point list (RollbackPointList), recovery state information (RecoveryState, including recovery identifier, recovery source, recovery target version, and recovery time), token consumption state (TokenUsage), cost budget (CostBudget), and execution mode (ExecutionMode, such as serial, parallel, semi-automatic, and fully automatic).

[0177] The overall operation process is as follows Figure 1 As shown, after receiving a long task request, the system creates a long task execution instance and determines whether there is a recoverable historical running state. If a recoverable state exists, the system loads the historical task graph version and runtime state snapshot, and restores the task node state, agent state, tool state, context summary, memory index, and completed results. If no recoverable state exists, the system generates an initial dynamic task graph V0, initializes the runtime state object RuntimeState, and saves the initial state snapshot RuntimeSnapshot.

[0178] During task execution, the system identifies executable task nodes, calculates agent matching scores, and assigns agents to execute task nodes. It then collects execution results, tool results, exception information, and cost information, and updates the runtime state object. When the runtime state meets the task graph evolution conditions, the system performs operations such as adding, splitting, merging, replacing, adjusting dependency edges, generating verification nodes, or rolling back the task graph, generating a new task graph version Vn and a task graph version difference record object GraphDiff, which is then bound to a RuntimeSnapshot. When a task fails, is interrupted, or a recovery request occurs, the system restores the task graph structure and runtime state based on the RuntimeSnapshot and GraphDiff until the task is completed and the final result is output.

[0179] Specifically:

[0180] Step S1: Receive long task requests and create long task execution instances.

[0181] The system receives long task requests input by the user. These requests can be natural language tasks, file tasks, interface tasks, automation tasks, periodic tasks, or interruptible tasks. The task input parsing module parses the long task requests, extracting the overall goal, explicit constraints, implicit constraints, input data, output format, task domain, time requirements, available tools, and expected results.

[0182] The system creates a long task execution instance for the long task request and generates a unique task identifier. The long task execution instance is used to associate the user goal, task graph version set, runtime state object, runtime state snapshot set, task graph version difference record set, shared memory index, and execution trajectory.

[0183] Step S2: Determine if there is a recoverable historical operating state.

[0184] The system queries whether a historical task graph version and runtime state snapshot corresponding to the current long task exist based on the task identifier, user identifier, or task recovery request. If a recoverable state exists, the system loads the most recent stable runtime state snapshot, restores the task graph version, task node state, agent state, tool state, context summary, memory index, completed results, and cost state, and proceeds to step S4; if no recoverable state exists, the system proceeds to step S3.

[0185] The stable runtime state snapshot refers to a runtime state snapshot in which the task graph version corresponding to the snapshot is consistent with the task graph version recorded in the snapshot, the completed state of the executing task nodes has been solidified, the output results of the completed task nodes have been persisted, the incomplete tool calls have ended or have been marked as recoverable, and there are no unhandled dependency exceptions in the corresponding task graph.

[0186] Step S3: Generate the initial task graph and initialize the runtime state object.

[0187] When no recoverable state exists, the system generates an initial task graph based on the long task execution instance of the long task request, marks the initial task graph version as V0, and initializes a runtime state object (RuntimeState). The runtime state object includes the current task identifier, current task graph version, currently active task graph, set of executable task nodes, set of executing task nodes, set of completed task nodes, set of failed task nodes, agent state set, tool state set, context cache, memory index, abnormal state, and cost state. The system saves a snapshot of the initial runtime state and marks task nodes without prerequisite dependencies as Ready.

[0188] Step S4: Identify the set of executable task nodes

[0189] The system scans all nodes in the current task graph and determines whether the prerequisites of each node are satisfied.

[0190] If all dependent nodes of a node are Completed, then the node's state is set to Ready.

[0191] Form a set of executable task nodes:

[0192] ReadyNodeSet = {all nodes whose dependencies are satisfied but not yet executed}

[0193] Step S5: Construct the task node scheduling context and calculate the agent matching score.

[0194] For each executable task node, the system constructs a task node scheduling context based on the node's task objective, the output of the preceding task node, the required capabilities, tool requirements, current constraints, and the current task graph summary, and calculates the candidate agent matching score based on the task node scheduling context.

[0195] The agent matching score can be calculated as follows:

[0196] Score(agent, node) =

[0197] w1 × CapabilityMatch +

[0198] w2 × ContextMatch +

[0199] w3 × ToolMatch +

[0200] w4 × SuccessRate

[0201] - w5 × CurrentLoad

[0202] - w6 × RecentFailure

[0203] in:

[0204] CapabilityMatch represents the degree of match between the agent's capabilities and the task requirements;

[0205] ContextMatch represents the degree of matching between the agent's current context and the task context;

[0206] ToolMatch represents the degree of match between the tools available to the agent and the tool requirements of the task;

[0207] SuccessRate represents the agent's historical success rate;

[0208] CurrentLoad represents the current load;

[0209] RecentFailure indicates the number of recent failures;

[0210] CapabilityMatch, ContextMatch, ToolMatch, SuccessRate, CurrentLoad, and RecentFailure are normalized to preset numerical ranges, with w1 to w6 being non-negative weight parameters.

[0211] Before calculating the agent matching score, the system first excludes candidate agents that do not have the mandatory ability of the current task node or the necessary tool access permissions.

[0212] When the highest agent matching score reaches the preset admission threshold, the system selects the agent with the highest score to execute the corresponding task node; when the highest agent matching score is lower than the preset admission threshold, the system triggers the generation of at least one of the following: task splitting node, capability supplementing node, alternative tool node, or manual intervention request.

[0213] Step S6: Lock the task node and assign an agent

[0214] The multi-agent dynamic scheduling module updates the status of the selected task node from Ready to Running.

[0215] Simultaneously record: executing agent, execution start time, input context, tool call permissions, current task graph version, and state snapshot reference.

[0216] This step prevents multiple agents from repeatedly executing the same task node.

[0217] Step S7: Construct the node execution context

[0218] The system completes the task node scheduling context based on the assigned intelligent agent's context access permissions, shared memory access permissions, and tool call permissions, forming the final node execution context.

[0219] The execution context of the final node includes the current node task objective, the output results of the preceding task nodes, the user's original objective, the current task graph summary, relevant shared memory, relevant tool descriptions, current constraints, and output format requirements.

[0220] If the context length exceeds the preset context length threshold, the context compression module is invoked to generate a structured context summary.

[0221] The compression process includes: deleting low-value historical dialogues, retaining user hard constraints, retaining key intermediate conclusions, retaining current node dependency results, and generating a structured context summary.

[0222] Step S8: The agent executes the task node.

[0223] The assigned agent executes task nodes according to the execution context.

[0224] During execution, the agent can: invoke large language models, invoke external tools, retrieve knowledge bases, read files, generate code, run tests, generate reports, and invoke APIs.

[0225] Each time a tool is invoked, it is recorded as a tool state object.

[0226] The tool state object includes:

[0227] ToolState = {

[0228] ToolCallID (a unique identifier for tool invocation),

[0229] ToolName (Tool Name)

[0230] InputParam (input parameters),

[0231] OutputResult

[0232] CallStatus (call status)

[0233] ErrorMessage (error message)

[0234] StartTime (calls the start time),

[0235] EndTime (call end time),

[0236] RelatedNodeID (Identifier of the associated task node)

[0237] }

[0238] Step S9: Collect task node execution results and update runtime status

[0239] After a task node completes execution, the system collects the following data: node output results, execution logs, tool call results, error messages, newly generated sub-targets, context changes, token consumption, and execution time.

[0240] The runtime state management module updates the following based on the execution results: task node state, agent state, tool state, context cache, memory index, event log, and cost consumption state.

[0241] If the execution is successful, the node state will be set to Completed.

[0242] If the execution fails, the node status is set to Failed, and the reason for the failure is recorded.

[0243] Step S10: Determine whether the task graph evolution has been triggered.

[0244] The task graph evolution decision module determines whether the task graph needs to be modified based on the runtime state.

[0245] The conditions that trigger the evolution of the task graph include:

[0246] (1) Triggering the addition of a sub-target

[0247] When the node output contains new unfinished targets, the system generates a new task node.

[0248] For example, if the research agent discovers that "further legal compliance review is needed," the system will automatically add a "compliance review node."

[0249] (2) Triggered by excessively high task complexity

[0250] When the complexity score of a task node exceeds the threshold, the system splits the node into multiple child nodes.

[0251] Complexity scores can be calculated based on the following factors: length of input data, number of targets, number of tools required, estimated execution time, and failure rate of similar historical tasks.

[0252] (3) Triggered by task failure

[0253] When a task node fails to execute and the number of failures exceeds a preset threshold, the system generates an alternative node or recovery path.

[0254] For example:

[0255] If the failure is due to insufficient capabilities of the agent, then replace the agent.

[0256] If the failure is due to insufficient context, then generate a supplementary data node;

[0257] If the failure is due to the tool being unavailable, then an alternative tool node is generated;

[0258] If the failure is due to the task being too large, then split the task into nodes.

[0259] (4) Result conflict triggering

[0260] When the output results of two task nodes conflict, the system generates a verification node.

[0261] For example, if one agent believes that solution A is feasible, while another agent believes that solution A is not feasible, the system adds a "conflict verification node".

[0262] (5) User feedback trigger

[0263] When a user adds new requirements during task execution, the system adds, deletes, or adjusts task nodes based on user feedback.

[0264] (6) Resource budget trigger

[0265] When token consumption, execution time, or tool call cost exceeds a threshold, the system adjusts the task graph.

[0266] For example: reduce task accuracy, merge similar nodes, pause low-priority nodes, trigger context compression, and switch to low-cost agents.

[0267] Step S11: Perform the task graph evolution operation

[0268] When the evolution conditions are met, the task graph evolution decision module modifies the current task graph.

[0269] The specific operations include:

[0270] (1) Add a new node

[0271] When a new sub-target is discovered, the system generates a new task node and establishes dependencies.

[0272] AddNode(NewNode): Adds the new task node to the task node collection.

[0273] AddEdge(SourceNode, NewNode): The original predecessor node points to the newly added node.

[0274] AddEdge(NewNode, TargetNode): Adds a new node that points to the original successor node.

[0275] (2) Split nodes

[0276] When the complexity of a task node is too high, split a node into multiple child nodes.

[0277] For example:

[0278] Original node: Generates complete project code

[0279] Split into:

[0280] Child node 1: Generate backend code

[0281] Child node 2: Generate front-end code

[0282] Child node 3: Generate database script

[0283] Child node 4: Generate deployment script

[0284] The original task node's node status is set to "Replaced" and it will no longer be used as a subsequent scheduling object; the system will add the multiple sub-task nodes generated after splitting to the current task graph and re-establish the dependency relationship according to the execution order between the sub-tasks.

[0285] (3) Merging nodes

[0286] When two or more task nodes have similar objectives, similar inputs, and similar output requirements, the system merges them into one node to reduce redundant execution.

[0287] Similarity can be calculated based on the task target text, input data, and output type.

[0288] If the similarity exceeds a preset threshold, a merge will be performed.

[0289] (4) Replace nodes

[0290] When the number of node failures exceeds a threshold, the system generates a replacement node.

[0291] For example:

[0292] Original node: Code generated by the Coding Agent

[0293] Reason for failure: Continuous generation of inoperable code

[0294] Alternate Nodes: Code regenerated by an advanced Coding Agent

[0295] The original node's status is set to Obsolete or Replaced.

[0296] (5) Adjust the dependent edges

[0297] When a node no longer depends on its predecessor node, or when a new predecessor verification node needs to be added, the system adjusts the dependency edges in the task graph. For example:

[0298] Original dependency: N3 → N5

[0299] After adjustment: N3 → N4 → N5

[0300] (6) Generate parallel branches

[0301] When there is no strong dependency between multiple nodes, the system marks them as executable in parallel.

[0302] For example: data retrieval node, competitor analysis node, technology selection node

[0303] It can be assigned to different agents for execution in parallel.

[0304] (7) Generate verification nodes

[0305] When the system detects high-risk output, conflicting output, or low-confidence output, it automatically generates a verification node.

[0306] Verification nodes can be executed by either a QA agent or a review agent.

[0307] (8) Task map version update

[0308] Each time the task graph changes, the system generates a new version of the task graph.

[0309] For example:

[0310] V0: Initial Task Map

[0311] V1: Added compliance review node

[0312] V2: Split code generation node

[0313] V3: Replace failed test nodes

[0314] The system records the differences between each version, including: added nodes, deleted nodes, replaced nodes, adjusted edges, trigger reasons, trigger time and trigger status.

[0315] Step S12: Save state snapshot

[0316] The system saves state snapshots at the following times: after the initial task graph is generated, after each key node is completed, after each task graph evolution, before and after each exception occurs, after the user modifies the task objective, and before the system prepares to execute high-risk nodes.

[0317] The state snapshot includes: the current task graph version, the state of all task nodes, the agent state, the tool state, the context summary, the memory index, the completed results, the current error record, the cost state, the task graph version difference record reference, the recovery state information, and the snapshot generation time.

[0318] In this embodiment, a state snapshot refers to a state record formed by the system solidifying and saving the current runtime state at a preset time; a state snapshot object (RuntimeSnapshot) is a data object used to carry this state record. Each state snapshot object corresponds to one state saving operation. The state snapshot object RuntimeSnapshot includes: a unique state snapshot identifier SnapshotID, a long task instance identifier TaskID, the task graph version GraphVersion corresponding to the snapshot, a task node state set NodeStateMap, an agent state set AgentStateMap, a tool call state set ToolStateMap, a context summary ContextSummary, a memory index reference MemoryIndexRef, a completed result reference CompletedResultRef, an abnormal state ErrorState, a cost state CostState, a task graph version difference record reference GraphDiffRef, recovery state information RecoveryState, and a snapshot generation time CreateTime.

[0319] The GraphDiffRef can be null when the runtime state snapshot is not generated by task graph evolution.

[0320] It's important to note that a runtime state snapshot is not a recursive copy of the runtime state object that includes all references. Instead, it extracts state records from the runtime state object, forming a set of predefined state fields. A runtime state snapshot does not include the runtime state snapshot collection itself within the runtime state object, nor does it include the complete task graph version difference record set; it only saves the reference identifiers of the corresponding task graph version difference records.

[0321] Step S13: Failure Detection and Recovery

[0322] When a task node fails, the fault analysis and recovery strategy module executes different recovery strategies based on the cause of the failure.

[0323] (1) Tool failure recovery

[0324] If the failure is due to the tool being unavailable, the interface timing out, or returning an exception, then: mark the tool status as abnormal, query alternative tools, rebuild the tool call node, or suspend or replace the original node.

[0325] (2) Agent failure recovery

[0326] If the failure is due to low agent output quality, consecutive failures, or failure to meet evaluation rules, then: reduce the agent's score, reselect an agent, generate an alternative execution node, or restore the node execution context from the most recent stable runtime state snapshot consistent with the current task graph version.

[0327] (3) Context-inadequate recovery

[0328] If the failure is due to insufficient context, then: generate a memory retrieval node, generate a data supplementation node, write the supplementary results to the context cache, and re-execute the original task node.

[0329] (4) Recovery due to excessive task size

[0330] If the failure is due to excessive task complexity, then: split the current task node, generate multiple child nodes, adjust dependencies, set the original task node's state to "already replaced," and stop further scheduling of the original task node.

[0331] (5) Result Conflict Recovery

[0332] If multiple agents produce conflicting results, then: generate a verification node, invoke the QA agent, compare multiple results, select a reliable result, or generate a fused result.

[0333] (6) Task interruption recovery

[0334] If a system restart, network interruption, user-initiated pause, or external execution environment anomaly occurs during task execution, the state recovery control module queries the most recent stable runtime state snapshot based on the task identifier in the long task execution instance, and restores the corresponding task graph version, task node state, agent state, tool state, context summary, memory index, completed results, and cost state. After recovery, the system recalculates the set of executable task nodes and continues to schedule agents to execute tasks based on the restored runtime state.

[0335] (7) Task map version rollback and recovery

[0336] If the evolution of the task graph leads to the continuous failure of subsequent tasks, the existence of dependency anomalies in the task graph, or a request to restore to a historical task graph version is received, the system determines the target task graph version based on the task graph version difference record object GraphDiff, and restores the task graph structure based on PreviousGraphVersion, CurrentGraphVersion, ChangedNodeSet, AddedNodeSet, RemovedNodeSet, ReplacedNodeSet, and ChangedEdgeSet in GraphDiff.

[0337] Simultaneously, the system locates the corresponding runtime state snapshot based on the SnapshotRef in GraphDiff, and restores the task node state, agent state, tool state, context summary, memory index, completed results, and cost state. After restoration, the system verifies the consistency of the task graph version, task node state, and task node dependencies, redetermines the set of executable task nodes, and continues task execution based on the restored runtime state.

[0338] Step S14: Shared memory update

[0339] The system determines which information needs to be written to shared memory based on the node execution results.

[0340] The information written into the shared memory includes: explicit user requirements, long-term project constraints, key technical solutions, verified conclusions, reasons for errors, successful execution strategies, agent performance, and tool availability records.

[0341] For low-value information, such as temporary logs, duplicate content, and invalid output, the system does not write them into long-term memory, but only stores them in short-term context.

[0342] Step S15: Determine the task completion conditions

[0343] The system determines whether the task is completed.

[0344] The completion conditions include: all necessary task nodes are in the Completed state, there are no unresolved high-priority failed nodes, the final output node has been generated, the user's goal has been met, the result has passed the evaluation rules, and there are no unresolved conflicts.

[0345] If the completion conditions are not met, return to step S4 to continue execution.

[0346] If the completion conditions are met, proceed to step S16.

[0347] Step S16: Generate the final result and save the execution trajectory

[0348] The results summary output module integrates the outputs of the necessary completed task nodes to generate the final result.

[0349] The final results include: user-readable results, task completion summary, key intermediate conclusions, agents used, major tool calls, final version of the task graph, important state changes, and exception handling records.

[0350] The system also saves the complete execution trajectory for subsequent auditing, review, and task recovery.

[0351] Preferably, such as Figure 4 As shown, the system can evolve the initial task graph V0 into multiple subsequent versions based on the runtime state. For example, in V1, a compliance review node is inserted based on new requirements; in V2, the code generation node is split into multiple child nodes based on task complexity; and in V3, the original test node is replaced with a verification test node based on the failure status. Each task graph evolution corresponds to the generation of a runtime state snapshot (Snapshot) and a task graph version difference record object (GraphDiff), which records version changes, changed nodes, changed dependency edges, and triggering reasons. By binding GraphDiff to the snapshot, the system can restore to the corresponding task graph version and runtime state when the task is interrupted, fails, or the user requests resumption.

[0352] Dynamic task graph evolution rules:

[0353] Rule 1: Rules for Adding New Task Nodes

[0354] When a task node outputs an incomplete target, and the similarity between that target and an existing task node is below a preset threshold, the system adds a new task node.

[0355] if NewGoalDetected == true and Similarity(NewGoal, ExistingNodes) < θ1:

[0356] AddNode(NewGoal)

[0357] Wherein, NewGoalDetected indicates whether a new incomplete target has been detected, NewGoal represents a new target, ExistingNodes represents the set of existing task nodes in the current task graph, Similarity represents the similarity calculation function, and θ1 represents the first preset similarity threshold.

[0358] Rule 2: Task Node Splitting Rules

[0359] When the complexity score of a task node exceeds the second preset threshold, the system splits the task node into multiple sub-task nodes and re-establishes the dependency edges in the task graph based on the dependency relationships between the sub-tasks.

[0360] The task node complexity score can be expressed as:

[0361] Complexity(Node) =

[0362] a1 × InputLength +

[0363] a2 × GoalCount +

[0364] a3 × ToolCount +

[0365] a4 × EstimatedTime +

[0366] a5 × HistoricalFailureRate

[0367] when:

[0368] When Complexity(Node) > θ2, the system performs a task node splitting operation.

[0369] Where InputLength represents the length of the input data, GoalCount represents the number of task objectives, ToolCount represents the number of tools required, EstimatedTime represents the estimated execution time, HistoricalFailureRate represents the failure rate of similar historical tasks, a1 to a5 are weight parameters, and θ2 represents the second preset complexity threshold.

[0370] Rule 3: Task Node Merging Rules

[0371] When the similarity of task objectives, inputs, and output types of two nodes all exceed the threshold, the system merges the nodes.

[0372] if GoalSimilarity(Ni, Nj) > θ3

[0373] and InputSimilarity(Ni, Nj) > θ4

[0374] and OutputTypeSimilarity(Ni, Nj) > θ5:

[0375] Merge(Ni, Nj)

[0376] Where Ni and Nj represent two task nodes in the current task graph, GoalSimilarity represents the similarity of task objectives, InputSimilarity represents the similarity of input data, OutputTypeSimilarity represents the similarity of output types, and θ3, θ4, and θ5 represent the corresponding preset similarity thresholds.

[0377] Rule 4: Failed Node Replacement Rule

[0378] When the number of failures of a task node exceeds the preset maximum number of retries, the system generates a replacement task node based on the reason for the failure and marks the original task node as replaced or abandoned.

[0379] The judgment condition can be expressed as:

[0380] if Node.RetryCount > MaxRetry:

[0381] FailureType = AnalyzeFailure(Node)

[0382] ReplacementNode = GenerateReplacementNode(Node, FailureType)

[0383] Replace(Node, ReplacementNode)

[0384] Wherein, RetryCount represents the number of times the task node failed, MaxRetry represents the maximum number of retries, FailureType represents the type of failure reason, and ReplacementNode represents the replacement task node generated based on the failure reason.

[0385] Rule 5: Dependency Edge Adjustment Rules

[0386] When the system detects that a task node is missing a necessary prerequisite result, it automatically generates a prerequisite task node and adds a dependency edge between the prerequisite task node and the current task node in the current task graph.

[0387] The judgment condition can be expressed as:

[0388] if MissingDependency(Node) == true:

[0389] PreNode = GenerateDependencyNode(Node)

[0390] AddEdge(PreNode, Node)

[0391] Here, MissingDependency indicates whether there is a missing dependency, PreNode represents the generated preceding task node, and AddEdge represents the newly added task dependency edge.

[0392] Rule Six: Verification Node Generation Rules

[0393] When the confidence level of the output result of a task node is lower than the preset confidence threshold, or when there is a conflict between the output results of multiple task nodes, the system generates a verification task node and adds the verification task node to the current task graph.

[0394] if Confidence(Result) < θ6 or ConflictDetected == true:

[0395] AddValidationNode(Result)

[0396] Where Confidence represents the confidence level of the result, Result represents the output result of the task node, ConflictDetected indicates whether a result conflict was detected, and θ6 represents the preset confidence threshold.

[0397] Rule 7: Context Compression Triggering Rule

[0398] When the context length, token consumption, or task round exceeds the corresponding preset threshold, the system triggers a context compression operation to compress the historical context into a structured summary, while retaining the task objective, key conclusions, user constraints, output results of preceding nodes, and a list of tasks to be executed.

[0399] if ContextLength > θ7 or TokenUsage > θ8 or TurnCount > θ9:

[0400] CompressContext()

[0401] Where ContextLength represents the context length, TokenUsage represents the token consumption, TurnCount represents the task execution rounds, and θ7, θ8, and θ9 represent the corresponding preset thresholds.

[0402] Task graph version difference recording and state snapshot binding mechanism:

[0403] To support task graph backtracking, exception recovery, and execution trajectory auditing during long task execution, the system generates a task graph version difference record object each time the task graph changes, and binds the task graph version difference record object to the corresponding runtime state snapshot.

[0404] Specifically, the system first assigns a task graph version difference record identifier to the task graph evolution operation and generates a task graph version difference record object; then it generates a runtime state snapshot corresponding to the changed task graph version and writes the task graph version difference record identifier into the runtime state snapshot; after the runtime state snapshot is generated, its snapshot identifier is written into the task graph version difference record object, thereby establishing the correspondence between the task graph version, the task graph version difference record object and the runtime state snapshot.

[0405] The task graph version difference record object (GraphDiff) includes: the task graph version before the change (PreviousGraphVersion), the task graph version after the change (CurrentGraphVersion), the set of task nodes that changed (ChangedNodeSet), the set of newly added task nodes (AddedNodeSet), the set of deleted task nodes (RemovedNodeSet), the set of replaced task nodes (ReplacedNodeSet), the set of dependent edges that changed (ChangedEdgeSet), the reason that triggered the task graph evolution (EvolutionTrigger), the identifier of the task node that triggered the evolution (TriggerNodeID), the runtime state when the evolution was triggered (TriggerRuntimeState), the runtime state snapshot reference bound to this task graph evolution (SnapshotRef), and the task graph change time (ChangeTime).

[0406] During task recovery, the system can locate the corresponding runtime state snapshot based on the SnapshotRef in the GraphDiff object and restore the task graph version according to PreviousGraphVersion or CurrentGraphVersion. Simultaneously, it restores or rolls back the task graph structure based on ChangedNodeSet, AddedNodeSet, RemovedNodeSet, ReplacedNodeSet, and ChangedEdgeSet. Through this mechanism, the system can bind changes in the task graph structure to changes in runtime state, enabling long-running tasks to recover to a stable, executable state after abnormal interruption.

[0407] A key feature of this invention is that the task graph does not change independently, and the runtime state is not recorded separately, but rather the two are linked. Specifically, this includes:

[0408] After a task node completes execution, its runtime state is updated.

[0409] After the runtime state changes, the task graph evolution judgment is triggered;

[0410] If the evolutionary conditions are met, then modify the task graph;

[0411] After the task graph is modified, a new version of the task graph is generated.

[0412] The new task graph version is written to the runtime state;

[0413] Runtime state is saved as a snapshot;

[0414] Subsequent agent scheduling is based on the new task graph and the new running state.

[0415] In other words, the present invention forms the following closed loop:

[0416] Task execution → State update → Evolution judgment → Task graph adjustment → Generate GraphDiff → Save RuntimeSnapshot → Bind GraphDiff and RuntimeSnapshot → Reschedule → Recovery in case of exception → Continue execution.

[0417] This closed loop enables the multi-agent system to continuously self-adjust during operation. Through this closed loop, the system can not only continuously adjust the task graph according to the runtime state, but also restore a consistent task graph structure and runtime state based on the task graph version differences, recorded objects, and runtime state snapshots when a task is interrupted, fails, or is resumed at the user's request.

[0418] Let's take the "Enterprise AI R&D Collaboration Platform" as an example:

[0419] The system is configured with the following agents: master agent, planning agent, research agent, coding agent, testing agent, document agent, and quality review agent.

[0420] User input task: Design and implement an enterprise AI assistant system that supports knowledge base question answering, file upload, vector retrieval, and access control.

[0421] The system generates an initial task graph:

[0422] N1: Requirements Analysis

[0423] N2: System Architecture Design

[0424] N3: Database Design

[0425] N4: Backend Interface Design

[0426] N5: Vector Retrieval Module Design

[0427] N6: File Upload Module Design

[0428] N7: Front-end Page Design

[0429] N8: Access Control Module Design

[0430] N9: System Test

[0431] N10: Deployment Documentation Generation

[0432] During execution, the research agent discovered the need to add a "sensitive information desensitization module." The system determined that the target did not exist in the current task graph, and therefore added a new node:

[0433] N11: Design of Sensitive Information Desensitization Module

[0434] And adjust dependencies:

[0435] N6 → N11 → N9

[0436] The subsequent coding agent failed repeatedly during the design of the N5 vector retrieval module. System analysis determined the failure to be due to "excessive task complexity," and therefore, this node was split into:

[0437] N5-1: Embedding Model Call Encapsulation

[0438] N5-2: Vector Database Writing

[0439] N5-3: Similarity Search Interface

[0440] N5-4: Reordering search results

[0441] The system marks the original node N5 as Replaced and generates a new task graph version V2.

[0442] When the test agent detects inconsistencies between the backend and frontend interface fields, the system generates a verification node:

[0443] N12: Consistency Verification of Front-end and Back-end Interface Fields

[0444] Finally, the system generates complete code, deployment documentation, and test reports based on the output of all completed necessary task nodes, and saves task graph evolution records and runtime state snapshots.

[0445] The difference between this invention and existing multi-agent task scheduling schemes is that existing schemes mainly revolve around the structured task decomposition of natural language requests, task graph generation, capability tag matching, agent registry center screening, and structured execution result generation. Their task graphs are mainly used to determine the task execution order and agent matching relationships.

[0446] This invention further utilizes the task graph as a dynamic control structure during the execution of long tasks, and uses runtime state objects as feedback for task graph evolution and state recovery. During task execution, the system continuously collects task node states, agent states, tool states, context states, memory states, exception states, and cost states, and triggers task graph evolution based on these runtime states. Each time the task graph changes, the system not only generates a new task graph version but also generates a task graph version difference record object, and binds this difference record object to a runtime state snapshot.

[0447] Therefore, this invention does not solve the ordinary task scheduling problem, but rather the problems of continuous evolution of task graph, maintenance of state consistency, task anomaly recovery, context compression, and execution trajectory tracing during the execution of complex and long tasks.

[0448] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for multi-agent dynamic task graph evolution and state recovery for long-running tasks, characterized in that, Including the following steps: M100 receives a user's long task request, establishes a long task execution instance and generates a unique task identifier. The long task execution instance is used to associate the user's target, task graph version set, runtime state object, runtime state snapshot set, task graph version difference record set, shared memory index and execution trajectory. M200 generates an initial task graph based on the long task execution instance, or loads a historical task graph version if a recoverable historical state exists, initializes a runtime state object, and saves an initial runtime state snapshot; the runtime state object includes a current task identifier, a current task graph version, a currently active task graph, a set of executable task nodes, a set of executing task nodes, a set of completed task nodes, a set of failed task nodes, a set of agent states, a set of tool states, a context cache, a memory index, an abnormal state, and a cost state; M300: Based on the dependencies between task nodes in the currently active task graph, determine the executable task nodes whose dependency conditions have been met, and construct a node execution context for each executable task node. The node execution context includes the current node task objective, the output results of the preceding task nodes, the user's original objective, the current task graph summary, relevant shared memory, relevant tool descriptions, current constraints, and output format requirements. M400 selects a target agent from the candidate agent set based on the capabilities required by the task node, the capabilities of the candidate agents, the degree of context matching, the degree of tool matching, historical execution results, current load, and recent failure status. It then locks the corresponding task node and assigns the target agent to the corresponding task node, which then executes the corresponding task node according to the node execution context. M500 collects the execution results of task nodes, updates the runtime state object, and updates the shared memory based on the execution results of task nodes. Based on the updated runtime state object, it determines whether the task graph evolution conditions are met. If the task graph evolution conditions are met, it performs at least one of the following operations on the currently effective task graph: adding task nodes, deleting task nodes, splitting task nodes, merging task nodes, replacing task nodes, adjusting dependency edges, generating verification task nodes, or rolling back the task graph, generating a new task graph version and a task graph version difference record object. M510. Generate a corresponding runtime state snapshot for the new task graph version, and establish a binding relationship between the task graph version difference record object and the runtime state snapshot; the task graph version difference record object records at least the task graph version before the change, the task graph version after the change, the set of changed task nodes, the set of changed dependency edges, the evolution triggering reason, the triggering task node, and the corresponding runtime state snapshot reference. M520: When a task node fails to execute, task execution is interrupted, task graph dependency is abnormal, or a state recovery request is received, the target task graph version and the corresponding runtime state snapshot are located according to the task identifier and the binding relationship. The task graph structure, task node state, agent state, tool state, context summary, memory index, completed results and cost state are restored. The consistency between the restored task graph structure and the runtime state is verified. The set of executable task nodes is re-determined, and agents are continued to be scheduled based on the restored runtime state. M600: When the currently active task graph meets the preset task completion conditions, integrate the output results of the completed necessary task nodes, generate the final result, and save the complete execution trajectory; the preset task completion conditions include the completion of necessary task nodes, the absence of unprocessed high-priority failed task nodes, the generation of the final output task node, and the absence of unprocessed task result conflicts.

2. The method for multi-agent dynamic task graph evolution and state recovery for long-duration task execution as described in claim 1, characterized in that: In step M200, based on the task identifier, user identifier, or task recovery request, query whether there is a historical task graph version and runtime state snapshot corresponding to the current long task execution instance; If a recoverable historical state exists, select the most recent stable runtime state snapshot from the recoverable historical state, load the task graph version corresponding to the stable runtime state snapshot, and restore the task node state, agent state, tool state, context summary, memory index, completed results, and cost state. If no recoverable historical state exists, an initial task graph is generated, the initial task graph is marked as the initial task graph version, and an initial runtime state snapshot is generated. The stable runtime state snapshot refers to a runtime state snapshot in which the task graph version corresponding to the snapshot is consistent with the task graph version recorded in the snapshot, the completed state of the executing task nodes has been solidified, the output results of the completed task nodes have been persisted, the incomplete tool calls have ended or have been marked as recoverable, and there are no unhandled dependency exceptions in the task graph.

3. The method for multi-agent dynamic task graph evolution and state recovery for long-duration task execution as described in claim 1, characterized in that: The task graph evolution conditions in step M500 include at least one of the following: When the execution result of a task node contains an unfinished target that does not exist in the current task graph, a new task node is generated and the corresponding dependency relationship is established; When the complexity score of a task node exceeds the preset complexity threshold, the task node is split into multiple sub-task nodes, and the dependencies between the sub-task nodes are re-established according to the execution order of the sub-task nodes. When the number of failed executions of a task node reaches a preset failure threshold, an alternative task node or recovery path is generated. When the output results of multiple task nodes meet the preset conflict judgment conditions, a verification task node is generated. When users add, delete, or modify task requirements during task execution, corresponding task nodes are added, deleted, or adjusted accordingly. When the token consumption, execution time, or tool call cost reaches the corresponding resource threshold, perform at least one of the following operations on the current task graph: merge task nodes, pause low-priority task nodes, replace agents, or compress context.

4. The method for multi-agent dynamic task graph evolution and state recovery for long-duration task execution according to claim 1, characterized in that: In step M510, the binding relationship between the task graph version difference record object and the runtime state snapshot is established, including: Generate a task graph version difference record identifier for this task graph evolution; generate a task graph version difference record object based on the task graph version before and after the change; generate a runtime state snapshot corresponding to the changed task graph version, and write the task graph version difference record identifier into the runtime state snapshot; write the snapshot identifier of the runtime state snapshot into the corresponding task graph version difference record object; save the correspondence between the task graph version, the task graph version difference record object, and the runtime state snapshot.

5. The method for multi-agent dynamic task graph evolution and state recovery for long-duration task execution according to claim 1, characterized in that: The runtime state snapshot is generated at at least one of the following times: after the initial task graph is generated, after the preset key task nodes are completed, after the task graph evolution is completed, before or after an abnormal event occurs, after the user modifies the task objective, and before the execution of a high-risk task node. The runtime state snapshot includes a snapshot identifier, the task identifier to which it belongs, the task graph version corresponding to the snapshot, the task node state set, the agent state set, the tool state set, the context summary, the memory index reference, the completed result reference, the abnormal state, the cost state, the task graph version difference record reference, the recovery state information, and the snapshot generation time; The runtime state snapshot is a state record formed by extracting preset state fields from the runtime state object, and does not include the runtime state snapshot set itself in the runtime state object.

6. The method for multi-agent dynamic task graph evolution and state recovery for long-duration task execution according to claim 1, characterized in that: In step M500, when a task node fails to execute, different recovery strategies are implemented based on the reason for the failure: If the failure is due to tool unavailability, interface timeout, or return an exception, mark the tool status as abnormal, query alternative tools, rebuild the tool call node, and suspend or replace the original node. If the failure is due to low agent output quality, consecutive failures, or failure to meet the evaluation rules, the agent's score is reduced, a new agent is selected, an alternative execution node is generated, and the node execution context is restored from the most recent stable runtime state snapshot consistent with the current task graph version. If the failure is due to insufficient context, then generate a memory retrieval node, generate a data supplementation node, write the supplementary results to the context cache, and re-execute the original task node; If the failure is due to excessive task complexity, then split the current task node, generate multiple child nodes, adjust the dependencies, set the original task node's state to be replaced, and stop further scheduling of the original task node. If the failure is due to conflicting results from multiple agents, a verification node is generated, the QA agent is invoked, and after comparing multiple results, a reliable result is selected or a fusion result is generated. If a system restart, network interruption, user-initiated pause, or external execution environment anomaly causes a failure during task execution, the most recent stable runtime state snapshot is queried based on the task identifier in the long task execution instance. After restoring the task graph version, task node state, agent state, tool state, context summary, memory index, completed results, and cost state corresponding to the snapshot, the set of executable task nodes is recalculated, and agents continue to be scheduled to execute tasks based on the restored runtime state. If the evolution of the task graph leads to the continuous failure of subsequent tasks, the existence of dependency anomalies in the task graph, or a request to restore to a historical task graph version is received, the target task graph version is determined based on the task graph version difference record object, and the task graph structure and runtime state are restored based on the runtime state snapshot bound to the target task graph version. After the restoration is completed, the consistency of the task graph version, task node state, and task node dependency relationship is verified, and the set of executable task nodes is re-determined.

7. The method for multi-agent dynamic task graph evolution and state recovery for long-duration task execution according to claim 1, characterized in that: The k-th task graph version is represented as a directed graph as follows: in, This represents the k-th task graph version. This represents the set of task nodes in the k-th task graph version. This represents the set of directed dependency edges between task nodes; The runtime execution state corresponding to the k-th task graph version is represented as follows: in, This indicates the allocation relationship between task nodes and intelligent agents. It represents the set of runtime states consisting of task node state, agent state, tool state, context state, exception state, and recovery state. Represents a set of memory indexes. Indicates cost status; When the task graph evolves from the k-th task graph version to the (k+1)-th task graph version, a corresponding task graph version difference record object and a runtime state snapshot are generated.

8. The method for multi-agent dynamic task graph evolution and state recovery for long-duration task execution according to claim 1, characterized in that: In step M400, the agent matching scoring method is as follows: Score(agent, node) = w1 × CapabilityMatch + w2 × ContextMatch + w3 × ToolMatch + w4 × SuccessRate - w5 × CurrentLoad - w6 × RecentFailure in: CapabilityMatch represents the degree of match between the agent's capabilities and the task requirements; ContextMatch represents the degree of matching between the agent's current context and the task context; ToolMatch represents the degree of match between the tools available to the agent and the tool requirements of the task; SuccessRate represents the agent's historical success rate; CurrentLoad represents the current load; RecentFailure indicates the number of recent failures; CapabilityMatch, ContextMatch, ToolMatch, SuccessRate, CurrentLoad, and RecentFailure are each normalized to a preset numerical range; to These are non-negative weight parameters; Before calculating the agent matching score, candidate agents that do not have the ability to enforce task nodes or access to necessary tools are excluded; when the highest agent matching score is lower than the preset admission threshold, at least one of the following is triggered: task splitting node, capability supplementing node, alternative tool node, or manual intervention request.

9. A multi-agent dynamic task graph evolution and state recovery system for long-running tasks, characterized in that, include: The long task instance management module is used to receive long task requests, create long task execution instances, and assign a unique task identifier to the long task execution instances. The task input parsing module is used to parse long task requests and generate structured task request objects; The dynamic task graph construction module is used to generate an initial task graph based on the structured task request object, and modify the currently effective task graph according to the task graph evolution operation generated by the task graph evolution decision module to generate a new task graph version. The agent capability modeling module is used to maintain the capabilities, callable tools, current load, and historical execution results of candidate agents. The multi-agent dynamic scheduling module is used to select target agents based on task node status, agent status, and tool status, lock executable task nodes, and assign target agents to corresponding task nodes. The runtime state management module is used to maintain the currently active task graph, task node state, agent state, tool state, context state, memory state, exception state, and cost state. The task graph evolution decision module is used to determine whether the task graph evolution conditions are met based on the runtime state, and when the task graph evolution conditions are met, it generates at least one task graph evolution operation, including adding task nodes, deleting task nodes, splitting task nodes, merging task nodes, replacing task nodes, adjusting dependency edges, generating verification task nodes, or rolling back the task graph. The Task Graph Version Difference Recording module is used to generate Task Graph Version Difference Recording objects when the task graph evolves. The state snapshot management module is used to generate corresponding runtime state snapshots for the initial task graph version and the evolved task graph version, and to establish a binding relationship between the task graph version difference record object and the runtime state snapshot. The state recovery control module is used to restore the target task graph version and its corresponding runtime state according to the binding relationship when the task execution fails, is interrupted, has a dependency exception, or a state recovery request is received; verify the consistency between the restored task graph structure and the runtime state; redetermine the set of executable task nodes; and continue to schedule the agent. The results summary and output module is used to summarize the execution results of the necessary completed task nodes and generate the final output when the currently effective task graph meets the preset task completion conditions.

10. The multi-agent dynamic task graph evolution and state recovery system for long-duration task execution according to claim 9, characterized in that, Also includes: The shared memory management module is used to update the short-term task context, medium-term task status, and long-term shared memory based on the execution results of task nodes. The context compression module is used to compress historical context into a structured summary when the context length, token consumption, or task execution rounds reach the corresponding preset thresholds. The fault analysis and recovery strategy module is used to determine the fault type based on tool abnormality, agent output abnormality, insufficient context, excessive task complexity, or conflicting task results, and generate recovery actions such as replacing the tool, replacing the agent, supplementing the context, splitting task nodes, generating alternative task nodes, or generating verification task nodes. The state recovery control module is used to restore the target task graph version and its corresponding runtime state based on the recovery actions generated by the fault analysis and recovery strategy module, or based on task execution interruption and state recovery requests.

Images