Multi-agent cooperative task processing method and device, equipment, medium and product
Patent Information
- Application Number
- CN202610804740.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-04
- Publication Date
- 2026-10-16
AI Technical Summary
[0003]本发明提供一种多智能体协同任务处理方法、装置、设备、介质及产品,用以解决现有技术中因缺乏跨域智能体动态调度能力而导致目标任务处理效率低下的技术问题
[0015] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-agent cooperative task processing method as described above.
Smart Images

Figure CN122933644A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of intelligent agent technology, and in particular to a method, apparatus, device, medium and product for multi-agent collaborative task processing. Background Technology
[0002] Existing distributed agent systems, when processing target tasks, lack the ability to dynamically schedule agents across domains, making it difficult to achieve efficient multi-agent collaborative processing, resulting in low overall efficiency. Summary of the Invention
[0003] This invention provides a method, apparatus, device, medium, and product for multi-agent collaborative task processing, which solves the technical problem of low efficiency in target task processing caused by the lack of cross-domain agent dynamic scheduling capability in the prior art.
[0004] This invention provides a multi-agent cooperative task processing method, comprising the following steps: Receive the target task; The target task is analyzed to generate a task plan graph; Based on the task plan graph, candidate third-level agents are obtained from the local domain registry center, or candidate third-level agents from other domains are obtained through cross-domain communication; Based on the comprehensive scores of the candidate Level 3 agents, the target Level 3 agents for each subtask in the task planning graph are determined from the candidate Level 3 agents, and each subtask is sent to the corresponding target Level 3 agent so that the corresponding subtask can be executed based on the target Level 3 agent.
[0005] According to a multi-agent cooperative task processing method provided by the present invention, the step of obtaining candidate third-level agents from the local domain registry center based on the task plan graph, or obtaining candidate third-level agents from other domains through cross-domain communication, includes: Determine the capability tags and resource specifications required for each subtask in the task planning map; Select Level 3 agents that meet the capability tags and resource specifications and are online from the local domain registry center, and add them to the candidate Level 3 agents of the local domain. Determine whether the number of candidate level 3 agents in this domain meets the task distribution requirements; If the conditions are not met, then request the global scheduling platform or the first-level agents of other domains to obtain candidate third-level agents from other domains, and add the candidate third-level agents from other domains to the candidate list; All Level 3 agents in the candidate list are selected as candidate Level 3 agents.
[0006] According to a multi-agent cooperative task processing method provided by the present invention, the step of determining the target third-level agent for each subtask in the task planning graph based on the comprehensive scores of the candidate third-level agents includes: Obtain the load status, response time, resource matching degree, and cross-domain communication cost of each candidate Level 3 agent; Based on the load status, response time, resource matching degree, and cross-domain communication cost, calculate the comprehensive score of each candidate Level 3 agent for each sub-task; Based on the comprehensive score, the target Level 3 agent for each subtask in the task planning graph is determined from the candidate Level 3 agents.
[0007] According to a multi-agent cooperative task processing method provided by the present invention, the step of calculating the comprehensive score of each candidate third-level agent for each sub-task based on the load state, the response time, the resource matching degree, and the cross-domain communication cost includes: Determine the task priority of each subtask in the task planning graph; Based on the task priorities, determine the weights of the scoring dimensions; Based on the weights of the scoring dimensions, the load status, the response time, the resource matching degree, and the cross-domain communication cost, calculate the comprehensive score of each candidate Level 3 agent for each sub-task.
[0008] A multi-agent cooperative task processing method provided by the present invention further includes: Receive the execution status feedback from the target level 3 intelligent agent; When an execution exception is detected in a subtask based on the execution status, the exception type is determined based on the execution status, wherein the exception type includes at least one of node exception, task execution exception, distribution exception, and cross-domain collaboration exception. The corresponding rescheduling strategy is executed according to the anomaly type, and the subtask is migrated to the new target Level 3 agent.
[0009] According to a multi-agent cooperative task processing method provided by the present invention, the step of executing a corresponding rescheduling strategy according to the anomaly type and migrating the subtask to a new target third-level agent includes: When the anomaly type is node anomaly, the target Level 3 agent executing the subtask is identified as an abnormal node; Obtain other Level 3 agents, excluding the abnormal node, as candidate nodes from the local domain registry center; Based on the target scores of each candidate node, a new target level 3 agent is determined from the candidate nodes, and the subtask is transferred to the new target level 3 agent.
[0010] According to a multi-agent cooperative task processing method provided by the present invention, the step of executing a corresponding rescheduling strategy according to the anomaly type and migrating the subtask to a new target third-level agent includes: When the exception type is a task execution exception, the target level 3 agent executing the subtask is identified as a fault node; The third-level agents with a load rate lower than the faulty node are obtained from the local domain registry as candidate nodes. Based on the target scores of each candidate node, a new target level 3 agent is determined from the candidate nodes, and the subtask is transferred to the new target level 3 agent.
[0011] According to a multi-agent cooperative task processing method provided by the present invention, the step of executing a corresponding rescheduling strategy according to the anomaly type and migrating the subtask to a new target third-level agent includes: When the exception type is a distribution exception, the target third-level agent that failed to receive the subtask is identified as a failed node. Retry the failed node and record the number of retries; If the retry is successful, the rescheduling process ends. If the retry fails and the current number of retries has not reached the preset threshold, then continue to retries the failed node; If the retry fails and the current number of retries has reached the preset threshold, then other Level 3 agents besides the failed node are obtained from the local registry center as candidate nodes. Based on the target scores of each candidate node, a new target level 3 agent is determined, and the subtasks are distributed to the new target level 3 agent.
[0012] According to a multi-agent cooperative task processing method provided by the present invention, the step of executing a corresponding rescheduling strategy based on the exception type includes: When the anomaly type is a cross-domain collaboration anomaly, the target level 3 agent executing the subtask is identified as an abnormal cross-domain node, and the severity of the anomaly of the abnormal cross-domain node is determined. If the severity of the anomaly is mild, the abnormal cross-domain node will be retried. If the retry is successful, the abnormal cross-domain node will continue to be used as the new target Level 3 agent. If the retry fails, a new target Level 3 agent will be selected from the local domain registry. If the severity of the anomaly is moderate, then a new target Level 3 agent is selected from other Level 3 agents in the same region; If the severity of the anomaly is classified as severe, a new target Level 3 agent is selected from the local domain registry center, and a cross-domain operation and maintenance alarm is triggered.
[0013] The present invention also provides a multi-agent collaborative task processing device, comprising the following modules: The receiving module is used to receive the target task; The parsing module is used to parse the target task and generate a task plan graph; The acquisition module is used to acquire candidate third-level agents from the local domain registry center based on the task plan graph, or to acquire candidate third-level agents from other domains through cross-domain communication; The determination module is used to determine the target level three agent for each subtask in the task plan graph from the candidate level three agents based on the comprehensive score of the candidate level three agents, and to issue each subtask to the corresponding target level three agent so as to execute the corresponding subtask based on the target level three agent.
[0014] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the multi-agent cooperative task processing method described above.
[0015] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-agent cooperative task processing method as described above.
[0016] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements any of the multi-agent cooperative task processing methods described above.
[0017] This invention provides a multi-agent collaborative task processing method, apparatus, device, medium, and product. The method involves receiving a target task; parsing the target task to generate a task plan graph; obtaining candidate third-level agents from a local domain registry center based on the task plan graph, or obtaining candidate third-level agents from other domains through cross-domain communication; determining the target third-level agents for each sub-task in the task plan graph from the candidate third-level agents based on their comprehensive scores; and distributing each sub-task to the corresponding target third-level agent for execution. This solves the technical problem of low target task processing efficiency due to the lack of cross-domain agent dynamic scheduling capabilities. Compared to existing technologies, this invention achieves automatic decomposition and structured arrangement of complex objectives through a task planning graph, enabling globally interpretable task distribution. Simultaneously, it introduces a cross-domain communication mechanism to proactively and dynamically supplement candidate agents from other domains when local resources are insufficient, breaking down the resource boundaries of a single domain. Furthermore, by combining multi-dimensional comprehensive scoring (such as load, response time, resource matching degree, and cross-domain cost), it accurately matches the optimal Level 3 agent for each sub-task. Therefore, this invention achieves fully automated cross-domain collaborative scheduling, significantly improving the processing efficiency of target tasks, system resource utilization, and scheduling flexibility. Attached Figure Description
[0018] To more clearly illustrate the technical solutions in this 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 some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0019] Figure 1 This is one of the flowcharts of the multi-agent collaborative task processing method provided by the present invention.
[0020] Figure 2 This is a system overall framework diagram of the multi-agent collaborative task processing method provided by the present invention.
[0021] Figure 3 This is the second flowchart of the multi-agent collaborative task processing method provided by the present invention.
[0022] Figure 4 This is the third flowchart of the multi-agent collaborative task processing method provided by the present invention.
[0023] Figure 5 This is a schematic diagram of the structure of the multi-agent collaborative task processing device provided by the present invention.
[0024] Figure 6 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation
[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0026] The following is combined Figure 1 , Figure 3 as well as Figure 4 The present invention describes a multi-agent cooperative task processing method applicable to any multi-agent cooperative task processing. The executing entity of this method can be an electronic device or a multi-agent cooperative task processing device installed in the electronic device. The multi-agent cooperative task processing device can be implemented by software, hardware, or a combination of both.
[0027] Figure 1 This is one of the flowcharts illustrating the multi-agent cooperative task processing method provided by the present invention, applied to the scheduling node in a multi-agent cooperative task processing system, such as... Figure 1 As shown, the multi-agent cooperative task processing method includes: Step 101: Receive the target task; It should be noted that the target task refers to a complete business request submitted by a business system or user terminal through the API gateway, such as a logistics delivery order, a data processing job, or a real-time monitoring instruction. The scheduling node, as a first-level intelligent agent, receives target tasks from business systems through the unified API gateway within its domain. The API gateway first authenticates, authorizes, and controls the flow of the task; after successful verification, it forwards the target task to the corresponding first-level intelligent agent in the domain.
[0028] In specific implementations, such as Figure 2As shown, the multi-agent collaborative task processing system adopts a hierarchical deployment approach: Level 1 agents (such as A0, B0, and J0) serve as the core scheduling nodes for each business domain. They share a single codebase but are deployed as multiple independent instances with different configurations (network space, processing engine, large model, etc.), responsible for task planning, distribution, and state management within their respective domains. Level 3 agents (such as A1, A2, B1, B2, J1, and J2) act as execution nodes, responsible for executing specific sub-tasks and feeding back results to the Level 1 agents. Each business domain has an independent API gateway (such as API gateway for domain A and API gateway for domain B) as a unified entry point for business systems or user terminals, enabling security management such as authentication, authorization, and traffic control. Simultaneously, each domain deploys an independent registry center (based on Nacos) for the registration and discovery of Level 1 and Level 3 agents: Level 1 agents load the AgentCard list from the registry center to achieve unified management of Level 3 agents within the domain, and their configuration information is stored in a MySQL database for dynamic updates. Different business domains communicate across domains via the A2A protocol, supporting task collaboration and data sharing among Level 1 agents. In task management, the first-level agent monitors the execution status through the task management module, while the third-level agent reports the execution results. Task status (such as an asynchronous task status table) is stored in MySQL for global querying and tracing. Furthermore, the system integrates a large-scale AI platform service to provide the agents with intelligent decision-making and natural language processing capabilities.
[0029] Step 102: Analyze the target task and generate a task plan graph; It should be noted that a task planning graph refers to a multi-level task structure formed after the target task is structurally decomposed. It includes several subtasks and the types, priorities, dependencies, and execution time limits of the subtasks. A subtask is the smallest execution unit of the target task and can be independently assigned to a third-level agent for execution.
[0030] In practice, the scheduling node invokes the large model service of the domain AI platform or the local rule engine to analyze the business semantics of the target task. Based on the task type and input parameters, the large model infers the key action sequence required to complete the task and identifies the pre-dependencies between actions, thereby generating a structured task plan graph.
[0031] Step 103: Based on the task plan graph, obtain candidate third-level agents from the local domain registry center, or obtain candidate third-level agents from other domains through cross-domain communication; It should be noted that the local registry center refers to the service discovery component of the business domain to which the current scheduling node belongs. It stores and manages the AgentCard information (including identity ID, capability tag, resource specifications, online status, current load, etc.) of all Level 3 agents within this domain. Cross-domain communication refers to data exchange between Level 1 agents from different business domains via the A2A protocol, or querying cross-domain agent information through the global scheduling platform. A candidate Level 3 agent refers to an execution node with the potential to execute a specific subtask.
[0032] In the implementation, the scheduling node traverses each subtask in the task planning graph. Based on the capability tags and resource specifications required by the subtask, it queries the local domain registry to obtain a list of all online, capability-matching Level 3 agents. If the number of matching agents in the local domain is insufficient (e.g., at least one execution node is required but there are no matching agents in the local domain), the scheduling node sends a cross-domain query request via the A2A protocol to the global scheduling platform (based on MySQL + ClickHouse) or Level 1 agents in other domains. The request includes the capability requirements of the subtask. Other domains refer to different business domains or geographical areas that are distinct from the business domain to which the current scheduling node belongs (i.e., "local domain") and independently deployed with complete agent clusters and supporting services (such as API gateways, registry centers, Level 1 agents, and Level 3 agents). The global scheduling platform returns information on matching agents in other domains, and the scheduling node adds these cross-domain agents to the candidate list.
[0033] Step 104: Based on the comprehensive score of the candidate Level 3 agents, determine the target Level 3 agents for each subtask in the task plan graph from the candidate Level 3 agents, and send each subtask to the corresponding target Level 3 agent so that the corresponding subtask can be executed based on the target Level 3 agent.
[0034] It should be noted that the comprehensive score is a value obtained by weighting multiple dimensions (load status, response time, resource matching degree, and cross-domain communication cost) of the candidate level 3 agent, and is used to quantitatively evaluate the suitability of the agent to perform the current subtask.
[0035] In the implementation, the scheduling node calculates a comprehensive score for each candidate Level 3 agent for the current subtask. The scoring dimensions include: load status (lower load, higher score), response timeliness (shorter historical average response time, higher score), resource matching degree (higher matching degree between available and required resources, higher score), and cross-domain communication cost (lower communication cost for local nodes, higher score; for cross-domain nodes, the score is adjusted based on communication latency). The scheduling node weights and sums the scores of each dimension according to preset weights (e.g., load 30%, response timeliness 25%, resource matching degree 25%, cross-domain communication cost 20%) to obtain the comprehensive score. For each subtask, the scheduling node selects the candidate agent with the highest comprehensive score as the target Level 3 agent, and then sends the subtask parameters, execution time limit, and status callback address to the target Level 3 agent via the A2A protocol, waiting for a confirmation of receipt.
[0036] This invention achieves automatic decomposition and structured orchestration of complex objectives through a task planning graph, enabling globally interpretable task distribution. Simultaneously, it introduces a cross-domain communication mechanism to proactively and dynamically supplement candidate agents from other domains when local resources are insufficient, breaking down the resource boundaries of a single domain. Furthermore, by combining multi-dimensional comprehensive scoring (such as load, response time, resource matching degree, and cross-domain cost), it accurately matches the optimal Level 3 agent for each subtask. Therefore, this invention achieves fully automated cross-domain collaborative scheduling, significantly improving the processing efficiency of target tasks, system resource utilization, and scheduling flexibility.
[0037] Based on any of the above embodiments, the step of obtaining candidate third-level agents from the local domain registry center or obtaining candidate third-level agents from other domains through cross-domain communication based on the task plan graph includes: Determine the capability tags and resource specifications required for each subtask in the task planning map; Select Level 3 agents that meet the capability tags and resource specifications and are online from the local domain registry center, and add them to the candidate Level 3 agents of the local domain. Determine whether the number of candidate level 3 agents in this domain meets the task distribution requirements; If the conditions are not met, then request the global scheduling platform or the first-level agents of other domains to obtain candidate third-level agents from other domains, and add the candidate third-level agents from other domains to the candidate list; All Level 3 agents in the candidate list are selected as candidate Level 3 agents.
[0038] It should be noted that capability tags are identifiers describing the functional attributes (such as "image recognition," "speech synthesis," and "cold chain transportation") possessed by a Level 3 agent. Resource specifications refer to the hardware or software resource requirements for executing subtasks, such as the required number of CPU cores, memory size, storage space, and network bandwidth. The domain registry stores real-time information on all Level 3 agents in this domain, including the list of capability tags reported by each agent, available resource specifications, and heartbeat status (online / offline). Task distribution requirements refer to the number of agents or redundancy requirements needed to execute all subtasks in the task planning graph.
[0039] In the implementation, the scheduling node traverses the list of nodes in the task planning graph. For each subtask node, the scheduling node accesses its pre-filled fields: required_capabilities (an array of strings, e.g., ["Cold Chain Transportation", "GPS"]), required_cpu (an integer, per core), and required_memory (an integer, per MB). If required_capabilities is empty, the scheduling node queries the local capability mapping table based on the subtask's type (e.g., inferred from the task name), for example, the task type "Image Recognition" maps to the capability labels "GPU Computing" and "Image Processing". The scheduling node stores the finally determined required capability labels and resource specifications in a temporary structure for use in the next step.
[0040] It's important to note that the global scheduling platform is a cross-domain coordination center. It receives core indexes synchronized from the registration centers of various domains, forming a cross-domain agent capability graph. First-level agents in other domains manage the third-level agents within their respective domains and can directly respond to cross-domain queries. Specifically, when the number of candidate third-level agents in a domain is insufficient, the scheduling node sends a cross-domain query request to the global scheduling platform via the A2A protocol. This request carries the capability tags, resource specifications, and the required number of agents to supplement the subtask. The global scheduling platform queries its cross-domain index (aggregating core information from the registration centers of various domains), filters out eligible online agents in other domains, and returns the AgentCard information for these agents. The scheduling node can also directly send requests to first-level agents in neighboring domains, which will then query and return the results. Upon receiving cross-domain agent information, the scheduling node appends these agent objects to the candidate list and marks them as cross-domain nodes to increase communication cost weight during subsequent scoring.
[0041] Understandably, the candidate Level 3 agents include those selected from the current domain and those added from other domains. Specifically, the scheduling node merges the candidate list from the current domain with the list of agents from other domains. During the merging process, deduplication is performed using the globally unique identifier of the agent (e.g., domain ID + agent ID) as the key to avoid adding the same agent repeatedly. The final list is the set of candidate Level 3 agents for this subtask.
[0042] This invention prioritizes selecting online Level 3 agents that meet the capability tags and resource specifications from within the local domain, reducing communication costs and latency when resources are sufficient within the domain. When there are insufficient candidates within the domain, cross-domain supplementation is automatically achieved through a global scheduling platform or other domain-level agents, ensuring resource coverage and success rate in task distribution. This strategy implements an adaptive resource acquisition mechanism that prioritizes local resources and provides cross-domain backup, improving the system's resilience to resource fluctuations while ensuring timely task execution and avoiding task blocking caused by single-point resource bottlenecks.
[0043] Figure 3 This is the second flowchart of the multi-agent cooperative task processing method provided by the present invention, as shown in Figure 3. Step 104 further includes steps 1041 to 1043: Step 1041: Obtain the load status, response time, resource matching degree, and cross-domain communication cost of each candidate Level 3 agent; It should be noted that the load status reflects the current workload of the Level 3 agent, typically represented by a combination of metrics such as CPU utilization, memory utilization, and task queue length. Response timeliness refers to the historical average latency from receiving a task to completing execution or returning a response result. Resource matching degree refers to the proximity between the agent's available resources (such as remaining CPU and memory) and the resource requirements of the subtask. Cross-domain communication cost refers to the network latency, bandwidth consumption, and compliance overhead that may result from cross-domain data transmission between the scheduling node and the agent.
[0044] In the implementation, the scheduling node can read the dynamic information of each candidate agent from the heartbeat data of the registry center, the monitoring indicator database, or the local cache. For Level 3 agents in the local domain, load status and response time are usually reported via heartbeat packets sent by the agent every few seconds; resource matching degree can be obtained by comparing the available resources reported by the agent with the subtask requirements; cross-domain communication cost is set to zero for agents in the local domain, and estimated based on historical communication latency for agents in cross-domain domains. The scheduling node aggregates this data by agent ID to form an evaluation record.
[0045] Step 1042: Based on the load status, response time, resource matching degree, and cross-domain communication cost, calculate the comprehensive score of each candidate third-level agent for each sub-task; In the specific implementation, when calculating the comprehensive score, the original values of the four dimensions mentioned above can first be normalized to a score range of 0 to 100: Load status score = 100 - load rate; Response timeliness score = maximum allowable latency - actual latency / maximum allowable latency × 100, and not lower than 0; Resource matching score = min(available CPU / required CPU, available memory / required memory) × 100; Cross-domain communication cost score: 100 for the local domain, and linearly calculated for cross-domain communication based on the estimated latency. Then, the four scores are multiplied by preset weights (e.g., load status 30%, response timeliness 25%, resource matching 25%, cross-domain communication cost 20%) and summed to obtain the comprehensive score. The higher the score, the more suitable the candidate level 3 agent is to execute the current subtask.
[0046] Step 1043: Based on the comprehensive score, determine the target level 3 agent for each subtask in the task plan graph from the candidate level 3 agents.
[0047] Understandably, the scheduling node can sort the candidate Level 3 agents in the candidate agent list for each subtask according to their comprehensive scores from highest to lowest. After sorting, the agent ranked first is selected as the target Level 3 agent for that subtask. If multiple agents have the same comprehensive score, the scheduling node can further compare secondary indicators, such as historical task success rate, remaining task queue length, or randomly select one. After determining the target, the scheduling node encapsulates the subtask into a message and sends it to the target Level 3 agent via the A2A protocol, while recording the target agent's ID and decision time.
[0048] This invention achieves multi-dimensional quantitative scoring by comprehensively evaluating the load status, response time, resource matching degree, and cross-domain communication cost of candidate third-level agents, thereby accurately matching the optimal target agent for each sub-task. This mechanism can dynamically balance system load, reduce task response latency, improve resource utilization, and prioritize nodes with lower communication costs in cross-domain scenarios, effectively reducing network overhead and bandwidth consumption. Overall, this method enhances the scientific nature and adaptability of multi-agent collaborative scheduling, ensuring the efficiency and stability of task execution.
[0049] Based on any of the above embodiments, the step of calculating the comprehensive score of each candidate third-level agent for each sub-task based on the load status, response time, resource matching degree, and cross-domain communication cost includes: Determine the task priority of each subtask in the task planning graph; Based on the task priorities, determine the weights of the scoring dimensions; Based on the weights of the scoring dimensions, the load status, the response time, the resource matching degree, and the cross-domain communication cost, calculate the comprehensive score of each candidate Level 3 agent for each sub-task.
[0050] It's important to note that task priority is a level or numerical value representing the importance or urgency of a subtask. Scheduling nodes can derive the task priority of each subtask from its attributes or context. This task priority can be used to identify the relative importance and urgency of different subtasks within the business context, and this information can guide subsequent scheduling strategies, thereby ensuring that critical tasks receive better resources.
[0051] In the implementation, the scheduling node parses the metadata of each subtask in the task planning graph. The scheduling node can directly read a predefined priority field from the structured description of the subtask, such as "high," "medium," or "low." If this field is not present, the scheduling node can also dynamically calculate a priority value based on the subtask's type, the stage of the business process it belongs to, or its approaching timeout. For example, a subtask on a critical path that depends on all other subtasks will be automatically assigned the highest priority.
[0052] Understandably, the weights of the scoring dimensions refer to the proportion of each scoring factor (such as load, response, etc.) in the total score, and these weight values can be dynamically adjusted by the scheduling node based on task priority. Specifically, the scheduling node queries or dynamically calculates a set of weight vectors from a policy configuration table based on task priority. For example, for subtasks with a priority of "urgent," the scheduling node will adopt a weight scheme that emphasizes response speed and low load, such as increasing the weights of response timeliness and load status. For subtasks with a priority of "normal," the scheduling node will adopt a weight scheme that emphasizes resource utilization, such as increasing the weights of resource matching and load balancing. For subtasks with a priority of "low-priority," the scheduling node may prioritize communication cost to save system bandwidth.
[0053] In practice, the formula for calculating the overall score is as follows: In the formula, Score(a,t) represents the comprehensive score of candidate level 3 agent a for subtask t, with a higher score indicating a better suitability for executing the subtask; La represents the load state of candidate level 3 agent a, normalized to [0,1], with a smaller value indicating a lower load (higher idle time). Therefore, 1-La is the positive load score; R a,t M represents the response time (e.g., expected response time) of candidate level 3 agent a relative to subtask t; a smaller value indicates a faster response. a,tThe resource matching degree of candidate level 3 agent a for subtask t has been normalized to [0,1][0,1], with a larger value indicating a higher degree of resource matching; C a,t For candidate level 3 agent a, the lower the cross-domain communication cost (such as network latency, bandwidth consumption, etc.) for subtask t, the better; w load w resp w match w cost For the weights of the scoring dimensions, satisfying w load +w resp +w match +w cost =1.
[0054] This invention employs a scheduling node to dynamically adjust scoring weights based on the urgency of subtasks: urgent tasks prioritize low-load, high-time-efficiency agents to ensure the real-time performance of critical business operations; ordinary tasks focus on resource matching and load balancing to improve overall system utilization; and low-priority tasks prioritize communication costs to save cross-domain bandwidth. This achieves a differentiated agent scheduling strategy, optimizing resource allocation and communication overhead while meeting task timeliness requirements, thereby improving the execution efficiency and robustness of the distributed agent system.
[0055] Figure 4 This is the third flowchart of the multi-agent cooperative task processing method provided by the present invention, as shown in Figure 4. After step 104, steps 105 to 107 are also included: Step 105: Receive the execution status feedback from the target level 3 agent; It should be noted that the execution status refers to various information returned by the Level 3 agent during or after the execution of a subtask, including execution progress, intermediate results, completion flags, error codes, and execution time. Feedback can be provided in two ways: periodically pushing incremental status updates during execution, and returning complete results upon completion.
[0056] Understandably, after receiving the execution status feedback from the target level 3 agent, the scheduling node (i.e., the first-level agent) updates the task status (pending execution / in execution / completed / abnormal) in real time and synchronously writes it to the asynchronous task status table in MySQL, generating a TraceId to achieve end-to-end tracing. It can also scan the task status table in real time through the global scheduling platform to trigger alarms for timed-out and abnormal tasks; and it supports exposing status interfaces to external systems via API gateways and monitoring platforms for real-time querying by business systems.
[0057] Step 106: When an execution exception is detected in a subtask based on the execution status, the exception type is determined based on the execution status, wherein the exception type includes at least one of node exception, task execution exception, distribution exception, and cross-domain collaboration exception. It should be noted that the anomaly type is a fault category determined by the scheduling node based on the received execution status or its own monitoring data. Node anomaly refers to a fault in the Level 3 agent itself, such as lost heartbeat, resource overload, or network unreachability. Task execution anomaly refers to logical failure, timeout, or output verification failure during subtask execution. Distribution anomaly refers to failure to receive confirmation of receipt or multiple failed retries when a task is distributed. Cross-domain collaboration anomaly refers to timeouts, permission verification failures, or data verification failures during cross-domain communication.
[0058] Step 107: Execute the corresponding rescheduling strategy according to the anomaly type, and migrate the subtask to the new target Level 3 agent.
[0059] It should be noted that the rescheduling strategy refers to the recovery measures taken for different types of anomalies. For example, selecting a replacement node and migrating the context for a node failure, selecting a faster node and adjusting parameters for execution timeouts, retrying or switching nodes for distribution anomalies, and handling cross-domain collaborative anomalies in a tiered manner. The new target level 3 agent is another level 3 agent selected according to the rescheduling strategy to take over the execution of subtasks from the original failed node.
[0060] This invention, through receiving execution status feedback from a three-level intelligent agent, monitors subtask anomalies in real time and automatically identifies the anomaly type. For node anomalies, task execution anomalies, distribution anomalies, or cross-domain collaboration anomalies, corresponding rescheduling strategies are executed, migrating failed subtasks to a new target three-level intelligent agent. This method solves the problem of the lack of unified state tracking and anomaly handling capabilities in existing technologies, achieving automatic recovery from task execution anomalies and significantly improving system reliability and task completion rate.
[0061] Based on any of the above embodiments, the step of executing the corresponding rescheduling strategy according to the exception type and migrating the subtask to the new target level 3 agent includes: When the anomaly type is node anomaly, the target Level 3 agent executing the subtask is identified as an abnormal node; Obtain other Level 3 agents, excluding the abnormal node, as candidate nodes from the local domain registry center; Based on the target scores of each candidate node, a new target level 3 agent is determined from the candidate nodes, and the subtask is transferred to the new target level 3 agent.
[0062] It should be noted that an abnormal node refers to a node in the original target Level 3 agent that has failed and is unable to continue executing the subtask. The criteria for determining an abnormal node include: the registry center not receiving a heartbeat from the node for 15 consecutive seconds, the node's CPU usage exceeding 90% for 5 minutes, memory usage exceeding 85%, or network packet loss exceeding 5%. The scheduling node sends a query request to the local registry center, requesting the return of all online Level 3 agents except for the abnormal node ID. Query conditions also include: the agent's online status is active, and its AgentCard's capability tags at least include the capability tags required for the subtask. The local registry center returns a list of agents that meet the conditions, and the scheduling node uses these agents as candidate nodes.
[0063] In the specific implementation, the scheduling node calculates a target score for each candidate node: Target Score = ((10 - Load Rate) / 100) × 40 + (Number of Matching Capability Tags / Total Number of Tags Required for the Task) × 60, where the load rate is the current load percentage of the candidate node (e.g., CPU utilization; if greater than 10, this item is 0), the number of matching capability tags is the number of capability tags in the candidate node's AgentCard that match the capability tags required for the subtask, and 40 and 60 are the fixed weights for load balancing and capability matching, respectively. Finally, the scheduling node selects the candidate node with the highest target score as the new target level 3 agent and migrates the subtask to that node; if there is no suitable node in the local domain, it can be extended to cross-domain nodes, with additional filtering conditions such as communication latency (preferably <500ms), cross-domain permission level, and data compliance, and then the target score is calculated using the same formula.
[0064] Understandably, the new target level 3 agent is the optimal replacement node selected based on the target score. Subtask migration refers to packaging the current execution state of the atomic task (including completed progress, intermediate output data, and unexecuted steps) and passing it to the new node, enabling it to continue execution from the breakpoint. Specifically, the scheduling node sorts the candidate node list from highest to lowest target score and selects the node with the highest target score as the new target level 3 agent. Then, the scheduling node obtains the current execution progress and intermediate data of the subtask from the last status report of the abnormal node and encapsulates this information into a task context. The scheduling node sends the subtask context and the original task parameters to the new target level 3 agent via the A2A protocol, requesting it to continue execution from the breakpoint. After the new node returns a confirmation of receipt, the scheduling node updates the subtask allocation record and marks the original abnormal node as isolated.
[0065] In this embodiment of the invention, when a node malfunctions, the faulty node is removed, and the optimal replacement node is selected from the remaining healthy nodes in the domain based on the target score. The subtask context is then migrated to the new node for continued execution. This method achieves rapid detection and automatic transfer of node faults, avoiding task interruption or re-execution, effectively reducing the impact of node malfunctions on business operations, and improving system high availability and task recovery efficiency.
[0066] Based on any of the above embodiments, the step of executing the corresponding rescheduling strategy according to the exception type and migrating the subtask to the new target level 3 agent includes: When the exception type is a task execution exception, the target level 3 agent executing the subtask is identified as a fault node; The third-level agents with a load rate lower than the faulty node are obtained from the local domain registry as candidate nodes. Based on the target scores of each candidate node, a new target level 3 agent is determined from the candidate nodes, and the subtask is transferred to the new target level 3 agent.
[0067] It should be noted that a failure node refers to a logical error, timeout, or output verification failure that occurred during the execution of a subtask by the original target Level 3 agent. Triggering conditions for task execution anomalies include: the Level 3 agent returning execution failure (error code non-zero), task execution time exceeding 1.5 times the estimated time limit, and output data format or integrity verification failing. The purpose of this step is to identify the specific node that failed, so as to select a better alternative node in the subsequent process.
[0068] Understandably, load rate refers to the current busy level of a Level 3 agent, typically measured by CPU utilization, memory utilization, or task queue length. The scheduling node retrieves the current load rate of the failed node (if the failed node is still communicable) or its last reported load rate from the registry. Then, the scheduling node queries its local registry for all online and capable Level 3 agents, requiring their current load rates to be strictly lower than the failed node's load rate. This ensures that new nodes have more resource slack to process tasks than existing nodes.
[0069] In practical implementation, the target score can be calculated based on load status, response time, and resource matching degree. Considering that task execution anomalies often stem from execution timeouts, the scheduling node can dynamically adjust the execution parameters of subtasks according to the resource specifications (such as CPU cores, memory size, etc.) of the new target Level 3 agent when migrating tasks. For example, it can appropriately extend the timeout threshold to avoid timeouts due to tight deadlines, or appropriately reduce the task concurrency to match the processing capacity of the new node, thereby effectively improving the success rate of rescheduling. Subsequently, the scheduling node selects the Level 3 agent with the highest target score from the candidate nodes as the new target Level 3 agent, and migrates the current execution context of the atomic task (including completed progress, intermediate data, and remaining work) and the adjusted execution parameters to the new node, triggering continued execution. If the new node successfully completes the task, the entire rescheduling process ends; if it still fails, it can continue to trigger the next round of rescheduling or mark it as a final failure according to the configuration. The above mechanism not only avoids rescheduling tasks to equally busy nodes, but also reduces secondary timeouts caused by resource mismatches through parameter adaptation, thereby significantly improving the recovery success rate and system robustness in abnormal task execution scenarios.
[0070] In this embodiment of the invention, when a task execution fails, the original target node is designated as the faulty node, candidate nodes with lower load rates are selected, and the optimal replacement node is chosen based on the target score, allowing the task to be migrated for execution. This method effectively avoids execution timeouts or failures caused by excessive node load, schedules tasks to nodes with more abundant resources, thereby improving the success rate of task rescheduling, preventing the same cause from causing failures again, and enhancing system execution stability.
[0071] Based on any of the above embodiments, the step of executing the corresponding rescheduling strategy according to the exception type and migrating the subtask to the new target level 3 agent includes: When the exception type is a distribution exception, the target third-level agent that failed to receive the subtask is identified as a failed node. Retry the failed node and record the number of retries; If the retry is successful, the rescheduling process ends. If the retry fails and the current number of retries has not reached the preset threshold, then continue to retries the failed node; If the retry fails and the current number of retries has reached the preset threshold, then other Level 3 agents besides the failed node are obtained from the local registry center as candidate nodes. Based on the target scores of each candidate node, a new target level 3 agent is determined, and the subtasks are distributed to the new target level 3 agent.
[0072] It should be noted that distribution anomaly refers to the failure to receive acceptance confirmation from the target Level 3 agent within the specified time after the subtask is issued. This includes the following triggering conditions: no confirmation within 3 seconds of task issuance, zero candidate agents, and A2A communication handshake failure. A failure node refers to an agent that cannot normally receive or confirm the task.
[0073] Understandably, a retry refers to attempting to distribute the subtask to the same failed node again, as the distribution failure might be due to temporary network jitter or momentary node congestion. Recording the number of retries is to avoid infinite retries. Specifically, the scheduling node sets a retry counter, initially set to 0. For the same failed node with the same subtask, the scheduling node will retry a maximum of a preset threshold (e.g., 3 times). Before each retry, the scheduling node increments the counter by 1, then sends the task distribution request to the failed node again via the A2A protocol, and restarts the 3-second acknowledgment timer. If an acknowledgment is received during a retry, the distribution is successful, and the rescheduling process ends; if the maximum number of retries is reached and the task still fails, other Level 3 agents are obtained from the local registry as candidate nodes.
[0074] In the specific implementation, after the scheduling node obtains the candidate node list from the local domain registry, it obtains the current load status, historical response time, resource matching degree with the subtask requirements, and whether it is cross-domain (if it is cross-domain, communication cost also needs to be considered) for each candidate Level 3 agent. It performs normalized scoring on these four dimensions respectively, and then sums them according to preset weights (e.g., load status weight 30%, response time weight 25%, resource matching degree weight 25%, cross-domain communication cost weight 20%) to obtain the target score of each candidate node, and selects a new target Level 3 agent based on the target score.
[0075] In this embodiment of the invention, when a distribution anomaly occurs, the failed node is retried a limited number of times, and the number of retries is recorded. If successful, the node is restored; otherwise, it is switched to another candidate node only after a failure occurs and a threshold is reached. This method avoids the resource waste caused by immediately switching nodes due to temporary network jitter. By selecting the optimal replacement node through scoring, it effectively balances the retry overhead and switching cost, significantly improving the success rate of task distribution and the robustness of the system.
[0076] Based on any of the above embodiments, the step of executing the corresponding rescheduling strategy according to the exception type includes: When the anomaly type is a cross-domain collaboration anomaly, the target level 3 agent executing the subtask is identified as an abnormal cross-domain node, and the severity of the anomaly of the abnormal cross-domain node is determined. If the severity of the anomaly is mild, the abnormal cross-domain node will be retried. If the retry is successful, the abnormal cross-domain node will continue to be used as the new target Level 3 agent. If the retry fails, a new target Level 3 agent will be selected from the local domain registry. If the severity of the anomaly is moderate, then a new target Level 3 agent is selected from other Level 3 agents in the same region; If the severity of the anomaly is classified as severe, a new target Level 3 agent is selected from the local domain registry center, and a cross-domain operation and maintenance alarm is triggered.
[0077] It should be noted that an abnormal cross-domain node refers to a target Level 3 agent currently executing a subtask, located in another business domain, whose task execution is abnormal due to cross-domain communication problems. Cross-domain collaboration anomalies refer to failures in cross-domain communication between the scheduling node and the target agent, including communication timeouts, permission verification failures, and data transmission verification failures. The severity of the anomaly is an assessment and classification of the impact range of the cross-domain anomaly, categorized into mild anomalies (e.g., temporary communication delays, momentary insufficient permissions), moderate anomalies (e.g., node overload, data verification failures), and severe anomalies (e.g., network interruption, certificate expiration). Specifically, the scheduling node can preset classification rules: if the anomaly is an occasional timeout or temporary permission expiration, it is classified as a mild anomaly; if the anomaly is a continuous node overload or multiple data verification failures, it is classified as a moderate anomaly; if the anomaly is a complete network disconnection or permanent certificate expiration, it is classified as a severe anomaly.
[0078] Understandably, for minor anomalies, the original cross-domain path should be restored first, and a switch to a local domain node should only be attempted after multiple failed retries to avoid unnecessary cross-domain switching overhead. For moderate anomalies (i.e., when the original cross-domain node cannot be used but cross-domain execution needs to be retained), a switch can be made to another healthy cross-domain node (i.e., a level 3 agent) within the same region to reduce communication latency and cross-domain costs, while avoiding resource waste caused by directly reverting to the local domain. For severe anomalies (i.e., when there is a serious failure in the cross-domain network or permissions), the task can be quickly rolled back to the local domain for execution to avoid prolonged task suspension, while simultaneously notifying operations and maintenance personnel to intervene and repair the cross-domain link.
[0079] In the event of cross-domain collaboration anomalies, this invention employs a tiered approach based on the severity of the anomaly: minor anomalies prioritize retrying the original node to avoid unnecessary handovers; moderate anomalies switch to other cross-domain nodes within the same region to reduce communication costs; and severe anomalies directly revert to the local domain and trigger an alarm to ensure rapid task recovery. This tiered strategy, while maintaining task continuity, reduces unnecessary cross-domain resource waste and handover overhead, enhancing the system's robustness and self-healing capabilities in cross-domain anomaly scenarios.
[0080] The multi-agent cooperative task processing device provided by the present invention is described below. The multi-agent cooperative task processing device described below can be referred to in correspondence with the multi-agent cooperative task processing method described above. For example Figure 5 As shown, the multi-agent collaborative task processing device includes: Receiver module 10 is used to receive the target task; The parsing module 20 is used to parse the target task and generate a task plan graph; The acquisition module 30 is used to acquire candidate third-level agents from the local domain registry center based on the task plan graph, or to acquire candidate third-level agents from other domains through cross-domain communication; The determination module 40 is used to determine the target level three agent for each subtask in the task plan graph from the candidate level three agents based on the comprehensive score of the candidate level three agents, and to send each subtask to the corresponding target level three agent so as to execute the corresponding subtask based on the target level three agent.
[0081] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include a processor 610, a communications interface 620, a memory 630, and a communication bus 640, wherein the processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The processor 610 can call logical instructions in the memory 630 to execute a multi-agent cooperative task processing method. This method includes: receiving a target task; parsing the target task to generate a task plan graph; based on the task plan graph, obtaining candidate third-level agents from the local domain registry center, or obtaining candidate third-level agents from other domains through cross-domain communication; based on the comprehensive scores of the candidate third-level agents, determining the target third-level agents for each subtask in the task plan graph from the candidate third-level agents, and distributing each subtask to the corresponding target third-level agent to execute the corresponding subtask based on the target third-level agent.
[0082] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0083] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the multi-agent cooperative task processing method provided by the above methods. The method includes: receiving a target task; parsing the target task to generate a task plan graph; obtaining candidate third-level agents from a local domain registry center based on the task plan graph, or obtaining candidate third-level agents from other domains through cross-domain communication; determining the target third-level agents for each sub-task in the task plan graph from the candidate third-level agents based on their comprehensive scores, and distributing each sub-task to the corresponding target third-level agent to execute the corresponding sub-task based on the target third-level agent.
[0084] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the multi-agent cooperative task processing method provided by the above methods. The method includes: receiving a target task; parsing the target task to generate a task plan graph; obtaining candidate third-level agents from a local domain registry center based on the task plan graph, or obtaining candidate third-level agents from other domains through cross-domain communication; determining the target third-level agents for each sub-task in the task plan graph from the candidate third-level agents based on their comprehensive scores, and distributing each sub-task to the corresponding target third-level agent to execute the corresponding sub-task based on the target third-level agent.
[0085] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown 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 this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; 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; and these 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 for multi-agent cooperative task processing, characterized in that, Applied to scheduling nodes, including: Receive the target task; The target task is analyzed to generate a task plan graph; Based on the task plan graph, candidate third-level agents are obtained from the local domain registry center, or candidate third-level agents from other domains are obtained through cross-domain communication; Based on the comprehensive scores of the candidate Level 3 agents, the target Level 3 agents for each subtask in the task planning graph are determined from the candidate Level 3 agents, and each subtask is sent to the corresponding target Level 3 agent so that the corresponding subtask can be executed based on the target Level 3 agent.
2. The multi-agent cooperative task processing method according to claim 1, characterized in that, The step of obtaining candidate Level 3 agents from the local domain registry center based on the task plan graph, or obtaining candidate Level 3 agents from other domains through cross-domain communication, includes: Determine the capability tags and resource specifications required for each subtask in the task planning map; Select Level 3 agents that meet the capability tags and resource specifications and are online from the local domain registry center, and add them to the candidate Level 3 agents of the local domain. Determine whether the number of candidate level 3 agents in this domain meets the task distribution requirements; If the conditions are not met, then request the global scheduling platform or the first-level agents of other domains to obtain candidate third-level agents from other domains, and add the candidate third-level agents from other domains to the candidate list; All Level 3 agents in the candidate list are selected as candidate Level 3 agents.
3. The multi-agent cooperative task processing method according to claim 1, characterized in that, The step of determining the target Level 3 agent for each subtask in the task planning graph based on the comprehensive scores of the candidate Level 3 agents includes: Obtain the load status, response time, resource matching degree, and cross-domain communication cost of each candidate Level 3 agent; Based on the load status, response time, resource matching degree, and cross-domain communication cost, calculate the comprehensive score of each candidate Level 3 agent for each sub-task; Based on the comprehensive score, the target Level 3 agent for each subtask in the task planning graph is determined from the candidate Level 3 agents.
4. The multi-agent cooperative task processing method according to claim 3, characterized in that, The comprehensive score for each candidate Level 3 agent for each sub-task is calculated based on the load status, response time, resource matching degree, and cross-domain communication cost, including: Determine the task priority of each subtask in the task planning graph; Based on the task priorities, determine the weights of the scoring dimensions; Based on the weights of the scoring dimensions, the load status, the response time, the resource matching degree, and the cross-domain communication cost, calculate the comprehensive score of each candidate Level 3 agent for each sub-task.
5. The multi-agent cooperative task processing method according to claim 1, characterized in that, Also includes: Receive the execution status feedback from the target level 3 intelligent agent; When an execution exception is detected in a subtask based on the execution status, the exception type is determined based on the execution status, wherein the exception type includes at least one of node exception, task execution exception, distribution exception, and cross-domain collaboration exception. The corresponding rescheduling strategy is executed according to the anomaly type, and the subtask is migrated to the new target Level 3 agent.
6. The multi-agent cooperative task processing method according to claim 5, characterized in that, The step of executing the corresponding rescheduling strategy based on the anomaly type and migrating the subtask to the new target level 3 agent includes: When the anomaly type is node anomaly, the target Level 3 agent executing the subtask is identified as an abnormal node; Obtain other Level 3 agents, excluding the abnormal node, as candidate nodes from the local domain registry center; Based on the target scores of each candidate node, a new target level 3 agent is determined from the candidate nodes, and the subtask is transferred to the new target level 3 agent.
7. The multi-agent cooperative task processing method according to claim 5, characterized in that, The step of executing the corresponding rescheduling strategy based on the anomaly type and migrating the subtask to the new target level 3 agent includes: When the exception type is a task execution exception, the target level 3 agent executing the subtask is identified as a fault node; The third-level agents with a load rate lower than the faulty node are obtained from the local domain registry as candidate nodes. Based on the target scores of each candidate node, a new target level 3 agent is determined from the candidate nodes, and the subtask is transferred to the new target level 3 agent.
8. The multi-agent cooperative task processing method according to claim 5, characterized in that, The step of executing the corresponding rescheduling strategy based on the anomaly type and migrating the subtask to the new target level 3 agent includes: When the exception type is a distribution exception, the target third-level agent that failed to receive the subtask is identified as a failed node. Retry the failed node and record the number of retries; If the retry is successful, the rescheduling process ends. If the retry fails and the current number of retries has not reached the preset threshold, then continue to retries the failed node; If the retry fails and the current number of retries has reached the preset threshold, then other Level 3 agents besides the failed node are obtained from the local registry center as candidate nodes. Based on the target scores of each candidate node, a new target level 3 agent is determined, and the subtasks are distributed to the new target level 3 agent.
9. The multi-agent cooperative task processing method according to claim 5, characterized in that, The step of executing the corresponding rescheduling strategy based on the exception type includes: When the anomaly type is a cross-domain collaboration anomaly, the target level 3 agent executing the subtask is identified as an abnormal cross-domain node, and the severity of the anomaly of the abnormal cross-domain node is determined. If the severity of the anomaly is mild, the abnormal cross-domain node will be retried. If the retry is successful, the abnormal cross-domain node will continue to be used as the new target Level 3 agent. If the retry fails, a new target Level 3 agent will be selected from the local domain registry. If the severity of the anomaly is moderate, then a new target Level 3 agent is selected from other Level 3 agents in the same region; If the severity of the anomaly is classified as severe, a new target Level 3 agent is selected from the local domain registry center, and a cross-domain operation and maintenance alarm is triggered.
10. A multi-agent collaborative task processing device, characterized in that, include: The receiving module is used to receive the target task; The parsing module is used to parse the target task and generate a task plan graph; The acquisition module is used to acquire candidate third-level agents from the local domain registry center based on the task plan graph, or to acquire candidate third-level agents from other domains through cross-domain communication; The determination module is used to determine the target level three agent for each subtask in the task plan graph from the candidate level three agents based on the comprehensive score of the candidate level three agents, and to issue each subtask to the corresponding target level three agent so as to execute the corresponding subtask based on the target level three agent.
11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the cross-domain multi-agent cooperative task processing method as described in any one of claims 1 to 9.
12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the cross-domain multi-agent cooperative task processing method as described in any one of claims 1 to 9.
13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the cross-domain multi-agent cooperative task processing method as described in any one of claims 1 to 9.