Service Mesh-Based Multi-Agent Orchestration Methods, Devices, and Storage Media

Abstract

This application provides a multi-agent orchestration method, device, and storage medium based on a service mesh, relating to the field of artificial intelligence technology. The method includes: generating corresponding domain-specific language description information based on workflow information of multiple agents; and generating routing information corresponding to the workflow information of the multiple agents based on the domain-specific language description information, wherein the routing information is used to define the calling relationships of the multiple agents in the service mesh. This solution reduces manual costs and improves orchestration efficiency.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a multi-agent orchestration method, device and storage medium based on service mesh. Background Technology

[0002] With the rapid development of artificial intelligence and large language model technology, multi-agent systems have shown great potential in solving complex problems.

[0003] However, in practical applications, the functions of multiple agents in a multi-agent system often differ. For example, when task A needs to be executed, the staff needs to manually arrange the routing information corresponding to the workflow information of the multiple agents involved in task A. When task B needs to be executed, the staff needs to manually arrange the routing information corresponding to the workflow information of the multiple agents involved in task B. That is, for different tasks, the staff needs to manually arrange the workflow information of the multiple agents involved in the task and the routing information corresponding to the workflow information. This results in high labor costs and low arrangement efficiency. Summary of the Invention

[0004] This application provides a service mesh-based multi-agent orchestration method, device, and storage medium to reduce labor costs and improve orchestration efficiency.

[0005] In a first aspect, embodiments of this application provide a multi-agent orchestration method based on a service mesh, wherein the service mesh is registered with multiple agents, and the method includes:

[0006] Based on the workflow information of the multiple intelligent agents, corresponding domain-specific language description information is generated;

[0007] Based on the domain-specific language description information, routing information corresponding to the workflow information of the multiple intelligent agents is generated. The routing information is used to define the calling relationship of the multiple intelligent agents in the service mesh.

[0008] Secondly, embodiments of this application provide a multi-agent orchestration device based on a service mesh, wherein the service mesh is registered with multiple agents, and the device includes:

[0009] The acquisition module is used to generate corresponding domain-specific language description information based on the workflow information of the multiple intelligent agents;

[0010] The generation module is used to generate routing information corresponding to the workflow information of the multiple intelligent agents based on the domain-specific language description information. The routing information is used to define the calling relationship of the multiple intelligent agents in the service mesh.

[0011] Thirdly, embodiments of this application provide a multi-agent task processing method based on a service mesh, applied to a gateway, wherein the service mesh has multiple registered agents, and the method includes:

[0012] Receive the tasks to be processed corresponding to the plurality of intelligent agents;

[0013] Obtain routing information corresponding to the workflow information of the plurality of intelligent agents, wherein the routing information is used to define the calling relationship of the plurality of intelligent agents in the service mesh, and the routing information is generated according to the multi-agent orchestration method provided in the first aspect;

[0014] The multiple intelligent agents are invoked based on the routing information to execute the task to be processed.

[0015] Fourthly, embodiments of this application provide a multi-agent task processing device based on a service mesh, applied to a gateway, wherein the service mesh has multiple registered agents, and the device includes:

[0016] The receiving module is used to receive the tasks to be processed corresponding to the plurality of intelligent agents;

[0017] The acquisition module is used to acquire routing information corresponding to the workflow information of the multiple agents. The routing information is used to define the calling relationship of the multiple agents in the service mesh. The routing information is generated according to the multi-agent orchestration method provided in the first aspect.

[0018] The invocation module is used to invoke the multiple intelligent agents to execute the task to be processed based on the routing information.

[0019] Fifthly, embodiments of this application provide an electronic device, including: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor performs the method as described in the first or third aspect.

[0020] In a sixth aspect, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the method described in the first or third aspect.

[0021] In a seventh aspect, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, can implement the method described in the first or third aspect.

[0022] In the service mesh-based multi-agent orchestration scheme provided in this application embodiment, domain-specific language description information is generated based on the workflow information of the multiple agents. Based on this domain-specific language description information, routing information corresponding to the workflow information of the multiple agents and used to define the calling relationship of the multiple agents in the service mesh can be automatically generated, saving manual costs and achieving high orchestration efficiency. Attached Figure Description

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

[0024] Figure 1 A flowchart illustrating a service mesh-based multi-agent orchestration method provided in this application embodiment;

[0025] Figure 2 A specific example diagram of a workflow diagram provided in this application embodiment;

[0026] Figure 3 A specific example diagram of domain-specific language description information provided in this application embodiment;

[0027] Figure 4 Another flowchart of a service mesh-based multi-agent orchestration method provided for embodiments of this application;

[0028] Figure 5 This is an application illustration of registering intelligent agents through a gateway, provided in an embodiment of this application.

[0029] Figure 6 Specific example diagrams for generating composite intelligent agents provided in the embodiments of this application;

[0030] Figure 7 A specific example diagram illustrating the collaborative completion of a target task by multiple composite intelligent agents, as provided in the embodiments of this application.

[0031] Figure 8 A flowchart illustrating a service mesh-based multi-agent task processing method provided in this application embodiment;

[0032] Figure 9 This application provides a schematic diagram of a task processing request application based on a first route, as illustrated in an embodiment of the present application.

[0033] Figure 10 This application provides a schematic diagram of a task processing request application based on a second route.

[0034] Figure 11 This application provides an schematic diagram of a service mesh-based multi-agent task processing method according to an embodiment of the present application.

[0035] Figure 12 A schematic diagram of a service mesh-based multi-agent orchestration device provided in this application embodiment;

[0036] Figure 13 A schematic diagram of the structure of a service mesh-based multi-agent task processing device provided in this application embodiment;

[0037] Figure 14 This is a schematic diagram of the structure of an electronic device provided in this embodiment. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. In addition, the timing of the steps in the following method embodiments is only an example and not a strict limitation.

[0039] It should be noted that, in the cases involving user information in the embodiments of this application, 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 the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to large language models or other models) comply with relevant laws and standards.

[0040] Additionally, it should be noted that the specific language generation model, task generation model, and agent determination model involved in the embodiments of this application can be an artificial intelligence-based language model (LM) or multimodal model (MM), etc. The embodiments of this application do not limit the number of model parameters supported by the model, aiming to meet actual needs. If the model has relatively more parameters, the model will be relatively larger in scale and have relatively better performance; however, it will consume more time and resources during inference or training. If the model has relatively fewer parameters, the model will be relatively smaller in scale, and while meeting performance requirements, it will be more lightweight, consuming less time and resources during inference or training. This specific language generation model, task generation model, and agent determination model can be a deep learning model used to process and generate natural language text or multimodal data, and can be implemented based on a neural network architecture, allowing for pre-training on large amounts of data. In one alternative implementation, the specific language generation model, task generation model, and agent determination model may include an encoder, a decoder, a self-attention layer, and a feed-forward neural network. The encoder primarily converts input data (usually in sequence form) into vector representations, capturing the semantic features of the input data. The decoder is responsible for converting the intermediate representations generated by the encoder into output data (usually in sequence form). The self-attention layer is a mechanism that allows the model to focus on other positions in the sequence to better encode information at the current position. The feed-forward neural network can perform nonlinear transformations on the output of the self-attention layer to enhance the model's expressive power. These components work together, enabling the model built upon them to perform well in various complex processing tasks, such as natural language processing, computer vision, speech recognition, machine translation, text summarization, and intelligent question answering.

[0041] The following explains the terms or concepts involved in the embodiments of this application:

[0042] Intelligent agent: refers to an agent that can perceive the environment and take actions to achieve specific goals. It can be software, hardware or a system, and has autonomy, adaptability and interaction capabilities.

[0043] A service mesh is an intelligent infrastructure layer used to handle inter-service communication. In practice, a service mesh is typically implemented using a set of lightweight network proxies deployed alongside the application without being aware of the application itself. In this embodiment, multiple agents act as multiple services, registering themselves with the service mesh to collaboratively complete user-triggered tasks, thus forming a mesh-like structure. The proxy responsible for communication between these agents can be the gateway in this embodiment. The gateway can implement routing forwarding between different agents within the service mesh based on generated routing information (defining the calling relationships between multiple agents in the service mesh). The specific meaning and implementation of a service mesh can be found in existing related technologies and will not be elaborated upon here.

[0044] With the rapid development of artificial intelligence, multi-agent systems have shown great potential in solving complex problems. Currently, for different tasks, staff need to manually arrange the workflow information of multiple agents involved in the task, as well as the corresponding routing information, which is time-consuming, labor-intensive, and inefficient.

[0045] In view of this, embodiments of this application provide a multi-agent orchestration method that solves the above problems through the following approach: obtaining domain-specific language description information corresponding to the workflow information of multiple agents, and then automatically generating routing information corresponding to the workflow information of multiple agents based on the domain-specific language description information. The entire process is automatic and requires no manual intervention, saving labor costs and improving orchestration efficiency.

[0046] Figure 1 A flowchart illustrating a multi-agent orchestration method based on a service mesh, provided in this application embodiment, is shown. The service mesh has multiple registered agents, and the method is applied to a gateway, such as... Figure 1 As shown, the method includes the following steps:

[0047] 101. Based on workflow information from multiple intelligent agents, generate corresponding domain-specific language description information.

[0048] 102. Based on domain-specific language description information, generate routing information corresponding to the workflow information of multiple agents. The routing information is used to define the calling relationship of multiple agents in the service mesh.

[0049] In practical applications, workflow information can be either a workflow diagram formed by operating multiple agents through a user interface, or a workflow description text generated through natural language, in which the workflow description text describes the connection relationships between multiple agents.

[0050] Specifically, on the one hand, when the workflow information is a workflow diagram formed by operating multiple agents through interface operation, domain-specific language description information corresponding to the workflow information of multiple agents can be dynamically generated in the following way: parse the workflow diagram to determine the connection relationship of multiple agents, and generate domain-specific language description information based on the attribute information and connection relationship of multiple agents.

[0051] For easier understanding, please refer to Figure 2 This provides a specific example diagram of a workflow diagram. Figure 2 The system includes the following intelligent agents:

[0052] Coordinator Agent: Used to interact with users and coordinate and manage the work of other agents based on the results of the interaction, such as Data Collection Agent, Analysis Agent, Specialized Planning Agent, Visualization Agent, Critique Agent, and Refinement Agent.

[0053] Specifically, the data collection agent is used to collect data, and it is associated with multiple parallel agents, such as the Population Agent, Economic Agent, Environmental Agent, and Traffic Agent. The Population Agent collects population data, the Economic Agent collects economic data, the Environmental Agent collects environmental data, and the Traffic Agent collects traffic data.

[0054] The analytical agent is used to analyze the data to be processed issued by the coordinating agent or the data output by the data collection agent. It is associated with multiple agents that execute sequentially (also known as serially), such as the data preprocessing agent, the trend designer, and the prediction modeler. The data preprocessing agent preprocesses the raw data (e.g., data cleaning, deduplication), the trend designer analyzes the trend of a specific data point in the next time period (e.g., analyzing the company's net profit trend for the next fiscal year), and the prediction modeler analyzes the data from a holistic perspective, such as predicting trends in overall data including population, economy, environment, and transportation.

[0055] Specialized planning agents are used in specialized domains to perform corresponding design and planning based on the data to be processed issued by the coordinating agent or the analysis results of the analysis agent. Multiple parallel agents are associated with each agent, such as the Land Use Agent, Transportation Agent, Public Facilities Agent, and Environmental Protection Agent. Specifically, the Land Use Agent performs design and planning based on the data to be processed in the land domain; the Transportation Agent performs design and planning based on the data to be processed in the transportation domain; the Public Facilities Agent performs design and planning based on the data to be processed in the public facilities domain; and the Environmental Protection Agent performs design and planning based on the data to be processed in the environmental protection domain.

[0056] Visual agents are used to convert the data to be processed issued by the coordinator agent or the output of the professional planning agent into visual results, such as 3D models and charts.

[0057] The solution review agent is used to review the solutions to be processed issued by the coordinator agent or the output results of the visualization agent, and output the review results.

[0058] The iterative optimization agent is used to iteratively optimize the review results output by the solution review agent or the solutions issued by the coordinator agent, and output an optimized solution. In practical applications, if it is confirmed that no further optimization is needed after obtaining the optimized solution, then the solution is taken as the final solution. If it is confirmed that further optimization is needed after obtaining the optimized solution, then the solution is input again into the solution review agent and the iterative optimization agent for iterative optimization until the solution no longer needs further optimization.

[0059] In practice, it can be done on the visual interface. Figure 2 The multiple intelligent agents are shown to perform drag-and-drop, click, and other operations to form a workflow diagram.

[0060] As one implementation approach, it is assumed that multiple functional module icons with agent names have been pre-configured on the visual interface. In practical applications, simply drag and drop the multiple agent functional module icons to the designated positions according to the names of the multiple agents, and then connect the multiple agents with arrow lines based on the relationships between the agents (such as parallel relationships, serial relationships, etc.) and the working order to obtain the workflow diagram.

[0061] As another implementation method, assume that a workflow diagram template has been configured on the visualization interface. This workflow diagram template contains multiple empty areas for placing functional module icons, as well as connecting lines with arrows that connect multiple empty areas. The workflow diagram template also contains multiple functional module icon options with agent names. When you need to fill a certain empty area, you only need to click on the empty area and then click on the functional module icon you want to fill in the empty area. When all the empty areas are filled, you get the final workflow diagram.

[0062] After obtaining the workflow diagram, a rule engine can parse it to determine the connections between multiple agents. For example, it can determine the connections between the coordinator agent and agents such as the data collection agent, analysis agent, professional planning agent, and visualization agent, among others. Then, domain-specific language (DSL) descriptions are automatically generated based on the attribute information and connections between the agents. The rule engine can be located inside or outside the gateway; this is not limited here. The DSL descriptions refer to the attribute information and connections between multiple agents described using a computer language focused on a specific application domain (i.e., a domain-specific language, DSL).

[0063] It should be noted that the attribute information of multiple agents refers to the attribute information carried by each agent itself, which can be directly obtained by default during the operation of multiple agents. Taking the coordinator agent as an example, its attribute information may include "type: LLMAgent, indicating an agent with built-in or connected large language model services", "role: city planner", etc. Based on the above... Figure 2It is known that the coordinator agent has connections with the data collection agent, analysis agent, professional planning agent, visualization agent, solution review agent, and iterative optimization agent. Therefore, based on this attribute information and connections, domain-specific language description information can be generated. A specific example of this domain-specific language description information is as follows:

[0064] Coordinator Agent

[0065] type: LLMAgent

[0066] role: Urban Planner

[0067] SubAgent:

[0068] -Data Collection Agent

[0069] -Analysis Agent

[0070] -Specialized Planning Agent

[0071] -Visualization Agent

[0072] -Critique Agent

[0073] -Refinement Agent”

[0074] Here, SubAgent refers to multiple sub-agents (data collection agent, analysis agent, professional planning agent, visualization agent, solution review agent, and iterative optimization agent) that have a connection relationship with the Coordinator Agent. Furthermore, it should be noted that, for ease of understanding, only a partial example of the domain-specific language descriptions above is provided; for complete examples, please refer to [link to documentation / reference]. Figure 3 .exist Figure 3 middle, Figure 3 It shows Figure 2 The attribute information corresponding to all agents (where "HierarchicalAgent" represents a hierarchical agent, "ParallelAgent" represents a parallel processing agent, and "SequentialAgent" represents a sequential processing agent), and Figure 3 The workflow section describes the logical relationships between the agents, which are already described in the description. Figure 2 The details were explained in detail at the time, and will not be repeated here.

[0075] The workflow diagram is created through drag-and-drop and click operations on a visual interface, which is simple and efficient. In subsequent practical applications, the connection relationships between multiple agents can be determined simply by parsing the workflow diagram. Then, domain-specific language description information is automatically generated based on the attribute information of multiple agents and their connection relationships, thus improving the generation speed of domain-specific language description information.

[0076] On the other hand, when the workflow information is a workflow description text generated through natural language description, and the workflow description text describes the connection relationship of multiple agents, the corresponding domain-specific language description information is generated based on the workflow information of multiple agents, including: inputting the workflow description text and the attribute information of multiple agents into a specific language generation model, so as to generate domain-specific language description information through the specific language generation model.

[0077] In practical applications, workflow information can be workflow description text generated by users through natural language descriptions. For ease of understanding, we will continue with... Figure 2 Taking the workflow described in [the document] as an example, the workflow description text can be illustrated as follows: First, the population data collection agent and the economic data collection agent run in parallel to collect population data and economic data. Then, the collected population data and economic data are sent to the analysis agent for data analysis. Here, the data collection agent and the analysis agent run in parallel, and the data collection agent is at least associated with the population data collection agent and the economic data collection agent, etc. Descriptions of other agents are not listed here.

[0078] In practice, the workflow description text and attribute information of multiple agents are input into a specific language generation model. This generates a domain-specific language description based on the agent attributes and their connections. Then, a rules engine performs security and compliance checks, such as syntax validation, on the generated domain-specific language description to ensure it meets requirements, resulting in the final domain-specific language description. The rules engine can be located either inside or outside the gateway; this is not limited here.

[0079] By inputting workflow description text generated using natural language and attribute information of multiple agents into a specific language generation model, domain-specific language description information is obtained, reducing the difficulty of obtaining domain-specific language description information (users only need to use natural language to make relevant descriptions, without needing to understand the specific writing method of domain-specific language). Furthermore, the domain-specific language description information is automatically generated by the specific language generation model, ensuring the accuracy and efficiency of obtaining domain-specific language description information.

[0080] It should be noted that in the two processes of dynamically generating domain-specific language (DNS) description information described above, the orchestration of some agents may differ in different application scenarios. If some orchestrated agents change under the set application scenario, causing changes in the workflow information, the corresponding DNS description information will be triggered to change accordingly, resulting in changes to the routing information subsequently generated based on the DNS description information. In other words, as users dynamically update or modify the workflow information, the corresponding DNS description information will also be dynamically updated, thereby dynamically updating the corresponding routing information.

[0081] Furthermore, after obtaining the domain-specific language description information, routing information corresponding to the workflow information of multiple intelligent agents can be generated based on the domain-specific language description information. Generating routing information corresponding to the workflow information of multiple intelligent agents can include the following steps: generating first routing information for accessing at least one main intelligent agent based on the connection relationships between different main intelligent agents contained in the workflow information; and generating second routing information for accessing each of the at least one main intelligent agent's associated sub-intelligent agents based on the sub-intelligent agents associated with each main intelligent agent.

[0082] In practical applications, multiple agents can include at least one master agent and at least one sub-agent associated with the master agent, continuing in... Figure 2 For example, the main intelligent agent can be a data collection agent, an analysis agent, a professional planning agent, a visualization agent, a solution review agent, and an iterative optimization agent. Taking the data collection agent as an example, its associated sub-agents include: population data collection agent, economic data collection agent, environmental data collection agent, and transportation data collection agent. For details on the sub-agents associated with other main intelligent agents, please refer to [link to relevant documentation]. Figure 2 They are not listed here one by one.

[0083] Understandably, if access to a particular agent is required, the routing information for that agent must first be determined. In practice, based on the connection relationships between different primary agents contained in the workflow information, first routing information for accessing at least one primary agent can be generated. For example, assuming the workflow information includes a data collection agent and an analysis agent connected sequentially, the generated first routing information could take the following form:

[0084] "route":

[0085] - Match:

[0086] -Prefix: Data Collection

[0087] Service:

[0088] -Target (match):

[0089] - Host: Data Collection Agent

[0090] - Match:

[0091] - prefix: Analysis

[0092] Service:

[0093] -Target (match):

[0094] - Host: Analysis Agent

[0095] In practical applications, if the access request contains the prefix "Data Collection", it will be routed to the Data Collection Agent based on the prefix and the first routing information mentioned above. If the access request contains the prefix "Analysis", it will be routed to the Analysis Agent based on the prefix and the first routing information mentioned above.

[0096] Furthermore, based on the child agents associated with each main agent, second routing information can be generated for accessing at least one of the child agents associated with each main agent. Taking a data collection agent as an example, its associated child agents include: a Population Agent, an Economic Agent, an Environmental Agent, and a Traffic Agent. The second routing information generated based on these child agents can then take the following form:

[0097] "next forward filter (routing decision filter, used to determine the next hop target for a request based on the response of the previous service):"

[0098] format_endpoint_list (list of routable endpoints):

[0099] PopulationAgent.svc (The address of the population data collection agent)

[0100] EconomicAgent.svc (the address of the economic data collection agent)

[0101] EnvironmentAgent.svc (the address of the environmental data collection agent)

[0102] TrafficAgent.svc (The address corresponding to the traffic data collection agent)

[0103] phase: after_response (Execution phase: after the response)

[0104] format_code (redirection status code): 301

[0105] format_endpoint (route target): {{ response.body.next}} (The response contains the address of the agent for the next hop)

[0106] format_type (request processing mode): pass_through (pass-through mode)

[0107] In practical applications, assuming the data collection agent is accessed through the first routing information, the data collection agent will return a response to the gateway (i.e., the response mentioned above). By parsing the "body" in the response, the address of the next-hop agent can be obtained. For example, if parsing the "body" yields "next: PopulationAgent.svc", it means the address of the next-hop agent is PopulationAgent.svc. In this case, the population data collection agent can be accessed directly based on this agent address.

[0108] By generating first routing information for accessing at least one main agent based on the connection relationships between different main agents contained in the workflow information, the workflow between main agents can be controlled by the first routing information, ensuring the stability of the core process. Furthermore, by generating second routing information for accessing at least one child agent associated with each main agent, based on the child agents associated with each main agent, calls to child agents under a main agent can be implemented, satisfying the requirement of local modification (when it is necessary to modify the call of a child agent associated with a main agent, it will not affect the collaboration between other main agents). Moreover, by generating the first and second routing information, the "routing between main agents" and "routing between child agents" are decoupled, making the overall routing architecture clearer and the division of labor more explicit.

[0109] Based on the above, the multi-agent orchestration method provided in this application embodiment can automatically generate routing information corresponding to workflow information, saving labor costs and improving orchestration efficiency.

[0110] Figure 4 Another flowchart of a service mesh-based multi-agent orchestration method provided in this application embodiment is shown below. Figure 4 As shown, the method includes the following steps:

[0111] 401. Input the description information of the target task, the attribute information of multiple agents and the composite agent orchestration template information into the task generation model, so as to generate a composite agent corresponding to the target task through the task generation model. The composite agent includes the target master agent and the sub-agents associated with the target master agent. The target master agent is one of at least one master agent. The agents contained in the composite agent are used to cooperate to complete the target task, which is one of multiple tasks.

[0112] 402. Output the composite agents corresponding to each of the multiple tasks so that users can generate workflow information based on the composite agents corresponding to each of the multiple tasks. The workflow information reflects the structure of the composite agents corresponding to each of the multiple tasks and the connection relationship of the main agents in different composite agents.

[0113] 403. Obtain domain-specific language description information corresponding to the workflow information of multiple intelligent agents.

[0114] 404. Based on domain-specific language description information, generate routing information corresponding to the workflow information of multiple intelligent agents.

[0115] In practical applications, before orchestrating multiple agents, they need to be registered in the gateway. The specific steps are as follows: Receive an agent registration request and register the target agent based on the attribute information of the target agent contained in the registration request. The target agent can be any one of the multiple agents.

[0116] In practice, users initiate an agent registration request for a target agent through the Application Programming Interface (API) provided by the gateway. This registration request includes attribute information such as the target agent's type, role, and the address of its host. Upon receiving the registration request, the gateway initiates a verification process. This includes verifying whether the target agent's input and output formats conform to the domain-specific language specifications, or verifying the compatibility between the current and previous versions of the target agent to meet the established verification requirements. This ensures that the target agent to be registered adheres to the technical specifications and security standards set for registration.

[0117] After successful verification, the gateway will assign a unique identifier to the target agent and store the identifier and the target agent's complete information (such as attribute information, function description, version number, etc.) in the designated agent service registry. At the same time, it will update the routing information used to store the agent and its corresponding routing address to ensure that when there are external requests that need to use the target agent, they can be accurately and efficiently forwarded to the target agent through the identifier.

[0118] After the target agent successfully registers, the gateway triggers a system-level discovery event. This event includes at least the target agent's identifier, attribute information, functional description, and version number. The gateway can then send this event to relevant components such as the load balancer and monitoring system via the internal message bus or by calling their APIs. These components then perform health checks on the target agent (e.g., checking every 5 seconds, marking it as unhealthy after two consecutive failures), formulate traffic allocation strategies (e.g., initially allocating 30% of the traffic, increasing by 10% every hour), and add the target agent to the monitoring targets, thus integrating it into the agent pool used to store agents.

[0119] After publishing the aforementioned discovery event, the gateway will generate a detailed confirmation message and return it to the user who initiated the agent registration request. This confirmation message includes: a unique identifier for the target agent and access credentials (such as keywords, tokens, etc., used for authentication when subsequently calling the gateway or other services).

[0120] Figure 5 This is a schematic diagram illustrating an application of registering intelligent agents via a gateway, as provided in an embodiment of this application. Figure 5 In the gateway, multiple sub-agents are registered, including: Population Agent, Economic Agent, Environmental Agent, Traffic Agent, Data Preprocessor, Trend Designer, Prediction Modeler, Land Use Agent, Transportation Agent, Public Facilities Agent, and Environmental Protection Agent. The target agent can be one of these.

[0121] By receiving agent registration requests and registering target agents based on the attribute information of the target agents contained in the registration requests, new agents are continuously integrated into the system, achieving plug-and-play functionality and being ready to receive and process various complex tasks at any time.

[0122] After registering multiple agents using the above method, the description information of the target task, the attribute information of the multiple agents, and the composite agent orchestration template information can be input into the task generation model. The task generation model will then generate the composite agent corresponding to the target task. For details, please refer to [link to relevant documentation]. Figure 6 .

[0123] exist Figure 6 The system comprises a gateway (including a first plugin, also known as the Direct Proxy plugin, and a second plugin, also known as the Agent Route Plugin; the Direct Proxy represents direct proxying, used to forward requests between agents, while the Agent Route Plugin integrates LLM decision-making capabilities, enabling dynamic selection of sub-agents based on context), an LLM Service (i.e., the aforementioned task generation model), and three composite agents generated based on the task generation model: "A first composite agent consisting of a Data Collection Agent and its associated Population Data Collection Agent, Economic Data Collection Agent, Environmental Data Collection Agent, and Traffic Data Collection Agent"; "A second composite agent consisting of an Analysis Agent and its associated Data Preprocessor, Trend Designer, and PredictionModeler"; and "A Specialized Planning Agent and its associated Land Use Agent." The third composite intelligent agent is composed of the Agent, Transportation Agent, Public Facilities Agent, and Environmental Protection Agent.

[0124] In practical applications, each main agent (Data Collection Agent, Analysis Agent, Specialized Planning Agent) sends a target task request to the gateway. This request includes a description of the target task, attribute information of multiple agents, and a composite agent orchestration template. The target task description could be something like "analyze the population change trend in city A" or "conduct artificial and economic statistics for city A," among others. The composite agent orchestration template contains the logical relationships between the agents, such as whether they operate in parallel or sequentially, which agents are main agents, which are sub-agents, and the connections between main and sub-agents.

[0125] After receiving the description information of the target task, the attribute information of multiple agents, and the composite agent orchestration template information, the gateway sends this information to the task generation model. It also receives the selected sub-agents corresponding to the main agent from the task generation model, and identifies the main agent and its corresponding sub-agents as the composite agent. For example, if the description information of the target task input to the task generation model is "Analyze the population change trend of city A," then the composite agent generated from the target task description information may include: the main agent "AnalysisAgent," and the sub-agents associated with this main agent, "Data Preprocessor" and "Trend Analysis Agent." Conversely, if the description information of the target task input to the task generation model is "Conduct manual and economic statistics for city A," then the composite agent generated from the target task description information may include: the main agent "Data Collection Agent," and the sub-agents associated with this main agent, "Population Data Collection Agent" and "Economic Data Collection Agent."

[0126] After obtaining the composite agents corresponding to each of the multiple tasks generated by the task generation model, the user can generate workflow information based on these composite agents. The task generation model can be built into the gateway or invoked externally; this is not limited here.

[0127] Based on the above, by using a task generation model to generate multiple composite intelligent agents corresponding to each task, it becomes simpler and faster for users to orchestrate workflow information, improving the user's orchestration experience and further enhancing orchestration efficiency.

[0128] During this process, users can arrange workflow information using either the interface operation method or by generating workflow description text through natural language. A specific example diagram illustrating the collaborative work of multiple intelligent agents to complete the target task after arrangement can be found here. Figure 7 .exist Figure 7 The system comprises multiple main agents and three composite agents. The main agents include: Coordinator Agent, Visualization Agent, Critique Agent, and Refinement Agent. The three composite intelligent agents include: "the first composite intelligent agent consisting of the Data Collection Agent and its associated Population Data Collection Agent, Economic Data Collection Agent, Environmental Data Collection Agent, and Traffic Data Collection Agent"; "the second composite intelligent agent consisting of the Analysis Agent and its associated Data Preprocessor, Trend Designer, and Prediction Modeler"; and "the third composite intelligent agent consisting of the Specialized Planning Agent and its associated Land Use Agent, Transportation Agent, Public Facilities Agent, and Environmental Protection Agent".

[0129] In practice, the coordinator agent receives a target task request from the user and, based on this request, allocates a first composite agent to collect relevant data. The first composite agent then sends the collected data to a second composite agent for analysis, and sends the analysis results to a third composite agent. The third composite agent then proposes a processing solution based on the analysis results and sends it to an iterative optimization agent for further optimization. Finally, the iterative optimization agent sends the optimized solution to a visualization agent for visual presentation, and an approval agent reviews the visualization. Once approved, the approved content is sent to the user.

[0130] Figure 8 This application provides a flowchart of a multi-agent task processing method based on a service mesh, where multiple agents are registered in the service mesh. This method is applied to a gateway, such as... Figure 8 As shown, the method includes the following steps:

[0131] 801. Receive tasks to be processed corresponding to multiple intelligent agents.

[0132] 802. Obtain routing information corresponding to the workflow information of multiple agents. The routing information is used to define the calling relationship of multiple agents in the service mesh. The routing information is generated according to the multi-agent orchestration method described above.

[0133] 803. Based on the routing information, call multiple agents to execute the tasks to be processed.

[0134] It is understandable that since the multi-agent orchestration method provided in the above embodiments can improve orchestration efficiency, in practical applications, when a user sends a task to be processed corresponding to multiple agents, the routing information generated by the multi-agent orchestration method provided in the above embodiments is used to call multiple agents to execute the task to be processed, and no manual intervention is required, resulting in high task processing efficiency.

[0135] In practical applications, multiple intelligent agents include at least one master intelligent agent and at least one sub-intelligent agent associated with each master intelligent agent. The routing information includes first routing information for accessing at least one master intelligent agent and second routing information for accessing at least one sub-intelligent agent associated with each master intelligent agent.

[0136] In specific implementation, after receiving a user-issued task corresponding to multiple intelligent agents (such as "analyzing the population change trend of city A" or "conducting manual and economic statistics on city A"), multiple intelligent agents can be invoked to execute the task based on the routing information obtained in the above embodiment. The specific process is as follows: In response to receiving a first task processing request to access the first intelligent agent as the master intelligent agent, the first task processing request is sent to the first intelligent agent according to the first routing information corresponding to the first intelligent agent; a second task processing request is received from the feedback of the first intelligent agent; a second intelligent agent is determined from the sub-intelligent agents associated with the first intelligent agent to handle the second task processing request; and a second task processing request is sent to the second intelligent agent according to the second routing information corresponding to the second intelligent agent.

[0137] It should be noted that all or some of the intelligent agents in a group of intelligent agents can have multiple versions, and traffic forwarding rules or traffic forwarding conditions corresponding to each version can be configured in the gateway.

[0138] The traffic forwarding rules can be manually pre-written into the gateway or automatically defined by the gateway.

[0139] For example, it can be manually determined that requests to access a certain agent during a certain time period are sent to the first version of that agent, while requests to access the agent during another time period are sent to another version of that agent. Another example is that it can be manually configured to send requests where a certain field has the value of the first field to the first version of that agent, while requests where that field has the value of the second field are sent to another version of that agent.

[0140] Furthermore, taking an initial version of an agent as V0 as an example, the gateway can use analysis tools such as large models to analyze the values ​​of certain fields in the network traffic sent to this version of the agent, i.e., the requests. This determines the type of network traffic (e.g., traffic with a field value of 'a' is considered one type), and establishes a correspondence between this type and the agent's V0 version as the traffic forwarding rule for that V0 version of the agent. After the agent is upgraded to version V1, if a request to access the agent carries a field value of 'a', it is determined that access should be made to version V0; otherwise, access should be made to version V1. Similarly, traffic forwarding rules can be established for version V1 of the agent.

[0141] One of the aforementioned fields can serve as a feature identifier in the request. The meaning of this field could be, for example, the request source address, user identifier, task type, etc.

[0142] Based on this, when the gateway receives a third task processing request to access the target agent, it determines the target agent of the target version from multiple versions corresponding to the target agent based on the feature identifier carried in the third task processing request, and then sends the third task processing request to the target agent of the target version based on the generated routing information. The target agent is any one of the multiple agents.

[0143] To facilitate understanding, the following will be combined with... Figure 9 and Figure 10 The process for handling task processing requests is explained in detail below:

[0144] Figure 9 This describes the process of sending task processing requests based on the first routing information. Figure 9 In the process, the user sends a first task processing request (Request) to the main intelligent agent A (i.e., PAgent-A), which includes:

[0145] "path (path: / A);"

[0146] next: PAgent-B (meaning that after PAgent-A has finished processing the first task request, the request needs to be redirected to the main agent B, i.e., PAgent-B).

[0147] Content: {......}

[0148] After receiving the first task processing request, the primary agent A processes it. Upon completion, it sends a redirect request to the gateway, containing the message: "Path changed to ' / B', content is the processed data." Upon receiving this redirect request, the gateway, using its A2A (Agent-to-Agent) Client Proxy plugin, forwards the redirect request to the primary agent B, enabling agent B to process the redirected first task processing request and complete subsequent tasks.

[0149] Among them, the A2A Client Proxy is an intelligent proxy component specifically designed for multi-agent systems. It is embedded in the service mesh to handle communication between agents. In this embodiment, it can perform routing based on the preset routing rules and domain-specific language description information in the gateway.

[0150] In practice, domain-specific language descriptions can be obtained based on workflow information, and then a translation engine can translate these descriptions into routing rules that the gateway can recognize, for the gateway to use. For example, the routing rule could be:

[0151] "PAgent-A: Matches path " / A";

[0152] PAgent-B: Matches the path " / B";

[0153] SubAgent-A1: Matches the path " / A" and the value of the request header "headersub" is "a1";

[0154] SubAgent-A2: Matches the path " / A" and the value of the request header "headersub" is "a2".

[0155] It should be noted that the above routing rules are implemented by Istio's VirtualService. Istio is a service mesh, and VirtualService is an important resource object in Istio used to define routing rules. It specifies how to route requests to services within the service mesh. For example, requests can be routed to different service versions or different services based on the request path, request headers, etc. In the current scenario, VirtualService is used to implement routing control between PAgentA and PAgentB. For example, when the task request path is " / A", it is routed to PAgent-A; when the task request path is " / B", it is routed to PAgent-B. PAgent-B is the first agent mentioned above.

[0156] Figure 10 This refers to the process of sending task processing requests based on the second routing information. Figure 10 In the process, the main agent C receives a second task processing request from the first agent, which includes:

[0157] "Path (path: / LLM-service);"

[0158] Content: {......}

[0159] After receiving the second task processing request, the main agent C processes it. Upon completion, it sends the processed second task processing request to the Large Language Model Service (LLM-service) via the gateway's Transport Proxy, so that the LLM-service can respond. The response information may include:

[0160] "path (path: / C);"

[0161] next: SubAgent-C1 (meaning the next hop is subAgent C1);

[0162] Content: {......}

[0163] Here, "Transport Proxy" refers to the component in the gateway responsible for network transport proxying. Specifically, it is a network transport layer proxy that handles requests and responses, responsible for forwarding requests from the user to the correct target service (such as an agent) and returning the response to the user. The LLM-service can determine the agent model. In practice, the second task processing request is sent to the agent determination model, which, combined with the attribute information of the child agents associated with the main agent C, determines the second agent (i.e., child agent C1) to handle the second task processing request. It is understandable that when selecting which child agent to execute the second task processing request through the LLM-service, the selection result will dynamically change depending on the second task processing request; that is, the use of routing information corresponding to the child agents under the main agent is dynamic.

[0164] By using an agent determination model, a second agent is determined from the sub-agents associated with the first agent to handle the second task processing request. This improves work efficiency while ensuring the accuracy of the determined second agent.

[0165] Upon receiving the response information, the gateway determines that the second task processing request needs to be redirected to sub-agent C1. At this point, the gateway uses its A2A (Agent-to-Agent) Client Proxy plugin to send the redirection request to sub-agent C1, enabling C1 to process the redirected second task processing request and complete the subsequent task. This redirection request includes: "path changed to " / C"; request header headersub=a1; content is the processed data".

[0166] In practice, domain-specific language descriptions can be obtained based on workflow information, and then a translation engine can translate these descriptions into routing rules that the gateway can recognize, for the gateway to use. For example, the routing rule could be:

[0167] "PAgent-C: Matches path " / C";

[0168] SubAgent-C1: Matches the path " / C" and the value of the request header "headersub" is "c1".

[0169] Based on the above, by using the two-layer routing mechanism (i.e., selecting the main agent through the first routing information and selecting the sub-agent through the second routing information), highly flexible and intelligent request distribution is achieved. This two-layer structure not only ensures the stability of the overall architecture, but also provides fine-grained dynamic adaptability.

[0170] To facilitate understanding, the following will be combined with... Figure 11 A specific example is provided to illustrate this solution:

[0171] exist Figure 11 The document contains the following parts:

[0172] 1. Console: This console is used to interact with users. Users can add multiple agents and arrange their order to form workflow information by dragging, clicking, or using natural language input.

[0173] II. The rules engine receives workflow information sent from the console and converts it into domain-specific language description information. This domain-specific language description information may include the following:

[0174] Coordinator Agent

[0175] type: LLMAgent

[0176] role: Urban Planner

[0177] SubAgent:

[0178] -Data Collection Agent

[0179] -Analysis Agent

[0180] -Specialized Planning Agent

[0181] -Visualization Agent

[0182] -Critique Agent

[0183] -Refinement Agent

[0184] Data Collection Agent

[0185] type: ParallelAgent

[0186] Role: Data Collector

[0187] SubAgent:

[0188] -PopulationAgent

[0189] -EconomicAgent

[0190] -EnvironmentAgent

[0191] TrafficAgent

[0192] AnalysisAgent

[0193] type: SequentialAgent

[0194] role: Data Analyst

[0195] SubAgent:

[0196] DataPreprocessor

[0197] -TrendAnalyzer

[0198] -PredictionModeler

[0199] III. The gateway's control plane receives domain-specific language description information sent by the rule engine, and based on this information, generates first and second routing information corresponding to the workflow information of multiple agents. It then converts this first and second routing information into a language understandable by the gateway's data plane and sends it to the data plane. The first routing information includes:

[0200] "route":

[0201] - Match:

[0202] -Prefix: Data Collection

[0203] Service:

[0204] -Target (match):

[0205] - Host: Data Collection Agent

[0206] - Match:

[0207] - prefix: Analysis

[0208] Service:

[0209] -Target (match):

[0210] - Host: Analysis Agent

[0211] The second routing information includes:

[0212] "next forward filter (routing decision filter, used to determine the next hop target for a request based on the response of the previous service):"

[0213] format_endpoint_list (list of routable endpoints):

[0214] PopulationAgent.svc (The address of the population data collection agent)

[0215] EconomicAgent.svc (the address of the economic data collection agent)

[0216] EnvironmentAgent.svc (the address of the environmental data collection agent)

[0217] TrafficAgent.svc (The address corresponding to the traffic data collection agent)

[0218] phase: after_response (Execution phase: after the response)

[0219] format_code (redirection status code): 301

[0220] format_endpoint (route target): {{ response.body.next}} (The response contains the address of the agent for the next hop)

[0221] format_type (request processing mode): pass_through (pass-through mode)

[0222] IV. Gateway Data Plane:

[0223] Suppose the traffic hijacking module intercepts the task request "example.com / data-collector", which includes the following information: host: example.com, prefix: data-collector. At this point, the first route matching is performed. Specifically, based on the prefix "data-collector", it can be determined that the request needs to access the host address link, thus redirecting the user to the Data Collection Agent.

[0224] As one implementation, after processing the task request, the Data Collection Agent will respond, receiving response information including: "body: next: PopulationAgent.svc". Here, "body" refers to the HTTP request body, the core data carrier of the HTTP request. By parsing the body, the next hop can be determined as the PopulationAgent. At this point, the PopulationAgent can be directly invoked.

[0225] As another implementation, the Data Collection Agent processes the task request and then responds, determining the model (i.e., ...) through the agent. Figure 11 The LLM driver in the code, based on the response information and the attribute information of multiple agents in the parent agent cluster and sub-agent cluster, determines the next hop as PopulationAgent, and returns the next hop to the traffic hijacking module. The traffic hijacking module then sends the task request to PopulationAgent. Figure 11 For a detailed description of the agents in each agent cluster, please refer to the above embodiments, which will not be repeated here.

[0226] In summary, the embodiments of this application have at least the following beneficial effects:

[0227] 1. Low cost and high flexibility: When user needs change, the functionality of the intelligent agent may need to be modified, leading to changes in workflow information. These changes are reflected in modifications to the domain-specific language description information. In short, when users need to adjust the functionality of the intelligent agent or workflow information, they only need to adjust the domain-specific language description information using natural language, without modifying the underlying code of the intelligent agent, resulting in low cost. This modification method can quickly adapt to new needs and scenarios, greatly improving the system's adaptability and maintainability. Furthermore, by adjusting the domain-specific language description information, the interaction logic and workflow between multiple intelligent agents can be redefined.

[0228] 2. Scalability: This application allows for the continuous registration and addition of new intelligent agents to meet increasingly complex business needs.

[0229] 3. Intelligent Service Mesh Solution: The intelligent service mesh solution non-intrusively integrates multiple agents, large language models, and tools to form a dynamically adaptive network structure. Its core is the A2A Client Proxy, employing an intelligent dynamic routing strategy driven by both workflow information and the large language model. This design combines the controllability of predefined processes with the flexibility of real-time decision-making by the large language model, enabling more precise handling of complex tasks and optimized resource utilization.

[0230] The following describes in detail one or more embodiments of the multi-agent orchestration apparatus of this application. Those skilled in the art will understand that these apparatuses can all be configured using commercially available hardware components through the steps taught in this solution.

[0231] Figure 12 This application provides a schematic diagram of a multi-agent orchestration device based on a service mesh, wherein the service mesh is registered with multiple agents, such as... Figure 12 As shown, the device includes: an acquisition module 11 and a generation module 12.

[0232] The acquisition module 11 is used to generate corresponding domain-specific language description information based on the workflow information of the multiple intelligent agents;

[0233] The generation module 12 is used to generate routing information corresponding to the workflow information of the multiple intelligent agents based on the domain-specific language description information. The routing information is used to define the calling relationship of the multiple intelligent agents in the service mesh.

[0234] Optionally, the workflow information is a workflow diagram formed by operating the multiple agents through an interface, and the workflow information is a workflow description text generated by natural language description, which describes the connection relationship of the multiple agents; the acquisition module 11 is specifically used to: parse the workflow diagram to determine the connection relationship of the multiple agents; generate the domain-specific language description information based on the attribute information of the multiple agents and the connection relationship; and input the workflow description text and the attribute information of the multiple agents into a specific language generation model to generate the domain-specific language description information through the specific language generation model.

[0235] Optionally, the plurality of intelligent agents includes at least one master intelligent agent and each of the at least one master intelligent agent's associated sub-intelligent agents; the generation module is specifically used to: generate first routing information for accessing the at least one master intelligent agent based on the connection relationship between different master intelligent agents contained in the workflow information, and generate second routing information for accessing each of the at least one master intelligent agent's associated sub-intelligent agents based on the associated sub-intelligent agents of each master intelligent agent.

[0236] Optionally, the generation module 12 is further configured to: input the description information of the target task, the attribute information of the plurality of intelligent agents, and the composite intelligent agent orchestration template information into the task generation model, so as to generate a composite intelligent agent corresponding to the target task through the task generation model, wherein the composite intelligent agent includes a target master intelligent agent and sub-intelligent agents associated with the target master intelligent agent, the target master intelligent agent is one of the at least one master intelligent agent, and the intelligent agents included in the composite intelligent agent are used to cooperate to complete the target task, the target task is one of a plurality of tasks; output the composite intelligent agents corresponding to each of the plurality of tasks so that the user can generate the workflow information according to the composite intelligent agents corresponding to each of the plurality of tasks, the workflow information reflecting the structure of the composite intelligent agents corresponding to each of the plurality of tasks and the connection relationship of the master intelligent agents in different composite intelligent agents.

[0237] Optionally, the device further includes: a registration module, configured to receive an agent registration request, the agent registration request including attribute information of a target agent; and register the target agent based on the attribute information of the target agent, wherein the target agent is any one of the plurality of agents.

[0238] Figure 12 The apparatus shown can execute the steps in the service mesh-based multi-agent orchestration method in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0239] The following describes in detail one or more embodiments of a multi-agent task processing apparatus according to this application. Those skilled in the art will understand that these apparatuses can all be configured using commercially available hardware components through the steps taught in this solution.

[0240] Figure 13 This application provides a schematic diagram of a multi-agent task processing device based on a service mesh, which is applied to a gateway. The service mesh has multiple registered agents, such as... Figure 13 As shown, the device includes: a receiving module 13, an acquisition module 14, and a calling module 15.

[0241] The receiving module 13 is used to receive the tasks to be processed corresponding to the plurality of intelligent agents;

[0242] The acquisition module 14 is used to acquire routing information corresponding to the workflow information of the multiple agents. The routing information is used to define the calling relationship of the multiple agents in the service mesh. The routing information is generated according to the above-mentioned multi-agent orchestration method.

[0243] The module 15 is invoked to invoke the plurality of intelligent agents to execute the task to be processed based on the routing information.

[0244] Optionally, the plurality of agents includes at least one master agent and each of the at least one master agent's associated sub-agents; the routing information includes first routing information for accessing the at least one master agent, and second routing information for accessing the at least one master agent's associated sub-agents.

[0245] The invocation module 15 is specifically configured to: respond to receiving a first task processing request to access a first intelligent agent as the main intelligent agent, send the first task processing request to the first intelligent agent according to the first routing information corresponding to the first intelligent agent; receive a second task processing request fed back by the first intelligent agent; determine a second intelligent agent to process the second task processing request from the sub-intelligent agents associated with the first intelligent agent; and send the second task processing request to the second intelligent agent according to the second routing information corresponding to the second intelligent agent.

[0246] The calling module 15 is further configured to: send the attribute information of the sub-intelligent agents associated with the first intelligent agent to the intelligent agent determination model, so as to determine the second intelligent agent for processing the second task processing request through the intelligent agent determination model.

[0247] Figure 13The apparatus shown can execute the steps of the service mesh-based multi-agent task processing method in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0248] Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 14 As shown, in practice, this electronic device includes a memory 21 and a processor 22.

[0249] Memory 21 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0250] The processor 22, coupled to the memory 21, is used to execute the computer program in the memory 21 to implement the multi-agent task processing method provided in the foregoing embodiments.

[0251] Furthermore, such as Figure 14 As shown, the electronic device also includes other components such as a communication component 23, a display 24, a power supply component 25, and an audio component 26. Figure 14 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 14 The components shown are as follows. The electronic device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server device such as a conventional server, cloud server, or server array.

[0252] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0253] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0254] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0255] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0256] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0257] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access 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), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0258] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

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

Claims

1. A service mesh based multi-agent orchestration method, the service mesh registers a plurality of agents, characterized in that, The method comprises: generating corresponding domain-specific language description information based on the workflow information of the plurality of intelligent agents, wherein the domain-specific language description information describes the attribute information and connection relationship of the plurality of intelligent agents; generating routing information corresponding to the workflow information of the plurality of intelligent agents based on the domain-specific language description information, wherein the routing information is used to define the calling relationship of the plurality of intelligent agents in the service mesh.

2. The method of claim 1, wherein, The workflow information is a workflow graph formed by operating the plurality of intelligent agents through an interface operation mode. The method further comprises: parsing the workflow graph to determine the connection relationship of the plurality of intelligent agents; generating the domain-specific language description information according to the attribute information and connection relationship of the plurality of intelligent agents.

3. The method of claim 1, wherein, The workflow information is a workflow description text generated by natural language description, wherein the workflow description text describes the connection relationship of the plurality of intelligent agents. The method further comprises: inputting the workflow description text and the attribute information of the plurality of intelligent agents into a specific language generation model to generate the domain-specific language description information through the specific language generation model.

4. The method of claim 1, wherein, The plurality of intelligent agents comprise at least one master intelligent agent and sub-intelligent agents associated with the at least one master intelligent agent respectively. The method further comprises: generating first routing information for accessing the at least one master intelligent agent according to the connection relationship between different master intelligent agents contained in the workflow information, and generating second routing information for accessing the sub-intelligent agents associated with the at least one master intelligent agent respectively according to the sub-intelligent agents associated with each master intelligent agent.

5. The method of claim 4, wherein, The method further comprises: inputting the description information of a target task, the attribute information of the plurality of intelligent agents, and composite intelligent agent orchestration template information into a task generation model to generate a composite intelligent agent corresponding to the target task through the task generation model, wherein the composite intelligent agent comprises a target master intelligent agent and sub-intelligent agents associated with the target master intelligent agent, the target master intelligent agent is one of the at least one master intelligent agent, and each intelligent agent contained in the composite intelligent agent is used to cooperatively complete the target task, the target task is one of a plurality of tasks; outputting the composite intelligent agents corresponding to the plurality of tasks respectively, so that a user generates the workflow information according to the composite intelligent agents corresponding to the plurality of tasks respectively, and the workflow information reflects the structure of the composite intelligent agents corresponding to the plurality of tasks respectively and the connection relationship of the master intelligent agents in different composite intelligent agents.

6. The method according to any one of claims 1-5, characterized in that, The method further comprises: receiving an intelligent agent registration request, wherein the intelligent agent registration request contains attribute information of a target intelligent agent; registering the target intelligent agent based on the attribute information of the target intelligent agent, wherein the target intelligent agent is any one of the plurality of intelligent agents.

7. A multi-agent task processing method based on a service mesh, characterized in that, The method is applied to a gateway, the service mesh registers a plurality of intelligent agents, and the method comprises: receiving a to-be-processed task corresponding to the plurality of agents; obtaining routing information corresponding to workflow information of the plurality of agents, the routing information being used to define a calling relationship of the plurality of agents in the service mesh, and the routing information being generated according to any one of the methods in claims 1-6; calling the plurality of agents according to the routing information to execute the to-be-processed task.

8. The method of claim 7, wherein, The plurality of agents includes at least one master agent and sub-agents respectively associated with the at least one master agent; and the routing information includes first routing information used to access the at least one master agent, and second routing information used to access the sub-agents respectively associated with the at least one master agent. The calling the plurality of agents according to the routing information to execute the to-be-processed task includes: in response to receiving a first task processing request for accessing a first agent as a master agent, sending the first task processing request to the first agent according to first routing information corresponding to the first agent; receiving a second task processing request fed back by the first agent; determining a second agent for processing the second task processing request from sub-agents associated with the first agent; sending the second task processing request to the second agent according to second routing information corresponding to the second agent.

9. The method of claim 8, wherein, The determining a second agent for processing the second task processing request from sub-agents associated with the first agent includes: sending attribute information of the sub-agents associated with the first agent to an agent determination model to determine a second agent for processing the second task processing request through the agent determination model.

10. The method of claim 7, wherein, The calling the plurality of agents according to the routing information to execute the to-be-processed task includes: receiving a third task processing request for accessing a target agent, the target agent being any one of the plurality of agents; determining a target agent of a target version from a plurality of versions corresponding to the target agent based on a feature identifier carried in the third task processing request; sending the third task processing request to the target agent of the target version based on the routing information.

11. An electronic device, comprising: comprise: a memory, a processor, and a communication interface; wherein the memory has stored executable codes, and when the executable codes are executed by the processor, the processor executes the method in any one of claims 1-6 or 7-10.

12. A non-transitory machine-readable storage medium, comprising: The non-transitory machine-readable storage medium has stored executable codes, and when the executable codes are executed by the processor of the electronic device, the processor executes the method in any one of claims 1-6 or 7-10.

13. A computer program product, characterised in that, comprise: a computer program, and when the computer program is executed by the processor of the electronic device, the processor executes the method in any one of claims 1-6 or 7-10.

Images