Method and device for generating revisable planning graph, electronic equipment, storage medium and computer program product

Abstract

This application discloses a method, apparatus, electronic device, storage medium, and computer program product for generating a revisable planning diagram, comprising: parsing task information to obtain task configuration data; constructing an initial revisable planning diagram based on the task configuration data; querying a preset external resource library to bind execution configuration metadata and decision basis information for each task node in the task node sequence; scheduling the execution of target task nodes and collecting task execution information; extracting a structured summary based on the task execution information and comparing the structured summary with the corresponding expected output; updating any target task node and scheduling the execution steps when any target task node fails; and obtaining the final revisable planning diagram when the quality judgment is passed. Thus, by constructing a revisable planning diagram that binds execution and decision information, and updating nodes and rescheduling them based on write-back information when quality fails, unified plan execution, precise local repair, and complete traceability are achieved.

Description

Technical Field

[0001] This application relates to the technical field of intelligent task planning, and more specifically, to a method, apparatus, electronic device, storage medium, and computer program product for generating a revisable planning diagram. Background Technology

[0002] With the development of high-throughput sequencing technology, public bioinformatics databases, and cloud computing platforms, bioinformatics research increasingly relies on multi-step, multi-tool, and multi-data source combined analysis processes, characterized by long toolchains, parameter sensitivity, and high reproducibility requirements.

[0003] In related technologies, static workflow engines (e.g., Snakemake or Nextflow) and general large language models are used to assist in execution. However, static workflow engines are difficult to cope with the dynamic process adjustment needs in exploratory scientific research tasks, while general large language models lack structured management of task dependencies, tool capabilities and execution status, making it difficult to stably advance to a reproducible and complete research.

[0004] The above solutions have the following drawbacks: the task plan lacks a planning diagram structure that allows for partial revision; there is no unified binding relationship between tool calls, literature knowledge, and platform interfaces, resulting in a disconnect between planning and execution; when a tool fails, it can only be retried as a whole, and it is impossible to accurately insert repair tasks; and there is a lack of complete traceability records, making it difficult to meet the requirements for scientific research reproduction and auditing. Summary of the Invention

[0005] In view of the above problems, this application proposes a method, apparatus, electronic device, storage medium and computer program product for generating revisable planning maps, which can solve the above problems.

[0006] In a first aspect, embodiments of this application provide a method for generating a revisable planning graph. The method includes: receiving task information and parsing the task information to obtain task configuration data; constructing an initial revisable planning graph based on the task configuration data; the initial revisable planning graph includes a sequence of task nodes, inter-node dependency logic, and dynamic revision status; querying a preset external resource library to bind execution configuration metadata and decision basis information to each task node in the task node sequence; scheduling the execution of target task nodes in the task node sequence, collecting task execution information, and writing the task execution information back to its corresponding task node; extracting a structured summary based on the task execution information, comparing the key indicators in the structured summary with the expected output in its corresponding task node, and determining the comparison result of the target task node; when the comparison result of any target task node is a quality judgment failure, updating any target task node, and returning to the execution steps to schedule the execution of target task nodes in the task node sequence, collecting task execution information, and writing the task execution information back to its corresponding task node; when the comparison result of the target task node is a quality judgment pass, obtaining the final revisable planning graph.

[0007] Secondly, embodiments of this application also provide an apparatus for generating a revisable planning diagram. The apparatus includes: a parsing module for receiving task information and parsing the task information to obtain task configuration data; a construction module for constructing an initial revisable planning diagram based on the task configuration data; the initial revisable planning diagram includes a sequence of task nodes, inter-node dependency logic, and dynamic revision status; a binding module for querying a preset external resource library to bind execution configuration metadata and decision-making basis information to each task node in the task node sequence; and an execution module for scheduling the execution of target task nodes in the task node sequence, collecting task execution information, and returning the task execution information to... The process involves several modules: a writing module to the corresponding task node; a comparison module to extract a structured summary based on task execution information, comparing key indicators in the structured summary with the expected output of the corresponding task node to determine the comparison result of the target task node; a first judgment module to update any target task node when the comparison result of any target task node is that the quality judgment fails, returning to the target task node in the execution step scheduling task node sequence for execution, collecting task execution information, and writing the task execution information back to its corresponding task node; and a second judgment module to obtain the final revisable planning map when the comparison result of the target task node is that the quality judgment passes.

[0008] Thirdly, embodiments of this application also provide an electronic device, including a processor, a memory, and one or more application programs; the one or more application programs are stored in the memory and configured to be executed by the processor to implement the above-described method for generating a revisable planning diagram.

[0009] Fourthly, embodiments of this application also provide a computer-readable storage medium storing program code, wherein the above-described method for generating a revisable planning diagram is executed when the program code is run by a processor.

[0010] Fifthly, embodiments of this application also provide a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer, cause the computer program product to perform the above-described method for generating a revisable planning diagram.

[0011] The technical solution provided in this application includes the following method: receiving task information and parsing the task information to obtain task configuration data; constructing an initial revisable planning graph based on the task configuration data; the initial revisable planning graph includes a task node sequence, inter-node dependency logic, and dynamic revision status; querying a preset external resource library to bind execution configuration metadata and decision basis information to each task node in the task node sequence; scheduling the execution of target task nodes in the task node sequence, collecting task execution information, and writing the task execution information back to its corresponding task node; extracting a structured summary based on the task execution information, comparing the key indicators in the structured summary with the expected output in its corresponding task node, and determining the comparison result of the target task node; when the comparison result of any target task node is that the quality judgment fails, updating any target task node, and returning to the execution step to schedule the execution of target task nodes in the task node sequence, collecting task execution information, and writing the task execution information back to its corresponding task node; when the comparison result of the target task node is that the quality judgment passes, obtaining the final revisable planning graph. Therefore, an initial revisable planning graph containing task node sequences, inter-node dependency logic, and dynamic revision status is constructed. Execution configuration metadata and decision-making basis information are bound to each task node, thereby establishing a unified binding relationship between tool calls, literature knowledge, and platform interfaces, solving the problem of disconnect between planning and execution. Furthermore, by collecting task execution information and writing it back to the corresponding task nodes, a structured summary is extracted based on the execution information and compared with the expected output. When the comparison result indicates that the quality judgment has failed, the target task node is updated and the execution scheduling steps are returned. This achieves partial revision of the task plan, avoiding overall retries. Moreover, the dynamic revision status and execution information write-back form a complete traceability record, meeting the requirements for reproducibility and auditing. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments and drawings obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0013] Figure 1 The illustration shows a flowchart of a method for generating a revisable planning diagram according to an embodiment of this application.

[0014] Figure 2 A schematic diagram of a revisable planning diagram generation device provided in an embodiment of this application is shown.

[0015] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown.

[0016] Figure 4 This illustration shows a schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of this application.

[0017] Figure 5 A schematic diagram of the structure of a computer program product provided in an embodiment of this application is shown. Detailed Implementation

[0018] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0024] With the continuous development of high-throughput sequencing technology, public bioinformatics databases, and cloud computing platforms, bioinformatics research increasingly relies on multi-step, multi-tool, and multi-data source combined analysis processes. In typical bioinformatics research scenarios, researchers often need to obtain sequences and metadata from public databases, and then sequentially call upon tools such as quality control, genome assembly, virus identification, functional annotation, host prediction, similarity clustering, structural variation detection, statistical analysis, and visualization, and cross-validate intermediate results with literature, database annotations, and domain knowledge.

[0025] The aforementioned process is characterized by long toolchains, large data volumes, sensitive parameters, heterogeneous result formats, and high repeatability requirements, placing high demands on task planning and execution management. Related technologies typically employ manual writing of Shell scripts, Python scripts, or R scripts; use static workflow engines such as Snakemake / Nextflow; manually submit tasks item by item on a web platform; and use general-purpose large language models to assist in generating code or interpreting results.

[0026] Among them, static workflow engines are suitable for established standard processes, but for exploratory research tasks, research objectives, data availability, tool failures, parameter adjustments, and interpretation of intermediate results often require dynamic modifications to the process, which static engines cannot adapt to. Although general large language models can generate suggestions, they usually lack structured management of task dependencies, tool capabilities, platform interfaces, execution status, and audit evidence, making it difficult to stably advance from natural language objectives to reproducible complete research.

[0027] Existing automated execution systems have the following shortcomings: First, task plans are mostly in the form of text lists or one-off plans, lacking an executable, verifiable, and locally revisable planning diagram structure; Second, there is a lack of unified binding relationships between tool calls and literature knowledge, platform interfaces, container environments, and output files, leading to a disconnect between planning and execution; Third, when a tool fails, data is missing, or results deviate from expectations, the system often can only retry the entire process or require manual redesign, failing to accurately insert repair tasks or generate alternative paths at affected nodes; Fourth, large-scale result files cannot all be included in the model context, causing automated execution systems to easily lose quantitative structure or make judgments based on fragmented information; Fifth, the lack of complete traceability records makes it difficult to meet the requirements of scientific research reproduction and auditing.

[0028] Therefore, how to construct an executable, revisable, and auditable task planning graph structure, and automatically complete data acquisition, tool selection, parameter setting, result verification, and report generation around this structure, is a technical problem that urgently needs to be solved in the current field.

[0029] Based on this, this application provides a method for generating a revisable planning map. The execution entity of this method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in the embodiments of this application: a server, a terminal, etc. In other words, the method for generating the revisable planning map can be executed by software or hardware installed on a terminal device or a server device. The software can be a blockchain platform. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0030] Please see Figure 1 , Figure 1 This illustration shows a flowchart of a method for generating a revisable planning diagram according to an embodiment of this application. Figure 1 As shown, the method may include steps 110 to 170.

[0031] In step 110, task information is received and parsed to obtain task configuration data.

[0032] In some implementations, the task information can be a description of the task objective in natural language input by the user. For example, the task information could be "reproduce the core findings of a bioinformatics study and generate a visualization report" or "perform unified quality control, batch correction, differential analysis and pathway enrichment on multiple publicly available expression matrices and generate a verifiable report."

[0033] In some implementations, the task configuration data can be structured data obtained by parsing task information, which may specifically include data source, target species, sample range, evaluation indicators, calculation budget, and delivery format.

[0034] The data source can be an identifier of the source of the data required for task execution, including but not limited to public database names, local file paths, API interface addresses, or data download links. The target species can be the name or taxonomic identifier of the biological species targeted by the task execution, including but not limited to the Latin name or commonly used Chinese name of the species. The sample range can be a limitation on the sample set covered by the task execution, including but not limited to the number of samples, sample grouping conditions, sample collection time, or sample storage number.

[0035] Evaluation metrics can be quantitative standards used to assess the quality or performance of task execution results, including but not limited to accuracy, recall, F1 score, AUC, P-value, or custom scoring rules. Computational budget can be the upper limit of computing resources allowed for task execution, including but not limited to the number of CPU cores, memory size, GPU model, execution time, or storage space. Delivery format can be the presentation format of the output results after task execution, including but not limited to file format, data format, chart type, or report template.

[0036] In step 120, an initial revisable planning graph is constructed based on the task configuration data; the initial revisable planning graph includes the task node sequence, the inter-node dependency logic, and the dynamic revision status.

[0037] The initial revisable planning graph can be a directed task graph generated based on task configuration data, containing a sequence of task nodes, inter-node dependencies, and dynamic revision status. The sequence of task nodes should include at least the nodes for data retrieval, quality control, tool selection, parameter determination, execution, statistical analysis, visualization, and report synthesis.

[0038] When subsequent tasks fail, deviate, or become blocked, the system can partially update the initial revisable planning map based on the execution feedback, rather than rebuilding a new revisable planning map.

[0039] Inter-node dependency logic refers to the execution order and data transfer relationships between the different types of task nodes mentioned above. This logic is generated based on structured constraints in the task configuration data, ensuring that the output of upstream nodes meets the input requirements of downstream nodes, and that all dependencies form a directed acyclic graph, thus avoiding execution deadlocks caused by circular dependencies.

[0040] Dynamic revision status can be metadata used to identify the current execution status and revision history of each task node in the initial revisable planning graph. This includes, but is not limited to: the node's execution status (e.g., ready, executing, completed, skipped, failed), quality assessment result, revision count, revision reason, and revised node configuration. This status is updated in real time during task execution and verification, and serves as the direct basis for triggering local graph revisions and continued scheduling.

[0041] Thus, the research objectives of natural language processing are transformed into directed task graphs containing specific nodes of different types, thereby automating and structuring task execution. Furthermore, the dependency logic between nodes ensures the correctness of the execution order and data consistency of different types of task nodes, avoiding execution failures caused by missing dependencies.

[0042] In step 130, a preset external resource library is queried to bind execution configuration metadata and decision basis information to each task node in the task node sequence.

[0043] In some implementations, the preset external resource library includes a preset execution resource library and a preset domain knowledge library.

[0044] The default execution resource repository can be a tool and platform resource registry. The platform resource registry uses the type of task node as the index key and stores the mapping relationship of candidate tools, APIs, container images, input / output data modes and versions.

[0045] Among them, the candidate tool can be computing software or script program that can be used to execute task nodes; the API can be an application programming interface that can be called and its calling method; the container image can be a containerized image file that encapsulates the tool's runtime environment; the input and output data pattern can be the input and output data format, field type and constraint of the tool or API; and the version can be the version identifier of the tool, API or container image.

[0046] The platform resource registry is used to retrieve matching candidate tools, APIs, container images, input / output data patterns, and versions based on the type of the task node before task execution, and to bind execution configuration metadata to the task node.

[0047] The pre-defined domain knowledge base can be literature knowledge or knowledge graph. The pre-defined domain knowledge base uses the type of task node as the search key and stores the relationship between evidence fragments, methodological basis and evaluation criteria.

[0048] Among them, the evidence fragments can be original text fragments or knowledge triples related to the task nodes in literature or knowledge graphs; the methodological basis can be the task execution methods, parameter configurations or technical routes recorded in literature or knowledge graphs; and the evaluation criteria can be the task result quality assessment indicators or judgment rules defined in literature or knowledge graphs.

[0049] The pre-defined domain knowledge base is used to retrieve matching evidence fragments, methodological basis, and evaluation criteria based on the type of task node before task execution, and to bind decision-making basis information to the task node.

[0050] Specifically, in some implementations, the step of querying a preset external resource library and binding execution configuration metadata and decision-making basis information to each task node in the task node sequence may also include the following steps: (1) Parse the task type label for each task node; (2) Based on the task type tag, retrieve the matching candidate computing entities, interface contracts and version identifiers in the preset execution resource library, and generate execution configuration metadata; (3) Based on task type tags, retrieve matching evidence fragments, methodological basis and evaluation criteria in the preset domain knowledge base to generate decision basis information; (4) Associate and bind the execution configuration metadata and decision basis information to the corresponding task nodes to form a node instance with complete execution capabilities and verification basis.

[0051] Task type tags can be inherent attributes generated when a task node is constructed during the initial revisionable planning graph, used to identify the node's functional category. Parsing task type tags can involve reading them from the task node's data structure, using them as unique search keys for subsequent retrieval of the preset execution resource library and preset domain knowledge base.

[0052] Candidate computing entities can be the candidate tools, APIs, and container images mentioned above; the interface contract can be the input / output data pattern; and the version identifier can be the version mentioned above.

[0053] Evidence fragments can be original text fragments or knowledge triples from literature knowledge or knowledge graphs; methodological basis can be task execution methods, parameter configurations, or technical routes; evaluation criteria can be task result quality assessment indicators or judgment rules.

[0054] The execution configuration metadata and decision basis information are written into the node data structure as extended attributes of the task node. The execution configuration metadata provides the task node with the computing resources and data pattern definition required for execution, and the decision basis information provides the task node with method support and result verification standards during the execution process. Together, they enable the task node to have complete execution capabilities and verification basis, forming a node instance that can be scheduled for execution.

[0055] In step 140, the target task node in the scheduled task node sequence is executed, and task execution information is collected and written back to its corresponding task node.

[0056] The target task node can be a specific task node that is dynamically selected from the task node sequence based on the current scheduling policy and node status, and is about to be executed. The target task node is an instantiated object of the task node sequence at the time of scheduling. Its task type label, execution configuration metadata, and decision basis information have all been bound, and it has complete execution capabilities.

[0057] Specifically, in some implementations, the method for generating the revisable planning map may further include: traversing the sequence of task nodes, filtering out candidate nodes whose current execution state is ready, and identifying them as target task nodes.

[0058] During the scheduling process, the status of the target task node is updated from ready to executing, and after execution, it is updated to completed, skipped, or failed based on the quality judgment result. The task execution information generated during its execution process will be written back to the node in real time as a direct basis for subsequent verification and revision.

[0059] Task execution information can be a set of objective data generated by task nodes during execution to support subsequent quality assessment and local graph revision. This includes, but is not limited to: commands called during task execution, runtime environment configuration, execution logs, resource consumption data, output file paths, and exit status codes.

[0060] Task execution information is collected in real time during task execution and written back to its corresponding task node, serving as a direct basis for subsequent extraction of structured summaries, quality assessment, and generation of repair nodes or alternative paths.

[0061] In step 150, a structured summary is extracted based on the task execution information. The key indicators in the structured summary are compared with the expected outputs in the corresponding task nodes to determine the comparison results of the target task node.

[0062] Structured summaries can be standardized datasets extracted from task execution information to characterize the quality of task execution results. They include multidimensional key indicators, which may include key performance indicators extracted from task execution logs, core result parameters parsed from output files, and efficiency indicators statistically derived from resource consumption data.

[0063] In another implementation, multidimensional key indicators may include the completeness ratio of task output, the fill rate of key fields, and the degree of deviation of numerical indicators from the expected range.

[0064] The expected output can be benchmark data generated based on the evaluation metrics and delivery format in the task configuration data, used to measure whether the task execution results meet the standards. This includes, but is not limited to: the target thresholds corresponding to the evaluation metrics, the key parameter ranges required by the delivery format, and the expected result parameters of the task nodes under ideal execution conditions.

[0065] Furthermore, in some embodiments, the method for generating the revisable planning map may further include the following steps: (1) Calculate the confidence score of the structured summary to obtain the execution confidence value of the target task node; (2) When the execution confidence value is lower than the preset confidence threshold, a preventive local graph revision is triggered. If the target task node has not yet been determined to have failed the quality judgment, an alternative path is generated in advance and mounted to the revisable planning graph.

[0066] The execution confidence value is calculated based on the multi-dimensional key indicators in the structured summary. Each key indicator is assigned a weight coefficient, and the weighted sum is normalized to the [0,1] interval to obtain the execution confidence value of the target task node.

[0067] The weighting coefficients can be pre-configured in a preset domain knowledge base and stored in association with task type tags to support differentiated scoring strategies for different task types.

[0068] The preset confidence threshold can be configured based on the importance of the task, resource constraints, or timeliness requirements. When the execution confidence value of the target task node is lower than the preset confidence threshold, the system determines that the node has potential execution risk. Even if the comparison results in subsequent steps have not yet been determined to be a quality failure, a preventative handling process should be triggered.

[0069] Based on the task type label of the target task node and the current execution context, the system searches the preset execution resource library for alternative computing entities or alternative execution paths that can complete the same task objective, and generates at least one alternative path. The alternative path contains at least one alternative task node, and the alternative task node carries independent execution configuration metadata and decision basis information.

[0070] Subsequently, the backup alternative path is attached to the revisable planning graph and exists in parallel with the target task node in a conditional activation manner; that is, when the target task node is finally determined to pass the quality assessment, the backup alternative path is not activated; when the target task node is finally determined to fail the quality assessment, the system can directly switch to the backup alternative path to continue scheduling without rebuilding the revision plan, thereby significantly reducing revision latency.

[0071] The results of preventative local graph revision operations and the generation of alternative paths are all recorded in the audit metadata, including the trigger time, confidence value, alternative path structure, and whether it is ultimately activated, to support subsequent execution process traceability and optimization.

[0072] Therefore, the results of preventive local graph revision operations and the generation of alternative paths are recorded in the audit metadata, including the trigger time, confidence value, alternative path structure, and whether it is ultimately activated, to support subsequent execution process traceability and optimization.

[0073] In step 160, when the comparison result of any target task node is that the quality judgment fails, the target task node is updated, and the execution of the target task node in the execution step scheduling task node sequence is returned. The task execution information is collected and written back to its corresponding task node.

[0074] A failure to pass the quality assessment can be attributed to a discrepancy between key metrics extracted from the structured summary and the pre-defined expected output of the target task node, exceeding the pre-defined quality tolerance range. Key metrics could include, for example, the completeness of the task output, accuracy scores, and coverage of key fields. Expected output can be written into the node attributes when binding execution configuration metadata to the task node.

[0075] In one implementation, updating any target task node includes at least one of the following: modifying the execution configuration metadata of any target task node, for example, replacing candidate computing entities, adjusting interface contract parameters, or updating version identifiers; modifying the decision basis information of any target task node, for example, supplementing new evidence fragments or updating evaluation criteria; updating the dynamic revision status of any target task node, marking it as pending re-execution, and writing this update operation into audit metadata, recording the update reason, update content, and update time.

[0076] It should be noted that the update operation only makes a local revision to any target task node itself, and does not affect other task nodes that have been judged to have passed the quality assessment in the revisable planning diagram, thus ensuring that the scope of the revision operation is minimized.

[0077] After updating any target task node, the system returns the scheduling process to the execution steps of the target task node. The return is not a full restart of the entire task node sequence, but based on the inter-node dependency logic in the revisable planning graph, only the nodes whose execution status is pending re-execution are added back to the scheduling queue, while the execution status of the remaining nodes remains unchanged.

[0078] After the target task node is updated, it is rescheduled for execution, and the system collects the task execution information of that node again. After collection, the task execution information is written back to the node attributes of its corresponding task node, overwriting or appending to the execution record of the previous round, so as to ensure that the node attributes always reflect the latest execution status.

[0079] The process continues until the target task node passes the quality assessment. Optionally, to prevent infinite loops, a maximum iteration threshold can be set. When the number of iterations exceeds the maximum iteration threshold, the target task node is marked as a revision failure, and manual intervention or a global replanning process is triggered to ensure the robustness of the system.

[0080] In some implementations, updating any target task node may further include the following steps: (1) Determine the failure type of any target task node. The failure type includes at least one of execution failure, output deviation and execution blocking. (2) Based on the failure type, perform a local graph revision operation on any target task node. The local graph revision operation includes: (3) When the failure type is execution failure, a repair node is generated. The repair node carries the corrective execution configuration metadata for the failure type and replaces any target task node. (4) When the failure type is output deviation, a correction node is inserted after any target task node. The correction node is used to compensate for the deviation output. (5) When the failure type is execution blocking, generate an alternative path in the revisable planning graph that bypasses any target task node. The alternative path contains at least one functionally equivalent alternative task node. (6) Update the dependency logic between affected task nodes and the dynamic revision status in the revisable planning diagram.

[0081] The failure type is determined based on the analysis of the task execution information of the target task node. If the task execution information contains abnormal interruption records, process crash logs, or interface call error codes, the failure type is determined to be execution failure, indicating that an unrecoverable runtime error occurred during the execution of the node, causing the task to fail to complete normally.

[0082] If the task execution information shows that the task has been completed normally, but there is a deviation between the key indicators extracted from the structured summary and the expected output that exceeds the quality tolerance range, then the failure type is determined to be output deviation, indicating that the execution process of this node is normal but the output result does not meet the quality requirements.

[0083] If the task execution information contains a timeout record, a resource lock contention log, or an upstream dependency not ready flag, the failure type is determined to be execution blocking, indicating that the node cannot continue execution due to external constraints.

[0084] It should be noted that the failure type can be at least one of the three situations mentioned above. When multiple failure types exist at the same time, the system can process them in the order of priority: execution failure, output deviation, and execution blocking.

[0085] When the failure type is execution failure, the system generates a repair node to replace any target task node. Root cause analysis is performed on the abnormal records in the task execution information to determine the specific reason for the execution failure, such as incompatible compute entity versions, incorrect interface contract parameters, or unavailable dependent services. Based on the failure type, matching candidate compute entities, interface contracts, and version identifiers are re-retrieved from the preset execution resource library to generate corrected execution configuration metadata for the failure type. The repair node is constructed using the corrected execution configuration metadata and replaces any target task node in the revisable planning graph. The repair node inherits the task objectives, node attributes, and dependencies of any target task node; only the execution configuration metadata changes.

[0086] When the failure type is output deviation, the system inserts a correction node after any target task node. First, based on the deviation between the key indicators in the structured summary and the expected output, the specific deviation items that need to be compensated are determined, such as completing missing fields, correcting numerical indicators, or converting content with incorrect formatting. Second, a correction node is constructed. The correction node takes the actual output of any target task node as input and the result that meets the expected output requirements after compensation processing as output. The correction node is also configured with corresponding execution configuration metadata and decision basis information. Finally, the correction node is inserted after any target task node in the revisable planning graph, and the dependency relationship between any target task node and its original successor node is updated, making the correction node an intermediate processing node between the two.

[0087] By inserting correction nodes instead of replacing the original nodes, the original execution record of any target task node can be preserved, which facilitates subsequent auditing and tracing, while avoiding unnecessary re-execution of nodes that have already been executed.

[0088] When the failure type is execution blocking, the system generates an alternative path to bypass any target task node in the revisable planning graph. First, it analyzes the root cause of the execution blocking of any target task node to determine whether the blocking can be resolved in the short term. If it is determined that the blocking cannot be resolved in the short term, the alternative path generation process is triggered. Second, based on the task objective of any target task node, it searches the preset execution resource library and preset domain knowledge library for backup execution schemes that can achieve the same or equivalent task objective, and constructs at least one alternative task node. The alternative task node is functionally equivalent to any target task node at the task objective level, but uses a different execution path or computation entity. Finally, the alternative path consisting of at least one alternative task node is attached to the revisable planning graph. The starting point of the alternative path is connected to the predecessor node of any target task node, and the ending point is connected to the successor node of any target task node, thereby structurally bypassing any blocked target task node and ensuring the continuity of overall task scheduling.

[0089] After completing any of the above partial graph revision operations, the system synchronously updates the dependency logic and dynamic revision status of the affected nodes in the revisable planning graph, recalculates the predecessor and successor node sets of the nodes affected by the revision operation, and updates the corresponding dependency edges; initializes the dynamic revision status of newly added repair nodes, correction nodes, or replacement task nodes to the pending execution state; updates the dynamic revision status of any target task node to the revised or bypassed state; and writes a complete record of this partial graph revision operation into audit metadata, including the revision trigger time, failure type, revision strategy type, changes in node structure and dependencies before and after the revision, to support full-process execution traceability.

[0090] In some implementations, updating any target task node may further include the following steps: (1) Based on the assessment of the scope of failure impact of any target task node, determine the revision granularity, which includes either node-level revision or subgraph-level revision; (2) When the revision granularity is node-level revision, only replace or repair any target task node; (3) When the revision granularity is subgraph level, the subgraph containing any target task node and its directly dependent nodes is reconstructed as a whole.

[0091] Based on the assessment of the failure impact scope of any target task node, the revision granularity is adaptively determined, including either node-level revision or subgraph-level revision. When the revision granularity is node-level, only the target task node itself is replaced or repaired; when the revision granularity is subgraph-level, the entire subgraph containing the target task node and its directly dependent nodes is reconstructed, thereby achieving a precise match between the revision scope and the failure impact scope.

[0092] Starting with any target task node, the algorithm expands outward along the dependency edges in the revisable planning graph, traversing adjacent nodes that have a direct dependency relationship with any target task node, including its predecessor and successor nodes. Next, an impact propagation analysis is performed on each adjacent node to determine whether the failure of any target task node will lead to missing input data, unmet execution preconditions, or invalid output results for adjacent nodes. Finally, the number of affected nodes and their positional distribution in the task node sequence are counted to obtain the impact range of any target task node's failure. The impact range can be quantified as the proportion of the number of affected nodes to the overall task node sequence. For example, when the number of affected nodes does not exceed a preset impact range threshold, the impact range is determined to be a local impact; when the number of affected nodes exceeds the preset impact range threshold, the impact range is determined to be a diffuse impact.

[0093] When the assessment result of the scope of failure is local, that is, the failure only affects the target task node itself and the execution preconditions of its directly dependent nodes are not violated, the revision granularity is determined to be node-level revision.

[0094] When the failure impact assessment result is a diffusion impact, that is, the failure of any target task node has resulted in the loss of input data or the failure to meet the execution preconditions of one or more of its directly dependent nodes, the revision granularity is determined to be a subgraph-level revision.

[0095] Through the above rules, the system can adaptively select the revision granularity according to the actual scope of the failure, avoiding the omission of affected nodes due to an excessively small revision scope, or the unnecessary reconstruction overhead due to an excessively large revision scope.

[0096] When the revision granularity is node-level, the revision operation only applies to any target task node itself. When any target task node fails due to incompatibility of execution configuration metadata, the matching candidate computing entity, interface contract and version identifier are re-retrieved from the preset execution resource library. A new node is built with the updated execution configuration metadata to replace any target task node. The new node inherits the task target, node attributes and dependencies of the original node.

[0097] When any target task node fails due to local parameter errors or insufficient decision-making information, without replacing the entire node, only the execution configuration metadata or decision-making information of that target task node is locally corrected, while the rest of the node's attributes remain unchanged.

[0098] Once a node-level revision is completed, the structure and dependencies of other nodes in the revisionable planning diagram remain unchanged, minimizing the impact of the revision.

[0099] When the revision granularity is at the subgraph level, the revision operation performs a comprehensive reconstruction of the subgraph containing any target task node and its directly dependent nodes. First, the boundary range of the subgraph is determined. The subgraph contains any target task node and all its predecessor and successor nodes that have direct dependencies. Second, the dependency logic and data flow between nodes in the subgraph are analyzed to identify the set of nodes in the subgraph whose state is abnormal due to the failure of any target task node. Then, the subgraph is reconstructed as a whole, including: replanning the task node sequence and the dependency logic between nodes in the subgraph, rebinding execution configuration metadata and decision basis information for the affected nodes, and uniformly updating the dynamic revision status of each node in the subgraph. The reconstructed subgraph is re-embedded into the revisable planning graph, and the dependency edges between the subgraph and its external nodes are updated to ensure the overall structural consistency of the revisable planning graph.

[0100] It should be noted that subgraph-level revisions only reconstruct nodes within the subgraph boundary; completed nodes outside the subgraph boundary remain unaffected, thus ensuring the integrity of the revision while controlling revision overhead.

[0101] In step 170, when the comparison result of the target task node is that the quality judgment is passed, the final revisable planning map is obtained.

[0102] The comparison result indicates that the quality judgment is passed. The key indicators extracted from the structured summary and the deviation between them and the preset expected output in the target task node do not exceed the preset quality tolerance range. That is, the actual output of the target task node meets the expected requirements in terms of quality standards.

[0103] It should be noted that the quality assessment is performed on each of the currently scheduled target task nodes one by one, rather than requiring all nodes in the task node sequence to complete the assessment simultaneously. After each target task node completes execution and passes the quality assessment, the system continues to schedule the next candidate node in the task node sequence that is in the ready execution state, until all task nodes in the task node sequence have completed execution and the comparison result shows that the quality assessment has passed.

[0104] The final revisable planning diagram maintains the same basic framework as the initial revisable planning diagram in terms of structure, that is, it still contains the sequence of task nodes, the dependency logic between nodes, and the dynamic revision status, but its content has undergone complete iterative revision and information write-back during the execution process.

[0105] For example, in terms of the task node sequence, each task node in the final revisable planning diagram has been executed, and its node attributes record the final task execution information, structured summary, and comparison results of passing the quality judgment; if a task node has undergone a revision operation during execution, its node attributes also record the configuration changes before and after the revision.

[0106] Regarding the inter-node dependency logic, if a local graph revision operation occurs during execution, such as inserting a correction node, generating an alternative path, or reconstructing a subgraph, the inter-node dependency logic in the final revisable planning graph has been updated synchronously to reflect the actual execution path.

[0107] Regarding the dynamic revision status, the dynamic revision status of each task node in the final revisable planning diagram has been updated to the completed status, indicating that the node has been executed and passed the quality assessment.

[0108] Regarding audit metadata, the audit metadata of the final revisable planning diagram fully records all revision operations that occur throughout the entire execution process, including the revision trigger time, failure type, revision strategy, changes in node structure before and after the revision, and the final execution result, which can serve as a complete credential for task execution.

[0109] Please see Figure 2 , Figure 2 This illustration shows a schematic diagram of a revisable planning diagram generation device according to an embodiment of this application. The revisable planning diagram generation device 200 includes: a parsing module 210, a construction module 220, a binding module 230, an execution module 240, a comparison module 250, a first determination module 260, and a second determination module 270. Specifically: The parsing module 210 is used to receive task information and parse the task information to obtain task configuration data; Module 220 is used to build an initial revisable planning graph based on task configuration data; the initial revisable planning graph includes a sequence of task nodes, inter-node dependency logic, and dynamic revision status; The binding module 230 is used to query a preset external resource library and bind execution configuration metadata and decision basis information to each task node in the task node sequence. The execution module 240 is used to schedule the execution of target task nodes in the task node sequence, collect task execution information, and write the task execution information back to its corresponding task node. The comparison module 250 is used to extract a structured summary based on task execution information, compare the key indicators in the structured summary with the expected output in the corresponding task node, and determine the comparison result of the target task node. The first judgment module 260 is used to update any target task node when the comparison result of any target task node is that the quality judgment is not passed, and return to the target task node in the execution step scheduling task node sequence for execution, and collect task execution information and write the task execution information back to its corresponding task node. The second judgment module 270 is used to obtain the final revisable planning map when the comparison result of the target task node is that the quality judgment is passed.

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0111] In the several embodiments provided in this application, the coupling or direct coupling or communication connection between the modules shown or discussed may be an indirect coupling or communication connection through some interface, device or module, and may be electrical, mechanical or other forms.

[0112] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0113] Please see Figure 3 , Figure 3 The diagram illustrates the structure of an electronic device according to an embodiment of this application. The electronic device 300 in this application may include one or more of the following components: a processor 310, a memory 320, and one or more application programs. The one or more application programs may be stored in the memory 320 and configured to be executed by one or more processors 310. The one or more programs are configured to execute the method for generating a revisable planning diagram as described in the foregoing method embodiments.

[0114] Processor 310 may include one or more processing cores. Processor 310 connects to various parts within the electronic device 300 using various interfaces and lines, and performs various functions and processes data of the electronic device 300 by running or executing instructions, programs, code sets, or instruction sets stored in memory 320, and by calling data stored in memory 320. Optionally, processor 310 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 310 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 310 and may be implemented separately using a communication chip.

[0115] The memory 320 may include random access memory (RAM) or read-only memory (ROM). The memory 320 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 320 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, etc. The data storage area may also store data created by the electronic device 300 during use.

[0116] Please see Figure 4 , Figure 4 The diagram illustrates the structure of a computer-readable storage medium 400 provided in an embodiment of this application. The computer-readable storage medium 400 stores program code, which can be called by a processor to execute the method for generating a revisable planning diagram as described in the above method embodiments.

[0117] The computer-readable storage medium 400 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 400 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 400 has storage space for program code 410 that performs any of the method steps described above. This program code can be read from or written to one or more computer program devices. The program code 410 may be compressed, for example, in a suitable form.

[0118] Please see Figure 5 , Figure 5 The diagram illustrates the structure of a computer program product according to an embodiment of this application. The computer program product includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer, cause the computer program product to perform the method for generating a revisable planning diagram as described in the foregoing method embodiments.

[0119] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for generating a revisable planning map, characterized in that, The method includes: Receive task information and parse the task information to obtain task configuration data; Based on the task configuration data, an initial revisable planning graph is constructed; the initial revisable planning graph includes a task node sequence, inter-node dependency logic, and dynamic revision status; Query the preset external resource library to bind execution configuration metadata and decision basis information for each task node in the task node sequence; The target task node in the task node sequence is scheduled to execute, and task execution information is collected and written back to its corresponding task node. Based on the task execution information, a structured summary is extracted, and the key indicators in the structured summary are compared with the expected outputs in the corresponding task nodes to determine the comparison result of the target task node. When the comparison result of any target task node is that the quality judgment fails, update the target task node, return to the execution step to schedule the target task node in the task node sequence to execute, collect task execution information, and write the task execution information back to its corresponding task node. When the comparison result of the target task node is that the quality judgment is passed, the final revisable planning map is obtained.

2. The method for generating a revisable planning map according to claim 1, characterized in that, The preset external resource library includes a preset execution resource library and a preset domain knowledge library; The steps involve querying a preset external resource library and binding execution configuration metadata and decision-making basis information to each task node in the task node sequence, including: Parse the task type label of each task node; Based on the task type tag, the matching candidate computing entity, interface contract and version identifier are retrieved from the preset execution resource library to generate the execution configuration metadata; Based on the task type tag, matching evidence fragments, methodological basis and evaluation criteria are retrieved from the preset domain knowledge base to generate the decision basis information; The execution configuration metadata and the decision basis information are associated and bound to the corresponding task nodes to form a node instance with complete execution capabilities and verification basis.

3. The method for generating a revisable planning map according to claim 1, characterized in that, The step of updating any of the target task nodes includes: Determine the failure type of any target task node, wherein the failure type includes at least one of execution failure, output deviation, and execution blocking; Based on the failure type, a local graph revision operation is performed on any of the target task nodes. The local graph revision operation includes: When the failure type is execution failure, a repair node is generated. The repair node carries the corrective execution configuration metadata for the failure type and replaces any of the target task nodes. When the failure type is output deviation, a correction node is inserted after any target task node. The correction node is used to compensate for the deviation output. When the failure type is execution blocking, an alternative path is generated in the revisable planning graph to bypass any of the target task nodes, and the alternative path contains at least one functionally equivalent alternative task node. Update the dependency logic and dynamic revision status between the affected task nodes in the revisable planning graph.

4. The method for generating a revisable planning map according to claim 1, characterized in that, The method further includes: The structured summary is scored with confidence to obtain the execution confidence value of the target task node; When the execution confidence value is lower than the preset confidence threshold, a preventive local graph revision is triggered. If the target task node has not yet been determined to have failed the quality assessment, an alternative path is generated in advance and attached to the revisable planning graph.

5. The method for generating a revisable planning map according to claim 1, characterized in that, The method further includes: Traverse the sequence of task nodes, filter out candidate nodes whose current execution state is ready, and determine them as the target task nodes.

6. The method for generating a revisable planning map according to claim 1, characterized in that, The method further includes: Based on the assessment of the failure impact scope of any of the target task nodes, the revision granularity is determined, which includes one of node-level revision and subgraph-level revision; When the revision granularity is node-level revision, only one of the target task nodes is replaced or repaired; When the revision granularity is a subgraph-level revision, the subgraph containing any of the target task nodes and their directly dependent nodes is reconstructed as a whole.

7. An apparatus for generating a revisable planning map, characterized in that, The device includes: The parsing module is used to receive task information and parse the task information to obtain task configuration data; A construction module is used to construct an initial revisable planning graph based on the task configuration data; the initial revisable planning graph includes a task node sequence, inter-node dependency logic, and dynamic revision status; The binding module is used to query a preset external resource library and bind execution configuration metadata and decision basis information to each task node in the task node sequence. The execution module is used to schedule the execution of target task nodes in the task node sequence, collect task execution information, and write the task execution information back to its corresponding task node. The comparison module is used to extract a structured summary based on the task execution information, compare the key indicators in the structured summary with the expected output in the corresponding task node, and determine the comparison result of the target task node. The first determination module is used to update any target task node when the comparison result of any target task node is that the quality determination fails, and return to the execution steps to schedule the target task node in the task node sequence to execute, and collect task execution information and write the task execution information back to its corresponding task node. The second determination module is used to obtain the final revisable planning map when the comparison result of the target task node is that the quality determination is passed.

8. An electronic device, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the method for generating a revisable planning map as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method for generating a revisable planning map as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program stored on a computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer program product to perform the method for generating a revisable planning map as described in any one of claims 1-6.

Images