Multi-agent arrangement method and device based on service grid and storage medium

Abstract

The embodiment of the invention provides a multi-agent arrangement method and device based on a service grid and a storage medium, and relates to the technical field of artificial intelligence. The method comprises the following steps: generating corresponding domain-specific language description information based on workflow information of a plurality of agents; and based on the domain-specific language description information, generating routing information corresponding to the workflow information of the plurality of agents, the routing information being used for defining a calling relationship of the plurality of agents in the service grid. According to the scheme, the labor cost is reduced, and the arrangement efficiency is improved.

Description

Technical Field

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

[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 actual applications, the functions corresponding to multiple agents in a multi-agent system are often different. In specific implementation, for example, when task A needs to be executed, the staff needs to manually arrange the routing information corresponding to the workflow information of multiple agents involved in task A, and when task B needs to be executed, the staff needs to manually arrange the routing information corresponding to the workflow information of multiple agents involved in task B. That is, for different tasks, the staff needs to manually arrange the workflow information of multiple agents involved in the task, as well as the routing information corresponding to the workflow information, which results in high labor costs and low orchestration efficiency. Summary of the Invention

[0004] The embodiments of the present application provide a multi-agent orchestration method, device, and storage medium based on a service grid, which are used to reduce labor costs and improve orchestration efficiency.

[0005] In a first aspect, an embodiment of the present application provides a multi-agent orchestration method based on a service grid, wherein the service grid is registered with multiple agents, and the method includes: Generate corresponding domain-specific language description information based on workflow information of the plurality of agents; Based on the domain-specific language description information, routing information corresponding to the workflow information of the multiple agents is generated, and the routing information is used to define the calling relationship between the multiple agents in the service grid.

[0006] In a second aspect, an embodiment of the present application provides a multi-agent orchestration device based on a service grid, wherein the service grid is registered with multiple agents, and the device includes: An acquisition module, configured to generate corresponding domain-specific language description information based on workflow information of the plurality of agents; A generation module is used to generate routing information corresponding to the workflow information of the multiple agents based on the domain-specific language description information, and the routing information is used to define the calling relationship between the multiple agents in the service grid.

[0007] In a third aspect, an embodiment of the present application provides a multi-agent task processing method based on a service grid, which is applied to a gateway, wherein the service grid is registered with multiple agents, and the method includes: receiving tasks to be processed corresponding to the plurality of agents; Obtaining routing information corresponding to the workflow information of the multiple agents, the routing information being used to define a calling relationship between the multiple agents in the service grid, the routing information being generated according to the multi-agent orchestration method provided in the first aspect; The plurality of agents are called according to the routing information to execute the tasks to be processed.

[0008] In a fourth aspect, an embodiment of the present application provides a multi-agent task processing device based on a service grid, which is applied to a gateway, wherein the service grid is registered with multiple agents, and the device includes: A receiving module, configured to receive tasks to be processed corresponding to the plurality of intelligent agents; an acquisition module, configured to acquire routing information corresponding to the workflow information of the plurality of agents, the routing information being used to define a calling relationship between the plurality of agents in the service grid, the routing information being generated according to the multi-agent orchestration method provided in the first aspect; A calling module is used to call the multiple agents according to the routing information to execute the tasks to be processed.

[0009] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising: 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 executes the method described in the first aspect or the third aspect.

[0010] In the sixth aspect, an embodiment of the present application provides a non-temporary machine-readable storage medium, on which executable code is stored. When the executable code is executed by a processor of an electronic device, the processor can at least implement the method described in the first aspect or the third aspect.

[0011] In a seventh aspect, an embodiment of the present application provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it can implement the method described in the first aspect or the third aspect.

[0012] In the multi-agent orchestration solution based on the service grid provided in the embodiment of the present application, corresponding domain-specific language description information is generated based on the workflow information of the multiple agents, and based on the domain-specific language description information, routing information corresponding to the workflow information of the multiple agents can be automatically generated to define the calling relationship between the multiple agents in the service grid, thereby saving labor costs and improving orchestration efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0014] Figure 1 A flowchart of a multi-agent orchestration method based on a service grid provided in an embodiment of the present application; Figure 2 A specific example diagram of a workflow diagram provided in an embodiment of the present application; Figure 3 A specific example diagram of a domain-specific language description information provided in an embodiment of the present application; Figure 4 Another flowchart of a multi-agent orchestration method based on a service grid provided in an embodiment of the present application; Figure 5 A schematic diagram of an application for registering an agent through a gateway provided in an embodiment of the present application; Figure 6 A specific example diagram of generating a composite intelligent agent provided in an embodiment of the present application; Figure 7 A specific example diagram of multiple composite intelligent agents collaborating to complete a target task provided in an embodiment of the present application; Figure 8 A flowchart of a multi-agent task processing method based on a service grid provided in an embodiment of the present application; Figure 9 A schematic diagram of a task processing request application based on a first route provided in an embodiment of the present application; Figure 10 A schematic diagram of a task processing request application based on a second route provided in an embodiment of the present application; Figure 11 A schematic diagram of an application of a multi-agent task processing method based on a service grid provided in an embodiment of the present application; Figure 12 A schematic diagram of the structure of a multi-agent orchestration device based on a service grid provided in an embodiment of the present application; Figure 13 A schematic diagram of the structure of a multi-agent task processing device based on a service grid provided in an embodiment of the present application; Figure 14 This is a schematic structural diagram of an electronic device provided in this embodiment. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. In addition, the step timing in the following method embodiments is only an example and not a strict limitation.

[0016] It should be noted that when the embodiments of this application involve user information, 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, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation portals 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) are in compliance with relevant laws and standards.

[0017] In addition, it should be noted that the specific language generation model, task generation model, and agent determination model involved in the embodiments of the present application can be a language model (Language Mode, abbreviated as LM) or a multimodal model (Multimodal Model, abbreviated as MM) based on artificial intelligence, etc. The embodiments of the present application do not limit the number of model parameters supported by the model, with the goal of meeting actual needs. If the model parameters are relatively large, the scale of the model will be relatively large, and the model performance will be relatively better. Of course, more time and resources will be consumed during the reasoning or training process; if the model parameters are relatively small, the scale of the model will be relatively small. If the performance meets the requirements, the model will be more lightweight and consume relatively less time and resources during the reasoning or training process. The 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, which can be implemented based on a neural network architecture and can be pre-trained on a large amount of data. In an optional 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 is primarily used to convert input data (usually in sequence form) into a vector representation, a process that can capture the semantic features of the input data. The decoder is responsible for converting the intermediate representation 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 expressiveness. These components work together, enabling the model built based on 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.

[0018] The following are explanations of the terms or concepts involved in the embodiments of this application: Agent: An agent that can perceive the environment and take actions to achieve specific goals. It can be software, hardware or a system with autonomy, adaptability and interaction capabilities.

[0019] Service mesh: It is an intelligent infrastructure layer used to handle communication between services. In practice, service mesh is usually implemented through a set of lightweight network proxies that are deployed together with the application without being aware of the application itself. In the embodiment of the present application, multiple intelligent agents act as multiple services and register multiple intelligent agents in the service mesh to collaborate on completing user-triggered tasks, so that multiple intelligent agents form a grid structure. The agent responsible for communication between multiple intelligent agents can be the gateway in the embodiment of the present application. The gateway can implement routing forwarding between different intelligent agents in the service mesh based on the generated routing information (which defines the calling relationship between multiple intelligent agents in the service mesh). The specific meaning of the service mesh and related implementation can be referred to the existing relevant technologies and will not be elaborated here.

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

[0021] In view of this, an embodiment of the present application provides a multi-agent orchestration method, which solves the above problems through the following ideas: obtaining domain-specific language description information corresponding to the workflow information of multiple agents, and then based on the domain-specific language description information, automatically generating routing information corresponding to the workflow information of multiple agents. The entire process is carried out automatically without the need for human participation, saving labor costs and improving orchestration efficiency.

[0022] Figure 1 A flowchart of a multi-agent orchestration method based on a service grid provided in an embodiment of the present application, wherein the service grid has multiple agents registered therein, and the method is applied to a gateway, such as Figure 1 As shown, the method includes the following steps: 101. Based on the workflow information of multiple intelligent agents, generate corresponding domain-specific language description information.

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

[0024] In practical applications, workflow information can be a workflow diagram formed by operating multiple agents through interface operations, or it can be a workflow description text generated through natural language description, where the workflow description text describes the connection relationship between multiple agents.

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

[0026] For easier understanding, see Figure 2 A specific example of a workflow diagram is provided. Figure 2 The following agents are included: 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 the Data Collection Agent, Analysis Agent, Specialized Planning Agent, Visualization Agent, Critique Agent, and Refinement Agent.

[0027] Specifically, the Data Collection Agent is used to collect data and is associated with multiple parallel agents, such as the Population Agent, the Economic Agent, the Environmental Agent, and the 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.

[0028] The Analyzer Agent analyzes pending data sent by the Coordinator Agent or data output by the Data Collection Agent. It is associated with multiple agents that execute sequentially (also known as serial), such as the Data Preprocessor Agent, the Trend Designer Agent, and the Prediction Modeler Agent. The Data Preprocessor Agent preprocesses raw data (e.g., cleaning and removing duplicate data). The Trend Designer Agent analyzes the trends of a particular data item over the next time period, such as "analyzing the company's net profit data for the next fiscal year." The Prediction Modeler Agent analyzes data from a holistic perspective, for example, forecasting trends across all data, including demographic, economic, environmental, and transportation data.

[0029] The professional planning agent is used to perform corresponding design and planning in a professional field based on the pending data issued by the coordinator agent or the analysis results of the analysis agent. It is associated with multiple parallel agents, such as the land use agent (Land Use Agent), the transportation planning agent (Transportation Agent), the public facilities agent (Public Facilities Agent), and the environmental protection agent (Environmental Protection Agent). Among them, the land use agent is used to perform corresponding design and planning based on the pending data in the land field; the transportation planning agent is used to perform corresponding design and planning based on the pending data in the transportation field; the public facilities agent is used to perform corresponding design and planning based on the pending data in the public facilities field; and the environmental protection agent is used to perform corresponding design and planning based on the pending data in the environmental protection field.

[0030] The visualization agent is used to convert the data to be processed issued by the coordinator agent or the output results of the professional planning agent into visual results, such as three-dimensional models, charts, etc.

[0031] The solution review agent is used to review the pending solutions issued by the coordinator agent or the output results of the visualization agent and output the review results.

[0032] The Iterative Optimization Agent is used to iteratively optimize the audit results output by the Solution Review Agent or the solutions issued by the Coordinator Agent, outputting an optimized solution. In practical applications, if the optimized solution is confirmed to require no further optimization, it will be used as the final solution. If the optimized solution is confirmed to require further optimization, it will be input into the Solution Review Agent and the Iterative Optimization Agent for iterative optimization until the solution no longer requires further optimization.

[0033] When implementing it, you can Figure 2 The multiple agents displayed are dragged, clicked, and operated to form a workflow diagram.

[0034] As an implementation, assume that multiple function module icons with agent names are preconfigured on the visualization interface. In practice, simply drag and drop the function module icons to the designated locations based on the agent names. Then, based on the relationships between agents (e.g., parallel or serial) and their work order, connect the agents using arrows to create a workflow diagram.

[0035] As another implementation method, assume that a set of workflow diagram templates has been configured on the visual interface. The workflow diagram template contains multiple free areas for placing function module icons, and connecting lines with arrows connecting multiple free areas. In addition, the workflow diagram template is also configured with multiple function module icon options with intelligent agent names. When you need to fill a free area, you only need to click on the free area, and then click on the function module icon you want to fill in the free area. When all the free areas are filled, the final workflow diagram is obtained.

[0036] After obtaining the workflow diagram, the workflow diagram can be parsed by the rule engine to determine the connection relationship between multiple agents. For example, the connection relationship between the coordinator agent and the data collection agent, analysis agent, professional planning agent, visualization agent and other agents can be determined, which are not listed here one by one. Afterwards, domain-specific language description information is automatically generated based on the attribute information and connection relationship of multiple agents. Among them, the rule engine can be located inside or outside the gateway, which is not limited here. The domain-specific language description information refers to: the attribute information and connection relationship of multiple agents described using a computer language (i.e., domain-specific language, Domain-Specific Language, abbreviated as DSL) that focuses on a certain application domain.

[0037] It should be noted that the attribute information of multiple agents is the attribute information carried by the multiple agents themselves, which can be directly obtained by default when the multiple agents are running. Taking the coordinator agent as an example, its attribute information may include "type (type): LLMAgent, indicating an agent with built-in or connected large language model service", "role (role): urban planner", etc. According to the above Figure 2As can be seen, 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 connection relationships, domain-specific language description information can be generated. A specific example of this domain-specific language description information is as follows: "Coordinator Agent type:LLMAgent role: Urban Planner SubAgent: -Data Collection Agent -Analysis Agent -Specialized Planning Agent -Visualization Agent -Critique Agent -Refinement Agent” Among them, SubAgent represents: 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. In addition, it should be noted that for ease of understanding, the above domain-specific language description information only gives some examples. The complete example can be found in Figure 3 .exist Figure 3 middle, Figure 3 Shown in Figure 2 The attribute information corresponding to all agents in (where "HierarchicalAgent" represents a hierarchical agent, "ParallelAgent" represents a parallel processing agent, and "SequentialAgent" represents a sequential processing agent), and Figure 3 The workflow part in the worlflow describes the logical relationship between the agents. This logical relationship has been described in Figure 2 Detailed description was given at the time and will not be repeated here.

[0038] By creating a workflow diagram through dragging and clicking on a visual interface, the operation is simple and efficient. In subsequent practical applications, simply parsing the workflow diagram can determine the connection relationships between multiple agents. Then, domain-specific language description information is automatically generated based on the attributes and connection relationships of multiple agents, which greatly improves the generation speed of domain-specific language description information.

[0039] 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 intelligent agents, corresponding domain-specific language description information is generated based on the workflow information of multiple intelligent agents, including: inputting the workflow description text and the attribute information of multiple intelligent agents into a specific language generation model to generate domain-specific language description information through the specific language generation model.

[0040] In practical applications, workflow information can be a workflow description text generated by users through natural language description. For ease of understanding, the following continues with Figure 2 Taking the workflow process described in [1] as an example, the workflow description text can be illustrated as follows: The demographic data collection agent and the economic data collection agent are first run in parallel to collect demographic and economic data, respectively. Afterwards, the collected demographic and economic data are sent to the analysis agent for analysis. The data collection agent and the analysis agent run in parallel, and the data collection agent is associated with at least the demographic data collection agent and the economic data collection agent, among others. The descriptions of other agents are not listed here.

[0041] In specific implementation, the workflow description text and the attribute information of multiple agents are input into a specific language generation model. This generates domain-specific language description information based on the attribute information and connection relationships of the multiple agents. Subsequently, a rule engine performs grammatical verification and other security and compliance processing on the domain-specific language description information generated by the specific language generation model to ensure that the generated domain-specific language description meets the requirements, thereby obtaining the final domain-specific language description information. The rule engine can be located within or outside the gateway, without limitation.

[0042] By inputting the workflow description text generated by natural language description and the attribute information of multiple intelligent agents into the specific language generation model, domain-specific language description information is obtained, which reduces the difficulty of obtaining domain-specific language description information (users only need to use natural language for relevant descriptions without having to understand the specific writing method of the domain-specific language). In addition, the domain-specific language description information is automatically generated through the specific language generation model, ensuring the accuracy and generation efficiency of obtaining domain-specific language description information.

[0043] It should be noted that in the two aforementioned processes for dynamically generating domain-specific language description information, the orchestration of some agents can differ across different application scenarios. If some of the orchestrated agents change within the set application scenario, resulting in changes in the workflow information, this will trigger changes in the corresponding domain-specific language description information, and thus in the routing information subsequently generated based on the domain-specific language description information. In other words, as users dynamically update or modify workflow information, the corresponding domain-specific language description information will also be dynamically updated, and thus the corresponding routing information will be dynamically updated.

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

[0045] In practical applications, multiple agents may include at least one main agent and at least one sub-agent associated with the main agent. Figure 2 For example, the main 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 traffic data collection agent. For details of the sub-agents associated with other main agents, please refer to Figure 2 , which are not listed here one by one.

[0046] It is understood that if a certain agent needs to be accessed, the agent's routing information must first be determined. In specific implementations, first routing information for accessing at least one master agent can be generated based on the connection relationships between different master agents contained in the workflow information. For example, assuming that the workflow information includes a data collection agent and an analysis agent connected in sequence, the generated first routing information can be in the following form: “Route: -match: -Prefix: Data Collection Service: -Target (match): -Host: Data Collection Agent -match: -Prefix: Analysis Service: -Target (match): -Host: Analysis Agent" In actual applications, if the access request contains the prefix "Data Collection", the access request will be routed to the Data Collection Agent based on the prefix and the first routing information. If the access request contains the prefix "Analysis", the access request will be routed to the Analysis Agent based on the prefix and the first routing information.

[0047] Furthermore, based on the sub-agents associated with each master agent, second routing information can be generated for accessing the sub-agents associated with at least one master agent. For example, if the master agent is a data collection agent, its associated sub-agents include: a population data collection agent (Population Agent), an economic data collection agent (Economic Agent), an environmental data collection agent (Environmental Agent), and a traffic data collection agent (Traffic Agent). The second routing information generated based on the sub-agents can be in the following form: "next forward filter (a routing decision filter used to determine the next hop target of a request based on the response of the previous service): format_endpoint_list (routable endpoint list): PopulationAgent.svc (address corresponding to the population data collection agent) EconomicAgent.svc (the address corresponding to the economic data collection agent) EnvironmentAgent.svc (the address corresponding to the environment data collection agent) TrafficAgent.svc (the address corresponding to the traffic data collection agent) phase: after_response (execution phase: after response) format_code (redirect status code): 301 format_endpoint (routing target): {{ response.body.next}} (the response contains the next hop agent address) format_type (request processing mode): pass_through (transparent mode)" In practice, assuming the data collection agent is accessed through the first routing information, the data collection agent returns a response to the gateway (the response described above). By parsing the "body" within the response, the next-hop agent address can be obtained. For example, if the "body" is parsed and the result is "next:PopulationAgent.svc," the next-hop agent address is PopulationAgent.svc. In this case, the population data collection agent can be accessed directly based on this agent address.

[0048] By generating first routing information for accessing at least one main agent based on the connection relationship between different main agents contained in the workflow information, the workflow between the main agents can be controlled by the first routing information, ensuring the stability of the core process. By generating second routing information for accessing the sub-agents associated with at least one main agent based on the sub-agents associated with each main agent, the calling of sub-agents under the main agent can be realized, meeting the requirements of local modification (when the call of the sub-agent associated with a certain main agent needs to be modified, it will not affect the collaboration between other main agents). In addition, by generating the first routing information and the second routing information, the decoupling of "routing between main agents" and "routing of sub-agents" is achieved, making the overall routing architecture clearer and the division of labor more clear.

[0049] Based on the above, the multi-agent orchestration method provided in the embodiment of the present application can realize the automatic generation of routing information corresponding to the workflow information, save labor costs and improve orchestration efficiency.

[0050] Figure 4 Another flow chart of a multi-agent orchestration method based on a service grid provided in an embodiment of the present application, such as Figure 4 As shown, the method includes the following steps: 401. Input the description information of the target task, the attribute information of multiple agents and the composite agent arrangement template information into the task generation model to generate a composite agent corresponding to the target task through the task generation model, wherein the composite agent includes the target main agent and the sub-agents associated with the target main agent, the target main agent is one of at least one main agent, and the agents contained in the composite agent are used to collaborate to complete the target task, and the target task is one of multiple tasks.

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

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

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

[0054] In practical applications, before orchestrating multiple agents, multiple agents need to be registered in the gateway. The specific steps are as follows: receiving an agent registration request and registering the target agent based on the target agent's attribute information contained in the agent registration request. The target agent is any one of the multiple agents.

[0055] In specific implementation, the user initiates an agent registration request for the target agent through the Application Programming Interface (API) provided by the gateway. The agent registration request includes attribute information such as the target agent's type, role, and host address. After receiving the agent registration request, the gateway initiates a verification process. For example, it verifies whether the input and output formats of the target agent conform to the specifications of the domain-specific language, or verifies whether the compatibility of the current version of the target agent with the previous version meets the set verification requirements, etc., to ensure that the target agent symbol to be registered meets the technical specifications and security standards.

[0056] After verification, the gateway will assign a unique identifier to the target agent, and store the identifier and the complete information of the target agent (for example, it may include attribute information, function introduction, version number, etc.) in the set agent service registration center, and at the same time update the routing information used to store the agent and its corresponding routing address to ensure that when there are subsequent external requests that need to use the target agent, they can be accurately and efficiently forwarded to the target agent through the identifier.

[0057] After the target agent is successfully registered, the gateway triggers a system-level discovery event, which includes at least the target agent's identifier, attribute information, function description, version number, etc. The gateway can then send this release event to relevant components such as the load balancer and monitoring system via the internal message bus or by calling the API of the relevant component, allowing them to perform health checks on the target agent (e.g., checking every 5 seconds, marking it unhealthy if it fails twice in a row), formulate traffic allocation strategies (e.g., initially allocating 30% of the traffic to it, and subsequently increasing it by 10% every hour), and add the target agent to the monitoring targets, thereby integrating the target agent into the agent pool used to store agents.

[0058] After publishing the discovery event, the gateway generates a detailed confirmation message and returns it to the user who initiated the agent registration request. The confirmation message includes: the target agent's unique identifier and access credentials (such as keywords, tokens, etc., which are used for authentication in subsequent calls to the gateway or other services).

[0059] Figure 5 This is a schematic diagram of an application in which an agent is registered via a gateway. Figure 5 In the gateway, multiple sub-agents are registered, including: population data collection agent (Population Agent), economic data collection agent (Economic Agent), environmental data collection agent (Environmental Agent), traffic data collection agent (Traffic Agent), data preprocessor agent (Data Preprocessor), trend analysis agent (Trend Designer), prediction model agent (Prediction Modeler), land use agent (Land UseAgent), transportation planning agent (Transportation Agent), public facilities agent (Public FacilitiesAgent), and environmental protection agent (Environmental Protection Agent). The above target agent can be one of them.

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

[0061] After completing the registration of multiple agents based on the above method, the description information of the target task, the attribute information of multiple agents and the composite agent arrangement template information can be input into the task generation model to generate the composite agent corresponding to the target task through the task generation model. The specific process can be seen in Figure 6 .

[0062] exist Figure 6 The system includes a gateway (including the first plug-in (also called Direct Proxy plug-in) and the second plug-in (also called Agent Route Plugin plug-in), where Direct Proxy represents a direct proxy for forwarding requests between agents, and Agent Route Plugin integrates the decision-making ability of LLM and can dynamically select sub-agents according to the context), LLM Service (that is, the task generation model mentioned above), and three composite agents generated based on the task generation model, namely: "Data Collection Agent, and its associated population data collection agent (Population Agent), economic data collection agent (Economic Agent), environmental data collection agent (Environmental Agent) and traffic data collection agent (Traffic Agent) constitute the first composite agent", "Analysis Agent, and its associated data preprocessing agent (DataPreprocessor), trend analysis agent (Trend Designer), prediction model agent (PredictionModeler) constitute the second composite agent", "Specialized Planning Agent, and its associated land use agent (Land Use The third composite agent is composed of the traffic planning agent (TransportationAgent), the public facilities agent (Public Facilities Agent), and the environmental protection agent (EnvironmentalProtection Agent).

[0063] In actual applications, each main agent (Data Collection Agent, Analysis Agent, Specialized Planning Agent) sends a target task request to the gateway. The target task request includes the description information of the target task, the attribute information of multiple agents, and the composite agent orchestration template information. Among them, the description information of the target task can be "Analyze the population change trend of City A" or "Conduct labor and economic statistics for City A", etc., which are not listed here one by one. The composite agent orchestration template information contains the working logic relationship between multiple agents, for example, whether the multiple agents are in a parallel or serial relationship, which are the main agents and which are the sub-agents, the connection relationship between the main agent and the sub-agents, etc.

[0064] After receiving the target task description, the attributes of multiple agents, and the composite agent orchestration template, the gateway sends this information to the task generation model. The gateway then returns the selected sub-agents corresponding to the main agent, identifying the main agent and its corresponding sub-agents as a composite agent. For example, if the target task description currently input into the task generation model is "Analyze the population trends of City A," the composite agent generated from this description might include the main agent "AnalysisAgent" and its associated sub-agents "Data Preprocessor and Trend Analysis Agent." Alternatively, if the target task description currently input into the task generation model is "Conduct human and economic statistics for City A," the composite agent generated from this description might include the main agent "Data Collection Agent" and its associated sub-agents "Population Agent and Economic Agent."

[0065] After obtaining the composite agents corresponding to the multiple tasks generated by the task generation model, the user can generate workflow information based on the composite agents corresponding to the multiple tasks. The task generation model can be built into the gateway or called from outside the gateway, which is not limited here.

[0066] Based on the above, by using the task generation model to generate composite intelligent agents corresponding to multiple tasks, it can make subsequent users' workflow information arrangement easier and faster, improve the user's arrangement experience, and further improve the arrangement efficiency.

[0067] In this process, users can use the above-mentioned "through interface operation" or "through natural language description to generate workflow description text" to complete the arrangement of workflow information. The specific example diagram of multiple composite intelligent agents collaborating to complete the target task after arrangement can be seen in Figure 7 .exist Figure 7 In the system, there are multiple main agents and three composite agents. The main agents include: Coordinator Agent, Visualization Agent, Critique Agent, and Refinement Agent. The three composite agents include "the first composite agent consisting of the Data Collection Agent and its associated Population Agent, Economic Agent, Environmental Agent and Traffic Agent", "the second composite agent consisting of the Analysis Agent and its associated Data Preprocessor, Trend Designer and Prediction Modeler", and "the third composite agent consisting of the Specialized Planning Agent and its associated Land Use Agent, Transportation Agent, Public Facilities Agent and Environmental Protection Agent".

[0068] During implementation, the coordinator agent receives a target task request from a user and, based on the target task request, dispatches the first composite agent to collect target task-related data. The first composite agent then sends the collected target task-related data to the second composite agent, which analyzes the target task-related data and sends the analysis results to the third composite agent. The third composite agent then develops a solution based on the analysis results and sends it to the iterative optimization agent for solution optimization. The iterative optimization agent then sends the optimized solution to the visualization agent for visual display. The review agent then reviews the content of the visual display and, upon approval, sends the approved content to the user.

[0069] Figure 8 A flowchart of a multi-agent task processing method based on a service grid is provided in an embodiment of the present application. The service grid has multiple agents registered. The method is applied to a gateway, such as Figure 8 As shown, the method includes the following steps: 801. Receive tasks to be processed corresponding to multiple intelligent agents.

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

[0071] 803. Call multiple agents according to the routing information to execute the pending tasks.

[0072] It can be understood that since the multi-agent orchestration method provided by the above embodiment can improve the orchestration efficiency, in actual application, for the pending tasks corresponding to multiple agents sent by the user, the routing information generated by the multi-agent orchestration method provided by the above embodiment is used to call multiple agents to execute the pending tasks, and no human participation is required, and the task processing efficiency is high.

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

[0074] In specific implementation, after receiving pending tasks corresponding to multiple agents issued by the user (such as "analyzing the population change trend of city A" and "conducting artificial and economic statistics for city A"), multiple agents can be called to execute the pending tasks according to the routing information obtained by adopting the method of the above embodiment. The specific process is as follows: in response to receiving a first task processing request to access the first agent as the main agent, the first task processing request is sent to the first agent according to the first routing information corresponding to the first agent; the second task processing request fed back by the first agent is received; the second agent for processing the second task processing request is determined from the sub-agents associated with the first agent; and the second task processing request is sent to the second agent according to the second routing information corresponding to the second agent.

[0075] It should be noted that all or part of the multiple agents may have multiple versions, and traffic forwarding rules corresponding to each version or traffic forwarding conditions corresponding to each version may be configured in the gateway.

[0076] Among them, the traffic forwarding rules can be manually pre-written into the gateway or automatically formulated by the gateway.

[0077] For example, you can manually determine that requests to access an agent during a certain time period are sent to the first version of the agent, and requests to access the agent during another time period are sent to another version of the agent. Another example is that you can manually determine that requests to access an agent with a field value of a first field value are sent to the first version of the agent, and requests with a field value of a second field value are sent to another version of the agent.

[0078] In addition, taking the initial version of an agent as V0 as an example, the gateway can use analytical tools such as large models to analyze the network traffic sent to this version of the agent, that is, the values ​​of certain fields contained in the request, to determine the type of this network traffic (for example, traffic with a certain field value of a is one type) and formulate a correspondence between this type and the agent's V0 version as the traffic forwarding rule corresponding to the V0 version of the agent. After the agent is upgraded to version V1, if the value of the aforementioned field carried in the request to access the agent is a, it is determined that the V0 version should be accessed; otherwise, it is determined that the V1 version should be accessed. Similarly, traffic forwarding rules corresponding to the V1 version of the agent can also be formulated.

[0079] Among them, the above-mentioned field can be used as a characteristic identifier in the request. The meaning of the field can be, for example, the request source address, user identifier, task type, etc.

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

[0081] For ease of understanding, the following Figure 9 and Figure 10 The following describes the process of processing a task request: Figure 9 It represents the process of sending the task processing request according to the first routing information. Figure 9 In the example, the user sends a first task processing request to the main agent A (ie: PAgent-A). The first task processing request includes: "path(path: / A); next: PAgent-B (indicates that the first task processing request needs to be redirected to the main agent B, i.e. PAgent-B, after PAgent-A completes processing); Content: {......}" After receiving the first task processing request, master agent A processes it and, after completing the processing, sends a redirect request to the gateway. This redirect request includes the message "Change the path to " / B" and the content to the processed data." Upon receiving the redirect request, the gateway, using the A2A (Agent-to-Agent) Client Proxy plug-in, sends the redirect request to master agent B. This redirect request is then processed by master agent B, who then completes the subsequent task.

[0082] Among them, A2A Client Proxy is an intelligent proxy component specially designed for multi-agent systems. It is embedded in the service grid to handle communication between agents. In the embodiment of this application, it can route according to the routing rules preset in the gateway and domain-specific language description information.

[0083] In specific implementation, domain-specific language description information can be obtained based on workflow information, and then translated into routing rules that can be recognized by the specific gateway through the translation engine for use by the gateway. For example, the routing rule can be: "PAgent-A: matches path " / A"; PAgent-B: matches path “ / B”; SubAgent-A1: matches the path " / A" and the value of the request header "headersub" is "a1"; SubAgent-A2: matches the path " / A" and the request header "headersub" has a value of "a2".

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

[0085] Figure 10 It represents the process of sending the task processing request according to the second routing information. Figure 10 In the example, the master agent C receives the second task processing request fed back by the first agent, and the second task processing request includes: "path (path: / LLM-service); Content: {......}" After receiving the second task processing request, the main agent C processes the second task processing request. After the processing is completed, the main agent C sends the processed second task processing request to the large language model service LLM-service through the gateway's Transport Proxy, so that the LLM-service can respond. The specific response information may include: "path(path: / C); next: SubAgent-C1 (indicates the next hop is sub-agent C1); Content: {......}" Among them, "Transport Proxy" refers to the component in the gateway that is responsible for the network transport agent. Specifically, it is a network transport layer agent that processes requests and responses, and is responsible for forwarding requests from users to the correct target service (such as an agent) and returning responses to the user. LLM-service can be a model for agent determination. In specific implementation, the second task processing request is sent to the agent determination model to determine the second agent (i.e., sub-agent C1) used to process the second task processing request through the agent determination model combined with the attribute information of the sub-agent associated with its built-in main agent C. It can be understood that when selecting which sub-agent to execute the second task processing request through LLM-service, the selection result will change dynamically with the difference of the second task processing request, that is, the use of the routing information corresponding to the sub-agent under the main agent is dynamic.

[0086] By using the agent determination model to determine the second agent for processing the second task processing request from the sub-agents associated with the first agent, the accuracy of the determined second agent is ensured while improving work efficiency.

[0087] After receiving the response, the gateway determines that it needs to redirect the second task processing request to child agent C1. The gateway then uses the A2A (Agent-to-Agent) Client Proxy plugin to send the redirect request to child agent C1, enabling C1 to process the redirected second task processing request and complete the subsequent task. The redirect request (Request Redirect) includes: "Path changed to ' / C'; Request header headersub=a1; Content is the processed data."

[0088] In specific implementation, domain-specific language description information can be obtained based on workflow information, and then translated into routing rules that can be recognized by the specific gateway through the translation engine for use by the gateway. For example, the routing rule can be: "PAgent-C: match path " / C"; SubAgent-C1: matches the path " / C" and the request header "headersub" value is "c1".

[0089] Based on the above, by using the above-mentioned two-layer routing mechanism (i.e., selecting the main intelligent agent through the first routing information and selecting the sub-intelligent 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.

[0090] For ease of understanding, the following Figure 11 The following are some specific examples to illustrate this solution: exist Figure 11 It contains the following parts: 1. The console is used to interact with users. Users can add multiple agents and arrange the order of multiple agents on the console through interface operations such as dragging and clicking, or using natural language input to form workflow information.

[0091] 2. The rule engine is used to receive the workflow information sent by the console and convert the workflow information into domain-specific language description information. The domain-specific language description information may specifically include the following: "Coordinator Agent type:LLMAgent role: Urban Planner SubAgent: -Data Collection Agent -Analysis Agent -Specialized Planning Agent -Visualization Agent -Critique Agent -Refinement Agent Data Collection Agent type:ParallelAgent role: Data Collector SubAgent: -PopulationAgent -EconomicAgent -EnvironmentAgent -TrafficAgent AnalysisAgent type: SequentialAgent role: Data Analyst SubAgent: -DataPreprocessor -TrendAnalyzer -PredictionModeler 3. The control plane of the gateway is used to receive the domain-specific language description information sent by the rule engine, and based on the domain-specific language description information, generate first routing information and second routing information corresponding to the workflow information of multiple agents, and convert the first routing information and second routing information into a language understandable by the data plane of the gateway and send it to the data plane. The first routing information includes: “Route: -match: -Prefix: Data Collection Service: -Target (match): -Host: Data Collection Agent -match: -Prefix: Analysis Service: -Target (match): -Host: Analysis Agent" The second routing information includes: "next forward filter (a routing decision filter used to determine the next hop target of a request based on the response of the previous service): format_endpoint_list (routable endpoint list): PopulationAgent.svc (address corresponding to the population data collection agent) EconomicAgent.svc (the address corresponding to the economic data collection agent) EnvironmentAgent.svc (the address corresponding to the environment data collection agent) TrafficAgent.svc (the address corresponding to the traffic data collection agent) phase: after_response (execution phase: after response) format_code (redirect status code): 301 format_endpoint (routing target): {{ response.body.next}} (the response contains the next hop agent address) format_type (request processing mode): pass_through (transparent mode)".

[0092] 4. Gateway data plane: Assume the traffic hijacking module intercepts the task request "example.com / data-collector," which includes the following: host:example.com, prefix:data-collector. At this point, a first routing information match is performed. Specifically, based on the prefix:data-collector, it can be determined that the address link to host is required, and then jump to the Data Collection Agent.

[0093] As an implementation, after processing a task request, the Data Collection Agent responds with a response message containing "body:next:PopulationAgent.svc." "body" refers to the HTTP request body, the core data carrier of an HTTP request. By parsing the body, the next hop is determined to be the PopulationAgent. At this point, the PopulationAgent can be directly invoked.

[0094] As another implementation method, after processing the task request, the Data Collection Agent will respond by determining the model (i.e. Figure 11 LLM driver in the process), based on the response information and the attribute information of multiple agents in the main agent (ParentAgent) cluster and the subagent (SubAgent) cluster, it determines that the next hop is PopulationAgent, returns the next hop to the traffic hijacking module, and sends the task request to PopulationAgent through the traffic hijacking module. Figure 11 The detailed description of the agents in each agent cluster can be found in the above embodiments and will not be repeated here.

[0095] In summary, the embodiments of the present application have at least the following beneficial effects: 1. Low cost and high flexibility: When user needs change, the functionality of the agent may need to be modified, which in turn causes changes in workflow information. These changes in workflow information are reflected in changes to the domain-specific language description information. In summary, when users need to adjust the functionality or workflow information of an agent, they can simply adjust the domain-specific language description information through natural language, without modifying the underlying agent code, which is relatively low-cost. This modification method can quickly adapt to new needs and scenarios, greatly improving the adaptability and maintainability of the system. Furthermore, by adjusting the domain-specific language description information, the interaction logic and workflow between multiple agents can be redefined.

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

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

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

[0099] Figure 12 A schematic diagram of a multi-agent orchestration device based on a service grid provided in an embodiment of the present application, wherein the service grid registers multiple agents, such as Figure 12 As shown, the device includes: an acquisition module 11 and a generation module 12.

[0100] An acquisition module 11 is configured to generate corresponding domain-specific language description information based on workflow information of the plurality of agents; The generation module 12 is used to generate routing information corresponding to the workflow information of the multiple agents based on the domain-specific language description information, and the routing information is used to define the calling relationship between the multiple agents in the service grid.

[0101] Optionally, the workflow information is a workflow diagram formed by operating the multiple agents through an interface operation, and the workflow information is a workflow description text generated through natural language description, wherein the workflow description text describes the connection relationship between the multiple agents; the acquisition module 11 is specifically configured to: parse the workflow diagram to determine the connection relationship between the multiple agents; generate the domain-specific language description information based on the attribute information and connection relationship of the multiple agents; 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 using the specific language generation model.

[0102] Optionally, the multiple agents include at least one main agent and sub-agents associated with the at least one main agent; the generation module is specifically used to: generate first routing information for accessing the at least one main agent based on the connection relationship between different main agents contained in the workflow information, and generate second routing information for accessing the sub-agents associated with each main agent based on the sub-agents associated with each main agent.

[0103] Optionally, the generation module 12 is also used to: input the description information of the target task, the attribute information of the multiple agents and the compound agent orchestration template information into the task generation model, so as to generate the compound agent corresponding to the target task through the task generation model, wherein the compound agent includes the target main agent and the sub-agents associated with the target main agent, the target main agent is one of the at least one main agent, and the agents contained in the compound agent are used to collaborate to complete the target task, and the target task is one of multiple tasks; output the compound agents corresponding to each of the multiple tasks, so that the user can generate the workflow information based on the compound agents corresponding to each of the multiple tasks, and the workflow information reflects the structure of the compound agents corresponding to each of the multiple tasks and the connection relationship between the main agents in different compound agents.

[0104] Optionally, the device further includes: a registration module for receiving an agent registration request, wherein the agent registration request includes attribute information of a target agent; and registering the target agent based on the attribute information of the target agent, wherein the target agent is any one of the multiple agents.

[0105] Figure 12 The device shown can execute the steps in the multi-agent orchestration method based on the service grid in the aforementioned embodiment. The detailed execution process and technical effects can be found in the description of the aforementioned embodiment and will not be repeated here.

[0106] The following describes in detail the multi-agent task processing device of one or more embodiments of the present application. Those skilled in the art will understand that these devices can be configured using commercially available hardware components through the steps taught in this solution.

[0107] Figure 13 A schematic diagram of a multi-agent task processing device based on a service grid provided in an embodiment of the present application is provided. The device is applied to a gateway. The service grid is registered with multiple agents, such as Figure 13 As shown, the device includes: a receiving module 13, an acquiring module 14, and a calling module 15.

[0108] A receiving module 13 is configured to receive tasks to be processed corresponding to the plurality of agents; an acquisition module 14, configured to acquire routing information corresponding to the workflow information of the plurality of agents, the routing information being used to define a calling relationship between the plurality of agents in the service grid, the routing information being generated according to the multi-agent orchestration method; The calling module 15 is used to call the multiple agents according to the routing information to execute the tasks to be processed.

[0109] Optionally, the plurality of agents include at least one main agent and sub-agents respectively associated with the at least one main agent; the routing information includes first routing information for accessing the at least one main agent, and second routing information for accessing the sub-agents respectively associated with the at least one main agent; The calling module 15 is specifically used to: in response to receiving a first task processing request to access the first agent as the main agent, send the first task processing request to the first agent according to the first routing information corresponding to the first agent; receive a second task processing request fed back by the first agent; determine the second agent for processing the second task processing request from the sub-agents associated with the first agent; and send the second task processing request to the second agent according to the second routing information corresponding to the second agent.

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

[0111] Figure 13 The device shown can execute the steps in the multi-agent task processing method based on the service grid in the aforementioned embodiment. The detailed execution process and technical effects can be found in the description of the aforementioned embodiment and will not be repeated here.

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

[0113] The memory 21 is used to store computer programs and can be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device, data structures, contact data, phone book data, messages, images, videos, etc.

[0114] The processor 22 is coupled to the memory 21 and is used to execute the computer program in the memory 21 to implement the multi-agent task processing method provided in the aforementioned embodiment.

[0115] Further, if Figure 14 As shown, the electronic device also includes: a communication component 23, a display 24, a power component 25, an audio component 26 and other components. Figure 14 Only some components are shown schematically, which does not mean that the electronic device only includes Figure 14 The electronic device of this embodiment can be implemented as a terminal device such as a desktop computer, a laptop computer, a smart phone or an IOT device, or a server device such as a conventional server, a cloud server or a server array.

[0116] The above-mentioned memory can be implemented by any type of volatile or non-volatile memory 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 memory, flash memory, magnetic disk or optical disk.

[0117] The communication component is configured to facilitate wired or wireless communication between the device in which the communication component resides and other devices. The device in which the communication component resides can access a wireless network based on a communication standard, such as a 2G, 3G, 4G / LTE, 5G, or other mobile communication network, or a combination thereof. In an exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0118] The display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can detect not only the boundaries of a touch or slide action, but also the duration and pressure associated with the touch or slide operation.

[0119] The power supply assembly provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located.

[0120] The above-mentioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC). When the device where the audio component is located is in an operating mode, such as call mode, recording mode, and voice recognition mode, the microphone is configured to receive external audio signals. The received audio signal can be further stored in the memory or sent via the communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0121] Accordingly, an embodiment of the present application also provides 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 method embodiment. The computer-readable storage medium includes volatile or non-volatile or a combination thereof, and may 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 technology, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic cassette, tape disk storage or other magnetic storage device or any other non-transmission medium. Accordingly, an embodiment of the present application further provides a computer program product, which includes a computer program or instructions, and when the computer program or instructions are executed by a processor, the processor is enabled to implement the steps in the above-mentioned method embodiment. It should be understood that each process or a combination of multiple processes in the above-mentioned method flow can be implemented by a computer program or instruction. In addition, these computer programs or instructions can be applied to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device, so that the processor of the general-purpose computer, the special-purpose computer, the embedded processor or other programmable data processing device can be implemented as a device for implementing the corresponding functions in the above-mentioned method embodiment.

[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A multi-agent orchestration method based on a service grid, wherein the service grid is registered with multiple agents, characterized in that: include: Generate corresponding domain-specific language description information based on workflow information of the plurality of agents; Based on the domain-specific language description information, routing information corresponding to the workflow information of the multiple agents is generated, and the routing information is used to define the calling relationship between the multiple agents in the service grid.

2. The method according to claim 1, characterized in that The workflow information is a workflow diagram formed by operating the multiple agents through interface operations; The generating of corresponding domain-specific language description information based on the workflow information of the plurality of agents includes: Parsing the workflow diagram to determine the connection relationship between the multiple agents; The domain-specific language description information is generated according to the attribute information and connection relationships of the multiple agents.

3. The method according to claim 1, characterized in that The workflow information is a workflow description text generated by natural language description, and the workflow description text describes the connection relationship between the multiple agents; The generating of corresponding domain-specific language description information based on the workflow information of the plurality of agents includes: The workflow description text and the attribute information of the plurality of agents are input into a specific language generation model to generate the domain-specific language description information through the specific language generation model.

4. The method according to claim 1, wherein The plurality of agents include at least one main agent and sub-agents respectively associated with the at least one main agent; The generating of routing information corresponding to the workflow information of the plurality of agents comprises: Based on the connection relationship between different main agents contained in the workflow information, first routing information for accessing at least one main agent is generated, and based on the sub-agents associated with each main agent, second routing information for accessing the sub-agents associated with each main agent is generated.

5. The method according to claim 4, characterized in that The method further comprises: Inputting the description information of the target task, the attribute information of the multiple agents, and the composite agent arrangement template information into a task generation model to generate a composite agent corresponding to the target task through the task generation model, wherein the composite agent includes a target main agent and sub-agents associated with the target main agent, the target main agent is one of the at least one main agent, and the agents contained in the composite agent are used to collaboratively complete the target task, which is one of the multiple tasks; Output the composite intelligent entities corresponding to each of the multiple tasks so that the user can generate the workflow information based on the composite intelligent entities corresponding to each of the multiple tasks. The workflow information reflects the structure of the composite intelligent entities corresponding to each of the multiple tasks and the connection relationship between the main intelligent entities in different composite intelligent entities.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: receiving an agent registration request, wherein the agent registration request includes attribute information of a target agent; The target agent is registered based on the attribute information of the target agent, where the target agent is any one of the multiple agents.

7. A multi-agent task processing method based on a service grid, characterized in that: Applied to a gateway, the service grid is registered with multiple agents, and the method includes: receiving tasks to be processed corresponding to the plurality of agents; Obtaining routing information corresponding to the workflow information of the multiple agents, the routing information being used to define a calling relationship between the multiple agents in the service grid, the routing information being generated according to any one of the methods of claims 1-6; The plurality of agents are called according to the routing information to execute the tasks to be processed.

8. The method according to claim 7, characterized in that The plurality of agents include at least one main agent and sub-agents associated with the at least one main agent; the routing information includes first routing information for accessing the at least one main agent and second routing information for accessing the sub-agents associated with the at least one main agent; The calling of the plurality of agents according to the routing information to execute the tasks to be processed comprises: In response to receiving a first task processing request for accessing a first agent serving 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; The second task processing request is sent to the second agent according to the second routing information corresponding to the second agent.

9. The method according to claim 8, characterized in that The step of determining a second agent for processing the second task processing request from sub-agents associated with the first agent includes: The attribute information of the sub-agent associated with the first agent is sent to the agent determination model, so as to determine the second agent for processing the second task processing request through the agent determination model.

10. The method according to claim 7, characterized in that Calling the plurality of agents according to the routing information to execute the tasks to be processed includes: receiving a third task processing request for accessing a target agent, wherein the target agent is any one of the plurality of agents; Determining a target intelligent agent of a target version from multiple versions corresponding to the target intelligent agent based on the feature identifier carried in the third task processing request; Based on the routing information, the third task processing request is sent to the target agent of the target version.

11. An electronic device, characterized in that: include: 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 executes the method according to any one of claims 1 to 6 or claims 7 to 10.

12. A non-transitory machine-readable storage medium, characterized in that The non-transitory machine-readable storage medium stores executable code, and when the executable code is executed by a processor of an electronic device, the processor is caused to perform the method according to any one of claims 1 to 6 or claims 7 to 10.

13. A computer program product, characterized in that include: A computer program, when executed by a processor of an electronic device, causes the processor to perform the method according to any one of claims 1 to 6, or claims 7 to 10.

Images