Internet of Things home platform, dialogue method based on multi-agent switching and product

Abstract

The invention provides an Internet of Things home platform, a dialogue method based on multi-agent switching and a product, and relates to the field of artificial intelligence. The method disclosed by the invention comprises the following steps: forwarding an input request to a first agent under the condition that an activated agent does not exist; the first agent performs intention recognition on the input request, generates a first agent switching request based on a second agent which can be matched when the intention cannot be matched with the first agent, and sends the first agent switching request to the agent composer; the agent composer forwards the input request to a second agent; the second agent executes a corresponding task based on the input request, generates a response and returns the response; the second agent judges whether the task is completed or not, if not, the activation state is kept, and a first activation keeping notice is generated and sent to the agent composer; and the agent composer sets the second agent as an activated agent in response to the first activation hold notification.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of artificial intelligence, and in particular, to an Internet of Things home platform, a dialogue method based on multi-agent switching, and a product. BACKGROUND

[0002] In the field of artificial intelligence and smart home, to meet the needs of users to complete diversified tasks (such as device control, scene setting, timing task, linkage configuration, and casual chat) through natural language interaction, the current mainstream multi-agent dialogue system generally adopts a "centralized intent recognition" architecture. In the "centralized intent recognition" architecture, an independent intent recognition module (usually a dedicated agent or classifier) is used as a unified entrance to first classify the input request of the user, and then a function agent is dispatched by an agent arranger to perform secondary processing. Although the "centralized intent recognition" architecture can achieve task distribution, it has significant defects. In the first defect, each request requires at least two large model calls (intent recognition + function execution), resulting in a doubling of Token consumption and API costs. In the second defect, serial calling significantly prolongs the response delay, weakening the real-time nature of the interaction. In the third defect, in multi-turn dialogue, the intent recognition module lacks the task context of the function execution layer, which is prone to misjudgment of intent due to unclear references or semantic omission, resulting in context fragmentation and task failure, making it difficult to balance efficiency, cost, and strong coherence. SUMMARY

[0003] The present disclosure provides an Internet of Things home platform, a dialogue method based on multi-agent switching, and a product.

[0004] According to one aspect of the present disclosure, a multi-agent switching-based dialogue method is provided, comprising: receiving an input request and determining whether there is an activated agent; in the case where there is no activated agent, an agent orchestrator forwards the input request to a first agent according to routing rules; the first agent performs intent recognition on the input request to obtain an intent corresponding to the input request, and determines whether the intent can match the first agent; in the case where the intent cannot match the first agent, the first agent determines a second agent to which the intent can match, generates a first agent switching request based on the second agent, and sends it to the agent orchestrator; the agent orchestrator parses the first agent switching request to obtain the second agent, and forwards the input request to the second agent; the second agent performs a corresponding task based on the input request, generates a response and returns; the second agent determines whether the task is completed, and in the case where it is not completed, maintains an activated state, generates a first activation maintenance notification and sends it to the agent orchestrator; and the agent orchestrator sets the second agent as an activated agent in response to the first activation maintenance notification.

[0005] According to the technical solution of one aspect, by distributing the intent recognition capability in each functional agent and combining a dynamic activation maintenance mechanism, high-frequency tasks can be directly completed by a first agent in a single call when there is no activated agent, significantly reducing the frequency of calling large models and the consumption of word units. By the first agent generating a structured switching request when the intent does not match, precise and low-latency inter-agent collaboration can be achieved, avoiding the serial delay caused by the centralized recognition module. By the second agent actively declaring and maintaining the activated state when the task is not completed, the same agent can be ensured to control the context throughout the multi-round dialogue, effectively solving the problem of intent misjudgment caused by unclear references and omitted semantics, thereby achieving an efficient, low-cost and strongly coherent multi-modal task dialogue experience as a whole.

[0006] According to at least one embodiment of the present disclosure, after determining whether the intent can match the first agent, it further comprises: in the case where the intent can match the first agent, the first agent performs a corresponding task based on the input request, generates a response and returns; the first agent determines whether the task is completed, and in the case where it is not completed, maintains an activated state, generates a second activation maintenance notification and sends it to the agent orchestrator; and the agent orchestrator sets the first agent as an activated agent in response to the second activation maintenance notification.

[0007] According to the technical solution of this embodiment, the "activation retention" capability is generalized to all functional agents (not limited to the second agent after switching), realizing a unified session management strategy that is task-driven, on-demand activated, and continuously coherent. This can further improve the adaptability and resource utilization efficiency to mixed user behaviors (intertwining high-frequency simple commands and low-frequency complex tasks).

[0008] According to at least one embodiment of this disclosure, after the first agent determines that the intent can be matched with a second agent, the method further includes: if the second agent is a chat-type agent, the first agent performs a corresponding task based on the input request, generates a response and returns it, and at the same time generates an agent activation request corresponding to the second agent and sends it to the agent orchestrator; and the agent orchestrator responds to the agent activation request, activates the second agent, and sets the second agent as an activated agent.

[0009] According to the technical solution of this embodiment, both responsiveness and content professionalism are taken into account, and a natural and smooth transition from "lightweight guidance" to "deep interaction" in chat tasks is achieved without increasing the user's perceived latency.

[0010] According to at least one embodiment of this disclosure, after determining whether an activated agent exists, the method further includes: if an activated agent exists, the agent orchestrator forwards the input request to the activated agent; the activated agent performs intent recognition on the input request to obtain the intent corresponding to the input request; determines whether the intent can match the activated agent; if the intent can match the activated agent, the activated agent executes a corresponding task based on the input request, generates a response, and returns; and the activated agent determines whether the task is completed, and if not, remains active.

[0011] According to the technical solution of this embodiment, the interaction accuracy and robustness of complex tasks (such as scene configuration and linkage rule editing) can be improved. At the same time, since the default routing and cross-agent switching overhead are eliminated, response latency and system resource consumption can be further reduced, realizing highly coherent, low-latency, and low-overhead multi-round task closed-loop processing.

[0012] According to at least one embodiment of this disclosure, after determining whether the intent can match the activated agent, the method further includes: if the intent cannot match the activated agent, the activated agent determines a third agent that the intent can match, generates a second agent switching request based on the third agent, and sends it to the agent orchestrator; the agent orchestrator parses the second agent switching request to obtain the third agent, and forwards the input request to the third agent; the third agent executes a corresponding task based on the input request, generates a response, and returns; the third agent determines whether the task is completed, and if not, maintains its active state, generates a third activation hold notification, and sends it to the agent orchestrator; and the agent orchestrator, in response to the third activation hold notification, updates the activated agent to the third agent.

[0013] According to the technical solution of this embodiment, seamless handover of task intent naturally evolves in multi-turn dialogues. It can ensure that each sub-task in complex conversations is executed by the most suitable professional intelligent agent while maintaining a single conversation channel and contextual coherence throughout. It can improve adaptability and robustness to mixed intents and jump-like interactive behaviors of real users.

[0014] According to at least one embodiment of this disclosure, after determining whether the task is completed, the method further includes: if completed, exiting the activation state, generating a task completion notification and sending it to the agent orchestrator; and the agent orchestrator, in response to the task completion notification, clearing the settings information of the activated agent.

[0015] According to the technical solution of this embodiment, the session state can be released and reset in a timely manner, which can ensure that the next round of new input requests are routed again from the default agent, and can avoid intention misjudgment or context pollution caused by residual activation state (such as the user's newly initiated "turn on the light" being incorrectly handed over to the scene agent after the previous scene configuration task is completed).

[0016] According to at least one embodiment of this disclosure, when an agent orchestrator forwards an input request to a first agent according to routing rules, the process includes: determining a semantic keyword corresponding to the input request; determining, according to the routing rules, whether there exists a default agent that can match the semantic keyword; if there exists a default agent that can match the semantic keyword, using the default agent as the first agent; and forwarding the input request to the first agent.

[0017] According to the technical solution of this embodiment, the first-round hit rate can be improved by using lightweight semantic keyword extraction and rule-driven routing mechanism, thereby effectively reducing the average response latency and saving API costs without increasing the overhead of large models.

[0018] According to at least one embodiment of this disclosure, after determining whether there is a default agent that can match the semantic keyword, the method further includes: if there is no default agent that can match the semantic keyword, selecting one of the default agents as the first agent.

[0019] According to the technical solution of this embodiment, this fallback mechanism can ensure that the dialogue process can still be started robustly when the semantic keywords do not match any default agent, thus avoiding routing failure.

[0020] According to at least one embodiment of this disclosure, selecting one of the default agents as the first agent includes: selecting the agent with the highest priority among the default agents as the first agent.

[0021] According to the technical solution of this embodiment, by selecting the default agent with the highest priority as the first agent, the optimal first-round routing can still be achieved based on business importance or high-frequency user behavior when the semantic keywords are not matched, thereby further improving the single call completion rate and taking into account both system robustness and response efficiency.

[0022] According to at least one embodiment of this disclosure, selecting one of the default agents as the first agent includes: selecting the agent most frequently used among the default agents as the first agent.

[0023] According to the technical solution of this embodiment, the default agent that is used most frequently is used as the first agent. Data-driven routing optimization can be achieved based on the user's real behavioral preferences, which can significantly improve the first-round hit rate of high-frequency intents and further reduce the frequency of agent switching.

[0024] According to another aspect of this disclosure, an Internet of Things (IoT) home platform is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform a dialogue method based on multi-agent switching according to any embodiment of this disclosure.

[0025] According to another aspect of this disclosure, a readable storage medium is provided, wherein execution instructions are stored therein, which, when executed by a processor, are used to implement a dialogue method based on multi-agent switching according to any embodiment of this disclosure.

[0026] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a dialogue method based on multi-agent switching according to any embodiment of this disclosure. Attached Figure Description

[0027] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0028] Figure 1 This is a schematic diagram of the structure of a dialogue system based on multi-agent switching according to one embodiment of the present disclosure.

[0029] Figure 2 This is a flowchart illustrating a dialogue method based on multi-agent switching according to one embodiment of the present disclosure.

[0030] Figure 3 This is a flowchart illustrating a method for determining a first intelligent agent according to one embodiment of the present disclosure.

[0031] Figure 4 This is a flowchart illustrating a dialogue method based on multi-agent switching according to another embodiment of this disclosure.

[0032] Figure 5 This is a flowchart illustrating a dialogue method based on multi-agent switching according to yet another embodiment of the present disclosure.

[0033] Figure 6 This is a flowchart illustrating a dialogue method based on multi-agent switching according to another embodiment of the present disclosure.

[0034] Figure 7 This is a schematic block diagram of a dialogue device based on multi-agent switching according to one embodiment of the present disclosure.

[0035] Figure 8 This is a schematic structural block diagram of an IoT home platform using a processor-based hardware implementation according to one embodiment of the present disclosure. Detailed Implementation

[0036] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0037] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0038] Current mainstream multi-agent dialogue systems generally adopt a "centralized intent recognition" architecture. The core of this architecture lies in the need for a dedicated, independent intent recognition module (which is usually an agent or a classifier itself) as a unified entry point and scheduling center for input requests. This "centralized intent recognition" architecture often suffers from drawbacks such as high cost (at least two large model calls double the cost of lexical units and APIs), high latency (serial processing significantly lengthens response time), and context fragmentation (the intent recognition module lacks task context, making it prone to misinterpreting referential and ellipsis statements).

[0039] To address this, this disclosure proposes the following technical solution, which abandons the centralized intent recognition method and embeds intent recognition capabilities into each functional agent, achieving efficient collaboration through an agent orchestrator and dynamic activation mechanism. Specifically, when no agent is initially activated, the input request is forwarded to the default first agent according to preset routing rules. The first agent autonomously performs intent recognition, and if the intent does not match (cannot match the first agent), it proactively generates a clear agent switching request. The agent orchestrator activates the target second agent based on the agent switching request and forwards the original request (i.e., the input request). After the second agent executes the task, if the task is not completed, it proactively declares and maintains itself as the currently activated agent, allowing subsequent dialogue requests to be handled directly by it, thereby ensuring the continuity and integrity of the task context. This disclosure can significantly reduce the frequency of large model calls (high-frequency requests (such as device control) can be completed by a single call from the default functional agent (first agent), saving lexical consumption and API costs compared to the traditional two-stage serial architecture of "intent recognition + function execution". Meanwhile, by reducing sequential reasoning steps, the average response latency is significantly reduced, improving real-time interaction and user experience. Furthermore, the "remain active until task completion" mechanism allows the functional agent to maintain full control over the multi-turn dialogue context, effectively resolving intent misjudgment issues caused by ambiguous referencing and semantic omissions. This significantly enhances the accuracy and robustness of complex tasks (such as scene configuration and linkage rule setting). In addition, the decentralized collaborative architecture exhibits excellent scalability; adding new functional agents requires no changes to the core scheduling logic, only registration and embedded intent recognition capabilities.

[0040] To facilitate description and make the technical solutions of this disclosure easier to understand, the terminology of this disclosure will be explained before describing the technical solutions of this disclosure.

[0041] An intelligent agent is a software entity built on a large language model (LLM) that possesses domain-specific functions and autonomous decision-making capabilities.

[0042] This disclosure applies to intelligent system scenarios that require natural language interaction to complete diverse tasks (such as device control, scene configuration, timed tasks, linkage settings, and casual conversation), and is especially suitable for large-model-driven multi-turn dialogue systems such as smart homes, smart vehicles, and smart customer service that are sensitive to real-time response, contextual coherence, and operating costs.

[0043] Figure 1 The diagram shows a schematic representation of a dialogue system based on multi-agent switching, according to one embodiment. Figure 1 The system shown includes an agent orchestrator 100, a default agent 200, and non-default agents 300. The default agent 200 can be an agent set in the routing rules, typically a functional agent with primary or frequently used user functions, such as a device control agent. The non-default agent 300 is a functional agent other than the default agent 200, i.e., an agent not set in the routing rules. Examples include scene setting agents, scheduled task agents, and chat agents. Both the default agent 200 and the non-default agent 300 have intent recognition capabilities. The agent orchestrator 100 forwards input requests to either the default agent 200 or the non-default agent 300, and sets the agent that remains active as the active agent. Based on this system, after initially receiving an input request, the agent orchestrator 100 forwards the input request to the default agent 200 (i.e., the first agent) corresponding to the input request in the routing rules, according to the routing rules. After receiving an input request, the default agent 200 first performs intent recognition. If the recognized intent does not match, it sends a first agent switching request to the agent orchestrator 100. Based on the first agent switching request, the agent orchestrator 100 forwards the input request to a second agent whose recognized intent matches (an agent other than the first agent, which can be either the default agent 200 or a non-default agent 300).

[0044] Figure 2 A schematic diagram illustrating the overall flow of a dialogue method based on multi-agent switching according to one embodiment of this disclosure is shown. Figure 2 The method shown includes steps S210 to S280. This method can be executed by electronic devices such as mobile phones and tablets.

[0045] In step S210, an input request is received, and it is determined whether an activated agent exists.

[0046] Input requests can be natural language input requests initiated by the user (such as voice or text commands).

[0047] An activated agent refers to an agent that is in an active state (this can be a first agent, a second agent, etc.). An activated agent has priority in processing subsequent input requests. As one possible implementation, an activated agent field is used to record activated agents. When an activated agent exists, the field value is set to the unique agent code corresponding to that activated agent. When no activated agent exists, the field value is empty. The existence of an activated agent can be determined by checking if the activated agent field value is empty.

[0048] In step S220, if no active agent exists, the agent orchestrator forwards the input request to the first agent according to the routing rules.

[0049] The first agent can be the default agent determined by the routing rules. There can be only one default agent, in which case the routing rules will route all input requests to that default agent. Having only one default agent is suitable for scenarios with distinct domain characteristics (such as a pure smart home scenario) or for simplifying the initial design. There can also be multiple default agents. Having multiple default agents is suitable for complex or multi-domain scenarios. In this case, the preset routing rules can define the selection method for multiple default agents. The agent orchestrator determines the default agent (i.e., the first agent) corresponding to the input request based on this selection method.

[0050] Figure 3 A flowchart illustrating a first agent determination method according to an embodiment of this disclosure is shown. Figure 3 The method shown includes steps S310 to S340.

[0051] In step S310, the semantic keywords corresponding to the input request are determined. These voice keywords serve as the basis for subsequent routing rule determination. Common keyword determination methods can be used, such as rule-based keyword matching (e.g., regular expressions, dictionary lookup); semantic feature extraction based on lightweight NLP models (e.g., TF-IDF, BERT-mini classifiers); and personalized keyword weighting combined with user profiles (e.g., historically high-frequency functions).

[0052] In step S320, based on the routing rules, it is determined whether a default agent exists that can match the semantic keywords. As one possible implementation, the agent orchestrator matches the determined semantic keywords with preset routing rules, determining whether each routing rule matches the semantic keywords. If a semantic keyword is matched, it is determined that a default agent exists that matches the semantic keywords. For example, if the keyword contains {"create", "scene", "mode"}, then "scene setting agent" is matched; if the keyword contains {"daily", "timed", "XX o'clock"}, then "timed task agent" is matched.

[0053] In step S330, if a default agent exists that can match the semantic keywords, the default agent is selected as the first agent. As one possible implementation, when a routing rule matches successfully, the default agent included in the successfully matched routing rule is selected as the first agent.

[0054] In step S340, the input request is forwarded to the first agent. The agent orchestrator forwards the complete input request to the first agent determined in step S330, which then performs intent recognition and task processing.

[0055] Steps S310 to S340 improve the first-round hit rate through lightweight semantic keyword extraction and rule-driven routing mechanism, thereby effectively reducing the average response latency and saving API costs without increasing the overhead of large models.

[0056] As one possible implementation, after determining whether a default agent exists that matches the semantic keywords, the method further includes: if no default agent exists that matches the semantic keywords, selecting one of the default agents as the first agent. This fallback mechanism ensures that the dialogue process can still be robustly initiated even if the semantic keywords do not match any default agent, thus avoiding routing failures.

[0057] As a further implementation, one of the default agents is designated as the first agent, including: selecting the agent with the highest priority among the default agents as the first agent. The priority of the default agents can be set according to business needs. For example, the priority of the default agents can be set from high to low based on the user usage frequency corresponding to each agent. By selecting the default agent with the highest priority as the first agent, the optimal first-round routing can still be achieved based on business importance or high-frequency user behavior even when the semantic keywords are not matched, further improving the single-call completion rate and balancing system robustness and response efficiency.

[0058] As another further implementation, one of the default agents is designated as the first agent, including: designating the agent most frequently used among the default agents as the first agent. Using the most frequently used default agent as the first agent allows for data-driven routing optimization based on users' actual behavioral preferences, significantly improving the first-round hit rate of high-frequency intents and further reducing the frequency of agent switching.

[0059] In step S230, the first agent performs intent recognition on the input request, obtains the intent corresponding to the input request, and determines whether the intent can match the first agent.

[0060] The first intelligent agent identifies the intent of the input request through its built-in intent recognition capability. As one possible implementation, determining whether an intent matches the first intelligent agent involves judging whether the intent falls within the defined functional responsibilities of the first intelligent agent. For example, if the first intelligent agent is a device control agent whose responsibility is "immediate device operation," then it is determined to match the first intelligent agent (device control agent) only if the input request is a complete and directly executable instruction such as "turn on the air conditioner" or "increase the brightness of the living room lights."

[0061] In step S240, if the intent cannot match the first agent, the first agent determines the second agent that the intent can match, generates a first agent switching request based on the second agent, and sends it to the agent orchestrator.

[0062] If an intent cannot be matched with the first agent, the first agent determines a second agent that can be matched. The second agent is an agent other than the first intent; it can be the default agent or a non-default agent. The determination of the second agent can be based on the agent-intent mapping relationship. For example, if the input request is "turn off the lights at 10 PM," the first agent recognizes that its intent belongs to a scheduled task, which falls within the functional scope of the "scheduled task agent." Therefore, the "scheduled task agent" is selected as the second agent that can be matched with the intent.

[0063] In step S250, the agent orchestrator parses the first agent switching request to obtain the second agent and forwards the input request to the second agent.

[0064] The first agent switching request needs to include the identifier (such as a unique code) of the target functional agent (i.e., the second agent). By parsing the first agent switching request, the target functional agent that needs to execute the input request can be obtained.

[0065] In step S260, the second agent executes the corresponding task based on the input request, generates a response, and returns it. As one possible implementation, the generated response can first be returned to the agent orchestrator, and then uniformly encapsulated by the agent orchestrator before being returned to the user.

[0066] In step S270, the second agent determines whether the task is completed. If it is not completed, it remains active, generates a first active hold notification, and sends it to the agent orchestrator.

[0067] In determining whether a task is completed, the second intelligent agent can assess the achievement of the current task's business objectives based on its domain knowledge and task logic. For tasks with clearly defined objectives (such as scheduled tasks, scene settings, device linkage, etc.), completion is determined if all necessary parameters have been collected, the user has confirmed, and the core actions have been successfully executed (such as the scheduling rules being written into the system and the scene being created).

[0068] In step S280, the agent orchestrator responds to the first activation hold notification by setting the second agent as the activated agent.

[0069] The first activation hold notification is used to notify the second agent to remain active, so that the agent orchestrator, upon receiving the first activation hold notification, will set the second agent to an active state.

[0070] Steps S210 to S280, by distributively embedding intent recognition capabilities into each functional agent and combining them with a dynamic activation maintenance mechanism, enable high-frequency tasks to be completed directly by a single call from the first agent when no active agent is available, significantly reducing the frequency of large model calls and lexical consumption. By having the first agent proactively generate a structured switching request when intents do not match, accurate and low-latency inter-agent collaboration can be achieved, avoiding the serial latency caused by a centralized recognition module. By having the second agent proactively declare and maintain its active state when a task is not completed, the context can be controlled by the same agent throughout multi-turn dialogues, effectively solving the problem of intent misjudgment caused by ambiguous referencing and semantic omissions. This results in a highly efficient, low-cost, and highly coherent multimodal task dialogue experience overall.

[0071] Figure 4 A schematic diagram illustrating the overall flow of a dialogue method based on multi-agent switching, according to another embodiment of this disclosure, is shown. Figure 4 The method shown includes steps S410 to S460.

[0072] In step S410, an input request is received, and it is determined whether an activated agent exists.

[0073] In step S420, if no active agent exists, the agent orchestrator forwards the input request to the first agent according to the routing rules.

[0074] In step S430, the first agent performs intent recognition on the input request, obtains the intent corresponding to the input request, and determines whether the intent can match the first agent.

[0075] In step S440, if the intent matches the first agent, the first agent executes the corresponding task based on the input request, generates a response, and returns it. The fact that the intent matches the first agent indicates that the task corresponding to the input request is a function possessed by the first agent itself. In this case, the first agent executes the task corresponding to the input request and generates the corresponding response.

[0076] In step S450, the first agent determines whether the task is completed. If not, it remains active, generates a second active hold notification, and sends it to the agent orchestrator. The method by which the first agent determines whether the task is completed is the same as the method by which the second agent determines whether the task is completed in step S270, and will not be described again here.

[0077] In step S460, the agent orchestrator, in response to the second activation hold notification, sets the first agent as an activated agent. The second activation hold notification is used to inform the first agent that it needs to remain active, so that the agent orchestrator, upon receiving the second activation hold notification, sets the first agent as activated.

[0078] In steps S410 to S460, the first agent is allowed to actively maintain its active state and notify the orchestrator when the intent is matched but the task is not completed. This enables high-frequency single-round tasks to achieve zero switching and a single-call closed loop. For tasks requiring multi-round interaction (such as device linkage configuration with incomplete parameters), it can also seamlessly switch to context-holding mode, avoiding context loss or duplicate recognition caused by releasing control before the task is completed. This implementation generalizes the "activation-holding" capability to all functional agents (not limited to the second agent after switching), realizing a unified session management strategy that is task-driven, on-demand activated, and continuously coherent. It can further improve the adaptability and resource utilization efficiency to mixed user behaviors (intertwining high-frequency simple commands and low-frequency complex tasks).

[0079] As a further implementation, after the first agent determines that the intent can be matched with the second agent, the method further includes: if the second agent is a chat-type agent, the first agent executes the corresponding task based on the input request, generates a response and returns it, and simultaneously generates an agent activation request for the second agent and sends it to the agent orchestrator. The agent orchestrator responds to the agent activation request, activates the second agent, and sets the second agent as an activated agent.

[0080] Chat-type agents can be specialized chat agents, and their responses can be configured with richer formats and deeper content, rather than simple casual conversation. In one example, the input request is "I want to travel to Xiamen." In this case, without an activated agent, the first agent first identifies the intent as chat. The first agent determines that the intent doesn't match the first agent, and the second agent that does match is a chat-type agent. At this point, the first agent can adopt a collaborative strategy of "instant response + background activation." On one hand, the first agent quickly generates a friendly and concise initial response based on its capabilities (e.g., responding to "I want to travel to Xiamen" with "Gulangyu Island in Xiamen is especially beautiful~ Which attraction do you most want to visit?"), ensuring a smooth and lag-free first-round interaction. On the other hand, the first agent simultaneously sends an agent activation request for chat-type agents to the agent orchestrator, which then sets the chat-type agent as an activated agent. This ensures that from the next input request onwards, the conversation will be taken over by a professional chatbot with domain knowledge and deep generative capabilities, outputting high-value content such as structured itinerary suggestions and detailed explanations of attractions. This implementation method balances responsiveness and content professionalism, achieving a natural and smooth transition from "lightweight guidance" to "deep interaction" in chatbot tasks without increasing user-perceived latency.

[0081] Figure 5 A schematic diagram illustrating the overall flow of a dialogue method based on multi-agent switching, according to yet another embodiment of this disclosure, is shown. Figure 5 The method shown includes steps S510 to S550.

[0082] In step S510, an input request is received, and it is determined whether an activated agent exists.

[0083] In step S520, if an active agent exists, the agent orchestrator forwards the input request to the active agent.

[0084] In one possible implementation, after step S280 is completed and a new input request is received again, the activated agent at this time is... Figure 2The second agent in the illustrated embodiment therefore forwards the received new input request to the second agent.

[0085] In another possible implementation, after step S460 is completed, a new input request is received again, at which point the activated agent is... Figure 4 The first agent in the illustrated embodiment therefore forwards the new input request received to the first agent.

[0086] In step S530, the activated agent performs intent recognition on the input request to obtain the intent corresponding to the input request.

[0087] In step S540, it is determined whether the intent can match the activated agent.

[0088] In step S550, if the intent can match the activated agent, the activated agent executes the corresponding task based on the input request, generates a response, and returns it.

[0089] In step S560, the activated agent determines whether the task is completed. If the task is not completed, it remains activated.

[0090] In steps S510 to S560, when an activated agent exists, the input request is directly routed to the activated agent, which then autonomously completes intent recognition, task execution, and state maintenance. This ensures that the entire multi-turn dialogue is led by the same functional agent, avoiding context breaks caused by repeated intent recognition or route switching. This implementation can improve the interaction accuracy and robustness of complex tasks (such as scene configuration and linkage rule editing). Furthermore, by eliminating the overhead of default routing and cross-agent switching, response latency and system resource consumption can be further reduced, achieving highly coherent, low-latency, and low-overhead multi-turn task closed-loop processing.

[0091] Figure 6 A schematic diagram illustrating the overall flow of a dialogue method based on multi-agent switching according to another embodiment of this disclosure is shown. Figure 6 The method shown includes steps S610 to S690.

[0092] In step S610, an input request is received, and it is determined whether an activated agent exists.

[0093] In step S620, if an active agent exists, the agent orchestrator forwards the input request to the active agent.

[0094] In step S630, the activated agent performs intent recognition on the input request to obtain the intent corresponding to the input request.

[0095] In step S640, it is determined whether the intent can match the activated agent.

[0096] In step S650, if the intent cannot be matched with the activated agent, the activated agent determines a third agent that the intent can be matched, generates a second agent switching request based on the third agent, and sends it to the agent orchestrator.

[0097] The third agent is an agent other than the already activated agent. In one possible implementation, the activated agent is... Figure 2 The second agent in the illustrated embodiment. In this case, the third agent can be the default agent (including the original first agent) or a non-default agent. In another possible embodiment, the activated agent is... Figure 4 The first agent in the illustrated embodiment. In this case, the third agent can be either a default agent other than the first agent, or a non-default agent.

[0098] In step S660, the agent orchestrator parses the second agent switching request to obtain the third agent and forwards the input request to the third agent. The second agent switching request needs to include a flag (such as a unique code) of the third agent. By parsing the second agent switching request, the third agent that needs to execute the input request can be obtained.

[0099] In step S670, the third agent executes the corresponding task based on the input request, generates a response, and returns it.

[0100] In step S680, the third agent determines whether the task is completed. If not, it remains active, generates a third active hold notification, and sends it to the agent orchestrator. The method by which the third agent determines whether the task is completed is the same as the method by which the second agent determines whether the task is completed in step S270, and will not be described again here.

[0101] In step S690, the agent orchestrator, in response to the third activation hold notification, updates the activated agent to the third agent. The third activation hold notification is used to inform the third agent that it needs to remain active, so that the agent orchestrator, upon receiving the third activation hold notification, sets the third agent to the activated state.

[0102] In steps S610 to S690, when an activated agent detects intent drift (i.e., the current input request no longer matches its responsibility), it is allowed to proactively determine and switch to a new third agent. Simultaneously, the agent orchestrator dynamically transfers activation rights and updates the state. This implementation enables seamless handover of tasks in multi-turn dialogues as intents evolve naturally. For example, a user might suddenly ask "What's the weather like in Xiamen?" during scene configuration. The currently activated agent (e.g., the scene setting agent) can accurately identify that the request belongs to casual conversation intent and immediately generate a second agent switching request to be handled by the third agent (e.g., a professional casual conversation agent), avoiding errors or context pollution caused by forced responses. This implementation possesses dynamic intent tracking and on-demand agent rotation capabilities. It can ensure that each subtask in a complex conversation is executed by the most suitable professional agent while maintaining a single conversation channel and contextual coherence throughout. It can improve adaptability and robustness to real user mixed intents and jumpy interactive behaviors.

[0103] As one possible implementation, after determining whether the task is completed, the method further includes: if completed, exiting the activation state, generating a task completion notification and sending it to the agent orchestrator. The agent orchestrator, in response to the task completion notification, clears the settings information of the activated agents. Determining task completion can be... Figure 2 The second agent in the illustrated embodiment determines that the task is completed. Figure 4 The first agent in the illustrated embodiment determines that the task is completed. Figure 5 In the illustrated embodiment, the activated agent determines that the task is completed, and Figure 6 In the illustrated implementation, the third agent determines task completion status. By having the agent proactively exit the active state and notify the orchestrator to clear the settings information of the activated agent after the task is completed, timely release and reset of the session state can be achieved. This ensures that the next round of new input requests will be routed again from the default agent, avoiding misjudgment of intent or context pollution caused by residual active states (e.g., after the previous scene configuration task has ended, a user-initiated "turn on the light" request is incorrectly handled by the scene agent). This implementation ensures the clarity and independence of each task session boundary, improves the accuracy of responding to user intent switching, and enhances the robustness and predictability of the overall architecture.

[0104] According to any of the above embodiments, this disclosure also provides a dialogue device 700 based on multi-agent switching. Figure 7 This is a schematic block diagram of a dialogue device 700 based on multi-agent switching, according to one embodiment of this disclosure. Figure 7As shown, the dialogue device 700 based on multi-agent switching includes an input request receiving module 710, a first input request forwarding module 720, an intent recognition module 730, an intent matching module 740, a second input request forwarding module 750, an input request execution module 760, a task completion judgment module 770, and an activated agent setting module 780. The input request receiving module 710 receives input requests and determines whether an activated agent exists. The first input request forwarding module 720 forwards the input request to the first agent according to routing rules if no activated agent exists. The intent recognition module 730 identifies the intent of the input request, obtains the intent corresponding to the input request, and determines whether the intent matches the first agent. The intent matching module 740 determines a second agent that can match the intent if it does not match the first agent, and generates a first agent switching request based on the second agent. The second input request forwarding module 750 parses the first agent switching request, obtains the second agent, and forwards the input request to the second agent. The input request execution module 760 is used to execute the corresponding task based on the input request, generate a response, and return it. The task completion judgment module 770 is used to determine whether the task is completed. If it is not completed, it maintains the active state and generates a first activation hold notification. The activated agent setting module 780 is used to set the second agent as the activated agent in response to the first activation hold notification.

[0105] According to further embodiments of this disclosure, an Internet of Things (IoT) home platform is also provided. Figure 8This diagram illustrates a schematic block diagram of an IoT home platform implemented using a processor, according to one embodiment of the present disclosure. The hardware architecture of the IoT home platform of this disclosure can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. Bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400 such as peripheral devices, voltage regulators, power management circuits, external antennas, etc. Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one connecting line is used in this figure, but this does not indicate that there is only one bus or one type of bus. The memory 1300 stores a computer program. When the processor 1200 executes the computer program, the processor 1200 can perform the following process: Receive an input request and determine if an active agent exists. If no active agent exists, the agent orchestrator forwards the input request to a first agent according to routing rules. The first agent identifies the intent of the input request, obtains the intent corresponding to the input request, and determines whether the intent matches the first agent. If the intent does not match the first agent, the first agent determines a second agent whose intent matches, generates a first agent switching request based on the second agent, and sends it to the agent orchestrator. The agent orchestrator parses the first agent switching request, obtains the second agent, and forwards the input request to the second agent. The second agent executes the corresponding task based on the input request, generates a response, and returns. The second agent determines whether the task is completed. If not, it remains active, generates a first activation hold notification, and sends it to the agent orchestrator. In response to the first activation hold notification, the agent orchestrator sets the second agent as the active agent.

[0106] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0107] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0108] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

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

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

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

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

[0113] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0114] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A multi-agent switching based dialogue method, characterized by, The method comprises the following steps: receiving an input request and determining whether there is an activated intelligent agent; in the case where there is no activated intelligent agent, an intelligent agent scheduler forwards the input request to a first intelligent agent according to a routing rule; the first intelligent agent performs intent recognition on the input request to obtain an intent corresponding to the input request, and determines whether the intent can match the first intelligent agent; in the case where the intent cannot match the first intelligent agent, the first intelligent agent determines a second intelligent agent that can match the intent, generates a first intelligent agent switching request based on the second intelligent agent, and sends the first intelligent agent switching request to the intelligent agent scheduler; the intelligent agent scheduler analyzes the first intelligent agent switching request to obtain the second intelligent agent, and forwards the input request to the second intelligent agent; the second intelligent agent performs a corresponding task based on the input request, generates a response, and returns the response; the second intelligent agent determines whether the task is completed, and in the case where the task is not completed, keeps an activated state, generates a first activated state keeping notification, and sends the first activated state keeping notification to the intelligent agent scheduler; and the intelligent agent scheduler sets the second intelligent agent as an activated intelligent agent in response to the first activated state keeping notification.

2. The method of claim 1, wherein, After determining whether the intent can match the first intelligent agent, the method further comprises the following steps: in the case where the intent can match the first intelligent agent, the first intelligent agent performs a corresponding task based on the input request, generates a response, and returns the response; the first intelligent agent determines whether the task is completed, and in the case where the task is not completed, keeps an activated state, generates a second activated state keeping notification, and sends the second activated state keeping notification to the intelligent agent scheduler; and the intelligent agent scheduler sets the first intelligent agent as an activated intelligent agent in response to the second activated state keeping notification.

3. The method of claim 1, wherein, After the first intelligent agent determines the second intelligent agent that can match the intent, the method further comprises the following steps: in the case where the second intelligent agent belongs to a chat type intelligent agent, the first intelligent agent performs a corresponding task based on the input request, generates a response, and returns the response, and simultaneously generates an intelligent agent activation request corresponding to the second intelligent agent and sends the intelligent agent activation request to the intelligent agent scheduler; and the intelligent agent scheduler activates the second intelligent agent in response to the intelligent agent activation request, and sets the second intelligent agent as an activated intelligent agent.

4. The method of claim 1, wherein, After determining whether there is an activated intelligent agent, the method further comprises the following steps: in the case where there is an activated intelligent agent, the intelligent agent scheduler forwards the input request to the activated intelligent agent; the activated intelligent agent performs intent recognition on the input request to obtain an intent corresponding to the input request; determining whether the intent can match the activated intelligent agent; in the case where the intent can match the activated intelligent agent, the activated intelligent agent performs a corresponding task based on the input request, generates a response, and returns the response; and the activated intelligent agent determines whether the task is completed, and in the case where the task is not completed, keeps an activated state.

5. The method of claim 4, wherein, After determining whether the intent can match the activated intelligent agent, the method further comprises the following steps: In a case where the intention cannot match the activated agent, the activated agent determines a third agent that can match the intention, generates a second agent switching request based on the third agent, and sends the second agent switching request to the agent orchestrator; The agent orchestrator parses the second agent switching request to obtain the third agent, and forwards the input request to the third agent; The third agent performs a corresponding task based on the input request, generates a response, and returns the response; The third agent determines whether the task is completed, and in a case where the task is not completed, keeps an activated state, generates a third activation keeping notification, and sends the third activation keeping notification to the agent orchestrator; and The agent orchestrator updates the activated agent to the third agent in response to the third activation keeping notification.

6. The method of claim 1, 2, 4 or 5, wherein, After determining whether the task is completed, the method further comprises: In a case where the task is completed, the method further comprises: The agent orchestrator clears the setting information of the activated agent in response to the task completion notification.

7. The method of claim 1, wherein, In forwarding the input request to the first agent according to the routing rule by the agent orchestrator, the method further comprises: Determining a semantic keyword corresponding to the input request; According to the routing rule, determining whether there is a default agent that can match the semantic keyword; In a case where there is a default agent that can match the semantic keyword, the method further comprises: Forwarding the input request to the default agent as the first agent; and 8. The method of claim 7, wherein, Forwarding the input request to the first agent. After determining whether there is a default agent that can match the semantic keyword, the method further comprises:

9. An Internet of Things home platform, characterized by In a case where there is no default agent that can match the semantic keyword, the method further comprises: Selecting one of the default agents as the first agent, wherein the selecting one of the default agents as the first agent comprises: selecting a default agent with a highest priority as the first agent, or selecting a default agent with a most frequent usage as the first agent. The method comprises: a memory storing execution instructions; and 10. A computer program product comprising a computer program, characterized in that, a processor executing the execution instructions stored in the memory, so that the processor performs the method for a dialogue based on multi-agent switching according to any one of claims 1 to 8. The computer program is executed by the processor to implement the method for a dialogue based on multi-agent switching according to any one of claims 1 to 8.

Images