Task execution method, device and equipment of multi-agent system

Abstract

The embodiment of the invention provides a task execution method, device and equipment of a multi-agent system. The scheme comprises: obtaining a target task; a plurality of agents are scheduled to execute the target task according to the first task scheduling graph, and an execution track is generated; based on the execution track, judging whether a preset cooperation abnormal mode appears or not; if the cooperation abnormal mode appears, the first task scheduling graph is reconstructed into a second task scheduling graph, and the reconstruction is used for eliminating the cooperation abnormal mode; and continuing to execute the target task based on the second task scheduling graph.

Description

Technical Field

[0001] This specification relates to the field of artificial intelligence technology, and particularly to a task execution method for a multi-agent system. This specification also relates to a task execution apparatus and a computing device. Background Technology

[0002] With the rapid development of artificial intelligence technology, multi-agent systems have been widely applied in many fields such as intelligent customer service, autonomous driving, software engineering, and scientific research due to their advantages in complex task decomposition, parallel processing, and collaborative problem-solving. In a multi-agent system, multiple agents with specific capabilities work together through a certain cooperation mechanism to complete a complex target task submitted by the user.

[0003] Currently, mainstream collaborative methods typically construct static task scheduling graphs based on pre-defined collaborative paradigms. During system runtime, each agent is scheduled to execute tasks according to this static scheduling graph, and execution trajectories are collected. However, the aforementioned methods based on static pre-defined scheduling graphs have revealed significant limitations in practice, especially when dealing with complex tasks in open and dynamic environments, where their robustness and adaptability are insufficient. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide a task execution method, apparatus, and device for a multi-agent system to solve the problems of insufficient robustness and adaptability of existing multi-agent systems when performing tasks.

[0005] According to a first aspect of one or more embodiments of this specification, a task execution method for a multi-agent system is provided, comprising: Obtain the target task; Multiple agents are scheduled to execute the target task according to the first task scheduling diagram, and an execution trajectory is generated; Based on the execution trajectory, determine whether a preset collaboration anomaly mode has occurred; If the aforementioned collaboration anomaly occurs, the first task scheduling graph is reconstructed into a second task scheduling graph; the reconstruction is used to eliminate the collaboration anomaly. Based on the second task scheduling graph, continue to execute the target task.

[0006] According to a second aspect of one or more embodiments of this specification, a task execution apparatus is provided, comprising: The task acquisition module is used to acquire target tasks; The task execution module is used to schedule multiple agents to execute the target task according to the first task scheduling graph and generate an execution trajectory; An anomaly detection module is used to determine whether a preset collaborative anomaly mode has occurred based on the execution trajectory. The scheduling graph reconstruction module is used to reconstruct the first task scheduling graph into a second task scheduling graph if the collaboration anomaly mode occurs; the reconstruction is used to eliminate the collaboration anomaly mode. The task execution module is used to continue executing the target task based on the second task scheduling graph.

[0007] According to a third aspect of one or more embodiments of this specification, a computing device is provided, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor executes the computer instructions to implement the steps of the task execution method.

[0008] One embodiment of this specification achieves at least the following beneficial effects: By introducing a collaborative anomaly dynamic detection and task scheduling graph adaptive reconstruction mechanism based on execution trajectory, the robustness and execution success rate of multi-agent systems in complex and uncertain task environments are significantly improved. Specifically, during the execution of the target task, the system continuously generates and analyzes the execution trajectory, compares it in real time with preset collaborative anomaly patterns, and triggers targeted reconstruction of the current task scheduling graph once an anomaly is detected, thereby eliminating the collaborative defects that cause the anomaly from a structural level. Since the reconstructed second task scheduling graph directly addresses the exposed problems and supports seamless resumption of execution from the interruption point, it avoids the resource waste and delay caused by retrying tasks from the beginning. This not only effectively blocks the propagation of anomalies but also realizes the online evolution and self-healing of scheduling strategies. Ultimately, while ensuring the task completion rate, it improves the system's adaptive capability, execution efficiency, and overall collaborative reliability. Attached Figure Description

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

[0010] Figure 1 This diagram illustrates an application scenario of a task execution method for a multi-agent system provided in the embodiments of this specification. Figure 2 A flowchart illustrating a task execution method for a multi-agent system provided in an embodiment of this specification; Figure 3 This is a schematic diagram of the structure of a multi-agent system provided in the embodiments of this specification; Figure 4The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a task execution device; Figure 5 A structural block diagram of a computing device provided according to an embodiment of this specification is shown. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0013] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0014] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0015] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0016] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0017] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0018] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0019] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0020] The following explains the terms and concepts used in one or more embodiments of this specification.

[0021] An intelligent agent is an entity that can perceive information in its environment, make autonomous decisions, and execute actions to achieve its goals. It is an AI "role" with specific capabilities, such as a "planner" or "executor."

[0022] Multi-agent systems (MAS) are distributed systems in which multiple agents interact and collaborate in a shared environment to solve complex tasks that are difficult for a single agent to handle. The core of an agent system lies in decentralization and collaboration; that is, there is no single controller directing everything, but rather each agent makes independent decisions based on local information and its own goals, working together through communication and negotiation (such as the Contract Network protocol) to achieve a global objective. This gives the system greater fault tolerance, scalability, and adaptability.

[0023] Topology: The physical and logical arrangement of nodes and connections.

[0024] Collaborative paradigms: Organizational patterns of multi-agent systems. Collaborative paradigms describe the macro-level organizational structure of multi-agent systems, rather than specific task steps. The main typical patterns include: Plan-Execute, ReAct, Hierarchical, and Cyclic Collaboration.

[0025] Plan-Execute: This is a hierarchical, phased paradigm. First, a "planner" agent formulates a detailed and executable plan of sub-tasks based on the global goal. Then, "executor" agents each complete their assigned sub-tasks, usually eliminating the need for complex intermediate coordination.

[0026] Reasoning-Action (ReAct): This is an interactive, cyclical paradigm. An agent independently completes a task using a "think-act-observe" cycle. It first reasones based on the goal, deciding the next action or tool to invoke. After observing the results, it performs another round of reasoning based on new observations until the task is completed. This paradigm is often used for single agents to handle complex decisions, but it can also serve as a behavioral pattern for individuals in multi-agent systems.

[0027] A hierarchical structure is a clearly defined chain-of-command paradigm. The system contains agents at different levels, with higher-level "managers" assigning tasks to lower-level "workers," summarizing results, and making higher-level decisions. This structure has a clear division of labor, similar to an enterprise's organizational structure.

[0028] Cyclic Collaboration: This is a paradigm that emphasizes peer-to-peer and continuous interaction. Agents collaborate through a cyclical workflow, where tasks and intermediate results continuously flow, are processed, and fed back among different agents until a final conclusion is reached. Dynamic graph collaboration, exemplified by the "LangGraph" framework, is a typical implementation of this paradigm. It allows for dynamic changes to the execution path based on intermediate results, making it more flexible than traditional fixed workflows.

[0029] Workflow: A flowchart illustrating the steps involved in task execution. The core of workflow is the determinism and automation of the process. It emphasizes breaking down business processes into standardized steps and clearly defining the executor (person or system), flow rules (sequence, conditional branches), and required data for each step. The workflow management system is responsible for automatically distributing tasks and tracking the status of the entire process until completion.

[0030] Large Language Models (LLMs) are deep learning models trained on massive amounts of text data, enabling them to generate natural language text or understand the meaning of language text. LLMs can provide in-depth knowledge and language production on a wide range of topics through training on large datasets. They learn patterns and structures of natural language through large-scale unsupervised training, mimicking human language cognition and generation processes to some extent. LLMs employ a similar Transformer architecture and pre-training objectives as smaller models, with the main differences being increased model size, training data, and computational resources. Compared to traditional Natural Language Processing (NLP) models, LLMs can better understand and generate natural text, while also exhibiting some logical thinking and reasoning abilities. LLMs possess context learning capabilities. Context learning (LLM) capabilities enable learners to learn complex patterns in language and perform a wide range of tasks, including text summarization, translation, sentiment analysis, multi-turn dialogue, and more. For example, LLM can include the GPT series, T5 (Text Learning Model), and other related technologies. to Text Transfer Transformer (TTL) model, PaLM model, BERT, LLaMA (Large Language Model MetaAI) model, Tongyi Qianwen model, Bailing model, etc.

[0031] In related technologies, methods based on statically preset scheduling graphs have revealed significant limitations in practice, especially when dealing with complex tasks in open and dynamic environments, where their robustness and adaptability are insufficient. Staticly preset scheduling graphs lack the ability to adaptively handle runtime anomalies. For example, when unexpected anomalies occur during task execution (e.g., an agent continuously outputs invalid results, agent behavior violates safety regulations, or system environment interference errors), static scheduling graphs cannot self-diagnose and adjust. The system typically can only terminate with an error or rely on pre-written, limited anomaly handling rules, making it difficult to cope with the diverse and complex combinations of collaborative anomalies, leading to a high task failure rate. The fixed structure of static scheduling graphs may result in low collaborative efficiency in certain task scenarios. For example, individual agents may work ineffectively in loops while the overall task makes no progress, or due to unreasonable scheduling logic, agents may get stuck in a stalemate of mutual waiting or conflict.

[0032] Based on the embodiments in this specification, by introducing a dynamic detection mechanism for collaborative anomaly patterns based on execution trajectories and an online reconstruction mechanism for the task scheduling graph, the inherent defects of traditional multi-agent systems that rely on static preset processes are overcome. Specifically, because the system can diagnose runtime anomalies such as progress stagnation, insufficient result confidence, or behavior exceeding limits in real time during task execution, and proactively reconstruct the first task scheduling graph into a second task scheduling graph aimed at eliminating the anomaly after an anomaly is identified, the system achieves a transformation from rigid execution to dynamic adaptation. This transformation means that when faced with unforeseen execution obstacles, the system no longer necessarily fails or relies on manual intervention, but instead autonomously recovers or optimizes the task process by adjusting the agent collaboration structure (such as adding or deleting nodes, modifying dependencies, and inserting verification loops), thereby directly improving the success rate and robustness of complex tasks in open environments. At the same time, this reconstruction capability gives the system the possibility of self-optimization within a single task execution cycle, reducing agent idleness or conflict by immediately correcting inefficient or ineffective collaborative paths, thereby improving the success rate, efficiency, and reliability of multi-agent systems in complex real-world scenarios.

[0033] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0034] Figure 1 This diagram illustrates an application scenario of a task execution method for a multi-agent system provided in the embodiments of this specification.

[0035] like Figure 1As shown, server 200 can receive a target task input by the user from terminal device 100; it schedules multiple agents to execute the target task according to a first task scheduling graph and generates an execution trajectory; then, based on the execution trajectory, it determines whether a preset cooperation anomaly mode has occurred. If the cooperation anomaly mode occurs, the first task scheduling graph is reconstructed into a second task scheduling graph to eliminate the cooperation anomaly mode. Afterward, the target task can continue to be executed based on the second task scheduling graph. After the target task is completed, server 200 can feed back the task execution result to terminal device 100.

[0036] In such Figure 1 In the application scenario shown, server 200 can connect to one or more terminal devices 100 via LAN connection, WAN connection, Internet connection or other types of data network. Figure 1 The server 200 in the text can include, but is not limited to, any device, equipment, platform, or equipment cluster with computing and processing capabilities. Figure 1 The terminal device 100 may include, but is not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices.

[0037] In practical applications, the task execution method provided in the embodiments of this specification can be implemented as a multi-agent runtime engine. Considering the limited computing resources of mobile terminals, the task execution method provided in the embodiments of this specification can be applied to, for example... Figure 1 The application scenarios shown are not limited to these. In, for example... Figure 1 In the application scenario shown, the multi-agent runtime engine is deployed on server 200. Terminal device 100 can interact with the user through a graphical user interface to invoke the multi-agent runtime engine deployed on server 200, thereby implementing the method provided in the embodiments of this specification. It should be noted that, provided that the runtime resources of the terminal device can meet the deployment and operation conditions of the multi-agent runtime engine, the embodiments of this specification can be performed on terminal device 100.

[0038] This specification provides a task execution method for a multi-agent system in its embodiments. This application also relates to a task execution device for a multi-agent system, and the multi-agent system will be described in detail in the following embodiments.

[0039] Figure 2 This is a flowchart illustrating a task execution method for a multi-agent system provided in an embodiment of this specification.

[0040] From a programming perspective, the entity executing the process can be a program hosted on a server or terminal. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0041] like Figure 2 As shown, the process may include the following steps: Step 202: Obtain the target task.

[0042] The target task can be user-inputted. The user can refer to an external entity that interacts with the multi-agent system, such as a human operator, an upper-level application system, other AI agents, or automated scripts.

[0043] The target task can be a specific work objective that the user wants the multi-agent system to complete collaboratively. In practical applications, the target task can be in the form of structured data (such as JSON, XML), semi-structured instructions (such as Prompt templates), or unstructured natural language (such as "Help me plan a three-day, two-night trip to Hangzhou").

[0044] Step 204: Schedule multiple agents to execute the target task according to the first task scheduling graph and generate an execution trajectory.

[0045] The task scheduling graph is a directed graph data structure used to represent the execution blueprint of a multi-agent system at runtime. Nodes in the task scheduling graph represent agents, and edges represent task scheduling dependencies between agents, including control flow dependencies and data flow dependencies.

[0046] In the embodiments of this specification, the system can record the execution trajectory of a task in real time and perform analysis based on the execution trajectory during or after the task has finished running. The execution trajectory can specifically include the execution trajectories of each agent used to execute the current task. For example, the execution trajectory for an agent is Trace = (step_i, Observation_i, Action_i, Result_i, Confidence_i), where step_i represents the step number, Observation_i represents the information input to the agent, Action_i represents the action performed by the agent, Result_i represents the result produced after the action is performed, and Confidence_i represents the confidence level of the result. This is merely an example; in actual applications, the information in the trajectory may not be limited to this.

[0047] Step 206: Based on the execution trajectory, determine whether a preset collaboration anomaly mode has occurred.

[0048] In practical applications, after each execution step, the adaptive orchestrator in the system can check whether the execution status information meets any of the dynamic adjustment conditions. If any condition is met, the corresponding modification operation is executed.

[0049] In one or more embodiments of this specification, the collaboration anomaly mode includes at least one of the following: Task progress error: The same agent node continuously outputs results with a similarity reaching a preset similarity threshold a predetermined number of times, and the target task is not achieved; Execution quality anomaly: The confidence level of the execution result of any agent node is lower than the preset confidence level threshold; Abnormal behavior: Any agent node issues a request to invoke an unregistered tool; System status abnormality: A preset non-system error has occurred; Task feasibility error: Based on the execution trajectory prediction, the first task scheduling graph cannot complete the target task within the preset constraints.

[0050] Furthermore, abnormal task progress can be used to detect situations where an agent may be trapped in an ineffective loop or a fixed mindset. That is, although an agent is working continuously, its output does not drive the task to make substantial progress toward the goal, causing the task to stagnate.

[0051] Continuous output refers to an agent being scheduled multiple times and producing output at the same execution position (node) in the task scheduling graph. A similarity threshold is reached when the similarity between the current output and several previous historical outputs exceeds a preset numerical threshold, determined by methods such as text similarity calculation (e.g., cosine similarity), semantic vector distance comparison, or structured data alignment. The predetermined number of times is a configurable integer used to set the tolerance level, for example, three consecutive times. Failure to achieve the target task can be determined based on the completion criteria defined for the task objective (e.g., generating code that meets all requirements, obtaining the final answer, etc.), confirming that the task has not yet succeeded.

[0052] In practical applications, for example, the output sequence of each agent node can be monitored. When the similarity between each pair of outputs from the same node is detected to be higher than a threshold S for N consecutive times, and the system determines that the overall task is not completed, this anomaly is triggered. In practical applications, this can manifest as the detection that the currently adopted first collaboration paradigm is stuck in an infinite loop in historical execution steps, the task completion efficiency is lower than the threshold, or the evolution manager determines that the current collaboration paradigm cannot effectively advance the target task.

[0053] Furthermore, execution quality anomalies can be used to monitor the reliability of each agent's output. Low-confidence results may indicate that the agent is uncertain about its output, has limited knowledge boundaries, or lacks sufficient input information. Directly using such results may lead to deviations in subsequent decisions or executions.

[0054] Confidence level refers to the agent's self-assessment of the certainty of its output. In practical applications, confidence level is usually generated internally by the agent model (e.g., the probability score corresponding to text generated by a large language model, or the highest probability value in the probability distribution output by a classification model), or by designing an independent self-assessment module to evaluate the consistency and reasonableness of the output. The preset confidence threshold can be a pre-defined value representing the minimum acceptable level of confidence for the system.

[0055] In practical applications, for example, each time an agent node generates output, its confidence score can be synchronously acquired or calculated. If the score is lower than a preset threshold, this exception is triggered immediately.

[0056] Furthermore, by identifying abnormal behavior patterns, agents can be prevented from performing unauthorized, potentially harmful, or unstable operations, ensuring that tasks are performed within a controlled and secure environment.

[0057] Unregistered tools can refer to external application programming interfaces, functions, software packages, system commands, or data sources that are not registered in the system tool library or whitelist. A call request can refer to an agent attempting to perform an external operation (such as running a shell command, accessing a specific API, or installing a Python package) by calling an interface provided by the system during execution.

[0058] In practical applications, for example, the system can intercept all tool invocation intentions issued by agents and check whether the tool identifier requested by the agent exists in the list of registered tools. If it is not in the list, this exception is triggered.

[0059] Furthermore, the system state anomalies can be used to detect unexpected changes in the external environment or underlying infrastructure on which task execution depends. These changes, although they may not be related to the agent's collaborative logic itself, may hinder the normal progress of the task.

[0060] Among these, the predefined non-systematic errors can refer to errors not caused by the core scheduling and collaboration logic of the multi-intelligent system, but rather by the failure of external dependencies. For example, these error types are predefined in a list, and may include, for instance, network connection timeouts / interruptions, external API services returning unsuccessful status codes (such as 5xx errors), database connection failures, unavailability of dependent third-party services, and errors in local or cloud storage read / write permissions.

[0061] In practical applications, for example, the system can globally monitor all calls to external resources and the status of the underlying platform. When a captured error type matches any category in a preset list, the exception is triggered. For instance, in a multi-source information aggregation task, when a network information query agent attempts to retrieve data from a target website, it receives multiple "502 Bad Gateway" errors. This error is preset as "system status exception." Once triggered, the system can reconstruct the scheduling graph, for example, by inserting a backup source query agent or notifying upstream nodes to adjust information requirements.

[0062] Furthermore, by identifying task feasibility anomalies, the likelihood of success of the current predetermined plan (first task scheduling graph) can be assessed based on the existing execution trajectory before the task completely fails or resources are exhausted, thereby avoiding unnecessary consumption.

[0063] Among these, execution trajectory prediction refers to using existing execution records (such as executed steps, time and results of each step, resource consumption, and progress assessments) as input, and then using a predictive model or a set of heuristic rules to deduce and evaluate future execution paths. Preset constraints refer to the limitations that a task needs to meet, typically including total time limits, maximum computational cost (such as token consumption), financial budgets, and physical resource limitations (such as memory usage limits).

[0064] In practical applications, for example, at key nodes of task execution, the current execution trajectory and task constraints can be input into a prediction module. This module analyzes the complexity of the remaining task subgraph, historical step speed, resource consumption rate, etc., and predicts the time / resources required to complete all tasks according to the current path. If the predicted value exceeds any preset constraint, this exception can be triggered.

[0065] Step 208: If the collaboration anomaly mode occurs, the first task scheduling graph is reconstructed into a second task scheduling graph; the reconstruction is used to eliminate the collaboration anomaly mode.

[0066] In practical applications, if the aforementioned abnormal collaboration mode occurs, the first task scheduling graph can be reconstructed into a second task scheduling graph by changing the composition of the agents and / or the task scheduling dependencies between them.

[0067] In one or more embodiments of this specification, an Adaptive Orchestrator component is provided in the system. This orchestrator acts as the control center of the system, continuously monitoring the "execution trajectory" data stream reported from each agent node. This data stream includes the output content of each node, metadata (such as confidence level and execution time), and system status information. During task execution, the Adaptive Orchestrator can add or delete nodes or modify connection edges in real time based on the quality of intermediate results to achieve dynamic collaboration among agents.

[0068] Furthermore, the adaptive orchestrator can identify collaboration anomaly patterns based on preset rules or a dynamic orchestration model, and determine the corresponding refactoring operations for eliminating these anomaly patterns. Specifically, the adaptive orchestrator can integrate an anomaly diagnosis and strategy generation module. For example, this module can first match the monitored execution trajectory with features of predefined collaboration anomaly patterns (e.g., calculating whether the confidence level is below a threshold, detecting whether the call is unauthorized). Once a match is successful, the module can generate one or more specific refactoring operation instruction sets based on a preset "anomaly-refactoring" mapping rule base, or using a trained dynamic orchestration model (which can take anomaly type, context, and task objective as input, and recommended refactoring operations as output).

[0069] In one or more embodiments of this specification, reconstructing the first task scheduling graph into a second task scheduling graph specifically includes calling a graph operation application interface to perform at least one of the following reconstruction operations: adding or deleting agent nodes; adding, deleting, or modifying task scheduling dependency connections between agent nodes.

[0070] Specifically, dynamic graph manipulation operators can be triggered by calling the graph manipulation application programming interface (API) to insert new agent nodes into the task scheduling graph, delete existing agent nodes from the task scheduling graph, and modify the connecting edges between nodes in the task scheduling graph. These dynamic graph manipulation operators form the basic instruction set for implementing topology mutations.

[0071] As an example, dynamic graph operation operators can include, but are not limited to, Add_Node (dynamic injection expert), Rewire_Edge (path replanning), and Dynamic_Loop (confidence-based loopback verification). These operators directly correspond to executable operations of the underlying system API.

[0072] For example, the Add_Node(agent, new_agent) operator is used for the dynamic addition of agents. When the orchestrator determines that new capabilities need to be introduced, this operator can be called to dynamically inject a prepared agent instance (new_agent) into the position associated with the specified agent in the current topology graph, thereby expanding the system's collaborative capabilities.

[0073] For example, the Rewire_Edge(agent1, agent2) operator is used for dynamic path modification, including adding edges (add_edge) or deleting edges (delete_edge). For instance, when an existing associated path is found to be inefficient or invalid, the task flow can be replanned by deleting old edges and adding new ones, rerouting the task from agent1 to a more suitable agent2.

[0074] For example, the `Dynamic_Loop(agent, max_run_times, stop_func)` operator is used to create dynamic loop logic. It causes the specified agent to switch to a loop execution mode and sets the maximum number of runs (`max_run_times`) and a stop function (`stop_func`). In an exemplary application, when the output of a search agent is deemed insufficient by the evaluation function (`stop_func`), the agent will be automatically re-executed in a loop until the result meets the requirements or the loop limit is reached, thus achieving validation-based adaptive iteration.

[0075] Furthermore, the adaptive orchestrator possesses the capability for circuit breaking and intervention in case of anomalies. When severe anomalies such as execution deadlock or a result confidence level consistently falling below a preset threshold are detected, the orchestrator can automatically trigger highly interventionist topology mutations. For example, after a series of agent nodes exhibiting low-quality output, a thought chain optimization node can be dynamically inserted. This node can act as an auxiliary node, not directly executing the original task, but rather decomposing the output of the predecessor node, completing the inference chain, or optimizing prompts. The optimized context is then passed to subsequent nodes for processing, thereby attempting to break inefficient or erroneous thought patterns and attempting to repair the execution path without restarting the system.

[0076] In an optional embodiment, the reconstruction operation may specifically include: inserting a verification node after the current execution node in the execution trajectory; establishing a dependency connection from the verification node to the current execution node to form a cyclic verification path. This forms a cyclic verification path containing the current execution node and the verification node. The cyclic verification path is used to trigger the execution of the current execution node based on the verification result of the verification node.

[0077] In practical applications, the verification node can be used to verify the correctness of the output of the current execution node (in practical applications, the preceding agent). If the verification fails and the maximum number of retries has not been reached, a loopback is triggered back to the current execution node. The verification node itself can be a verification agent or a simple rule checker. Its verification logic can be customized according to the task type. For example, for code generation tasks, the verification node can call a syntax checker; for question-answering tasks, it can call a fact consistency checker. The loopback mechanism means that when verification fails, the task flow will not proceed directly downwards, but will reschedule the current execution node with the failure feedback information, prompting it to adjust its output. This process continues until verification succeeds or the preset maximum number of retries is reached. If it still fails in the end, a higher-level exception may be triggered, leading to further refactoring (such as changing the execution node).

[0078] Step 210: Based on the second task scheduling graph, continue to execute the target task.

[0079] Specifically, based on the second task scheduling graph, the agents defined in the second task scheduling graph can be scheduled to continue executing the target task.

[0080] Furthermore, the adaptive orchestrator can modify the task scheduling graph using hot-swappable orchestration. By introducing middleware interceptors, the task scheduling graph can be manipulated in real time during the time slice intervals of task execution.

[0081] In one or more embodiments of this specification, reconstructing the first task scheduling graph into a second task scheduling graph specifically includes: pausing the execution of the target task; modifying the first task scheduling graph during the pause; and correspondingly, continuing to execute the target task based on the second task scheduling graph specifically includes: resuming the execution of the target task from the pause point based on the second task scheduling graph.

[0082] Specifically, the target task can be continued from a node that completed execution before the pause (e.g., the most recent valid state point before the collaboration anomaly occurred), based on the second task scheduling graph. More specifically, the context state carried by the execution trajectory can be mapped to the input of the second task scheduling graph to continue the execution of the target task.

[0083] Furthermore, during the scheduling process, the intelligent agent nodes exchange data with zero copy through distributed shared storage.

[0084] Specifically, during scheduling and execution, snapshot and rollback mechanisms can be employed to support state recovery in the event of dynamic topology change failures. Furthermore, snapshots can save the historical states of all agents, such as agent inputs, tool calls and responses, and agent decision information. They can also include task metadata, such as task IDs and completed agent nodes. In practical applications, snapshots and rollbacks can be implemented through the system's dynamic graph construction and scheduling engine.

[0085] Based on the embodiments of this specification, the reconstruction of the first task scheduling graph into a second task scheduling graph can be modified at runtime. If the system finds that the current task scheduling graph is difficult to execute or has problems, nodes can be dynamically added, deleted, or connection edges can be modified without restarting the entire system. In other words, the task scheduling graph in the embodiments of this specification can actually change dynamically during actual runtime and can evolve based on real-time feedback during task execution. All reconstruction operations are completed within a controllable time slice through middleware interceptors, achieving seamless switching of currently executing task instances, maximizing the continuity of task execution and the overall availability of the system, and improving the system's execution success rate and robustness.

[0086] Based on the embodiments described in this specification, a hot reload-based system self-adjustment is implemented. The entire task scheduling graph reconstruction process takes place in the system's runtime memory: the adaptive orchestrator generates reconstruction instructions, calls dynamic graph operation operators through the graph operation API, and directly performs incremental updates to the current task scheduling graph data structure maintained in memory. Task states (including intermediate outputs and context of each node) are fully preserved, and after a brief synchronization wait, the system scheduling engine immediately resumes scheduling from the pause point or a specific node based on the updated second task scheduling graph. This mechanism ensures the continuity of task execution and greatly improves the system's resilience and efficiency in handling long-cycle, uncertain tasks.

[0087] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0088] Figure 2The proposed method significantly improves the robustness and success rate of multi-agent systems in complex and uncertain task environments by introducing a dynamic detection mechanism for collaborative anomalies based on execution trajectories and an adaptive reconstruction mechanism for the task scheduling graph. Specifically, during the execution of the target task, the system continuously generates and analyzes the execution trajectory, compares it in real time with preset collaborative anomaly patterns, and triggers a targeted reconstruction of the current task scheduling graph once an anomaly is detected, thereby eliminating the collaborative defects that cause the anomalies at the structural level. Since the reconstructed second task scheduling graph directly addresses the exposed problems and supports seamless resumption of execution from the interruption point, it avoids the resource waste and delay caused by retrying tasks from the beginning. This not only effectively blocks the propagation of anomalies but also realizes the online evolution and self-healing of the scheduling strategy. Ultimately, while ensuring the task completion rate, it improves the system's adaptability, execution efficiency, and overall collaborative reliability.

[0089] based on Figure 2 In addition to the method described herein, this specification also provides some improved implementation methods, which will be described below.

[0090] In one or more embodiments of this specification, the system provides an adaptive management framework. In this adaptive management framework, on the one hand, as described above... Figure 2 As described, the adaptive orchestrator in the system can monitor the execution flow state and issue node change instructions when necessary. On the other hand, the evolution manager in the system can adjust the cooperation paradigm and topology, optimizing the topology based on the state space and execution trajectory, which will be described in detail below.

[0091] In one or more embodiments of this specification, considering the same task topology (i.e., the types of agents and static connections), if different collaboration paradigms (such as sequential execution, debate, voting, and reflection-execution) are used for instantiation, logically different task scheduling graphs will be generated, resulting in completely different execution effects in terms of efficiency and result quality for the same task. Therefore, the system is designed not only to adjust the topology at runtime, but also to further analyze the collaboration efficiency of the collaboration paradigm used in the current task execution, and automatically migrate to a better collaboration paradigm within or across task execution cycles based on the analysis results, thereby realizing the macro-evolution of the system's collaboration strategy. Specifically, the system has a built-in paradigm effectiveness evaluation and migration module (i.e., an evolution manager). The core function of this module is to collect and analyze historical execution data generated under the first collaboration paradigm during the execution of the target task (online evaluation) or after execution (offline analysis); based on the quantitative conclusions obtained from the analysis, trigger and execute a migration process to modify the first collaboration paradigm to a second collaboration paradigm.

[0092] Furthermore, the system can employ a dedicated analysis model (such as a rule engine or machine learning model) to perform in-depth analysis of the execution trajectory to evaluate the execution efficiency of the first collaboration paradigm adopted by the first task scheduling graph. This analysis model can transform the execution trajectory into a series of performance indicators. If the evaluation results indicate that the first collaboration paradigm has not achieved the expected efficiency, the analysis module can determine that this situation is a high-order, systemic collaboration anomaly (which can be classified as a paradigm efficiency anomaly), and accordingly generate an evolutionary strategy to migrate the first collaboration paradigm to a second collaboration paradigm.

[0093] Optionally, the collaboration paradigm may include at least one of the following: workflow, handoff, debate, and team. The workflow paradigm executes according to topological order and supports conditional branching; the handoff paradigm represents collaboration between agents through dialogue and tool calls, supporting loops and backtracking; the debate paradigm represents multiple agents reacting from different perspectives and reaching consensus through debate; and the team paradigm represents collaboration between agents through shared workspaces and negotiation mechanisms.

[0094] In practice, ReAct and Plan-Execute are the "fundamental paradigms" defining collaboration logic, while Workflow, Handoff, etc., are "implementation patterns" describing team organizational structures. ReAct and Plan-Execute define the core thinking and action cycles of individual or collective agents. Workflow, Handoff, Team, and Debate define the organizational structure, communication protocols, and task flow methods among multiple agents. Typically, the Plan-Execute paradigm manifests as a Handoff mode in team organization. The ReAct paradigm can be specifically implemented into various team modes, such as Workflow mode, Team mode, and Debate mode.

[0095] Furthermore, the task execution method may further include: determining the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph based on the execution trajectory, wherein the performance evaluation result is determined based on at least one of task success rate, number of execution steps, resource consumption and result confidence; and modifying the first collaboration paradigm to a second collaboration paradigm in response to the performance evaluation result satisfying a preset paradigm switching condition.

[0096] The performance evaluation is a multi-dimensional quantification process. Task success rate can represent the final judgment (yes / no) on the achievement of the task objective, or a continuous success score (e.g., 0-1). Execution steps can represent the total number of scheduling steps required to complete the entire task or key sub-objectives, directly reflecting process efficiency. Resource consumption can mainly include computational resource consumption (e.g., total number of tokens, GPU time) and total task execution time. Result confidence can represent the system's overall confidence in the final output result, which in practical applications can be determined by the output confidence of the end agent or the verification result of a specific verification node.

[0097] Evaluation metrics such as task success rate, number of execution steps, resource consumption, and result confidence can be carried in the historical execution trajectory or obtained through analysis of information in the historical execution trajectory. The paradigm effectiveness evaluation and transfer module can extract or calculate these metrics from the execution trajectory and synthesize the final paradigm effectiveness score through, for example, a weighted scoring function.

[0098] The paradigm shift condition can be exemplarily defined as follows: the evaluation score in the performance assessment result is lower than a preset performance threshold, for example, lower than the average score of similar historical tasks. Furthermore, the paradigm shift condition can also be relative; for example, in an A / B test, the average performance score of the current paradigm is consistently lower than that of another alternative paradigm; or, during task execution, the real-time predictive trend of performance indicators indicates that the task cannot be completed within the constraints.

[0099] Based on the timing and scope of paradigm shifts, the system supports two typical paradigm switching scenarios.

[0100] In an optional embodiment, the task execution method further includes: acquiring the execution trajectory of the target task in execution; determining, based on the execution trajectory, the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph on the target task; and, in response to the performance evaluation result satisfying a preset paradigm switching condition, switching the collaboration paradigm of the target task and subsequent tasks from the first collaboration paradigm to a second collaboration paradigm. This is an online task migration scenario. For example, in the middle of a complex problem-solving task, the system detects that the current debate-based paradigm is causing the agents to get bogged down in endless arguments and unable to progress. At this time, it can dynamically switch to a team collaboration paradigm, where the organizer agent terminates the argument and decides on the next action.

[0101] In an optional embodiment, the task execution method further includes: obtaining the task execution trajectory of multiple completed tasks executed based on the first task scheduling graph; determining the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph on the multiple completed tasks based on the task execution trajectory; and switching the collaboration paradigm of subsequent tasks from the first collaboration paradigm to the second collaboration paradigm in response to the performance evaluation result meeting a preset paradigm switching condition. This is an offline cross-task migration scenario. For example, when automating the processing of customer complaint work orders, the handoff paradigm (collaboration between agents through dialogue and tool calls, supporting flexible backtracking and looping) was initially adopted. Later, the system found that for work orders with high process standardization requirements, there were problems of uncertain processing paths and long processing times. Performance evaluation showed that after switching to the more rigorous workflow paradigm, the average processing time of the task was shortened by 40%. Therefore, the system will automatically migrate subsequent work order tasks marked as "standard process" from the handoff paradigm to the workflow paradigm.

[0102] In practical applications, performance evaluation can be performed after each task is completed. Specifically, the evaluation result can be a performance score. The evaluation result meets a preset paradigm shift condition, which can be that the performance score is greater than or equal to a preset score threshold. Optionally, if the system is found to be stuck in an infinite loop during task execution, the performance score can be lower than the preset score threshold; for example, the performance score can be 0.

[0103] As an example, modifying the first collaborative paradigm to the second collaborative paradigm can be done in one scenario: changing the collaborative paradigm from the ReAct paradigm to the Plan-execute paradigm. In the ReAct paradigm, agents perform reasoning and action invocation in an interleaved manner, which is suitable for exploratory tasks. However, when system evaluation finds that this paradigm leads to too much invalid exploration and backtracking in tasks requiring explicit steps, it can be switched to the Plan-execute paradigm. In this paradigm, a planning agent first formulates a complete sequence of steps, and then the executing agent executes them sequentially, thereby improving the determinism and efficiency of execution.

[0104] In one or more embodiments of this specification, determining the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph based on the execution trajectory specifically includes: inputting the execution trajectory and the description information of the target task into a pre-trained performance prediction model to obtain the performance evaluation result of the first collaboration paradigm on the target task output by the performance prediction model; wherein, the performance prediction model is a machine learning model trained based on historical task data, used to predict the execution performance of different collaboration paradigms under a given task type; the performance evaluation result includes an evaluation score and paradigm recommendation information, wherein the paradigm recommendation information indicates that the first collaboration paradigm should be replaced by a second collaboration paradigm.

[0105] The performance prediction model can be a machine learning model trained under supervised supervision based on historical multi-agent task data. By learning the complex mapping relationship between task features, collaborative behaviors, and execution results, it predicts the potential execution performance of different collaborative paradigms under a given task type. The performance prediction model can be implemented using fine-tuning of a large language model. Specifically, the model's training data can come from a historical task database. Each data sample can include: a natural language description and metadata of the task (such as task type and complexity labels); the identifier of the adopted collaborative paradigm (such as workflow or debate); a complete textual record of the execution trajectory (including agent actions, outputs, states, and time consumption for each step); and the final performance label (such as success / failure and efficiency score) obtained through manual annotation or post-calculation. By fine-tuning the large language model (e.g., a model based on the Transformer architecture) on the above data, it learns to analyze and infer the suitability and problems of the current collaborative paradigm based on the input task description and execution trajectory fragments.

[0106] The evaluation score can be used to objectively measure the effectiveness of the current paradigm, while the paradigm recommendation information can provide specific optimization directions. For example, this recommendation information can be output in structured natural language or JSON format.

[0107] In practical applications, when the performance prediction model outputs evaluation results that include paradigm recommendation information, it can also simultaneously output node modification suggestions. For example, the paradigm recommendation information output by the model could be, "It is recommended to use the Plan-Execute paradigm and add a new summarizing agent to enable downstream processes to better obtain key information." Therefore, modifications to the task scheduling graph can be implemented based on the node modification suggestions output by the performance prediction model.

[0108] In one or more embodiments of this specification, modifying the first collaboration paradigm to a second collaboration paradigm specifically includes: using the second collaboration paradigm to re-instantiate the topology corresponding to the first task scheduling graph to generate a third task scheduling graph.

[0109] Specifically, the first collaboration paradigm parameter (e.g., build_type='workflow') used when instantiating the task scheduling graph is replaced with a second collaboration paradigm parameter (e.g., build_type='team'). Thus, the logical rules of the second collaboration paradigm can be used to re-instantiate the original topology corresponding to the current task, thereby generating a third task scheduling graph with completely different internal scheduling logic.

[0110] Based on the timing of the migration and its impact on the current task, paradigm switching can be divided into two modes: online switching and offline switching.

[0111] Optionally, a paradigm switch can be performed online. In this case, the second collaborative paradigm can be adopted to re-instantiate the topology of the currently executing target task, generating a third task scheduling graph. This third task scheduling graph can be used to execute the current target task and subsequent similar tasks. Specifically, the evolution manager can reconstruct the current task scheduling graph to generate a new task scheduling graph that matches the second collaborative paradigm. Specifically, at least one of the following operations can be performed on the current task scheduling graph: deleting ineffective agent nodes; generating new agent nodes and establishing connections with specified agent nodes in the current task scheduling graph. This paradigm switch process needs to maintain state continuity and consistency. After reconstructing the task scheduling graph, the context state during the execution of the old task scheduling graph (first task scheduling graph) can be mapped to the corresponding input of the new task scheduling graph (third task scheduling graph) to continue or re-execute the target task based on the historical execution state. The context state may include, but is not limited to, the output results of completed agent nodes, shared information in the global workspace, the current understanding of the task objectives and constraints, and the consumption of resources. The state mapping engine needs to analyze the data flow interfaces of the old and new scheduling graphs, intelligently filling the corresponding input slots in the new graph with the valid information from the old state. This may involve data format conversion, information summarization, or reorganization. For example, when switching from a workflow paradigm to a debate paradigm, the intermediate conclusions of the linear output need to be transformed into an initial set of arguments that can be cited by multiple debaters.

[0112] Optionally, the paradigm switch can be performed offline. In this case, the second collaborative paradigm can be used to re-instantiate the topology structure with the same task type as the target task, generating a third task scheduling graph. The third task scheduling graph can be used to execute subsequent tasks of the same type. This paradigm switch process occurs after the current task has been completed, or after analysis conclusions are obtained based on batch historical task data. This paradigm switch process does not involve runtime state migration; it can simply update the paradigm template corresponding to this type of task within the system. When the next task of the same type is created, the system will directly use the new paradigm template for instantiation.

[0113] In practical applications, for online migrations, the orchestrator will coordinate the transfer of task states from the old graph to the new graph; for offline migrations, the graph instantiated by the new paradigm will be applied directly when the next task starts.

[0114] Traditional multi-agent systems employ a pre-configured collaborative paradigm by the system designer, which cannot self-adjust based on actual task performance. This solution enables the system to intelligently determine the suitability of the current paradigm based on actual execution data during operation and automatically recommend a better option. This represents a leap from static configuration to dynamic evolution, significantly improving the system's adaptability and task success rate.

[0115] Based on the embodiments described in this specification, an adaptive evolution scheme for collaborative paradigms is provided. Based on feedback such as execution trajectories, the system automatically identifies the defects of the current collaborative paradigm and reflects on and improves it, achieving system self-repair and evolution. Specifically, by analyzing complex execution trajectories using a large language model, the system can automatically identify the failure modes of the current paradigm (such as getting stuck in an infinite loop, inefficiency, etc.) without requiring manual log analysis by developers. This significantly reduces operational costs and enables real-time or near real-time system self-optimization. More importantly, this data-driven paradigm evolution capability allows the multi-agent system to continuously accumulate experience, forming a practical knowledge base for different task scenarios, thereby exhibiting long-term autonomous performance improvement evolutionary characteristics.

[0116] In one or more embodiments of this specification, a paradigm shift knowledge accumulation mechanism is further provided. This mechanism aims to accumulate the experience gained from a successful paradigm shift and task execution into reusable knowledge to optimize the system's handling of future tasks.

[0117] Specifically, the task execution method further includes: determining whether the target task or new task has been successfully executed based on the third task scheduling graph; if the new task has the same task characteristics as the target task; and if so, storing the task characteristics, the topology, and the second collaboration paradigm as a task paradigm template. Specifically, the system can trigger a template generation process after detecting the successful completion of a paradigm shift-driven task. The criteria for successful execution are configurable, for example, the task's final output passing acceptance testing, the overall performance evaluation score exceeding a preset threshold, or no serious collaboration anomalies being triggered.

[0118] The task features can be implemented as task type representations or semantic embedding vectors of task information, but are not limited to these. Furthermore, the consistency of task features can mean that the new task and the target task are classified into the same type in a preset task classification system; or that the keyword matching degree between the new task and the target task exceeds a preset threshold; or that the task description is converted into a high-dimensional semantic embedding vector, and the consistency of task features is determined by calculating the cosine similarity between the vectors.

[0119] Furthermore, the task paradigm template can also be associated with and store historical execution performance information. This historical performance information may include at least one of the following: the average number of steps required to complete the task; the average time required to complete the task; the average amount of computing resources consumed to complete the task; and the average confidence level of the execution result. This performance information can serve as performance tags for the template, and can be used as an important basis for sorting or filtering when retrieving and recommending templates in the future.

[0120] In an optional embodiment, the task paradigm template is used so that when the system receives a subsequent task that matches the task characteristics, it automatically loads the corresponding topology and collaboration paradigm to generate an initial task scheduling graph, and then executes the subsequent task. This avoids the system exploring from scratch or using default configurations for each new task, instead allowing it to initialize directly from historically optimized practices, thereby significantly improving the task execution success rate.

[0121] To achieve the aforementioned automatic recommendation capabilities, the system can maintain a centralized collaborative paradigm knowledge base (referred to as the paradigm base).

[0122] In one or more embodiments of this specification, the task execution method further includes: upon receiving a subsequent task, performing a similarity match between the task description of the subsequent task and task feature information in a plurality of stored task paradigm templates; if a target task paradigm template with a similarity exceeding a preset similarity threshold is matched, then an initial task scheduling graph is constructed for the subsequent task based on the topology associated with the target task paradigm template and the second collaboration paradigm.

[0123] Upon receiving a subsequent task, the description of the subsequent task is matched with the task feature information in multiple stored task paradigm templates. If a target collaboration template with a similarity exceeding a preset similarity threshold is matched, an initial execution configuration is constructed for the subsequent task based on the topology information and collaboration paradigm information of the target collaboration template.

[0124] Furthermore, the construction of the initial task scheduling graph for subsequent tasks based on the target task paradigm template can specifically include at least one of the following methods: directly instantiating the initial task scheduling graph using the topology associated in the target task paradigm template and the second cooperation paradigm; or making adaptive adjustments based on the topology associated in the target task paradigm template, and then instantiating it using the second cooperation paradigm to generate the initial task scheduling graph. The adaptive adjustments may include fine-tuning points or edges using the aforementioned dynamic graph operation operators according to subtle differences in subsequent tasks; retaining the topological skeleton but replacing individual agents with updated versions of similar functions, etc.

[0125] Based on the embodiments described in this specification, the system maintains a paradigm library to implement intelligent recommendations based on historical experience. This paradigm library can recommend suitable collaborative configurations for subsequent tasks through task similarity matching.

[0126] Specifically, the paradigm library adopts a key-value pair storage architecture. The key is the semantic embedding vector of a historical task; the value is the configuration metadata corresponding to that task. The configuration metadata associated with each key is a structured data object, which may include: 1) a topology definition, representing the specific agent nodes and their connections used when executing the task corresponding to the key; 2) a collaboration paradigm identifier, representing the applied collaboration paradigm, such as, but not limited to, workflow paradigm, handover paradigm, debate paradigm, or team paradigm; 3) execution performance data (optional), representing metrics for quantitatively evaluating the historical execution efficiency of the configuration, including but not limited to success rate, total task time, and number of execution steps; 4) other information (optional), such as template creation time, number of successful executions, and applicable task constraints.

[0127] Furthermore, the retrieval and matching process of the paradigm library may include: when a subsequent task is received, the system calculates the similarity between the task description of the subsequent task and all keys (i.e., semantic vectors of historical tasks) in the paradigm library. If there is a historical task with a similarity exceeding a preset threshold, it is considered a successful match (or "recall"). The system retrieves the configuration metadata associated with the historical task with the highest matching degree as a reference for constructing the initial execution configuration of the subsequent task. Further, the system can weight and sort the configuration metadata associated with the top K historical tasks with the highest matching degree according to their associated execution performance data (such as success rate), and finally use the highest-ranked configuration metadata as a reference for constructing the initial execution configuration of the subsequent task.

[0128] Based on the embodiments in this specification, thanks to the constructed paradigm library and the reuse mechanism of the task paradigm templates in the paradigm library, the system can learn by analogy and quickly apply successful experience in solving similar problems to new problems, realizing the inheritance and reuse of experience knowledge, giving the multi-agent system the ability to continuously adapt and evolve, thereby helping to improve the system's task execution success rate, efficiency and reliability.

[0129] In one or more embodiments of this specification, the task paradigm template is also associated with and stored paradigm evolution information; the paradigm evolution information is used to indicate that the first collaboration paradigm is modified to the second collaboration paradigm.

[0130] Specifically, the paradigm evolution information can be a meta-description of a successful paradigm shift event, which records the system's self-optimization decisions in a structured form. In practical applications, this paradigm evolution information may include: 1) the first collaboration paradigm adopted before the evolution; 2) the second collaboration paradigm adopted after the evolution; 3) the specific collaboration anomaly or inefficiency that triggered this evolution; and 4) optionally, the context in which the evolution occurred (such as the task execution phase) and the quantitative improvement effect brought about by the evolution (such as the percentage increase in task success rate or the reduction in time consumption).

[0131] Furthermore, the task paradigm template is used so that when the system receives a subsequent task matching the task characteristics, if the current task scheduling graph is generated based on the first collaboration paradigm, the first collaboration paradigm can be replaced with the second collaboration paradigm. Specifically, the second collaboration paradigm can be used to reconstruct the abstract topology on which the current scheduling graph is based to generate a reconstructed task scheduling graph, and then execute the subsequent task. This means that the task paradigm template, which stores paradigm evolution information, not only provides an optimized solution (the second collaboration paradigm) but also retains knowledge of the upgrade path from a non-optimized solution (the first collaboration paradigm) to an optimized solution (the second collaboration paradigm). When the configuration initialized by the system for a new task happens to fall into the first collaboration paradigm, which has historically been proven to be a non-optimized solution, a preventative paradigm upgrade can be proactively and in advance based on the evolution information recorded in the template, instead of waiting for the same anomaly to occur again during task execution. This is equivalent to directly transforming historical lessons into proactive optimization for the future.

[0132] In an optional embodiment, the task paradigm template is further used as reference information input to the performance prediction model; wherein the performance prediction model is used to receive the task paradigm template and the execution trajectory of the current task, and output collaborative paradigm recommendation information for the current task.

[0133] The task paradigm templates are used as reference examples input into the performance prediction model to help it provide more accurate paradigm recommendations. In other words, these templates constitute a sample library (Few-Shot Examples) or a source of training data for the performance prediction model. By learning from these successful paradigm evolution cases, the performance prediction model can more accurately understand under what task characteristics and anomalous performance should it switch from paradigm A to paradigm B.

[0134] Furthermore, a paradigm library (i.e., a knowledge base storing historical task paradigm templates) can be provided as input to the large language model, enabling the construction of a more powerful and reliable evaluation and recommendation system. Specifically, this can be implemented as an application of a retrieval-enhanced generative architecture in system self-optimization. The system dynamically combines real-time analysis of the problem (current task and trajectory) with the historical experience base (paradigm library), ensuring that the large language model's reasoning is based on verified facts.

[0135] Specifically, the performance prediction model is a large language model; determining the performance evaluation result using the performance prediction model specifically includes: constructing prompt information and inputting it into the large language model, the prompt information including at least: the execution trajectory of the current task, the currently adopted first collaboration paradigm, and historical task paradigm templates similar to the current task retrieved from multiple stored task paradigm templates; the large language model generates paradigm recommendation information that combines the execution trajectory and the historical task paradigm templates based on the prompt information.

[0136] In practical applications, an effectiveness prediction model is used to determine the effectiveness evaluation results. Specifically, this involves constructing a prompt message input to the large language model, comprising the following parts: Context, providing the current configuration environment of the multi-agent system, a list of available agents, and a toolset; Analysis Object, providing a description of the current target task, information on the first collaborative paradigm, and the currently generated detailed execution trajectory; Knowledge Reference (optionally), task paradigm templates from one or more historically successful tasks similar to the current target task retrieved from a paradigm library, wherein the templates at least contain the collaborative paradigm they adopted (and may also contain execution effectiveness data); Instructions, requiring the evaluation of the effectiveness of the current paradigm based on the provided trajectory data and referring to historical success experience, and recommending a better collaborative paradigm. Based on the prompt message, the large language model generates the evaluation results and paradigm recommendation information that combine real-time performance and historical experience. Therefore, the analysis of the large language model is not arbitrary but anchored and guided by context and knowledge reference, making its recommendation results more practical and accurate.

[0137] Based on the embodiments described in this specification, the large language model can not only analyze why a current task fails or is inefficient, but also draw on the successful experiences of similar tasks in the past. For example, even if the current ReAct paradigm performs poorly, the large language model can find that the Plan-Execute paradigm has a high success rate for similar tasks through retrieval, and can directly recommend the latter based on historical experience, making the decision more persuasive and reliable. Furthermore, since the templates in the paradigm library are verified and effective templates, the large language model can effectively avoid recommending new paradigms that are theoretically feasible but not practically verified, or incompatible with the existing intelligent agents / tools in the system, thus ensuring the stability, controllability, and feasibility of the recommendation results.

[0138] Based on the embodiments described in this specification, the system forms a learning closed loop: successful experiences (including the final paradigm-topology combination and its evolution path) are stored in the paradigm library -> when subsequent tasks encounter problems during startup or execution, the system retrieves and calls upon these relevant historical experiences as a reference -> combined with real-time data, it makes better decisions (such as directly adopting templates or triggering proactive evolution), thereby generating new successful experiences -> these are then filtered and stored again in the paradigm library. This allows the system's collective intelligence to continuously grow over time, achieving adaptive evolution; that is, the system can continuously improve its task processing efficiency, accuracy, and robustness during use.

[0139] In one or more embodiments of this specification, the first task scheduling diagram may be actively selected by the user when inputting target task information; or it may be automatically determined by the system from multiple preset task scheduling diagrams after the user inputs target task information. In either case, the first task scheduling diagram may be pre-generated.

[0140] Specifically, before scheduling multiple agents to execute the target task according to the first task scheduling graph, the method further includes: instantiating a specified topology using a first cooperation paradigm to generate the first task scheduling graph.

[0141] Specifically, the first task scheduling graph is generated by the following steps: based on the topology and according to the execution semantics defined by the first cooperation paradigm parameters, the control flow and data flow dependencies between nodes in the topology are derived, thereby forming a schedulable directed graph.

[0142] More specifically, a topology description can be obtained, which includes topology structure information and a first protocol paradigm parameter; then, the topology structure specified in the topology description is instantiated based on the first cooperation paradigm specified in the topology description to generate the first task scheduling graph.

[0143] The topology description can be provided by the developer.

[0144] The topology can represent an abstract collaborative skeleton declared by the developer, used to represent nodes and the abstract connection intentions between nodes. The same topology can correspond to multiple execution methods. In the embodiments of this specification, the topology declared in the topology description can be defined using declarative syntax / native data structures (such as (A, [B, C])).

[0145] The collaborative paradigm can represent an execution strategy or semantic interpretation rule. More specifically, it can be used to determine the specific rules for interaction between agents, data transfer protocols, and scheduling logic. Examples of collaborative paradigms include workflow, handoff, debate, and team collaboration. Collaborative paradigms can determine how topological structures are interpreted, influencing edge semantics, node behavior, and context passing methods.

[0146] The task scheduling graph, representing a concrete, schedulable execution graph instance, is a specific runtime object. It includes nodes, directed edges, data flow, and control flow. The task scheduling graph serves as the basis for the system's actual agent scheduling. Determined by both the topology and the cooperation paradigm, the task scheduling graph is the result of the system parsing, compiling, and instantiating the abstract topology according to the algorithm corresponding to a specific cooperation paradigm.

[0147] In practical applications, the same topology can generate different task scheduling graphs when using different collaboration paradigms.

[0148] Traditionally, task scheduling graphs in multi-agent systems typically require developers to define them by writing code (e.g., using frameworks like LangGraph and AutoGen). Developers need to specify the agents (nodes) and the connections between them (edges). This usually includes: defining the functionality of each agent (e.g., by writing functions or classes); defining the interaction logic between agents, i.e., control flow (e.g., one agent's output as another agent's input); and possibly defining state management (i.e., the overall system state structure and how each agent reads and updates the state). For example, in LangGraph, developers need to write a state graph, add nodes (agents), and then define edges (including conditional edges). This requires developers to have a deep understanding of graph concepts and the framework's API. This development model not only leads to inefficiency but also easily introduces errors due to manually managing complex dependencies and states, increasing debugging and maintenance costs. Ultimately, this makes the application threshold for multi-agent collaboration technologies high, hindering their rapid iteration and widespread deployment.

[0149] In the embodiments described in this specification, developers do not need to learn specialized graph definition languages ​​or framework APIs. They can describe complex parallel, serial, and nested topologies using data structures (lists, tuples) from familiar programming languages ​​such as Python. Developers do not need to explicitly define edges (connections). Instead, they implicitly define control flow and data flow through nested lists and tuples, and the system can automatically deduce execution dependencies based on the data structures.

[0150] Based on the embodiments described in this specification, a unified declarative syntax based on the native data structures of programming languages ​​is applied. This syntax allows developers to define arbitrarily complex collaborative topologies in an intuitive and concise manner. The system can automatically deduce all control flow and data flow dependencies, thereby freeing developers from tedious low-level coding. Furthermore, the multi-agent collaborative framework in the embodiments of this specification applies a fractal architecture of "topology as nodes," supporting unlimited nesting and hybrid orchestration of collaborative modules of different granularities and paradigms. It also introduces a runtime dynamic topology reconstruction and adaptive evolution mechanism for collaborative paradigms, enabling the system to adjust collaborative strategies in real time during task execution.

[0151] In one or more embodiments of this specification, a technical solution is provided for generating task scheduling graphs for use during task execution based on a unified declarative syntax.

[0152] Specifically, the step of instantiating the specified topology using the first cooperation paradigm to generate the first task scheduling graph includes: obtaining a topology description; the topology description is composed of native data structures of a programming language and is used to declare the topology between nodes in a multi-agent system and the first cooperation paradigm; based on the topology description, deriving the execution dependencies between nodes defined by the topology, the execution dependencies including control flow dependencies and data flow dependencies; and instantiating the execution dependencies into a task scheduling graph.

[0153] In this context, "programming language" refers to the language used by developers to write multi-agent cooperative topologies, such as Python.

[0154] The term "native data structure of a programming language" as used in the embodiments of this specification refers to the data structure types defined in the programming language's standard specification that can be used without importing external libraries. In other words, it refers to the basic, built-in data construction methods provided by the programming language's standard library for organizing data. Different programming languages ​​have different native data structures. For example, Python's native data structures include, but are not limited to: lists, tuples, dictionaries, and sets.

[0155] Based on the embodiments in this specification, multi-agent topology is described using data structures built into programming languages ​​and naturally used by developers (such as lists and tuples in Python). This eliminates the need for additional syntax or DSL parsers, replacing the complex code that traditionally requires explicit definition of edges and states. As a result, the engine can directly manipulate native object structures in the developer's program without requiring the developer to write additional configuration files or learn a new language. Developers describe the topology using declarative syntax, and the system automatically parses the declaration and derives control flow and data flow dependencies, thereby scheduling execution. In computer science, declarative programming is a programming paradigm that describes the nature of a goal, allowing the computer to understand the goal, rather than the process. That is, telling the computer "what I want," rather than "how to do it."

[0156] Based on the embodiments in this specification, developers can describe the topology of multi-agent systems using a unified syntax (such as a combination of data structures like lists and tuples). For example, the line `Swarm(agent1, [agent2, agent3], agent4)` declares the cooperative relationship between agents: agent1 executes first, then agent2 and agent3 execute in parallel, and finally agent4 executes. Developers do not need to write code on how to schedule, how to transfer data, or how to execute in parallel; they only need to declare the logical relationships between these nodes. The system will parse this declaration and automatically deduce the execution order (control flow) and data flow (data flow), and then schedule the execution.

[0157] The declaration occurs when the developer writes the topology description. The developer uses a provided unified syntax (which in Python may manifest as predefined classes, and data structures such as lists and tuples) to declare the topology. This declaration can be in the code or in a configuration file (such as JSON / YAML). Unlike imperative methods (such as LangGraph) that require explicit definition of edges and states, the declarative approach in the embodiments of this specification is not only reflected in the fact that the developer only needs to describe the topology, but also in: using common programming data structures (lists, tuples) as the syntax, which is very intuitive for developers; supporting nesting (fractals), allowing the construction of arbitrarily complex topologies; and automatically deriving control flow and data flow without the need for manual definition of edges and state transitions.

[0158] In embodiments of this specification, the topology description declares the collaborative relationships between agents through a combination of native data structures of the programming language. More specifically, the topology description information uses a combination of data structures built into the programming language to represent the topology structure, that is, to represent the topology structure between nodes.

[0159] The topology description employs a unified modeling protocol based on data structure expressions (or a unified meta-topology modeling protocol, which can be viewed as a set of grammatical rules). These data structure expressions utilize built-in syntax structures from programming languages, representing agent nodes, parallel execution structures, serial execution structures, and recursive sub-topologies through combinations of expressions. Furthermore, by parsing the nested relationships of the data structure expressions in the topology description, the execution dependencies between agent nodes can be automatically derived, and tasks can be scheduled for each relevant agent based on these derived dependencies.

[0160] The data structure expressions may include: array expressions for representing parallel execution relationships; and tuple expressions for representing serial execution relationships. The recursive sub-topology is encapsulated as a single logical node, enabling topology structures at any level to be referenced as nodes in higher-level topologies.

[0161] Furthermore, the topology description adopts a unified representation method based on data structure literal syntax, wherein: agent nodes are represented by variable identifiers; parallel execution relationships are represented by array literal syntax; serial execution relationships are represented by tuple literal syntax; and sub-topologies are represented by variable identifiers of topology objects. The data structure literal syntax described in the embodiments of this specification refers to the expression syntax in programming languages ​​that directly constructs data structures without the need for function calls or object instantiation.

[0162] In Python, the literal syntax for data structures is a concise way to create and represent instances of data structures directly in code. For example, lists are defined using square brackets [], with elements separated by commas. Tuples are defined using parentheses (), with elements separated by commas. Sets are defined using curly braces {}, with elements separated by commas. Dictionaries are defined using curly braces {}, but contain key-value pairs, with keys and values ​​separated by colons and key-value pairs separated by commas.

[0163] For example, in Python, `agent` is a variable identifier literal; `[agent1, agent2]` is a list literal (array literal); and `(agent1, agent2)` is a tuple literal. Those skilled in the art will understand that the corresponding literal syntax may differ in other programming languages, but all such variations fall within the scope of this invention.

[0164] Existing multi-agent invocation frameworks, such as LangGraph and AutoGen, require explicit definition of nodes, edges, and state graphs, resulting in verbose code. In LangGraph, a StateGraph must be explicitly created, and `add_node / add_edge` operations must be performed manually. In AutoGen, configuration is done through a GroupChat + Agent list, but the process logic still requires hard-coding. It is evident that while LangGraph and AutoGen use native data structures from programming languages ​​(such as tuples / lists), they do not use the syntax of these native data structures (e.g., whether to use tuples or lists) as a direct carrier of collaborative semantics.

[0165] The embodiments based on this specification actually utilize a set of declarative unified meta-topology definition language (UTDL) to abstract complex collaboration logic into high-order data structures, directly mapping high-level topology structures to collaboration semantics. The system can automatically identify collaboration semantics based on the type of the original data structure (e.g., tuples represent serial execution, lists represent parallel execution), and then automatically deduce execution dependencies.

[0166] In one or more embodiments of this specification, in the step of deriving the execution dependencies between nodes defined by the topology based on the type and nesting relationship of the native data structure, the execution dependencies between agents expressed by the topology description are determined based on a preset mapping rule between the type of the native data structure and the agent collaboration semantics. For example, a list structure is mapped to a parallel execution group, and a tuple structure is mapped to a serial execution chain. The derivation includes determining the serial dependencies and parallel execution relationships between agent nodes based on the order and nesting relationship of elements in the data structure, without requiring the developer to explicitly define an adjacency matrix.

[0167] Traditional multi-agent systems employ an imperative programming paradigm, requiring developers to explicitly write execution details such as state management, flow control, and exception handling, resulting in high development complexity and a high risk of errors. The embodiments in this specification adopt a declarative programming paradigm. Developers only need to describe the collaborative relationships between agents using high-level syntax; the system automatically transforms these declarative descriptions into executable scheduling logic, significantly lowering the development threshold. Developers declare their collaborative intentions using concise syntax, while the system automatically derives and executes detailed control logic through a parsing engine, achieving a "what you think is what you get" multi-agent system development experience.

[0168] In one or more embodiments of this specification, the nodes in the topology include at least one of atomic agent nodes and logical nodes; the logical node is encapsulated by a sub-topology, which contains at least two atomic agent nodes; the logical node and the atomic agent nodes have a unified execution interface. An atomic agent node corresponds to a single agent. A logical node is encapsulated by a defined sub-topology and is used to be referenced as a single node in a higher-level topology.

[0169] In the embodiments described in this specification, the logical node is implemented using the Composite Pattern. Specifically, by recursively encapsulating the composite pattern, the logical node implements the same interface as the atomic agent node, thereby enabling the encapsulation of sub-topology networks of arbitrary complexity into a single logical node, which can then participate as a regular node in higher-level collaborative topology construction. Furthermore, when parsing the sub-topology object, the system can recursively call preset mapping rules to expand the internal structure of the sub-topology object, thus supporting infinite levels of nested collaboration.

[0170] Based on the embodiments of this specification, the unified modeling protocol supports the construction of multiple collaboration paradigms through a single set of syntax and application programming interfaces. These multiple collaboration paradigms may include, but are not limited to, workflow paradigms, handover paradigms, debate paradigms, and team collaboration paradigms. Sub-topologies of different collaboration paradigms are encapsulated as logical nodes and can be mixed and orchestrated and executed collaboratively within the same topology. Based on the embodiments of this specification, an infinite fractal architecture of "Topology as a Node" is implemented through a nested composition pattern, solving the problem of mixed orchestration of collaboration paradigms with different granularities.

[0171] In practical applications, the collaboration paradigm type can be specified in the topology description via the `build_type` parameter. This paradigm type includes workflow, handoff, team, or debate. Developers can switch between different collaboration paradigms (such as ReAct, Plan-Execute, etc.) using simple syntactic sugar without rewriting the entire topology. When tasks need dynamic adjustments, the system can automatically modify the topology without manual intervention from developers.

[0172] In one or more embodiments of this specification, the topology description consists of native data structures of the programming language, including: atomic agent objects representing a single agent, collection-type data structures representing parallel execution groups, sequence-type data structures representing serial execution chains, and container objects representing nested sub-topologies.

[0173] Specifically, the native data structure includes at least one of atomic agent objects, set-type data structures, sequence-type data structures, and sub-topology objects; wherein, the atomic agent object corresponds to an atomic agent node; the sequence-type data structure corresponds to a chain of nodes executed serially; the set-type data structure corresponds to a group of nodes executed in parallel; and the sub-topology object corresponds to a logical node. In other words, the atomic agent object represents an atomic agent node. The sequence-type data structure represents the serial execution relationship of multiple nodes. The node chain includes at least one of atomic agent nodes and logical nodes. The set-type data structure represents the parallel execution relationship of multiple nodes. The node group includes at least one of atomic agent nodes and logical nodes. The sub-topology object represents a sub-topology structure, or a hierarchical topology structure, or a recursively expandable nested cooperative unit.

[0174] Optionally, the sequence-type data structure is a tuple structure in the programming language; the set-type data structure is a list structure in the programming language. In the unified modeling protocol, the atomic agent object (also known as a single agent object) corresponds to an atomic agent node. Thus, when parsing the topology description, the variable identifier representing the atomic agent object can be mapped to the atomic agent node.

[0175] In the unified modeling protocol, the sub-topology object corresponds to a logical node. Thus, when parsing the topology description, the variable identifier representing the sub-topology object can be mapped to a logical node encapsulated by the sub-topology structure constructed by the atomic agent.

[0176] In the unified modeling protocol, the set-type data structure corresponds to a group of nodes that are executed in parallel, thereby mapping the array construction expression to a group of nodes that are executed in parallel. The node group may include atomic agent nodes and / or logical nodes encapsulated by sub-topologies constructed by atomic agents. As an example, the set-type data structure is a list or array in the programming language.

[0177] In the unified modeling protocol, the sequential data structure corresponds to a chain of nodes executed sequentially. Thus, tuple construction expressions can be mapped to chains of nodes executed sequentially. The chain of nodes may include atomic agent nodes and / or logical nodes encapsulated by sub-topologies constructed by atomic agents. As an example, the sequential data structure is a tuple or an ordered list in the programming language.

[0178] For ease of understanding, consider the following examples: The identifier (variable name) `Agent` can represent a single agent node, such as `agent1`. The tuple literal `[Agent, Agent, ...]` can represent a group of agents executing in parallel, such as `[agent1, agent2]`. The list literal `(Agent, Agent, ...)` can represent a chain of agents executing sequentially, such as `(agent1, agent2)`. The identifier (variable name) `Swarm` can represent a nested sub-topology, such as `inner_swarm`.

[0179] In one or more embodiments of this specification, in a chain of nodes executed serially, nodes have serial dependencies; in a group of nodes executed in parallel, nodes have parallel dependencies originating from the same parent node. Specifically, the step of deriving the execution dependencies between nodes defined by the topology based on the type and nesting relationship of the original data structure includes: parsing a sequence-type data structure to construct serial dependency edges for nodes arranged sequentially in the sequence-type data structure; for example, identifying adjacent agent pairs and constructing serial dependency edges. Parsing a set-type data structure to construct parallel dependency edges originating from the same parent node for nodes contained in the set-type data structure; for example, identifying a list of agents, constructing parallel distribution nodes, and broadcasting upstream output to all agents in the list. Based on the parsed sub-topology object, marking the sub-topology object as a logical node. For example, in response to parsing a variable identifier representing a sub-topology, marking it as a subgraph node, and recursively calling the parsing process to load its internal topology structure. Furthermore, when constructing serial dependency edges, a data flow dependency relationship is established between the output of the previous node and the input of the next node; when constructing parallel dependency edges, a data flow dependency relationship is established between the output of the parent node and the input of each parallel node.

[0180] For sequential data structures, the system schedules nodes sequentially, with the output of the previous node serving as the input of the next. For set-based data structures, the system broadcasts the output of upstream nodes to all nodes within the set and aggregates the return results from all nodes. Furthermore, the output results of parallel-executed node groups are automatically aggregated and passed to downstream nodes via a dependency injection mechanism. Further, when the original data structure is a multi-layered nested structure, it is recursively parsed from the outside in, in a depth-first order, constructing execution dependencies layer by layer. Specifically, the task processing method also includes: recursively parsing the internal topology of logical nodes.

[0181] In one or more embodiments of this specification, while achieving isolation of the state space within a subgraph, cross-level context sharing is supported through context configuration parameters (Hyper-parameters), solving the problem of heterogeneous fusion across different levels. Specifically, the topology description includes context configuration parameters for controlling node access to or isolation of the context environment; the recursive parsing of the internal topology structure of the logical node specifically includes: establishing data flow dependencies between the input of the logical node and the output of each parent node according to the context configuration parameters. The context configuration parameters include a context isolation mode or a context penetration mode, used to control whether the sub-topology accesses the state, memory, or toolset of the parent topology. As an example, the recursive parsing supports context isolation and penetration configuration, including: by default, the context state inside the logical node is isolated from the external topology; through context configuration parameters, specified context information can be allowed to penetrate and share between topology levels.

[0182] In one or more embodiments of this specification, deriving the execution dependencies between nodes defined by the topology specifically includes: converting the topology description into an intermediate representation of an abstract syntax tree; traversing the abstract syntax tree to construct the execution dependencies.

[0183] Furthermore, the step of converting the topology description into an intermediate representation of an abstract syntax tree specifically includes: mapping a single agent object to an atomic agent node; mapping a list structure to a parallel execution group; mapping a tuple structure to a serial execution chain; and mapping a sub-topology object to a subgraph placeholder.

[0184] Specifically, firstly, based on preset syntax rules, the collaborative topology description can be parsed into an intermediate structure with semantic tags, where: a single agent object is mapped to an atomic node, a list structure is mapped to a parallel execution group, a tuple structure is mapped to a serial execution chain, and a sub-topology object is mapped to a subgraph placeholder, and the control flow and data flow dependencies between nodes are automatically derived; then, the intermediate structure can be recursively traversed, and each subgraph placeholder can be nested and parsed to encapsulate a sub-topology of arbitrary complexity into a single logical node, and whether to share the execution environment between the sub-topology and the parent topology can be determined according to the context configuration parameters, thereby generating a unified directed execution graph containing multi-level nodes; then, each agent node can be scheduled to execute the target task based on the directed execution graph.

[0185] In practical applications, the topology parsing engine in the system can be used to construct a task scheduling graph from the topology description input by the developer.

[0186] Based on the embodiments in this specification, by using native data structures of programming languages ​​(such as lists, tuples, nested objects, etc.) as the declaration method for multi-agent collaborative topologies, developers can express complex serial, parallel, and nested collaborative logic simply by combining natural and intuitive data structures, without having to learn domain-specific languages ​​or explicitly define node connection relationships. After receiving the topology description, the system can automatically deduce the complete control flow and data flow dependencies based on the type of data structure (such as lists representing parallel groups and tuples representing serial chains) and its nesting level (such as sub-topologies encapsulated as logical nodes), thereby constructing an executable scheduling graph. As a result, not only is semantic alignment and seamless hybrid orchestration of different granularities (single agent and composite sub-topologies) and different collaborative paradigms (such as ReAct, Plan-Execute) achieved under a unified framework, but the development threshold and maintenance cost of multi-agent systems are also significantly reduced. Developers define AI team collaboration processes as if writing ordinary data structures, while the system automatically completes dependency resolution, resource scheduling, and result aggregation, ultimately improving task construction efficiency and system flexibility while ensuring execution correctness.

[0187] To facilitate understanding of the solutions in the embodiments of this application, examples are provided below.

[0188] Example 1: Suppose that the topology description input by the developer includes the following: ReAct paradigm swarm1 = Swarm((agent8, agent9), (agent8, agent10), build_type='handoff') # plan-execute paradigm swarm2 = Swarm((agent11, agent12), (agent11, agent13), build_type='team') # Workflow Paradigm swarm = Swarm( agent1, [(agent2, (agent4, [agent6, agent7])), (agent3, agent5)], swarm1 ) }

[0189] In Example 1, the tuple (agent8, agent9) declares a sequential dependency edge from agent8 to agent9. The tuple (agent8, agent10) declares a sequential dependency edge from agent8 to agent10. The object swarm1=Swarm(..., build_type='handoff') encapsulates the above relationships into a logical node, whose internal collaboration paradigm is handoff.

[0190] The list [(agent2, ...), (agent3, agent5)] declares that the subprocesses represented by the two tuples in the list are executed in parallel, i.e., two branches. The list (agent4, [agent6, agent7]) declares that agent4 is executed first, and its output is used as the input of both agent6 and agent7 (in parallel). Other similar content will not be elaborated.

[0191] Based on the syntax rules, the system will automatically deduce the following execution dependencies.

[0192] Specifically, the control flow dependencies (execution order) are as follows: Main trunk: agent1 → (branch 1 and branch 2 in parallel) → swarm1.

[0193] Branch 1: agent2→agent4→(agent6 and agent7 run in parallel).

[0194] Branch 2: agent3 → agent5.

[0195] Inside Swarm1: agent8 → (agent9 and agent10 run in parallel).

[0196] Data flow dependencies (data transfer) are as follows: Each arrow in the control flow implies a data transfer relationship. For example, the output of agent1 is simultaneously passed to agents2 and 3; the output of agent4 is simultaneously broadcast to agents6 and 7. Specifically, swarm1, as a logical node, receives input from the aggregation or selection of the results of branch 1 and branch 2, and its internal agent8 will receive this input.

[0197] This example demonstrates that by using native data structures from programming languages ​​(such as lists and tuples) as a unified declarative syntax, developers can intuitively describe the collaborative relationships between agents, thus supporting the intuitive representation of directed acyclic graphs and even circular dependency graphs of arbitrary complexity. This design eliminates the need for developers to learn domain-specific languages ​​or manually write complex low-level code for graph construction, edge definition, and state transitions. System construction can be completed simply by defining high-level collaborative intentions, fundamentally reducing the development complexity and technical barriers of multi-agent systems.

[0198] Furthermore, the same declarative syntax (tuples, lists, nested structures) can be instantiated into completely different collaboration paradigms (such as handoff, team) through different `build_type` parameters. The system does not need to modify the topology description; it can produce different collaborative behaviors for the same set of connections (such as subordinate handoff or equal team discussion) simply by changing the scheduling strategy, providing great flexibility for multi-paradigm collaboration.

[0199] Example 2: Suppose that the topology description input by the developer includes the following: ReAct paradigm swarm1 = Swarm((agent8, agent9), (agent8, agent10), build_type='handoff') # plan-execute paradigm swarm2 = Swarm((agent11, agent12), (agent11, agent13), build_type='team') # hybrid swarm swarm3 = Swarm(swarm1, swarm2) swarm = Swarm( agent1, [(agent2, (agent4, [agent6, agent7])),# String parallelism [(agent3, agent5)], # Serial parallelism swarm3 ) }

[0200] In this example 2, swarm1 = Swarm((agent8, agent9), (agent8, agent10),build_type='handoff') defines a subtopology swarm1 containing two edges from agent8 to agent9 and agent10, and specifies that its internal collaboration is in the handoff paradigm.

[0201] `swarm2 = Swarm((agent11, agent12), (agent11, agent13), build_type='team')` defines a sub-topology `swarm2`. Its structure is the same as `swarm1`, but it specifies that it uses a "team" paradigm for collaboration, demonstrating that the same topology can adapt to different paradigms.

[0202] The function `swarm3 = Swarm(swarm1, swarm2)` constructs a new, higher-level topology `swarm3` by using `swarm1` and `swarm2` as logical nodes. This achieves the first level of nesting of the "topology as node" concept.

[0203] The function `swarm = Swarm(agent1, [(...), (...)], swarm3)` constructs the main topology `swarm`, which combines atomic nodes (`agent1`), parallel branches (list structure), and sub-topology logical nodes (`swarm3`), demonstrating a fractal architecture.

[0204] Based on the syntax rules, the system will automatically deduce the following execution dependencies.

[0205] Specifically, the control flow dependencies (execution order) are as follows: 1) Top-level control flow and data flow.

[0206] The macroscopic execution flow of the main swarm topology is: agent1 → parallel branch → swarm3. The output of agent1 will simultaneously serve as the input to both parallel branches. The outputs of the two parallel branches will converge and serve as the input to swarm3.

[0207] 2) Internal dependencies within parallel branches.

[0208] The two parallel branches have different internal structures: Branch 1: agent2 → agent4 → (agent6 and agent7 run in parallel). Branch 2: agent3 → agent5. All arrows simultaneously define data flow dependencies.

[0209] 3) Internal expansion of the subtopology (swarm3).

[0210] As a logical node, swarm3 needs to expand its internal structure during execution, forming a second layer of dependency: swarm1→swarm2 (serial). The input of swarm3 (i.e., the convergence result of the parallel branches of the main topology) will be used as the input of swarm1. The output of swarm1 will be used as the input of swarm2.

[0211] 4) Internal expansion of atomic subtopology (swarm1 / swarm2).

[0212] Ultimately, the system recursively expands to the underlying atomic agents, forming a third layer of dependency: within swarm1 (handoff paradigm): agent8 → (agent9 and agent10 in parallel). within swarm2 (team paradigm): agent11 → (agent12 and agent13 in parallel, but following the interaction logic of team collaboration).

[0213] This example demonstrates that through fractal nesting, developers can manage global complexity with concise local code (e.g., `swarm3 = Swarm(swarm1, swarm2)`), while the system automatically handles recursive unrolling and dependency propagation. `swarm1` and `swarm2` share the same connection topology (A->B, A->C), but are given distinctly different collaboration semantics (handoff vs. team) through the `build_type` parameter, achieving complete decoupling between "structural description" and "collaborative behavior." The entire complex collaboration graph, containing three levels of nesting, mixed serial-parallel processing, and dozens of potential dependency edges, is automatically derived by the system from just a few lines of declarative code at the highest level, without requiring the manual definition of a single edge.

[0214] Example 3: Dynamic addition of intelligent agents swarm.add_agent(agent, new_agent) # Dynamic path modification swarm.add_edge(agent1, agent2) swarm.delete_edge(agent1, agent2) # Dynamic Loop # For example, if the search agent finds the search results insufficient after evaluation, it becomes a loop agent and restarts to re-evaluate the search results. swarm.loop_agent( agent=search_agent, max_run_times=5, loop_point="result_validation", stop_func=is_result_good_enough ) }

[0215] In this example three, The `swarm.add_agent(agent, new_agent)` method adds a new agent node (`new_agent`) to the currently running swarm topology at runtime. This operation inserts `new_agent` after the existing `agent` node. The system automatically reconnects the data stream, so that the output of the current `agent` is passed to `new_agent`, and the output of `new_agent` is then passed to the original subsequent nodes of the current `agent`. In practical applications, this operation can be used to dynamically introduce an "expert" agent to assist when the system finds that the current node's capabilities are insufficient (e.g., lacking a specific tool).

[0216] In `swarm.add_edge(agent1, agent2)`, `dd_edge` can represent adding a directed edge between nodes `agent1` and `agent2`, thereby establishing or changing the control flow and data flow. In `swarm.delete_edge(agent1, agent2)`, `delete_edge` can represent deleting the existing directed edge between nodes `agent1` and `agent2`, severing the original dependency. In practical applications, the aforementioned dynamic path modification operations are used to dynamically replan paths based on intermediate results. For example, if an invalid path is found, the old edge can be deleted and a new edge added, transferring the task flow to another group of agents.

[0217] Dynamic loop operations allow adding a loop execution logic based on validation results to an agent. Here, `agent=search_agent` specifies the agent node to be executed in the loop (e.g., a search agent). `max_run_times=5` sets the maximum number of loop executions (5 times in this case), preventing infinite loops and serving as an important safety boundary. `loop_point="result_validation"` specifies the loop trigger point; the system will automatically insert a "result validation" node after `search_agent` specifically for evaluating output quality. `stop_func=is_result_good_enough` is the conditional function for loop termination. After each loop, the system calls this function (with the latest result) to judge whether the loop is good enough. If it returns `True` (the result is good enough), the loop exits; otherwise, the result is passed back to `search_agent` to start the next round.

[0218] Dynamic loop operations transform the `search_agent` from a one-time execution node into an adaptive loop unit of "execution-verification-re-execution". The system automatically constructs an internal closed loop: `search_agent` → verification node → (`stop_func` judgment) → if the criteria are not met, rollback to `search_agent` to start again. This process is entirely data-driven at runtime, demonstrating the system's self-optimization and debugging capabilities.

[0219] In practical applications, the content of Example 3 above can be automatically generated by the system without user intervention.

[0220] Based on Example 3, the solution based on the embodiments of this specification achieves at least the following: all operations are performed dynamically within the task execution flow without stopping or restarting the entire process; fine-grained modifications to the topology are possible at the node level (adding / deleting agents) and the edge level (adding / deleting dependencies); and the collaborative process possesses autonomous decision-making capabilities based on goal achievement through the injection of business logic (stop_func). This solves the fundamental pain points of traditional static workflow systems: rigidity and inability to handle runtime exceptions or new requirements.

[0221] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0222] Based on the same idea, the embodiments of this specification also provide a system corresponding to the above method.

[0223] Figure 3This is a schematic diagram of the structure of a multi-agent system provided in the embodiments of this specification.

[0224] like Figure 3 As shown, the multi-agent system includes: The scheduling engine 302 is used to acquire the target task and schedule multiple agents to execute the target task according to the first task scheduling graph, thereby generating an execution trajectory.

[0225] An adaptive orchestrator 304 is used to determine whether a preset collaboration anomaly mode occurs based on the execution trajectory; and if the collaboration anomaly mode occurs, the first task scheduling graph is reconstructed into a second task scheduling graph; the reconstruction is used to eliminate the collaboration anomaly mode.

[0226] The scheduling engine 302 is also used to continue executing the target task based on the second task scheduling graph.

[0227] Furthermore, the multi-agent system also includes: Evolution Manager 306 is used to determine the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph based on the execution trajectory; the performance evaluation result is determined based on at least one of task success rate, number of execution steps, resource consumption and result confidence; in response to the performance evaluation result satisfying a preset paradigm switching condition, the first collaboration paradigm is modified to a second collaboration paradigm.

[0228] Furthermore, the evolution manager 306 is also configured to: if the target task or new task is successfully executed based on the third task scheduling graph, and the new task has the same task characteristics as the target task; then store the task characteristics, the topology, and the second collaboration paradigm as a task paradigm template.

[0229] Furthermore, the multi-agent system also includes: The topology parsing engine 308 is used to obtain a topology description, which consists of native data structures of a programming language and is used to declare the topology structure and first cooperation paradigm between nodes in a multi-agent system. Based on the topology description, the engine derives the execution dependencies between nodes defined by the topology structure, which include control flow dependencies and data flow dependencies. The engine then instantiates the execution dependencies into a task scheduling graph.

[0230] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods.

[0231] Figure 4 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a task execution device.

[0232] like Figure 4 As shown, the device may include: Task acquisition module 402 is used to acquire target tasks; Task execution module 404 is used to schedule multiple intelligent agents to execute the target task according to the first task scheduling diagram and generate an execution trajectory; Anomaly identification module 406 is used to determine whether a preset collaboration anomaly mode has occurred based on the execution trajectory; The scheduling graph reconstruction module 408 is used to reconstruct the first task scheduling graph into a second task scheduling graph if the collaboration anomaly mode occurs; the reconstruction is used to eliminate the collaboration anomaly mode. The task execution module 404 is used to continue executing the target task based on the second task scheduling diagram.

[0233] based on Figure 4 The embodiments of this specification also provide some specific implementation schemes of the method, which are described below.

[0234] Optionally, the collaboration anomaly mode includes at least one of the following: Task progress error: The same agent node continuously outputs results with a similarity reaching a preset similarity threshold a predetermined number of times, and the target task is not achieved; Execution quality anomaly: The confidence level of the execution result of any agent node is lower than the preset confidence level threshold; Abnormal behavior: Any agent node issues a request to invoke an unregistered tool; System status abnormality: A preset non-system error has occurred; Task feasibility error: Based on the execution trajectory prediction, the first task scheduling graph cannot complete the target task within the preset constraints.

[0235] Optionally, the scheduling graph reconstruction module 408 is specifically used to call the graph operation application interface to perform at least one of the following reconstruction operations: adding or deleting agent nodes; adding, deleting or modifying task scheduling dependency connections between agent nodes.

[0236] Optionally, the reconstruction operation specifically includes: inserting a verification node after the current execution node in the execution trajectory; and establishing a dependency connection from the verification node to the current execution node to form a cyclic verification path.

[0237] Optionally, the scheduling graph reconstruction module 408, in reconstructing the first task scheduling graph into a second task scheduling graph, specifically includes: pausing the execution of the target task; modifying the first task scheduling graph during the pause; the task execution module 404 is further configured to: resume the execution of the target task from the pause point based on the second task scheduling graph.

[0238] Optionally, the device is further configured to: determine the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph based on the execution trajectory; the performance evaluation result is determined based on at least one of task success rate, number of execution steps, resource consumption and result confidence; and in response to the performance evaluation result satisfying a preset paradigm switching condition, modify the first collaboration paradigm to a second collaboration paradigm.

[0239] Optionally, determining the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph based on the execution trajectory specifically includes: inputting the execution trajectory and the description information of the target task into a pre-trained performance prediction model to obtain the performance evaluation result of the first collaboration paradigm on the target task output by the performance prediction model; wherein, the performance prediction model is a machine learning model trained based on historical task data, used to predict the execution performance of different collaboration paradigms under a given task type; the performance evaluation result includes an evaluation score and paradigm recommendation information, wherein the paradigm recommendation information indicates that the first collaboration paradigm should be replaced by a second collaboration paradigm.

[0240] Optionally, modifying the first collaboration paradigm to a second collaboration paradigm specifically includes: using the second collaboration paradigm to re-instantiate the topology corresponding to the first task scheduling graph to generate a third task scheduling graph.

[0241] Optionally, the device is further configured to: determine whether the target task or the new task has been successfully executed based on the third task scheduling graph; the new task has the same task characteristics as the target task; if so, the task characteristics, the topology, and the second collaboration paradigm are associated and stored as a task paradigm template.

[0242] Optionally, the task paradigm template also stores paradigm evolution information; the paradigm evolution information is used to indicate that the first collaboration paradigm is modified to the second collaboration paradigm.

[0243] Optionally, the apparatus is further configured to: before scheduling multiple agents to execute the target task according to the first task scheduling graph, instantiate a specified topology using a first cooperation paradigm to generate the first task scheduling graph.

[0244] Optionally, the nodes in the topology include at least one of atomic agent nodes and logical nodes; the logical node is encapsulated by a sub-topology, and the sub-topology contains at least two atomic agent nodes; the logical node and the atomic agent node have a unified execution interface.

[0245] Optionally, the step of instantiating the specified topology using the first cooperation paradigm to generate the first task scheduling graph specifically includes: obtaining a topology description; the topology description is composed of native data structures of a programming language, used to declare the topology between nodes in a multi-agent system and the first cooperation paradigm; deriving the execution dependencies between nodes defined by the topology based on the topology description; the execution dependencies include control flow dependencies and data flow dependencies; and instantiating the execution dependencies into a task scheduling graph.

[0246] Optionally, deriving the execution dependencies between nodes defined by the topology structure specifically includes: converting the topology description into an intermediate representation of an abstract syntax tree; traversing the abstract syntax tree to construct the execution dependencies.

[0247] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0248] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0249] The above is an illustrative scheme of a task execution device according to this embodiment. It should be noted that the technical solution of this task execution device and the technical solution of the task execution method described above belong to the same concept. For details not described in detail in the technical solution of the task execution device, please refer to the description of the technical solution of the task execution method described above.

[0250] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0251] Figure 5 A structural block diagram of a computing device provided according to an embodiment of this specification is shown.

[0252] The computing device 500 includes: Memory 510 and processor 520; The memory 510 is used to store computer programs / instructions, and the processor 520 is used to execute the computer programs / instructions, which, when executed by the processor 520, implement the steps of the task execution method.

[0253] Specifically, the components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and the database 550 is used to store data.

[0254] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0255] In one embodiment of this specification, the aforementioned components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0256] Computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). Computing device 500 can also be a mobile or stationary server.

[0257] The steps of the task execution method are implemented when the processor 520 executes the computer instructions.

[0258] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the task execution method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the task execution method described above.

[0259] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the task execution method as described above.

[0260] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the task execution method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the task execution method described above.

[0261] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described task execution method.

[0262] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the task execution method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the task execution method described above.

[0263] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the apparatus and device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The apparatus, device and method provided in the embodiments of this specification are corresponding to each other, and therefore the apparatus and device also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus and device will not be repeated here.

[0264] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0265] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0266] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0267] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0268] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0269] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0270] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0271] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0272] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0273] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0274] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0275] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0276] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0277] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A task execution method for a multi-agent system, comprising: Obtain the target task; Multiple agents are scheduled to execute the target task according to the first task scheduling diagram, and an execution trajectory is generated; Based on the execution trajectory, determine whether a preset collaboration anomaly mode has occurred; If the aforementioned collaboration anomaly occurs, the first task scheduling graph is reconstructed into a second task scheduling graph; the reconstruction is used to eliminate the collaboration anomaly. Based on the second task scheduling graph, continue to execute the target task.

2. The method of claim 1, wherein the collaboration anomaly mode includes at least one of the following: Task progress error: The same agent node continuously outputs results with a similarity reaching a preset similarity threshold a predetermined number of times, and the target task is not achieved; Execution quality anomaly: The confidence level of the execution result of any agent node is lower than the preset confidence level threshold; Abnormal behavior: Any agent node issues a request to invoke an unregistered tool; System status abnormality: A preset non-system error has occurred; Task feasibility error: Based on the execution trajectory prediction, the first task scheduling graph cannot complete the target task within the preset constraints.

3. The method as described in claim 1, wherein reconstructing the first task scheduling graph into a second task scheduling graph specifically includes calling a graph manipulation application programming interface to perform at least one of the following reconstruction operations: Add or delete agent nodes; Add, delete, or modify task scheduling dependency connections between agent nodes.

4. The method as described in claim 3, wherein the reconstruction operation specifically includes: A verification node is inserted after the current execution node in the execution trajectory; Establish a dependency connection from the verification node to the current execution node to form a cyclic verification path.

5. The method as described in claim 1, wherein reconstructing the first task scheduling graph into a second task scheduling graph specifically includes: Pause the execution of the target task; Modifications to the first task scheduling graph were completed during the pause; The step of continuing to execute the target task based on the second task scheduling graph specifically includes: Based on the second task scheduling graph, the execution of the target task is resumed from the pause point.

6. The method of claim 1, further comprising: Based on the execution trajectory, determine the performance evaluation result of the first collaboration paradigm adopted by the first task scheduling graph; The performance evaluation results are determined based on at least one of the following: task success rate, number of execution steps, resource consumption, and result confidence. In response to the performance evaluation results meeting the preset paradigm switching conditions, the first collaboration paradigm is modified to the second collaboration paradigm.

7. The method of claim 6, wherein determining the performance evaluation result of the first collaborative paradigm adopted by the first task scheduling graph based on the execution trajectory specifically includes: The execution trajectory and the description information of the target task are input into a pre-trained performance prediction model to obtain the performance evaluation result of the first collaboration paradigm on the target task output by the performance prediction model. The performance prediction model is a machine learning model trained based on historical task data, used to predict the execution performance of different collaboration paradigms under a given task type. The performance evaluation results include an evaluation score and paradigm recommendation information, wherein the paradigm recommendation information indicates that the first collaboration paradigm should be replaced by the second collaboration paradigm.

8. The method of claim 6, wherein modifying the first collaboration paradigm to a second collaboration paradigm specifically includes: Using the second collaboration paradigm, the topology corresponding to the first task scheduling graph is re-instantiated to generate a third task scheduling graph.

9. The method of claim 8, further comprising: Determine whether the target task or new task has been successfully executed based on the third task scheduling graph; The new task has the same task characteristics as the target task; If so, the task features, the topology, and the second collaboration paradigm are associated and stored as a task paradigm template.

10. The method of claim 9, wherein the task paradigm template further stores paradigm evolution information; the paradigm evolution information is used to indicate that the first collaboration paradigm is modified to the second collaboration paradigm.

11. The method of claim 1, further comprising, before scheduling multiple agents to execute the target task according to the first task scheduling graph: The first collaboration paradigm is used to instantiate the specified topology to generate the first task scheduling graph.

12. The method of claim 11, wherein the nodes in the topology include at least one of atomic agent nodes and logical nodes; the logical node is encapsulated by a sub-topology, the sub-topology containing at least two atomic agent nodes; and the logical node and the atomic agent nodes have a unified execution interface.

13. The method of claim 11, wherein instantiating the specified topology using a first cooperation paradigm to generate the first task scheduling graph specifically includes: Obtain the topology description; the topology description consists of native data structures of the programming language and is used to declare the topology between nodes in the multi-agent system and the first cooperation paradigm. Based on the topology description, deduce the execution dependencies between nodes defined by the topology structure; the execution dependencies include control flow dependencies and data flow dependencies. The execution dependencies are instantiated into a task scheduling graph.

14. The method of claim 13, wherein deriving the execution dependencies between nodes defined by the topology specifically includes: The topological description is converted into an intermediate representation of an abstract syntax tree; Traverse the abstract syntax tree to construct the execution dependencies.

15. A task execution device, comprising: The task acquisition module is used to acquire target tasks; The task execution module is used to schedule multiple agents to execute the target task according to the first task scheduling graph and generate an execution trajectory; An anomaly detection module is used to determine whether a preset collaborative anomaly mode has occurred based on the execution trajectory. The scheduling graph reconstruction module is used to reconstruct the first task scheduling graph into a second task scheduling graph if the collaboration anomaly mode occurs; the reconstruction is used to eliminate the collaboration anomaly mode. The task execution module is used to continue executing the target task based on the second task scheduling graph.

16. A computing device comprising a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor, when executing the computer instructions, implements the steps of the task execution method as claimed in any one of claims 1 to 14.

Images