Task orchestration method and apparatus

Abstract

This specification provides a task orchestration method and apparatus. The task orchestration method includes: obtaining a directed graph of tasks corresponding to a target task, wherein the target task includes multiple subtasks, each node in the directed graph is determined based on the semantics of each subtask, and directed edges are determined based on the execution order of each subtask; determining the relationships between nodes according to the directed graph, and determining the information processing strategy corresponding to each node based on the semantics of each subtask and the relationships between nodes; executing the target task based on the execution order of each subtask and the information processing strategy, and generating a target processing result corresponding to the target task. The task orchestration method provided in this specification can efficiently and accurately process long-term engineering tasks.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of artificial intelligence technology, and in particular to a task orchestration method and apparatus. Background Technology

[0002] With the continuous development of the field of artificial intelligence, people have increasingly higher requirements for the processing accuracy of intelligent units in scenarios involving complex and long-term engineering tasks.

[0003] In the process of compressing complex and long-term engineering tasks, at the context compression level, the misalignment between the context compression threshold trigger and the task semantic boundaries leads to critical decisions being easily interrupted midway. Coupled with a lack of global understanding, the compression quality is low, resulting in passive context management. Furthermore, in terms of task orchestration, incremental decomposition methods fail to identify global dependencies and parallel opportunities, leading to rigid task orchestration.

[0004] Therefore, how to use intelligent processing units to efficiently and accurately handle long-term engineering tasks has become an urgent problem to be solved. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a task orchestration method. One or more embodiments of this specification also relate to a task orchestration apparatus, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a task orchestration method is provided, comprising: Obtain the task-directed graph corresponding to the target task, wherein the target task includes multiple subtasks, each node in the task-directed graph is determined based on the semantics of each subtask, and the directed edges are determined based on the execution order between each subtask. The relationships between nodes are determined based on the directed graph of the task. The current node is identified among the nodes, and the current subtask corresponding to the current node and at least one successor node associated with the current node are obtained. The semantics of the successor subtasks corresponding to each successor node are determined. The merging semantics of the semantics of each successor subtask are determined, and the current semantic boundary corresponding to the current subtask is determined based on the merging semantics. The information processing strategy corresponding to the current node is determined based on the current semantic boundary, wherein the current node is any one of the nodes. The target task is executed based on the execution order and information processing strategy corresponding to each subtask, and the target processing result corresponding to the target task is generated.

[0007] According to a second aspect of the embodiments of this specification, a task execution method is provided, comprising: Receive task description information for tasks to be processed; Based on the task semantics of the task description information parsed by the orchestration intelligent processing unit, a task blueprint is determined. The task blueprint includes the decomposition and dependencies of each subtask represented by a directed graph, information processing strategies for the marker nodes of each subtask, pre-determined information retention, compression, and removal strategies for each marker node, and the expected output format specifications for each subtask. The information processing strategies are derived from the dependency analysis of subsequent subtasks on the current stage information. Specifically, the current node is determined among all nodes, and the current subtask corresponding to the current node and at least one subsequent node associated with the current node are obtained. The semantics of the subsequent subtasks corresponding to each subsequent node are determined. The merging semantics of the semantics of each subsequent subtask are determined, and based on the merging semantics, the current semantic boundary corresponding to the current subtask is determined. Based on the current semantic boundary, the information processing strategy corresponding to the current node is determined, where the current node is any one of the nodes. Based on the dependencies between subtasks in the task directed graph, the subtasks are distributed to one or more execution intelligent processing units. In response to the completion of each subtask, the processing result corresponding to the task to be processed is generated based on the information processing strategy according to each flag node.

[0008] According to a third aspect of the embodiments of this specification, a method for executing a cross-module refactoring task is provided, comprising: Obtain the directed graph of the cross-module refactoring task corresponding to the refactoring task, wherein the cross-module refactoring task includes multiple sub-tasks to be refactored, each node in the directed graph of the refactoring task is determined based on the semantics of the sub-tasks to be refactored, and the directed edges are determined based on the execution order between the sub-tasks to be refactored. Based on the directed graph of the task to be reconstructed, determine the relationships between nodes, identify the current node, obtain the current subtask corresponding to the current node and at least one successor node associated with the current node, determine the semantics of the successor subtasks corresponding to each successor node, determine the merging semantics of the semantics of each successor subtask, and based on the merging semantics, determine the current semantic boundary corresponding to the current subtask; based on the current semantic boundary, determine the information processing strategy corresponding to the current node, wherein the current node is any one of the nodes; The cross-module reconstruction task is executed based on the execution order and information processing strategy of each subtask to be reconstructed, and the target processing result corresponding to the cross-module reconstruction task is generated.

[0009] According to a fourth aspect of the embodiments of this specification, a task orchestration apparatus is provided, comprising: The acquisition unit is configured to acquire the task directed graph corresponding to the target task, wherein the target task includes multiple subtasks, each node in the task directed graph is determined based on the semantics of the subtasks corresponding to each subtask, and the directed edges are determined based on the execution order between the subtasks. The determining unit is configured to determine the association relationships between nodes based on the task directed graph, determine the current node among the nodes, obtain the current subtask corresponding to the current node and at least one successor node associated with the current node, determine the semantics of the successor subtasks corresponding to each successor node, determine the merging semantics of the semantics of each successor subtask, and determine the current semantic boundary corresponding to the current subtask based on the merging semantics; and determine the information processing strategy corresponding to the current node based on the current semantic boundary, wherein the current node is any one of the nodes; The processing unit is configured to execute the target task based on the execution order of each subtask and the information processing strategy, and generate the target processing result corresponding to the target task.

[0010] According to a fifth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above method.

[0011] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0012] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0013] According to one embodiment provided in this specification, the execution order between subtasks is automatically obtained through a directed task graph, and information processing strategies are automatically determined based on semantics and relationships, avoiding the need for manual configuration of data transfer rules for each task. This improves execution efficiency and fully utilizes parallel resources. Furthermore, by analyzing the merging semantics of successor nodes to determine how the current node processes information, the current node can proactively discard or compress unnecessary downstream data, avoiding the transmission of redundant information in the task chain and reducing network and storage overhead. In addition, the directed task graph clearly identifies subtasks that can be executed in parallel, allowing multiple subtasks to be scheduled to different execution units simultaneously during orchestration, shortening completion time. The task orchestration method provided in this specification efficiently and accurately handles long-term engineering tasks. Attached Figure Description

[0014] Figure 1 A flowchart of a task orchestration method according to an embodiment of this specification is shown; Figure 2 A flowchart is shown for another task orchestration method provided according to one embodiment of this specification; Figure 3 A flowchart illustrating a task orchestration and execution process according to an embodiment of this specification is shown; Figure 4 An architecture diagram of a task orchestration method provided according to an embodiment of this specification is shown; Figure 5 A flowchart illustrating the processing procedure of a task orchestration method provided in one embodiment of this specification is shown. Figure 6 This specification shows a schematic diagram of the structure of a task orchestration apparatus according to one embodiment; Figure 7 This specification illustrates an architecture diagram of a task orchestration system provided in one embodiment. Figure 8 A structural block diagram of a computing device according to an embodiment of this application is shown. Detailed Implementation

[0015] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0016] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0017] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0018] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0019] In one or more embodiments of this specification, a large model refers to a deep learning model with a large number of model parameters, typically containing hundreds of millions, tens of billions, hundreds of billions, trillions, or even tens of trillions of model parameters. A large model can also be called a foundation model. It is pre-trained using large-scale unlabeled corpora to produce a pre-trained model with hundreds of millions of parameters. Such models can adapt to a wide range of downstream tasks and have good generalization ability. Examples include Large Language Models (LLMs) and multi-modal pre-training models.

[0020] In practical applications, large models only require a small number of samples to fine-tune the pre-trained model before they can be applied to different tasks. Large models can be widely used in fields such as Natural Language Processing (NLP) and Computer Vision. Specifically, they can be applied to computer vision tasks such as Visual Question Answering (VQA), Image Captioning (IC), and Image Generation, as well as NLP tasks such as text-based sentiment classification, text summarization, and machine translation. The main application scenarios for large models include digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0021] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0022] The orchestration intelligent processing unit (Spec-Leader Agent) is the core scheduling intelligent agent responsible for global task analysis, execution blueprint generation, execution monitoring, and experience accumulation. In this specification, the orchestration intelligent processing unit is used to distribute the target task to the corresponding execution intelligent processing unit based on the task attribute information of the target task and its corresponding directed task graph.

[0023] The Execution Intelligent Processing Unit (Worker Agent), also known as the Worker Intelligent Processing Unit or the Second Intelligent Processing Unit, is a subordinate intelligent processing unit used to receive sub-tasks and execute specific operations. In this specification, the Execution Intelligent Processing Unit is used to receive the sub-tasks distributed by the Orchestration Intelligent Processing Unit based on the target task and to process each sub-task.

[0024] A roadbook is a structured description that includes task decomposition, dependencies, information processing strategies, acceptance criteria, and error recovery plans. In this specification, a roadbook can be understood as a task blueprint used to construct a directed graph of tasks.

[0025] Context Window: A limited inference context resource for large language models; the maximum information capacity that an LLM can process in a single inference iteration.

[0026] Compression points can be understood as the trigger locations for semantic boundary-aware context compression, pre-planned context compression execution points at the semantic boundaries of the task. In this specification, compression points can be understood as markers for compression based on semantic boundaries when the information processing strategy is an information compression strategy.

[0027] MapReduce delegation can be understood as a multi-agent task delegation and result merging based on a divide-and-conquer-aggregate model, distributing complex tasks to multiple executing agents for parallel processing and then summarizing the results. In this specification, the target task is delegated to multiple executing intelligent processing units according to the orchestration intelligent processing unit.

[0028] Layered self-healing can be understood as a hierarchical error detection, recovery, and escalation mechanism, where local errors are self-corrected by the executing agent, and cross-task errors are coordinated and recovered by the orchestration and control agent. In this specification, layered self-healing can be understood as the process of self-healing based on the abnormal situation when an anomaly occurs during the execution of the target task or its subtasks.

[0029] Compound interest precipitation can be understood as a two-layer granularity mechanism for accumulating and reusing execution experience, used for macro-precipitation blueprint template strategies, and for micro-precipitation of verifiable atomic capability units.

[0030] A capability atom can be understood as a verifiable atomic capability unit, which is the smallest reusable functional unit that is automatically extracted during execution and verified.

[0031] The experience base can be understood as a structured execution experience knowledge base, used to store historical blueprint templates and atomic capabilities in a persistent retrieval storage.

[0032] Intelligent Processing Unit: An automated processing system with a Large Language Model (LLM) as the core reasoning engine, combined with memory mechanisms, planning capabilities, and tool usage capabilities.

[0033] With the continuous development of artificial intelligence technology, people have increasingly higher requirements for the processing efficiency and accuracy of intelligent processing units in handling long-term engineering tasks.

[0034] The complexity of long-term engineering tasks stems from several factors: Long-term dependencies: An error in one subtask can trigger a domino effect, impacting all subsequent tasks. For example, choosing the wrong data structure early on can lead to the rewriting of all subsequent algorithms and interfaces. A rapidly expanding search space: Each step involves countless possible actions. Without domain knowledge and value judgment, the agent can become lost among numerous possible code modification paths. Ambiguous feedback and delayed rewards: The correctness of an action (such as modifying a line of configuration) may not be known until tens of minutes later during system testing. This delay makes it difficult for the agent to attribute "final failure" to "an initial action." Real-world constraints: Engineering tasks must adhere to hard constraints such as API rate limits, file permissions, cost budgets, and concurrency control.

[0035] In scenarios where large language model agents are used to perform complex, long-term engineering tasks, a passive, reactive strategy is typically employed to manage the context window to avoid contextual redundancy. For example, context compression is performed when context resource utilization approaches a threshold. However, this approach suffers from a misalignment between the compression trigger point and the task's semantic boundaries. Consequently, the context may be forcibly truncated midway through a critical decision-making process, leading to the loss of decision information. Furthermore, due to a lack of global awareness of subsequent tasks, it is difficult to determine which information in the current context can be compressed. This results in either retaining a large amount of useless information that consumes valuable resources or mistakenly deleting crucial pre-existing information for later stages.

[0036] Furthermore, in executing complex, long-term engineering tasks, multi-agent orchestration is often employed. However, this process typically uses an incremental strategy of "execute one step, decompose one step," failing to identify dependencies and parallel opportunities between subtasks from a global perspective, leading to serial bottlenecks and dependency conflicts. Additionally, the use of predefined, fixed process templates (such as software development SOPs) prevents dynamic adjustments to decomposition strategies and execution paths based on the specific characteristics of the task. Moreover, the lack of pre-planning of rollback points and recovery paths forces ad-hoc decisions after errors occur, potentially wasting significant amounts of completed work.

[0037] Furthermore, each agent starts from scratch during task execution, lacking the ability to accumulate and reuse experience across tasks, thus wasting significant inference resources. Valuable outputs generated during execution, such as verified code snippets, verification rules, and test cases, are lost along with the context and cannot be reused in subsequent tasks. Valuable experiences such as problems encountered during execution, the repair strategies adopted, and the final results are not recorded in a structured manner, and the same errors may recur in subsequent tasks.

[0038] In summary, there is a lack of proactive, forward-looking, and accumulative agent architectures in scenarios where multiple agents are executing complex long-term engineering tasks.

[0039] To address these issues, a common approach is to have multiple agents collaborate through conversational messaging, with the dialogue flow driving task execution. Alternatively, predefined standard operating procedures (such as requirements analysis, design, coding, and testing) can be used, with tasks assigned to specific roles. Context management can also be likened to virtual memory in an operating system, where agents autonomously decide how to load and swap information at runtime. Another approach is to use an LLM (Local Management Model) to break down tasks into a list of subtasks, schedule their execution sequentially, and then aggregate the results. Yet another approach is to periodically save system checkpoints, rolling back to the most recent checkpoint for re-execution in case of anomalies.

[0040] However, at the context management level, the reactive management approach leads to a misalignment between compression timing and semantic boundaries, resulting in the accidental deletion of critical information. At the task planning level, it either lacks planning (conversational approach), uses static templates, or employs shallow decomposition (linear lists), none of which can generate a deep, integrated execution blueprint. At the error recovery level, it either lacks a mechanism or is designed for general fault tolerance (unsuitable for the nondeterministic nature of LLM), both lacking pre-planned layered recovery strategies. At the experience accumulation level, all execution is stateless, lacking the ability to accumulate and reuse experience across tasks.

[0041] Therefore, this specification provides a method for orchestrating long-term engineering tasks using an orchestration execution intelligent processing unit and delegating them to multiple execution intelligent processing units. The aim is to obtain the relationships between nodes in the directed task graph corresponding to the target task, and to use the directed task graph so that the subtasks represented by each node can learn the overall processing method of the target task. Furthermore, based on the relationships between nodes, corresponding information processing strategies are assigned to each task, improving the processing efficiency and accuracy of the target task. This specification provides a task orchestration method, and also relates to a task orchestration device, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail in the following embodiments.

[0042] It should be understood that the intelligent agent involved in this scheme is also called an intelligent processing unit. The two terms are used interchangeably, but their meanings should be understood to be consistent.

[0043] See Figure 1 , Figure 1 A flowchart of a task orchestration method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0044] Step 102: Obtain the task-directed graph corresponding to the target task, wherein the target task includes multiple subtasks, each node in the task-directed graph is determined based on the semantics of the subtasks corresponding to each subtask, and the directed edges are determined based on the execution order between the subtasks.

[0045] The target task can be understood as a long-term engineering task that needs to be orchestrated and executed, consisting of multiple sub-tasks. Examples include software development projects and data analysis pipelines.

[0046] A task-directed graph can be understood as a graph structure constructed based on the task semantics of a long-term engineering task. It consists of subtasks as nodes and the execution order between subtasks as directed edges, and is used to visually represent the dependencies and parallel relationships between subtasks.

[0047] A subtask can be understood as the smallest unit of execution that constitutes the target task. It's important to understand that in a directed task graph, all subtasks together form the overall target task.

[0048] Subtask semantics can be understood as the descriptive information or meaning of a subtask, which may include function, input / output, business domain, operation type, etc., and is used to analyze the logical relationships between various subtasks. It is important to understand that the subtask semantics corresponding to each subtask in this specification are obtained based on the overall semantic analysis of the target task.

[0049] A directed edge can be understood as an arrow connecting two nodes, with the direction indicating the execution order constraint. For example, "A→B" means that A must be completed before B can be executed.

[0050] The execution order can be understood as the sequence of subtasks, including two types: serial (must wait for the previous one to complete) and parallel (can be executed simultaneously).

[0051] In one specific embodiment provided in this specification, the target task of a long-term project is input, and a directed task graph is determined based on the target task. In the directed task graph, nodes are determined based on subtask semantics, and directed edges are determined based on the execution order.

[0052] It should be understood that the directed graph corresponding to the target task mentioned in this specification can be a historical directed graph that matches the task attribute information determined based on the target task's task attribute information. Alternatively, the directed graph of the target task can be a pre-constructed directed graph based on the target task.

[0053] In one example, the complete task directed graph could be generated in one go by a single orchestration intelligence processing unit. In another example, the blueprint could be generated collaboratively by the orchestration intelligence processing unit and a dedicated analytics intelligence processing unit (two-stage generation). In yet another example, a coarse-grained task directed graph framework could be generated first, and the final task directed graph could be generated incrementally during execution.

[0054] The task attribute information includes at least the task semantics, task theme, task structure, and the number of task subgraphs that can be obtained from the decomposition. The historical task directed graph can be a task directed graph that is completely matched based on the task attribute information, or it can be a task directed graph obtained by making simple adjustments to the historical task directed graph.

[0055] For ease of understanding, this manual uses the term "task directed graph" to describe the construction method of the task directed graph, which is based on the target task and is constructed in advance.

[0056] In one specific embodiment provided in this specification, the task-directed graph is constructed in the following manner: The full task semantics corresponding to the target task are parsed to obtain multiple subtasks, and the subtask semantics and topological order corresponding to each subtask are determined.

[0057] The full task semantics can be understood as the overall description information of the target task. Based on the overall description information of the target task, multiple sub-tasks can be obtained. The natural language description of each sub-task can represent the full task semantics of the target task.

[0058] Topological order can be understood as the linear ordering of nodes in a directed acyclic graph, such that each directed edge points from the node at the beginning of the order to the node at the end of the order. In this specification, it refers to the logical order of subtasks.

[0059] In one specific embodiment provided in this specification, a complete description of the target task is received, and multiple independent subtasks are obtained from the complete description of the target task through natural language processing or other methods. At the same time, the semantics of each subtask are extracted, and the topological order corresponding to each subtask is obtained according to the input-output relationship between the subtasks.

[0060] In one specific implementation, the full task semantics corresponding to the target task are parsed to generate a task blueprint. This task blueprint serves as a roadmap for the subsequent generation of a directed task graph. Specifically, the task blueprint includes the decomposition and dependencies of each subtask represented by the directed task graph; information processing strategies for the marker nodes of each subtask, wherein the information processing strategies are obtained based on the dependency analysis of subsequent subtasks on the information of the current stage, and include pre-determined information retention, compression, and removal strategies for each marker node; the expected output format specifications for each subtask; the stage acceptance criteria for each subtask; and error recovery plans for critical subtask nodes, wherein the error recovery plans include rollback recovery point definitions and recovery strategy selection rules, etc.

[0061] Based on the semantics of each subtask, the semantic relationships between the subtasks are determined.

[0062] Semantic relationships can be understood as whether two subtasks have dependencies or influences on each other in terms of functionality, data flow, or business logic. If they are related, they may need to be performed sequentially; otherwise, they can be performed in parallel. For example, semantic relationships can be understood as the decomposition and dependencies between the subtasks involved in the task blueprint.

[0063] In one specific implementation provided in this specification, the semantic relationships between any two subtasks are analyzed in terms of function, business domain, or data logic. This is to facilitate determining the execution order of the subtasks based on their semantic relationships.

[0064] Based on semantic relationships and the topological order of each subtask, the execution order among the subtasks is determined.

[0065] In one specific implementation provided in this specification, the execution order of each subtask is determined based on the topological order, semantic association, etc., corresponding to the subtasks.

[0066] In one example, if two subtasks are adjacent in topological order and semantically unrelated, then the two subtasks can be executed in parallel.

[0067] In another example, if two subtasks are adjacent in the topological order and semantically related, it can be understood that the two subtasks can be executed sequentially.

[0068] It is important to understand that for non-adjacent subtasks, the execution order of the subtasks can be determined by the transitivity between them.

[0069] In one specific embodiment provided in this specification, the execution order of each subtask is determined based on semantic relationships and the topological order corresponding to each subtask, including: Based on the topological order corresponding to each subtask, determine the first and second subtasks that are topologically adjacent, and determine the semantic association between the first and second subtasks; When there is no semantic association, the execution order between the first subtask and the second subtask is determined to be parallel execution. If the semantic relationship is related, the execution order between the first subtask and the second subtask is determined to be sequential.

[0070] In this context, topological adjacency can be understood as two subtasks that are adjacent in position within the topological order, namely the preceding position and the following position.

[0071] In one specific implementation provided in this specification, each pair of adjacent subtasks is sequentially extracted from the constructed topological order. The one preceding the other is called the first subtask, and the one following is called the second subtask. Then, semantic analysis (such as keyword matching, domain knowledge base, and predefined rules) is used to determine whether there is a business or logical relationship between the two subtasks. For example, the Boolean values ​​or enumeration values ​​of each node can be used to determine whether they are related or not. In one case, if the determination result is "not related," it means that the two subtasks are independent in terms of function, data, and resources, and can be executed simultaneously without conflict or error. Therefore, the scheduling system marks them as parallel execution, that is, no directed edge is added, or they are allowed to be assigned to different execution intelligent processing units to run simultaneously. In another case, if the determination result is "related," it means that there is a dependency between the two subtasks (for example, the second subtask needs to use the output of the first subtask, or both operate on the same data), and they must be executed sequentially according to the topological order. Therefore, the scheduling system marks them as serial execution, that is, a directed edge from the first subtask to the second subtask is added to the task directed graph.

[0072] It should be understood that this specification only judges subtasks that are adjacent in order; the order of non-adjacent tasks may be determined by transitivity.

[0073] According to a specific implementation provided in this specification, automatic calculation based on topological order and semantic relationships reduces the human cost of orchestrating large-scale tasks. Sequential execution is only enforced when there is a semantic relationship, avoiding performance degradation due to overly conservative (all tasks executed sequentially). Simultaneously, tasks that are semantically unrelated are allowed to execute in parallel, even if they are adjacent in the topological order, thereby maximizing parallelism. The topological order already implicitly contains data dependencies; further fine-grained adjustments based on semantic relationships do not disrupt necessary data order while releasing unnecessary constraints.

[0074] Given the execution order of each subtask as described above, we construct a task directed graph by treating each subtask as a node and the execution order between each subtask as a directed edge.

[0075] In one specific embodiment provided in this specification, subtasks are extracted from the overall description of the target task, the semantics of each subtask are extracted, and a preliminary topological order (e.g., based on input-output dependencies) is determined. The semantic relevance of each pair of subtasks is analyzed. Combining these two pieces of information, it is determined which subtasks must be executed sequentially and which can be executed in parallel. A graph structure is drawn, with subtasks as nodes and the execution order as directed edges.

[0076] According to a specific implementation provided in this specification, subtasks are automatically split and semantic relationships are extracted by parsing the semantics of the entire task, eliminating the need for manual definition of dependencies. Simultaneously, the execution order is determined using topological order (reflecting inherent data flow) and semantic relationships (reflecting business logic relevance), avoiding concurrency errors caused by functional coupling. When two subtasks are adjacent in the topological order and semantically unrelated, they are determined to be executable in parallel, thereby compressing the overall execution time and improving resource utilization. Using nodes to represent subtasks and directed edges to represent order constraints, the output DAG can be directly used for parallel task allocation, resource scheduling, and dynamic intervention, supporting incremental merging and fault recovery.

[0077] It's important to understand that each node in the directed graph of a task includes its own corresponding node attribute information. This node attribute information can include metadata such as node identifier (i.e., the topological order of the node), task type, resource requirements, estimated execution time, and input / output data locations. The attribute information for each directed edge is also determined, including the labeled dependency type (data dependency, control dependency), data transfer volume, and the reason for sequential execution. After topologically sorting the DAG, all nodes with an in-degree of 0 (no predecessors) can be executed in parallel. When a node finishes execution, the in-degree of its successor nodes is decremented by 1, and the new set of nodes with an in-degree of 0 forms a parallelizable set again.

[0078] In one specific embodiment provided in this specification, based on the obtained task directed graph, each node in the task directed graph is assigned its own corresponding information processing strategy.

[0079] Step 104: Determine the relationships between nodes based on the task directed graph, and determine the information processing strategy corresponding to each node based on the semantics of each subtask and the relationships between nodes.

[0080] The information processing strategy can be understood as the data or context processing method adopted for subtasks, such as retaining all information, compressing information, removing information, etc., which is used to control the amount of information transmitted during task execution. The information processing strategy of the current node is determined based on the merging semantics of the successor nodes, and the current node is any one of the nodes.

[0081] In one specific implementation provided in this specification, the connection relationships between nodes in the directed graph of the analysis task (whether there are edges and the direction of the edges) are analyzed, and combined with the semantic information of each subtask, a corresponding information processing strategy is assigned to each node (subtask).

[0082] In one example, the information processing strategy for each node could be, for example, information retention, compression, or removal.

[0083] In a specific embodiment provided in this specification, based on the semantics of each subtask and the correlation between each node, the information processing strategy corresponding to each node is determined, including S1042-S1046: S1042. Obtain the current subtask corresponding to the current node and at least one successor node associated with the current node, and determine the semantics of the successor subtask corresponding to each successor node, wherein the current node is any one of the nodes.

[0084] Here, the current node can be understood as any node in the directed task graph that is being processed.

[0085] A successor node can be understood as a node that can be directly reached from the current node through a directed edge in a directed graph. In other words, it is the task that must be executed after the current node has completed its task.

[0086] The semantics of a successor subtask can be understood as the semantic description of the subtask corresponding to each successor node.

[0087] In one specific implementation provided in this specification, a node is randomly selected from the directed graph of the task as the current node. The node pointed to by the directed edge originating from the current node (i.e., the direct successor node) is determined. If the current node has no successor node, a default strategy (such as information preservation) is adopted. For each successor node, its corresponding subtask semantics are read. These subtask semantics can be obtained from a task description library, metadata, or real-time parsing; this specification does not limit their specificity.

[0088] S1044. Determine the merging semantics of each subsequent subtask, and based on the merging semantics, determine the current semantic boundary corresponding to the current subtask.

[0089] In this context, merging semantics can be understood as the overall semantic features obtained by merging the semantics of multiple successor subtasks (e.g., taking the union, intersection, or logical combination). Merging semantics reflects the information needs that are commonly required or embodied by all successor tasks of the current node.

[0090] The current semantic boundary can be understood as the information processing scope or upper limit defined for the current subtask based on the merging semantics of subsequent tasks, determining which information (global, partial, or excluded) the current task needs to focus on. The semantic boundary can be global information, partial information, or independent information. For example, the semantic boundary can be the preceding word segment in the current subtask used for segmentation. If the current subtask has 10 words, then the current semantic boundary could be the first 8 words.

[0091] In one specific embodiment provided in this specification, multiple subsequent semantics are merged into a general description, and then it is determined whether the current subtask should process global information, partial information, or independent information.

[0092] In one example, all subsequent subtask semantics are merged. The merging method can be any one of A)-C): A): Take the union of all subsequent semantics: If a subsequent task requires multiple different types of information, then merge the semantics into "global information".

[0093] B): Take the intersection or common part of all subsequent semantics: If subsequent tasks all require a certain part of common information, then merge the semantics into "partial information".

[0094] C): If subsequent tasks are independent of each other and have no information transfer requirement with the current task, then the combined semantics are "independent information".

[0095] In one specific embodiment provided in this specification, determining the current semantic boundary corresponding to the current subtask based on the merging semantics includes: When the merged semantics are global information, the current semantic boundary corresponding to the current subtask is determined as the global lexical information of the current subtask; In the case where the merged semantics are partial information, the current semantic boundary corresponding to the current subtask is determined to be part of the lexical information of the current subtask; When the merged semantics are independent information, the current semantic boundary corresponding to the current subtask is determined as the removed lexical information of the current subtask.

[0096] Global lexical information can be understood as all the original information required by the subtask (such as complete input data and all fields).

[0097] Partial lexical information can be understood as partial information required by the subtask (such as key fields after filtering or summarization).

[0098] Removing lexical information can be understood as removing or ignoring information that is not needed by the subtask.

[0099] In one specific implementation provided in this specification, if the merged semantics are global information, then the current semantic boundary is determined to be global lexical information (the current task requires all data). If the merged semantics are partial information, then the current semantic boundary is determined to be partial lexical information (the current task only needs partial data). If the merged semantics are independent information, then the current semantic boundary is determined to be the current semantic boundary, which is the removal of lexical information (the current task should not carry any irrelevant data and can be considered as executing independently).

[0100] In one example, based on the merge information, the semantic boundaries of the current subtask are determined according to the type of merge semantics. Specifically, this is A)-C): A): When the merged semantics is "global information", the current semantic boundary is "global lexical information" (requiring all original information).

[0101] B): When the merged semantics is "partial information", the current semantic boundary is "partial word information" (only the filtered key information is needed).

[0102] C): When the merging semantics is "independent information", the current semantic boundary is "removing lexical information" (no information needs to be transmitted, and the current task can be executed independently).

[0103] According to a specific implementation provided in this specification, merging semantics are divided into different types, and fundamentally different types are mapped to different semantic boundaries, making the information processing strategy more granular and precise. Furthermore, the semantic boundaries are entirely driven by the merging semantics of subsequent tasks, eliminating the need for manual specification of how much information each task should output. When the downstream task set changes, the boundaries are automatically recalculated, ensuring continuous optimization of information transmission. In addition, when the merging semantics are "partial information" or "independent information," unnecessary terms are actively removed or compressed, reducing the amount of data transmitted between tasks and minimizing the waste of computing resources. The semantic boundaries determine the size of the data output by the tasks; different scheduling methods can be used to predict network load and storage requirements, thereby more rationally allocating bandwidth and cache resources.

[0104] S1046. Based on the current semantic boundary, determine the information processing strategy corresponding to the current node.

[0105] In one specific implementation provided in this specification, semantic boundaries are mapped to specific information processing strategies (removal, compression, retention).

[0106] In one example, the context compression trigger position is determined based on the current semantic boundary, thereby determining the information processing strategy corresponding to the current node.

[0107] Based on the current semantic boundary, determine the information processing strategy corresponding to the current node, including: When the current semantic boundary is to remove lexical information, the information processing strategy corresponding to the current node is determined to be an information removal strategy; When the current semantic boundary is part of lexical information, the information processing strategy corresponding to the current node is determined to be an information compression strategy; When the current semantic boundary is global lexical information, the information processing strategy corresponding to the current node is determined to be an information retention strategy.

[0108] The information removal strategy can be understood as discarding certain unnecessary information when executing subtasks in order to reduce transmission and storage overhead.

[0109] Information compression strategies can be understood as summarizing, aggregating, or compressing information to retain core content while reducing data volume.

[0110] Information retention strategy can be understood as retaining all original information completely without any reduction.

[0111] In one example, the information processing strategy could be a compression strategy based on static rules. For instance, a mapping table of retain / compress / discard can be obtained by pre-setting information types.

[0112] In another example, the information processing strategy could be, for instance, a compression strategy based on dynamic scoring. For example, calculating a "subsequent dependency probability" score for each piece of contextual information.

[0113] In another example, the information processing strategy could be a compression strategy based on information entropy. For instance, calculating information density and prioritizing the compression of low-density information.

[0114] It should be understood that this specification does not limit the processing method of the information processing strategy involved. Furthermore, the information processing strategy can also be determined based on any combination of the above examples. Further, when the information processing strategy is an information compression strategy, this specification determines the compression points based on semantic boundaries, for example, determining which lexical unit to compress. Then, the information compression strategy is executed based on the determined compression points.

[0115] According to a specific implementation method provided in this specification, the semantic requirements of subsequent tasks are analyzed to determine how the current task should process information. This allows the current task to proactively discard or compress data that is not needed downstream, avoiding the transmission of redundant information in the task chain and reducing network and storage overhead. Since the semantic boundary is calculated in real time based on the actual subsequent nodes, the information processing strategy is automatically recalculated when the task directed graph changes (such as adding, deleting, or modifying subsequent tasks), without the need for manual adjustment. Dynamic decision-making based on task semantics is more intelligent and accurate, balancing correctness and efficiency.

[0116] Furthermore, in one specific embodiment provided in this specification, the method further includes: If the current node has no successor node, the information processing strategy corresponding to the current node is determined to be an information retention strategy.

[0117] In one specific implementation provided in this specification, if the current subtask is the last task (without a successor), there is a possibility that a final result needs to be produced. In this case, all information is retained to avoid information loss due to arbitrary removal or compression.

[0118] According to a specific implementation provided in this specification, the end node typically produces the final output or key summary data of the entire task orchestration process. An information retention strategy is enforced to avoid missing or incorrect results due to accidental compression or removal. For nodes without successor nodes, no complex analysis (such as merging semantics or successor requirements) is required; the information retention strategy is directly adopted, reducing algorithm complexity and computational overhead.

[0119] Step 106: Execute the target task based on the execution order and information processing strategy corresponding to each subtask, and generate the target processing result corresponding to the target task.

[0120] The target processing result can be understood as the overall result obtained by summarizing all subtasks after they have been executed in the order of execution and according to the information processing strategy.

[0121] In one specific embodiment provided in this specification, each subtask is executed sequentially or simultaneously according to the execution order (serial or parallel) defined in the task directed graph, and its corresponding information processing strategy is applied when executing each subtask, thereby obtaining the overall processing result of the target task.

[0122] In one specific embodiment provided in this specification, the target task is executed based on the execution order of each subtask and the information processing strategy to generate the target processing result corresponding to the target task, including: Distribute each subtask to the corresponding execution intelligent processing unit; Based on the execution order of each subtask, the information processing strategy corresponding to each subtask is executed in each execution intelligent processing unit to generate the target processing result corresponding to the target task.

[0123] The execution intelligent processing unit can be understood as a computing entity that can independently execute subtasks, such as threads, containers, servers, etc.

[0124] In one specific embodiment provided in this specification, each subtask is assigned to a specific execution unit based on the resource scheduling results. The subtasks are executed in the order of the directed graph (parallel or serial), and a previously determined information processing strategy is applied during the execution of each subtask. Finally, the results of the target task are obtained by summarizing the results.

[0125] In one example, based on the execution order determined in the task directed graph and the resource scheduling results, MapReduce delegation is used to assign each subtask to a corresponding intelligent processing unit (such as a local working tree, a remote container, or a dedicated server) to facilitate the aggregation of processing results from each intelligent processing unit. The following conditions must be met when distributing each subtask to its corresponding intelligent processing unit: Dependency: A subtask is only dispatched when all its predecessor tasks have been completed (or there is no need to wait).

[0126] Resource matching: The resource requirements (CPU, memory, GPU, data location) of the subtask are matched with the capabilities of the execution unit.

[0127] Load balancing: Avoid distributing a large number of tasks to the same unit.

[0128] Based on the above conditions, subtasks are initiated in each execution intelligent processing unit according to the execution order (serial or parallel) defined by the task directed graph. During execution, each subtask must apply its predefined information processing strategy. For example, if the strategy is information retention, the subtask produces all original information and passes it completely to the subsequent task or the final result; if the strategy is information compression, the subtask filters, aggregates, or summarizes the produced information, passing only the necessary parts; if the strategy is information removal, the subtask does not pass any information downstream (or the downstream ignores its output). Communication between execution intelligent processing units may be necessary (e.g., passing intermediate results), but the content of the communication is constrained by the information processing strategy. After all subtasks have been executed, the retained information of each terminal node (without a successor node) and the necessary intermediate results are summarized to form the final target processing result.

[0129] In one example, the way subtasks are distributed to their corresponding execution intelligent processing units could be, for example, pure parallel distribution, where all independent subtasks execute simultaneously; pipelined distribution, where partial output of a previous subtask triggers subsequent subtasks; or hybrid distribution, where the critical path is serial and the non-critical path is parallel.

[0130] The methods for determining critical and non-critical paths include, for example, based on execution order or their association with the target task. This specification does not limit these methods.

[0131] According to a specific implementation provided in this specification, by distributing subtasks to multiple execution intelligent processing units and executing them strictly according to the execution order (allowing parallel processing), multi-core and multi-machine resources can be fully utilized to reduce the completion time of the target task. Information processing strategies are dynamically applied during the execution phase without modifying the business logic of the subtasks themselves. Strategy changes (such as changing from compression to retention) only affect information transmission and do not affect task functionality, facilitating optimization and adaptation to different scenarios. Information compression and removal strategies take effect during execution, effectively reducing the amount of data transmitted across units and the size of persistent intermediate results, making it particularly suitable for bandwidth-constrained or storage-sensitive environments. After distribution, each subtask runs in an independent unit, and the orchestration agent can monitor the execution status of each unit in real time. When a failure or timeout occurs, only the affected subtasks can be reassigned without affecting completed units.

[0132] In view of this, based on the above, in a specific embodiment provided in this specification, during the process of generating the target processing result corresponding to the target task, in order to avoid abnormal situations in the information processing process, the processing results corresponding to each sub-task are accepted and judged according to the acceptance judgment conditions involved in the roadmap. Specifically, the method further includes: Detect the execution status of the corresponding subtasks at each node; If a pending subtask is in a fault state, the pending subtask is repaired based on its fault level.

[0133] The execution status can be understood as the running status of the subtask, such as in progress, completed, faulty, timed out, etc.

[0134] A fault state can be understood as a state where the execution of a subtask fails or cannot continue.

[0135] Fault level can be understood as the scope or type of impact of a fault, such as single-level (fault within a single execution unit) or cross-level (fault across multiple units or graph structure levels).

[0136] In one specific implementation provided in this specification, the operation of each subtask is continuously monitored. When a subtask failure is detected, it is determined whether the failure is local or global, and then corresponding remedial measures are taken.

[0137] The nodes in the task-directed graph also include flag nodes that represent repair flags.

[0138] In this context, a flag node can be understood as a special type of node in the task-directed graph, used to represent a repair flag or an indication of a recovery strategy. It's important to understand that flag nodes can be the same as or different from the nodes representing subtasks in the task-directed graph.

[0139] In one specific embodiment provided in this specification, repairing the subtask to be processed based on its fault level includes: If the fault level of the subtask to be processed is a single-level fault, determine the execution intelligent unit to be processed corresponding to the subtask to be processed, and repair the subtask to be processed based on the execution intelligent unit to be processed. When the fault level of the subtask to be processed is a cross-level fault, in the directed graph of the task, the pending flag node corresponding to the pending subtask is determined, and the set of recovery strategies corresponding to the pending flag node is determined. Based on the set of recovery strategies, the pending subtask is repaired.

[0140] The fault level can be understood as an attribute describing the scope of a fault's impact or its type, and is divided into single-level faults and cross-level faults. A single-level fault refers to a fault that occurs only within a single intelligent processing unit and does not involve dependencies between tasks; a cross-level fault refers to a fault that involves dependencies between multiple tasks, or requires adjustments to the directed graph structure of the tasks to be repaired.

[0141] A single-level failure can be understood as a failure occurring within a single intelligent processing unit, without involving dependencies between tasks. It can usually be repaired by restarting the unit or retrying within that unit.

[0142] Cross-level failures can be understood as failures involving dependencies between multiple tasks, or requiring adjustments to the directed graph structure of tasks.

[0143] A set of recovery strategies can be understood as a collection of various repair methods that may be used to address cross-level failures. Each recovery strategy is a specific failure handling action, such as: re-executing the entire subgraph, adjusting dependent edges and retrying, triggering degradation processing, or manual intervention.

[0144] In one specific embodiment provided in this specification, if the fault level is a single-level fault, the execution intelligent processing unit (e.g., container ID, process PID, remote host address) corresponding to the subtask is found based on the task allocation record. The subtask is then repaired by retrying or restarting the unit itself.

[0145] In one example, a local repair operation is performed within the execution intelligent processing unit corresponding to a single-level fault, including but not limited to: restarting the unit and re-executing the subtask; retrying the subtask within the unit (using the same or later parameters); and clearing the unit's temporary state before re-executing.

[0146] If the fault level is a cross-level fault, it can be understood as affecting multiple tasks or requiring adjustments to the graph structure. In this case, find the marker node corresponding to the faulty subtask in the directed task graph. The marker node can be a recovery strategy indicator pre-configured for each subtask or each critical path, or it can be a special node dynamically created when the fault occurs. Read the set of pre-configured or dynamically bound recovery strategies on the marker node.

[0147] In one example, in the case of a cross-level failure, the corresponding set of recovery strategies could include: re-executing the failed subtask and all its downstream tasks; adjusting the directed graph of tasks (e.g., adding / deleting edges) and then re-executing the affected portion; switching to an alternative implementation or a degraded path; and requesting manual intervention. One or more strategies are selected from the strategy set based on the specific information of the failure (e.g., error code, scope of impact). Typically, these are attempted in order of priority until a successful repair or escalation to manual intervention is achieved.

[0148] According to a specific implementation provided in this specification, for single-level faults, the repair action is confined to the faulty unit, without interfering with other normally operating intelligent processing units or modifying the task directed graph. For cross-level faults, structural adjustments or global rescheduling can be performed at the graph level through flag nodes and a set of recovery strategies, resolving issues such as dependency errors and data pollution that single-level repair cannot handle. Flag nodes separate recovery strategies from business subtasks, allowing recovery logic to be configured and updated independently without modifying subtask code. Different subtasks can share the same flag nodes and strategy sets. Single-level fault repair does not modify the graph structure, avoiding unnecessary graph changes; cross-level fault repair explicitly manages graph adjustments through flag nodes, preventing arbitrary modifications that could lead to graph inconsistencies. Furthermore, since the fault level is determined at runtime, the system can adapt to different types of faults without pre-specifying a fixed repair method for each subtask, exhibiting dynamic adaptability.

[0149] In one specific implementation provided in this specification, nodes that do not meet the acceptance criteria, such as those in a fault state, are repaired according to the error recovery plan involved in the road book.

[0150] In one specific embodiment provided in this specification, repairing the subtask to be processed based on the set of recovery strategies includes: Determine the fault information of the subtask to be processed; Based on the fault information of the sub-task to be processed, at least one target repair strategy is determined from the set of recovery strategies; The sub-tasks to be processed are repaired based on the repair strategies for each target.

[0151] The fault information can be understood as detailed data describing the cause, location, error code, etc. of the fault.

[0152] A target repair strategy can be understood as one or more specific repair methods selected from a set of recovery strategies.

[0153] In one specific implementation provided in this specification, when a subtask failure is detected, all contextual information related to the failure is automatically collected. Based on matching criteria, the failure information is matched against the applicable conditions of each strategy in the recovery strategy set, and the selected target repair strategy is executed sequentially. After each strategy is executed, it is checked whether the failure has been resolved (e.g., the subtask succeeds after re-execution). If resolved, the repair is complete; if not resolved and there is another strategy, execution continues.

[0154] The matching conditions can be, for example: rule matching, such as "if the error code is TIMEOUT, then select the retry strategy"; machine learning classification, such as training a model based on historical failure data to predict the better strategy; or priority ranking, such as trying strategies sequentially according to predefined priorities until a usable strategy is found.

[0155] It is important to understand that this manual may select one main strategy or multiple strategies to form an execution sequence (e.g., try a lightweight strategy first, and upgrade to a heavyweight strategy if it fails).

[0156] In one example, the system uses error logs, exit codes, and timeout flags returned by the intelligent processing unit. It also considers the states of the predecessor and successor nodes of the subtask in the task's directed graph. Alternatively, it collects all contextual information related to the subtask's corresponding fault by inputting data verification results and resource monitoring data (CPU, memory, network). The fault information is then matched against the applicable conditions of each strategy in the recovery strategy set. Matching methods can include: rule matching (e.g., "if the error code is TIMEOUT, then select the retry strategy"); machine learning classification (training a model based on historical fault data to predict the optimal strategy); and priority ranking (trying strategies sequentially according to predefined priorities until an available strategy is found). A primary strategy can be selected, or multiple strategies can be selected to form an execution sequence (e.g., first try a lightweight strategy, then upgrade to a heavyweight strategy if it fails). The selected target repair strategies are executed sequentially. After each strategy is executed, it checks whether the fault has been resolved (e.g., the subtask succeeds after re-execution). If resolved, the repair is complete; if not resolved and there is another strategy, execution continues.

[0157] According to a specific implementation provided in this specification, using fault information (such as error codes and stack traces) to drive strategy selection can avoid blind retries or incorrect adjustments to the graph structure, thereby improving the success rate of repair.

[0158] In one specific embodiment provided in this specification, the set of recovery strategies is determined based on at least one of the following: Re-execute the pending subtask; Adjust the directed graph of the task and re-execute the sub-task to be processed; Trigger the degradation processing strategy.

[0159] Re-execution of pending subtasks can be understood as restarting failed tasks without changing dependencies.

[0160] Adjusting the directed graph of tasks and re-executing the pending subtasks can be done by modifying the edges or nodes of the directed graph of tasks (e.g., adding new dependencies or removing old dependencies) and then re-executing.

[0161] The degradation handling strategy can be understood as using alternative solutions (such as returning the default value or skipping the task) to ensure that the overall process is not interrupted when a task cannot be completed normally.

[0162] According to a specific implementation method provided in this specification, a customized information processing strategy (retention / compression / removal) is adopted for each subtask through task directed graph and semantic analysis, effectively reducing redundant data transmission, improving execution efficiency, and avoiding the transmission of unnecessary information. The serial / parallel execution order is determined based on semantic relationships and topological order, ensuring dependency correctness while maximizing parallelism and shortening the overall completion time. Multiple recovery strategies, such as retry, graph adjustment, and degradation, are provided to differentiate between single-level and cross-level faults, improving the system's robustness and self-healing capabilities. A flag node is introduced to uniformly manage the recovery strategy for cross-level faults, decoupling the repair logic from the business logic. The information boundary of the current task is dynamically determined based on the merging semantics of subsequent tasks, achieving context-aware information pruning and reducing the processing load of subsequent tasks. The construction of the task directed graph and strategy decision-making are semantically based, not relying on hard-coded rules, and are applicable to various domains. The fault handling strategy is configurable, facilitating adjustments by operations and maintenance personnel as needed.

[0163] In one specific embodiment provided above in this specification, after generating the target processing result corresponding to the target task, this specification can also automatically abstract the structured information such as the task decomposition strategy, compression strategy, and recovery plan of the directed graph of the current task execution into a reusable blueprint template, i.e., the updated roadmap. Deviations between the actual execution path and the pre-planned path (such as which subtasks were retried, and which compression strategies were proven unreasonable) are recorded as correction information for the blueprint template. This information is stored in an experience knowledge base, and an index relationship between task characteristics and blueprint templates is established.

[0164] During this process, each capability atom is marked with its verification status (verified / pending verification), applicable scenarios, and dependent conditions; these are then stored in the capability atom index of the experience knowledge base.

[0165] When a new task arrives, the blueprint generation engine first searches the experience knowledge base: it retrieves candidate blueprint templates by matching task features with the blueprint template index based on similarity; it pre-populates verified capability atoms by matching subtask descriptions with capability atom indexes; and it optimizes the blueprint generation strategy based on historical correction information (e.g., the compression strategy for a certain type of subtask needs adjustment). As the number of executions increases, the experience knowledge base becomes richer, and the efficiency and quality of blueprint generation improve exponentially. Each execution not only completes the current task but also accumulates reusable macro-strategies and micro-capabilities for subsequent tasks.

[0166] Among them, the candidate blueprint templates for retrieval can be, for example, similarity retrieval based on vectorized representation; exact matching based on structured tags; or association reasoning retrieval based on graphs.

[0167] The above process also includes automatically identifying and extracting reusable capability atomic units from the execution process, including but not limited to: code snippets / configuration templates that have been verified by acceptance testing; verification rules and test cases that have been proven to be effective; and practice patterns for specific technology stacks.

[0168] Furthermore, regarding the task arrangement methods mentioned above in this specification, for ease of understanding, this specification incorporates the appendix... Figure 2 The above task arrangement method will be explained. Figure 2 A flowchart of another task orchestration method according to an embodiment of this specification is shown, including steps 202-208: Step 202: Receive the task description information of the task to be processed.

[0169] Step 204: Based on the task semantics of the task description information parsed by the orchestration intelligent processing unit, a task directed graph is generated.

[0170] The directed edges in the task directed graph are used to represent the decomposition and dependencies of each subtask.

[0171] In one specific embodiment provided in this specification, a task roadmap is generated by parsing the full task semantics of the task description information using an orchestration intelligent processing unit. This roadmap includes at least one of the following: Based on the decomposition and dependencies of each subtask represented by the task directed graph; Information processing strategies for the marker nodes of each subtask, wherein the information processing strategies are obtained based on the dependency analysis of subsequent subtasks on the information of the current stage, and the information processing strategies include the pre-determined information retention strategy, information compression strategy and information removal strategy for each marker node. The expected output format specifications for each subtask; The criteria for stage acceptance of each sub-task; Error recovery plans for critical sub-task nodes include rollback recovery point definitions and recovery strategy selection rules.

[0172] Step 206: Based on the dependencies of each subtask in the task directed graph, distribute the subtasks to one or more execution intelligent processing units.

[0173] In one specific embodiment provided in this specification, based on the dependencies between the subtasks in the task-directed graph, the MapReduce delegation method is used to distribute the subtasks in the task-directed graph to multiple execution intelligent processing units, so as to facilitate parallel execution by each execution intelligent processing unit. The results of the parallel execution by each execution intelligent processing unit are then summarized.

[0174] Furthermore, the process of each execution intelligent processing unit handling each subtask can be specifically as follows: For each execution intelligent processing unit, it receives the subtask description, input data, expected output format specifications, and acceptance criteria for its corresponding subtask based on the content of the roadmap. Simultaneously, it receives the necessary compressed context information. Based on the obtained information, the subtask is executed. If the execution result meets the acceptance criteria, it is used as the final summary information. If the execution result does not meet the acceptance criteria, it is repaired according to the error recovery plan.

[0175] The compressed context information can be determined by a semantic-aware context perceptron, and this specification does not impose any limitations on it.

[0176] Furthermore, the recovery process according to the error recovery plan can be carried out using a layered self-healing approach. Specifically: The intelligent processing unit automatically detects local errors (such as format mismatches or logical inconsistencies) during execution and attempts to repair them autonomously within that local area. The boundaries of this self-repair mechanism include: a maximum number of retries and a repair scope that does not exceed the boundaries of the current subtask. When local self-repair fails or a global error across subtasks is detected (such as inconsistent outputs or dependency conflicts between subtasks), the error is reported to the orchestration intelligent processing unit. Based on the recovery plan pre-planned in the execution blueprint, the orchestration control agent rolls back the execution state to the nearest recovery point (flag node) and decides, based on the cause of the error, whether to redistribute the subtask, adjust the blueprint and re-execute the affected subtask subgraph, or trigger a degradation processing strategy. Step 208: In response to the completion of each subtask, generate the processing result corresponding to the task to be processed based on the information processing strategy according to each flag node.

[0177] In one specific embodiment provided in this specification, for each subtask that passes the acceptance criteria, the semantic-aware context manager performs context processing operations at predetermined semantic boundary points according to the information processing strategy pre-planned in the execution blueprint. For example, it maintains essential information in the main context; generates a structured summary of compressible information and replaces the original information; and removes information that can be safely discarded from the context. The processing results of each subtask obtained by the various execution intelligent processing units are summarized to generate the processing result corresponding to the task to be processed.

[0178] After the task to be processed is completed, the information processing strategies and repair operations involved in the processing of the task are abstracted into a reusable blueprint template. The deviation between the actual execution path and the pre-planned path of the task to be processed (e.g., which subtasks were retried, which compression strategies were proven unreasonable) is recorded as correction information for the template and stored in the experience knowledge base. An index relationship between task characteristics and blueprint templates is established for subsequent direct use. During this process, capability atoms are preserved. Specifically, reusable capability atom units are automatically identified and extracted from the execution process, including but not limited to: code snippets / configuration templates verified through acceptance testing; proven effective verification rules and test cases; and expected practice patterns for specific technology stacks. Each capability atom is marked with its verification status (verified / pending verification), applicable scenario, and dependencies, and stored in the capability atom index of the experience knowledge base.

[0179] Furthermore, when a new task arrives, the blueprint generation engine first searches the experience knowledge base. For example, this can be achieved by retrieving candidate blueprint templates through similarity matching between task features and blueprint template indexes; pre-populating verified capability atoms by matching subtask descriptions with capability atom indexes; and optimizing the blueprint generation strategy based on historical correction information (such as adjusting the compression strategy for a certain type of subtask).

[0180] In this process, as the number of executions increases, the experience knowledge base is continuously enriched, and the efficiency and quality of blueprint generation improve exponentially. Each execution not only completes the current task, but also accumulates reusable macro strategies and micro capabilities for subsequent tasks.

[0181] In one example, this manual uses a cross-module refactoring task as an example to explain the execution process of the task orchestration method. For example... Figure 3 As shown, Figure 3 A flowchart of a task orchestration and execution process according to an embodiment of this specification is shown, including steps 302-306.

[0182] Step 302: Obtain the directed graph of the tasks to be refactored corresponding to the cross-module refactoring task.

[0183] The cross-module reconstruction task includes multiple sub-tasks to be reconstructed. Each node in the directed graph of the reconstructed task is determined based on the semantics of the sub-tasks to be reconstructed, and the directed edges are determined based on the execution order between the sub-tasks to be reconstructed.

[0184] In one example, a cross-module refactoring task might be to "extract the authentication logic of the REST APIs involved in the project from each controller and migrate it uniformly to the middleware layer, involving the user module, order module, and payment module." In this case, the cross-module refactoring task is parsed, a full semantic analysis is performed on the task, and the corresponding roadmap is obtained. Based on this roadmap, a directed graph of the task is obtained.

[0185] The directed graph for this task includes the following nodes: Node 1, analyzing existing authentication logic; Node 2, involving middleware interfaces; Node 3, user module migration; Node 4, order module migration; Node 5, payment module migration; Node 6, integration testing; Node 7, regression verification.

[0186] The acceptance criteria are: after each module is migrated, all existing API test cases pass.

[0187] The recovery plan is as follows: if any module fails to migrate, the module will be rolled back to its state before migration, without affecting other modules.

[0188] Experience matching involves retrieving historical "authentication logic migration" blueprint templates and verified middleware injection capability atoms from the knowledge base.

[0189] Step 304: Determine the relationships between nodes based on the directed graph of the task to be reconstructed, and determine the information processing strategy corresponding to each node based on the semantics of each subtask to be reconstructed and the relationships between nodes.

[0190] The current node is determined among all nodes, and the current subtask corresponding to the current node and at least one successor node associated with the current node are obtained. The semantics of the successor subtasks corresponding to each successor node are determined. The merging semantics of the semantics of each successor subtask are determined, and the current semantic boundary corresponding to the current subtask is determined based on the merging semantics. The information processing strategy corresponding to the current node is determined based on the current semantic boundary, wherein the current node is any one of the nodes.

[0191] In one example, based on the directed graph of the task, the compression strategy is determined as follows: after the "Analyze Existing Authentication Logic" step corresponding to node 1 is completed, the interface contract and authentication rule summary are retained, the specific code scan details are compressed, and the contents of node 3 "User Module Migration," node 4 "Order Module Migration," and node 5 "Payment Module Migration" are executed in parallel.

[0192] Step 306: Execute the cross-module reconstruction task based on the execution order and information processing strategy of each subtask to be reconstructed, and generate the target processing result corresponding to the cross-module reconstruction task.

[0193] In one example, the processing of node 3 "User Module Migration", node 4 "Order Module Migration", and node 5 "Payment Module Migration" is performed in parallel by various execution intelligent processing units.

[0194] During this process, it is determined whether the processing results obtained by each execution intelligent unit meet the acceptance criteria. If the "order module" fails to pass acceptance after migration, for example, if an internal authentication branch is missing, the corresponding execution intelligent processing unit will automatically detect and repair it until the result meets the acceptance criteria, thereby obtaining the target processing result.

[0195] Furthermore, after obtaining the target processing result, the blueprint template corresponding to the authentication migration involved in this execution process is preserved, and the "middleware authentication" injection capability atom is extracted.

[0196] According to the embodiments described above in this specification, by performing full semantic analysis on the tasks to be processed, and then determining compression points based on semantic boundaries, the ability to retain key information is improved, thereby reducing the probability of accidental deletion of key information. Furthermore, by determining the information processing strategies corresponding to each subtask, the effective density of contextual information is effectively guaranteed, ensuring that necessary information is retained in each execution process of the tasks to be processed, thereby reducing the occupation of storage space by invalid information and improving space utilization. In addition, since the tasks to be processed are allocated and executed based on a directed task graph, semantic compression ensures the continued existence of key contextual information. In other words, according to the task orchestration method provided in this specification, a task blueprint is constructed through full semantic analysis during the task analysis phase, and the execution path of each node is pre-planned. In this case, the information processing strategy of the current node is determined based on the dependency analysis of subsequent nodes in the directed task graph, rather than being triggered based on resource utilization, fundamentally eliminating the contradiction between accidental deletion of key information and retention of useless information.

[0197] Furthermore, in this specification, if there are situations where the acceptance criteria are not met during the execution of each execution intelligent processing unit, repairs are carried out in a layered self-healing manner. For example, in the case of a single-level fault, the corresponding execution intelligent processing unit is used for repair. If there is a cross-level fault, the system rolls back to the flag node according to the flag node method, thereby performing repair operations. This reduces the average error recovery cost and eliminates the need for global work or manual intervention, thus reducing the error recovery cost.

[0198] Furthermore, in this specification, after generating the target processing result corresponding to the task to be processed, a blueprint template is generated and stored. Therefore, when a new task to be processed needs to be processed, if a historical blueprint template matches, only incremental adjustments need to be made to the historical blueprint template, without regenerating the blueprint template, thus reducing the time spent on blueprint template generation. In addition, since corresponding capability atoms are also stored according to the task to be processed, verified capability atoms can be directly reused, avoiding the time-consuming implementation of duplicate sub-capabilities. Furthermore, historical correction information can guide blueprint optimization, thereby avoiding error relapse rates. In other words, based on the target processing result corresponding to the task to be processed, by storing the task blueprint and capability atoms corresponding to that task, repeated full semantic analysis for subsequent new tasks to be processed is avoided. The reuse of capability atoms also avoids implementing new tasks from scratch. Based on this, the execution efficiency of new tasks to be processed is improved. That is, the execution efficiency of new tasks to be processed increases linearly with the number of uses.

[0199] See Figure 4 , Figure 4 An architecture diagram of a task orchestration method according to an embodiment of this specification is shown below: It should be noted that this architecture diagram includes a user task description module, an orchestration intelligent processing unit module, a structured execution module, a semantic awareness module, a blueprint generation engine, a structured experience knowledge base module, a divide-and-conquer-aggregate module, at least one execution intelligent processing unit module, a hierarchical self-healing controller module, a result aggregation and acceptance module, and a two-layer experience accumulation engine module.

[0200] The user task description can be understood as the original requirements or task description submitted by the user, usually given in natural language, and used to generate the target task of long-term engineering.

[0201] A structured experience knowledge base can be understood as storing reusable knowledge accumulated from the execution of historical tasks, including macroscopic blueprint templates and microscopic capability atoms (i.e., reusable subtask processing units). This knowledge base is used to guide the decomposition, orchestration, and self-healing of new tasks.

[0202] The orchestration intelligent processing unit is responsible for receiving user tasks, calling the blueprint generation engine, managing the context, generating structured execution blueprints, and monitoring the entire execution process. It includes the ability to reference "blueprint templates + capability atoms".

[0203] The blueprint generation engine automatically generates a "structured execution blueprint" component based on the user's task description and experience knowledge base. The blueprint includes a directed task graph (DAG), information processing strategies (compression / retention / removal), acceptance criteria, and recovery plans.

[0204] The semantic awareness module is responsible for parsing task semantics and identifying relationships between modules, while the context manager is responsible for maintaining the global state of the current task execution (such as completed subtasks, intermediate results, and resource usage). Together, they provide dynamic information for blueprint generation and execution.

[0205] The divide-and-conquer-aggregate module is responsible for breaking down tasks in the structured execution blueprint into multiple parallel subtasks (divide and conquer), distributing them to the execution intelligence processing units, and aggregating the results after execution. This engine manages the lifecycle of the subtasks.

[0206] The execution intelligent processing unit module is the computing unit (second intelligent agent) that actually executes the sub-tasks. Each intelligent agent runs independently in an isolated workspace (local or remote) and has local self-healing capabilities (such as self-retry and degradation), as well as the ability to periodically report its status to the hierarchical self-healing controller.

[0207] The hierarchical self-healing controller module is responsible for monitoring the operational status of all executing agents, detecting faults, and handling them in a hierarchical manner. It does not intervene in single-level faults (which can be handled by local self-healing), but initiates global recovery strategies (such as adjusting the DAG and reallocating) for cross-level faults.

[0208] The results aggregation and acceptance module collects the output of all executing agents, verifies it according to the acceptance criteria defined in the structured execution blueprint, and aggregates it to form the final target processing result. If the acceptance fails, a repair or rollback is triggered.

[0209] The two-layer experience accumulation engine stores the effective blueprint templates (macro) and reusable capability atoms (micro) from the current task execution into a structured experience knowledge base for future use. This achieves self-closing-loop optimization of experience.

[0210] In one specific embodiment provided in this specification, a user-described task is obtained to arrive at a target task, which is a long-term engineering task. The orchestration intelligent processing unit invokes a blueprint generation engine to query blueprint templates and capability atoms for similar tasks from a structured experience knowledge base, resulting in a directed task graph. The semantic awareness module analyzes each node in the directed task graph to obtain the relationships between nodes, and assigns them to the corresponding execution intelligent processing units based on these relationships. During the generation of processing results for each subtask, the execution intelligent processing unit corrects any anomalies that occur during the processing.

[0211] At this point, the hierarchical self-healing controller monitors anomalies between nodes and corrects them accordingly. Then, it feeds back the results generated by each intelligent processing unit after the repairs are completed, and merges them to obtain the processing result of the target task.

[0212] Furthermore, the successful parallel development blueprint (a fully parallel DAG of three independent tasks) will be stored in the knowledge base as a macro template. Capabilities will be atomically marked for future reuse.

[0213] The following is in conjunction with the appendix Figure 5 Taking the task orchestration method provided in this specification as an example of its application in long-term engineering tasks, the task orchestration method will be further explained. Among other things, Figure 5 The present specification illustrates a flowchart of a task orchestration method according to an embodiment, which includes the following steps.

[0214] Step 502: Obtain the target task description to get the target task.

[0215] In one example, a natural language description of the target task submitted by the user is received.

[0216] Step 504: Retrieve the structured experience knowledge base.

[0217] In one example, based on the target task, a structured experience knowledge base is retrieved to determine whether a blueprint template similar to the target task exists.

[0218] Step 506: Generate a structured execution blueprint.

[0219] In one example, if a similar blueprint template is matched, a blueprint draft is generated based on that template.

[0220] In another example, if a miss occurs, a full semantic analysis of the target task is performed to generate a structured execution blueprint.

[0221] The structured execution blueprint includes: Subtask DAG decomposition: the target task is decomposed into multiple subtasks, and a directed graph of the task is constructed based on the semantics and topological order of each subtask, where nodes represent subtasks and directed edges represent the execution order.

[0222] Based on the relationships between subtasks and the merging semantics of subsequent nodes, an information processing strategy is determined for each node. The information processing strategy includes information retention strategy, information compression strategy, or information removal strategy.

[0223] Define the data structure for the final processing result. Define the completion conditions for each subtask and the overall target task. Predefine a set of recovery strategies for possible failures, including at least one of the following: re-execute the subtask to be processed, adjust the task directed graph and then re-execute, or trigger a degradation processing strategy. Perform a consistency check on the generated blueprint.

[0224] Step 508: Distribute subtasks according to the topological order of the task directed graph.

[0225] In one example, each subtask is distributed to the corresponding execution intelligent processing unit according to the execution order determined in the task directed graph.

[0226] Step 510: The intelligent processing unit executes the subtask.

[0227] In one example, each execution intelligent processing unit performs its assigned subtask in an isolated workspace and applies a pre-planned information processing strategy (such as semantic compression) for that subtask.

[0228] Step 512: Acceptance and judgment at each stage.

[0229] In one example, the execution results of each subtask or batch are evaluated for acceptance: if the acceptance is successful, the subsequent subtasks continue; if the acceptance fails and it is a local error (single-level fault), the execution intelligent processing unit performs local self-repair (such as retrying or downgrading); if the acceptance fails and it is a global error (cross-level fault), the orchestration control agent performs a rollback operation according to the recovery strategy set to restore the system state to the preset recovery point.

[0230] Step 514: Determine if there are any subsequent subtasks.

[0231] In one example, based on the task directed graph, if there are unexecuted subtasks, return to step 508 to continue dispatching; otherwise, proceed to the aggregation phase.

[0232] Step 516: Merge all subtask results.

[0233] In one example, the execution results returned by all execution intelligent processing units are collected, aggregated according to the output schema definition and acceptance criteria, and the target processing result corresponding to the target task is generated.

[0234] Step 518: Two-layer experience accumulation.

[0235] In one example, macro-level sedimentation involves storing valid blueprint templates from this execution into a structured experience knowledge base; micro-level sedimentation involves extracting reusable capability atoms (such as subtask processing units and information processing strategy configurations) and storing them in the knowledge base.

[0236] Step 520: Write back to the experience knowledge base.

[0237] The experience data obtained from the two-layer sedimentation is updated into the structured experience knowledge base.

[0238] Step 522: Output the final result.

[0239] Output the target processing result corresponding to the target task.

[0240] Corresponding to the above method embodiments, this specification also provides embodiments of a task orchestration apparatus. Figure 6 A schematic diagram of a task orchestration apparatus according to one embodiment of this specification is shown. Figure 6 As shown, the device includes: The acquisition unit 602 is configured to acquire a task-directed graph corresponding to a target task, wherein the target task includes multiple subtasks, each node in the task-directed graph is determined based on the semantics of the subtasks corresponding to each subtask, and the directed edges are determined based on the execution order between the subtasks.

[0241] The determining unit 604 is configured to determine the association relationship between nodes according to the task directed graph, determine the current node among the nodes, and obtain the current subtask corresponding to the current node and at least one successor node associated with the current node, determine the semantics of the successor subtask corresponding to each successor node; determine the merging semantics of the semantics of each successor subtask, and determine the current semantic boundary corresponding to the current subtask based on the merging semantics; and determine the information processing strategy corresponding to the current node based on the current semantic boundary, wherein the current node is any one of the nodes.

[0242] The processing unit 606 is configured to execute the target task based on the execution order of each subtask and the information processing strategy, and generate the target processing result corresponding to the target task.

[0243] Furthermore, the task-directed graph is constructed in the following manner: The full task semantics corresponding to the target task are parsed to obtain multiple subtasks, and the subtask semantics and topological order corresponding to each subtask are determined. Based on the semantics of each subtask, determine the semantic relationships between each subtask; Based on semantic relationships and the topological order of each subtask, the execution order among the subtasks is determined. By treating each subtask as a node and the execution order between subtasks as directed edges, a directed task graph is constructed.

[0244] Furthermore, the acquisition unit 602 is further configured as follows: Based on the topological order corresponding to each subtask, determine the first and second subtasks that are topologically adjacent, and determine the semantic association between the first and second subtasks; When there is no semantic association, the execution order between the first subtask and the second subtask is determined to be parallel execution. If the semantic relationship is related, the execution order between the first subtask and the second subtask is determined to be sequential.

[0245] Furthermore, unit 604 is further configured as follows: When the merged semantics are global information, the current semantic boundary corresponding to the current subtask is determined as the global lexical information of the current subtask; In the case where the merged semantics are partial information, the current semantic boundary corresponding to the current subtask is determined to be part of the lexical information of the current subtask; When the merged semantics are independent information, the current semantic boundary corresponding to the current subtask is determined as the removed lexical information of the current subtask.

[0246] Furthermore, unit 604 is further configured as follows: When the current semantic boundary is to remove lexical information, the information processing strategy corresponding to the current node is determined to be an information removal strategy; When the current semantic boundary is part of lexical information, the information processing strategy corresponding to the current node is determined to be an information compression strategy; When the current semantic boundary is global lexical information, the information processing strategy corresponding to the current node is determined to be an information retention strategy.

[0247] Furthermore, unit 604 is also configured as follows: If the current node has no successor node, the information processing strategy corresponding to the current node is determined to be an information retention strategy.

[0248] Furthermore, the processing unit 606 is further configured as follows: Distribute each subtask to the corresponding execution intelligent processing unit; Based on the execution order of each subtask, the information processing strategy corresponding to each subtask is executed in each execution intelligent processing unit to generate the target processing result corresponding to the target task.

[0249] Furthermore, the processing unit 606 is also configured as follows: Detect the execution status of the corresponding subtasks at each node; If a pending subtask is in a fault state, the pending subtask is repaired based on its fault level.

[0250] Furthermore, the nodes in the task-directed graph also include marker nodes that represent repair markers; Processing unit 606 is further configured as follows: If the fault level of the subtask to be processed is a single-level fault, determine the execution intelligent unit to be processed corresponding to the subtask to be processed, and repair the subtask to be processed based on the execution intelligent unit to be processed. When the fault level of the subtask to be processed is a cross-level fault, in the directed graph of the task, the pending flag node corresponding to the pending subtask is determined, and the set of recovery strategies corresponding to the pending flag node is determined. Based on the set of recovery strategies, the pending subtask is repaired.

[0251] Furthermore, the processing unit 606 is further configured as follows: Determine the fault information of the subtask to be processed; Based on the fault information of the sub-task to be processed, at least one target repair strategy is determined from the set of recovery strategies; The sub-tasks to be processed are repaired based on the repair strategies for each target.

[0252] Furthermore, the set of recovery strategies is determined based on at least one of the following: Re-execute the pending subtask; Adjust the directed graph of the task and re-execute the sub-task to be processed; Trigger the degradation processing strategy.

[0253] The above is a schematic scheme of a task orchestration device according to this embodiment. It should be noted that the technical solution of this task orchestration device and the technical solution of the task orchestration method described above belong to the same concept. For details not described in detail in the technical solution of the task orchestration device, please refer to the description of the technical solution of the task orchestration method described above.

[0254] See Figure 7 , Figure 7 This specification illustrates an architecture diagram of a task orchestration system according to an embodiment of the present specification. The task orchestration system may include a client 100 and a server 200. Client 100 is used to send the directed graph of the target task to server 200; Server 200 is used to obtain a directed graph of a target task, wherein the target task includes multiple subtasks, each node in the directed graph is determined based on the semantics of the subtasks, and the directed edges are determined based on the execution order of the subtasks; the server determines the relationships between nodes according to the directed graph, identifies the current node, obtains the current subtask corresponding to the current node and at least one successor node associated with the current node, and determines the semantics of the successor subtasks corresponding to each successor node; the server determines the merging semantics of the semantics of the successor subtasks, and determines the current semantic boundary corresponding to the current subtask based on the merging semantics; the server determines the information processing strategy corresponding to the current node based on the current semantic boundary, wherein the current node is any one of the nodes; the server executes the target task based on the execution order of the subtasks and the information processing strategy, generates the target processing result corresponding to the target task; and sends the target processing result to client 100. Client 100 is also used to receive the target processing results sent by server 200.

[0255] Using the schemes of the embodiments in this specification, the task orchestration system may include multiple clients 100 and a server 200, wherein the client 100 may be referred to as an end-side device, and the server 200 may be referred to as a cloud-side device. Multiple clients 100 can establish communication connections through the server 200. In a task orchestration scenario, the server 200 is used to provide task orchestration services among the multiple clients 100, and the multiple clients 100 can act as either senders or receivers, communicating through the server 200.

[0256] Users can interact with server 200 through client 100 to receive data sent by other clients 100, or send data to other clients 100, etc. In a task orchestration scenario, users can publish data streams to server 200 through client 100, server 200 can generate target processing results based on the data stream, and push the target processing results to other clients that have established communication.

[0257] In this system, client 100 and server 200 establish a connection via a network. The network provides the medium for communication between client 100 and server 200. The network can include various connection types, such as wired or wireless communication links or fiber optic cables. Data transmitted by client 100 may need to undergo encoding, transcoding, compression, or other processing before being published to server 200.

[0258] Client 100 can be a browser, an app (application), a web application such as an H5 (HyperText Markup Language 5) application, a lightweight application (also known as a mini-program), or a cloud application. Client 100 can be developed based on the software development kit (SDK) of the corresponding service provided by server 200, such as a real-time communication (RTC) SDK. Client 100 can be deployed on a computing device and depends on the device or certain apps on the device to run. The computing device may have a display screen and support information browsing, such as a personal mobile terminal like a mobile phone, tablet, or personal computer. Various other types of applications can also be configured on the computing device, such as human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, and social media platform software.

[0259] Server 200 may include servers providing various services, such as servers providing communication services to multiple clients, servers supporting backend training of models used on clients, and servers processing data sent by clients. It should be noted that server 200 can be implemented as a distributed server cluster composed of multiple servers, or as a single server. The server can also be a server in a distributed system, or a server integrated with blockchain. The server can also be a cloud server providing 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 (CDNs), and big data and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology.

[0260] It is worth noting that the task orchestration method provided in the embodiments of this specification is generally executed by the server. However, in other embodiments of this specification, the client may also have similar functionality to the server, thereby executing the task orchestration method provided in the embodiments of this specification. In other embodiments, the task orchestration method provided in the embodiments of this specification may also be executed jointly by the client and the server.

[0261] Figure 8A structural block diagram of a computing device according to an embodiment of this application is shown. The components of the computing device 800 include, but are not limited to, a memory 810 and a processor 820. The processor 820 is connected to the memory 810 via a bus 830, and a database 850 is used to store data.

[0262] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 840 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0263] In one embodiment of this application, the aforementioned components of the computing device 800 and Figure 8 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 8 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0264] The computing device 800 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 800 can also be a mobile or stationary server.

[0265] The processor 820 is used to execute the following computer program / instructions, which, when executed by the processor, implement the steps of the above task orchestration method.

[0266] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the task orchestration method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the task orchestration method described above.

[0267] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the task orchestration method described above.

[0268] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the computer-readable storage medium embodiments are described simply because they are substantially similar to the task orchestration method embodiments; relevant parts can be referred to in the description of the task orchestration method embodiments.

[0269] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the task orchestration method described above.

[0270] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the task scheduling method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the task scheduling method described above.

[0271] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0272] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0273] It should be noted that the above description describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous. Secondly, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this specification.

[0274] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0275] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A task orchestration method, comprising: Obtain the task-directed graph corresponding to the target task, wherein the target task includes multiple subtasks, each node in the task-directed graph is determined based on the semantics of each subtask, and the directed edges are determined based on the execution order between each subtask. The relationships between nodes are determined based on the directed graph of the task. The current node is identified among the nodes, and the current subtask corresponding to the current node and at least one successor node associated with the current node are obtained. The semantics of the successor subtasks corresponding to each successor node are determined. The merging semantics of the semantics of each successor subtask are determined, and the current semantic boundary corresponding to the current subtask is determined based on the merging semantics. The information processing strategy corresponding to the current node is determined based on the current semantic boundary, wherein the current node is any one of the nodes. The target task is executed based on the execution order and information processing strategy corresponding to each subtask, and the target processing result corresponding to the target task is generated.

2. The method as described in claim 1, wherein the task-directed graph is constructed in the following manner: The full task semantics corresponding to the target task are parsed to obtain multiple subtasks, and the subtask semantics and topological order corresponding to each subtask are determined. Based on the semantics of each subtask, determine the semantic relationships between each subtask; Based on semantic relationships and the topological order of each subtask, the execution order among the subtasks is determined. By treating each subtask as a node and the execution order between subtasks as directed edges, a directed task graph is constructed.

3. The method as described in claim 2, wherein determining the execution order of each subtask based on semantic relationships and the topological order corresponding to each subtask includes: Based on the topological order corresponding to each subtask, determine the first and second subtasks that are topologically adjacent, and determine the semantic association between the first and second subtasks; When there is no semantic association, the execution order between the first subtask and the second subtask is determined to be parallel execution. If the semantic relationship is related, the execution order between the first subtask and the second subtask is determined to be sequential.

4. The method as described in claim 1, wherein determining the current semantic boundary corresponding to the current subtask based on the merging semantics includes: When the merged semantics are global information, the current semantic boundary corresponding to the current subtask is determined as the global lexical information of the current subtask; In the case where the merged semantics are partial information, the current semantic boundary corresponding to the current subtask is determined to be part of the lexical information of the current subtask; When the merged semantics are independent information, the current semantic boundary corresponding to the current subtask is determined as the removed lexical information of the current subtask.

5. The method as described in claim 1, wherein determining the information processing strategy corresponding to the current node based on the current semantic boundary, includes: When the current semantic boundary is to remove lexical information, the information processing strategy corresponding to the current node is determined to be an information removal strategy; When the current semantic boundary is part of lexical information, the information processing strategy corresponding to the current node is determined to be an information compression strategy; When the current semantic boundary is global lexical information, the information processing strategy corresponding to the current node is determined to be an information retention strategy.

6. The method according to any one of claims 1 to 5, the method further comprising: If the current node has no successor node, the information processing strategy corresponding to the current node is determined to be an information retention strategy.

7. The method as described in claim 1, wherein the target task is executed based on the execution order of each sub-task and the information processing strategy, and a target processing result corresponding to the target task is generated, comprising: Distribute each subtask to the corresponding execution intelligent processing unit; Based on the execution order of each subtask, the information processing strategy corresponding to each subtask is executed in each execution intelligent processing unit to generate the target processing result corresponding to the target task.

8. The method of claim 1, further comprising: Detect the execution status of the corresponding subtasks at each node; If a pending subtask is in a fault state, the pending subtask is repaired based on its fault level.

9. The method of claim 8, wherein the nodes in the task directed graph further include flag nodes representing repair flags; Based on the fault level of the subtask to be processed, repair the subtask to be processed, including: If the fault level of the subtask to be processed is a single-level fault, determine the execution intelligent unit to be processed corresponding to the subtask to be processed, and repair the subtask to be processed based on the execution intelligent unit to be processed. When the fault level of the subtask to be processed is a cross-level fault, in the directed graph of the task, the pending flag node corresponding to the pending subtask is determined, and the set of recovery strategies corresponding to the pending flag node is determined. Based on the set of recovery strategies, the pending subtask is repaired.

10. The method of claim 9, wherein repairing the pending subtask based on the set of recovery strategies includes: Determine the fault information of the subtask to be processed; Based on the fault information of the sub-task to be processed, at least one target repair strategy is determined from the set of recovery strategies; The sub-tasks to be processed are repaired based on the repair strategies for each target.

11. The method of claim 10, wherein the set of recovery strategies is determined based on at least one of the following: Re-execute the pending subtask; Adjust the directed graph of the task and re-execute the sub-task to be processed; Trigger the degradation processing strategy.

12. A task execution method, comprising: Receive task description information for tasks to be processed; Based on the task semantics parsed by the orchestration intelligent processing unit, a task blueprint is determined. This blueprint includes the decomposition and dependencies of subtasks represented by a directed graph, information processing strategies for the marker nodes of each subtask, pre-determined information retention, compression, and removal strategies for each marker node, and the expected output format specifications for each subtask. The information processing strategies are derived from dependency analysis of subsequent subtasks on the current stage's information. The current node is determined among all nodes, and the current subtask corresponding to the current node and at least one subsequent node associated with the current node are obtained. The semantics of the subsequent subtasks corresponding to each subsequent node are determined. The merging semantics of the semantics of each subsequent subtask are determined, and based on the merging semantics, the current semantic boundary corresponding to the current subtask is determined. Based on the current semantic boundary, the information processing strategy corresponding to the current node is determined, where the current node is any one of the nodes. Based on the dependencies between subtasks in the task directed graph, the subtasks are distributed to one or more execution intelligent processing units. In response to the completion of each subtask, the processing result corresponding to the task to be processed is generated based on the information processing strategy according to each flag node.

13. A method for executing a cross-module refactoring task, comprising: Obtain the directed graph of the cross-module refactoring task corresponding to the refactoring task, wherein the cross-module refactoring task includes multiple sub-tasks to be refactored, each node in the directed graph of the refactoring task is determined based on the semantics of the sub-tasks to be refactored, and the directed edges are determined based on the execution order between the sub-tasks to be refactored. Based on the directed graph of the task to be reconstructed, determine the relationships between nodes, identify the current node, obtain the current subtask corresponding to the current node and at least one successor node associated with the current node, determine the semantics of the successor subtasks corresponding to each successor node, determine the merging semantics of the semantics of each successor subtask, and based on the merging semantics, determine the current semantic boundary corresponding to the current subtask; based on the current semantic boundary, determine the information processing strategy corresponding to the current node, wherein the current node is any one of the nodes; The cross-module reconstruction task is executed based on the execution order and information processing strategy of each subtask to be reconstructed, and the target processing result corresponding to the cross-module reconstruction task is generated.

14. A task orchestration apparatus, comprising: The acquisition unit is configured to acquire the task directed graph corresponding to the target task, wherein the target task includes multiple subtasks, each node in the task directed graph is determined based on the semantics of the subtasks corresponding to each subtask, and the directed edges are determined based on the execution order between the subtasks. The determining unit is configured to determine the association relationships between nodes based on the task directed graph, determine the current node among the nodes, obtain the current subtask corresponding to the current node and at least one successor node associated with the current node, determine the semantics of the successor subtasks corresponding to each successor node, determine the merging semantics of the semantics of each successor subtask, and determine the current semantic boundary corresponding to the current subtask based on the merging semantics; and determine the information processing strategy corresponding to the current node based on the current semantic boundary, wherein the current node is any one of the nodes; The processing unit is configured to execute the target task based on the execution order of each subtask and the information processing strategy, and generate the target processing result corresponding to the target task.

15. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 13.

16. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 13.

17. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 13.

Images