A recoverable execution and anti-drift cooperative method for long-period AI tasks

Abstract

The application discloses a recoverable execution and anti-drift cooperative method for long-period AI tasks, comprising the following steps: identifying long task attributes according to a received AI task request, obtaining a task root directory, obtaining a task target and determining task definition; selecting a task target determined to be capable of supporting subsequent execution, performing task definition, and obtaining a task topology according to task plan splitting information to complete standardized anchor point initialization, obtain a task core anchor point, and then select a task type template and generate an execution checkpoint; executing or dispatching a current node task according to an allowed execution level to generate a task execution result and perform verification, obtaining a verification result and a task completion degree after performing degradation repair processing on a task scene that fails to pass acceptance, and performing task delivery, closing or continuing to run. The application comprehensively improves the overall stability and controllability of long tasks.

Description

Technical Field

[0001] This invention relates to the fields of AI intelligent agent engineering, automated research and development, and long-cycle task scheduling technology. Specifically, it relates to a recoverable execution and anti-drift collaborative method for long-cycle AI tasks. Background Technology

[0002] With AI programming tools and intelligent agents widely used in software development and various engineering scenarios, actual business tasks such as code refactoring, code migration, multi-round research, and version releases are often long-cycle, complex tasks involving multiple modules, roles, and iterations. These tasks commonly encounter complex situations such as session interruptions, context compression, tool timeouts, and additional requirements, placing higher demands on the continuity, stability, and controllability of AI task execution. Current mainstream AI clients and intelligent agent frameworks only focus on extending single-action execution capabilities, enabling basic operations such as file reading and writing, command execution, and parallel sub-agents. While solving the execution problem of single task actions, they lack a standardized management system for the entire long-cycle task process, resulting in several inherent flaws: First, the progress, objectives, boundaries, and execution logic of long tasks rely entirely on chat sessions. Changes, compression, or interruptions to the session make it impossible to stably restore the task state, easily leading to task deviations and rework. Secondly, the lack of pre-emptive clarification and boundary freezing mechanisms for task objectives makes it difficult to distinguish task confidence levels when faced with vague or incomplete initial user requirements, leading to high-cost and ineffective execution due to cognitive biases. Thirdly, existing multi-agent solutions only support simple parallelism and lack task topology discrimination and responsibility allocation mechanisms, resulting in blurred boundaries between single-task collaboration and multi-task coordination, leading to issues such as state confusion, conflicting results, and unclear recovery entry points. Fourthly, the lack of pre-task verification, timeout degradation, and delivery verification gates makes it impossible to identify abnormal working conditions such as agent timeouts, empty results, and semi-finished product delivery, easily leading to the judgment of unqualified results as completed, accumulating delivery risks. Fifthly, each mainstream AI client adopts an independent long-task management mechanism, lacking an industry-wide standard for long-task protocols, resulting in poor cross-platform adaptability, low reusability, and significant duplication of construction, making it difficult for existing AI technologies to stably, controllably, and in a standardized manner support the implementation of long-cycle and complex engineering tasks. Summary of the Invention

[0003] To address the aforementioned issues, the present invention aims to provide a recoverable execution and anti-drift collaborative method for long-cycle AI tasks. This method addresses the core problems of existing AI task execution technologies, which only solve the problem of single-action execution capability and lack a comprehensive system for target control, state accumulation, breakpoint recovery, collaborative constraints, result verification, and cross-platform adaptation for long-cycle tasks. As a result, long-cycle AI tasks suffer from weak stability, poor recoverability, chaotic collaboration, uncontrollable delivery, and high reuse costs, thus meeting the needs of implementing complex, long-cycle engineering tasks.

[0004] To achieve the above technical objectives, this application provides a recoverable execution and drift prevention collaborative method for long-cycle AI tasks, comprising the following steps: Based on the received AI task requests, identify the attributes of long tasks, obtain the task target and determine the task clarity by retrieving the task root directory; Select the task objectives that are determined to be able to support subsequent execution, define the task, and obtain the task topology based on the task plan breakdown information to complete the standardized anchor point initialization and obtain the core anchor point of the task. Based on the core anchor point of the task, select the task type template and generate the execution checkpoint. According to the allowed execution level, execute or dispatch the task of the current node to generate the task execution result. After verifying the task execution results and performing downgrade repair for task scenarios that fail to pass acceptance, the verification results and task completion status are obtained in order to execute task delivery, closure, or continuation.

[0005] Preferably, when identifying long task attributes, the long task attributes are identified based on whether the task has the core characteristics of a long task, such as continuous multi-round, cross-file, cross-module, multi-role participation, and interruptibility and recovery.

[0006] Preferably, when obtaining the task objective, the task objective is determined based on the core requirements of the task, expected output results, multi-dimensional candidate understandings, key points of ambiguity, default execution assumptions, risk of cognitive misinterpretation, and questions requiring user confirmation.

[0007] Preferably, when defining a task, the task definition is standardized and the core elements of the task are locked in, including the task objective, execution scope, non-objective content that is prohibited from execution, delivery success criteria, execution constraints, final deliverables, results verification methods, and execution risk level.

[0008] Preferably, when acquiring the task topology, the task execution topology type is determined based on the independence of the task delivery boundary, the independence of the execution leader, the independence of the interruption recovery entry point, and the independence of the result verification closing point, including: single task mode, multi-agent collaboration mode within the task, and multi-task collaborative operation mode.

[0009] Preferably, when obtaining the core anchor point of a task, if the task topology is a single task, the target discovery, task definition, task status and handover description are initialized in the same task root directory to obtain the core anchor point of the task. If the task topology is a collaborative operation, then a coordinating task root directory is created, and an independent task root directory and state anchor point are created for each member task to obtain the task core anchor point.

[0010] Preferably, when selecting a task type template, based on the core anchor point of the task, combined with the task definition, risk level, task business type, and client execution capability, a corresponding task type template is matched to break down long tasks into multiple lightweight, acceptable, and traceable execution checkpoints.

[0011] Preferably, when verifying the results of task execution, the existence, completeness, compliance, and compliance of the product are checked to verify the results of task execution.

[0012] Preferably, when performing downgrade repair processing, for verification failure scenarios, the actual failure reason is recorded and the corresponding downgrade repair strategy is matched, including any one of the following processing methods: small-scale retries, only collecting and retaining execution evidence, the person in charge taking over and reprocessing, returning to the task freeze stage for re-authorization, and waiting for user instruction confirmation, in order to perform downgrade repair processing.

[0013] Preferably, when performing task delivery, closure, or continuation, if all checkpoints pass acceptance, a final delivery description is automatically generated, and the task is closed. If the task has subsequent execution stages or incomplete nodes, update the handover document to clarify the execution content of the next session, the content that should not be repeated, the current remaining risks and execution precautions, and finally update the task status to complete, paused, blocked or pending.

[0014] The present invention discloses the following technical effects: This invention enables lossless recovery of long tasks across sessions and executors. It avoids demand drift losses by pre-fixing task objectives, strengthens collaborative management by isolating multi-agent collaborative states through task topology splitting, adds delivery verification checkpoints to ensure the reliability of output results, and reduces the cross-platform migration and transformation costs of various code clients by relying on platform-independent underlying protocols. It comprehensively improves the overall stability and controllability of long task execution, collaboration, delivery and cross-platform adaptation. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of the method described in this invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] like Figure 1 As shown, this invention provides a recoverable execution and anti-drift collaborative method for long-cycle AI tasks. This method achieves accurate identification, traceable execution, interruptible recovery, standardized delivery, and controllable anomaly handling for complex long tasks through standardized hierarchical execution processes, standardized task directory anchors, target freezing and confirmation mechanisms, structured checkpoint decomposition, multi-topology task collaboration adaptation, full-process verification access control and anomaly degradation, and closed-loop processing of branch scenarios. This significantly improves the standardization, stability, reusability, and delivery quality of long task processing.

[0019] In one embodiment, the present invention specifies the entire operational sequence of a long-cycle AI task from receiving, clarifying, freezing, executing, verifying to handing over, and during the execution process, the task objective and status must fall into a stable file; each advancement must have a checkpoint; and each delivery must pass through a verification gate.

[0020] In one embodiment, the present invention breaks down long tasks into several stable objects, and subsequent recovery, parallelization and verification are performed around these objects, as shown in Table 1.

[0021] Table 1. Core Objects and Descriptions for Long Tasks

[0022] S1. Receive task requests and identify long task attributes.

[0023] In one embodiment, by utilizing the received new user task requests, task instructions triggered by continuing, resuming or transferring existing tasks, and identifying whether the task has the core characteristics of a long task, such as continuous multi-round, cross-file, cross-module, multi-role participation, and interruptible recovery, ordinary one-time question and answer tasks and long-cycle tasks are distinguished; for requests determined to be long tasks, a long task start flag is generated and a complete original request record is retained to complete the admission determination of long tasks.

[0024] S2. Create or locate the task root directory.

[0025] In one implementation, based on the long task start flag or the user's historical task continuation instruction, a unique standardized task root directory is created for a brand new long task, and the existing task root directory is accurately located for restored historical long tasks. The task root directory is set as the only unified entry point for reading, restoring, verifying, and handing over long tasks, so as to realize the traceability and anchoring of the entire life cycle path of a single task. The unified directory specification is longtask / <task identifier> / .

[0026] S3. Perform Goal Discovery.

[0027] In one implementation, based on multi-dimensional contextual information such as the user's original requirements, associated files, code repository context, and historical handover records, the core requirements of the task, expected output results, multi-dimensional candidate understandings, key points of ambiguity, default execution assumptions, risks of cognitive misinterpretation, and questions requiring user confirmation are comprehensively sorted out and recorded to determine the clarity of execution. In this stage, only execution information reading, content sorting, and low-risk preparatory operations are allowed, while high-cost modification operations are prohibited. Finally, the GOAL_DISCOVERY.md target discovery document is generated and updated, and the task target clarity determination result is output simultaneously to clarify whether the target can support subsequent execution.

[0028] S4. Mission Freeze.

[0029] In one implementation, once the target discovery results are clear enough to support formal execution, or the user confirms the key boundaries of the task, the task freezing and authorization confirmation process is initiated; the task definition is standardized and the core elements of the task are locked, including the task objective, execution scope, prohibited non-objective content, delivery success criteria, execution constraints, final deliverables, results verification methods, and execution risk levels; for tasks with unresolved questions or unconfirmed boundaries, the task status is marked as draft or provisional, and high-risk execution permissions are prohibited; finally, the MISSION.md task definition document is generated and updated to solidify the compliant execution boundaries and status of the task.

[0030] S5. Determine the task topology.

[0031] In one implementation, based on task definition and task plan breakdown information, the task execution topology type is intelligently determined, specifically divided into three categories: single task mode, multi-agent collaboration mode within a task, and multi-task collaborative operation mode. The core criteria for determination are the independence of task delivery boundary, the independence of execution leader, the independence of interruption recovery entry point, and the independence of result verification closing point, providing topology basis for subsequent task initialization and collaborative dispatch.

[0032] S6. Initialize protocol anchor points and member tasks.

[0033] In one implementation, standardized anchor point initialization is performed based on the determined task topology type: for a single-task topology, four types of core anchor point files—target discovery, task definition, task status, and task handover—are initialized in a unified task root directory; for a multi-task collaborative operation topology, a top-level coordinating task root directory is built, and a dedicated independent root directory and status anchor point are configured for each independent member task; persistent and recoverable core task anchor points are uniformly generated, including GOAL_DISCOVERY.md, MISSION.md, TASK_STATE.json, and HANDOFF.md, to achieve full retention and traceability of task status.

[0034] S7. Select the task type template and generate execution checkpoints.

[0035] In one implementation, based on the core anchor point of the task, combined with the task definition, risk level, task business type, and client execution capabilities, a corresponding standardized task template is matched, covering mainstream task types such as ordinary coding, refactoring and migration, knowledge base construction, and document generation. Based on the matched template, the overall long task is broken down into multiple lightweight, acceptable, and traceable execution checkpoints. Each checkpoint clearly defines and solidifies the input conditions, core execution actions, product storage paths, and standardized acceptance methods. Finally, the complete checkpoint plan is written into the TASK_STATE.json plan file to form a structured and implementable execution plan.

[0036] S8, execute node tasks or dispatch node tasks to collaborators.

[0037] In one implementation, based on the current execution checkpoint and the allowed execution level, the task leader independently executes the current node task, or assigns standardized collaborators to sub-tasks with clear boundaries and independent responsibilities. The assignment process forcibly synchronizes the task objectives, execution scope, deliverable requirements, prohibited execution items, timeout handling mechanism, and result recovery path to prevent collaborators' cognitive biases, execution overstepping, and inability to collect results. The final output of the task execution results includes phased execution deliverables, execution evidence documents, command execution results, or collaborator feedback results.

[0038] S9. Perform access control verification and anomaly degradation.

[0039] In one implementation, a full-process verification access control mechanism is constructed to comprehensively verify the task execution results, focusing on verifying the existence, completeness, compliance, and achievement of standards of the products. It also checks whether necessary procedural commands have been executed or manual confirmation has been completed. For scenarios such as task timeouts, lack of valid results, production of only semi-finished products, or absence of standardized product paths, all are judged as acceptance failures, and the task is prohibited from being marked as completed. For verification failure scenarios, the actual reasons for failure are accurately recorded, and corresponding degradation and repair strategies are matched, including five processing methods: small-scale retries, collecting and retaining only execution evidence, responsible person taking over and reprocessing, returning to the task freeze stage for re-authorization, and waiting for user instruction confirmation. Clear verification results, failure tracing information, degradation strategies, and next execution actions are output to obtain verification results and task completion status.

[0040] S10, Task delivery, closure, or continuation processing.

[0041] In one implementation, closed-loop processing is completed based on the verification results and task completion: if all checkpoints pass the acceptance test, the final delivery instructions are automatically generated and the task is officially closed; if the task has subsequent execution stages or incomplete nodes, the HANDOFF.md handover document is updated to clarify the execution content of the next session, the content that should not be repeated, the current remaining risks and execution precautions, and finally the task status is updated to complete, paused, blocked or pending, thus achieving a closed loop for the entire task lifecycle.

[0042] In one embodiment, the present invention addresses the issues of process disruption, lack of clear processing guidelines, and uncontrollable risks by establishing standardized branching loop rules for long-running tasks with frequent anomalies and changes. Specifically, it includes five core branching mechanisms: 1. Closed-loop for unclear objectives: When the task objective is ambiguous or lacks clarity, directly return to the objective discovery stage and only perform low-risk operations such as user question completion, data reading, directory scanning, and risk assessment. Prohibit large-scale modification, iteration, and other high-risk execution actions to avoid ineffective rework from the source.

[0043] 2. Closed-loop for task boundary changes: When core boundaries such as task execution scope, delivery standards, and constraints change, the task is returned to the task freeze phase. The task scope, non-target items, successful acceptance standards, and execution authority levels are updated again. Then, the checkpoint plan is re-generated based on the updated task definition to ensure that the execution of the changed task is compliant and controllable.

[0044] 3. Multi-agent collaboration closed loop: When a task requires the participation of multiple agents, it is prioritized to determine whether it is a lightweight collaboration within the task or a cross-task collaborative operation mode. Only for member tasks with completely independent delivery, responsibilities, recovery and verification, a dedicated independent task root directory is created to avoid directory redundancy and state chaos, and to achieve hierarchical management of collaborative tasks.

[0045] 4. Collaborator Anomaly Closed Loop: For scenarios where collaborators time out or fail to return valid results, the true status of the task should be accurately recorded. False marking of task completion is strictly prohibited. Depending on the severity of the anomaly, the task scope should be narrowed down for retrying or the main person in charge should take over the execution directly to ensure the continuous progress of the task.

[0046] 5. Failure verification closed loop: All task nodes that fail access control verification are prohibited from entering the delivery and closing stage. Based on the specific reason for failure, they are returned to the corresponding checkpoint plan or execution stage for downgrade repair. Only after all nodes have passed verification can the final delivery, closing and task closure be completed, realizing a closed loop of quality throughout the entire process.

[0047] In summary, this invention achieves standardized management and control of the entire lifecycle of long tasks, from identification, initialization, authorization, decomposition, execution, verification to delivery, through a ten-level standardized layered process. This solves the problems of lack of standardization, anchor points, and traceability in the traditional execution of long tasks, and significantly improves the standardization of task processing.

[0048] This invention uses a target discovery and task freezing mechanism to lock in task boundaries in advance and avoid cognitive ambiguity, thereby reducing task rework, out-of-bounds execution, and invalid operations from the source and significantly improving the efficiency of long task execution.

[0049] This invention adapts to various execution scenarios such as single task, multi-agent collaboration, and multi-task coordination by classifying task topology and initializing differentiated anchor points, resulting in wider adaptability and clearer division of labor in collaboration.

[0050] The structured checkpoint decomposition, full-process verification access control, and multi-level anomaly degradation mechanism designed in this invention enable segmented task acceptance, controllable risks, and traceable anomalies, eliminating problems such as semi-finished product delivery and false completion, and ensuring delivery quality.

[0051] This invention designs a complete branching loop rule and handover retention mechanism, which supports task interruption recovery, change iteration, and cross-session continuation, greatly reducing the cost of handover, retry, and recovery of long tasks, and realizing the sustainable, closed-loop, and reusable processing of complex long tasks.

[0052] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0053] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A collaborative method for recoverable execution and anti-drift for long-cycle AI tasks, characterized in that, Includes the following steps: Based on the received AI task requests, identify the attributes of long tasks, obtain the task target and determine the task clarity by retrieving the task root directory; Select the task objectives that are determined to be able to support subsequent execution, define the task, and obtain the task topology based on the task plan breakdown information to complete the standardized anchor point initialization and obtain the core anchor point of the task. Based on the core anchor point of the task, select a task type template and generate an execution checkpoint. According to the allowed execution level, execute or dispatch the task of the current node to generate the task execution result. After verifying the task execution results and performing downgrade repair processing on task scenarios that fail to pass acceptance, the verification results and task completion status are obtained in order to execute task delivery, closure, or continuation.

2. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When identifying the attributes of long tasks, the attributes are identified based on whether the task has the core characteristics of a long task, such as continuous multi-round, cross-file, cross-module, multi-role participation, and interruptibility and recovery.

3. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When obtaining the task objective, the task objective is determined based on the core requirements of the task, expected output results, multi-dimensional candidate understandings, key points of ambiguity, default execution assumptions, risk of cognitive misinterpretation, and questions requiring user confirmation.

4. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When defining a task, standardize the task definition and lock in the core elements of the task, including the task objectives, scope of execution, prohibited non-objective content, delivery success criteria, execution constraints, final deliverables, results verification methods, and execution risk level.

5. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When acquiring the task topology, the task execution topology type is determined based on the independence of the task delivery boundary, the independence of the execution leader, the independence of the interruption recovery entry point, and the independence of the result verification closing point. This includes: single task mode, multi-agent collaboration mode within the task, and multi-task collaborative operation mode.

6. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When obtaining the core anchor point of a task, if the task topology is a single task, the target discovery, task definition, task status and handover description are initialized in the same task root directory to obtain the core anchor point of the task. If the task topology is a collaborative operation, then a coordinating task root directory is established, and an independent task root directory and status anchor point are established for each member task to obtain the task core anchor point.

7. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When selecting a task type template, based on the core anchor point of the task, combined with the task definition, risk level, task business type, and client execution capabilities, a corresponding task type template is matched to break down long tasks into multiple lightweight, acceptable, and traceable execution checkpoints.

8. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When verifying the results of task execution, the existence, completeness, compliance, and achievement of the product are checked to verify the results of task execution.

9. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When performing downgrade repair, for verification failure scenarios, record the actual failure reason and match the corresponding downgrade repair strategy, including any one of the following: small-scale retries, only collecting and retaining execution evidence, the person in charge taking over and reprocessing, returning to the task freeze stage for re-authorization, or waiting for user instruction confirmation, in order to perform downgrade repair.

10. The recoverable execution and anti-drift collaborative method for long-cycle AI tasks according to claim 1, characterized in that: When delivering, closing, or continuing a task, if all checkpoints pass inspection, a final delivery description is automatically generated, and the task is closed. If the task has subsequent execution stages or incomplete nodes, update the handover document to clarify the execution content of the next session, the content that should not be repeated, the current remaining risks and execution precautions, and finally update the task status to complete, paused, blocked or pending.

Images