Multi-agent task generation and global planning method and device

Abstract

The application belongs to the technical field of intelligent control, and provides a multi-agent task generation and global planning method and device. The method comprises the following steps: receiving a user intention or an environment feedback, and constructing a standardized task request; performing identity checking, permission verification on the task request, and analyzing the task intention to determine the executability; decomposing a single natural language task in the task request into multiple sub-tasks, and constructing a dependency graph between the sub-tasks; monitoring the execution states of the multiple sub-tasks in real time, and performing corresponding operations when an abnormal execution or failure of a sub-task is monitored until all the sub-tasks are completed. The edge side first performs rapid local processing on recoverable abnormalities such as device faults, thereby avoiding unnecessary cloud-side communication overhead; only when an unrecoverable failure such as semantic mismatch or capability loss which cannot be solved by the edge side occurs, the cloud-side deep re-planning is triggered, and the self-adaptability and robustness can be improved.

Description

Technical Field

[0001] This application belongs to the field of intelligent control technology, and specifically relates to a method and apparatus for multi-agent task generation and global planning. Background Technology

[0002] With the rapid development of various intelligent agents such as drones and mobile robots, their deployment in complex environments such as disaster relief, real-time security, intelligent inspection, and emergency support is becoming increasingly widespread, serving as an important tool for improving operational efficiency and expanding the boundaries of human activities. The core requirement of multi-agent systems is to achieve efficient decomposition, collaborative execution, and dynamic adaptation of complex tasks. While traditional centralized control systems and single-point inference methods played a significant role in early, simple scenarios, they have gradually revealed undeniable technical bottlenecks as application environments become more complex and task requirements more diversified.

[0003] The technical shortcomings of existing multi-agent systems are mainly reflected in the following four aspects: Most current multi-agent systems rely on predefined command sets or fixed scripts, lacking the ability to directly parse natural language instructions and accurately understand users' unstructured task descriptions. At the same time, they lack the ability to decompose and logically organize complex task sequences, making it difficult for the system to cope with sudden tasks or dynamically changing task requirements in open environments, which greatly limits the expansion of its application scenarios.

[0004] While edge nodes (such as local controllers of terminal intelligent agents) have the advantages of being close to the task site and having low response latency, they are limited by hardware size, power consumption, and other constraints, resulting in limited local computing power and storage resources. This makes it difficult for them to independently handle heavy computational loads such as structured task parsing and complex strategy generation. Consequently, task planning often adopts a static and fixed model, lacking the intelligence to dynamically optimize based on the site environment, and failing to adapt to the task execution requirements of complex scenarios.

[0005] While cloud-based platforms possess powerful computing capabilities, enabling them to perform global analysis and planning for complex tasks, network transmission latency exists in communication between the cloud and edge / device-side intelligent agents. In scenarios with extremely high timeliness requirements, such as disaster relief and real-time security, excessive response delays can lead to task execution lags, severely impacting the system's effectiveness and robustness, and even posing security risks.

[0006] Existing systems generally adopt a one-way control mode of "one-time instruction issuance - terminal execution," without establishing an effective task execution status feedback and dynamic adjustment mechanism. When abnormal situations such as task failure, agent disconnection, or insufficient resources occur during execution, the system cannot detect them in time and replan or repair the strategy, resulting in task execution interruption or poor performance, and the system's adaptability and robustness are poor.

[0007] In summary, traditional centralized control systems and single-point reasoning methods can no longer meet the task execution requirements of multi-agent systems in complex environments, demanding "high understanding, high real-time performance, high adaptability, and high robustness." There is an urgent need to develop a multi-agent collaborative task processing system capable of natural language task parsing, cloud-edge computing power collaboration, real-time response to emergencies, and dynamic adaptive adjustment. This system is of significant practical importance and application value for overcoming existing technological bottlenecks, expanding the application boundaries of multi-agent systems, and improving operational efficiency and reliability in complex scenarios. Summary of the Invention

[0008] To address the aforementioned problems, this application provides a multi-agent task generation and global planning method, the method comprising: Receive user intent or environmental feedback, and construct standardized task requests; Perform identity verification and permission verification on task requests, and parse the task intent to determine its executability; The single natural language task in the task request is broken down into multiple sub-tasks, and a dependency graph between the sub-tasks is constructed. It monitors the execution status of multiple subtasks in real time. When an abnormality or failure is detected in the execution of a subtask, it performs the corresponding operation until all subtasks are completed.

[0009] Furthermore, by receiving user intent or environmental feedback, standardized task requests are constructed, including: Receive raw data from the user's human-computer interaction interface or edge sensors; The natural language understanding module parses the semantic information in the raw data, and the context fusion module integrates the environmental state information to extract the task objective and the current environmental state. Based on the extracted task objectives and environmental conditions, a structured task request is generated.

[0010] Furthermore, the task request undergoes identity verification and permission validation, and the task intent is parsed to determine its executability, including: Parse the identity credential field in the task request to complete user identity verification; Based on the preset access control policy, verify the resource access permissions of the task request; Perform semantic understanding on the task description field in the task request to parse its task intent; The parsed task intent is matched with the system's predefined set of executable capabilities to determine the task's executability. If a match fails, the task request is deemed unexecutable, and a rejection response is returned to the edge.

[0011] Furthermore, the single natural language task in the task request is decomposed into multiple subtasks, and a dependency graph between the subtasks is constructed, including: Define multiple subtask nodes, each containing unique identifier information and executable capability type information; Based on the logical relationships between subtasks, construct a task dependency graph that represents their execution order or concurrency relationship; The defined subtask nodes and their dependencies are encapsulated into a structured data format; The encapsulated structured data is distributed to each side computing node.

[0012] Furthermore, based on the logical relationships between subtasks, a task dependency graph representing their execution order or concurrency relationship is constructed, including: If it is determined that two subtasks can be executed in parallel, then no dependency edge is established between the two subtask nodes in the dependency graph. If it is determined that two subtasks need to be executed sequentially, then a directed edge is created in the dependency graph from the previous subtask node to the next subtask node.

[0013] Furthermore, the defined subtask nodes and dependency information are encapsulated into a structured data format, including: Encapsulate the dependency graph into a data structure that includes a list of nodes and a list of edges; The node list is used to record the attribute information of all subtask nodes; The edge list is used to record the dependencies between subtask nodes.

[0014] Furthermore, the attribute information in the node list includes at least the unique identifier of the subtask node and its corresponding tool attribute; the dependency relationship in the edge list includes at least the start identifier and the end identifier.

[0015] Furthermore, the distribution of the encapsulated structured data to each edge computing node is accomplished through a preset communication protocol.

[0016] Furthermore, the execution status of multiple subtasks is monitored in real time. When an abnormality or failure is detected in the execution of a subtask, corresponding operations are performed, including: Local fault tolerance recovery is performed on the edge side; if local fault tolerance recovery fails, the cloud-side replanning mechanism is triggered to replan the relevant subtasks based on the execution feedback results.

[0017] Furthermore, local fault tolerance recovery is performed on the edge side; if local fault tolerance recovery fails, a cloud-side replanning mechanism is triggered to replan the relevant subtasks based on the execution feedback results, including hierarchical processing steps: Level 1 processing: When an abnormality is detected in the execution of a subtask, local fault tolerance recovery is first performed on the edge side; Second-level processing: If local fault tolerance recovery fails, the edge side will trigger a cloud side replanning request; Third-level processing: After receiving the replanning request, the cloud side performs partial reconstruction based on the context information of the failed task and generates an alternative execution plan.

[0018] Furthermore, local fault-tolerant recovery is performed on the edge, including: When a subtask fails, the side performs a recoverability assessment of the failure. If the assessment indicates that the task is recoverable, a local recovery mechanism is triggered. This mechanism involves selecting an available, equivalent execution device within the edge and reassigning and executing the failed subtask.

[0019] Furthermore, the recoverability assessment is based on the determination of the failure cause type; when the failure cause type is determined to be a hardware or software failure of the execution device, the assessment result is recoverable.

[0020] Furthermore, the condition for triggering a cloud-side replanning request from the edge is that the edge evaluates the failed subtask and determines it to be an unrecoverable failure. The criteria for determining unrecoverable failure include at least one of the following: There are currently no available devices on the side that meet the subtask capability requirements; The requirements of the subtask exceed the capabilities of all available devices on the side. The subtask failed even after the local recovery mechanism was triggered on the side and the preset number of retries were attempted.

[0021] Furthermore, the cloud-side replanning request includes a structured error report, which includes task information for identifying failed subtasks, execution status information representing their unrecoverable state, and diagnostic information for assisting cloud-side replanning.

[0022] Furthermore, after receiving the replanning request, the cloud side performs a partial refactoring based on the context information of the failed task, including: The cloud side listens for and receives replanning requests triggered by the edge side, and obtains the context of failed subtasks; Based on the context, generate a sequence of alternative subtasks to replace the original failed subtasks and their associated tasks; Based on the sequence of alternative subtasks, update the structure of the local subgraphs related to failure in the original task dependency graph.

[0023] Furthermore, the strategy employed to update the local subgraph structure in the original task dependency graph includes at least one of the following: Reschedule and retry failed subtasks; Replace the failed subtask with a functionally equivalent alternative subtask; Skip failed subtasks and adjust subsequent dependency paths; Reconstruct the partial task execution path starting from the failed node based on the current context.

[0024] Furthermore, alternative subtask sequences are generated based on the context, including: Call the pre-trained language model to process the context, which includes at least the failure type, failure reason, and task environment information; Based on the output of the language model, generate a logically coherent sequence of new subtasks.

[0025] Furthermore, it also includes the logging step: Process data, including replanning requests, failure contexts, refactoring schemes, and execution results, will be persistently stored on the cloud as system execution logs. The system execution log is used for subsequent task planning strategy optimization and training of related analysis models.

[0026] This application also provides a multi-agent task generation and global planning apparatus, comprising: The building module is used to receive user intent or environmental feedback and build standardized task requests; The verification module is used to verify the identity and permissions of task requests, and to parse the task intent to determine its executability. The graph module is used to break down a single natural language task in a task request into multiple subtasks and construct a dependency graph between the subtasks. The planning module is used to monitor the execution status of multiple subtasks in real time. When an abnormality or failure is detected in the execution of a subtask, the corresponding operation is performed until all subtasks are completed.

[0027] Compared with the prior art, this application has the following advantages: By receiving user intent or environmental feedback, constructing standardized task requests, verifying identity and permissions, and parsing task intent to determine executability, the system directly parses user-input natural language commands or environmental feedback and transforms them into structured task requests with explicit semantics. This overcomes the limitation of traditional systems that can only handle predefined commands, greatly improving the system's ability to understand and process complex, ambiguous, or unexpected tasks in open environments.

[0028] A single natural language task in a task request is decomposed into multiple subtasks, and a dependency graph between these subtasks is constructed. The task planning process is abstracted as the process of constructing a task dependency graph. By defining subtask nodes and explicitly depicting their sequential or concurrent dependencies (such as directed edges), complex task logic can be expressed clearly and unambiguously. This graph-based representation not only enhances the interpretability of task planning but, more importantly, provides precise operational objects and structural foundations for subsequent global replanning, ensuring global consistency of the task flow during multi-agent collaborative execution.

[0029] The system monitors the execution status of multiple subtasks in real time and re-plans related subtasks based on the execution feedback until all subtasks are completed. The edge side first handles recoverable anomalies such as device failures locally, avoiding unnecessary cloud-side communication overhead. Only when encountering unrecoverable failures such as semantic mismatches or capability deficiencies that the edge side cannot resolve are deep re-planning triggered on the cloud side. Based on a complete task dependency graph and rich context, the cloud side performs semantic-level task chain reconstruction. This mechanism significantly improves the system's robustness and adaptability in dynamic and uncertain environments.

[0030] By placing computationally intensive tasks such as parsing, graph construction, and global replanning on the cloud side, while real-time-critical execution monitoring and rapid fault tolerance are handled on the edge side, optimized allocation of computing resources is achieved. This division of labor alleviates the computing power pressure on edge nodes, leverages the powerful computing capabilities of the cloud side to ensure planning quality, and reduces cloud-side load and communication latency through a layered fault tolerance mechanism, thereby improving the overall system response efficiency and resource utilization.

[0031] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application 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 application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 A schematic flowchart of a multi-agent task generation and global planning method according to an embodiment of this application is shown; Figure 2The diagram illustrates the edge-side and cloud-side workflows of the multi-agent task generation and global planning method according to embodiments of this application. Figure 3 A schematic diagram of cloud-side operation is shown in the multi-agent task generation and global planning method according to an embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] like Figure 1 As shown, this embodiment provides a multi-agent task generation and global planning method, including the following steps: Step S101: Receive user intent or environmental feedback and construct a standardized task request. This step is crucial for standardizing the task input interface. Its purpose is to construct a standardized task request format based on the user intent or environmental feedback received by the edge device, thus completing the task request to the cloud side. In other words, this step is executed on the edge. (See reference...) Figure 2 The specific implementation method is as follows: Edge devices receive raw data through their human-machine interface (such as a voice receiving module or a text input box) or edge sensors (such as a camera or force sensor). For example, a user may issue a voice command through a microphone, or an edge vision sensor may detect a device malfunction and generate an alarm message.

[0036] A lightweight Natural Language Understanding (NLU) module running on the edge device recognizes and transcribes voice commands, or performs preliminary parsing of text commands. Simultaneously, the Context Merger module integrates current device status (such as GPS location and battery level) and sensor data summaries. This process transforms raw signals into structured semantic information. The extracted information is then encapsulated into a standardized task request. This request is a structured data object whose core fields include: Token: User identity credential used for cloud-based authentication.

[0037] TaskTypeID: Task type identifier (such as "anomaly investigation"), which facilitates quick classification and processing on the cloud side.

[0038] NLTask: Original description of natural language tasks.

[0039] Timestamp: A timestamp used for request sorting and timeliness determination.

[0040] Context: Optional context information, including a summary of the current device status, such as whether a device is unavailable or other actual execution information. This structured request is ultimately transmitted to the cloud via an efficient communication protocol (such as gRPC). This step unifies heterogeneous input into a standardized format that the cloud can process, laying the foundation for subsequent processing.

[0041] Among them, constructing structured task requests:

[0042] Step S102 involves verifying the identity and permissions of the task request, and parsing the task intent to determine its executability. This step is completed on the cloud side, ensuring the security and executability of the task, and is a multi-layered verification process.

[0043] The cloud-side gateway first parses the Token field in the request and verifies the user's identity using standard authentication mechanisms such as OAuth 2.0 or JWT. Then, based on a pre-defined access control list (ACL), it checks whether the user has permission to execute the requested task and access related resources. For example, it checks whether the user has permission to enter a specific area. This achieves identity verification and permission validation.

[0044] like Figure 3 As shown, after successful authentication, the cloud side invokes the Large Language Model (LLM) to perform deep semantic understanding of the NLTask field in the request. The LLM parses out the core objective, key parameters, and constraints of the task to complete the task intent parsing.

[0045] The parsed task intent is matched against a predefined set of executable capabilities. This capability set abstractly describes the types of operations the system can perform (e.g., navigation, object detection, high-quality photography). If all operations in the task intent can be matched in the capability set, it is determined to be executable; otherwise, it is determined to be inexecutable, and a rejection response with a reason is returned to the edge. This step ensures, at the semantic level, that tasks planned on the cloud side are ultimately executed by devices on the edge side.

[0046] Step S103 involves breaking down the single natural language task in the task request into multiple subtasks and constructing a dependency graph between the subtasks. This step is the core of cloud-side planning, and its goal is to transform a macro-level task into an executable task dependency graph.

[0047] The cloud-based LLM executes a task decomposition function, breaking down the authorized macro-task into a series of discrete sets of sub-task nodes. Each subtask node is assigned a unique identifier (such as an ID) and executable capability type information (such as capability: photography). Specifically, the LLM receives... Then, execute the function. Each subtask node includes a number and an executable capability type (such as visual perception, navigation, photo upload, etc.), with the following parameter structure: args i (Parameters required to execute this subtask) may include location coordinates, mode selection, expected accuracy parameters, and motion amplitude, so that the side can further combine local resources to perform capability matching during local planning, thereby completing task decomposition and node definition.

[0048] Based on the logical relationships between subtasks, the cloud side uses the LangGraph framework to construct a task dependency graph. , where vertex set For all subtask nodes, Let E be the set of edges in the graph, representing dependencies, i.e., execution order or concurrency relationships. Dependencies are generated by built-in rules in the LangGraph module or through LLM (LangGraph Logic Manager). Dependencies are determined by the LLM or rule engine: if tasks can be performed in parallel (e.g., τ2 and τ3 can be performed simultaneously), no dependency edges are created; if tasks must be executed sequentially (e.g., τ1 must be completed before τ2), then directed edges from τ1 to τ2 are created. This process achieves explicit and visual modeling of task logic.

[0049] The generated task dependency graph is encapsulated into a structured data format for transmission. A typical encapsulation method is to use a JSON structure containing nodes and edges. The nodes list records the attributes of each subtask in detail (such as ID, tool type), and the edges list precisely describes the dependencies (such as from:τ1, to:τ2). After encapsulation, the planning results are distributed to each edge computing node through a preset communication protocol (such as the MCP protocol). It is worth noting that this graph only describes the logic of "what to do" and "what to do first and what to do later," without specifying "who does it," thus decoupling planning and execution and enhancing the system's flexibility. Specifically, each object in the node list represents a subtask, containing a unique identifier "id" and a corresponding tool attribute "tool"; each object in the edge list represents the dependency relationship between nodes, containing a starting identifier "from" and an ending identifier "to." For example, the output of task T1 (using the tool "take_picture") serves as the input of task T2 (using the tool "report"), and there is an edge between them pointing from T1 to T2, thus clearly describing the logical order and priority relationship between subtasks.

[0050] Step S104 involves real-time monitoring of the subtask execution status. When an abnormality or failure is detected in the subtask execution, corresponding operations are performed. This step is crucial for achieving closed-loop adaptation and improving system robustness. This step aims to provide real-time feedback of the edge execution status to the cloud side and trigger a local replanning mechanism on the cloud side in case of abnormalities, failures, or delays, ensuring the complete closed-loop execution of the task chain. When performing local fault tolerance recovery on the edge side, if the local fault tolerance recovery fails, the cloud-side replanning mechanism is triggered. Based on the execution feedback results, the relevant subtasks are replanned. This step involves a three-level hierarchical processing, as detailed below: Level 1 processing: When a subtask execution anomaly is detected, local fault tolerance recovery is first performed on the edge side. Specifically, the edge node monitors the execution status S_exec of its assigned subtasks in real time (e.g., start (task has started execution), progress (task is executing), fail (task execution failed), done (task has successfully completed), and continuously reports it. When a task failure is detected, the edge side first performs a recoverability assessment. For example, if the failure is due to a hardware or software fault in the executing device (e.g., a motor malfunction), it is assessed as recoverable. The edge side then triggers a local recovery mechanism, which selects a backup device with equivalent capabilities (e.g., another motor) within the edge side to reassign and execute the failed task. This process does not require reporting to the cloud side, achieving rapid fault recovery, and is ultimately determined to be recoverable.

[0051] Second-level processing: If the local fault tolerance recovery fails, the edge side triggers a cloud-side replanning request. Specifically, when the edge side assesses the failure as unrecoverable (e.g., the current task requires "temperature measurement" capability, but none of the edge devices have this capability; or multiple local retries fail), the edge side will trigger a cloud-side replanning request; this is the determination of an unrecoverable failure. The edge side will generate a structured error report, which includes the identification information of the failed task, detailed execution status information, and error information for auxiliary diagnosis, and send it to the cloud side via the communication protocol. This report provides key context for the cloud side's deep replanning. That is, when the edge side detects the following unrecoverable situations, such as the current task node having no alternative device to execute, the subtask itself having a semantic mismatch (e.g., the device does not have a certain capability), or multiple retries failing without results, the edge side will report an unrecoverable state, setting the execution task status as follows: At the same time, the error message will be displayed. The structure is uploaded to the cloud side, task id : A unique identifier for a failed task; timestamp: the time the failure occurred. It includes fault categories (such as action failure, sensor non-response, target loss, etc.) and brief diagnostic information, enabling the cloud side to understand the semantic reasons for the failure and providing a basis for the next step of graph reconstruction.

[0052] Level 3 Processing: After receiving the replanning request, the cloud-side performs local reconstruction based on the context information of the failed task, generating an alternative execution plan. The cloud-side continuously monitors requests from the edge side. Upon receiving a replanning request, the cloud-side obtains the complete failure context, including the structured error report. The cloud-side invokes LLM, combining the failure context to generate a new, alternative subtask sequence to replace the original failed subtask chain. Subsequently, the affected local subgraph structure in the original task dependency graph is updated according to the new sequence, with strategies including alternative execution, skipping, or path reconstruction. Key data throughout the replanning process (such as replanning requests, failure contexts, and reconstruction plans) is persistently stored as a system execution log on the cloud-side for subsequent analysis, strategy optimization, and model fine-tuning, enabling the system to continuously evolve. Specifically, the cloud-side continuously monitors the summary of task execution status from the edge side and maintains a real-time task status. Whenever a task is detected... If this occurs, local replanning is triggered, using LLM combined with edge feedback (error type, failure reason, context) to generate an alternative subtask sequence, and then applying this to the dependency graph related to the error. Graphs with direct edge relationships Implement local replanning strategies, including but not limited to retrying, alternative execution, skipping, and path reconstruction. The reconstructed subgraph. The task will be resent to the edge via the MCP protocol, overwriting the original task nodes and achieving uninterrupted repair execution of the task chain. In addition, the system writes all execution logs (including timestamps, task graph versions, edge node numbers, and failure reasons) to the cloud archive for future planning optimization and model fine-tuning.

[0053] This application also provides a multi-agent task generation and global planning apparatus, comprising: The building module is used to receive user intent or environmental feedback and build standardized task requests; The verification module is used to verify the identity and permissions of task requests, and to parse the task intent to determine its executability. The graph module is used to break down a single natural language task in a task request into multiple subtasks and construct a dependency graph between the subtasks. The planning module is used to monitor the execution status of the multiple subtasks in real time, and in response to subtask execution abnormalities or failures, trigger replanning operations hierarchically based on the execution feedback results until all subtasks are completed.

[0054] In summary, this application has the following advantages: User commands are processed via a natural language understanding module on the edge, while deep semantic parsing is performed using a large language model on the cloud. This enables the system to directly understand and process open and complex natural language tasks, and transform them into a well-structured, machine-executable task dependency graph.

[0055] This paper pioneers the use of task dependency graphs to explicitly model the sequential or concurrent relationships between subtasks. This graph-based representation (e.g., G_task = (V, E)) enables the clear and unambiguous expression of complex task logic, enhancing the interpretability of task planning and, more importantly, providing precise operational objects for subsequent global replanning, thus ensuring global consistency during multi-agent collaborative execution.

[0056] A layered processing framework of "edge-side local fault tolerance - cloud-side semantic reconstruction" was constructed. The edge side first handles recoverable anomalies such as device failures quickly; only when encountering semantic-level failures that the edge side cannot resolve, such as capability mismatch, is deep replanning triggered in the cloud. This mechanism achieves efficient closed-loop planning, significantly improving the system's adaptability and robustness in dynamic and uncertain environments, and preventing the entire task from being interrupted due to local failures.

[0057] Through an edge-cloud collaborative architecture, optimized allocation of computing resources is achieved. Computationally intensive tasks such as parsing, graph construction, and global replanning are performed on the cloud side, while real-time-critical execution monitoring and rapid fault tolerance are handled on the edge side. This division of labor leverages the powerful computing capabilities of the cloud to ensure planning quality while reducing cloud load and communication latency through rapid edge response, thus achieving low-latency, high-efficiency task processing overall.

[0058] Through a series of innovative designs including natural language-driven approaches, graph-based planning, hierarchical closed-loop fault tolerance, and edge-cloud collaboration, this system systematically addresses the core pain points of existing technologies in terms of task understanding, planning consistency, system robustness, and resource efficiency, providing an effective technical solution for realizing intelligent, reliable, and adaptive multi-agent collaborative systems.

[0059] Although this application 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 this application.

Claims

1. A multi-agent task generation and global planning method, characterized in that, The methods include: Receive user intent or environmental feedback, and construct standardized task requests; The task request is verified for identity and permissions, and the task intent is parsed to determine its executability. The single natural language task in the task request is decomposed into multiple sub-tasks, and a dependency graph between the sub-tasks is constructed. The execution status of the multiple subtasks is monitored in real time. When an abnormality or failure is detected in the execution of a subtask, the corresponding operation is performed until all subtasks are completed.

2. The multi-agent task generation and global planning method according to claim 1, characterized in that, The step of receiving user intent or environmental feedback and constructing a standardized task request includes: Receive raw data from the user's human-computer interaction interface or edge sensors; The semantic information in the raw data is parsed by the natural language understanding module, and the environmental state information is integrated by the context fusion module to extract the task objective and the current environmental state. Based on the extracted task objectives and environmental conditions, a structured task request is generated.

3. The multi-agent task generation and global planning method according to claim 1, characterized in that, The step of verifying the identity and permissions of the task request and parsing the task intent to determine its executability includes: Parse the identity credential field in the task request to complete user identity verification; Based on the preset access control policy, verify the resource access permissions of the task request; Semantic understanding is performed on the task description field in the task request to parse its task intent; The parsed task intent is matched with the system's predefined set of executable capabilities to determine the task's executability. If a match fails, the task request is deemed unexecutable, and a rejection response is returned to the side.

4. The multi-agent task generation and global planning method according to claim 1, characterized in that, The step of decomposing the single natural language task in the task request into multiple sub-tasks and constructing a dependency graph between the sub-tasks includes: Define multiple subtask nodes, each containing unique identifier information and executable capability type information; Based on the logical relationships between the subtasks, a task dependency graph representing their execution order or concurrency relationship is constructed; The defined subtask nodes and their dependencies are encapsulated into a structured data format; The encapsulated structured data is distributed to each side computing node.

5. The multi-agent task generation and global planning method according to claim 4, characterized in that, The construction of a task dependency graph representing the execution order or concurrency relationship based on the logical relationships between the subtasks includes: If it is determined that two subtasks can be executed in parallel, then no dependency edge is established between the two subtask nodes in the dependency graph. If it is determined that two subtasks need to be executed sequentially, then a directed edge is established in the dependency graph from the previous subtask node to the next subtask node.

6. The multi-agent task generation and global planning method according to claim 4, characterized in that, The process of encapsulating the defined subtask nodes and dependency information into a structured data format includes: The dependency graph is encapsulated into a data structure containing a list of nodes and a list of edges; The node list is used to record the attribute information of all subtask nodes; The edge list is used to record the dependencies between subtask nodes.

7. The multi-agent task generation and global planning method according to claim 6, characterized in that, The attribute information in the node list includes at least the unique identifier of the subtask node and its corresponding tool attribute; the dependency relationship in the edge list includes at least the start identifier and the end identifier.

8. The multi-agent task generation and global planning method according to claim 4, characterized in that, The distribution of the encapsulated structured data to each side computing node is accomplished through a preset communication protocol.

9. The multi-agent task generation and global planning method according to claim 1, characterized in that, The system monitors the execution status of the multiple sub-tasks in real time, and performs corresponding operations when an abnormality or failure is detected in the execution of a sub-task, including: Local fault tolerance recovery is performed on the edge side; if local fault tolerance recovery fails, the cloud-side replanning mechanism is triggered to replan the relevant subtasks based on the execution feedback results.

10. The multi-agent task generation and global planning method according to claim 9, characterized in that, The process involves performing local fault tolerance recovery on the edge side; if local fault tolerance recovery fails, a cloud-side replanning mechanism is triggered to replan the relevant subtasks based on the execution feedback results, including hierarchical processing steps: Level 1 processing: When a subtask execution error or failure is detected, local fault tolerance recovery is first performed on the edge side; Second-level processing: If the local fault tolerance recovery fails, the edge side will trigger a cloud-side replanning request; Third-level processing: After receiving the replanning request, the cloud side performs local reconstruction based on the context information of the failed task and generates an alternative execution plan.

11. The multi-agent task generation and global planning method according to claim 10, characterized in that, The step of performing local fault-tolerant recovery on the edge includes: When a subtask fails, the side performs a recoverability assessment of the failure. If the assessment indicates that the task is recoverable, a local recovery mechanism is triggered, which includes selecting an available execution device with equivalent capabilities within the side and reassigning and executing the failed subtask.

12. The multi-agent task generation and global planning method according to claim 11, characterized in that, The recoverability assessment is based on the determination of the failure cause type; when the failure cause type is determined to be a hardware or software failure of the execution device, the assessment result is recoverable.

13. The multi-agent task generation and global planning method according to claim 10, characterized in that, The condition for triggering a cloud-side replanning request from the edge side is that the edge side evaluates the failed subtask and determines it to be an unrecoverable failure. The criteria for determining unrecoverable failure include at least one of the following: There are currently no available devices on the side that meet the capability requirements of the subtask; The requirements of the sub-tasks exceed the capabilities of all available devices on the side. The subtask failed even after the local recovery mechanism was triggered locally on the side and a preset number of retries were attempted.

14. The multi-agent task generation and global planning method according to claim 13, characterized in that, The cloud-side replanning request includes a structured error report, which includes task information for identifying failed subtasks, execution status information for characterizing their unrecoverable state, and diagnostic information for assisting cloud-side replanning.

15. The multi-agent task generation and global planning method according to claim 10, characterized in that, After receiving the replanning request, the cloud side performs partial reconstruction based on the context information of the failed task, including: The cloud side listens for and receives the replanning request triggered by the edge side, and obtains the context of the failed subtask; Based on the aforementioned context, a sequence of alternative subtasks is generated to replace the original failed subtasks and their associated tasks. Based on the alternative subtask sequence, update the failure-related local subgraph structure in the original task dependency graph.

16. The multi-agent task generation and global planning method according to claim 15, characterized in that, The strategy employed to update the local subgraph structure in the original task dependency graph includes at least one of the following: Reschedule and retry failed subtasks; Replace the failed subtask with a functionally equivalent alternative subtask; Skip the failed subtasks and adjust subsequent dependency paths; Reconstruct the partial task execution path starting from the failed node based on the current context.

17. The multi-agent task generation and global planning method according to claim 15, characterized in that, The generation of alternative subtask sequences based on the context includes: The pre-trained language model is invoked to process the context, which includes at least the failure type, failure reason, and task environment information. Based on the output of the language model, a logically coherent sequence of new subtasks is generated.

18. The multi-agent task generation and global planning method according to claim 15, characterized in that, It also includes the logging process: The process data, including the replanning request, failure context, refactoring scheme and execution result, will be persistently stored on the cloud as system execution logs. The system execution log is used for subsequent task planning strategy optimization and training of related analysis models.

19. A multi-agent task generation and global planning device, characterized in that, include: The building module is used to receive user intent or environmental feedback and build standardized task requests; The verification module is used to verify the identity and permissions of the task request, and to parse the task intent to determine its executability. The graph module is used to decompose a single natural language task in the task request into multiple sub-tasks and construct a dependency graph between the sub-tasks. The planning module is used to monitor the execution status of the multiple subtasks in real time. When an abnormality or failure is detected in the execution of a subtask, the corresponding operation is performed until all subtasks are completed.

Images