Intelligent agent-based task processing method, device, system and service node

Abstract

Embodiments of the present application provide a task processing method, device and system based on intelligent agents, and a service node, the method comprising: a service process acquiring a user request message bound with a target user identifier; when there is no corresponding task being executed for the target user identifier, and no proxy service instance corresponding to the target user identifier is found, removing a proxy service instance that meets an inactivity condition; creating a target proxy service instance corresponding to the target user identifier; acquiring historical task information from historical task information isolated based on the user identifier; and calling a large language model based on the target proxy service instance and the historical task information to obtain a result. From the request message, the proxy service instance to the processing of the request message when there is no task being executed, and the historical task information are all logically isolated based on the user identifier, the request messages of the same user are executed in series, the inactivity proxy service instance is removed in a dynamic pooling manner, and the resource utilization is improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a task processing method, apparatus, system and service node based on intelligent agents. Background Technology

[0002] With the rapid development of large language model technology, AI agents based on large language models have moved from the laboratory to product applications. AI agents are capable of autonomous reasoning, calling tools, and executing multi-step tasks, demonstrating great value in scenarios such as intelligent customer service, IoT device control, and office automation.

[0003] In the task processing based on intelligent agents, user isolation is necessary to ensure user data security. Currently, the mainstream AI Agent deployment solutions in the industry are mainly the following two:

[0004] Option 1: Single-machine, single-user deployment mode, represented by open-source frameworks such as OpenClaw. OpenClaw is an open-source AI Agent runtime framework that adopts a local single-machine deployment architecture. Its core consists of three layers: Gateway, Reasoning Engine, and Execution Environment. Each OpenClaw instance serves one user, and the Agent's identity and memory are stored in a local Markdown file, achieving natural user isolation through the file system. Option 2: Containerized multi-instance deployment mode, creating an independent container for each user, with each container running one Agent instance. User isolation and resource management are achieved through container orchestration.

[0005] Both of the above solutions adopt a physical isolation mode of "one user = one independent running environment". Each user has a dedicated process or container. When the AI ​​Agent needs to provide services to a large number of users, taking OpenClaw as an example, a single Agent instance occupies about 200-500MB of memory, and 1000 users need 200-500GB of memory. However, the actual number of active users may be less than 10%, resulting in very low resource utilization. Summary of the Invention

[0006] The purpose of this application is to provide a task processing method, apparatus, system, and service node based on intelligent agents, so as to improve resource utilization while achieving user isolation. The specific technical solution is as follows:

[0007] In a first aspect, embodiments of this application provide a task processing method based on an intelligent agent, applied to the service process of a service node in an intelligent agent system, wherein the service node includes a pool of agent service instances, and the method includes:

[0008] Obtain a user request message, wherein the user request message is bound to a target user identifier;

[0009] If it is determined that there is no corresponding task being executed for the target user identifier, and no proxy service instance corresponding to the target user identifier is found in the proxy service instance pool, the proxy service instances that meet the inactive condition are removed based on the last active time of each proxy service instance in the proxy service instance pool.

[0010] Create a proxy service instance corresponding to the target user identifier in the proxy service instance pool as the target proxy service instance, and record the last active time of the target proxy service instance based on the current time;

[0011] Obtain the historical task information corresponding to the target user identifier from the stored historical task information isolated based on user identifier;

[0012] Based on the target proxy service instance and the acquired historical task information, the large language model is invoked to process the user request message and obtain the task processing result.

[0013] Optionally, the method further includes:

[0014] If a proxy service instance corresponding to the target user identifier is found, the found proxy service instance shall be used as the target proxy service instance.

[0015] Update the last active time of the target proxy service instance based on the current time.

[0016] Optionally, before the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool, the method further includes:

[0017] Determine whether the capacity of the proxy service instance pool has reached a preset capacity. If the capacity of the proxy service instance pool has reached the preset capacity, execute the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool; and / or,

[0018] The last active time of each proxy service instance in the proxy service instance pool is detected according to a preset period, and the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool is executed.

[0019] Optionally, after the step of removing proxy service instances that meet the inactive condition, the method further includes:

[0020] Upon receiving a request message for the user identifier corresponding to the removed proxy service instance, the proxy service instance corresponding to the user identifier is reconstructed based on the historical task information corresponding to the user identifier in the stored historical task information isolated by user identifier.

[0021] Optionally, after the step of obtaining the user request message, the method further includes:

[0022] Obtain the mutual exclusion information corresponding to the target user identifier;

[0023] If the mutual exclusion information indicates that the task processing resources corresponding to the target user identifier are not occupied, it is determined that there is no corresponding task being executed for the target user identifier.

[0024] Optionally, the mutual exclusion information includes a local mutual exclusion identifier and a cross-node mutual exclusion lock, wherein the cross-node mutual exclusion lock is used to restrict each service node in the intelligent agent system to only one service node at a time to process the request message corresponding to the same user identifier.

[0025] The step of determining that there is no corresponding task being executed for the target user identifier when the mutual exclusion information indicates that the task processing resource corresponding to the target user identifier is not occupied includes:

[0026] If the local mutex identifier is the first identifier and the cross-node mutex lock is successfully acquired, it is determined that the target user identifier does not have a corresponding task being executed.

[0027] After the step of obtaining the task processing result, the method further includes:

[0028] Set the local mutex identifier to the second identifier and release the cross-node mutex lock.

[0029] Optionally, the stored historical task information isolated based on user identifiers includes: user dialogue information partitioned according to user identifiers and historical task semantic information carrying user identifiers.

[0030] Optionally, the step of obtaining the user request message includes:

[0031] Retrieve messages to be processed from the message queue corresponding to the target user identifier;

[0032] If any message in the pending messages has a waiting time exceeding a preset duration, discard the message with the waiting time exceeding the preset duration and obtain the user request message; and / or,

[0033] If the pending messages include multiple messages, the multiple pending messages are merged into one message to obtain the user request message.

[0034] Secondly, embodiments of this application provide a task processing device based on an intelligent agent, applied to the service process of a service node in an intelligent agent system, wherein the service node includes a pool of agent service instances, and the device includes:

[0035] The request isolation module is used to obtain user request messages, wherein the user request messages are bound to a target user identifier;

[0036] The execution isolation module is used to remove proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool when it is determined that there is no corresponding task being executed for the target user identifier and no proxy service instance corresponding to the target user identifier is found in the proxy service instance pool.

[0037] The instance isolation module is used to create a proxy service instance corresponding to the target user identifier in the proxy service instance pool, which serves as the target proxy service instance, and to record the last active time of the target proxy service instance based on the current time.

[0038] The storage isolation module is used to obtain the historical task information corresponding to the target user identifier from the stored historical task information based on user identifier isolation;

[0039] The model reasoning module is used to process the user request message by calling the large language model based on the target proxy service instance and the acquired historical task information, and to obtain the task processing result.

[0040] Thirdly, embodiments of this application provide an intelligent proxy system, the system including service nodes and clients, wherein the service node includes a pool of proxy service instances, wherein:

[0041] The client is used to send user request messages;

[0042] The service process of the service node is used to execute any of the methods described in the first aspect above.

[0043] Fourthly, embodiments of this application provide a service node, including:

[0044] Memory, used to store computer programs;

[0045] When a processor executes a program stored in memory, it implements any of the methods described in the first aspect above.

[0046] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods described in the first aspect above.

[0047] Beneficial effects of the embodiments in this application:

[0048] The solution and method provided in this application embodiment are applied to the service process of a service node in an intelligent agent system. The service node includes a pool of agent service instances. The service process of the service node can obtain user request messages, wherein the user request message is bound to a target user identifier. If it is determined that there is no corresponding task being executed for the target user identifier, and no agent service instance corresponding to the target user identifier is found in the agent service instance pool, agent service instances that meet the inactive condition are removed based on the last active time of each agent service instance in the agent service instance pool. An agent service instance corresponding to the target user identifier is created in the agent service instance pool as the target agent service instance, and the last active time of the target agent service instance is recorded based on the current time. Historical task information corresponding to the target user identifier is obtained from the stored historical task information isolated based on user identifier. Based on the target agent service instance and the obtained historical task information, a large language model is called to process the user request message to obtain the task processing result. In this embodiment, from the user request message, the proxy service instance, to the processing of the user request message when there is no corresponding currently executing task for the target user identifier, and then to the storage of historical task information, all are logically isolated based on the user identifier. This ensures that the request messages of the same user are executed serially, while the request messages of multiple users can be executed concurrently, sharing a single service process. User isolation can be achieved without adopting a physical isolation mode where each user has an independent running environment. On this basis, the service process removes proxy service instances that meet the inactive conditions and evicts inactive proxy service instances through dynamic pooling, greatly improving resource utilization.

[0049] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

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

[0051] Figure 1 A schematic diagram of the intelligent agent system architecture provided in the embodiments of this application;

[0052] Figure 2 A flowchart illustrating a task processing method based on intelligent agents provided in this application embodiment;

[0053] Figure 3 For based on Figure 2 A flowchart of a capacity eviction method according to the embodiment shown;

[0054] Figure 4 For based on Figure 2 A flowchart of a timed eviction method according to the embodiment shown;

[0055] Figure 5 For based on Figure 2 A flowchart illustrating a method for determining the existence of a task being executed in the illustrated embodiment;

[0056] Figure 6 For based on Figure 2 A flowchart illustrating a task processing method based on intelligent agents in the embodiment shown.

[0057] Figure 7 For based on Figure 2 A timing diagram illustrating a task processing procedure based on a smart agent in the embodiment shown.

[0058] Figure 8 A schematic diagram of the structure of a task processing device based on an intelligent agent provided in an embodiment of this application;

[0059] Figure 9 This is a schematic diagram of the structure of an intelligent agent system provided in an embodiment of this application;

[0060] Figure 10 This is a schematic diagram of the structure of a service node provided in an embodiment of this application. Detailed Implementation

[0061] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0062] To improve resource utilization while achieving user isolation, embodiments of this application provide a task processing method, apparatus, intelligent agent system, service node, computer-readable storage medium, and computer program product based on intelligent agents. The following first describes a task processing method based on intelligent agents provided by embodiments of this application.

[0063] To facilitate understanding of the solutions provided in the embodiments of this application, the technical terms used herein are explained below:

[0064] AI Agent: An intelligent agent entity based on a Large Language Model (LLM) that can autonomously reason, invoke tools, and complete tasks.

[0065] ReAct Agent: An AI Agent that adopts the Reason+Act model, autonomously completes multi-step tasks through a cycle of "thinking → acting → observing".

[0066] User: An independent entity that uses the AI ​​Agent service and can be distinguished by a unique identifier.

[0067] Agent Pool (Agent Service Instance Pool): A container that manages multiple AI Agent instances, supporting dynamic creation, reuse, and recycling.

[0068] Request context: User identity information bound to the current request message, valid during request message processing.

[0069] Mutex lock: A mechanism that ensures that only one execution unit can operate on a specific resource at any given time.

[0070] LRU (Least Recently Used) eviction: An eviction policy based on the "least recently used" rule.

[0071] Token budget: A quota management mechanism that limits the total number of context tokens sent to a large language model.

[0072] Long-term memory storage: A storage system that supports semantic similarity search, used to store and retrieve the long-term memory of the AI ​​Agent.

[0073] This application provides a task processing method based on intelligent agents, applied to the service process of a service node in an intelligent agent system. The service node includes a pool of agent service instances. See also... Figure 1 The intelligent agent system may include a client 110, a service cluster 120, and distributed storage 130, etc. Multiple service nodes (e.g., node 1 and node 2) form the service cluster 120. Each user (e.g., user A, user B, and user C) can send request messages through the client. Figure 1 The request is sent to the service node. The service process on the service node can call the large language model service in the external service 140 based on the information stored in the distributed storage 130, thereby completing the processing of the request message. The external service 140 can also provide functions such as a service registry, which are not specifically limited here.

[0074] See Figure 2 A task processing method based on intelligent agents is applied to the service process of a service node in an intelligent agent system. The service node includes a pool of agent service instances. The method includes: S201, obtaining a user request message, wherein the user request message is bound to a target user identifier; S202, if it is determined that there is no corresponding task being executed for the target user identifier, and no agent service instance corresponding to the target user identifier is found in the agent service instance pool, removing agent service instances that meet the inactive condition based on the last active time of each agent service instance in the agent service instance pool; S203, creating an agent service instance corresponding to the target user identifier in the agent service instance pool as a target agent service instance, and recording the last active time of the target agent service instance based on the current time; S204, obtaining historical task information corresponding to the target user identifier from stored historical task information isolated based on user identifier; S205, processing the user request message by calling a large language model based on the target agent service instance and the obtained historical task information to obtain a task processing result. In this embodiment, from the user request message, the proxy service instance, to the processing of the user request message when there is no corresponding currently executing task for the target user identifier, and then to the storage of historical task information, all are logically isolated based on the user identifier. This ensures that the request messages of the same user are executed serially, while the request messages of multiple users can be executed concurrently, sharing a single service process. User isolation can be achieved without adopting a physical isolation mode where each user has an independent running environment. On this basis, the service process removes proxy service instances that meet the inactive conditions and evicts inactive proxy service instances through dynamic pooling, greatly improving resource utilization.

[0075] When a user needs to handle a task, they can send a user request message to the service node through the client. For example, a user can enter their search query in the service interface displayed on the client. The service node's service process can then receive the user request message and assign it a target user identifier.

[0076] In the first layer of isolation, namely request-level isolation, provided in the logical isolation mode of this application embodiment, a request context binding mechanism is adopted to bind each user request message to its own user, ensuring that all operations within the same processing flow belong to the correct user. The lifecycle of this mechanism is from the time the user request message is received at the request entry point and the target user identifier is bound, until the user request message is cleared after processing.

[0077] As one implementation method, when a user sends a user request message to the AI ​​Agent service (i.e., the intelligent agent system), the system receives the user request message, extracts the target user identifier and message identifier, performs authentication verification, user-level rate limiting checks, message deduplication checks, etc., and can create asynchronous task records and store them in external storage. Alternatively, the user request message can be enqueued into a user-specific queue, and the task identifier can be returned to the caller (i.e., the user) in a non-blocking manner.

[0078] Furthermore, the service process can retrieve pending user request messages from the user-specific queue and bind them to the request context, that is, mark the target user identifier and bind the user request message to the target user identifier.

[0079] In the second layer of isolation, namely execution-level isolation, provided in the logical isolation mode of this application embodiment, a mutual exclusion mechanism is used to ensure that user request messages of the same user are executed serially, while user request messages of different users are executed completely in parallel. Specifically, in the above step S202, the service process can determine whether there is a corresponding task being executed for the target user identifier. If there is a corresponding task being executed for the target user identifier, it means that the system is processing other messages sent by the user corresponding to the target user identifier. The service process can wait for the next consumption instead of continuing to process user request messages. This can avoid multiple messages of the same user being executed at the same time, which would lead to user dialogue confusion and prevent the large language model from fully considering it. It can also ensure that the state of the subsequent proxy service instance is correct and stable, and that the state of the proxy service instance will not be disordered.

[0080] If no corresponding task is currently being executed for the target user identifier, it means that no other messages sent by the user corresponding to the target user identifier are being processed at present. The service process can continue to determine whether a proxy service instance corresponding to the target user identifier can be found in the proxy service instance pool. If no proxy service instance corresponding to the target user identifier is found, a new proxy service instance corresponding to the target user identifier needs to be created.

[0081] The service process can remove proxy service instances that meet the inactive criteria based on the last active time of each proxy service instance in the proxy service instance pool. Proxy service instances that meet the inactive criteria are those that have been used very infrequently. The service process can remove these proxy service instances based on the LRU eviction policy to release proxy service instance resources.

[0082] The service process can then create a proxy service instance corresponding to the target user identifier in the proxy service instance pool, which serves as the target proxy service instance. It also records the last active time of the target proxy service instance based on the current time, i.e., executes step S204 above. The proxy service instance includes independent memory information, hook functions, toolsets, etc., which are not specifically limited here. The proxy service instance pool can be created using a thread-safe hash mapping method.

[0083] For example, see Figure 1 Each service node has an independent instance pool, i.e., an Agent pool. The Agent pool of service node 1 can include the proxy service instance corresponding to user A, i.e., the user A instance, and the proxy service instance corresponding to user B, i.e., the user B instance. The Agent pool of service node 2 can include the proxy service instance corresponding to user C, i.e., the user C instance, as well as the proxy service instances corresponding to other users, i.e., other instances.

[0084] After creating the proxy service instance corresponding to the target user identifier, the creation time can be determined as the last active time of the target proxy service instance, so that LRU eviction management can be performed on each proxy service instance based on the last active time.

[0085] The third layer of isolation in the logical isolation mode provided in this application embodiment is instance-level isolation. Through the above-mentioned Agent instance pool, i.e. proxy service instance pool mechanism, it is ensured that each user has an independent Agent instance, i.e. proxy service instance, which can be managed by management strategies such as on-demand creation and LRU eviction.

[0086] Next, the service process can retrieve the historical task information corresponding to the target user identifier from the stored historical task information isolated based on user identifier. The logical isolation mode provided in this application embodiment also includes storage information isolation, which can isolate historical task information through user identifier.

[0087] Historical task information isolated based on user identifiers can include short-term memories, task states, message queues, etc., for different users. This information is completely isolated based on user identifiers in shared storage. It can also include historical task information such as long-term semantic memory isolated based on user identifiers. Service processes can obtain the corresponding historical task information based on the target user identifier.

[0088] In step S205 above, the service process can process the user request message by calling the large language model based on the target proxy service instance and the acquired historical task information, and obtain the task processing result. The service process can trigger the hook function of the target proxy service instance to search for memory related to the target user identifier from long-term memory storage, inject the context, and load short-term dialogue memory separated by user identifier from external storage. Then, based on the token budget constraint, the context is assembled, where the context may include system prompts, tool definitions, historical messages, long-term memory, etc.

[0089] Furthermore, based on the assembled context, a large language model can be invoked for reasoning. After the large language model completes the reasoning, the task processing result is obtained and returned to the user, thus completing the processing of the user's request message. The service process can also store dialogue messages in short-term storage and long-term memory respectively.

[0090] When there are user request messages from multiple users that need to be processed, the same service process can process the user request messages from multiple users concurrently. For each user's user request message, the processing method described above can be used to obtain the task processing result.

[0091] This application proposes a multi-user AI Agent management architecture of "multi-layer isolation + dynamic pooling", which transforms the traditional "one user, one process" physical isolation mode into a "multi-user shared process" logical isolation mode, thereby improving resource utilization by an order of magnitude while ensuring user data security.

[0092] For example, multiple enterprise customers share the same AI Agent infrastructure. Each enterprise's knowledge base, conversation records, and tool configurations are completely isolated through the aforementioned multi-layered isolation. Even if Enterprise A's Agent and Enterprise B's Agent run in the same service process, Enterprise A's Agent cannot access any data from Enterprise B, and similarly, Enterprise B's Agent cannot access any data from Enterprise A, ensuring the security of user data.

[0093] As one possible implementation, the method may further include: if a proxy service instance corresponding to the target user identifier is found, using the found proxy service instance as the target proxy service instance; and updating the last active time of the target proxy service instance based on the current time. In this embodiment, when a proxy service instance corresponding to the target user identifier already exists in the proxy service instance pool, that proxy service instance is directly reused as the target proxy service instance, enabling on-demand creation of proxy service instances, ensuring that each user has an independent proxy service instance, avoiding resource waste, and simultaneously updating the last active time of the target proxy service instance to facilitate subsequent management of the target proxy service instance.

[0094] The service process can use the target user identifier as an index to traverse all existing proxy service instances in the proxy service instance pool to determine whether there is a proxy service instance corresponding to the target user identifier. If found, it will be used as the target proxy service instance for subsequent large language model invocation operations.

[0095] To facilitate the search for target proxy service instances, the service process can store the correspondence between user identifiers and proxy service instances. Based on this correspondence, the service process can quickly and accurately determine whether a target proxy service instance already exists in the proxy service instance pool.

[0096] The service process can update the last active time of the target proxy service instance based on the current time. For example, it can record the last active time of the target proxy service instance as the current time to ensure that the last active time can accurately represent the active status of the target proxy service instance.

[0097] As a possible implementation, before the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool, the method may further include: determining whether the capacity of the proxy service instance pool has reached a preset capacity; if the capacity of the proxy service instance pool has reached the preset capacity, performing the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool; and / or, detecting the last active time of each proxy service instance in the proxy service instance pool according to a preset period, and performing the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool. In this embodiment, the service process can manage the proxy service instance pool by using timed eviction, i.e., periodic scanning, where users who are inactive for more than a configured time are evicted, and / or capacity eviction, i.e., evicting the least active users when the pool is full, thereby further improving resource utilization and achieving optimal user coverage under limited resources.

[0098] In one implementation, namely capacity eviction, the service process can determine whether the capacity of the proxy service instance pool has reached a preset capacity. If the capacity of the proxy service instance pool has reached the preset capacity, it means that the remaining capacity of the current proxy service instance pool is very small. In order to ensure that resources are allocated to active users, the service process can perform the above-mentioned steps of removing proxy service instances that meet the inactive conditions based on the last active time of each proxy service instance in the proxy service instance pool, thereby releasing the capacity of the proxy service instance pool.

[0099] The preset capacity can be set according to factors such as the amount of resources required to create a proxy service instance. For example, it can be 90%, 95%, or 88% of the maximum capacity of the proxy service instance pool. Of course, it can also be set to the maximum capacity of the proxy service instance pool. No specific limitation is made here.

[0100] The proxy service instance that meets the inactive condition can be either a proxy service instance whose time difference between the last active time and the current time exceeds a threshold, or a proxy service instance whose last active time is the earliest compared to the current time. Both are reasonable.

[0101] For example, see Figure 3 Upon receiving the user request message, in step S301, the service process can search for the user identifier in the instance pool, specifically the proxy service instance corresponding to the target user identifier. If not found, proceed to step S302 to determine if the pool is full. If so, proceed to step S303 to find the least active instance. The service process can determine the least active proxy service instance based on the last active time of each proxy service instance in the proxy service instance pool—that is, the proxy service instance whose last active time is earliest compared to the current time. Then, this instance can be removed from the pool, i.e., proceed to step S304.

[0102] If it is determined that the pool capacity is not full (i.e., if the result of determining that the pool capacity is full is not true), the service process can create a new agent instance, i.e., execute step S305, which is to create a proxy service instance corresponding to the target user identifier. If a proxy service instance corresponding to the target user identifier is found in the proxy service instance pool, then step S307 is executed to update the last active time. Furthermore, the service process can use an existing agent instance (i.e., execute step S308) and execute step S309 through the agent instance corresponding to the target user identifier. The agent instance performs inference until processing is complete and the task processing result is obtained.

[0103] In another implementation, namely timed eviction, the service process can detect the last active time of each proxy service instance in the proxy service instance pool according to a preset period, and perform the above-mentioned steps of removing proxy service instances that meet the inactive conditions based on the last active time of each proxy service instance in the proxy service instance pool, thereby releasing the capacity of the proxy service instance pool.

[0104] The preset period can be determined based on the real-time requirements of the proxy service instance pool management. If the real-time requirements are high, the preset period can be set to a shorter period, such as 20 seconds, 30 seconds, or 60 seconds. If the real-time requirements are low, the preset period can be set to a longer period, such as 5 minutes, 3 minutes, or 10 minutes. No specific limitation is made here.

[0105] For example, see Figure 4 A timer can be set to trigger the service process to periodically scan each proxy service instance when a preset period is reached. Specifically, in step S401, the service process can scan all proxy instances. When traversing each instance, it can determine whether the currently traversed proxy service instance meets the inactivity condition. For example, it can determine whether the time difference between the last active time and the current time exceeds a threshold. If the proxy service instance is still active, that is, the time difference between the last active time and the current time does not exceed the threshold, step S402 can be executed, that is, the proxy service instance can be retained.

[0106] If the inactive instance of the proxy service exceeds the inactivity threshold, that is, the time difference between the last active time and the current time exceeds the threshold, then step S403 is executed to evict the inactive instance in order to release memory.

[0107] As one possible implementation, after the step of removing proxy service instances that meet the inactive condition, the method may further include: upon receiving a request message from a user identifier corresponding to the removed proxy service instance, reconstructing the proxy service instance corresponding to the user identifier based on the historical task information corresponding to the user identifier in the stored historical task information isolated by user identifier. In this embodiment, when the user corresponding to the user identifier of the removed proxy service instance sends a request message again, the proxy service instance corresponding to the user identifier can be automatically reconstructed, and the context corresponding to the proxy service instance can be recovered from the historical task information corresponding to the user identifier in the historical task information, achieving automatic reconstruction for the next request after eviction without state loss.

[0108] The aforementioned historical task information based on user identifier isolation stores historical task information corresponding to each user identifier. In this embodiment, see... Figure 1 The runtime state and persistent state of the Agent instance are separated. Short-term memory, locks, and message queues are stored in external short-term storage, dialogue history and task information are persisted in external persistent storage, and long-term semantic memory is stored in long-term memory storage. In this way, when the agent service instance is removed, the above information about the agent service instance will not be lost, so that the Agent instance can be rebuilt on any service node without losing context.

[0109] If a request message is received for the user identifier corresponding to the removed proxy service instance, it means that the user corresponding to the user identifier has become an active user and needs to call the large language model to process the dialogue task. The service process can then restore the removed proxy service instance and its context based on the historical task information corresponding to the user identifier stored above. This can include memory information, hook functions, toolsets, etc.

[0110] For example, see Figure 3 For the recreated agent service instance, the service process can execute step S306 to restore the context from external storage, thereby restoring the removed agent service instance. For example, thousands of users simultaneously use AI agents to control home devices, with each user's conversation history, device preferences, scheduled tasks, and other data completely isolated. A single service instance is managed through Agent pooling, maintaining Agent instances only for currently active users (e.g., approximately 10% of users), while the state of the remaining users is securely stored in external storage. When needed, the corresponding Agent instance can be recreated in milliseconds.

[0111] For example, an intelligent agent system might have over 100,000 registered users, approximately 10,000 daily active users, and around 1,000 concurrent users. The agent pool maintains only the most active agent instances. When a new user sends a request message, the least active agent instance is automatically evicted, and a new agent instance is created for the new user. When the evicted user sends a request message again, the service process restores the complete context of the agent instance from external storage, without the user noticing.

[0112] Existing containerization solutions use containers as the smallest unit of scaling. Starting a new container takes several seconds to tens of seconds, making it unsuitable for handling sudden traffic spikes. Furthermore, the number of containers is linearly related to the number of users, resulting in high operational complexity. In this embodiment, however, the creation and eviction of Agent instances are performed in memory, completing the process in milliseconds without waiting for the container to start. Agent instances can be evicted and recreated at any time, and all persistent state is stored in external distributed storage. Evicted Agent instances can be quickly recreated.

[0113] As one possible implementation, after the step of obtaining the user request message described above, see [link to relevant documentation]. Figure 5 The above method may further include: S501, obtaining mutual exclusion information corresponding to the target user identifier; S502, if the mutual exclusion information indicates that the task processing resources corresponding to the target user identifier are not occupied, determining that there is no corresponding task being executed for the target user identifier. In this embodiment, by setting mutual exclusion information, it can be ensured that request messages from the same user are processed serially, and request messages from different users are processed completely in parallel, thus ensuring execution-level user isolation.

[0114] After receiving the user request message, the service process can obtain the mutual exclusion information corresponding to the target user identifier. The mutual exclusion information corresponding to the user identifier is a pre-set information used to indicate whether the task processing resources corresponding to the user identifier are occupied.

[0115] If the obtained mutual exclusion information indicates that the task processing resource corresponding to the target user identifier is occupied, it means that a user request message corresponding to the target user identifier is currently being processed. At this time, the currently obtained user request message can be left unprocessed and wait for the next processing time before proceeding with subsequent processing.

[0116] In one implementation, the service process can put the currently acquired user request message back into the message queue corresponding to the target user identifier, wait for the currently being processed user request message corresponding to the target user identifier to be processed, and then retrieve the put-back user request message from the message queue for processing.

[0117] If the obtained mutual exclusion information indicates that the task processing resource corresponding to the target user identifier is not occupied, it means that there is currently no user request message corresponding to the target user identifier being processed. At this time, it can be determined that there is no corresponding task being executed for the target user identifier, and then the subsequent steps such as not finding a proxy service instance corresponding to the target user identifier in the proxy service instance pool can continue.

[0118] As one possible implementation, the aforementioned mutual exclusion information may include a local mutual exclusion identifier and a cross-node mutual exclusion lock. The cross-node mutual exclusion lock is used to restrict each service node in the intelligent agent system to only one service node at a time, allowing it to process request messages corresponding to the same user identifier. The step of determining that the target user identifier does not have a corresponding currently executing task when the mutual exclusion information indicates that the task processing resource corresponding to the target user identifier is not occupied may include: determining that the target user identifier does not have a corresponding currently executing task when the local mutual exclusion identifier is a first identifier and the cross-node mutual exclusion lock is successfully acquired; after obtaining the task processing result, the method further includes: setting the local mutual exclusion identifier to a second identifier and releasing the cross-node mutual exclusion lock. In this embodiment, by setting the local mutual exclusion identifier and the cross-node mutual exclusion lock, and using the user identifier as the granularity, dual serialization of the same user's request messages is achieved across service nodes and within service nodes, ensuring the serialization of the execution of the same user's request messages in cross-service node scenarios.

[0119] The aforementioned mutual exclusion information can include local mutex identifiers and cross-node mutex locks. Both local mutex identifiers and cross-node mutex locks can be based on user identifiers, meaning each user identifier corresponds to one local mutex identifier and one cross-node mutex lock. The cross-node mutex lock is used to restrict the intelligent agent system so that only one service node can process request messages corresponding to the same user identifier at a time.

[0120] The local mutex flag can be set to either a first flag or a second flag. The first flag indicates that the service node is not executing the task corresponding to the user flag locally, while the second flag indicates that the service node is executing the task corresponding to the user flag locally.

[0121] After obtaining the user request message corresponding to the target user identifier, the service process can check the local mutex identifier and attempt to acquire the cross-node mutex lock. If the local mutex identifier is the first identifier, it means that the current service node is not executing the task corresponding to the target user identifier locally. If the cross-node mutex lock is successfully acquired, it means that among the service nodes in the intelligent agent system, apart from the current service node, no other service node is processing the request message corresponding to the target user identifier. In this case, the service process can determine that there is no corresponding task being executed for the target user identifier.

[0122] After obtaining the above task processing results, the service process can set the local mutex corresponding to the target user identifier to the second identifier and release the cross-node mutex corresponding to the target user identifier to indicate that the user request message corresponding to the target user identifier has been processed, thus ensuring the accuracy of subsequent processing of request messages for each user.

[0123] If the local mutex identifier is the second identifier, it means that the current service node is currently executing the task corresponding to the target user identifier locally. If it cannot acquire the cross-node mutex lock, it means that in addition to the current service node, there are other service nodes in the intelligent agent system that are processing the request message corresponding to the target user identifier. In order to ensure that the request messages of the same user are executed serially, the service process can wait for the next processing time before proceeding with subsequent processing.

[0124] Of course, after obtaining the target proxy service instance, the service process can also check the local mutex again to prevent the request messages of the same user from being executed concurrently, which is reasonable.

[0125] As one possible implementation, the stored historical task information isolated based on user identifiers may include: user dialogue information partitioned according to user identifiers and historical task semantic information carrying user identifiers. In this embodiment, the storage information isolation included in the above logical isolation mode may specifically include storage-level isolation and memory-level isolation. Storage-level isolation refers to user dialogue information partitioned according to user identifiers, and memory-level isolation refers to historical task semantic information carrying user identifiers. Both are isolated through user identifiers to ensure that the historical task information of different users is logically completely isolated.

[0126] The logical isolation mode provided in this application embodiment also includes a fourth layer of isolation, namely storage-level isolation. Through the mechanism of partitioning data according to user identifier in shared storage, it ensures that user dialogue information such as short-term memory, task status, and message queues of different users are completely isolated in shared storage.

[0127] For example, if an intelligent agent system has 50 users, then in the shared storage, the data can be partitioned according to the user identifiers of the 50 users, with each user identifier corresponding to a data area to store the user's dialogue information.

[0128] The logical isolation mode provided in this application embodiment also includes a fifth layer of isolation, namely memory-level isolation. Through a mechanism of filtering by user identifier in long-term memory storage, it ensures that the long-term historical task semantic memory of different users is completely isolated. When storing and searching long-term historical task semantic memory, the user identifier is passed as a filtering condition.

[0129] For example, see Figure 1 The distributed storage 130 includes short-term storage, persistent storage, and long-term memory storage. Specifically, short-term storage can include short-term memory, locks (i.e., the aforementioned cross-node mutex locks), message queues, etc. Persistent storage can include task status, specifically dialogue history and task information. Long-term memory storage can include semantic memory, i.e., the aforementioned historical task semantic information. Short-term and persistent storage can be partitioned according to user identifiers, while long-term memory storage carries user identifiers, using them as filtering conditions during storage and searching.

[0130] In existing related technologies, OpenClaw's file system memory cannot be shared in a distributed environment, and the memory of each Agent instance is isolated. When horizontal scaling is required, stateless migration of Agent instances cannot be achieved. In this embodiment, all persistent state is stored in external distributed storage, isolated according to user identifiers. Agent instances can be evicted and recreated at any time based on persistent state storage.

[0131] As one possible implementation, the above-described step of obtaining user request messages may include: obtaining pending messages from the message queue corresponding to the target user identifier; if there are messages in the pending messages whose waiting time exceeds a preset duration, discarding messages whose waiting time exceeds the preset duration to obtain the user request message; and / or, if the pending messages include multiple messages, merging the multiple pending messages into one message to obtain the user request message. Existing OpenClaw uses a single-threaded ReAct Agent loop, which can only process one task at a time. When the same user quickly sends multiple messages, the lack of message queuing, merging, and deduplication mechanisms may lead to Agent state confusion. In this embodiment, a mechanism is provided to discard timed-out pending messages and / or merge multiple pending messages to avoid Agent state confusion.

[0132] After retrieving the message to be processed from the message queue corresponding to the target user identifier, the service process can check whether there are any messages in the message to be processed that have a waiting time exceeding the preset time. If there are, it means that the message to be processed has been waiting for too long and is a timeout message. The service process can discard the message and treat the remaining messages to be processed as user request messages.

[0133] If the pending message includes multiple messages, the service process can merge the multiple pending messages into one message to obtain the user request message. In this way, the merged message can be processed uniformly, and even if the same user sends multiple messages quickly, it will not cause processing chaos.

[0134] As one possible implementation, an example of the task processing method based on intelligent agents provided in this application embodiment can be found here. Figure 6 The aforementioned logical isolation mode includes a five-layer isolation architecture: request-level isolation, execution-level isolation, instance-level isolation, storage-level isolation, and memory-level isolation. Combined with a dynamic pooling management strategy, it enables secure and efficient provision of AI Agent services to a large number of users within a single service process. Figure 6 This demonstrates a five-layer user isolation architecture, from the request entry point to data storage. Each layer addresses isolation issues from different perspectives, and the five layers work together to form a complete isolation chain. Details are as follows:

[0135] The first-level request-level isolation includes steps S601 (request arrival), S602 (binding user context), and S603 (marking the current user identifier). The first-level isolation achieves request-level isolation based on user identifiers by binding the request context to the user identifier.

[0136] In the second-level execution-level isolation, step S604 involves acquiring a mutex lock. If acquisition is successful, step S605 is executed, allowing the message processing task to proceed, followed by step S606, setting the local mutex flag to "occupied". If mutex acquisition fails, step S607 is executed, re-enqueuing the message and waiting. The second-level isolation uses mutex locks to ensure the serialization of request messages from the same user, thus achieving execution-level isolation.

[0137] In the third-level instance-level isolation, step S608 involves searching for or creating an instance in the instance pool, i.e., searching for the target proxy service instance. If the target proxy service instance already exists, step S609 is executed to reuse the existing proxy instance; if the target proxy service instance does not exist, step S610 is executed to create a new proxy instance. At this point, it can be checked whether the pool capacity is full, i.e., step S611 is executed; if so, step S612 is executed to evict the least active instance; if not, step S613 is executed to directly create a new proxy instance. The third-level isolation achieves agent instance isolation through dynamic pooling, such as each user having an independent Agent instance, on-demand creation, LRU eviction, and capacity limit eviction.

[0138] In the fourth-level storage isolation, steps S614 and S615 are included: short-term storage is isolated by user identifier, and persistent storage is filtered by user identifier. The fourth-level isolation achieves storage-level isolation of data through user identifier partitioning in the storage layer.

[0139] In the fifth layer—memory-level isolation—step S616 is included, where long-term memory is filtered by user identifier. The fifth layer isolation achieves memory-level isolation through filtering by user identifiers stored in long-term memory.

[0140] The service process can call the Agent instance in the third layer of isolation, and based on the stored data corresponding to the target user identifier in the fourth layer of isolation and the long-term memory in the fifth layer of isolation, it can perform inference through the large language model to obtain the inference result, i.e., step S617. Then, in step S618, the lock can be released and the context can be cleared.

[0141] The specific implementation methods of each of the above steps have been described in the above embodiments. Please refer to the description of the relevant parts in the above embodiments. They will not be repeated here.

[0142] This application proposes a "five-layer isolation + dynamic pooling" multi-user AI Agent management architecture, transforming the traditional "one user, one process" physical isolation mode into a "multi-user shared process" logical isolation mode. This improves resource utilization by an order of magnitude while ensuring data security. Through request-level user context binding, execution-level mutex lock serialization, instance-level isolation of the dynamic pool, storage-level user identifier partitioning isolation, and long-term memory storage user identifier filtering isolation, these five layers work together to form a complete user isolation chain.

[0143] The first layer of isolation provides user identification for all subsequent layers. The second layer ensures the concurrent safety of Agent instances in the third layer of isolation. The fourth and fifth layers of isolation enable the eviction and reconstruction of Agent instances in the third layer of isolation. These five layers of isolation work together to achieve user isolation, ensuring user data security and providing a complete isolation chain from the request level to the memory level. The failure of any one layer will not lead to data leakage. Horizontal scaling is also supported: adding service nodes linearly increases capacity. The Agent pool is managed independently in each service node, and mutex locks ensure the consistency of Agent instance states across service nodes.

[0144] As one possible implementation method, see Figure 7 The process of a service process from receiving a request message to completing its processing involves the following parts: external caller, access layer, message queue, consumer, instance pool, proxy instance, large language model, and memory storage. Among them, the external caller can be the user's client, the consumer is the service process, the access layer is the message entry point of the service node, and the memory storage can be distributed storage, including the aforementioned short-term storage, persistent storage, and long-term memory storage. The message mentioned below is the request message sent by the user.

[0145] The external caller sends a message to the access layer. The message may include a user ID and a message identifier. The access layer can perform operations such as authentication, rate limiting, and deduplication on the message, then enqueue the message to a user-specific queue. A non-blocking approach can be used to return a task identifier to the external caller. The consumer retrieves the message from the queue, binds it to the context, and acquires a mutex lock (per-user), where "per-user" indicates that the mutex lock is granular with the user ID.

[0146] Then, a proxy instance is obtained / created, which can return a user-specific instance. Next, the inference process is performed through the proxy instance: it can filter by user identifier in the memory storage, search long-term memory, and the memory storage returns relevant memories to the proxy instance. The proxy instance loads short-term dialogue history isolated by user identifier, then calls the large language model for inference, and the large language model returns the results to the proxy instance. The proxy instance can also store dialogues in the memory storage, isolated by user identifier.

[0147] Next, the consumer can perform a cleanup process, which involves releasing the lock and clearing the context. It then sends a callback notification of the result to the external caller, thus completing message processing. The proxy instance described above is the Agent instance.

[0148] In the above request message processing process, the first layer, request-level isolation, provides user identification and covers the entire request message processing process. The second layer, execution-level isolation, covers the post-message processing process after the service process retrieves the message. The third layer, instance-level isolation, covers the process from obtaining / creating the proxy instance to obtaining the inference result. The fourth and fifth layers, storage-level and memory-level isolation, cover the process from searching long-term memory to storing the conversation. These five layers of isolation work together at different stages of request message processing.

[0149] In the technical solution of this application, the operations of obtaining, storing, using, processing, transmitting, providing and disclosing user personal information are all carried out with the user's authorization.

[0150] Corresponding to the above-described task processing method based on intelligent agents, this application also provides a task processing device based on intelligent agents. The following is a description of the task processing device based on intelligent agents provided in this application.

[0151] See Figure 8A task processing device based on intelligent agents is applied to the service process of a service node in an intelligent agent system. The service node includes a pool of agent service instances. The device includes: a request isolation module 810, used to acquire user request messages, wherein the user request messages are bound to a target user identifier; an execution isolation module 820, used to remove agent service instances that meet the inactive condition based on the last active time of each agent service instance in the agent service instance pool when it is determined that there is no corresponding currently executing task for the target user identifier and no agent service instance corresponding to the target user identifier is found in the agent service instance pool; an instance isolation module 830, used to create an agent service instance corresponding to the target user identifier in the agent service instance pool as a target agent service instance, and record the last active time of the target agent service instance based on the current time; a storage isolation module 840, used to acquire historical task information corresponding to the target user identifier from stored historical task information based on user identifier isolation; and a model inference module 850, used to process the user request message by calling a large language model based on the target agent service instance and the acquired historical task information to obtain a task processing result. In this embodiment, from the user request message, the proxy service instance, to the processing of the user request message when there is no corresponding currently executing task for the target user identifier, and then to the storage of historical task information, all are logically isolated based on the user identifier. This ensures that the request messages of the same user are executed serially, while the request messages of multiple users can be executed concurrently, sharing a single service process. User isolation can be achieved without adopting a physical isolation mode where each user has an independent running environment. On this basis, the service process removes proxy service instances that meet the inactive conditions and evicts inactive proxy service instances through dynamic pooling, greatly improving resource utilization.

[0152] As one possible implementation, the above-described apparatus may further include:

[0153] The example search module is used to, when a proxy service instance corresponding to the target user identifier is found, use the found proxy service instance as the target proxy service instance;

[0154] The active time update module is used to update the last active time of the target proxy service instance based on the current time.

[0155] As one possible implementation, the above-described apparatus may further include:

[0156] The capacity determination module is used to determine whether the capacity of the proxy service instance pool has reached a preset capacity before removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool; and if the capacity of the proxy service instance pool has reached the preset capacity, triggering the removal of proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool; and / or,

[0157] The periodic detection module is used to detect the last active time of each proxy service instance in the proxy service instance pool according to a preset period, and trigger the removal of proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool.

[0158] As one possible implementation, the above-described apparatus may further include:

[0159] The instance reconstruction module is used to reconstruct the proxy service instance corresponding to the user identifier based on the historical task information corresponding to the user identifier in the stored historical task information isolated by user identifier after the removal of the proxy service instance that meets the inactive condition and upon obtaining a request message for the user identifier corresponding to the removed proxy service instance.

[0160] As one possible implementation, the above-described apparatus may further include:

[0161] The mutual exclusion information acquisition module is used to acquire the mutual exclusion information corresponding to the target user identifier after the step of acquiring the user request message;

[0162] The task execution confirmation module is used to determine that there is no corresponding task being executed for the target user identifier when the mutual exclusion information indicates that the task processing resources corresponding to the target user identifier are not occupied.

[0163] As one possible implementation, the aforementioned mutual exclusion information may include a local mutual exclusion identifier and a cross-node mutual exclusion lock, wherein the cross-node mutual exclusion lock is used to restrict each service node in the intelligent agent system to only one service node at a time being able to process request messages corresponding to the same user identifier.

[0164] The task execution confirmation module includes:

[0165] The task execution confirmation unit is used to determine that there is no corresponding task being executed for the target user identifier when the local mutex identifier is the first identifier and the cross-node mutex lock is successfully acquired.

[0166] The above-mentioned device may further include:

[0167] The mutex information reset module is used to set the local mutex identifier to the second identifier and release the cross-node mutex lock after the task processing result is obtained.

[0168] As one possible implementation, the aforementioned stored historical task information based on user identifier isolation includes: user dialogue information partitioned according to user identifier and historical task semantic information carrying user identifier.

[0169] As one possible implementation, the request isolation module 810 described above may include:

[0170] The message acquisition unit is used to acquire messages to be processed from the message queue corresponding to the target user identifier;

[0171] The message discarding unit is configured to discard messages with a waiting time exceeding a preset duration if such messages exist among the pending messages, and obtain the user request message; and / or,

[0172] The message merging unit is used to merge multiple messages into one message when the message to be processed includes multiple messages, to obtain a user request message.

[0173] Corresponding to the above-described task processing method based on intelligent agents, this application also provides an intelligent agent system, see [link to relevant documentation]. Figure 9 A smart agent system is disclosed, comprising a service node 910 and a client 920. The service node 910 includes a pool of agent service instances 911. The client 920 is used to send user request messages. The service process of the service node 910 is used to execute the task processing method based on the smart agent described in any of the above embodiments. In this embodiment, from the user request message, agent service instance, to processing the user request message when there is no corresponding task being executed for the target user identifier, and then to the storage of historical task information, all are logically isolated based on the user identifier. This ensures that the request messages of the same user are executed serially, while the request messages of multiple users can be executed concurrently, sharing a single service process. User isolation can be achieved without adopting a physical isolation mode of one user, one independent running environment. On this basis, the service process removes agent service instances that meet the inactive conditions and evicts inactive agent service instances through dynamic pooling, greatly improving resource utilization.

[0174] Figure 9 The example provided here uses a single service node, but this does not mean that the intelligent agent system provided in this application embodiment can only include one service node. The intelligent agent system can also include multiple service nodes, each of which is used to execute the intelligent agent-based task processing method described in any of the above embodiments.

[0175] This application also provides a service node, such as... Figure 10 As shown, it includes:

[0176] Memory 1010 is used to store computer programs;

[0177] When the processor 1020 executes the program stored in the memory 1010, it implements the steps of the task processing method based on intelligent agents described in any of the above embodiments.

[0178] In this embodiment, from the user request message, the proxy service instance, to the processing of the user request message when there is no corresponding currently executing task for the target user identifier, and then to the storage of historical task information, all are logically isolated based on the user identifier. This ensures that the request messages of the same user are executed serially, while the request messages of multiple users can be executed concurrently, sharing a single service process. User isolation can be achieved without adopting a physical isolation mode where each user has an independent running environment. On this basis, the service process removes proxy service instances that meet the inactive conditions and evicts inactive proxy service instances through dynamic pooling, greatly improving resource utilization.

[0179] Furthermore, the aforementioned service nodes may also include a communication bus and / or a communication interface, and the processor 1020, the communication interface, and the memory 1010 communicate with each other through the communication bus.

[0180] The communication bus mentioned in the above service nodes can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0181] The communication interface is used for communication between the aforementioned service nodes and other devices.

[0182] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0183] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0184] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of the task processing method based on intelligent agents described in any of the above embodiments.

[0185] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the task processing method based on intelligent agents described in any of the above embodiments.

[0186] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can 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 (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0187] It should be noted that, in this document, relational terms such as "first" and "second" are used only 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 one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0188] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, systems, computer-readable storage media, and computer program products are basically similar to the method embodiments, and therefore the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0189] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A task processing method based on intelligent agents, characterized in that, A service process applied to a service node in an intelligent agent system, wherein the service node includes a pool of agent service instances, the method comprising: Obtain a user request message, wherein the user request message is bound to a target user identifier; If it is determined that there is a corresponding task being executed for the target user identifier, wait for the next processing of the user request message; if it is determined that there is no corresponding task being executed for the target user identifier, and no proxy service instance corresponding to the target user identifier is found in the proxy service instance pool, based on the last active time of each proxy service instance in the proxy service instance pool, remove the proxy service instance that meets the inactive condition, so that the request messages of the same user are executed serially, and the request messages of multiple users can be executed concurrently to share a service process; Create a proxy service instance corresponding to the target user identifier in the proxy service instance pool as the target proxy service instance, and record the last active time of the target proxy service instance based on the current time; Obtain the historical task information corresponding to the target user identifier from the stored historical task information isolated based on user identifier; Based on the target proxy service instance and the acquired historical task information, the large language model is invoked to process the user request message and obtain the task processing result.

2. The method according to claim 1, characterized in that, The method further includes: If a proxy service instance corresponding to the target user identifier is found, the found proxy service instance shall be used as the target proxy service instance. Update the last active time of the target proxy service instance based on the current time.

3. The method according to claim 1, characterized in that, Before the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool, the method further includes: Determine whether the capacity of the proxy service instance pool has reached a preset capacity. If the capacity of the proxy service instance pool has reached the preset capacity, execute the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool; and / or, The last active time of each proxy service instance in the proxy service instance pool is detected according to a preset period, and the step of removing proxy service instances that meet the inactive condition based on the last active time of each proxy service instance in the proxy service instance pool is executed.

4. The method according to claim 3, characterized in that, After the step of removing proxy service instances that meet the inactive condition, the method further includes: Upon receiving a request message for the user identifier corresponding to the removed proxy service instance, the proxy service instance corresponding to the user identifier is reconstructed based on the historical task information corresponding to the user identifier in the stored historical task information isolated by user identifier.

5. The method according to claim 1, characterized in that, After the step of obtaining the user request message, the method further includes: Obtain the mutual exclusion information corresponding to the target user identifier, wherein the mutual exclusion information is pre-set information used to characterize whether the task processing resources corresponding to the target user identifier are occupied; If the mutual exclusion information indicates that the task processing resources corresponding to the target user identifier are not occupied, it is determined that there is no corresponding task being executed for the target user identifier.

6. The method according to claim 5, characterized in that, The mutual exclusion information includes a local mutual exclusion identifier and a cross-node mutual exclusion lock. The cross-node mutual exclusion lock is used to restrict each service node in the intelligent agent system to only one service node at a time, which can process the request message corresponding to the same user identifier. The step of determining that there is no corresponding task being executed for the target user identifier when the mutual exclusion information indicates that the task processing resource corresponding to the target user identifier is not occupied includes: If the local mutex identifier is the first identifier and the cross-node mutex lock is successfully acquired, it is determined that the target user identifier does not have a corresponding task being executed. After the step of obtaining the task processing result, the method further includes: Set the local mutex identifier to the second identifier and release the cross-node mutex lock.

7. The method according to any one of claims 1-6, characterized in that, The stored historical task information isolated based on user identifiers includes: user dialogue information partitioned according to user identifiers and historical task semantic information carrying user identifiers.

8. The method according to any one of claims 1-6, characterized in that, The step of obtaining the user request message includes: Retrieve messages to be processed from the message queue corresponding to the target user identifier; If any message in the pending messages has a waiting time exceeding a preset duration, discard the message with the waiting time exceeding the preset duration and obtain the user request message; and / or, If the pending messages include multiple messages, the multiple pending messages are merged into one message to obtain the user request message.

9. A task processing device based on intelligent agents, characterized in that, A service process applied to a service node in an intelligent agent system, wherein the service node includes a pool of agent service instances, and the device includes: The request isolation module is used to obtain user request messages, wherein the user request messages are bound to a target user identifier; The execution isolation module is used to wait for the next processing of the user request message if it is determined that there is a corresponding task being executed for the target user identifier; if it is determined that there is no corresponding task being executed for the target user identifier and no proxy service instance corresponding to the target user identifier is found in the proxy service instance pool, the proxy service instance that meets the inactive condition is removed based on the last active time of each proxy service instance in the proxy service instance pool, so that the request messages of the same user are executed serially and the request messages of multiple users can be executed concurrently to share a service process; The instance isolation module is used to create a proxy service instance corresponding to the target user identifier in the proxy service instance pool, which serves as the target proxy service instance, and to record the last active time of the target proxy service instance based on the current time. The storage isolation module is used to obtain the historical task information corresponding to the target user identifier from the stored historical task information based on user identifier isolation; The model reasoning module is used to process the user request message by calling the large language model based on the target proxy service instance and the acquired historical task information, and to obtain the task processing result.

10. An intelligent agent system, characterized in that, The system includes service nodes and clients. The service nodes include a pool of proxy service instances, wherein: The client is used to send user request messages; The service process of the service node is used to execute the method described in any one of claims 1-8.

11. A service node, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images