Distributed agent computing method, system, and computer-readable storage medium

Abstract

This invention relates to the field of distributed computing and artificial intelligence task scheduling technology, and particularly to a distributed intelligent agent computing method, system, and computer-readable storage medium. The method includes: receiving and storing node capability information reported by each execution node; receiving a task request submitted by a user, generating a task dependency graph based on the task request, wherein the task dependency graph has multiple subtasks as nodes and the dependencies between the multiple subtasks as directed edges; identifying ready subtasks in the task dependency graph that satisfy all prerequisite dependencies, determining a target execution node based on the matching of node capability information and the task requirements of the ready subtasks, assigning the ready subtasks to the target execution node for execution until all subtasks are completed; and summarizing the execution results of each subtask and returning them to the user. This invention can automatically complete task decomposition, support heterogeneous node capability modeling, and achieve capability-aware scheduling.

Description

Technical Field

[0001] This invention relates to the fields of distributed computing and artificial intelligence task scheduling technology, and in particular to distributed intelligent agent computing methods, systems and computer-readable storage media. Background Technology

[0002] With the continuous evolution of large model and agent technologies, more and more complex tasks require the collaboration of multiple agents. Typical application scenarios include code generation and automated testing, data analysis and report generation, multimodal data processing, automated software development, and large-scale model inference tasks.

[0003] However, existing agent computing systems generally suffer from the following limitations in multi-node environments: First, most agent frameworks only support single-machine operation and cannot fully utilize the resources of multiple computing nodes; second, user tasks usually need to be manually broken down into multiple sub-tasks, making it difficult to achieve automated task decomposition; third, in real-world environments, different computing nodes often have different computing power, deploy different large models, and possess different skill modules, and the idle levels of each node vary, but existing systems lack a unified method for modeling node capabilities, resulting in scheduling decisions that cannot perceive the semantic-level capabilities of nodes; fourth, when multiple nodes execute tasks, existing systems typically use simple queues or random allocation methods, which cannot perform optimal scheduling based on node capability characteristics, resulting in low resource utilization.

[0004] In the existing technology, some distributed execution frameworks and container orchestration systems for machine learning have achieved resource-based multi-node scheduling. However, the node description system of such frameworks only covers computing resources and load information, and does not include the language model type deployed by the node and the type of executable task skills in the scheduling basis, which makes it difficult to meet the fine-grained scheduling needs in heterogeneous intelligent agent computing scenarios.

[0005] Therefore, there is an urgent need for a distributed intelligent agent computing method that can automatically complete task decomposition, support heterogeneous node capability modeling, and realize capability-aware scheduling to overcome the above-mentioned shortcomings. Summary of the Invention

[0006] The purpose of this invention is to provide a distributed intelligent agent computing method, system, and computer-readable storage medium to solve the technical problems in the prior art where intelligent agent systems cannot automatically split tasks in a multi-node environment, cannot uniformly model node capabilities, and lack a capability-aware scheduling mechanism.

[0007] To achieve this objective, the present invention adopts the following technical solution: In a first aspect, the present invention provides a distributed intelligent agent computing method, which includes the following steps: S1. Receive and store the node capability information reported by each execution node. The node capability information includes at least the computing resource information of each execution node, the model capability information describing the type of language model reasoning ability that each execution node can call, and the skill set information describing the type of task processing function that each execution node can perform. S2. Receive a task request submitted by the user, and generate a task dependency graph based on the task request. The task dependency graph has multiple sub-tasks as nodes and the dependency relationships between the multiple sub-tasks as directed edges. S3. Identify ready subtasks that satisfy all prerequisite dependencies in the task dependency graph, determine the target execution node based on the matching of the node capability information and the task requirements of the ready subtasks, and assign the ready subtasks to the target execution node for execution until all subtasks are completed. S4. Summarize the execution results of each subtask and return them to the user.

[0008] Preferably, in step S2, generating the task dependency graph based on the task request specifically includes: The task request is automatically broken down into multiple sub-tasks, and the dependencies between the sub-tasks are determined. The task dependency graph is constructed using the multiple subtasks as nodes and the dependencies as directed edges.

[0009] Preferably, after the ready subtask is assigned to the target execution node for execution, the execution result of the ready subtask also needs to be stored so that subsequent subtasks that depend on the ready subtask can obtain input data. When a ready subtask is completed and all its prerequisites for subsequent subtasks are satisfied, the subsequent subtask is treated as a new ready subtask. The determination and allocation of target execution nodes for the new ready subtask continues until all subtasks are completed.

[0010] In some preferred embodiments, the node capability information further includes the current load information, energy consumption parameter information and node type label of each execution node. The current load information includes the resource utilization rate and task queue length of each execution node, and the node type label includes at least one of high computing power node label, general computing node label and edge node label.

[0011] In some preferred embodiments, execution nodes labeled with high computing power nodes deploy large-scale language models, execution nodes labeled with general computing nodes deploy medium-scale language models, and execution nodes labeled with edge nodes deploy lightweight language models. When determining the target execution node, the execution node with the corresponding type of language model is determined as the target execution node based on the correspondence between the model type required by the ready subtask and the model capability information of each execution node.

[0012] Preferably, the step of automatically decomposing the task request into multiple sub-tasks specifically includes: For task requests that conform to a predefined rule template, a set of subtasks and their dependencies are generated based on the predefined rule template. For task requests that do not conform to the predefined rule template, the language model is invoked to perform semantic parsing on the task request, generating a set of subtasks and their dependencies.

[0013] Furthermore, after generating the task dependency graph, a validity check is performed on the task dependency graph. The validity check sequentially performs acyclicity detection, input / output integrity check of each subtask, dependency closure check, and resource executability check. If any check fails, the rule is corrected or the language model is called again to generate a set of subtasks and dependencies, and the validity check is performed again until all check items pass.

[0014] Preferably, in step S3, determining the target execution node based on the matching between the node capability information and the task requirements of the ready subtask specifically includes: Based on the inclusion relationship between the skill types required by the ready subtask and the skill set information of each execution node, a skill matching item is calculated; based on the inclusion relationship between the model types required by the ready subtask and the model capability information of each execution node, a model matching item is calculated; based on the ratio of the available computing resources of each execution node to the computing resources required by the ready subtask, a resource adaptation item is calculated; based on the resource utilization rate of each execution node, an idle metric is calculated and the idle metric is used as an idle item; based on the historical task execution success rate of each execution node, a reliability item is calculated; and based on the product of the energy consumption parameter information of each execution node and the expected runtime of the ready subtask, an energy consumption cost item is calculated. The skill matching item, model matching item, resource adaptation item, idle item, and reliability item are weighted and summed according to their respective weight coefficients. The product of the energy consumption cost item and its corresponding weight coefficient is then subtracted, and the execution node with the largest difference is selected as the target execution node.

[0015] Furthermore, the weight coefficient is set by configuration parameters during initialization, and during operation, it is adjusted according to the task type, adaptively adjusted according to the current load information of each execution node, and optimized and updated online according to the task completion time, success rate and resource consumption information in the historical scheduling execution results.

[0016] Furthermore, the execution nodes are sorted in descending order based on the difference, and a preset number of execution nodes with the highest difference ranking are selected to form a candidate execution node set. In the candidate execution node set, the execution node with the lowest resource utilization rate is selected as the target execution node based on the resource utilization rate of each execution node.

[0017] Preferably, after all subtasks have been completed, the execution time, success status, and resource consumption information of each subtask should be recorded, and the weight coefficients should be optimized and updated online based on the recorded execution time, success status, and resource consumption information for the purpose of determining the target execution node of subsequent tasks.

[0018] In some preferred embodiments, when there are multiple ready subtasks that are independent of each other in the task dependency graph, a target execution node is determined concurrently for each ready subtask in the same scheduling round, and the multiple ready subtasks are synchronously distributed to their respective target execution nodes for parallel execution.

[0019] In some preferred embodiments, when storing the execution results of each subtask, a unique subtask identifier is assigned to each subtask, and the execution results are stored in association with the unique subtask identifier; When a subsequent subtask obtains input data, it queries the execution result corresponding to the unique subtask identifier of the preceding subtask based on the dependency relationship of the subsequent subtask in the task dependency graph, and uses the queryed execution result as the input data of the subsequent subtask.

[0020] In some preferred embodiments, after the ready subtask is assigned to the target execution node, a locking process is also required for the ready subtask so that it is no longer assigned to other execution nodes. When the target execution node returns a resource unavailable response, the locked state of the ready subtask is released, and a new target execution node is determined based on the matching of the node capability information and the task requirements of the ready subtask.

[0021] In some preferred embodiments, when a subtask of an execution node fails to execute or a response times out, the subtask is reassigned to another execution node that meets the task requirements of the subtask. When there is no execution node that meets the task requirements of the subtask, the task requirements of the subtask are downgraded, and the downgraded subtask is reassigned to an execution node that meets the downgraded task requirements.

[0022] In some preferred embodiments, each execution node continuously updates the node capability information in a periodic heartbeat manner, wherein the update frequency of dynamic capability information reflecting the current operating status of each execution node is higher than the update frequency of static capability information reflecting the hardware configuration of each execution node; if no heartbeat update information is received from an execution node within a preset time limit, the execution node is marked as unavailable and excluded from the range of available execution nodes for subsequent ready subtasks.

[0023] In some preferred embodiments, when the task request includes a priority parameter, after identifying the ready subtasks in the task dependency graph, the ready subtasks are sorted according to the priority parameter. The ready subtasks with higher priority are given priority in determining the target execution node and completing the allocation. Ready subtasks with the same priority are scheduled in sequence according to the topological order of the task dependency graph.

[0024] In some preferred embodiments, before receiving a task request submitted by a user, it is also necessary to receive an original task request submitted through at least one of the following methods: application, web page, or program call interface; parse the original task request; generate a unified task description structure containing task instructions, input data files, and constraint parameters; and use the unified task description structure as the task request.

[0025] In some preferred embodiments, step S3, which involves assigning the ready subtask to the target execution node for execution, specifically includes: Call the locally deployed language model to perform agent reasoning and generate execution steps; Based on the skill type required by the ready subtask, at least one of a code executor, a data processing tool, or a visual processing tool is invoked to execute the execution steps, thereby generating the execution result of the ready subtask; The execution result is stored so that subsequent subtasks that depend on the ready subtask can read it as input.

[0026] In some preferred embodiments, when summarizing the execution results of each subtask, the execution results of multiple subtasks are merged to generate a final output result in a unified format, and the scheduling log and execution log of the task execution process are returned to the user together.

[0027] In some preferred embodiments, each subtask node in the task dependency graph also carries the model type label and skill type label required by its corresponding subtask; When determining the target execution node, execution nodes that simultaneously meet the model type requirements and skill type requirements are selected based on the matching results of the model type label and the model capability information of each execution node, and the matching results of the skill type label and the skill set information of each execution node.

[0028] In some preferred embodiments, each execution node reports all of the node capability information when it first connects, and only periodically reports the changes in the dynamic capability information during operation.

[0029] In a second aspect, the present invention provides a distributed intelligent agent computing system, comprising: The node registration unit is used to store the node capability information reported by each execution node. The node capability information includes at least the computing resource information of each execution node, the model capability information describing the type of language model reasoning ability that each execution node can call, and the skill set information describing the type of task processing function that each execution node can perform. The task planning unit is used to generate a task dependency graph based on the received user task request. The task dependency graph has multiple subtasks as nodes and the dependency relationships between the multiple subtasks as directed edges. The capability-aware scheduling unit is used to identify ready subtasks that satisfy all prerequisites in the task dependency graph, determine the target execution node based on the matching of node capability information stored in the node registration unit with the task requirements of the ready subtasks, assign the ready subtasks to the target execution node for execution, and trigger the scheduling of the subsequent subtasks when the ready subtasks are completed and all prerequisites of their subsequent subtasks are satisfied. The intermediate result storage unit is used to store the execution results of each subtask so that subsequent subtasks can obtain input data; The results aggregation unit is used to summarize the execution results of each subtask after all subtasks have been executed and return them to the user.

[0030] Preferably, the capability-aware scheduling unit is further configured to: After assigning the ready subtask to the target execution node, a locking process needs to be performed on the ready subtask. When the target execution node returns a resource unavailable response, the locking status of the ready subtask is released and a new target execution node is selected. When a subtask of an execution node fails to execute or times out, the subtask is reassigned to another execution node that meets the task requirements of the subtask. If no execution node meets the task requirements of the subtask, the task requirements of the subtask are downgraded and then reassigned.

[0031] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the distributed intelligent agent computing method described above.

[0032] Compared with the prior art, the present invention has the following beneficial effects: This invention addresses several key issues. Firstly, by introducing model capability information describing the reasoning ability of language models and skill set information describing the task processing function type into the node capability information, the scheduling system gains the ability to perceive the semantic capabilities of each execution node. This allows for precise matching based on the model type and skill type required by the subtask when determining the target execution node, fundamentally bridging the gap in existing distributed frameworks that can only perceive computing resources but not the semantic capabilities of agents. Secondly, by automatically generating task dependency graphs from user-submitted task requests, it achieves automatic transformation from task description to executable directed acyclic graphs, freeing users from tedious manual task decomposition and significantly improving the automation level of multi-agent tasks. Thirdly, through a recursive scheduling mechanism based on the task dependency graph and the storage of subtask execution results, execution nodes can collaboratively complete multi-level task flows with complex dependencies, ensuring the integrity and consistency of data flow between subtasks while fully utilizing distributed heterogeneous computing resources.

[0033] The present invention has other features and advantages, which will be apparent from or will be set forth in detail in the accompanying drawings and the following detailed description, which together serve to explain the particular principles of the invention. Attached Figure Description

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

[0035] Figure 1 This is a flowchart of the distributed intelligent agent computing method according to Embodiment 1 of the present invention.

[0036] Figure 2 This is a diagram of the distributed intelligent agent computing system architecture according to Embodiment 2 of the present invention. Detailed Implementation

[0037] To illustrate the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of this application in detail, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of this application and are therefore intended to limit the scope of protection of this application.

[0038] Example 1 Please see Figure 1The distributed intelligent agent computing method of this embodiment is applied to a distributed computing environment including a control node 10 and multiple execution nodes. Before introducing this method, a brief introduction to the distributed computing environment involved in this method will be given.

[0039] The multiple execution nodes may include high-performance execution nodes 21, general-purpose computing execution nodes 22 and edge execution nodes 23, which correspond to different computing power forms such as GPU servers, general-purpose workstations and edge devices, respectively.

[0040] The control node 10 has a built-in node registration unit 11, task planning unit 12, capability-aware scheduling unit 13, intermediate result storage unit 14, and result aggregation unit 15. The user terminal 41 interacts with the control node 10 through applications, web pages, or program call interfaces.

[0041] The steps of the distributed intelligent agent computing method in this embodiment will be described in detail below.

[0042] S1. Receive and store the node capability information reported by each execution node. The node capability information includes at least the computing resource information of each execution node, the model capability information describing the type of language model reasoning ability that each execution node can call, and the skill set information describing the type of task processing function that each execution node can perform.

[0043] It is understandable that when each execution node accesses the distributed system, it reports its node capability information to the control node 10, and the node registration unit 11 is responsible for storing and managing it.

[0044] Specifically, node capability information can be formally represented as a six-tuple C_node=(R,M,S,L,E,T), where R represents computing resource information, including parameters such as CPU computing power, GPU computing power, memory capacity, and storage capacity of each execution node; M represents model capability information, that is, the set of language models currently deployed on each execution node, such as large-scale language models, medium-scale language models, or lightweight language models; S represents the skill set information, which is the set of task processing function types that each execution node can perform, such as code generation, data analysis, document generation, and report generation. L represents the current load information, including the resource utilization rate of each execution node and the task queue length; E represents energy consumption parameter information, recording the rated power of each execution node; T represents the node type label, which includes at least one of the following: high-performance computing node label (corresponding to GPU server), general computing node label (corresponding to workstation), or edge node label (corresponding to edge device), such as GPU_NODE, CPU_NODE, EDGE_NODE, etc.

[0045] Furthermore, each execution node continuously updates its node capability information via periodic heartbeats. The update frequency of dynamic capability information (i.e., current load information L) reflecting the current operating status of each execution node is higher than that of static capability information (i.e., computing resource information R) reflecting the hardware configuration of each execution node.

[0046] If a heartbeat update from an execution node is not received within a preset time limit, that execution node is marked as unavailable and excluded from the range of available execution nodes for subsequent ready subtasks. Furthermore, each execution node reports all of its capability information upon initial connection. To avoid increasing the information processing load due to frequent interactions, only changes in dynamic capability information are reported periodically during operation.

[0047] Preferably, before receiving a task request submitted by a user, it is also necessary to receive an original task request submitted through at least one of the following methods: application, webpage, or program call interface. The original task request is parsed to generate a unified task description structure containing task instructions, input data files, and constraint parameters, and this unified task description structure is used as the task request.

[0048] Specifically, the unified task description structure described here can be represented as Task={prompt,input_files,constraints,metadata}, where prompt represents natural language instructions, input_files represents input files, constraints represent optional parameters such as priority, time limit, and resource constraints, and metadata represents task metadata.

[0049] S2. Receive a task request submitted by the user, and generate a task dependency graph based on the task request. The task dependency graph has multiple subtasks as nodes and the dependency relationships between the multiple subtasks as directed edges.

[0050] Furthermore, the step of generating a task dependency graph based on the task request specifically includes: Automatically break down task requests into multiple subtasks and determine the dependencies between each subtask. Construct a task dependency graph using multiple subtasks as nodes and dependencies as directed edges.

[0051] It is understood that the task dependency graph involved in this embodiment is a directed acyclic graph, which can be represented as G=(V,E), where V represents the set of subtask nodes and E represents the set of directed edges relating the dependencies between subtasks. Furthermore, the task dependency graph in this embodiment supports serial dependencies, parallelizable tasks, and staged data dependencies.

[0052] Furthermore, the automatic decomposition of the task request into multiple sub-tasks specifically includes: For task requests that conform to the predefined rule template, generate a set of subtasks and their dependencies based on the predefined rule template; For task requests that do not conform to the predefined rule template, the language model is invoked to perform semantic parsing on the task request. Through sub-steps such as semantic parsing, subtask generation, and dependency inference, a set of subtasks and dependencies are generated.

[0053] Furthermore, after generating the task dependency graph, a validity check needs to be performed on it. This validity check must sequentially perform acyclicity checks, input / output integrity checks for each subtask, dependency closure checks, and resource executability checks to ensure that the generated task dependency graph is logically consistent and resource-executable. This execution order ensures that the task dependency graph is a compliant and usable directed acyclic graph.

[0054] If any of the aforementioned checks—including acyclic execution detection, input / output integrity checks for each subtask, dependency closure checks, and resource executability checks—fail, rule correction or re-invoking the language model to generate the subtask set and dependencies is required, followed by another legality check until all checks pass.

[0055] In some preferred embodiments, each subtask node in the task dependency graph also carries the model type label and skill type label required by its corresponding subtask; When determining the target execution node, the matching results of the model type label with the model capability information of each execution node and the matching results of the skill type label with the skill set information of each execution node are used to select execution nodes that simultaneously meet the model type requirements and skill type requirements to participate in the determination of the target execution node.

[0056] S3. Identify ready subtasks that satisfy all prerequisites in the task dependency graph, determine the target execution node based on the matching of the node capability information and the task requirements of the ready subtasks, and assign the ready subtasks to the target execution node for execution until all subtasks are completed.

[0057] Understandably, the capability-aware scheduling unit 13 scans the task dependency graph, identifies ready subtasks that satisfy all prerequisite dependencies, and determines the target execution node based on the matching of node capability information stored in the node registration unit 11 with the task requirements of the ready subtasks.

[0058] Specifically, execution nodes labeled with high computing power nodes deploy large-scale language models, execution nodes labeled with general computing nodes deploy medium-scale language models, and execution nodes labeled with edge nodes deploy lightweight language models. When determining the target execution node, it is necessary to determine the execution node with the corresponding type of language model deployed based on the correspondence between the model type required by the ready subtask and the model capability information of each execution node.

[0059] Preferably, the determination of the target execution node based on the matching of node capability information with the task requirements of ready subtasks specifically includes: Based on the inclusion relationship between the skill type required by the ready subtask and the skill set information of each execution node, the skill matching item SkillMatch is calculated. The value of SkillMatch is 1 or 0. Specifically, if the skill type required by the ready subtask belongs to the skill set of the execution node, then SkillMatch=1, otherwise SkillMatch=0. Based on the inclusion relationship between the model type required by the ready subtask and the model capability information of each execution node, the model matching item ModelMatch is calculated. The value of ModelMatch is 1 or 0. Specifically, if the model type required by the ready subtask belongs to the model capability set of the execution node, then ModelMatch=1, otherwise ModelMatch=0. Based on the ratio of the available computing resources of each execution node to the computing resources required by the ready subtasks, the computing resource adaptation item ResourceFit is specifically defined as: ResourceFit = min(CPU_available / CPU_required, GPU_available / GPU_required). Based on the resource utilization of each execution node, the idle metric is calculated and used as the idle item IdleScore. Specifically, IdleScore = 1 - ResourceUsage. Calculate the reliability term based on the historical task execution success rate of each execution node; Based on the product of the energy consumption parameters of each execution node and the expected runtime of the ready subtask, the energy cost term EnergyCost is calculated. Specifically, EnergyCost = node_power × expected_runtime.

[0060] The skill matching, model matching, resource adaptation, idle time, and reliability items are weighted and summed according to their respective weight coefficients. The product of the energy consumption cost item and its corresponding weight coefficient is then subtracted. The execution node with the largest difference is selected as the target execution node. The calculation formula for the scoring function is as follows: Score(node,job)=α×SkillMatch+β×ModelMatch+γ×ResourceFit+δ×IdleScore+ε×Reliability-λ×EnergyCost.

[0061] Each scoring item is normalized before being included in the calculation. The selection criterion for the target execution node is node*=argmaxScore(node,job). The weight coefficients α, β, γ, δ, ε, and λ are set by configuration parameters during initialization. During operation, the rules are adjusted according to the task type, the status is adaptively adjusted according to the current load information of each execution node, and online optimization and updates are performed based on the task completion time, success rate, and resource consumption information in the historical scheduling execution results.

[0062] In some preferred embodiments, the execution nodes are sorted in descending order according to the difference, and a preset number of execution nodes with the highest difference ranking are selected to form a candidate execution node set. In the candidate execution node set, the execution node with the lowest resource utilization rate is selected as the target execution node based on the resource utilization rate of each execution node.

[0063] Furthermore, after assigning the ready subtask to the target execution node, it is also necessary to perform locking processing on the ready subtask to prevent it from being assigned to other execution nodes. When the target execution node returns a resource unavailable response, the locked state of the ready subtask is released, and a new target execution node is determined based on the matching of node capability information and the task requirements of the ready subtask.

[0064] Furthermore, when there are multiple ready subtasks that are independent of each other in the task dependency graph, the target execution node is determined concurrently for each ready subtask in the same scheduling round, and the multiple ready subtasks are synchronously distributed to their respective target execution nodes for parallel execution.

[0065] Furthermore, when the task request contains a priority parameter, after identifying the ready subtasks in the task dependency graph, the ready subtasks are sorted according to the priority parameter, and the target execution node is determined and the assignment is completed for the ready subtasks that are ranked higher. Ready subtasks with the same priority are scheduled in sequence according to the topological order of the task dependency graph.

[0066] Preferably, the step of assigning ready subtasks to target execution nodes for execution specifically includes: Call the locally deployed language model to perform agent reasoning and generate execution steps; Based on the skill type required by the ready subtask, at least one of the code executor, data processing tool, or visual processing tool is invoked to perform execution steps and generate the execution result of the ready subtask; The execution result is uploaded to the intermediate result storage unit 14 so that subsequent subtasks that depend on the ready subtask can read it as input.

[0067] Furthermore, after assigning ready subtasks to the target execution node for execution, the execution results of the ready subtasks also need to be stored so that subsequent subtasks that depend on the ready subtasks can obtain input data.

[0068] Furthermore, when storing the execution results of each subtask, a unique subtask identifier is assigned to each subtask, and the execution result is stored in association with the unique subtask identifier; When a subsequent subtask obtains input data, it queries the execution result corresponding to the unique subtask identifier of the preceding subtask based on the dependency relationship of the subsequent subtask in the task dependency graph, and uses the queryed execution result as the input data of the subsequent subtask.

[0069] For example, for the dependency relationship JobA→JobB in the task dependency graph, JobB retrieves the execution result corresponding to the unique subtask identifier of JobA from the intermediate result storage unit 14 as its input before execution.

[0070] Furthermore, when a ready subtask is completed and all its prerequisites for subsequent subtasks are satisfied, the subsequent subtask is treated as a new ready subtask. The determination and allocation of the target execution node for the new ready subtask continues until all subtasks are completed, forming a recursive scheduling loop based on the topological order of the directed acyclic graph.

[0071] Furthermore, when a subtask of an execution node fails to execute or times out, the subtask is reassigned to another execution node that meets the task requirements of the subtask. When there is no execution node that meets the task requirements of the subtask, the task requirements of the subtask are downgraded, and the downgraded subtask is reassigned to an execution node that meets the downgraded task requirements.

[0072] S4. Summarize the execution results of each subtask and return them to the user.

[0073] Understandably, after all subtasks have been executed, the result aggregation unit 15 summarizes the execution results of each subtask and returns them to the user. When summarizing the execution results of each subtask, a fusion process is performed on the execution results of multiple subtasks to generate a final output result in a unified format. The scheduling log and execution log of the task execution process are also returned to the user.

[0074] Furthermore, after all subtasks have been completed, the execution time, success status, and resource consumption information of each subtask must be recorded. Based on the recorded execution time, success status, and resource consumption information, the weight coefficients are optimized and updated online for use in determining the target execution nodes of subsequent tasks.

[0075] To better understand the technical solution of this embodiment, the complete operation process of this embodiment will be described in detail below using the composite task of "submitting code to generate, automatically testing, and exporting reports" as an example: The user submits an original task request through terminal 41, and control node 10 parses it into a unified task description structure. Task planning unit 12 decomposes the task into three sub-tasks with sequential dependencies: code_generation → build_test → report_export, constructs the corresponding task dependency graph, and completes the validity verification. The capability-aware scheduling unit 13 identifies when the code_generation subtask is ready, calculates a score based on the skill set information and model capability information of each execution node, and selects the target execution node for execution. The execution result of code_generation is uploaded to intermediate result storage unit 14 and associated with a unique subtask identifier. The prerequisites of build_test subtask are then satisfied, and it enters the recursive scheduling process. It is then assigned to an execution node with test execution capability by capability-aware scheduling unit 13. After build_test is completed, the report_export subtask is similarly triggered, scheduled, and executed; After all subtasks are completed, the result aggregation unit 15 merges the output results into a unified format and returns them to the user along with the scheduling log; Control node 10 performs online optimization and updates to the weight coefficients based on the execution record of this operation, for use in subsequent scheduling.

[0076] Example 2 Please see Figure 2The distributed intelligent agent computing system of this embodiment is used to execute the distributed intelligent agent computing method described in Embodiment 1. The distributed intelligent agent computing system includes a control node 10, multiple execution nodes, and a user terminal 41. The multiple execution nodes include a high-computing-power execution node 21, a general-purpose computing execution node 22, and an edge execution node 23. The control node 10 specifically includes: The node registration unit 11 is used to store the node capability information reported by each execution node. The node capability information includes at least the computing resource information of each execution node, the model capability information describing the type of language model reasoning ability that each execution node can call, and the skill set information describing the type of task processing function that each execution node can perform.

[0077] The task planning unit 12 is used to generate a task dependency graph based on the received user task request. The task dependency graph has multiple subtasks as nodes and the dependency relationships between multiple subtasks as directed edges.

[0078] The capability-aware scheduling unit 13 is used to identify ready subtasks whose prerequisites in the task dependency graph are all satisfied. Based on the matching between the node capability information stored in the node registration unit 11 and the task requirements of the ready subtasks, it determines the target execution node, assigns the ready subtasks to the target execution node for execution, and triggers the scheduling of the successor subtasks when the ready subtasks are completed and all prerequisites of their successor subtasks are satisfied. The capability-aware scheduling unit 13 is also used to perform locking processing on the ready subtasks after allocation. When the target execution node returns a resource unavailable response, the lock is released and a new target execution node is selected. When the execution of a subtask of an execution node fails or the response times out, the subtask is reassigned to other execution nodes that meet the task requirements. When there are no execution nodes that meet the task requirements, the task requirements are downgraded and then reassigned.

[0079] Intermediate result storage unit 14 is used to store the execution results of each subtask so that subsequent subtasks can obtain input data.

[0080] The result aggregation unit 15 is used to summarize the execution results of each subtask after all subtasks have been executed and return them to the user.

[0081] In this embodiment, the working principle of each unit of the distributed intelligent agent computing system corresponds one-to-one with the description of the corresponding steps in Embodiment 1, and will not be repeated here.

[0082] Example 3 This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the distributed intelligent agent computing method described in Embodiment 1.

[0083] Computer-readable storage media can be any type of media capable of storing program code, such as disks, optical discs, read-only memory (ROM), random access memory (RAM), flash memory, hard disks, or solid-state drives, or a combination of the above storage media.

[0084] Combination Figure 1 and Figure 2 This invention, on the one hand, introduces model capability information describing the reasoning ability type of the language model and skill set information describing the task processing function type into the node capability information, enabling the scheduling system to perceive the semantic capabilities of each execution node. When determining the target execution node, it can accurately match the model type and skill type required by the sub-task, fundamentally bridging the gap in existing distributed frameworks that can only perceive computing resources but not the semantic capabilities of the agent. On the other hand, by automatically generating a task dependency graph from the task requests submitted by the user, it realizes the automatic transformation from task description to executable directed acyclic graph, freeing users from the tedious manual task splitting work and significantly improving the automation level of multi-agent tasks. Furthermore, through the recursive scheduling mechanism based on the task dependency graph and the storage of the execution results of each sub-task, each execution node can collaboratively complete a multi-level task flow with complex dependencies, ensuring the integrity and consistency of data flow between sub-tasks while making full use of distributed heterogeneous computing resources.

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

Claims

1. A method of distributed agent computation, the method comprising: Includes the following steps: Receive and store the node capability information reported by each execution node. The node capability information includes at least the computing resource information of each execution node, the model capability information describing the type of language model reasoning ability that each execution node can call, and the skill set information describing the type of task processing function that each execution node can perform. Receive a task request submitted by a user, and generate a task dependency graph based on the task request. The task dependency graph has multiple subtasks as nodes and the dependency relationships between the multiple subtasks as directed edges. Identify ready subtasks that satisfy all prerequisites in the task dependency graph, determine target execution nodes based on the matching of node capability information and task requirements of ready subtasks, and assign ready subtasks to target execution nodes for execution until all subtasks are completed. The execution results of each subtask are summarized and returned to the user.

2. The distributed agent computing method of claim 1, wherein, The step of generating the task dependency graph based on the task request specifically includes: The task request is automatically broken down into multiple sub-tasks, and the dependencies between the sub-tasks are determined. The task dependency graph is constructed using the multiple subtasks as nodes and the dependencies as directed edges.

3. The distributed agent computing method of claim 1, wherein, After the ready subtask is assigned to the target execution node for execution, the execution result of the ready subtask also needs to be stored so that subsequent subtasks that depend on the ready subtask can obtain input data. When a ready subtask is completed and all its prerequisites for subsequent subtasks are satisfied, the subsequent subtask is treated as a new ready subtask. The determination and allocation of target execution nodes for the new ready subtask continues until all subtasks are completed.

4. The distributed agent computing method of claim 1, wherein, The node capability information also includes the current load information, energy consumption parameter information and node type label of each execution node. The current load information includes the resource utilization rate and task queue length of each execution node. The node type label includes at least one of high computing power node label, general computing node label and edge node label.

5. The distributed agent computing method of claim 4, wherein, Execution nodes labeled with high computing power nodes are used to deploy large-scale language models, execution nodes labeled with general computing nodes are used to deploy medium-scale language models, and execution nodes labeled with edge nodes are used to deploy lightweight language models. When determining the target execution node, the execution node with the corresponding type of language model is determined as the target execution node based on the correspondence between the model type required by the ready subtask and the model capability information of each execution node.

6. The distributed agent computing method of claim 2, wherein, The step of automatically decomposing the task request into multiple sub-tasks specifically includes: For task requests that conform to a predefined rule template, a set of subtasks and their dependencies are generated based on the predefined rule template. For task requests that do not conform to the predefined rule template, the language model is invoked to perform semantic parsing on the task request, generating a set of subtasks and dependencies.

7. The distributed agent computing method of claim 6, wherein, After generating the task dependency graph, a validity check is performed on the task dependency graph. The validity check sequentially performs acyclicity detection, input / output integrity check of each subtask, dependency closure check, and resource executability check. If any check fails, the rule is corrected or the language model is called again to generate a set of subtasks and dependencies, and the validity check is performed again until all check items pass.

8. The distributed agent computing method of claim 4, wherein, Determining the target execution node based on the matching between the node capability information and the task requirements of the ready subtasks specifically includes: Based on the inclusion relationship between the skill types required by the ready subtask and the skill set information of each execution node, a skill matching item is calculated; based on the inclusion relationship between the model types required by the ready subtask and the model capability information of each execution node, a model matching item is calculated; based on the ratio of the available computing resources of each execution node to the computing resources required by the ready subtask, a resource adaptation item is calculated; based on the resource utilization rate of each execution node, an idle metric is calculated and the idle metric is used as an idle item; based on the historical task execution success rate of each execution node, a reliability item is calculated; and based on the product of the energy consumption parameter information of each execution node and the expected runtime of the ready subtask, an energy consumption cost item is calculated. The skill matching item, model matching item, resource adaptation item, idle item, and reliability item are weighted and summed according to their respective weight coefficients. The product of the energy consumption cost item and its corresponding weight coefficient is then subtracted, and the execution node with the largest difference is selected as the target execution node.

9. The distributed agent computing method of claim 8, wherein, The weighting coefficients are set by configuration parameters during initialization. During operation, they are adjusted according to the task type, adaptively adjusted according to the current load information of each execution node, and optimized and updated online based on the task completion time, success rate, and resource consumption information in the historical scheduling execution results.

10. The distributed agent computing method of claim 8, wherein, The execution nodes are sorted in descending order based on the difference, and a preset number of execution nodes with the highest difference ranking are selected to form a candidate execution node set. Among the candidate execution node set, the execution node with the lowest resource utilization rate is selected as the target execution node based on the resource utilization rate of each execution node.

11. The distributed agent computing method of claim 9, wherein, After all subtasks are completed, the execution time, success status, and resource consumption information of each subtask must be recorded. Based on the recorded execution time, success status, and resource consumption information, the weight coefficients are optimized and updated online for use in determining the target execution nodes of subsequent tasks.

12. The distributed intelligent agent computing method as described in claim 1, characterized in that, When there are multiple ready subtasks that are independent of each other in the task dependency graph, a target execution node is determined concurrently for each ready subtask in the same scheduling round, and the multiple ready subtasks are synchronously distributed to their respective target execution nodes for parallel execution.

13. The distributed agent computing method of claim 3, wherein, When storing the execution results of each subtask, a unique subtask identifier is assigned to each subtask, and the execution result is stored in association with the unique subtask identifier; When a subsequent subtask obtains input data, it queries the execution result corresponding to the unique subtask identifier of the preceding subtask based on the dependency relationship of the subsequent subtask in the task dependency graph, and uses the queryed execution result as the input data of the subsequent subtask.

14. The distributed agent computing method of claim 1, wherein, After assigning the ready subtask to the target execution node, it is also necessary to perform a locking process on the ready subtask so that the ready subtask is no longer assigned to other execution nodes; When the target execution node returns a resource unavailable response, the locked state of the ready subtask is released, and a new target execution node is determined based on the matching of the node capability information and the task requirements of the ready subtask.

15. The distributed agent computing method of claim 1, wherein, When a subtask of an execution node fails to execute or times out, the subtask is reassigned to another execution node that meets the task requirements of the subtask. When there is no execution node that meets the task requirements of the subtask, the task requirements of the subtask are downgraded, and the downgraded subtask is reassigned to an execution node that meets the downgraded task requirements.

16. The distributed agent computing method of claim 1, wherein, Each execution node continuously updates its node capability information via periodic heartbeats. The update frequency of dynamic capability information reflecting the current operating status of each execution node is higher than the update frequency of static capability information reflecting the hardware configuration of each execution node. If a heartbeat update is not received from a certain execution node within a preset time limit, the execution node will be marked as unavailable and excluded from the range of available execution nodes for subsequent ready subtasks.

17. The distributed agent computing method of claim 1, wherein, When the task request contains a priority parameter, after identifying the ready subtasks in the task dependency graph, the ready subtasks are sorted according to the priority parameter, and the target execution node is determined and the allocation is completed for the ready subtasks that are ranked higher. Ready subtasks with the same priority are scheduled sequentially according to the topological order of the task dependency graph.

18. The distributed agent computing method of claim 1, wherein, Before receiving a task request submitted by a user, it is also necessary to receive an original task request submitted through at least one of the following methods: application, web page, or program call interface. The original task request is parsed to generate a unified task description structure containing task instructions, input data files, and constraint parameters, and the unified task description structure is used as the task request.

19. The distributed agent computing method of claim 1, wherein, The step of assigning the ready subtask to the target execution node for execution specifically includes: Call the locally deployed language model to perform agent reasoning and generate execution steps; Based on the skill type required by the ready subtask, at least one of a code executor, a data processing tool, or a visual processing tool is invoked to execute the execution steps, thereby generating the execution result of the ready subtask; The execution result is stored so that subsequent subtasks that depend on the ready subtask can read it as input.

20. The distributed agent computing method of claim 1, wherein, When summarizing the execution results of each subtask, the execution results of multiple subtasks are merged to generate a final output result in a unified format, and the scheduling log and execution log of the task execution process are returned to the user together.

21. The distributed agent computing method of claim 1, wherein, Each subtask node in the task dependency graph also carries the model type label and skill type label required by its corresponding subtask; When determining the target execution node, execution nodes that simultaneously meet the model type requirements and skill type requirements are selected based on the matching results of the model type label and the model capability information of each execution node, and the matching results of the skill type label and the skill set information of each execution node.

22. The distributed agent computing method of claim 16, wherein, When each execution node first connects, it reports all the contents of the node capability information. During operation, it only periodically reports the changes in the dynamic capability information.

23. A distributed agent computing system, characterized by include: The node registration unit is used to store the node capability information reported by each execution node. The node capability information includes at least the computing resource information of each execution node, the model capability information describing the type of language model reasoning ability that each execution node can call, and the skill set information describing the type of task processing function that each execution node can perform. The task planning unit is used to generate a task dependency graph based on the received user task request. The task dependency graph has multiple subtasks as nodes and the dependency relationships between the multiple subtasks as directed edges. The capability-aware scheduling unit is used to identify ready subtasks that satisfy all prerequisites in the task dependency graph, determine the target execution node based on the matching of node capability information stored in the node registration unit with the task requirements of the ready subtasks, assign the ready subtasks to the target execution node for execution, and trigger the scheduling of the subsequent subtasks when the ready subtasks are completed and all prerequisites of their subsequent subtasks are satisfied. The intermediate result storage unit is used to store the execution results of each subtask so that subsequent subtasks can obtain input data; The results aggregation unit is used to summarize the execution results of each subtask after all subtasks have been executed and return them to the user.

24. The distributed agent computing system of claim 23, wherein, The capability-aware scheduling unit is also used for: After assigning the ready subtask to the target execution node, a locking process needs to be performed on the ready subtask. When the target execution node returns a resource unavailable response, the locking status of the ready subtask is released and a new target execution node is selected. When a subtask of an execution node fails to execute or times out, the subtask is reassigned to another execution node that meets the task requirements of the subtask. If no execution node meets the task requirements of the subtask, the task requirements of the subtask are downgraded and then reassigned.

25. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the distributed intelligent agent computing method as described in any one of claims 1-22.

Images