A task execution method and system
By breaking down a task into multiple parallelizable subtasks and scheduling them using a dependency graph, the problems of increased task execution time and low execution accuracy in existing technologies are solved, achieving efficient and accurate task execution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BAIYANG TIMES (BEIJING) TECH CO LTD
- Filing Date
- 2026-04-28
- Publication Date
- 2026-07-21
AI Technical Summary
Existing AI systems based on large language models suffer from problems such as linearly increasing task time with complexity, low execution efficiency, and low execution accuracy due to the lack of explicit dependency modeling between subtasks.
The target task is broken down into multiple subtasks that can be executed in parallel. Corresponding subtask agents are created, and the subtask agents are launched in parallel. The tasks are executed based on the task dependency graph, and the execution results are integrated. By combining the atomic task acquisition mechanism with the dependency graph, race conditions and duplication of work can be avoided.
By executing subtasks in parallel and relying on the scheduling of the relational graph, the accuracy and efficiency of task execution are improved, and conflicts and repetitive work under multi-agent concurrency are avoided.
Smart Images
Figure CN122431836A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of artificial intelligence technology, and in particular to a task execution method and system. Background Technology
[0002] In recent years, AI systems based on large language models have been increasingly used in task planning and execution. Current technologies often employ a monolithic architecture, where a single model instance handles the entire task. However, monolithic agents struggle to automatically break down macroscopic tasks into a set of subtasks that can be executed in parallel. Even when tasks are manually broken down, the model still needs to process each subtask sequentially, failing to achieve true parallel execution. This results in the overall task time increasing linearly with complexity, leading to low execution efficiency. Furthermore, in scenarios where subtasks have temporal or data dependencies, the monolithic architecture lacks explicit dependency modeling, resulting in low execution accuracy.
[0003] In conclusion, improving the accuracy and efficiency of task execution is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0004] In view of this, this application provides a task execution method and system, which aims to improve the accuracy and efficiency of task execution.
[0005] Firstly, this application provides a task execution method, including: The target task is broken down into multiple subtasks that can be executed in parallel; For each of the multiple subtasks that can be executed in parallel, a corresponding subtask agent is created; Write the multiple executable subtasks into a shared task queue; Based on the dependencies between the multiple parallel executable subtasks, a task dependency graph is established; All the subtask agents are launched in parallel, so that the subtask agents atomically retrieve tasks from the shared task queue and execute tasks based on the task dependency graph; The execution results of all the sub-task agents are integrated to obtain the execution result of the target task.
[0006] Optionally, the step of decomposing the target task into multiple subtasks that can be executed in parallel includes: In response to the user inputting the target task, the complexity of the target task is evaluated, and the complexity evaluation result is obtained; Based on the complexity assessment results, determine whether to trigger the team derivation mechanism; If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
[0007] Optionally, the step of decomposing the target task into multiple subtasks that can be executed in parallel includes: In response to the user input of the target task, a task complexity score is calculated based on a complexity evaluation algorithm by analyzing the number of code modules involved in the target task, cross-service dependencies, and estimated lines of code. If the task complexity score is greater than the task complexity score threshold, the team derivation mechanism is triggered; if the task complexity score is less than or equal to the complexity score threshold, the team derivation mechanism is not triggered. If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
[0008] Optionally, after creating corresponding subtask agents for the plurality of parallel executable subtasks, the method further includes: Create a corresponding context window for each of the subtask agents.
[0009] Optionally, when the subtask agent performs a task, the method further includes: Communication between the subtask agents is achieved by subscribing to or publishing message streams.
[0010] Optionally, after integrating the execution results of all the sub-task agents to obtain the execution result of the target task, the method further includes: Destroy all the described subtask agents.
[0011] Optionally, the method further includes: Continuously monitor the number of running subtask agents and the cumulative token consumption; If the number of subtask agents or the cumulative token consumption exceeds the threshold, the generation of subtask agents will be restricted and a prompt message will be generated.
[0012] Secondly, this application provides a task execution system, comprising: The dominant agent module is used to decompose the target task into multiple subtasks that can be executed in parallel; create corresponding subtask agents for each of the multiple subtasks that can be executed in parallel; and integrate the execution results of all the subtask agents to obtain the execution result of the target task. A distributed state manager is used to write the multiple parallel executable subtasks into a shared task queue; establish a task dependency graph based on the dependencies between the multiple parallel executable subtasks; and start all the subtask agents in parallel, so that the subtask agents atomically obtain tasks from the shared task queue and execute tasks based on the task dependency graph.
[0013] Optionally, the step of decomposing the target task into multiple subtasks that can be executed in parallel includes: In response to the user inputting the target task, the complexity of the target task is evaluated, and the complexity evaluation result is obtained; Based on the complexity assessment results, determine whether to trigger the team derivation mechanism; If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
[0014] Optionally, the step of decomposing the target task into multiple subtasks that can be executed in parallel includes: In response to the user input of the target task, a task complexity score is calculated based on a complexity evaluation algorithm by analyzing the number of code modules involved in the target task, cross-service dependencies, and estimated lines of code. If the task complexity score is greater than the task complexity score threshold, the team derivation mechanism is triggered; if the task complexity score is less than or equal to the complexity score threshold, the team derivation mechanism is not triggered. If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
[0015] Optionally, the system further includes: A context isolation engine is used to create a corresponding context window for each of the subtask agents.
[0016] Optionally, the system further includes: The point-to-point communication layer is used to enable communication between the subtask agents by subscribing to or publishing message streams.
[0017] Optionally, the system further includes: The concurrency control module is used to destroy all the aforementioned subtask agents.
[0018] Optionally, the system further includes: The cost control gateway is used to continuously monitor the number of running subtask agents and the cumulative token consumption; if the number of subtask agents or the cumulative token consumption exceeds the threshold, the generation of subtask agents is restricted and a prompt message is generated.
[0019] This application provides a task execution method. When executing the method, firstly, the target task is decomposed into multiple parallelizable subtasks, and corresponding subtask agents are created for each of these subtasks. Next, the multiple parallelizable subtasks are written into a shared task queue. Based on the dependencies between the multiple parallelizable subtasks, a task dependency graph is established. Then, all subtask agents are started in parallel, allowing each subtask agent to atomically retrieve tasks from the shared task queue and execute them based on the task dependency graph. Finally, the execution results of all subtask agents are integrated to obtain the execution result of the target task. In this way, by decomposing the task into multiple parallelizable subtasks and assigning dedicated agents, combined with an atomic task retrieval mechanism and a dependency graph, the parallel execution efficiency is maximized while completely avoiding race conditions and repetitive work under multi-agent concurrency. Furthermore, dependency-aware scheduling ensures the rigor of the subtask execution sequence, thereby improving the accuracy and efficiency of task execution. Attached Figure Description
[0020] To more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings used in the description of the embodiment or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 A flowchart of a task execution method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a task execution system provided in an embodiment of this application. Detailed Implementation
[0022] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. This application provides a task execution method and system, relating to the field of artificial intelligence technology. The above are merely examples and do not limit the application areas of the methods and systems provided in this application.
[0023] In recent years, AI systems based on large language models have been increasingly used in task planning and execution. Current technologies often employ a monolithic architecture, where a single model instance handles the entire task. However, monolithic agents struggle to automatically break down macroscopic tasks into a set of subtasks that can be executed in parallel. Even when tasks are manually broken down, the model still needs to process each subtask sequentially, failing to achieve true parallel execution. This results in the overall task time increasing linearly with complexity, leading to low execution efficiency. Furthermore, in scenarios where subtasks have temporal or data dependencies, the monolithic architecture lacks explicit dependency modeling, resulting in low execution accuracy.
[0024] The inventors, through research, proposed the technical solution of this application, which decomposes the target task into multiple parallel executable subtasks. For each of these subtasks, a corresponding subtask agent is created. These subtasks are then written into a shared task queue. Based on the dependencies between these subtasks, a task dependency graph is established. All subtask agents are then launched in parallel, allowing them to atomically retrieve tasks from the shared task queue and execute them based on the dependency graph. Finally, the execution results of all subtask agents are integrated to obtain the execution result of the target task. This method, by decomposing the task into multiple parallelizable subtasks and assigning dedicated agents, combined with an atomic task retrieval mechanism and a dependency graph, maximizes parallel execution efficiency while completely avoiding race conditions and repetitive work under multi-agent concurrency. Furthermore, dependency-aware scheduling ensures the rigor of the subtask execution sequence, thereby improving the accuracy and efficiency of task execution.
[0025] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present application. It should be noted that, for ease of description, only the parts related to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features in the embodiments of the present application can be combined with each other.
[0026] See Figure 1 , Figure 1 A flowchart of a task execution method provided in this application embodiment includes: S101: Decompose the target task into multiple subtasks that can be executed in parallel.
[0027] Before executing the implementation steps in S101, the user uploads a macro-level task request to the leading agent module, i.e., a request to execute the target task. After receiving the macro-level task request from the user, the leading agent module performs semantic parsing of the task, converting it into a machine-understandable structured intent, and then initiates a task complexity evaluation algorithm. This algorithm calculates a complexity score by analyzing quantitative indicators such as the number of code modules involved in the task, the number of cross-service dependencies, and the estimated number of lines of code. For example, when the analysis finds that 14 microservices are involved and the estimated changes exceed 50,000 lines of code, the score exceeds a preset threshold. The system determines that a multi-agent collaboration mode must be enabled, triggering a team derivation mechanism. In this way, it can intelligently decide whether to enable a parallel architecture, avoiding the over-engineering of simple tasks and ensuring that complex tasks are not inefficiently handled by a single agent.
[0028] When the team derivation mechanism is triggered, the implementation method in step S101 is executed: the leading agent module generates a task decomposition scheme based on the target task. Here, task decomposition refers to logically breaking down a large-scale macro task into multiple sub-tasks with appropriate granularity, clear boundaries, and the ability to be executed in parallel as much as possible. For example, the macro task can be broken down into multiple sub-tasks that can be executed in parallel, such as "lexical analyzer reconstruction", "syntax parser optimization", "code generation module update", and "integration test writing", etc.
[0029] S102: Create corresponding subtask agents for multiple subtasks that can be executed in parallel.
[0030] Next, the context isolation engine creates an independent sub-agent instance for each subtask and a completely independent context window for each sub-agent. This means that when each sub-agent starts, its working memory is brand new. The system only injects it with generation prompts directly related to the subtask, necessary project-level configurations, and specific constraints, never passing on the historical dialogue records of the dominant agent or other sub-agents. This achieves complete physical isolation of the context, protecting sub-agents from noise interference from irrelevant information, solving the context pollution problem, and thus achieving extremely high focus and accuracy on local tasks.
[0031] S103: Write multiple subtasks that can be executed in parallel to a shared task queue.
[0032] The distributed state manager writes subtasks to a shared task queue. The shared task queue is a directory structure stored in the local file system, used to persistently store pending tasks.
[0033] S104: Establish a task dependency graph based on the dependencies between multiple parallel executable subtasks.
[0034] Meanwhile, the distributed state manager constructs a task dependency graph based on the logical relationships between tasks. For example, it marks the "integration test" subtask as having to wait for the "front-end UI" and "back-end API" subtasks to be completed before it can start.
[0035] S105: Start all subtask agents in parallel, so that the subtask agents atomically obtain tasks from the shared task queue and execute tasks based on the task dependency graph.
[0036] The concurrency control module launches multiple sub-agent processes based on resource availability. Before starting work, each sub-agent must claim a task from a shared queue. To ensure data consistency under high concurrency, the system employs a file lock-based task claiming mechanism. A file lock is a mutex lock provided by the operating system to control concurrent access to files. When a sub-agent attempts to acquire a task description file, it must first acquire an exclusive file lock. Only after successfully acquiring the lock can it mark the task as its own and then release the lock. This atomic operation prevents multiple agents from repeatedly claiming the same task or from experiencing race conditions.
[0037] As multiple sub-agents begin executing their respective tasks in parallel, they collaborate directly through a peer-to-peer communication layer, without needing to go through a dominant agent. This peer-to-peer communication layer is built on a shared global task channel, allowing sub-agents to directly send technical details, debate solutions, and share newly discovered dependencies during task execution, without reporting every interaction to the dominant agent. Furthermore, the peer-to-peer communication layer employs a publish-subscribe model, allowing each sub-agent to subscribe to message streams on specific topics, thus significantly reducing communication latency and redundancy.
[0038] After completing a task, a sub-agent submits a task status update to the distributed state manager. Upon receiving the update, the distributed state manager queries the task dependency graph to identify all downstream tasks blocked by that task. Once all prerequisites for a task are satisfied, the manager sends a dependency unlock signal, triggering the startup or resumption of the corresponding sub-agent. This allows for dynamic resource scheduling based on progress without manual intervention, improving the execution continuity of complex workflows.
[0039] S106: Integrate the execution results of all subtask agents to obtain the execution result of the target task.
[0040] Once all subtasks have been completed, the leading agent collects and summarizes the execution results of each subtask to obtain the execution result of the target task. The summary includes generated code, configuration files, test cases, etc. Subsequently, the leading agent performs consistency verification, checking whether cross-service interface definitions are consistent, data types match, and the overall architecture conforms to the original intent.
[0041] The concurrency control module issues a resource release command, destroys all sub-agent instances, and cleans up the memory and temporary files they occupy.
[0042] Furthermore, the cost control gateway continuously monitors the entire process. It sets a maximum concurrent agent count threshold and accumulates token consumption in real time. If it detects that the dominant agent is using overly open prompts leading to excessive derivation, or that token consumption is approaching the budget, the gateway will intervene and recommend using more explicit "command prompts" to limit the role scope.
[0043] In this embodiment, the target task is first decomposed into multiple parallel executable subtasks, and corresponding subtask agents are created for each subtask. Next, these subtasks are written into a shared task queue. Based on the dependencies between these subtasks, a task dependency graph is established. Then, all subtask agents are started in parallel, allowing them to atomically retrieve tasks from the shared task queue and execute them based on the dependency graph. Finally, the execution results of all subtask agents are integrated to obtain the target task's execution result. This approach, by decomposing the task into multiple parallel subtasks and assigning dedicated agents, combined with an atomic task retrieval mechanism and a dependency graph, maximizes parallel execution efficiency while completely avoiding race conditions and repetitive work under multi-agent concurrency. Furthermore, dependency-aware scheduling ensures the rigor of subtask execution timing, thereby improving the accuracy and efficiency of task execution.
[0044] The task execution method provided by the embodiments of this application has been introduced above. The following is an exemplary description of the task execution method in conjunction with specific application scenarios.
[0045] In one implementation, if a user needs to completely refactor their authentication system across 14 microservices, involving multiple independently deployed microservice modules such as user service, permission service, token service, and session management service, with a total code volume of approximately 80,000 lines, it is necessary to maintain strict consistency between the interfaces of each service.
[0046] The user inputs the task into the leading agent module via the terminal: "Reconstruct the OAuth 2.0 authentication system across 14 microservices, upgrade the JWT token mechanism to a security scheme that supports refresh token rotation, while maintaining backward compatibility."
[0047] After receiving the task, the leading agent module activates the built-in complexity evaluation algorithm. The algorithm analysis found that the task involves 14 microservices, has an estimated impact of more than 50,000 lines of code, and has 32 cross-service API dependencies. The calculated task complexity score is 8.7 (out of 10), which far exceeds the preset derivation threshold of 5.0, thus triggering the team derivation mechanism.
[0048] The leading agent generation task decomposition scheme breaks down the macro-level task into the following sub-tasks: Subtask A: Refactoring the authentication interface of the user service; Subtask B: Update the authorization logic of the permission service; Subtask C: Modification of the JWT generation and verification module for the token service; Subtask D: Implementation of the refresh token rotation mechanism for the session management service; Subtask E: Upgrade the token interceptor for the API gateway; Subtask F: Writing the database migration script (adding a refresh_tokens table); Subtask G: Development of a cross-service integration test suite; Subtask H: Backward compatibility verification and rollback scheme design.
[0049] The context isolation engine creates a separate sub-agent instance for each subtask. For example, the "token service agent" created for subtask C has a completely new context window that contains only: The message displayed reads: "You are a backend security expert specializing in JWT token processing, responsible for implementing token generation and verification logic that supports token rotation." Project configuration: Load AGENTS.md from the project root directory (which defines coding standards such as TypeScript strict mode and disabling any type) and CLAUDE.md from the token service subdirectory (which contains the API documentation and existing token processing flow for the service).
[0050] This context window contains no historical dialogue records of the dominant agent, nor any code details of the other 13 microservices, ensuring focus.
[0051] Next, the distributed state manager writes the eight subtasks into the local task queue directory and establishes a task dependency graph. Subtasks A, B, C, D, and E can be executed in parallel immediately (without prerequisites); task F depends on subtask D (the data structure of the refresh token needs to be determined first); subtask G depends on the completion of all subtasks A, B, C, D, and E; and subtask H depends on the completion of subtask G.
[0052] The concurrency control module simultaneously launches 5 sub-agent instances (corresponding to sub-tasks AE). Each instance atomically claims a task from the task queue through a file lock mechanism. For example, when agent a and agent b simultaneously attempt to claim task-A.json, the file lock ensures that only agent a successfully acquires it, while agent b automatically switches to claim task-B.json.
[0053] During execution, sub-agents collaborate through a peer-to-peer communication layer. For example, when the token service agent implements the token rotation refresh logic, it discovers that a `rotation_id` field needs to be added to the token payload. The token service agent sends a peer-to-peer message to the user service agent and the permission service agent via the peer-to-peer communication layer: "The token payload has a new `rotation_id` field (UUID format). Please make your token verification logic compatible with this field." The user service agent and the permission service agent immediately add parsing and verification logic for the `rotation_id` field to their respective code, without waiting for relay instructions from the leading agent.
[0054] Once subtask D is completed, the distributed state manager receives the task status update, checks the dependency graph, finds that the prerequisites of subtask F have been satisfied, automatically sends a dependency unlock signal, and triggers the "database migration agent".
[0055] Once all subtasks AE are completed, subtask G is automatically unlocked, and the "Integration Test Agent" starts and writes an end-to-end test suite covering all microservice interaction scenarios, containing 42 test cases.
[0056] Subtask H's "Compatibility Verification Agent" performed backward compatibility testing, confirming that the old version client can still use the original JWT token mechanism normally (without using refresh token rotation), and designed a canary release plan.
[0057] After all eight subtasks are completed, the lead agent module collects and summarizes the execution results for final consistency verification: checking whether the API interface definitions of each microservice are consistent, whether the token fields are unified, and whether the test coverage meets the standards. Once verification is successful, a complete refactoring plan is returned to the user, including code changes, database migration scripts, and deployment documentation.
[0058] Finally, the concurrency control module sends a resource release command to destroy all eight sub-agent instances, clean up temporary files and context windows, and complete this instantaneous collaborative session.
[0059] In another implementation, it can be applied to more extreme ultra-large-scale code generation scenarios. Specifically, a user needs to build a complete C language compiler from scratch. This compiler needs to support the core features of the C11 standard and be able to generate target code for three architectures: x86, ARM, and RISC-V. The total amount of code is estimated to exceed 100,000 lines.
[0060] The user inputs the task to the leading agent: "Build a cross-platform C compiler that supports the C11 standard, including modules for lexical analysis, syntax analysis, semantic analysis, intermediate code generation, optimization, and target code generation."
[0061] After evaluating the task, the leading agent decomposes it into 16 highly specialized subtasks, including: lexer development, parser development, abstract syntax tree (AST) design, symbol table manager development, type checker development, intermediate representation (IR) design, constant folding optimizer, dead code elimination optimizer, register allocator, x86 code generator, ARM code generator, RISC-V code generator, linker interface development, standard library interface implementation, compiler driver development, and end-to-end test suite development.
[0062] The context isolation engine creates an expert agent for each subtask. For example, the context window of the lexical analyzer agent contains only: theoretical knowledge of lexical analysis (regular expressions, finite state automata), C11 standard lexical rules (keywords, operators, literal formats), the project-defined token data structure, and constraints prohibiting the introduction of third-party lexical analysis libraries.
[0063] The agent is completely unaware of the implementation details of downstream modules such as syntax analysis and code generation, ensuring extreme focus.
[0064] Sixteen sub-agents are launched in parallel. During execution, they coordinate interface definitions through a point-to-point communication layer. For example, after the AST design agent defines the node types of the abstract syntax tree, it broadcasts them to the parser agent and type checker agent through the communication layer; after the IR design agent determines the instruction format of the intermediate representation, it notifies all code generator agents.
[0065] Due to the large scale of the task, the cost control gateway detected a high token consumption rate and automatically suggested that the user use "instructional" prompts to clarify the output boundaries of each agent and avoid excessive generation of sample code and comments.
[0066] After approximately 8 hours of parallel execution (including multiple iterations and debugging), the system successfully generated a complete compiler implementation containing 103,847 lines of Rust code.
[0067] The above are some specific implementations of the task execution method provided in the embodiments of this application. Based on this, this application also provides a corresponding system. The system provided in the embodiments of this application will be described below from the perspective of functional modularization.
[0068] See Figure 2 , Figure 2 This application provides a schematic diagram of the structure of a task execution system 200, which includes: The dominant intelligent agent module 210 is used to decompose the target task into multiple subtasks that can be executed in parallel; create corresponding subtask intelligent agents for each of the multiple subtasks that can be executed in parallel; and integrate the execution results of all the subtask intelligent agents to obtain the execution result of the target task. A distributed state manager 220 is used to write the plurality of parallel executable subtasks into a shared task queue; establish a task dependency graph based on the dependencies between the plurality of parallel executable subtasks; and start all the subtask agents in parallel, so that the subtask agents atomically obtain tasks from the shared task queue and execute tasks based on the task dependency graph.
[0069] Optionally, the step of decomposing the target task into multiple subtasks that can be executed in parallel includes: In response to the user inputting the target task, the complexity of the target task is evaluated, and the complexity evaluation result is obtained; Based on the complexity assessment results, determine whether to trigger the team derivation mechanism; If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
[0070] Optionally, the step of decomposing the target task into multiple subtasks that can be executed in parallel includes: In response to the user input of the target task, a task complexity score is calculated based on a complexity evaluation algorithm by analyzing the number of code modules involved in the target task, cross-service dependencies, and estimated lines of code. If the task complexity score is greater than the task complexity score threshold, the team derivation mechanism is triggered; if the task complexity score is less than or equal to the complexity score threshold, the team derivation mechanism is not triggered. If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
[0071] Optionally, the system 200 further includes: The context isolation engine 230 is used to create a corresponding context window for each of the subtask agents.
[0072] Optionally, the system 200 further includes: The point-to-point communication layer 240 is used to enable communication between the subtask agents by subscribing to or publishing message streams.
[0073] Optionally, the system 200 further includes: The concurrency control module 250 is used to destroy all the subtask agents.
[0074] Optionally, the system 200 further includes: The cost control gateway 260 is used to continuously monitor the number of running subtask agents and the cumulative token consumption; if the number of subtask agents or the cumulative token consumption exceeds the threshold, the generation of subtask agents is restricted and a prompt message is generated.
[0075] This application also provides corresponding devices and computer storage media for implementing the solutions provided in this application.
[0076] The device includes a memory and a processor. The memory stores instructions or code, and the processor executes the instructions or code to cause the device to perform the method described in any embodiment of this application.
[0077] The computer storage medium stores code, and when the code is run, the device running the code implements the method described in any embodiment of this application.
[0078] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.
[0079] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0080] It should also be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The system embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. The components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0081] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A task execution method, characterized in that, include: The target task is broken down into multiple subtasks that can be executed in parallel; For each of the multiple subtasks that can be executed in parallel, a corresponding subtask agent is created; Write the multiple executable subtasks into a shared task queue; Based on the dependencies between the multiple parallel executable subtasks, a task dependency graph is established; All the subtask agents are launched in parallel, so that the subtask agents atomically retrieve tasks from the shared task queue and execute tasks based on the task dependency graph; The execution results of all the sub-task agents are integrated to obtain the execution result of the target task.
2. The method according to claim 1, characterized in that, The process of breaking down the target task into multiple subtasks that can be executed in parallel includes: In response to the user inputting the target task, the complexity of the target task is evaluated, and the complexity evaluation result is obtained; Based on the complexity assessment results, determine whether to trigger the team derivation mechanism; If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
3. The method according to claim 2, characterized in that, The process of breaking down the target task into multiple subtasks that can be executed in parallel includes: In response to the user input of the target task, a task complexity score is calculated based on a complexity evaluation algorithm by analyzing the number of code modules involved in the target task, cross-service dependencies, and estimated lines of code. If the task complexity score is greater than the task complexity score threshold, the team derivation mechanism is triggered; if the task complexity score is less than or equal to the complexity score threshold, the team derivation mechanism is not triggered. If the team derivation mechanism is triggered, the target task will be broken down into multiple subtasks that can be executed in parallel.
4. The method according to claim 1, characterized in that, After creating corresponding subtask agents for the plurality of parallel executable subtasks, the method further includes: Create a corresponding context window for each of the subtask agents.
5. The method according to claim 1, characterized in that, When the subtask agent performs a task, the method further includes: Communication between the subtask agents is achieved by subscribing to or publishing message streams.
6. The method according to claim 1, characterized in that, After integrating the execution results of all the sub-task agents to obtain the execution result of the target task, the method further includes: Destroy all the described subtask agents.
7. The method according to any one of claims 1-6, characterized in that, The method further includes: Continuously monitor the number of running subtask agents and the cumulative token consumption; If the number of subtask agents or the cumulative token consumption exceeds the threshold, the generation of subtask agents will be restricted and a prompt message will be generated.
8. A task execution system, characterized in that, include: The leading agent module is used to break down the target task into multiple subtasks that can be executed in parallel; For each of the multiple subtasks that can be executed in parallel, a corresponding subtask agent is created; The execution results of all the sub-task agents are integrated to obtain the execution result of the target task; A distributed state manager is used to write the multiple parallel-executable subtasks into a shared task queue; Based on the dependencies between the multiple parallel executable subtasks, a task dependency graph is established; All the subtask agents are launched in parallel, so that the subtask agents atomically retrieve tasks from the shared task queue and execute the tasks based on the task dependency graph.
9. The system according to claim 8, characterized in that, The system also includes: A context isolation engine is used to create a corresponding context window for each of the subtask agents.
10. The system according to claim 8, characterized in that, The system also includes: The point-to-point communication layer is used to enable communication between the subtask agents by subscribing to or publishing message streams.