Multi-agent system and multi-agent dialogue management method

Abstract

The invention provides a multi-agent system and a multi-agent dialogue management method. The system comprises a main agent, a dialogue management module and a plurality of sub-agents, and the sub-agents correspond to processing of tasks in different business fields respectively; the main agent is used for calling the dialogue management module under the condition that a user request is received; the dialogue management module is used for acquiring historical information corresponding to the user request, analyzing the historical information and returning an analysis result to the main agent; the main agent is further used for determining corresponding request task data and a target sub-agent in the multiple sub-agents according to the analysis result and the user request, and sending the request task data to the target sub-agent; the sub-agent is used for processing based on the request task data, obtaining a task processing result and returning the task processing result to the main agent; and the main agent is also used for returning a corresponding natural language reply to the user according to the task processing result of the sub-agent.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a multi-agent system and a multi-agent dialogue management method. Background Technology

[0002] The integration of multi-agent systems and large language model technology has become an important development direction in the field of artificial intelligence, aiming to handle complex tasks through the collaborative work of multiple specialized intelligent agents. In this context, enabling intelligent agent systems to possess coherent and natural dialogue capabilities, and achieving efficient and adaptive resource scheduling, has become crucial for improving system usability and user experience. Especially in cross-domain task scenarios, the system needs to understand multi-turn dialogue contexts, dynamically coordinate intelligent agents from different domains, and flexibly invoke appropriate models based on task complexity, thereby optimizing response speed and computational resource consumption while ensuring task completion quality.

[0003] While existing multi-agent systems can achieve task distribution and collaboration, they typically lack deep integration with dialogue management mechanisms, making it difficult to maintain contextual coherence in multi-turn dialogues. At the same time, the systems often fail to dynamically select the appropriate language model based on the actual complexity of the task, resulting in simple tasks being handled by high-resource models or complex tasks being handled by lightweight models, leading to resource waste or decreased performance. This results in low overall resource utilization efficiency and task processing adaptability of the system. Summary of the Invention

[0004] This application provides a multi-agent system and a multi-agent dialogue management method, aiming to solve the technical problems of low overall system resource utilization efficiency and low task processing adaptability in related technologies.

[0005] In a first aspect, this application provides a multi-agent system, the system comprising: The system comprises a main intelligent agent, a dialogue management module, and multiple sub-intelligent agents, wherein the multiple sub-intelligent agents correspond to the processing of tasks in different business domains. The main intelligent agent is used to invoke the dialogue management module upon receiving a user request; The dialogue management module is used to obtain historical information corresponding to the user request, parse the historical information, and return the parsing result to the main intelligent agent; The main intelligent agent is also used to determine the corresponding request task data and the target sub-intelligent agent among multiple sub-intelligent agents based on the parsing result and the user request, and to send the request task data to the target sub-intelligent agent; The sub-agent is used to process the requested task data, obtain the task processing result, and return it to the main agent. The main agent is also used to return corresponding natural language responses to the user based on the task processing results of the sub-agents.

[0006] In some possible implementations, the sub-agent is specifically used for: Based on the requested task data, an execution plan is generated that includes at least one tool invocation node. The execution plan includes the execution logic and dependencies between the various tool invocation nodes. Based on the execution logic and the dependencies, each tool invocation node is executed sequentially; Once all tool invocation nodes have completed their execution, the task processing result is returned to the main agent based on the execution results of each tool invocation node.

[0007] In some possible implementations, the system further includes a large language model engine, and the sub-agent is specifically used for: Based on the execution logic and the dependencies, determine the nodes in each tool call node that require processing by the large language model; For the node in question, a request is sent to the large language model engine. The large language model engine is used to select a suitable model instance from multiple pre-mounted large language models to process the node based on the call request.

[0008] In some possible implementations, the invocation request includes fine-grained complexity information determined based on the business logic of the node, and the large language model engine is specifically used for: Receive a call request and parse it to obtain the fine-grained complexity information in the call request; Based on the preset complexity level mapping rules, the model type requirements corresponding to the fine-grained complexity information are determined; Obtain the runtime status indicators corresponding to each pre-mounted large language model; Based on the model type requirements and the various operational status indicators, a suitable model instance is selected from multiple pre-mounted large language models to process the node.

[0009] In some possible implementations, the large language model engine is specifically used for: Based on the model type requirements, a large language model that meets the model type requirements is determined, resulting in a model set; Based on the running status indicators of each model in the model set, a preset load balancing scheduling strategy is executed to determine the target model instance with the optimal load in the model set. The node is processed using the target model instance.

[0010] In some possible implementations, the dialogue management module includes a dialogue context storage unit, a memory unit, and a dialogue context understanding unit; A context storage unit is used to obtain the session identifier corresponding to the user request and retrieve the corresponding dialogue history based on the session identifier. A memory unit is used to obtain the user identifier corresponding to the user request and retrieve the corresponding user historical data based on the user identifier. The dialogue context understanding unit is used to obtain and return the parsing result to the main agent based on the user request, the dialogue history, and the user history data.

[0011] In some possible implementations, the memory unit is specifically used for: Based on the user identifier, the historical execution result records associated with the user are retrieved; Based on the user identifier, a user profile map constructed based on the user's long-term behavioral preferences is retrieved; The historical execution results and the user profile diagram are used to obtain historical user data.

[0012] In some possible implementations, the dialogue context understanding unit is specifically used for: The user request, the dialogue history, and the user history data are concatenated according to a preset format to obtain the model input content; The input content of the model is input into a preset large language model, and the parsing result is obtained and returned to the main intelligent agent.

[0013] In some possible implementations, the main intelligent agent is specifically used for: Extract the intent type of the user request from the parsing results; Based on the intent type, a preset sub-agent registry is queried to determine the target sub-agent among multiple sub-agents that corresponds to the intent type; The user request and the parsing result are encapsulated to generate request task data; Send the request task data to the target sub-agent.

[0014] Secondly, this application provides a multi-agent dialogue management method, which is applied to the multi-agent system described above, and the method includes: Upon receiving a user request, the dialogue management module is invoked to obtain the historical information corresponding to the user request, and the historical information is parsed to obtain the parsing result. Based on the parsing results and the user request, determine the corresponding request task data and the target sub-agent among multiple sub-agents; The target sub-agent processes the requested task data to obtain the task processing result; The system returns a corresponding natural language response to the user based on the task processing result.

[0015] The multi-agent system and multi-agent dialogue management method provided in this application embodiment, through the main agent calling the dialogue management module upon receiving a user request, enables the system to understand the current request based on the complete dialogue context, ensuring continuity in multi-turn interactions. The main agent accurately determines the target sub-agent suitable for the corresponding task based on the analysis results, avoiding capability mismatch and resource waste. While efficiently completing complex tasks, it can generate natural language responses consistent with the dialogue history, thereby improving the overall resource utilization efficiency and task processing adaptability of the multi-agent system. Attached Figure Description

[0016] This application can be better understood from the following description of specific embodiments in conjunction with the accompanying drawings, wherein: Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings, wherein the same or similar reference numerals denote the same or similar features.

[0017] Figure 1 This is a flowchart and timing diagram of a multi-agent system provided in one embodiment of this application; Figure 2 This is a flowchart and timing diagram of a multi-agent system provided in another embodiment of this application; Figure 3 This is a flowchart and timing diagram of a multi-agent system provided in another embodiment of this application; Figure 4 This is a flowchart of a multi-agent dialogue management method provided in one embodiment of this application; Figure 5 This is a schematic diagram of a multi-agent system provided in one embodiment of this application; Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0020] Multi-Agent System (MAS): A collection of multiple autonomous agents.

[0021] Large Language Model (LLM) is a probabilistic generative model that is pre-trained on text and can understand and generate natural language text that is close to human language.

[0022] Natural Language Understanding (NLU) is a branch of artificial intelligence that uses language to interpret the intent, emotion, and contextual meaning of human language.

[0023] Dialogue Manager (DM): This is the core control module responsible for coordinating user input, maintaining the dialogue state, and determining the next response.

[0024] Master Agent (MA): The core decision-making layer in a multi-agent system, responsible for coordinating the resources of sub-agents and integrating information flow.

[0025] Sub-Agent (SA): A specialized functional module scheduled by the master agent, which focuses on performing specific tasks and feeds back the results to the upper-level decision-making unit.

[0026] In existing technologies, multi-agent systems are not deeply integrated with dialogue management mechanisms, making it difficult to effectively connect contextual information in multi-turn dialogue scenarios, especially resulting in poor coherence in cross-domain tasks. Multi-agent systems cannot dynamically select appropriate models based on task complexity, leading to situations where simple tasks call complex models or complex tasks are distributed to lightweight models, resulting in resource waste or poor task execution. Addressing existing technologies presents two main technical challenges: first, how to deeply integrate multi-agent architecture with dialogue management mechanisms to achieve smooth multi-turn dialogue, especially cross-domain multi-turn dialogue; and second, how multi-agent systems can dynamically select appropriate models based on task complexity to avoid resource waste or insufficient processing power, thereby improving resource utilization efficiency and task processing adaptability.

[0027] To address the problems of the prior art, embodiments of this application provide a multi-agent system and a multi-agent dialogue management method. The multi-agent system provided in this application embodiment is described below.

[0028] Figure 1 A flowchart and timing diagram of a multi-agent system provided in one embodiment of this application is shown. Figure 1 As shown, the system includes a main intelligent agent 001, a dialogue management module 002, and multiple sub-intelligent agents 003, wherein the multiple sub-intelligent agents correspond to the processing of tasks in different business domains. The specific execution flow of the system includes: S101 to S105.

[0029] S101: The main intelligent agent, which calls the dialogue management module upon receiving a user request.

[0030] S102: Dialogue management module, used to obtain historical information corresponding to user requests, parse the historical information, and return the parsing results to the main intelligent agent.

[0031] S103: The main intelligent agent determines the corresponding request task data and the target sub-intelligent agent among multiple sub-intelligent agents based on the parsing results and user requests, and sends the request task data to the target sub-intelligent agent.

[0032] S104: Sub-agent, which processes the requested task data and returns the task processing result to the main agent.

[0033] S105: The main agent returns a corresponding natural language response to the user based on the task processing results of the sub-agents.

[0034] In the specific implementation of S101, when input from the user is received, the main agent first performs simple preprocessing on the input, such as checking whether it is a valid request or identifying the request type. If the request is determined to be valid, the main agent will issue a call instruction to the dialogue management module 002, requesting the dialogue management module to obtain and parse the historical information related to the request.

[0035] In the specific implementation of S102, the dialogue management module extracts records related to the current user's request from the historical data stored in the system, such as past dialogue logs, user's historical behavior, or preference settings. The dialogue management module needs to use natural language processing techniques (such as text matching and entity recognition) to parse the historical data in order to understand the user's intent and the context of the request, and then pass the parsing results to the main intelligent agent. The parsing results may include similar questions the user has asked before, the user's preference settings, or specific historical interaction patterns.

[0036] In the specific implementation of S103, based on the parsing results obtained in step S102 and the user's current request, the main agent 001 will analyze this information to determine the specific task data and processing path. In this step, the main agent needs to select the most suitable target sub-agent from multiple sub-agents 003 for task processing. The main agent will match the most relevant business domain tasks based on the content of the user's request and historical information, and then decide on the selection of the target sub-agent. At this point, the main agent not only needs to determine the priority and complexity of the task, but also needs to effectively allocate tasks based on the sub-agents' areas of expertise.

[0037] In the specific implementation of S104, after receiving the request task data from the main agent, sub-agent 003 executes the corresponding processing tasks based on this data. The sub-agent focuses on task processing within a specific business domain, possessing corresponding business logic and algorithms to complete the user request. The task processing may include operations such as data querying, calculation, and matching. After completing the task, the sub-agent returns the processing result to the main agent so that the main agent can further generate a response.

[0038] In the specific implementation of S105, the main agent 001 generates a natural language response based on the task processing results returned by the sub-agents and delivers it to the user. This process includes converting the data returned by the sub-agents into a natural language format that the user can understand. The main agent will appropriately format and express the task processing results according to the context and language of the user's request, ensuring that the user receives a clear and accurate answer. The role of the main agent is to convert technical data into easily understandable language and provide feedback to the user in an appropriate manner.

[0039] The multi-agent system provided in this application, upon receiving a user request, invokes a dialogue management module. This module actively retrieves and parses structured historical information and user profiles, enabling the system to understand the current request based on the complete dialogue context and ensuring continuity in multi-turn interactions. The main agent accurately determines the suitable target sub-agent for the corresponding task based on the parsing results, avoiding capability mismatch and resource waste. While efficiently completing complex tasks, it can generate natural language responses consistent with the dialogue history, thereby improving the overall resource utilization efficiency and task processing adaptability of the multi-agent system.

[0040] In order to perform efficient processing, sub-agent 003 can specifically be used to execute the following steps: S1041 to S1043.

[0041] S1041: Based on the request task data, generate an execution plan containing at least one tool call node. The execution plan includes the execution logic and dependencies between the various tool call nodes.

[0042] S1042: Based on the execution logic and dependencies, execute each tool call node in sequence.

[0043] S1043: After all tool calling nodes have completed execution, return the task processing result to the main agent based on the execution results of each tool calling node.

[0044] In the specific implementation of S1041, the sub-agent 003 first needs to generate an execution plan based on the received request task data. This execution plan contains multiple tool invocation nodes, which represent the specific tools or modules that the sub-agent needs to invoke when processing the task. Each tool invocation node corresponds to a specific function or computational task, such as database querying, computation, or data formatting. The execution plan not only lists the required tool nodes but also clarifies their execution logic and dependencies—that is, which nodes need to be executed first and which can be executed in parallel. The determination of dependencies is usually determined by the complexity of the task and the collaborative relationships between different tools. For example, when generating the execution plan, the sub-agent analyzes the request task data and automatically selects appropriate tool nodes based on the task type. In the execution plan, the dependencies between nodes are clearly defined; for example, some nodes may need to be executed only after other nodes have completed, or some nodes must be executed in parallel to improve efficiency.

[0045] In the specific implementation of S1042, sub-agent 003, based on the aforementioned generated execution plan, begins to execute each tool invocation node sequentially according to the defined execution logic and dependencies. The execution order is arranged according to the dependencies between nodes, ensuring that subsequent nodes can only begin execution if the previous node has executed successfully. For example, if a tool invocation node in the execution plan depends on the output of a previous node, then subsequent nodes can only begin after the previous node has successfully executed and returned a result. The sub-agent will initiate calls to the corresponding tool modules based on the function of each node, executing specific operations.

[0046] In the specific implementation of S1043, sub-agent 003 will synthesize the final task processing result based on the execution results of each node. These results may be the single output of multiple tool nodes, or they may be the summary or processed data of the outputs of each node. The sub-agent organizes these processing results into a standardized data format and returns them to the master agent 001 for further processing. For example, the sub-agent will check and verify the execution result of each node to ensure that all dependent tool calls have been successfully executed and the results meet expectations. If the execution result of a node is abnormal, the sub-agent may take certain abnormal handling measures, such as re-execution or calling backup tools. After all nodes have completed execution and the results are valid, the sub-agent will package the final task result into a data format suitable for the master agent to process and send it to the master agent.

[0047] The above-described implementation methods of this application, by generating execution plans, calling execution tool nodes, and finally feeding back the processing results to the main intelligent agent, can efficiently and accurately execute complex tasks and ensure that the dependencies between various tools are handled correctly, thereby achieving precise system response and efficient operation, thus decomposing tasks for efficient processing.

[0048] In order to perform reasonable processing through a large language model engine, refer to Figure 2 The system also includes a large language model engine 004 and a sub-agent 003, which can be used to execute the following steps: S201 to S202.

[0049] S201: Based on the execution logic and dependencies, determine the nodes in each tool call node that require processing by the large language model.

[0050] S202: For the node, a request is sent to the large language model engine.

[0051] Large Language Model Engine 004, used in S203: Selects the appropriate model instance from multiple pre-mounted large language models to process the node based on the call request.

[0052] In the specific implementation of S201, sub-agent 003 analyzes the tool call nodes in the execution plan based on the aforementioned generated execution logic and dependencies, and identifies the nodes that need to be processed by the large language model engine 004. It evaluates the functionality and task requirements of each tool call node. Based on the task type, complexity, and characteristics of the input data, the sub-agent determines which nodes are suitable or must be processed by the large language model. Specifically, the sub-agent compares each tool call node with preset processing requirements to determine which nodes involve tasks such as natural language processing, text analysis, and semantic understanding. For example, if a node needs to understand the user's natural language request and extract key information, or needs to generate a detailed text response based on context, these tasks will be marked as nodes that require processing by the large language model.

[0053] In the specific implementation of S202, sub-agent 003 identifies the node that needs processing by the large language model and initiates a request to the large language model engine 004 based on the task requirements of that node. At this point, the sub-agent constructs a request data packet containing a detailed task description of the node, the input data to be processed, and the expected output format of the processing result. The data in the request is then transmitted to the large language model engine so that the engine can select a suitable model instance for processing.

[0054] In the specific implementation of S203, the large language model engine 004 selects an appropriate large language model instance to process the target node based on the invocation request from the sub-agent 003. The large language model engine contains multiple pre-mounted large language models, which have different adaptability and effects in different tasks and scenarios. The large language model engine evaluates the specific requirements of each request and selects the most suitable model instance to perform processing based on factors such as the nature of the task, the complexity of the data, and response time. For example, if a node needs to generate an article based on a user-provided topic, the sub-agent 003 will pass the user's request to the large language model engine, which will then select a language model instance with strong text generation capabilities based on the task content to generate the required article content.

[0055] The embodiments described above in this application automatically process complex natural language tasks through the collaboration of sub-agents using a large language model engine. Through automated system invocation, model selection, and task processing, the entire process achieves efficient task execution and accurate response generation, with appropriate processing performed by the large language model engine.

[0056] In order to select a reasonable large language model for processing, the call request includes fine-grained complexity information determined according to the business logic of the node. The large language model engine 004 can be used to execute the following steps: S2031 to S2034.

[0057] S2031: Receive the call request and parse the fine-grained complexity information in the call request.

[0058] S2032: Determine the model type requirements corresponding to the fine-grained complexity information according to the preset complexity level mapping rules.

[0059] S2033: Obtain the runtime status indicators corresponding to each pre-mounted large language model.

[0060] S2034: Based on the model type requirements and various operational status indicators, select the appropriate model instance from multiple pre-mounted large language models to process the node.

[0061] In the specific implementation of S2031, the large language model engine 004 receives call requests from sub-agent 003 or other modules. These call requests contain a set of key information, one of which is fine-grained complexity information. This information details the complexity level and processing difficulty of the current task, typically including various parameters from the business logic, such as data size, task type, and the complexity of dependencies.

[0062] In the specific implementation of S2032, the large language model engine 004 determines the required model type based on fine-grained complexity information and predefined complexity level mapping rules. These mapping rules are a set of predefined rules that can map different levels of complexity information to appropriate model types. Complexity levels are typically divided into multiple tiers, each corresponding to different task processing requirements.

[0063] In the specific implementation of S2033, the large language model engine 004 queries and collects runtime status metrics for all pre-mounted large language models within it. These metrics typically include, but are not limited to, the model's current load, processing power, response time, memory usage, computational resource consumption, and model health status. The engine periodically checks the runtime status of each model using built-in monitoring tools or management modules. Through these runtime status metrics, the engine can understand the performance and health status of each model in real time, providing a basis for subsequent model selection decisions. For example, if one model has an abnormally delayed response time while another model has normal memory usage, the system may tend to select the latter to handle the current task.

[0064] In the specific implementation of S2034, the large language model engine 004 selects the most suitable model instance from multiple pre-mounted language models to handle the current node's task based on the previously obtained model type requirements and runtime status indicators. Specifically, based on the model type requirements, models that can meet the task requirements are selected. For example, if the task requires text generation, the engine will prioritize models with strong generation capabilities; if the task requires classification, it will select models suitable for classification. Next, based on the runtime status indicators of each model, such as performance, resource consumption, and response time, a model with optimal performance is further selected. For example, among multiple models that meet the task requirements, if a model has a good runtime status and a fast response speed, that model will be selected first.

[0065] The embodiments described above in this application utilize a large language model engine to intelligently select appropriate model instances to efficiently process tasks based on fine-grained complexity information and runtime status indicators. Through this intelligent selection and scheduling, processing efficiency and resource utilization can be maximized while ensuring task quality, by selecting a suitable large language model for processing.

[0066] In order to optimize the use of system resources, the large language model engine 004 can be used to perform the following steps: S20341 to S20343.

[0067] S20341: Based on the model type requirements, determine the large language models that meet the model type requirements to obtain the model set.

[0068] S20342: Based on the running status indicators of each model in the model set, execute the preset load balancing scheduling strategy to determine the target model instance with the optimal load in the model set.

[0069] S20343: Process nodes through target model instances.

[0070] In the specific implementation of S20341, the large language model engine 004 selects models from its pre-loaded large language models that can meet the current task requirements, forming a model set based on model type requirements. Model type requirements refer to the specific model capabilities required by the task, such as whether text generation, classification, reasoning, etc., are needed.

[0071] In the specific implementation of S20342, the large language model engine 004 will execute a set of preset load balancing scheduling strategies based on the running status indicators of each model in the model set to determine the target model instance with the optimal load. Running status indicators refer to indicators that reflect the current running status of each model, which typically include the model's load (such as computing resource usage), memory usage, response time, processing capacity, etc.

[0072] In the specific implementation of S20343, the large language model engine 004 uses the determined target model instance to process the target node. The target model instance refers to the optimal model selected in the previous stage through a load balancing strategy, while the node refers to the task or data unit that needs to be processed. The large language model engine 004 assigns tasks to the target model instance for specific calculations or processing. After selecting the aforementioned target model instance, the large language model engine 004 directly passes the task to that model for processing.

[0073] The embodiments described above intelligently select appropriate models for task processing using the large language model engine 004, while ensuring high performance under high load through a load balancing mechanism. This process helps improve task processing efficiency and optimize the use of system resources.

[0074] In order to accurately obtain historical information, refer to Figure 3 The dialogue management module 002 includes a dialogue context storage unit 0021, a memory unit 0022, and a dialogue context understanding unit 0023. The specific execution flow includes: S301 to S303.

[0075] S301: Context storage unit, used to obtain the session identifier corresponding to the user request and retrieve the corresponding dialogue history based on the session identifier.

[0076] S302: Memory unit, used to obtain the user identifier corresponding to the user request and retrieve the corresponding user historical data based on the user identifier.

[0077] S303: Dialogue Context Understanding Unit, used to obtain and return the parsing results to the main agent based on user requests, dialogue history, and user historical data.

[0078] In the specific implementation of S301, the session identifier associated with the current session is first obtained, and then this identifier is used to retrieve the related dialogue history. The session identifier is a unique identifier used to identify all interaction records from the beginning to the end of a session. Whenever a user initiates a dialogue, the system generates a new session identifier and saves it in correspondence with all the interaction data of the session.

[0079] In the specific implementation of S302, memory unit 0022 retrieves the user identifier associated with the user from the system according to the user's request, and uses this identifier to retrieve the user's historical data. The user identifier is a unique identifier that identifies the user, typically the user's account ID, mobile phone number, or other identity identifier. User historical data includes all past interactions with the system, personal preferences, interests, known issues, and previous requests.

[0080] In the specific implementation of S303, the dialogue context understanding unit 0023 comprehensively analyzes user requests, dialogue history, and user historical data, and generates the final parsing result, which is then returned to the main agent. If the user's request is based on a previous question or answer, the system will recognize this dependency. For example, if the user's question is "What is the answer to the question I asked last time?", the system will use the context understanding unit to identify that the question is related to the previous dialogue and return the previous answer. Simultaneously, the system will also combine user historical data to determine the user's possible intentions, such as the user's common questions or preferred answering methods.

[0081] The embodiments described above in this application obtain the session identifier corresponding to the user request, retrieve the corresponding dialogue history based on the session identifier, obtain the user identifier corresponding to the user request, retrieve the corresponding user history data based on the user identifier, and thus obtain and return the parsing result to the main intelligent agent based on the user request, dialogue history, and user history data. The dialogue management module 002 can effectively track the user's dialogue history and behavioral characteristics, providing contextual understanding and personalized responses for each interaction. This ensures that the system can understand and respond to user needs in continuous dialogue, improve user experience, and accurately obtain historical information.

[0082] In order to obtain accurate user history data, memory unit 0022 can be used to perform the following steps: S3021 to S3023.

[0083] S3021: Retrieve historical execution result records associated with the user based on the user identifier.

[0084] S3022: Based on the user identifier, retrieve the user profile map constructed based on the user's long-term behavioral preferences.

[0085] S3023: Obtain historical user data based on historical execution result records and user profile diagrams.

[0086] In the specific implementation of S3021, historical execution result records related to the user are retrieved using a user identifier. The user identifier is a unique identifier that identifies the user, typically the user's account ID, device ID, or other similar identifier. Historical execution result records refer to the user's interaction history with the system, including questions asked in past conversations, the system's responses, and any form of interaction execution result.

[0087] In the specific implementation of S3022, memory unit 0022 retrieves the user profile map from the database using the user identifier. The user profile map is a comprehensive data set constructed based on long-term user behavior data, covering the user's interests, behavior patterns, preference settings, purchase records, etc.

[0088] In the specific implementation of S3023, memory unit 0022 combines the historical execution result records retrieved in the first two steps with the user profile map to generate user history data. User history data is a comprehensive result, containing all past user interaction records and personalized behavioral characteristics. This data will provide the system with user behavior patterns, interests, and user-related historical content, thereby providing more targeted and personalized responses in future conversations.

[0089] The embodiments described above in this application retrieve historical execution result records associated with a user based on the user identifier; retrieve a user profile map constructed based on the user's long-term behavioral preferences based on the user identifier; and then obtain user historical data based on the historical execution result records and the user profile map. This allows for a comprehensive understanding and recording of the user's historical behavior and preference data, and the generation of user historical data by combining this information. This data will greatly improve the accuracy and personalization of the system's response in subsequent interactions, enhance the user experience, and obtain accurate user historical data.

[0090] In order to perform accurate parsing, the dialogue context understanding unit 0023 can be used to perform the following steps: S3031 to S3032.

[0091] S3031: Concatenate user requests, dialogue history, and user history data according to a preset format to obtain the model input content.

[0092] S3032: Input the model input content into the preset large language model, obtain and return the parsing result to the main agent.

[0093] In the specific implementation of S3031, user requests, dialogue history, and user historical data are concatenated together according to a preset format to generate the model input content. Specifically, user requests refer to the user's current input content; dialogue history refers to previous conversations with the user, typically including the user's questions and the system's answers; and user historical data includes the user's behavioral preferences, personalized needs, and past interaction records.

[0094] In the specific implementation of S3031, the model input content generated in S3031 is fed into a preset large language model for processing. The large language model is a deep learning-based natural language processing model capable of understanding and generating natural language through training data, thereby generating answers or suggestions that fit the context. After inputting the content, the model parses the current user's request based on the provided information and the language rules and knowledge acquired during its training. After parsing, the system returns these results to the main agent, which can further process the parsed results or present them to the user.

[0095] The above-described implementation of this application's embodiments obtains model input content by splicing user requests, dialogue history, and user historical data according to a preset format. The model input content is then input into a preset large language model, and the parsing result is obtained and returned to the main intelligent agent. This effectively integrates user requests, historical dialogues, and user preferences to generate accurate model input. The most suitable answer or feedback is obtained through parsing by the large language model, and accurate parsing is performed using the large language model.

[0096] In order to provide a suitable response, the main agent 001 may specifically perform the following steps: S1031 to S1034.

[0097] S1031: Extract the intent type of the user request from the parsing results.

[0098] S1032: Based on the intent type, query the preset sub-agent registry to determine the target sub-agent among multiple sub-agents that corresponds to the intent type.

[0099] S1033: Encapsulate user requests and parsing results to generate request task data.

[0100] S1034: Send request task data to the target sub-agent.

[0101] In the specific implementation of S1031, the intent type of the user request is extracted from the parsing results. The intent type of the user request refers to the core need or goal behind the user request, which usually includes different intents such as inquiry, command, and suggestion. In the implementation process, the system analyzes the parsing results, identifies the intents, and classifies them.

[0102] In the specific implementation of S1032, the main agent 001 queries the pre-defined sub-agent registry in the system based on the intent type extracted in S1031 to determine the target sub-agent corresponding to that intent type. The sub-agent registry is a table or database storing information about all available sub-agents in the system, where the function or service of each sub-agent is associated with a specific intent type. The target sub-agent is a subsystem capable of handling a specific intent. For example, if the user's request is identified as "weather query" in step S1031, the main agent 001 will query the sub-agent registry to find a target sub-agent that specializes in handling weather queries, such as the weather query sub-agent. If the user requests "play music," a music playback sub-agent will be selected. This step ensures that the request is sent to the most appropriate sub-agent, thereby improving the efficiency and accuracy of the system response.

[0103] In the specific implementation of S1033, the main agent 001 encapsulates the user's original request and the parsing result into request task data, and creates a standardized data packet for this task. Request task data is a data structure containing user request information, intent type, parsing result, and other necessary metadata, providing the sub-agents with all the information needed to execute the task.

[0104] In the specific implementation of S1034, the main agent 001 sends the request task data to the identified target sub-agent for processing. This operation can be completed through the system's internal communication mechanism. The target sub-agent executes the corresponding operation based on the received task data and returns the result.

[0105] The above-described implementation method of this application extracts the intent type of the user request from the parsing result, then queries a preset sub-agent registry based on the intent type to determine the target sub-agent among multiple sub-agents that corresponds to the intent type, and then encapsulates the user request and parsing result to generate request task data, thereby sending the request task data to the target sub-agent. This achieves accurate parsing of user requests, appropriate sub-agent matching, and efficient task execution, ensuring that the system can provide the most suitable response according to different request types.

[0106] As an example, a multi-agent dialogue management method is provided, which is applied to a multi-agent system. (Refer to...) Figure 4 The method includes the following steps: S401 to S104.

[0107] S401: Upon receiving a user request, the dialog management module is invoked to obtain the historical information corresponding to the user request, and the historical information is parsed to obtain the parsing result.

[0108] S402: Based on the parsing results and the user request, determine the corresponding request task data and the target sub-agent among multiple sub-agents.

[0109] S403: Process the requested task data based on the target sub-agent to obtain the task processing result.

[0110] S404: Return the corresponding natural language response to the user based on the task processing result.

[0111] In the specific implementation of S401, a request from the user is first received, usually in the form of text or voice. After receiving the request, the main AI calls the dialogue management module, whose main function is to manage the user's dialogue history and extract historical data related to the current user request.

[0112] In the specific implementation of S402, the parsing results obtained from S401 and the user request are combined to determine the request task data that needs to be processed, and the appropriate target sub-agent is selected from multiple sub-agents based on this information.

[0113] In the specific implementation of S403, the requested task data is passed to the selected target sub-agent, and the task is processed according to the capabilities of that sub-agent. Each sub-agent is typically a small module with specific functions, capable of performing tasks based on the received data.

[0114] In the specific implementation of S404, a corresponding natural language response is generated based on the task processing results and returned to the user. This process includes converting the results processed by the target sub-agent into a natural language form that is easy for the user to understand.

[0115] The multi-agent dialogue management method provided in this application involves the main agent invoking a dialogue management module upon receiving a user request. This module actively retrieves and parses structured historical information and user profiles, enabling the system to understand the current request based on the complete dialogue context and ensuring continuity in multi-turn interactions. The main agent accurately determines the target sub-agent suitable for the corresponding task based on the parsing results, avoiding capability mismatch and resource waste. While efficiently completing complex tasks, it can generate natural language responses consistent with the dialogue history, thereby improving the overall resource utilization efficiency and task processing adaptability of the multi-agent system.

[0116] In one embodiment of this application, the multi-agent system architecture is as follows: Figure 5As shown, the system is divided into three layers: MA, SA, and Tools, including two core components: DM and LLM engines. MA is the entry point for the entire system, acting as the central controller of the multi-agent system. When a user request is received, MA first analyzes the task complexity to determine whether it is a simple or complex task; it then understands the request based on the context and distributes it to the corresponding SA. If no matching SA is found, MA provides a fallback response. After completing the task, the SA needs to send the result back to MA for unified dialogue management. Each SA focuses on a specific business domain and can utilize different toolsets and knowledge bases to understand and process tasks within that domain. Tasks handled by the SA include: multi-turn dialogue within the business domain, NLU intent recognition, and slot extraction.

[0117] The Tools layer is a collection of tools for implementing business logic. In multi-agent systems, collaboration between agents is achieved through agent tools. When a new SA (Service Agent) for a business domain is added, this SA is also registered in the Tools layer for other SAs to call when needed. It supports serial, parallel, and Directed Acyclic Graph (DAG) calls between Tools. Serial Tool calls are suitable for scenarios where the input of the current Tool depends on the execution results of previous Tools, forming a sequential chain of calls. Parallel Tool calls are suitable for scenarios where Tools are independent of each other, with all Tools executing in parallel and then summarizing the results. DAG calls are suitable for more complex scenarios where single serial or parallel calls cannot meet the requirements. DAG calls are very flexible, allowing for flexible scheduling based on dependencies, and can be performed in parallel or serially.

[0118] In the system, the main function of DM is to uniformly maintain the dialogue context information of MAS, ensuring MAS's understanding and consistency of multi-turn interactions, especially cross-domain multi-turn interactions. The LLM engine has two functions: first, it selects the most suitable model from multiple pre-mounted models for inference based on task complexity, improving the resource utilization efficiency and task processing adaptability of MAS; second, in high-concurrency scenarios, it dynamically adjusts the scheduling strategy based on the current load and response time of each model to ensure the overall throughput and stability of the system.

[0119] MA is used to maintain dialogue context information to enable multi-turn semantic inheritance dialogue, especially context inheritance in cross-domain multi-turn dialogue. This module mainly includes: a dialogue context storage unit, a memory unit, and a dialogue context understanding unit.

[0120] For example, a travel assistant developed around MAS includes three areas: ticket booking, hotel booking, and travel planning, illustrating the role of the unified DM module in cross-domain multi-turn dialogues.

[0121] The user's first request is: "I want to travel to Chengdu for three days from Beijing. Please create a travel itinerary for me." The Marketing Assistant (MA) interprets this as a travel planning task, distributes it to the Travel Planning Assistant (SA), and calls upon a toolset to generate a travel report. After the travel report is generated, the SA feeds the results back to the MA. The context storage unit in the DM stores the current user request and the natural language summary of the travel report as dialogue history, while the memory unit stores the complete JSON result of the travel report.

[0122] The user's second request is: "Adjust the itinerary for day three; I want to go hiking." MA interprets this as a travel planning task based on the dialogue context and retrieves the previous round's travel report results from the memory unit to ensure that only the third day's itinerary is adjusted. After the travel report is generated again, the context storage unit stores the current user request and the natural language description summary of the travel report as dialogue history, while the memory unit stores the complete JSON result of the travel report and records the user's preference for hiking.

[0123] The user's third request is: "Please book a hotel for me, based on the overall itinerary." The MA interprets this as a hotel booking task based on the dialogue context and associates it with the user's first request "to Chengdu," extracting the hotel booking city as Chengdu. Then, it retrieves the previous round's travel report from the memory unit, obtains the structured itinerary, and distributes it to the hotel booking SA. After the hotel booking SA recommends a hotel, the context storage unit stores the current round's user request and the natural language description summary of the hotel recommendation as dialogue history, while the memory unit stores the complete JSON result of the recommended hotel.

[0124] The user's fourth round request is: "Book me a flight." MA combines the context of the dialogue and relates it to the user's first round request, "Departing from Beijing, go to Chengdu for three days and create a travel itinerary for me," interpreting it as a ticket booking task. It extracts the departure point as Beijing and the destination as Chengdu, and performs a flight booking. After the ticket booking, the context storage unit stores the current round user request and the natural language description summary of the ticket booking as dialogue history, while the memory unit stores the complete JSON result of the ticket booking.

[0125] Each agent is a pre-packaged task execution unit, including task definition, input / output format, constraints, etc. Calls to different agents, and even different calls to the same agent, can be executed using different LLMs. The LLM engine selects the most suitable model for the current task from the pre-mounted LLMs based on the task complexity definition, achieving an optimal balance between inference performance and resource consumption. This ensures the agent's functionality while improving the MAS's resource utilization efficiency and task processing adaptability.

[0126] The Management Controller (MA) is responsible for receiving user input task descriptions, classifying task complexity, managing SA registration, NLU domain distribution, task scheduling, cross-SA coordination, and execution result aggregation. The SA receives tasks distributed by the MA, performs fine-grained complexity assessment and execution plan generation, dynamically selects LLM execution DAG nodes, performs business-level result verification, and reports the execution results to the MA.

[0127] In the specific execution process of a task in MAS, firstly, MA performs a detailed analysis of the task description input by the user, classifies the task difficulty according to the task description and predefined task levels, and then identifies the SA that the task needs to call based on the task description and SA registry, and distributes the SA.

[0128] The Service Controller (SA) receives tasks and performs a more granular evaluation based on the task complexity classification according to the business definition and MA input, such as generating a Directed Acyclic Graph (DAG) for Tool calls and fine-grained complexity. At runtime, it dynamically selects an LLM (Limited Module Manager) from the LLM engine to execute the task based on node complexity and system strategy. Alternatively, the LLM-driven Tools can be classified by task complexity. Then, when executing business logic, the LLM-driven Tools dynamically select an LLM from the LLM engine to complete the task based on its difficulty, further improving the granularity of resource scheduling and the flexibility of system response.

[0129] After the system enters a stable operating phase, the LLM engine scheduler continuously monitors key metrics for each LLM instance, including utilization, memory usage, average response latency, and queue length. When it detects that a model instance is overloaded or its response latency has increased significantly, the scheduler will execute optimization strategies. For example, model switching will automatically switch some pending requests to an equivalent LLM with a lower load; rollback strategies will automatically downgrade non-critical tasks or minor calls to a more lightweight model to protect the resource priority of critical tasks.

[0130] Furthermore, in conjunction with the multi-agent dialogue management methods described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the multi-agent dialogue management methods described in the above embodiments.

[0131] This application also provides a computer program product, including a computer program, which, when executed, implements any of the multi-agent dialogue management methods described in the above embodiments.

[0132] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0133] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0134] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0135] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can also be implemented by an FPGA performing the specified functions or actions, or can be implemented by a combination of an FPGA and computer instructions.

[0136] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A multi-agent system, characterized in that, The system includes: The system comprises a main intelligent agent, a dialogue management module, and multiple sub-intelligent agents, wherein the multiple sub-intelligent agents correspond to the processing of tasks in different business domains. The main intelligent agent is used to invoke the dialogue management module upon receiving a user request; The dialogue management module is used to obtain historical information corresponding to the user request, parse the historical information, and return the parsing result to the main intelligent agent; The main intelligent agent is also used to determine the corresponding request task data and the target sub-intelligent agent among multiple sub-intelligent agents based on the parsing result and the user request, and to send the request task data to the target sub-intelligent agent; The sub-agent is used to process the requested task data, obtain the task processing result, and return it to the main agent. The main agent is also used to return corresponding natural language responses to the user based on the task processing results of the sub-agents.

2. The multi-agent system according to claim 1, characterized in that, The sub-agent is specifically used for: Based on the requested task data, an execution plan is generated that includes at least one tool invocation node. The execution plan includes the execution logic and dependencies between the various tool invocation nodes. Based on the execution logic and the dependencies, each tool invocation node is executed sequentially; Once all tool invocation nodes have completed their execution, the task processing result is returned to the main agent based on the execution results of each tool invocation node.

3. The multi-agent system according to claim 2, characterized in that, The system also includes a large language model engine, and the sub-agent is specifically used for: Based on the execution logic and the dependencies, determine the nodes in each tool call node that require processing by the large language model; For the node in question, a request is sent to the large language model engine. The large language model engine is used to select a suitable model instance from multiple pre-mounted large language models to process the node based on the call request.

4. The multi-agent system according to claim 3, characterized in that, The invocation request includes fine-grained complexity information determined based on the business logic of the node. The large language model engine is specifically used for: Receive a call request and parse it to obtain the fine-grained complexity information in the call request; Based on the preset complexity level mapping rules, the model type requirements corresponding to the fine-grained complexity information are determined; Obtain the runtime status indicators corresponding to each pre-mounted large language model; Based on the model type requirements and the various operational status indicators, a suitable model instance is selected from multiple pre-mounted large language models to process the node.

5. The multi-agent system according to claim 4, characterized in that, The large language model engine is specifically used for: Based on the model type requirements, a large language model that meets the model type requirements is determined, resulting in a model set; Based on the running status indicators of each model in the model set, a preset load balancing scheduling strategy is executed to determine the target model instance with the optimal load in the model set. The node is processed using the target model instance.

6. The multi-agent system according to claim 1, characterized in that, The dialogue management module includes a dialogue context storage unit, a memory unit, and a dialogue context understanding unit; A context storage unit is used to obtain the session identifier corresponding to the user request and retrieve the corresponding dialogue history based on the session identifier. A memory unit is used to obtain the user identifier corresponding to the user request and retrieve the corresponding user historical data based on the user identifier. The dialogue context understanding unit is used to obtain and return the parsing result to the main agent based on the user request, the dialogue history, and the user history data.

7. The multi-agent system according to claim 6, characterized in that, The memory unit is specifically used for: Based on the user identifier, the historical execution result records associated with the user are retrieved; Based on the user identifier, a user profile map constructed based on the user's long-term behavioral preferences is retrieved; Based on the historical execution results and the user profile, user historical data is obtained.

8. The multi-agent system according to claim 6, characterized in that, The dialogue context understanding unit is specifically used for: The user request, the dialogue history, and the user history data are concatenated according to a preset format to obtain the model input content; The input content of the model is input into a preset large language model, and the parsing result is obtained and returned to the main intelligent agent.

9. The multi-agent system according to claim 1, characterized in that, The main intelligent agent is specifically used for: Extract the intent type of the user request from the parsing results; Based on the intent type, a preset sub-agent registry is queried to determine the target sub-agent among multiple sub-agents that corresponds to the intent type; The user request and the parsing result are encapsulated to generate request task data; Send the request task data to the target sub-agent.

10. A multi-agent dialogue management method, characterized in that, The method is applied to the multi-agent system as described in any one of claims 1 to 9, and the method includes: Upon receiving a user request, the dialogue management module is invoked to obtain the historical information corresponding to the user request, and the historical information is parsed to obtain the parsing result. Based on the parsing results and the user request, determine the corresponding request task data and the target sub-agent among multiple sub-agents; The target sub-agent processes the requested task data to obtain the task processing result; The system returns a corresponding natural language response to the user based on the task processing result.

Images