Distributed agent system, request processing method and device and storage medium

Abstract

One or more embodiments of the invention provide a distributed agent system, a request processing method, equipment and a storage medium. The distributed agent system comprises an agent scheduler, an event queue, a database and a plurality of agent actuators. And the agent scheduler creates a running instance according to the processing request, stores the running instance in an execution state into a database, and sends a starting event to an event queue. The multiple agent actuators monitor the event queue at the same time, and the same event is acquired by only one agent actuator. After obtaining the initial event or the intermediate event, the agent executor executes a corresponding predefined execution process, generates the intermediate event or an end event carrying an execution result, and returns the intermediate event or the end event to the event queue; after the ending event is obtained, the state of the running instance in the database is updated to be ending, and an execution result is stored. And if the agent scheduler monitors that the operation instance is in an end state from the database, obtaining an execution result from the database and outputting the execution result.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of computer software technology, and in particular, to a distributed intelligent agent system, a request processing method, an electronic device, a computer-readable storage medium, and a computer program product. Background Art

[0002] Agent-based applications are those that use agent technology to complete specific tasks or solve problems. Agents are independent entities with the ability to perceive, reason, learn, and act, making autonomous decisions and executing tasks based on environmental changes.

[0003] Currently, agent-based applications generally use a monolithic architecture to achieve processing power. In this architectural model, a single agent must fully handle the entire processing process, from request parsing, computational reasoning, to result generation. To cope with the increase in processing requests, a horizontal scaling approach is often adopted. This involves deploying multiple identical agents on multiple machines and distributing processing requests to different agents using a load balancer. This solution can share the load to a certain extent. However, each agent is still limited to the computing power of a single agent when executing tasks. When task processing involves large amounts of computation or complex data processing, the limited resources of a single agent can easily become a performance bottleneck. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide a distributed intelligent system, a request processing method, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0006] According to a first aspect of one or more embodiments of this specification, a distributed agent system is provided, including an agent scheduler, an event queue, a database, and a plurality of agent executors;

[0007] The agent scheduler is configured to create a running instance based on a received processing request, store context information of the running instance in the database, and send a start event indicated by the running instance to the event queue; the context information at least includes that the running instance is in an execution state; wherein the event queue is monitored by the multiple agent executors and supports the same event being obtained by only one agent executor;

[0008] The agent executor is configured to, if it listens to and obtains the start event from the event queue, execute the predefined execution process indicated by the start event to obtain a non-start event and send it to the event queue, wherein the non-start event includes an intermediate event and an end event carrying the execution result of the running instance; if it listens to and obtains the intermediate event from the event queue, execute the predefined execution process indicated by the intermediate event to obtain a non-start event and send it to the event queue; if it listens to and obtains the end event from the event queue, change the execution state in the database to an end state and store the execution result in the database;

[0009] The agent scheduler is further configured to obtain and output the execution result from the database if it is detected from the database that the running instance is in an ending state.

[0010] The system can achieve the following beneficial effects: Through the division of labor and collaboration among the agent scheduler, event queue, agent executor, and database, and by using different event types (starting events, intermediate events, and ending events) to indicate the different execution stages of a running instance, the system achieves decoupling of the various execution stages of the running instance. Each execution stage is connected through event transmission rather than direct calls, achieving loose coupling. The event-driven design enables the running instance to be executed asynchronously in stages after creation. When the starting event corresponding to the running instance is triggered, the agent executor responds and executes the corresponding predefined execution process. At the same time, the subsequent execution stages of the running instance proceed independently based on the event triggering link. Therefore, the delay of the entire running instance processing is distributed among the various execution stages, which can reduce the overall response time. In addition, multiple agent executors each independently listen for events from the event queue and independently run the predefined execution process corresponding to the monitored events. In this way, the different execution stages of multiple running instances can be carried out in parallel, and the resources of different agent executors are fully utilized, thereby significantly improving the overall system throughput.

[0011] According to a second aspect of an embodiment of this specification, there is provided a distributed agent system, comprising an agent scheduler, a database, and a plurality of agent executors;

[0012] The agent scheduler is configured to create a running instance according to the received processing request, store context information of the running instance in the database, and send a start instruction indicated by the running instance to one of the agent executors; the context information at least includes whether the running instance is in an execution state;

[0013] The agent executor is configured to, upon receiving the start instruction, execute the predefined execution process indicated by the start instruction to obtain non-start instructions and send them to the agent scheduler, wherein the non-start instructions include intermediate instructions and end instructions carrying the execution results of the running instance;

[0014] The agent scheduler is further configured to send the received non-starting instruction to the agent executor;

[0015] The agent executor is further configured to, upon receiving the intermediate instruction, run the predefined execution process indicated by the intermediate instruction to obtain a non-start instruction and send it to the agent scheduler; and, upon receiving the end instruction, change the execution state in the database to an end state and store the execution result in the database;

[0016] The agent scheduler is further configured to obtain and output the execution result from the database if it is detected from the database that the running instance is in an ending state.

[0017] The system can achieve the following beneficial effects: Through the collaborative work of the agent scheduler, multiple agent executors, and the database, this system effectively decouples and coordinates the various stages of task initiation, execution, and result feedback, enabling each running instance to execute independently and efficiently in a distributed environment. Multiple agent executors utilize distributed parallel processing, with each agent executor independently executing the relevant predefined execution process based on the instructions it receives. This eliminates reliance on the sequential execution of a single node, reduces single-point load, and improves the system's parallel processing capabilities and throughput.

[0018] According to a third aspect of the embodiments of this specification, a request processing method is provided, which is applied to the agent scheduler in the distributed agent system described in the first aspect; the method includes:

[0019] Create a running instance based on the received processing request;

[0020] Storing context information of the running instance in a database in the distributed agent system, and sending a start event indicated by the running instance to an event queue in the distributed agent system; the context information at least includes that the running instance is in an execution state;

[0021] If it is monitored from the database that the running instance is in the end state, the execution result of the running instance is obtained from the database and outputted.

[0022] According to a fourth aspect of the embodiments of this specification, a request processing method is provided, which is applied to an agent executor in the distributed agent system described in the first aspect; the method comprises:

[0023] If a start event of any running instance is monitored from the event queue in the distributed agent system, a predefined execution process indicated by the start event is executed to generate non-starting events and send them to the event queue. The non-starting events include intermediate events and end events carrying the execution results of the running instance;

[0024] If an intermediate event of any running instance is monitored from the event queue, the predefined execution process indicated by the intermediate event is run to generate a non-starting event and send it to the event queue;

[0025] If an end event of any running instance is monitored from the event queue, the execution state of the running instance in the database of the distributed agent system is changed to an end state, and the execution result is stored in the database.

[0026] According to a fifth aspect of the embodiments of this specification, an electronic device is provided, including:

[0027] processor;

[0028] a memory for storing processor-executable instructions;

[0029] When the processor executes the executable instructions, it is used to implement the method described in the third aspect or the fourth aspect.

[0030] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the steps of the method described in the third aspect or the fourth aspect are implemented.

[0031] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program, which implements the steps of the method described in the third aspect or the fourth aspect when executed by a processor.

[0032] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 This is a schematic diagram of the architecture of a distributed intelligent agent system provided by an exemplary embodiment.

[0034] Figure 2 It is a schematic diagram of an exemplary embodiment providing an intelligent agent executor calling an external tool when executing a predefined execution process.

[0035] Figure 3 It is a schematic diagram of the architecture of another distributed intelligent agent system provided by an exemplary embodiment.

[0036] Figure 4 This is a flowchart of a request processing method provided by an exemplary embodiment.

[0037] Figure 5 It is a flowchart of another request processing method provided by an exemplary embodiment.

[0038] Figure 6 It is a structural diagram of an electronic device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0039] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0040] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0041] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0042] Agent-based applications are those that use agent technology to complete specific tasks or solve problems. Agents are independent entities with the ability to perceive, reason, learn, and act, making autonomous decisions and executing tasks based on environmental changes.

[0043] Applications based on intelligent agents include but are not limited to: ① Intelligent assistants: helping users with task management, information query, intelligent control, etc. ② Recommendation system: using intelligent agents to recommend movies, music, commodities, etc. based on user interests and behaviors. ③ Automated customer service: Many companies use intelligent agents to provide customer service, such as chatbots, which interact with users through natural language processing to answer questions and handle requests. ④ Smart home: Intelligent agents can control home devices, such as adjusting temperature, controlling lights, managing security systems, etc., usually through voice assistants or automated scripts. ⑤ Autonomous driving: For example, the intelligent agents in self-driving cars perceive the environment through sensors and make driving decisions based on real-time data. ⑥ Intelligent manufacturing and robotics: In industrial automation, intelligent agents are used to control robots to complete production tasks and optimize production processes.

[0044] By empowering agents with autonomy and intelligent decision-making capabilities, agent-based applications can provide efficient and intelligent solutions in a variety of fields. These applications not only enhance user experience but also drive the development of automation and intelligence.

[0045] Based on the problems in related technologies, please refer to Figure 1 An embodiment of this specification provides a distributed intelligent agent system, including an intelligent agent scheduler 10, an event queue 20, a database 30, and multiple intelligent agent executors 40.

[0046] Exemplarily, the agent scheduler 10 and the agent executor 40 are software modules deployed on a computing device such as a server, virtual machine, or container. For example, the agent scheduler 10 is deployed on a dedicated server, while multiple agent executors 40 are distributed on different hardware nodes to achieve parallelism and high availability.

[0047] The agent scheduler 10 is used to create a running instance according to the received processing request, store the context information of the running instance in the database 30, and send the starting event indicated by the running instance to the event queue 20; the context information at least includes that the running instance is in the execution state.

[0048] A processing request is an instruction initiated by the system, either externally or internally, that requires the system to process or respond. The following examples illustrate processing requests in different scenarios:

[0049] ① Intelligent Assistant / Intelligent Assistant Scenario: Users enter "What's the weather like in City C tomorrow?" or "Please schedule a meeting for me tomorrow morning" into the conversational interface. These are typical voice or text queries. In this case, the processing request represents a natural language question, and the distributed agent system must generate a relevant response.

[0050] ② Intelligent customer service scenario: A user submits a question through online customer service: "The product I purchased has quality issues. How do I apply for a return?" or "What are the details of the promotion?" The processing request here is an inquiry or complaint from the customer service channel, and the distributed intelligent agent system needs to provide feedback on the solution.

[0051] ③ Smart Manufacturing Scenario: A monitoring system in a production workshop detects an equipment anomaly and issues a "device maintenance request" or "production line scheduling adjustment" instruction. This processing request originates from production data monitoring or an operator's instruction issued through the monitoring system. It is used to initiate fault diagnosis, maintenance procedures, or production scheduling to ensure efficient and stable production processes.

[0052] ④ Enterprise Automation Application: An internal workflow system receives a request for a document approval request or automated financial statement analysis. In this scenario, the request might be initiated by an employee, triggering an approval process. The distributed agent system then completes the automated approval or report generation and provides feedback to the relevant personnel.

[0053] In various scenarios, the processing requests received by the agent scheduler 10 come in various forms, including direct natural language questions, operational instructions, automatic monitoring data anomaly prompts, or approval process initiation signals. Regardless of the specific form, these processing requests serve as input, driving the distributed agent system to complete the corresponding processing and feedback.

[0054] Exemplarily, the running instance created by the agent scheduler 10 based on the received processing request is a pointer to a complete execution cycle of the processing request, including the entire process from request parsing, planning, execution to final result feedback.

[0055] The context information of a running instance refers to all dynamic data and environmental states related to processing a request. This information is used to track, manage, and recover the execution process of the running instance. Exemplarily, the running instance includes at least the state of the running instance. Initially, the running instance is in the execution state.

[0056] An event is a message unit transmitted within the system that carries execution instructions or data. It can be categorized as start events, intermediate events, and end events. A start event represents the first execution signal after a running instance is started. The start event is sent to the event queue 20 to trigger the agent executor 40 to begin executing a predefined execution process.

[0057] The event queue 20 is monitored by multiple agent executors 40 and supports the same event being received by only one agent executor 40. For example, multiple agent executors 40 (i.e., consumers) subscribe to the event queue 20 and monitor events in the event queue 20 by registering callback functions or event handlers. When a new event is generated, multiple agent executors 40 compete to consume the event, and only one agent executor 40 will receive the message, thus ensuring that the same event is not processed repeatedly.

[0058] The agent executor 40 is configured to, upon receiving a start event from the event queue 20, execute the predefined execution process indicated by the start event to obtain non-start events and send them to the event queue 20. Non-start events include intermediate events and end events that carry the execution results of the running instance. Intermediate events carry intermediate data or status during task execution, while end events carry the final execution results, indicating the end of the entire running instance.

[0059] The agent executor 40 is further configured to, if an intermediate event is monitored and obtained from the event queue 20 , run a predefined execution process indicated by the intermediate event to obtain a non-starting event and send it to the event queue 20 .

[0060] The agent executor 40 is further configured to change the execution state in the database 30 to the end state and store the execution result in the database 30 if an end event is monitored and obtained from the event queue 20 .

[0061] The agent scheduler 10 is further used to obtain and output the execution result from the database 30 if it is monitored from the database 30 that the running instance is in the end state.

[0062] In this system, the decoupling of the various execution phases of a running instance is achieved through the division of labor and collaboration among the agent scheduler 10, event queue 20, agent executor 40, and database 30. By binding event types to execution phases, the system can precisely control the lifecycle of a running instance and achieve process automation. Different event types (starting events, intermediate events, and ending events) can indicate different execution phases of a running instance. The execution phases are connected through event transmission rather than direct calls, achieving loose coupling. The event-driven design enables the running instance to be executed asynchronously in stages after creation. When the starting event corresponding to the running instance is triggered, the agent executor 40 responds and executes the corresponding predefined execution process. At the same time, the subsequent execution phases of the running instance are independently advanced based on the event triggering link. Therefore, the delay of the entire running instance processing is distributed among the various execution phases, which can reduce the overall response time. In addition, multiple agent executors 40 each independently listen for events from the event queue 20 and independently run the predefined execution process corresponding to the monitored events. In this way, the different execution phases of multiple running instances can be carried out in parallel, and the resources of different agent executors 40 are fully utilized, thereby significantly improving the overall system throughput.

[0063] The predefined execution process may be code pre-configured in the agent executor 40. The predefined execution process includes at least one execution step, which can be specifically configured based on the actual application scenario. For example, the execution step includes the step of calling a preset tool. The preset tool called in the predefined execution process can be specifically configured based on different application scenarios.

[0064] For example, see Figure 2 , preset tools include but are not limited to:

[0065] (1) Pre-trained language models, such as the Large Language Model (LLM) and BERT models, refer to artificial intelligence models based on deep learning technology, especially those trained using large corpora. They are designed to understand and generate text similar to human language and have strong natural language understanding and generation capabilities. The goal of pre-trained language models is to use natural language processing capabilities to enable a variety of applications, such as task planning, text generation, translation, summarization, question answering, and dialogue systems, thereby helping to improve the efficiency and automation of human-computer interaction.

[0066] (2) Knowledge base: A specially constructed knowledge base can be called to obtain the required information to assist in task planning and decision-making.

[0067] (3) Computer vision processing tools can be called to analyze visual data, such as image recognition, video analysis, etc.

[0068] (4) API calling tools for external services, such as weather query, language translation, financial data, news aggregation, or social media information, can be integrated to obtain external data in real time.

[0069] (5) Data preprocessing tools can be called to perform text data normalization, denoising, format conversion, etc.

[0070] (6) Mathematical operation and statistical analysis tools, which can be called to perform numerical calculations and statistical analysis, and support the precise numerical calculations or data analysis required in the task.

[0071] (7) Speech processing tools, which can be used for speech recognition, speech analysis, speech synthesis, etc.

[0072] Within the predefined execution process, the configuration of pre-set tools is highly flexible. The specific tools selected can be determined based on the actual application scenario and data characteristics, thereby providing the most appropriate technical support for the system and improving the processing capabilities and application effects of the entire distributed intelligent agent system.

[0073] In one possible implementation, the distributed agent system includes multiple agent executors 40 deployed in different computing devices, each of which has the same computing resources (such as processors, memory, storage, etc.), ensuring that the performance and responsiveness of each agent executor 40 are balanced and consistent, thereby achieving load balancing. Each agent executor 40 can contain a predefined execution process indicated by events of all event types, that is, each agent executor 40 has the ability to handle all event types, whether it is a starting event, an intermediate event or an ending event, each agent executor 40 contains corresponding predefined code logic, and can execute the corresponding predefined code logic according to the received event type. Since the computing resources of all computing devices are consistent, when an event is published to the event queue 20, each agent executor 40 has the same opportunity to obtain and process the event. This competition mechanism enables the load to be evenly distributed among all executors, thereby maintaining the system's response speed and processing efficiency in high concurrency situations.

[0074] In another possible implementation, the distributed agent system includes multiple agent executors 40 deployed on different computing devices. These different computing devices have different computing resources, such as the number of processor cores, memory size, storage performance, and even the number of dedicated accelerators. For example, some devices have higher performance and are suitable for running computationally intensive tasks, while lower performance devices are suitable for processing tasks with lower resource requirements. In this case, each agent executor 40 can be configured with a predefined execution process indicated by an event of a specified event type based on the hardware capabilities of the computing device to which it belongs. For example, high-performance devices can be configured with a predefined execution process for start events and predefined execution processes for intermediate events, while low-performance devices can be configured with a predefined execution process for end events (i.e., changing state and storing execution results in the database 30). When an event is published to the event queue 20, each agent executor 40 listens for and obtains events appropriate to it. For example, agent executors 40 deployed on high-performance devices listen for and obtain start events and intermediate events, while agent executors 40 deployed on low-performance devices listen for and obtain end events. By configuring specialized predefined execution processes based on the computing device's resources, each device can focus on its most suitable execution process, thereby avoiding wasting high-performance resources on simple tasks and preventing low-performance devices from processing overly complex tasks.

[0075] In an exemplary embodiment, an intelligent assistant / intelligent assistant scenario is used for exemplary description:

[0076] Each event carries at least one of the following information: ① The session identifier of the session to which the processing request belongs; the session identifier uniquely identifies the session to which the processing request belongs, i.e., records and tags the continuous conversation messages between the user and the intelligent assistant. Using the session identifier, the agent executor 40 can associate received events with the corresponding session, ensuring that each execution phase indicated by the event references the conversation messages in that session. This facilitates personalized processing and contextually coherent responses tailored to the specific user's interaction history. ② The identifier of the running instance created based on the processing request; using the running instance identifier, the agent executor 40 can associate events with a specific running instance, enabling the agent scheduler 10 and each agent executor 40 to consistently track task progress, status updates, and storage of final results throughout the lifecycle of the running instance. This facilitates the management of multiple concurrent running instances and ensures data isolation and independent processing between different running instances. ③ The event type and execution data associated with the event type. The event type enables the agent executor 40 to determine which predefined execution process the current event triggers and execute the corresponding task steps. The execution data related to the event type includes specific data or parameters related to the current event operation, such as task input parameters, context information of the calling tool, intermediate data of task planning, execution result data, etc., but is not limited to these; it can provide the intelligent agent executor 40 with the information basis required to execute the predefined execution process.

[0077] Exemplarily, the starting event includes a task planning event; the intermediate events include a task planning event and a task execution event.

[0078] The intelligent agent scheduler 10 creates a running instance based on the received processing request and stores the context information of the running instance in the database 30. The context information includes at least the execution status of the running instance, the number of tasks to be executed, and the dialogue messages in the session to which the processing request belongs; the number of tasks to be executed is used to record the number of unfinished tasks in the running instance; the initial value of the number of tasks to be executed is 0; then, the intelligent agent scheduler 10 sends the task planning event indicated by the running instance to the event queue 20.

[0079] The event queue 20 is monitored by multiple agent executors 40 and supports the same event to be obtained by only one agent executor 40.

[0080] If the agent executor 40 monitors and obtains a task planning event from the event queue 20 , it executes the predefined execution process indicated by the task planning event.

[0081] Among them, the predefined execution process indicated by the task planning event includes: if a task planning event is monitored and obtained from the event queue 20, check whether the number of tasks to be executed corresponding to the running instance recorded in the database 30 is 0. The number of tasks to be executed corresponding to the running instance recorded in the database 30 can ensure that new task planning will not be repeatedly started at the same time. Only when all tasks in the previous round have been completed, it is allowed to enter the next round of task planning.

[0082] The predefined execution process indicated by the task planning event also includes: if the number of tasks to be executed is not 0, wait for all unfinished tasks related to the running instance to be completed; if the number of tasks to be executed is 0, it means that the next step of planning can be carried out, then the dialogue message in the session to which the processing request belongs can be obtained from the database 30, and then based on the dialogue message in the session to which the processing request belongs, the pre-trained language model is called to perform task planning; according to the return result, two situations are handled: in the first situation, if the return result of the pre-trained language model includes at least one task, it means that the running instance has not been completed, a task execution event is generated for each task, and the number of tasks to be executed recorded in the database 30 is updated based on the number of tasks planned by the pre-trained language model, that is, the updated number of tasks to be executed is equal to the number of tasks planned by the pre-trained language model. In the second situation, if the return result of the pre-trained language model is empty, it means that the pre-trained language model believes that all tasks have been completed, and an end event carrying the execution result of the running instance is generated.

[0083] After executing the predefined execution process indicated by the task planning event, the agent executor 40 sends the obtained task execution event or end event to the event queue 20.

[0084] If the agent executor 40 listens for and receives a task execution event from the event queue 20, it executes the predefined execution process indicated by the task execution event. This predefined execution process includes executing the task indicated by the task execution event. For example, the reply message generated during task execution can be added to the context information recorded in the database 30. After the task is completed, a task planning event is generated. The number of pending tasks recorded in the database 30 is decremented by one to reflect the completion of the task. The predefined execution process indicated by the task execution event finally generates a task planning event, thus entering the next round of task planning, forming a "plan-execute-replan" cycle.

[0085] After executing the predefined execution process indicated by the task execution event, the agent executor 40 sends the obtained task planning event to the event queue 20.

[0086] If the intelligent agent executor 40 listens to and obtains the end event from the event queue 20, it changes the execution state in the database 30 to the end state and stores the execution result in the database 30; wherein, the end event includes execution data related to the event type, such as the execution result of the running instance, and in the intelligent assistant / intelligent assistant scenario, the execution result of the running instance includes a reply message.

[0087] The agent scheduler 10 is also used to obtain the execution result from the database 30 and output it if it monitors from the database 30 that the running instance is in the end state. For example, the reply message can be output and displayed in the interface.

[0088] Those skilled in the art will appreciate that the aforementioned "plan-execute" approach is not limited to intelligent assistants; its basic framework is also applicable to other application scenarios. Customized applications can be implemented by simply adjusting the contextual information within the running instance based on the specific scenario. For example, scenarios such as smart homes, intelligent customer service, and enterprise automation can flexibly automate the processing of various types of data by adjusting the relevant context of the running instance and the execution data contained in each event.

[0089] In another exemplary embodiment, a smart home scenario is used for exemplary description:

[0090] Among them, any event carries at least one of the following information: ① The type of processing request. ② The identifier of the running instance created based on the processing request; used to distinguish the entire processing process of each control operation of the user. For example, if the user says "adjust the temperature of the living room to 22 degrees", this operation will generate a running instance, and the system will associate subsequent status updates and feedback during the processing. ③ Event type and execution data related to the event type. The event type enables the intelligent agent executor 40 to determine which predefined execution process needs to be triggered by the current event, so as to execute the corresponding task steps. The execution data related to the event type contains specific data or parameters related to the current event operation, which can provide the intelligent agent executor 40 with the information basis required to execute the predefined execution process.

[0091] Assume that the user's processing request is to "enable away mode." The distributed intelligent agent system will trigger a series of automated tasks, such as turning off lights, adjusting temperature, activating security systems, locking doors, etc.

[0092] The agent scheduler 10 creates a running instance based on the received processing request and stores the running instance's context information in the database 30. This context information includes at least: a running instance identifier, used to track the lifecycle of this device control operation; the initial state (e.g., whether the running instance is in the "executing" state); the user request type "away mode"; and the number of unfinished intermediate events. The agent scheduler 10 then sends the start event indicated by the running instance to the event queue 20.

[0093] The event queue 20 is monitored by multiple agent executors 40 and supports the same event to be obtained by only one agent executor 40.

[0094] After an agent executor 40 successfully receives a start event, it begins executing the predefined execution process indicated by the start event. For example, the predefined execution process includes: based on the user request type "Away Mode" and the preset mapping relationship between request types and tasks to be executed, it determines a task list, such as {a. Turn off all lights; b. Set the air conditioner to energy-saving mode; c. Activate the security camera; d. Lock the front door}. It then generates an intermediate event for each task in the task list, for a total of four intermediate events: a lighting control event, an air conditioner energy-saving adjustment event, a security system activation event, and a door lock control event. It also updates the "number of unexecuted intermediate events" recorded in database 30 to 4. After completing the predefined execution process indicated by the start event, the agent executor 40 sends the four intermediate events to the event queue 20.

[0095] When an agent executor 40 successfully obtains an intermediate event, it executes the predefined execution process indicated by the intermediate event.

[0096] The predefined execution process of the lighting control event indication includes: calling the intelligent lighting control module interface, sending the "turn off all lights" instruction, and after execution is completed, reducing the "number of unexecuted intermediate events" in the database 30 by 1. If the "number of unexecuted intermediate events" in the database 30 is 0, an end event is generated, otherwise no end event is generated.

[0097] The predefined execution process of the air conditioner energy-saving adjustment event indication includes: calling the smart air conditioner interface, switching to the energy-saving mode, and after execution is completed, reducing the "number of unexecuted intermediate events" in the database 30 by 1. If the "number of unexecuted intermediate events" in the database 30 is 0, an end event is generated, otherwise no end event is generated.

[0098] The predefined execution process of the security system activation event indication includes: calling the home security controller to enable the monitoring and alarm system; after the execution is completed, the "number of unexecuted intermediate events" in the database 30 is reduced by 1. If the "number of unexecuted intermediate events" in the database 30 is 0, an end event is generated, otherwise no end event is generated.

[0099] The predefined execution process indicated by the door lock control event includes: calling the door lock interface, issuing a door lock command, and after execution is completed, reducing the "number of unexecuted intermediate events" in the database 30 by 1. If the "number of unexecuted intermediate events" in the database 30 is 0, an end event is generated, otherwise no end event is generated.

[0100] That is to say, in the predefined execution process indicated by the intermediate event, after completing the task, it will try to determine whether it is the "last task". If so, an end event will be generated.

[0101] After a certain agent executor 40 completes the predefined execution process indicated by the intermediate event, if an end event is generated, the end event is sent to the event queue 20.

[0102] When an agent executor 40 listens to and obtains an end event from the event queue 20, it changes the execution state in the database 30 to the end state and stores the execution result in the database 30. For example, the execution result can be the integration of the result data of all intermediate events.

[0103] The agent scheduler 10 is also used to obtain the execution result from the database 30 and output it if it monitors from the database 30 that the running instance is in the end state. For example, the reply message can be output and displayed in the interface.

[0104] The various technical features in the above embodiments can be combined arbitrarily as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of the various technical features in the above embodiments also falls within the scope of disclosure of this specification.

[0105] In other embodiments, in addition to being event-driven, the agent scheduler 10 may also be responsible for scheduling. Figure 3 This embodiment also provides another distributed agent system, including an agent scheduler 10, a database 30 and multiple agent executors 40.

[0106] The agent scheduler 10 is configured to create a running instance according to the received processing request, store the context information of the running instance in the database 30, and send a start instruction of the running instance to one of the agent executors 40. The context information at least includes the running state of the running instance.

[0107] The agent executor 40 is used to execute the predefined execution process indicated by the start instruction if a start instruction is received to obtain non-start instructions and send them to the agent scheduler 10. The non-start instructions include intermediate instructions and end instructions carrying the execution results of the running instance.

[0108] The agent scheduler 10 is further configured to send the received non-initial instructions to the agent executor 40. For example, the agent scheduler 10 may send the received non-initial instructions to the agent executor 40 using a random distribution strategy or a load balancing strategy.

[0109] The intelligent agent executor 40 is also used to run the predefined execution process indicated by the intermediate instruction if an intermediate instruction is received, so as to obtain a non-starting instruction and send it to the intelligent agent scheduler 10; if an end instruction is received, the execution status in the database 30 is changed to the end status, and the execution result is stored in the database 30.

[0110] The agent scheduler 10 is further used to obtain and output the execution result from the database 30 if it is monitored from the database 30 that the running instance is in the end state.

[0111] This system achieves effective decoupling and efficient coordination of the task initiation, execution, and result feedback phases through the collaborative work of an agent scheduler and multiple agent executors. This results in the following beneficial effects: First, upon receiving a processing request, the agent scheduler creates a run instance and stores its contextual information in a database. This step provides baseline data and status records for the entire task execution process, ensuring that the information of each run instance is fully preserved and traceable. Next, the scheduler sends a start instruction to one of the agent executors, initiating the task planning process. During the execution phase, upon receiving the start instruction, the agent executor executes the predefined execution flow indicated by the start instruction, generating non-start instructions (including intermediate and end instructions). Each agent executor independently processes its received instructions, thereby achieving parallel processing and load balancing. Multiple agent executors utilize distributed parallel processing, with each agent executor independently completing its assigned task based on its received instructions. This eliminates the dependency of the overall task on the sequential execution of a single node and reduces single-point load. All non-start instructions generated during this process are returned to the agent scheduler, which then forwards them to the next agent executor for processing. This process forms a closed loop of "start-middle-end", and realizes the automated advancement of the entire task process through continuous command transmission and feedback between the intelligent agent scheduler and the executor.

[0112] In other words, the intelligent agent scheduler acts as the "brain" to complete global management and instruction distribution, while multiple intelligent agent executors act as "executors" and are distributed on different computing nodes to perform their respective tasks. The close coordination between the two enables the system to run efficiently in a distributed environment, achieving task decoupling and process automation.

[0113] Exemplarily, the initial instructions include task planning instructions; the intermediate instructions include task planning instructions and task execution instructions.

[0114] The predefined execution process indicated by the task planning instruction includes: calling the pre-trained language model for task planning, if the return result of the pre-trained language model includes at least one task, generating a task execution instruction for each task, if the return result of the pre-trained language model is empty, generating an end instruction.

[0115] The predefined execution process indicated by the task execution instruction includes: executing the task indicated by the task execution instruction, and generating a task planning instruction after the execution is completed.

[0116] Exemplarily, the context information also includes the number of tasks to be executed, which is used to record the number of unfinished tasks in the running instance; the initial value of the number of tasks to be executed is 0; the predefined execution process indicated by the task planning instruction also includes: if the task planning instruction is listened to and obtained from the instruction queue, check whether the number of tasks to be executed recorded in the database 30 is 0; if the number of tasks to be executed is not 0, wait for all unfinished tasks related to the running instance to be completed; if the number of tasks to be executed is 0, call the pre-trained language model for task planning.

[0117] Exemplarily, the predefined execution process indicated by the task planning instruction further includes: if the return result of the pretrained language model includes at least one task, updating the number of pending tasks recorded in database 30 based on the number of tasks planned by the pretrained language model. The predefined execution process indicated by the task execution instruction further includes: after the execution of any task indicated by the task execution instruction is completed, reducing the number of pending tasks recorded in database 30 by one.

[0118] Exemplarily, the context information also includes conversation messages in the session to which the processing request belongs;

[0119] The predefined execution process indicated by the task planning instruction also includes: calling the pre-trained language model to perform task planning based on the dialogue message in the session to which the processing request belongs obtained from the database 30; wherein the execution result of the running instance includes a reply message.

[0120] Exemplarily, any instruction carries at least one of the following information: a session identifier of the session to which the processing request belongs, an identifier of the running instance, an instruction type, and execution data related to the instruction type.

[0121] Exemplarily, the predefined execution process includes at least one execution step, wherein the execution step includes the step of calling a preset tool. The preset tool includes, but is not limited to, a pretrained language model. For further information, please refer to the above description of the preset tool.

[0122] The various technical features in the above embodiments can be combined arbitrarily as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of the various technical features in the above embodiments also falls within the scope of disclosure of this specification.

[0123] In some embodiments, see Figure 4 The embodiment of this specification also provides a request processing method, which is applied to Figure 1 An agent scheduler in a distributed agent system; the method includes:

[0124] In S401 , a running instance is created according to the received processing request.

[0125] In S402, the context information of the running instance is stored in the database of the distributed agent system, and the start event indicated by the running instance is sent to the event queue of the distributed agent system; the context information at least includes that the running instance is in an execution state.

[0126] In S403, if it is monitored from the database that the running instance is in the end state, the execution result of the running instance is obtained from the database and output.

[0127] The implementation process of each step in the above method is detailed in the relevant description of the intelligent agent scheduler in the above system, which will not be repeated here.

[0128] In some embodiments, see Figure 5 The embodiment of this specification also provides a request processing method, which is applied to Figure 1 An agent actuator in a distributed agent system; the method includes:

[0129] In S501, if the start event of any running instance is monitored from the event queue in the distributed intelligent system, the predefined execution process indicated by the start event is executed to generate a non-starting event and send it to the event queue. The non-starting event includes an intermediate event and an end event carrying the execution result of the running instance.

[0130] In S502 , if an intermediate event of any running instance is monitored from the event queue, the predefined execution process indicated by the intermediate event is run to generate a non-starting event and send it to the event queue.

[0131] In S503, if an end event of any running instance is monitored from the event queue, the execution state of the running instance in the database of the distributed agent system is changed to the end state, and the execution result is stored in the database.

[0132] Exemplarily, the starting event includes a task planning event; the intermediate events include a task planning event and a task execution event; the predefined execution process indicated by the task planning event includes: calling a pre-trained language model for task planning, if the return result of the pre-trained language model includes at least one task, generating a task execution event for each task, if the return result of the pre-trained language model is empty, generating an end event; the predefined execution process indicated by the task execution event includes: executing the task indicated by the task execution event, and generating a task planning event after the execution is completed.

[0133] Exemplarily, the context information also includes the number of tasks to be executed, which is used to record the number of tasks that have not been completed in the running instance; the initial value of the number of tasks to be executed is 0;

[0134] The predefined execution process indicated by the task planning event also includes: if a task planning event is monitored and obtained from the event queue, check whether the number of tasks to be executed recorded in the database is 0; if the number of tasks to be executed is not 0, wait for all unfinished tasks related to the running instance to be completed; if the number of tasks to be executed is 0, call the pre-trained language model for task planning.

[0135] Exemplarily, the predefined execution process indicated by the task planning event also includes: if the return result of the pre-trained language model includes at least one task, updating the number of tasks to be executed recorded in the database based on the number of tasks planned by the pre-trained language model; the predefined execution process indicated by the task execution event also includes: after the execution of any task indicated by the task execution event is completed, reducing the number of tasks to be executed recorded in the database by one.

[0136] The implementation process of each step in the above method is detailed in the relevant description of the intelligent agent actuator in the above system, which will not be repeated here.

[0137] In some embodiments, an embodiment of this specification further provides an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements any of the above methods by running the executable instructions.

[0138] Figure 6 This is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 6At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610. Of course, it may also include hardware required for other functions. One or more embodiments of this specification can be implemented based on software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 610 into the memory 608 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0139] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0140] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0141] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

[0142] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A distributed agent system comprising an agent scheduler, an event queue, a database, and multiple agent executors; The agent scheduler is configured to create a running instance according to the received processing request, store context information of the running instance in the database, and send a start event indicated by the running instance to the event queue; The context information at least includes that the running instance is in an execution state; wherein the event queue is monitored by the multiple agent executors and supports the same event to be obtained by only one agent executor; The agent executor is configured to, if it listens to and obtains the start event from the event queue, execute the predefined execution process indicated by the start event to obtain a non-start event and send it to the event queue, wherein the non-start event includes an intermediate event and an end event carrying the execution result of the running instance; if it listens to and obtains the intermediate event from the event queue, execute the predefined execution process indicated by the intermediate event to obtain a non-start event and send it to the event queue; if it listens to and obtains the end event from the event queue, change the execution state in the database to an end state and store the execution result in the database; The agent scheduler is further configured to obtain and output the execution result from the database if it is detected from the database that the running instance is in an ending state.

2. The system according to claim 1, wherein the starting event comprises a task planning event; the intermediate events comprise a task planning event and a task execution event; The predefined execution process indicated by the task planning event includes: calling a pre-trained language model to perform task planning; if the return result of the pre-trained language model includes at least one task, generating a task execution event for each of the tasks; if the return result of the pre-trained language model is empty, generating the end event; The predefined execution process indicated by the task execution event includes: executing the task indicated by the task execution event, and generating a task planning event after the execution is completed.

3. The system according to claim 2, wherein the context information further includes a number of tasks to be executed, wherein the number of tasks to be executed is used to record the number of tasks that have not been completed in the running instance; an initial value of the number of tasks to be executed is 0; The predefined execution process indicated by the mission planning event also includes: If the task planning event is monitored and obtained from the event queue, checking whether the number of tasks to be executed recorded in the database is 0; If the number of tasks to be executed is not 0, wait for all unfinished tasks related to the running instance to be completed; if the number of tasks to be executed is 0, call the pre-trained language model for task planning.

4. The system according to claim 3, wherein the predefined execution process indicated by the mission planning event further comprises: If the return result of the pre-trained language model includes at least one task, updating the number of tasks to be executed recorded in the database based on the number of tasks planned by the pre-trained language model; The predefined execution process indicated by the task execution event further includes: after the execution of any task indicated by the task execution event is completed, reducing the number of tasks to be executed recorded in the database by one.

5. The system according to claim 2, wherein the context information further includes a dialog message in a session to which the processing request belongs; The predefined execution process indicated by the mission planning event also includes: Based on the conversation message in the session to which the processing request belongs, obtained from the database, calling a pre-trained language model to perform task planning; The execution result of the running instance includes a reply message.

6. The system according to claim 5, wherein any event carries at least one of the following information: a session identifier of the session to which the processing request belongs, an identifier of the running instance, an event type, and execution data related to the event type.

7. The system according to claim 1, wherein the predefined execution process includes at least one execution step; The execution step includes the step of calling a preset tool; the preset tool at least includes a pre-trained language model.

8. A distributed agent system comprising an agent scheduler, a database, and a plurality of agent executors; The agent scheduler is configured to create a running instance according to the received processing request, store context information of the running instance in the database, and send a start instruction indicated by the running instance to one of the agent executors; the context information at least includes whether the running instance is in an execution state; The agent executor is configured to, upon receiving the start instruction, execute the predefined execution process indicated by the start instruction to obtain non-start instructions and send them to the agent scheduler, wherein the non-start instructions include intermediate instructions and end instructions carrying the execution results of the running instance; The agent scheduler is further configured to send the received non-starting instruction to the agent executor; The agent executor is further configured to, upon receiving the intermediate instruction, run the predefined execution process indicated by the intermediate instruction to obtain a non-start instruction and send it to the agent scheduler; and, upon receiving the end instruction, change the execution state in the database to an end state and store the execution result in the database; The agent scheduler is further configured to obtain and output the execution result from the database if it is detected from the database that the running instance is in an ending state.

9. A request processing method, applied to an agent scheduler in a distributed agent system according to any one of claims 1 to 7; the method comprising: Create a running instance based on the received processing request; Storing context information of the running instance in a database in the distributed agent system, and sending a start event indicated by the running instance to an event queue in the distributed agent system; the context information at least includes that the running instance is in an execution state; If it is monitored from the database that the running instance is in the end state, the execution result of the running instance is obtained from the database and outputted.

10. A request processing method, applied to an agent executor in a distributed agent system according to any one of claims 1 to 7; the method comprising: If a start event of any running instance is monitored from the event queue in the distributed agent system, a predefined execution process indicated by the start event is executed to generate non-starting events and send them to the event queue. The non-starting events include intermediate events and end events carrying the execution results of the running instance; If an intermediate event of any running instance is monitored from the event queue, the predefined execution process indicated by the intermediate event is run to generate a non-starting event and send it to the event queue; If an end event of any running instance is monitored from the event queue, the execution state of the running instance in the database of the distributed agent system is changed to an end state, and the execution result is stored in the database.

11. The method according to claim 10, wherein the starting event comprises a mission planning event; and the intermediate events comprise a mission planning event and a mission execution event; The predefined execution process indicated by the task planning event includes: calling a pre-trained language model to perform task planning; if the return result of the pre-trained language model includes at least one task, generating a task execution event for each of the tasks; if the return result of the pre-trained language model is empty, generating the end event; The predefined execution process indicated by the task execution event includes: executing the task indicated by the task execution event, and generating a task planning event after the execution is completed.

12. The method according to claim 11, wherein the context information further includes a number of tasks to be executed, wherein the number of tasks to be executed is used to record the number of tasks that have not been completed in the running instance; an initial value of the number of tasks to be executed is 0; The predefined execution process indicated by the mission planning event also includes: If the task planning event is monitored and obtained from the event queue, checking whether the number of tasks to be executed recorded in the database is 0; If the number of tasks to be executed is not 0, wait for all unfinished tasks related to the running instance to be completed; if the number of tasks to be executed is 0, call the pre-trained language model for task planning.

13. The method according to claim 12, wherein the predefined execution process indicated by the mission planning event further comprises: If the return result of the pre-trained language model includes at least one task, updating the number of tasks to be executed recorded in the database based on the number of tasks planned by the pre-trained language model; The predefined execution process indicated by the task execution event further includes: after the execution of any task indicated by the task execution event is completed, reducing the number of tasks to be executed recorded in the database by one.

14. An electronic device comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method according to any one of claims 9 to 13 by running the executable instructions.

15. A computer-readable storage medium having computer instructions stored thereon, wherein when the instructions are executed by a processor, the steps of the method according to any one of claims 9 to 13 are implemented.

16. A computer program product comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 9 to 13.

Images