Task orchestration method and apparatus

Abstract

This specification provides a task orchestration method and apparatus. The task orchestration method includes: acquiring at least two requirement tasks and constructing a directed task graph based on each requirement task; when the directed task graph includes at least two task subgraphs, matching execution intelligent processing units with isolated environments according to the resource requirement characteristics of the requirement tasks corresponding to each task subgraph, wherein nodes between task subgraphs do not have directed edges; assigning the requirement tasks corresponding to each subgraph to their respective corresponding execution intelligent processing units, and obtaining the execution results sent by each execution intelligent processing unit; invoking a merging intelligent processing unit, distributing the execution results to the merging intelligent processing unit when an execution result corresponding to any requirement task is generated, and merging the execution results based on the merging intelligent processing unit to obtain the target processing result. This specification improves the execution efficiency of simultaneous development of multiple requirements.

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 efficiency of coded intelligent agents in scenarios where multiple tasks are developed simultaneously.

[0003] In scenarios where multiple tasks are developed simultaneously, the coding intelligent processing unit typically employs a full isolation approach, allocating a separate virtual machine or container instance to each parallel task. This results in redundant storage and resource waste. Manual isolation methods, lacking physical isolation and semantic conflict resolution capabilities, lead to high costs for manual intervention. Furthermore, existing orchestration methods using directed acyclic graphs are limited to subtask decomposition within a single requirement, failing to effectively handle complex dependencies and environment scheduling across multiple independent tasks. This presents a dual dilemma of atomic failure risk and low environmental resource utilization.

[0004] Therefore, how to efficiently execute tasks with multiple requirements being developed simultaneously using orchestration intelligent processing units 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 task orchestration system, 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 at least two requirement tasks and construct a task directed graph based on each requirement task, wherein the nodes of the task directed graph represent requirement tasks and the directed edges represent the execution order between each requirement task. When the task directed graph includes at least two task subgraphs, an execution intelligent processing unit with an isolated environment is matched according to the resource requirement characteristics of the task corresponding to each task subgraph, wherein the nodes between each task subgraph do not have directed edges. The requirements tasks corresponding to each subgraph are assigned to their respective execution intelligent processing units, and the execution results sent by each execution intelligent processing unit are obtained. Among them, each execution intelligent processing unit executes the requirements tasks corresponding to each subgraph in parallel. The intelligent merging processing unit is invoked. If an execution result is generated for any required task, the execution result is distributed to the intelligent merging processing unit. The execution results are then merged based on the intelligent merging processing unit to obtain the target processing result.

[0007] According to a second aspect of the embodiments of this specification, a task orchestration apparatus is provided, comprising: The acquisition unit is configured to acquire at least two requirement tasks and construct a task directed graph based on each requirement task, wherein the nodes of the task directed graph are used to represent requirement tasks, and the directed edges are used to represent the execution order between each requirement task. The determining unit is configured to, when the task directed graph includes at least two task subgraphs, match an execution intelligent processing unit with an isolated environment based on the resource requirement characteristics of the task corresponding to each task subgraph, wherein the nodes between the task subgraphs do not have directed edges. The execution unit is configured to assign the required tasks corresponding to each subgraph to their respective execution intelligent processing units, and obtain the execution results sent by each execution intelligent processing unit, wherein each execution intelligent processing unit executes the required tasks corresponding to each subgraph in parallel. The processing unit is configured to invoke the merging intelligent processing unit, and in the case of generating the execution result corresponding to any required task, distribute the execution result to the merging intelligent processing unit, and merge the execution results based on the merging intelligent processing unit to obtain the target processing result.

[0008] According to a third aspect of the embodiments of this specification, a task orchestration system is provided, the task orchestration system including an orchestration intelligent processing unit, at least one execution intelligent processing unit, and a merging intelligent processing unit, including: The orchestration intelligent processing unit is used to acquire at least two requirement tasks and construct a task directed graph based on each requirement task. The nodes of the task directed graph represent requirement tasks, and the directed edges represent the execution order between requirement tasks. When the task directed graph includes at least two task subgraphs, it matches execution intelligent processing units with isolated environments based on the resource requirement characteristics of the requirement tasks corresponding to each task subgraph. The nodes between task subgraphs do not have directed edges. The requirement tasks corresponding to each subgraph are assigned to their respective execution intelligent processing units, and the execution results sent by each execution intelligent processing unit are obtained. Each execution intelligent processing unit is used to execute the required tasks corresponding to each subgraph in parallel; The intelligent merging processing unit is used to perform conflict detection and incremental merging on each execution result to obtain the target processing result.

[0009] According to a fourth 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.

[0010] According to a fifth 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.

[0011] According to a sixth 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.

[0012] According to the task orchestration method provided in this specification, in scenarios where multiple tasks are developed simultaneously, a directed task graph is constructed based on at least two tasks. This graph orchestrates the tasks as a whole, allowing for a clear visual representation of the relationships between them using directed edges. Furthermore, based on these relationships, the directed task graph is divided into at least two task subgraphs. These subgraphs represent the parallel relationships between tasks within the multi-task framework. Each subgraph is assigned a corresponding intelligent execution unit. Since these subgraphs can execute in parallel, assigning them corresponding intelligent execution units improves the processing efficiency of the multi-task framework. Moreover, because each intelligent execution unit has an isolated environment and is matched based on the resource requirements of each task, an independent code copy space is created for each unit, achieving file system-level modification isolation and ensuring the security of each task subgraph's execution. Furthermore, during the process of merging the execution results of various requirement tasks, when generating the execution result for any requirement task, it is sent to the merging intelligent processing unit. The merging intelligent processing unit performs incremental merging operations, thereby exposing conflicts as early as possible and reducing the difficulty of merging. In summary, according to the task orchestration method provided in this specification, requirement tasks are processed in parallel by dividing the directed task graph into at least two feasible parallel-execution task subgraphs, thus improving the development efficiency of multiple requirement tasks. Attached Figure Description

[0013] Figure 1A An architecture diagram of a task orchestration system according to one embodiment of this specification is shown; Figure 1B An architecture diagram of a task orchestration system based on different roles, according to an embodiment of this specification, is shown. Figure 2A flowchart of a task orchestration method according to an embodiment of this specification is shown; Figure 3A A flowchart illustrating a directed graph of a construction task provided in one embodiment of this specification is shown; Figure 3B This specification illustrates a flowchart of a resource scheduling and allocation method according to one embodiment. Figure 3C A flowchart illustrating a combined intelligent processing unit process provided in one embodiment of this specification is shown; Figure 4 This specification shows a schematic diagram of the structure of a task orchestration apparatus according to one embodiment; Figure 5 This specification illustrates an architecture diagram of a task orchestration system provided in one embodiment. Figure 6 A block diagram of a computing device structure according to an embodiment of this application is shown. Detailed Implementation

[0014] 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.

[0015] 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.

[0016] 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."

[0017] 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.

[0018] 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.

[0019] 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.

[0020] The task orchestration method provided in this manual is applicable to scenarios where multiple requirements are developed simultaneously.

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

[0022] The version control isolated workspace (Worktree) can be understood as creating an independent code copy space for each execution intelligent processing unit based on the worktree mechanism provided by the version control system, thereby achieving file system-level modification isolation.

[0023] A remote computing execution environment (Remote) can be understood as a development execution environment located on a remote server accessible via a network, providing independent computing resources (processors, memory, storage, accelerators, etc.).

[0024] The orchestration and scheduling agent (orchestration intelligent processing unit) can be understood as a central intelligent agent responsible for receiving multiple development requirements, analyzing parallel feasibility, allocating execution resources, monitoring progress, and coordinating merging, thus upgrading from a single-requirement progress manager to a multi-requirement parallel scheduler.

[0025] An executive agent (executive intelligent processing unit) can be understood as an agent instance that performs specific coding tasks in an independent and isolated workspace, with each instance focusing on the implementation of a single requirement.

[0026] A stateless environment (stateless reusable resource layer) can be understood as an environment resource that does not depend on the runtime context and can be shared across tasks, including: code dependency cache, language service index, static analysis results, etc.

[0027] A stateful environment (stateful task isolation resource layer) can be understood as an environment resource that depends on the runtime context and needs to be maintained independently for each task instance, including: development server instance, database instance, test runtime environment, etc.

[0028] A task ID (task instance identifier) ​​can be understood as a globally unique identifier used to associate and isolate stateful resources, ensuring that the stateful environments of different parallel tasks do not interfere with each other.

[0029] Semantic conflict (logical code change conflict) can be understood as, distinct from text-level version conflict, referring to the logical contradictions arising at the semantic level of two parallel modifications (such as different branches of the same function being modified in different ways).

[0030] A Directed Acyclic Graph (DAG) structure is used to model dependencies and parallel opportunities among multiple requirements. Nodes represent requirements / tasks, and directed edges represent dependency constraints (execution order). In this specification, the DAG structure is simply referred to as a task-directed graph.

[0031] The Language Service Protocol Index (LSP Index), which contains symbol indexes, type information, and cross-reference data generated by the code semantic analysis service, is a stateless, reusable resource.

[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, coding intelligence processing units, in scenarios of "simultaneous development of multiple requirements," typically rely on "serial execution of single requirements," making it difficult to efficiently handle the simultaneous advancement of multiple requirements in real-world R&D scenarios. Specifically, this is due to the context pollution problem in such scenarios. The AI ​​agent's memory is its context window. If it processes requirement A and requirement B within the same dialogue / process, it's prone to incorrectly applying the constraints, code logic, or solutions of requirement A to requirement B. Furthermore, there are state explosion and illusion problems. For example, simultaneously tracking the states of multiple requirements can quickly fill the context window, causing the AI ​​to "forget" early critical information, leading to "illusions" and the creation of non-existent files, functions, or dependencies. Further, there is the risk of atomic failure. For instance, suppose an agent simultaneously modifies file F to satisfy both requirement A and requirement B. If the code for requirement B has an error, causing the entire test to fail, then the correct modification for requirement A may also fail to be merged due to the unstable state of the codebase.

[0034] To address the aforementioned issues, a common approach is full isolation using independent virtual machines / containers. This involves allocating a separate virtual machine or container instance to each parallel task, ensuring each instance contains a complete operating system environment, code copy, dependency installation, and runtime services. However, this method suffers from significant resource waste because each container instance must independently install dependencies, build indexes, and start language services. For typical front-end projects, this results in redundant storage. Furthermore, the time required from container creation to environment readiness (dependency installation + index building + service startup) typically ranges from 3 to 10 minutes, severely impacting the startup speed of parallel tasks. Moreover, the system struggles to distinguish between shared and isolated resources, often employing a full isolation strategy that lacks cross-task resource awareness. Finally, the absence of a central coordinator among multiple container instances prevents intelligent decision-making based on code dependencies regarding which tasks can be parallelized and which should be sequential.

[0035] Alternatively, a manual isolation approach based on Git branches can be used. This involves creating a separate Git branch for each task and isolating modifications from different tasks by switching branches within the same working directory. However, this method suffers from several drawbacks. Because Git branches provide logical rather than physical isolation, the working directory can only be in one branch state at a time. Multiple intelligent processing units cannot work on different branches simultaneously. Furthermore, branch merging is performed manually by the developer, relying on a text-level three-way merge algorithm. The algorithm is completely unable to identify semantic conflicts (such as incompatibility between callers due to interface changes), requiring manual review. Moreover, switching branches only alters code files, not the runtime state (e.g., an already started development server continues to serve old code), leading to unreliable test results. Additionally, branch creation, task assignment, progress monitoring, and merging order all require manual management, lacking intelligent orchestration.

[0036] Alternatively, a collaborative solution based on a multi-intelligent processing unit (MIU) dialogue framework could be adopted. This framework uses role-based assignment (e.g., "Architect Agent," "Coder Agent," "Test Agent") to achieve collaboration. The framework provides message passing and task routing mechanisms. However, coordination between multiple MIUs via message passing lacks file system-level isolation mechanisms. When multiple coding MIUs need to modify code simultaneously, the framework itself does not provide code isolation capabilities. Furthermore, the framework focuses on message flow and role orchestration between MIUs, without addressing the management and scheduling of the development environment. Even with role-based assignment, execution still proceeds serially through each role node. The framework does not understand code version control and cannot autonomously perform merging and conflict resolution after parallel modifications are completed.

[0037] Alternatively, a DAG-based single-requirement task decomposition and parallel execution scheme could be used. This involves breaking down a complex requirement into multiple subtasks, constructing a dependency DAG between these subtasks, and employing a parallel distribution strategy for subtasks without dependencies. However, DAG decomposition only addresses "subtasks of a single requirement," failing to handle "parallel execution of multiple independent requirements." Subtasks of a single requirement typically modify different files (guaranteed by the execution blueprint) and can be safely executed in parallel within the same working directory. However, parallel modifications across requirements may involve different regions of the same file, requiring working tree-level isolation. Subtasks share the same environment, eliminating environment isolation requirements. However, when executing in parallel across requirements, different requirements may require different runtime configurations. The scheduling scope of the orchestration intelligent processing unit is limited to subtasks within a single execution blueprint and cannot perceive other requirements currently being executed.

[0038] Furthermore, another example is creating a separate cloud workspace for each task, with each workspace being a complete cloud development environment. However, each workspace is a complete cloud virtual machine (typically with 2-4 CPU cores and 4-8GB of memory). Even if a task only requires modifying a few lines of code, a full machine must be allocated, resulting in extremely low resource utilization. Cloud workspaces do not distinguish between reusable resources and those that must be isolated; all environment components (code, dependencies, services) are isolated together, leading to the duplicate installation of the same dependencies across multiple workspaces. Creating a cloud workspace requires allocating a virtual machine, pulling an image, and installing dependencies, typically taking 2-5 minutes. The overhead in scenarios with frequent workspace creation / destruction is not negligible. Cloud workspaces are merely "environment providers" and lack orchestration capabilities such as task scheduling, parallel decision-making, progress monitoring, and autonomous merging. These capabilities require additional orchestration systems.

[0039] In view of this, a task orchestration method is provided in this specification. This specification also relates to a task orchestration apparatus, a task orchestration system, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0040] See Figure 1A , Figure 1A An architecture diagram of a task orchestration system according to one embodiment of this specification is shown. Figure 1A As shown, the task orchestration system includes an orchestration intelligent processing unit 100, at least one execution intelligent processing unit 200, and a merging intelligent processing unit 300.

[0041] The orchestration intelligent processing unit 100 is used to acquire at least two requirement tasks and construct a task directed graph based on each requirement task. The nodes of the task directed graph represent requirement tasks, and the directed edges represent the execution order between requirement tasks. When the task directed graph includes at least two task subgraphs, it matches execution intelligent processing units with isolated environments based on the resource requirement characteristics of the requirement tasks corresponding to each task subgraph. The nodes between task subgraphs do not have directed edges. The requirement tasks corresponding to each subgraph are assigned to their respective execution intelligent processing units, and the execution results sent by each execution intelligent processing unit are obtained.

[0042] It's important to understand that for independent task subgraphs without directed edges, the shared information representing the various requirement tasks—namely, task metadata—is available for mutual sharing. This task metadata is used by the intelligent processing unit to process each requirement task in parallel during execution, eliminating the need to wait for shared information between each requirement task and saving execution time. Furthermore, since the shared information between requirement tasks is stored only once in the orchestration and execution processing unit, redundant storage is avoided, thus reducing resource waste.

[0043] In one specific embodiment provided in this specification, the orchestration intelligent processing unit acquires multiple requirement tasks, parses the task semantics of these tasks, and determines the relationships between them based on the semantic parsing results. This allows for the construction of directed edges in a task directed graph based on these relationships. Furthermore, instructions for each requirement task are generated, and corresponding execution intelligent processing units are assigned to each task according to the instructions, resulting in the execution results of each execution intelligent processing unit.

[0044] In one example, the orchestration intelligent processing unit receives five requirement tasks: requirement task 001, requirement task 002, requirement task 003, requirement task 004, and requirement task 005. Semantic analysis of these five requirement tasks reveals that the execution order of requirement tasks 001, 002, and 003 is: requirement task 001 first, then requirement task 002, and finally requirement task 003. Furthermore, requirement task 004 has no connection with requirement tasks 001 through 003, and similarly, requirement task 005 has no connection with either requirement task 004 or requirement tasks 001 through 003. Based on this, when constructing directed edges between requirement tasks as nodes and considering their execution order, it is found that requirement task 001 has a directed edge pointing to requirement task 002, and requirement task 002 has a directed edge pointing to requirement task 003. Requirement tasks 004 and 005 do not have directed edges with any other requirement tasks and are placed as independent nodes in the task directed graph.

[0045] Furthermore, based on the directed task graph obtained above, and the directed edges between nodes, three task subgraphs are obtained: task subgraph a (including: task 001, task 002, and task 003), task subgraph b (including: task 004), and task subgraph c (including: task 005).

[0046] Based on the above, at least one corresponding execution intelligent processing unit is assigned to each task subgraph, and the processing result of the execution intelligent processing unit is obtained.

[0047] Each execution intelligent processing unit 200 is used to execute the required tasks corresponding to each task subgraph in parallel.

[0048] In one specific embodiment provided in this specification, each execution intelligent processing unit provides an independent execution environment for each task subgraph and executes the required tasks in each task subgraph.

[0049] In one example, for task subgraph a, since it corresponds to three demand tasks, corresponding execution intelligent processing units are allocated to each demand task based on its resource information. It's important to understand that because the three demand tasks are executed sequentially, when demand task 001 receives a result, demand task 002 is processed by the execution intelligent processing unit corresponding to demand task 002. Similarly, when demand task 002 receives a result, demand task 003 is processed by the execution intelligent processing unit corresponding to demand task 003. To further conserve resources in this process, the execution intelligent processing units corresponding to demand tasks 002 and 003 can be the same as or different from the execution intelligent processing unit corresponding to demand task 001.

[0050] During the processing of task subgraph a, according to the directed graph of tasks, task subgraphs b and c are executed in parallel with task subgraph a. Therefore, task subgraph b can be processed synchronously according to the execution intelligent processing unit corresponding to task subgraph b. Similarly, task subgraph c can also be processed synchronously according to the execution intelligent processing unit corresponding to task subgraph c, thereby improving the efficiency of developing multiple tasks simultaneously.

[0051] Furthermore, based on the processing results corresponding to each task subgraph, this specification can obtain the processing results of the task subgraph by merging the intelligent processing unit.

[0052] The intelligent merging processing unit 300 is used to perform conflict detection and incremental merging on each execution result to obtain the target processing result.

[0053] Specifically, when generating the execution result corresponding to any required task, the execution result is distributed to the merging intelligent processing unit. The merging intelligent processing unit performs conflict detection and incremental merging on each execution result to obtain the target processing result.

[0054] Based on the aforementioned task orchestration system, and to further enhance the understanding of the task orchestration series, this manual incorporates... Figure 1B The different roles of the intelligent units shown are used to illustrate the task orchestration system. Figure 1BAn architecture diagram of a task orchestration system based on different roles, provided according to an embodiment of this specification, is shown.

[0055] like Figure 1B As shown, it includes an orchestration and scheduling layer, an execution isolation layer, an environment layering and reuse layer, and a merging and verification layer.

[0056] The orchestration and scheduling layer is determined based on an intelligent orchestration processing unit, which integrates functions such as demand reception and parsing, parallel analysis and decision-making, resource scheduling and allocation, progress monitoring and intervention, and merging, sorting and verification.

[0057] The execution isolation layer is determined based on multiple execution intelligent processing units, each of which is used to perform different task requirements.

[0058] The environment layering and reuse layer includes a stateless reusable resource pool (shared layer) and stateful resource reuse. It's important to understand that the environment layering and reuse layer is used in conjunction with the execution isolation layer.

[0059] The merging and verification layer includes a merging processing unit, which integrates functions such as text merging preprocessing, semantic conflict detection, intelligent processing unit autonomous detection, integrated verification and regression.

[0060] Building upon the above, in the case of multiple tasks including task 001, task 002, and task 003, at the orchestration and scheduling layer, the orchestration intelligent processing unit performs semantic parsing on each task. Based on the parsing results, parallel analysis and decision-making are conducted to determine the relationships between the tasks. At the semantic analysis level: task 001, task 002, and task 003 involve different functional modules and task domains, with no semantic dependencies. At the code level, it is predicted that the modified code files corresponding to each task have no overlap and are marked as safe for parallel processing. Combining the analysis results from the semantic and code levels, a task directed graph is constructed, and the complexity of each node representing a task in the directed graph is evaluated to determine the resources (e.g., the corresponding execution intelligent processing unit) for each task. For example, the complexity evaluation result for task 001 is lightweight, requiring only code modifications and unit testing; the complexity evaluation result for task 002 is medium, requiring the activation of the payment sandbox service; and the complexity evaluation result for task 003 is heavyweight, requiring GPU environment to run model inference tests.

[0061] Based on the above, task instructions are generated and sent to the execution isolation layer. In the execution isolation layer, corresponding intelligent processing units are allocated to each task. Furthermore, based on the complexity of each task, the resource allocation strategy for each task is determined in the environment layering and reuse layer. This process yields the execution results for each task.

[0062] In one example, a local working tree A is allocated to task 001, and its corresponding resource allocation strategy is determined to be the resource allocation strategy for stateless resources, that is, reusing the dependency cache and indexes of the main workspace through symbolic links or shared mounts. Similarly, a local working tree B is allocated to task 002, and its corresponding resource allocation strategy is determined to be the resource allocation strategy for stateful resources, that is, allocating independent port numbers and database instances based on the task instance identifier of each task to create isolated workspaces. Likewise, a remote GPU environment C is allocated to task 003, and its corresponding resource allocation strategy is determined to be the resource allocation strategy for stateful resources.

[0063] It is important to understand that each task shares information such as dependency cache, LSP index, and build cache. For ease of explanation, this specification refers to the shared information that can be shared between tasks as task metadata.

[0064] Furthermore, the execution results of each task are monitored in real time. Based on incremental merging, text merging preprocessing is performed on each task. Semantic conflict detection is then conducted, and if no conflicts are found, the execution results are merged. Optionally, during semantic conflict detection, if conflicts exist, the intelligent merging processing unit resolves them autonomously based on its capabilities. The merged results are then integrated, verified, and regressed to ensure operational accuracy.

[0065] In one example, assume the task completion order is task 001, task 002, and task 003. Based on this order, task 001 receives its processing result first. If the conflict detection result is conflict-free, it is merged into the main code. Next, task 002 receives its processing result, and if the conflict detection result is conflict-free, it is merged into the main code. Then, task 003 receives its processing result, and if the conflict detection result is conflict-free, it is merged into the main code. This yields the overall processing result of the directed graph. A full check is then performed on the main code based on these processing results, and all checks pass.

[0066] Furthermore, to facilitate a better understanding of the task orchestration system, this manual provides an explanation of the aforementioned task orchestration system in conjunction with the task orchestration method.

[0067] See Figure 2 , Figure 2 A flowchart of a task orchestration method according to an embodiment of this specification is shown, specifically including the following steps 202-208.

[0068] Step 202: Obtain at least two requirement tasks and construct a task directed graph based on each requirement task, wherein the nodes of the task directed graph represent requirement tasks and the directed edges represent the execution order between requirement tasks.

[0069] In this context, a requirement task can be understood as an independent work unit that needs to be completed during the software development process. Examples include "adding a user registration function" or "fixing a defect in the payment module." Each requirement task can include attributes such as a natural language description and the expected scope of modification.

[0070] A directed edge can be understood as an edge connecting two nodes, where the direction of the arrow indicates the execution order between the two connected nodes. For example, for nodes A and B, if the arrow on the directed edge points from node A to node B, then the execution order between nodes A and B is that node A is executed first, followed by node B.

[0071] A task-directed graph can be understood as a graph structure with task requirements as nodes and directed edges representing the execution order of task requirements. It is used to represent the execution order of various task requirements. It's important to understand that a task-directed graph can consist of multiple independent nodes.

[0072] In one example, there are task 001, task 002, task 003, task 004, and task 005. When constructing directed edges between task nodes to represent their execution order, if there are directed edges between task 001 and task 002, and between task 002 and task 003, then directed edges are constructed between task 001 and task 002, and between task 002 and task 003. Task 004 and task 005 do not have directed edges with any other task; they are placed as independent nodes in the directed task graph. These nodes represent the task nodes in the directed task graph. Each node corresponds to a unique task.

[0073] In one specific embodiment provided in this specification, at least two requirement tasks are obtained, the relationships between the requirement tasks are determined, and a directed task graph is constructed based on the relationships. The relationships between the requirement tasks may be, for example, parallel execution or serial execution.

[0074] In one example, at least two requirements are obtained from project management, the logical dependencies and resource conflicts between the tasks are analyzed, and it is determined which tasks must be performed sequentially and which can be performed in parallel, thereby constructing a directed graph.

[0075] To facilitate understanding, this manual explains the process of constructing a task-directed graph in the following manner. Specifically, it involves obtaining at least two requirement tasks and constructing a task-directed graph based on each requirement task, including: Input at least two requirements into the orchestration intelligent processing unit; The task semantics of each required task are determined in the orchestration intelligent processing unit, and based on the task semantics of each required task, the shared information between each required task is determined to obtain task metadata. Based on the orchestration intelligent processing unit, a task directed graph is constructed according to the task semantics of each required task, and task instructions are generated. Based on the task instructions, the orchestration intelligent processing unit is controlled to send the task metadata to the execution intelligent processing unit.

[0076] In one specific embodiment provided in this specification, at least two acquired requirement tasks are input to the orchestration intelligent processing unit. Based on the processing capability of the orchestration intelligent processing unit, the task semantics corresponding to each requirement task are determined, and based on the task semantics of each requirement task, the shared information that can be shared between the requirement tasks is determined. The shared information that can be shared between the requirement tasks may include shared dependency caches, LSP indexes, and build caches, etc., which are not limited in this specification. Furthermore, a directed task graph for each requirement task is constructed based on its task semantics, and corresponding task instructions are generated.

[0077] Based on task instructions, the orchestration intelligent processing unit drives each execution intelligent processing unit to operate on each required task, so that the operation results can be distributed to the corresponding merging intelligent processing unit in the future.

[0078] Furthermore, to facilitate the subsequent operation of the intelligent processing unit, this specification utilizes the orchestration intelligent processing unit to distribute shared information that can be shared between various required tasks as task metadata to each execution intelligent processing unit, so as to facilitate the processing of required tasks by each execution intelligent processing unit.

[0079] Specifically, a directed graph of tasks is constructed based on each requirement, including S2022-S2028: S2022. Analyze the task semantics corresponding to each requirement task to obtain the requirement attribute information and code attribute information corresponding to each requirement task.

[0080] Task semantics can be understood as the intention, function, business domain, and other information expressed in the natural language description corresponding to the required task.

[0081] Requirement attribute information can be understood as structured information about functional modules, business domains, etc., extracted from task semantics.

[0082] Code attribute information can be understood as task-related code characteristics obtained through analysis of the codebase. Examples include the set of files to be modified and the function / class level areas to be modified.

[0083] In one example, semantic parsing is performed on the text of each requirement task, while code analysis tools are used to predict the scope of its code impact.

[0084] S2024. Based on the requirement attribute information and code attribute information corresponding to each requirement task, determine the dependency relationship between each requirement task.

[0085] In one specific implementation provided in this specification, the overlap between requirement attribute information and code attribute information is comprehensively analyzed to determine the dependency relationships between different requirement tasks, such as sequential or parallel dependencies.

[0086] Specifically, in one embodiment provided in this specification, the dependencies between each requirement task are determined based on the requirement attribute information and code attribute information corresponding to each requirement task, including: Based on the requirement attribute information corresponding to each requirement task, determine the relationship between each requirement task; Based on the code attribute information corresponding to each requirement task, determine the set of code files corresponding to each requirement task; Based on the relationships between various requirements and tasks, as well as the set of code files, the dependencies between various requirements and tasks are determined.

[0087] The relationship can be understood as whether there is a functional or business relationship between tasks determined by the requirement attribute information.

[0088] In one specific embodiment provided in this specification, the task-directed graph includes a topological order corresponding to each requirement task. Based on the topological order of each requirement task, two requirement tasks corresponding to adjacent topological orders are arbitrarily selected. Then, semantic analysis is used to determine whether the two requirement tasks belong to the same business domain or have an explicit dependency. Furthermore, based on code attribute information, the modified code files corresponding to each requirement task are predicted. Combining the requirement attribute information and code attribute information dimensions, the dependency relationship between two adjacent requirement tasks is obtained.

[0089] According to the specific implementation methods provided in this specification, the relationships between adjacent task requirements are analyzed from both semantic and code perspectives. This improves the accuracy of determining these relationships and avoids errors in determining dependencies that can occur with a single analysis method, thereby enhancing the accuracy of the subsequently constructed task-directed graph. Furthermore, clarifying the relationships between each task requirement lays the foundation for configuring corresponding intelligent processing units for each task.

[0090] Based on the relationships between the various requirements and tasks, the dependencies between adjacent requirements and tasks are determined.

[0091] In one specific implementation provided in this specification, the dependencies between various requirement tasks are determined based on the associations between them and the set of code files, including: When there is no association between the various requirements tasks and the sets of code files corresponding to the various requirements tasks have no overlap, the dependency between the various requirements tasks is determined as parallel dependency; If the relationships between the various requirements tasks are related, and / or the sets of code files corresponding to the various requirements tasks overlap, then the dependencies between the various requirements tasks are determined as serial dependencies.

[0092] Parallel dependency can be understood as representing that two demand tasks can be executed simultaneously without waiting.

[0093] Serial dependency can be understood as two tasks that must be executed in sequence; the latter task can only begin to be processed after the former task is completed.

[0094] Unrelated can be understood as two requirements or tasks having no direct or indirect connection in terms of function or business.

[0095] A connection can be understood as two tasks having dependencies, interactions, or sharing of the same module in terms of functionality / business.

[0096] In one specific embodiment provided in this specification, the task-directed graph includes the topological order corresponding to each requirement task. Based on the topological order corresponding to each requirement task, two requirement tasks corresponding to adjacent topological orders are arbitrarily selected. Furthermore, if two requirement tasks are unrelated and the predicted sets of modified code files have no overlap, then the two requirement tasks are determined to be parallel dependencies. If two requirement tasks are related, or the sets of code files have overlap, then the two requirement tasks are determined to be serial dependencies.

[0097] According to the specific implementation provided in this specification, based on the association relationship of the required tasks corresponding to adjacent topological orders, it is determined from a semantic perspective that there is no semantic relationship between the required tasks. Furthermore, since different required tasks may have the same code files in different semantic terms, in order to further avoid the situation of context semantic pollution during the operation of each required task due to the same code files, this specification predicts the code files that the required tasks may modify, so as to clarify whether the association relationship between each required task is a serial dependency or a parallel dependency, thereby improving the processing accuracy of different required tasks using the execution intelligent processing unit, and thus facilitating the determination of the execution order of the required tasks based on the dependency relationship.

[0098] S2026. Based on dependencies, determine the execution order of each required task.

[0099] In one specific embodiment provided in this specification, when the dependency relationship between adjacent requirement tasks is a sequential dependency, the execution order between adjacent requirement tasks is determined. Similarly, in the case of parallel dependencies, the order of tasks representing adjacent requirement tasks is unconstrained, such as allowing them to be executed in parallel.

[0100] In one example, if task 001 and task 002 are sequentially dependent, the execution order is determined according to the topological order of each task, which is to execute task 001 first and then task 002.

[0101] In another example, if requirement task 004 and requirement task 005 are parallel dependencies, then there is no need to determine their execution order, indicating that the execution order between requirement task 004 and requirement task 005 can be executed in parallel.

[0102] S2028. Construct a task directed graph by treating each requirement task as a node and the execution order between each requirement task as a directed edge.

[0103] Based on the above, a task-directed graph with clearly defined dependencies between nodes is obtained. Furthermore, based on the number of task subgraphs in the task-directed graph, the corresponding intelligent processing unit for each task subgraph is determined.

[0104] Wherein, if the task-directed graph includes at least two task subgraphs, before determining the execution intelligent processing unit corresponding to each task subgraph, the method further includes: Determine the dependencies between the various required tasks; Based on the dependencies between the various task requirements, nodes in the directed graph of the task that are not connected by directed edges are divided into the same task subgraph, resulting in at least two task subgraphs.

[0105] In one specific embodiment provided in this specification, nodes without directed edge connections (i.e., without serial constraints) are grouped into the same task subgraph. It should be understood that adjacent nodes within the same subgraph are connected by edges. There are no directed edges between different subgraphs, thus resulting in at least two task subgraphs.

[0106] In one example, taking task 001, task 002, task 003, task 004, and task 005 as examples, it is known that in the directed graph of tasks, there are directed edges between task 001, task 002, and task 003, and task 004 and task 005 are independent of the above tasks and there are no directed edges between them. Then the resulting task subgraphs can be task subgraph a composed of task 001, task 002, and task 003, task subgraph b composed of task 004, and task subgraph c composed of task 005.

[0107] Step 204: When the task directed graph includes at least two task subgraphs, according to the resource requirement characteristics of the task corresponding to each task subgraph, an execution intelligent processing unit with an isolated environment is matched, wherein the nodes between the task subgraphs do not have directed edges.

[0108] In this context, a task subgraph can be understood as a subset of a directed graph containing tasks, consisting of nodes with directed edges. It's important to understand that there are no directed edges connecting two task subgraphs; therefore, the tasks in the two subgraphs can be executed in parallel.

[0109] Each execution intelligent processing unit has an isolated environment, and the resource requirements of each task are matched accordingly.

[0110] In one specific embodiment provided in this specification, when there are at least two unconnected task subgraphs in the task directed graph, an independent execution intelligent processing unit is assigned to each task subgraph so that parallel execution between the task subgraphs can be achieved subsequently based on the independent execution intelligent processing unit.

[0111] In one example, when there are two task subgraphs in a directed task graph, the corresponding execution intelligent processing units are assigned to each task subgraph. For example, the execution intelligent processing units can be assigned according to the number of required tasks in the task subgraph, or the execution intelligent processing units can be assigned to each task subgraph as a unit.

[0112] For ease of understanding, in a specific embodiment provided in this specification, the execution intelligent processing unit corresponding to each task subgraph is determined, including S2042-S2046: S2042. Determine each requirement task corresponding to the initial task subgraph, wherein the initial task subgraph is any one of the task subgraphs.

[0113] S2044. Determine the task complexity corresponding to each requirement task, and determine the resource allocation strategy corresponding to each requirement task based on the task complexity.

[0114] Task complexity can be understood as an assessment of the workload, resource consumption, and time required for a given task, such as lightweight, medium, or heavy.

[0115] Resource allocation strategy can be understood as a set of rules that determine which environment (local / remote) a task is assigned to, how to reuse shared resources, and how to isolate stateful resources.

[0116] Specifically, when assigning tasks to a remote environment, the following methods can be used: The remote computing environment is connected via a network protocol, and the orchestration agent maintains the state of the remote environment pool (available / occupied / initializing).

[0117] The remote environment also follows the principle of "stateless sharing and stateful isolation": dependency caches on remote machines can be reused across tasks, and runtime services are isolated by Task-ID.

[0118] Code synchronization: Changes to the working tree are pushed to a remote environment through a version control system to maintain code consistency.

[0119] In one specific implementation provided in this specification, the resource allocation strategy for each required task is determined based on task complexity, including: Based on the task complexity, determine the resource information corresponding to each required task; When the resource information is stateless, the resource allocation strategy is to reuse the dependency cache and index of the main workspace through symbolic links or shared mounts. When the resource information is stateful, the resource allocation strategy is determined to be to allocate independent port numbers and database instances based on the task instance identifiers of each demand task in order to create isolated workspaces.

[0120] Stateless resources can be understood as read-only resources that do not change with tasks and can be safely shared, such as dependency caches, Language Service Indexes (LSPs), and static analysis artifacts.

[0121] Specifically, stateless resources can also be represented as stateless resource reuse mechanisms. In the case of this stateless resource reuse mechanism, the following operations are included: Identify resource categories: code dependency cache, language service index, static analysis artifacts, build cache, etc.

[0122] Reuse strategy: Map stateless resources from the main workspace to isolated workspaces via symbolic links or shared mounts (read-only).

[0123] Incremental updates: When a new dependency is added to a workspace, incremental updates are performed on the shared cache pool instead of being reinstalled locally.

[0124] Stateful resources can be understood as resources that need to be isolated and used by different tasks using different instances, such as development servers and test databases.

[0125] Specifically, stateful resources can also be represented as stateful resource reuse mechanisms. These mechanisms include the following operations: Each parallel task is assigned a globally unique task instance identifier (Task-ID).

[0126] Stateful resources (development servers, databases, test runners, etc.) are bound to Task-IDs to create independent instances.

[0127] Port number allocation: base port + Task-ID offset (e.g., 3000 + 001 = 3001).

[0128] Database instance: Create a separate database schema or instance (such as test_db_001) based on Task-ID.

[0129] Resource lifecycle is bound to Task-ID: When a task is completed or canceled, the corresponding stateful resources are automatically reclaimed.

[0130] The Task Instance Identifier (Task-ID) can be understood as a unique number assigned to each required task, used to distinguish stateful resource instances of different tasks.

[0131] An isolated workspace can be understood as an independent execution environment created for each task, containing independent ports, database schemas, etc., to avoid mutual interference.

[0132] In one specific implementation provided in this specification, resource information is determined based on task complexity to identify the primary resource consumed by the task. If the resource is stateless, symbolic links or shared mounting are used to allow multiple isolated workspaces of different tasks to read-only reuse the same cache / index from the main workspace. If the resource is stateful, ports (e.g., 3000 + Task-ID) and database instances (e.g., test_db_001) are dynamically allocated based on the Task-ID to create completely isolated workspaces.

[0133] According to the specific implementation methods provided in this specification, a stateless / stateful layered strategy saves storage space. All parallel tasks share a single dependency cache, saving storage space compared to full copying. Furthermore, startup time is shortened; creating the working tree only requires copying the file index (seconds), compared to full environment construction (minutes), thus improving startup speed. Moreover, stateful resources are precisely isolated; independent instances are created for resources requiring isolation (ports, database instances), avoiding unnecessary resource redundancy.

[0134] S2046. Based on the resource allocation strategy corresponding to each requirement task, determine the execution intelligent processing unit corresponding to each task subgraph.

[0135] In one specific embodiment provided in this specification, based on the resource allocation strategy corresponding to each demand task, the execution intelligent processing unit corresponding to each task subgraph is determined, including: Determine the resource allocation strategy corresponding to the initial requirement task, wherein the initial requirement task is any one of the requirement tasks; Select at least two intelligent processing units to be configured from the set of intelligent processing units that meet the resource allocation strategy corresponding to the task with the initial requirements; Determine the unit performance corresponding to each intelligent processing unit to be configured, and sort the intelligent processing units to be configured based on the unit performance to determine the intelligent processing unit corresponding to the initial requirement task.

[0136] The initial requirement task can be understood as any requirement task currently being processed.

[0137] The set of execution intelligent processing units can be understood as a pool of all available computing resources.

[0138] The intelligent processing unit to be configured can be understood as a candidate unit selected from the set that meets the resource strategy of the task.

[0139] Unit performance can be understood as indicators such as the computing power, memory, and response speed of the intelligent processing unit.

[0140] In one specific embodiment provided in this specification, one requirement task is randomly selected from among the various requirement tasks as the initial requirement task. The task attribute information corresponding to the initial requirement task is determined, and based on this task attribute information, at least two intelligent processing units to be configured are selected from the set of intelligent processing units to be configured. The intelligent processing units to be configured are then sorted according to their performance priority to obtain the intelligent processing units corresponding to the initial requirement task.

[0141] In one example, suppose there are three sequentially dependent requirement tasks in the task subgraph, and the execution order of these tasks is requirement task 1, requirement task 2, and requirement task 3. Based on this, the corresponding intelligent processing unit for each requirement task is determined according to its task attribute information. Since the requirement tasks are sequentially dependent, the intelligent processing unit corresponding to requirement task 1 is used to process the requirement task according to its execution order. After requirement task 1 is processed, the intelligent processing unit corresponding to requirement task 1 is used again based on the task attribute information of requirement task 2. If so, requirement task 2 can continue to use the intelligent processing unit corresponding to requirement task 1, thereby saving the resources used by the intelligent processing unit in the task subgraph.

[0142] In another example, suppose there are two parallel dependent task requirements in the task subgraph, namely task requirement 1 and task requirement 2. Based on this, the execution intelligent processing unit corresponding to each task requirement is determined according to the task attribute information. That is, the execution intelligent processing unit corresponding to task requirement 1 performs the processing of task requirement 1. In addition, to reduce processing time and improve processing efficiency, task requirement 2 can also be processed in parallel according to the execution intelligent processing unit corresponding to task requirement 2.

[0143] According to a specific implementation provided in this specification, each intelligent processing unit operates in a physically independent working directory, allowing different intelligent processing units to modify files in their respective working trees. Physical isolation ensures that there is no possibility of concurrent writing to the same file. Furthermore, intermediate states are completely isolated; for example, the semi-finished code of intelligent processing unit 1 does not affect the compilation and testing environment of intelligent processing unit 2. Moreover, complete change traceability is provided; all modifications to each requirement are on independent branches, making it clear to trace the origin of each change.

[0144] Step 206: Assign the required tasks corresponding to each subgraph to their respective execution intelligent processing units, and obtain the execution results sent by each execution intelligent processing unit, wherein each execution intelligent processing unit executes the required tasks corresponding to each subgraph in parallel.

[0145] The execution intelligent processing unit can be understood as a computing entity that can independently execute required tasks. It can be a thread, process, container, virtual machine, or remote computing environment, and has the ability to understand, edit, run, and test code.

[0146] The execution result can be understood as the result obtained by the execution intelligent processing unit on each task subgraph. For example, the execution result may include code updates, test reports, and other information.

[0147] In one specific embodiment provided in this specification, based on the resource requirement characteristics of the task corresponding to each subgraph, an execution intelligent processing unit with a corresponding isolation environment (isolation environment can also be understood as isolation workspace; the two are used alternately, but their meanings should be understood to be consistent) is matched from the available computing resource pool. The execution intelligent processing units corresponding to each task subgraph work in parallel to obtain the execution results sent by each intelligent processing unit for each task subgraph.

[0148] In one example, the execution intelligent processing unit can determine the execution results corresponding to each required task in the following manner. Specifically: Read code and understand context in the assigned isolated workspace; navigate and edit code using shared stateless resources (LSP index, dependency cache); run and test using stateful resources (development server, test database) bound to Task-ID; periodically report task progress (in progress / completed / blocked / requires help) to the orchestration agent.

[0149] Step 208: Determine the target processing result based on each execution result.

[0150] Specifically, the intelligent merging processing unit is invoked. When an execution result corresponding to any required task is generated, the execution result is distributed to the intelligent merging processing unit. Based on the intelligent merging processing unit, the execution results are merged to obtain the target processing result.

[0151] The target processing result can be understood as the output result obtained by integrating and merging the execution results of all the required tasks, such as complete functional code.

[0152] In one specific embodiment provided in this specification, the execution results sent by each intelligent processing unit for each task subgraph are collected, and the final target processing result is obtained through merging, conflict resolution, and other processes.

[0153] In one specific implementation provided in this specification, the target processing result is determined based on each execution result, including: Invoke the merging intelligent processing unit; Once the execution result corresponding to any required task is generated, it is distributed to the merging intelligent processing unit, which then merges the execution results to obtain the target processing result.

[0154] The merging intelligent processing unit can be understood as an intelligent agent responsible for merging multiple execution results (code changes) and can automatically resolve conflicts.

[0155] In one specific embodiment provided in this specification, a merging intelligent processing unit is invoked to perform a merging operation. During this process, as soon as any execution result is generated, it is immediately distributed to the merging intelligent processing unit: an incremental merging strategy is adopted, without waiting for all tasks to complete. The merging intelligent processing unit merges the execution results into the main code. The target processing result is obtained and output to the code repository.

[0156] In one specific embodiment provided in this specification, during the merging process, the orchestration intelligent processing unit is also used for real-time monitoring, specifically as follows: Progress tracking: Maintain a global progress view, showing the completion percentage, current step, and estimated remaining time for each task.

[0157] Anomaly detection: Identify prolonged periods without progress (freezing detection), repeated retries (loop detection), and abnormal error rates (failure detection).

[0158] Dynamic intervention: For stuck tasks: analyze the cause, terminate and reassign to a new execution intelligent processing unit if necessary; For insufficient resources: dynamically expand (e.g., upgrade from the local work tree to a remote environment); For newly discovered dependencies between requirements: dynamically adjust the Demand-DAG and suspend the affected requirement tasks.

[0159] In one specific embodiment provided in this specification, during the merging process, when a conflict occurs, the method further includes: In response to the detection of code conflicts in the execution results between task subgraphs, the intelligent merging processing unit is invoked to determine the modification intent of each task subgraph and generate fusion code that satisfies the modification intent. Based on the fusion code of each task subgraph, the target processing result is obtained.

[0160] Code conflicts can be understood as the execution results of two parallel tasks modifying the same area of ​​the same code file, or being logically incompatible.

[0161] The intention to modify can be understood as the original functional goal or technical improvement objective that each requirement or task was intended to achieve.

[0162] In one example, when code conflicts are detected between the execution results of various task subgraphs, a large language model is used to read the requirement descriptions and code change summaries of each conflicting task subgraph to understand the purpose of the modifications. Based on this, the code scope of the modifications corresponding to the conflicting task subgraphs is analyzed to identify the program symbols that influence each other. It is then determined whether the two modifications are semantically orthogonal; if orthogonal, they are directly merged; otherwise, a conflict resolution step is initiated. During conflict resolution, fused code that satisfies the requirements of both parties is generated. Compilation checks and automated tests are then performed on the fused code.

[0163] In one specific implementation provided in this specification, in response to the detection of code conflicts in the execution results between task subgraphs, the reason for the modification is understood by reading the requirement description and change summary. The conflicting areas are automatically rewritten so that the final code satisfies all intents simultaneously. The conflicting code is replaced based on the merged code, and the merging process continues.

[0164] This includes determining the modification intent of each task subgraph and generating fusion code that satisfies the modification intent, including: Read the task descriptions of the conflicting requirements and restore the modification intentions of each requirement. Determine whether there is any semantic overlap between the modification intentions of each requirement task; If there is an intersection, it is directly merged to generate fused code that satisfies the modification intent; If there is no overlap, modify the modification intent of each requirement task and generate the fusion code.

[0165] Semantic intersection can be understood as whether two modification intentions can coexist logically without contradiction. For example, "adding parameter validation" and "modifying log format" have intersection (can coexist); "changing the return value to asynchronous" and "adding a synchronous caller" have no intersection (contradictory).

[0166] In one specific implementation provided in this specification, the target is extracted from the task text. Logical analysis and domain knowledge are used to determine whether the modification intentions of each requirement task semantically overlap. If overlap exists, the code from both sides can be simply concatenated or its order adjusted. If no overlap exists, the code in the conflicting areas is rewritten to simultaneously satisfy the original intention (or a compromise).

[0167] In one example, when a semantic conflict is detected, the orchestration intelligent processing unit assigns a merging intelligent processing unit (which can be the orchestration intelligent processing unit itself or a dedicated third intelligent processing unit) to perform the following steps: Intent recovery: Read the requirement descriptions and change summaries of the two parallel modifications to understand "why this modification was made".

[0168] Impact analysis: Analyze the scope of the code modified by both parties and identify the symbols (functions, types, interfaces) that have cross-influence.

[0169] Compatibility assessment: If two modifications are semantically orthogonal (e.g., A adds parameter validation, B modifies the log format), they are merged directly; if there are semantic contradictions (e.g., A changes the return value from synchronous to asynchronous, B adds a synchronous caller), the conflicting area needs to be rewritten.

[0170] The rewriting of conflict areas can be performed as follows: Conflict resolution: Based on the understanding of the intentions of both parties, generate fused code that satisfies both requirements; Self-verification: Perform compilation checks and unit tests on the fused code to ensure the correctness of the merged result.

[0171] According to the specific implementation methods provided in this specification, parallelizable tasks are automatically identified and allocated to independent execution units through task-directed graph and subgraph partitioning, maximizing parallel execution efficiency and shortening the overall delivery cycle. Based on semantic analysis and code impact scope prediction, potentially conflicting tasks are pre-defined as serial dependencies, avoiding complex conflicts during later merging. Incremental merging strategies expose conflicts early, reducing merging difficulty. Stateless resource sharing avoids repeated downloads and builds, saving storage and computation time. Stateful resources are isolated by Task-ID (port, database) to prevent interference between parallel tasks and ensure data security. The merging intelligent processing unit can restore the modification intent and generate fused code, reducing manual intervention and improving automation. For conflicts that cannot be automatically resolved, a clear conflict context is provided for manual decision-making. Execution intelligent processing units are dynamically allocated based on task complexity, and the best unit can be selected based on performance ranking to achieve load balancing and performance optimization. Furthermore, since there are no directed edges between task subgraphs, the failure of one subgraph will not block other subgraphs (unless dependencies are dynamically adjusted). Self-verification during the merging process further ensures output quality.

[0172] The following is in conjunction with the appendix Figures 3A-3B Taking the task orchestration method provided in this specification as an example of its application in the simultaneous development of multiple tasks with different requirements, the task orchestration method will be further explained. Figure 3A A flowchart of a directed graph for constructing a task is shown in one embodiment of this specification, specifically including the following steps.

[0173] In response to the orchestration and scheduling agent receiving multiple development request tasks, the following operations are performed: Step 312: In the semantic analysis layer: determine the requirement attribute information corresponding to each requirement task.

[0174] Parse the requirement task description corresponding to each requirement task to obtain the functional attribute information and business attribute information of each requirement task.

[0175] Based on the orthogonality between the functional attribute information corresponding to each requirement task, determine the degree of independence between each requirement task and identify the dependency relationship between requirement tasks.

[0176] Step 314: At the code analysis layer: predict the scope of code impact for each requirement task, and determine the set of modification files corresponding to each requirement task based on the mapping between the requirement task description and the code library.

[0177] Determine if there is any overlap between the task modification files corresponding to each requirement task. If there is no overlap, mark each requirement task as safe to run in parallel. If there is overlap, analyze whether there is any overlap in the modification areas between the task modification files.

[0178] Step 316: Construct a directed acyclic graph.

[0179] Each requirement task is treated as a node, and directed edges are determined between them based on their dependencies. Each node corresponding to a requirement task contains node attribute information, which is determined based on the conflict risk level (low / medium / high) and task complexity assessment (lightweight / medium / heavyweight) of each requirement task.

[0180] In one specific embodiment provided in this specification, based on the acquired task requirements, each task is analyzed from both semantic and code perspectives to construct a directed task graph corresponding to each task. Based on this, resource scheduling and environment allocation are performed according to the dependencies between nodes representing the task requirements in the directed task graph. Figure 3B A flowchart illustrating a resource scheduling and allocation method according to an embodiment of this specification is shown, specifically including the following steps.

[0181] Step 322: Determine the dependencies between nodes based on the task directed graph.

[0182] In one example, if there is no dependency, the step 3221 is marked as feasible; if there is a dependency, the step 3222 is executed to determine the execution order constraint; and if there is a partial dependency, the step 3223 is executed to assess the conflict risk level.

[0183] Step 324: Perform resource scheduling and environment allocation based on dependencies.

[0184] In one example, the task complexity corresponding to each requirement task is evaluated. If the task complexity is lightweight, step 3241 is executed to allocate a local working tree; if the task complexity is heavyweight, step 3242 is executed to allocate a remote computing environment.

[0185] Furthermore, if step 3241 is executed, step 3243 is executed to create a version control isolated workspace; if step 3242 is executed, step 3244 is executed to initialize the remote execution environment.

[0186] Step 326: Mount stateless shared resources according to the execution environment of each required task.

[0187] Step 328: Create a stateful isolated instance and bind the task instance identifier.

[0188] Furthermore, based on the above, corresponding intelligent processing units are configured for each required task.

[0189] In one example, based on the dependencies between the various task requirements, the execution intelligent processing unit processes each task in parallel. The processing results are then sent to the merging intelligent processing unit.

[0190] The intelligent processing unit performs conflict detection on each required task and merges the processing results into the main branch. Among these, Figure 3C This specification illustrates a flowchart of a combined intelligent processing unit process according to an embodiment, including the following steps: Step 332: Merge the processing results of each requirement task into the main branch according to the completion order of each requirement task.

[0191] Step 334: Perform conflict detection on each required task.

[0192] If there are textual conflicts between the task requirements, proceed to step 3341 to process them using the three-way merging algorithm. If there are no conflicts between the task requirements, proceed to step 3342 for automatic merging. If there are semantic conflicts between the task requirements, proceed to step 3343 for semantic understanding and autonomous resolution by the intelligent processing unit.

[0193] Step 336: Merge and verify.

[0194] Step 338: Perform integration tests on the main branch and obtain the test results.

[0195] In one example, if the test passes, the working tree and stateful resources are reclaimed, and the result is reported to the orchestration intelligent processing unit. If the test fails, the reason for the failure is located and fed back to the corresponding execution intelligent processing unit for processing.

[0196] In a specific embodiment provided in this specification, the above-mentioned Figures 3A to 3B This can be understood as: performing semantic analysis and code impact range prediction on each requirement task, constructing a requirement dependency directed acyclic graph, where nodes in the requirement dependency directed acyclic graph are used to represent requirement tasks, directed edges are used to represent execution order constraints between each requirement task, unconnected nodes represent requirements that can be executed in parallel, and each node is accompanied by conflict risk level and task complexity assessment information.

[0197] Based on the task complexity assessment information corresponding to each node in the demand-dependent directed acyclic graph, resource allocation decisions are made.

[0198] For stateless resources, the dependency cache and indexes of the main workspace can be reused through symbolic links or shared mounts.

[0199] For stateful resources, separate port numbers and database instances are assigned based on the task instance identifiers of each demand task to create isolated workspaces.

[0200] When the directed acyclic graph of demand dependencies indicates parallel execution, multiple intelligent processing units are launched to run each demand task in parallel in their respective isolated workspaces, and the execution results of each demand task are obtained.

[0201] An incremental merging strategy is adopted, and once the execution result corresponding to any requirement task is generated, it is immediately merged back into the main branch.

[0202] If a code conflict is detected, the intelligent merging processing unit is invoked to restore the modification intentions of both conflicting parties and generate fused code that satisfies the intentions of both parties.

[0203] Based on the merged code of each task and the conflict-free execution results, update the main branch code.

[0204] This manual further explains the process in five stages, using the following examples.

[0205] Phase 1: Parallel Analysis of Multiple Requirements In this phase, semantic analysis is performed on each requirement task to parse the functional modules involved in each requirement task. For example, task 001 corresponds to the user authentication module. Task 002 corresponds to the payment module. Task 003 corresponds to the order module.

[0206] Code analysis: Based on the historical mapping or static analysis of the codebase, predict the set of code files that may be modified for each requirement task.

[0207] Based on the results of semantic and code analysis, the dependencies (serial or parallel) between the required tasks are determined, and a directed graph of tasks is constructed.

[0208] For example, if three tasks involve different modules and have no overlap in files, they are guaranteed to be independent of each other and can be executed in parallel.

[0209] The dependency analysis results are output as a conclusion on dependency relationships for subsequent scheduling.

[0210] For example, the three tasks have no dependencies and can all be performed in parallel.

[0211] Phase Two: Resource Scheduling and Environmental Allocation In this phase, the dependency graph is used to divide the tasks into a subset that can be executed in parallel and a chain of tasks that must be executed sequentially.

[0212] For example, all tasks can be performed in parallel.

[0213] Estimate the workload and resource consumption (CPU, memory, database connection, etc.) of each task to assess task complexity.

[0214] For example, Task 001: Medium (requires calling a third-party SMS interface). Task 002: Lightweight (only modifies the log format). Task 003: Heavyweight (requires analyzing slow queries and rebuilding the index).

[0215] Choose the appropriate execution environment type (local or remote) for the task based on its complexity.

[0216] For example, task 001 and 002 correspond to the local workstation. Task 003 corresponds to the remote high-performance computing environment.

[0217] Tasks are bound to specific physical or virtual computing resources. For example, task 001 corresponds to local working tree A. Task 002 corresponds to local working tree B. Task 003 corresponds to remote environment C.

[0218] Create an isolated working directory (working tree) for each task and start the corresponding execution intelligent processing unit.

[0219] Make reusable read-only resources (such as dependency caches and LSP indexes) available to all workspaces via symbolic links or shared mounts.

[0220] For example, all workspaces share the same maven-repo directory and node_modules cache.

[0221] Assign a unique Task-ID to each task and create stateful resources such as a separate port number and database instance accordingly.

[0222] Phase 3: Parallel Execution and Progress Monitoring Each execution intelligence processing unit independently completes development tasks (writing code, running tests, etc.) in its own isolated workspace.

[0223] For example, Intelligent Processing Unit 1 adds SMS verification code logic to the login function in local working tree A. Intelligent Processing Unit 2 modifies the payment log format in local working tree B. Intelligent Processing Unit 3 analyzes the order query SQL and creates a new index in remote environment C.

[0224] The orchestration intelligent processing unit continuously monitors the progress, error rate, and abnormal status of each executing intelligent processing unit, such as whether it is stuck.

[0225] For example, it was detected that the execution time of intelligent processing unit 3 was much longer than expected (possibly due to database lock waits).

[0226] When an anomaly occurs, the orchestration intelligent processing unit can take automatic action (such as terminating the task, reassigning, rolling back changes, or requesting manual intervention).

[0227] For example, migrate requirement 003 from remote environment C to another, more robust remote environment D, and restore previously completed progress.

[0228] Phase Four: Incremental Merging and Semantic Conflict Resolution Instead of waiting for all tasks to be completed, each completed requirement is immediately merged back into the main branch (incremental merging).

[0229] For example, if the intelligent processing unit 2 completes first (log format modification), it is immediately merged into the main branch.

[0230] During the merging process, not only are text conflicts checked, but logical contradictions are also analyzed (for example, one requirement modifies the function signature, while another requirement calls the function).

[0231] For example, suppose task 001 modifies the return type of StringHelper.format(), while task 002 adds logging code that calls this method, indicating that a semantic conflict has been detected.

[0232] Use a three-way merge (original version, two modified versions) to perform text-level merging, automatically handling non-overlapping changes.

[0233] For example, for changes that do not conflict, Git-style automatic merging can be used directly.

[0234] When a semantic conflict is detected, the merging intelligent processing unit reads the requirement descriptions of both conflicting parties, understands their respective intentions, and generates fusion code.

[0235] For example, intent 001 is "improving readability," while intent 002 is "logging the call chain." The intelligent processing unit rewrites the logging call section to adapt it to the new return value type.

[0236] The results of merging multiple increments are integrated into the final codebase state.

[0237] For example, merge the changes to requirement task 002, requirement task 001, and requirement task 003 in sequence.

[0238] The merged code is automatically run for compilation checks and unit tests to ensure correctness.

[0239] Phase 5: Integration, Validation, and Environmental Recycling Once all requirements are merged, run a full integration test suite and static analysis on the final main codebase. For example, execute end-to-end test scripts (user login + payment + order query).

[0240] Output the result of whether the test passed or failed.

[0241] If the integration test fails, the system analyzes which requirement change caused the failure and assigns the corresponding intelligent processing unit to fix it.

[0242] For example, if an order query test fails and the bug is found to be introduced by the index optimization of task 003, the execution intelligent processing unit corresponding to task 003 will be notified to fix it.

[0243] After successful verification, delete all temporary workspaces, release ports, and delete the test database instance, etc.

[0244] According to the embodiments provided above in this specification, by constructing a directed task graph for multiple requirement tasks, the shared information between each requirement task can be clearly defined. This allows the orchestration intelligent processing unit to determine the task metadata corresponding to each requirement task, thus eliminating redundant arrangement and saving computing resources. Furthermore, the orchestration intelligent processing unit determines task instructions based on each requirement task, and drives the execution intelligent processing unit to process each requirement task according to the task instructions. During this process, based on the independence between each requirement task, each execution intelligent processing unit can process each requirement task in parallel, thereby saving execution time. Further, by using a stateless / stateful layered execution approach, storage space is saved and startup speed is improved. In addition, independent instances are created for resources that need to be isolated (ports, database instances) to avoid unnecessary resource redundancy. Each execution intelligent processing unit works in a physically independent working directory. Different intelligent processing units modify files in their respective working trees, and physical isolation ensures that there is no possibility of concurrent writing to the same file. Intermediate states are completely isolated; for example, the semi-finished code of execution intelligent processing unit A does not affect the compilation and testing environment of execution intelligent processing unit B. All modifications to each requirement are on independent branches, making it clear to trace the origin of each change. Furthermore, in this specification, based on the code intent understanding of the orchestration intelligent processing unit, it is possible to identify "what purpose this modification is for".

[0245] Corresponding to the above method embodiments, this specification also provides embodiments of a task orchestration apparatus. Figure 4 A schematic diagram of a task orchestration apparatus according to one embodiment of this specification is shown. Figure 4 As shown, the device includes: The acquisition unit 402 is configured to acquire at least two requirement tasks and construct a task directed graph based on each requirement task, wherein the nodes of the task directed graph are used to represent requirement tasks, and the directed edges are used to represent the execution order between each requirement task.

[0246] The determining unit 404 is configured to, when the task directed graph includes at least two task subgraphs, match an execution intelligent processing unit with an isolated environment based on the resource requirement characteristics of the task corresponding to each task subgraph, wherein the nodes between the task subgraphs do not have directed edges.

[0247] The execution unit 406 is configured to assign the requirement tasks corresponding to each subgraph to their respective execution intelligent processing units and obtain the execution results sent by each execution intelligent processing unit, wherein each execution intelligent processing unit executes the requirement tasks corresponding to each subgraph in parallel.

[0248] Processing unit 408 is configured to call the merging intelligent processing unit, and when an execution result corresponding to any required task is generated, distribute the execution result to the merging intelligent processing unit, and merge the execution results based on the merging intelligent processing unit to obtain the target processing result.

[0249] Furthermore, the acquisition unit 402 is further configured as follows: Analyze the task semantics corresponding to each requirement task to obtain the requirement attribute information and code attribute information corresponding to each requirement task; Based on the requirement attribute information and code attribute information corresponding to each requirement task, the dependency relationship between each requirement task is determined. Based on dependencies, determine the execution order of each required task; Each requirement task is treated as a node, and the execution order between each requirement task is treated as a directed edge, thus constructing a task directed graph.

[0250] Furthermore, the acquisition unit 402 is further configured as follows: Based on the requirement attribute information corresponding to each requirement task, determine the relationship between each requirement task; Based on the code attribute information corresponding to each requirement task, determine the set of code files corresponding to each requirement task; Based on the relationships between various requirements and tasks, as well as the set of code files, the dependencies between various requirements and tasks are determined.

[0251] Furthermore, the acquisition unit 402 is further configured as follows: When there is no association between the various requirements tasks and the sets of code files corresponding to the various requirements tasks have no overlap, the dependency between the various requirements tasks is determined as parallel dependency; If the relationships between the various requirements tasks are related, and / or the sets of code files corresponding to the various requirements tasks overlap, then the dependencies between the various requirements tasks are determined as serial dependencies.

[0252] Furthermore, unit 404 is also configured as follows: Determine the dependencies between the various required tasks; Based on the dependencies between the various task requirements, nodes in the directed graph of the task that are not connected by directed edges are divided into the same task subgraph, resulting in at least two task subgraphs.

[0253] Furthermore, unit 404 is further configured as follows: Determine each requirement task corresponding to the initial task subgraph, wherein the initial task subgraph is any one of the task subgraphs; Determine the task complexity for each requirement task, and determine the resource allocation strategy for each requirement task based on the task complexity. Based on the resource allocation strategy corresponding to each task requirement, the execution intelligent processing unit corresponding to each task subgraph is determined.

[0254] Furthermore, unit 404 is further configured as follows: Determine the resource allocation strategy corresponding to the initial requirement task, wherein the initial requirement task is any one of the requirement tasks; Select at least two intelligent processing units to be configured from the set of intelligent processing units that meet the resource allocation strategy corresponding to the task with the initial requirements; Determine the unit performance corresponding to each intelligent processing unit to be configured, and sort the intelligent processing units to be configured based on the unit performance to determine the intelligent processing unit corresponding to the initial requirement task.

[0255] Furthermore, unit 404 is further configured as follows: Based on the task complexity, determine the resource information corresponding to each required task; When the resource information is stateless, the resource allocation strategy is to reuse the dependency cache and index of the main workspace through symbolic links or shared mounts. When the resource information is stateful, the resource allocation strategy is determined to be to allocate independent port numbers and database instances based on the task instance identifiers of each demand task in order to create isolated workspaces.

[0256] Furthermore, unit 404 is also configured as follows: In response to the detection of code conflicts in the execution results between task subgraphs, the intelligent merging processing unit is invoked to determine the modification intent of each task subgraph and generate fusion code that satisfies the modification intent. Based on the fusion code of each task subgraph, the target processing result is obtained.

[0257] Furthermore, unit 404 is further configured as follows: Read the task descriptions of the conflicting requirements and restore the modification intentions of each requirement. Determine whether there is any semantic overlap between the modification intentions of each requirement task; If there is an intersection, it is directly merged to generate fused code that satisfies the modification intent; If there is no overlap, modify the modification intent of each requirement task and generate the fusion code.

[0258] Furthermore, the acquisition unit 402 is further configured as follows: Input at least two requirements into the orchestration intelligent processing unit; The task semantics of each required task are determined in the orchestration intelligent processing unit, and based on the task semantics of each required task, the shared information between each required task is determined to obtain task metadata. Based on the orchestration intelligent processing unit, a task directed graph is constructed according to the task semantics of each required task, and task instructions are generated. Based on the task instructions, the orchestration intelligent processing unit is controlled to send the task metadata to the execution intelligent processing unit.

[0259] 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.

[0260] See Figure 5 , Figure 5 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 at least two required tasks to server 200; Server 200 is used to acquire at least two requirement tasks and construct a task directed graph based on each requirement task, wherein the nodes of the task directed graph represent requirement tasks, and the directed edges represent the execution order between requirement tasks; when the task directed graph includes at least two task subgraphs, it determines the execution intelligent processing unit corresponding to each task subgraph, wherein the nodes between task subgraphs do not have directed edges; it assigns the requirement tasks corresponding to each subgraph to their respective execution intelligent processing units, obtains the execution results sent by each execution intelligent processing unit, wherein each execution intelligent processing unit executes the requirement tasks corresponding to each subgraph in parallel; it determines the target processing result based on each execution result; and it sends the target processing result to client 100. Client 100 is also used to receive the target processing results sent by server 200.

[0261] 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.

[0262] 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 task orchestrations based on the data streams, and push the task orchestrations to other clients that have established communication.

[0263] 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.

[0264] 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.

[0265] 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.

[0266] 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.

[0267] Figure 6A block diagram of a computing device 600 according to an embodiment of this application is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.

[0268] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. 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 640 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.

[0269] In one embodiment of this application, the aforementioned components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 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.

[0270] The computing device 600 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 600 can also be a mobile or stationary server.

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

[0272] 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.

[0273] 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.

[0274] 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.

[0275] 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.

[0276] 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.

[0277] 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.

[0278] 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.

[0279] 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.

[0280] 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.

[0281] 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 at least two requirement tasks and construct a task directed graph based on each requirement task, wherein the nodes of the task directed graph represent requirement tasks and the directed edges represent the execution order between each requirement task. When the task directed graph includes at least two task subgraphs, an execution intelligent processing unit with an isolated environment is matched according to the resource requirement characteristics of the task corresponding to each task subgraph, wherein the nodes between each task subgraph do not have directed edges. The requirements tasks corresponding to each subgraph are assigned to their respective execution intelligent processing units, and the execution results sent by each execution intelligent processing unit are obtained. Among them, each execution intelligent processing unit executes the requirements tasks corresponding to each subgraph in parallel. The intelligent merging processing unit is invoked. If an execution result is generated for any required task, the execution result is distributed to the intelligent merging processing unit. The execution results are then merged based on the intelligent merging processing unit to obtain the target processing result.

2. The method as described in claim 1, wherein constructing a task-directed graph based on each requirement task includes: Analyze the task semantics corresponding to each requirement task to obtain the requirement attribute information and code attribute information corresponding to each requirement task; Based on the requirement attribute information and code attribute information corresponding to each requirement task, the dependency relationship between each requirement task is determined. Based on dependencies, determine the execution order of each required task; Each requirement task is treated as a node, and the execution order between each requirement task is treated as a directed edge, thus constructing a task directed graph.

3. The method as described in claim 2, wherein the dependency relationship between each requirement task is determined based on the requirement attribute information and code attribute information corresponding to each requirement task, including: Based on the requirement attribute information corresponding to each requirement task, determine the relationship between each requirement task; Based on the code attribute information corresponding to each requirement task, determine the set of code files corresponding to each requirement task; Based on the relationships between various requirements and tasks, as well as the set of code files, the dependencies between various requirements and tasks are determined.

4. The method as described in claim 3, wherein determining the dependencies between various requirement tasks based on the association between them and the code file set includes: When there is no association between the various requirements tasks and the sets of code files corresponding to the various requirements tasks have no overlap, the dependency between the various requirements tasks is determined as parallel dependency; If the relationships between the various requirements tasks are related, and / or the sets of code files corresponding to the various requirements tasks overlap, then the dependencies between the various requirements tasks are determined as serial dependencies.

5. The method of claim 1, wherein, when the task directed graph includes at least two task subgraphs, before determining the execution intelligent processing unit corresponding to each task subgraph, the method further includes: Determine the dependencies between the various required tasks; Based on the dependencies between the various task requirements, nodes in the directed graph of the task that are not connected by directed edges are divided into the same task subgraph, resulting in at least two task subgraphs.

6. The method as described in claim 1, wherein an execution intelligent processing unit with an isolated environment is matched according to the resource requirement characteristics of the requirement tasks corresponding to each task subgraph, comprising: Determine each requirement task corresponding to the initial task subgraph, wherein the initial task subgraph is any one of the task subgraphs; Determine the task complexity for each requirement task, and determine the resource allocation strategy for each requirement task based on the task complexity. Based on the resource allocation strategy corresponding to each task requirement, the execution intelligent processing unit corresponding to each task subgraph is determined.

7. The method as described in claim 6, wherein the execution intelligent processing unit corresponding to each task subgraph is determined based on the resource allocation strategy corresponding to each demand task, comprising: Determine the resource allocation strategy corresponding to the initial requirement task, wherein the initial requirement task is any one of the requirement tasks; Select at least two intelligent processing units to be configured from the set of intelligent processing units that meet the resource allocation strategy corresponding to the task with the initial requirements; Determine the unit performance corresponding to each intelligent processing unit to be configured, and sort the intelligent processing units to be configured based on the unit performance to determine the intelligent processing unit corresponding to the initial requirement task.

8. The method as described in claim 6, wherein determining the resource allocation strategy corresponding to each required task based on task complexity includes: Based on the task complexity, determine the resource information corresponding to each required task; When the resource information is stateless, the resource allocation strategy is to reuse the dependency cache and index of the main workspace through symbolic links or shared mounts. When the resource information is stateful, the resource allocation strategy is determined to be to allocate independent port numbers and database instances based on the task instance identifiers of each demand task in order to create isolated workspaces.

9. The method of claim 1, further comprising: In response to the detection of code conflicts in the execution results between task subgraphs, the intelligent merging processing unit is invoked to determine the modification intent of each task subgraph and generate fusion code that satisfies the modification intent. Based on the fusion code of each task subgraph, the target processing result is obtained.

10. The method of claim 9, wherein determining the modification intent of each task subgraph and generating fusion code that satisfies the modification intent, includes: Read the task descriptions of the conflicting requirements and restore the modification intentions of each requirement. Determine whether there is any semantic overlap between the modification intentions of each requirement task; If there is an intersection, it is directly merged to generate fused code that satisfies the modification intent; If there is no overlap, modify the modification intent of each requirement task and generate the fusion code.

11. The method of claim 1, wherein at least two requirement tasks are obtained, and a task-directed graph is constructed based on each requirement task, comprising: Input at least two requirements into the orchestration intelligent processing unit; The task semantics of each required task are determined in the orchestration intelligent processing unit, and based on the task semantics of each required task, the shared information between each required task is determined to obtain task metadata. Based on the orchestration intelligent processing unit, a task directed graph is constructed according to the task semantics of each required task, and task instructions are generated. Based on the task instructions, the orchestration intelligent processing unit is controlled to send the task metadata to the execution intelligent processing unit.

12. A task orchestration apparatus, comprising: The acquisition unit is configured to acquire at least two requirement tasks and construct a task directed graph based on each requirement task, wherein the nodes of the task directed graph are used to represent requirement tasks, and the directed edges are used to represent the execution order between each requirement task. The determining unit is configured to, when the task directed graph includes at least two task subgraphs, match an execution intelligent processing unit with an isolated environment based on the resource requirement characteristics of the task corresponding to each task subgraph, wherein the nodes between the task subgraphs do not have directed edges. The execution unit is configured to assign the required tasks corresponding to each subgraph to their respective execution intelligent processing units, and obtain the execution results sent by each execution intelligent processing unit, wherein each execution intelligent processing unit executes the required tasks corresponding to each subgraph in parallel. The processing unit is configured to invoke the merging intelligent processing unit, and in the case of generating the execution result corresponding to any required task, distribute the execution result to the merging intelligent processing unit, and merge the execution results based on the merging intelligent processing unit to obtain the target processing result.

13. A task orchestration system, the task orchestration system comprising an orchestration intelligent processing unit, at least one execution intelligent processing unit, and a merging intelligent processing unit, comprising: The orchestration intelligent processing unit is used to acquire at least two requirement tasks and construct a task directed graph based on each requirement task. The nodes of the task directed graph represent requirement tasks, and the directed edges represent the execution order between requirement tasks. When the task directed graph includes at least two task subgraphs, it matches execution intelligent processing units with isolated environments based on the resource requirement characteristics of the requirement tasks corresponding to each task subgraph. The nodes between task subgraphs do not have directed edges. The requirement tasks corresponding to each subgraph are assigned to their respective execution intelligent processing units, and the execution results sent by each execution intelligent processing unit are obtained. Each execution intelligent processing unit is used to execute the required tasks corresponding to each subgraph in parallel; The intelligent merging processing unit is used to perform conflict detection and incremental merging on each execution result to obtain the target processing result.

14. 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 11.

15. 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 11.

16. 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 11.

Images