Task processing method and device based on multiple agents, equipment and storage medium

By parsing long-wheel tasks into multiple task nodes, dynamically calling intelligent agents and converting them into business-level execution states, the problems of fine-grained task progress feedback and data security in multi-agent collaborative execution are solved, achieving efficient, stable task progress display and secure synchronization.

CN121722508APending Publication Date: 2026-03-24BEIJING BAIDU NETCOM SCI & TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-16
Publication Date
2026-03-24

AI Technical Summary

Technical Problem

In long-running tasks, how to efficiently provide users with feedback on task execution progress, especially in the process of multi-agent collaborative execution, is a challenge that existing technologies struggle to achieve in-depth progress display and data security protection.

Method used

By parsing task processing requirements into multiple task nodes, dynamically calling intelligent agents to execute raw instructions, generating execution events, and converting them into user-understandable business-level execution states, the system uses the session protocol between the server and the user to feed back execution status messages, driving the user to dynamically render the user interface, thereby achieving refined display of task progress and data security protection.

Benefits of technology

It significantly improves the precision of task progress push, shields the underlying implementation differences of different intelligent agents, avoids front-end rendering crashes, simplifies the task progress synchronization process, and enhances data security and system stability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121722508A_ABST
    Figure CN121722508A_ABST
Patent Text Reader

Abstract

The invention provides a task processing method and device based on multiple agents, equipment and a storage medium, and relates to the technical field of artificial intelligence such as large models, agents and low codes. The method comprises the following steps: acquiring a task processing demand of a target task from a user side, and analyzing the task processing demand into a plurality of task nodes; the task node comprises a to-be-executed original instruction and a corresponding agent identifier; according to the agent identifier of the task node, dynamically calling a corresponding agent to execute the original instruction, and generating an execution event; the execution event is an intermediate state or a result of an instruction execution process; generating a user-oriented service-level execution state according to the original instruction and the execution event; and feeding back an execution state message to the user side based on the execution state so as to drive the user side to dynamically render a user interface.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, specifically to large-scale models, intelligent agents, and low-code artificial intelligence technologies. Specifically, it relates to a task processing method, apparatus, device, and storage medium based on multi-agent systems. Background Technology

[0002] As large-scale model technology iterates at an accelerated pace, the complexity of the tasks it processes continues to rise. To efficiently address this challenge, the Long-Polling Task model has emerged.

[0003] The system maintains a persistent connection with the server to achieve real-time synchronization of task status until the task is completed or a preset termination condition (such as timeout, error, etc.) is triggered before returning the result. For example, in a virtual code development scenario, a large model needs to collaborate with multiple agents to complete code generation.

[0004] However, how to provide users with feedback on the progress of long-running tasks has become a key issue. Summary of the Invention

[0005] This disclosure provides a multi-agent-based task processing method, apparatus, device, and storage medium.

[0006] According to one aspect of this disclosure, a multi-agent-based task processing method is provided, comprising:

[0007] The task processing requirements of the target task are obtained from the user terminal, and the task processing requirements are parsed into multiple task nodes; each task node includes the original instruction to be executed and the corresponding agent identifier.

[0008] Based on the agent identifier of the task node, the corresponding agent is dynamically invoked to execute the original instruction, generating an execution event; the execution event is an intermediate state or result of the instruction execution process.

[0009] Generate a user-oriented business-level execution state based on the original instructions and the execution events;

[0010] The execution status message is fed back to the user terminal based on the execution status, so as to drive the user terminal to dynamically render the user interface.

[0011] According to one aspect of this disclosure, a multi-agent-based task processing apparatus is provided, comprising:

[0012] The requirement parsing module is used to obtain the task processing requirements of the target task from the user terminal and parse the task processing requirements into multiple task nodes; the task node includes the original instruction to be executed and the corresponding intelligent agent identifier;

[0013] The agent invocation module is used to dynamically invoke the corresponding agent to execute the original instruction based on the agent identifier of the task node, and generate an execution event; the execution event is an intermediate state or result of the instruction execution process;

[0014] An execution status generation module is used to generate a user-oriented business-level execution status based on the original instructions and the execution events.

[0015] The message feedback module is used to send execution status messages to the user terminal based on the execution status, so as to drive the user terminal to dynamically render the user interface.

[0016] According to another aspect of this disclosure, an electronic device is provided, the electronic device comprising:

[0017] At least one processor; and

[0018] A memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods provided in any embodiment of this disclosure.

[0020] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods provided in any embodiment of this disclosure.

[0021] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods provided according to any embodiment of this disclosure.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0023] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0024] Figure 1 This is a flowchart of a multi-agent-based task processing method provided according to an embodiment of the present disclosure;

[0025] Figure 2 This is a flowchart of another multi-agent-based task processing method provided according to an embodiment of the present disclosure;

[0026] Figure 3aThis is a flowchart of yet another multi-agent-based task processing method provided according to an embodiment of the present disclosure;

[0027] Figure 3b This is a schematic diagram of a layered decoupling architecture provided according to an embodiment of this disclosure;

[0028] Figure 4 This is a schematic diagram of a multi-agent-based task processing device provided according to an embodiment of the present disclosure;

[0029] Figure 5 This is a block diagram of an electronic device used to implement a multi-agent-based task processing method according to an embodiment of the present disclosure. Detailed Implementation

[0030] Figure 1 This is a flowchart illustrating a multi-agent-based task processing method according to embodiments of this disclosure. The method is applicable to providing feedback to the user on the task execution progress during the collaborative execution of a long-running task by multiple agents. This method can be executed by a multi-agent-based task processing device, which can be implemented in software and / or hardware and integrated into a server-side electronic device. (Reference) Figure 1 A multi-agent-based task processing method in this embodiment may include:

[0031] S101, Obtain the task processing requirements of the target task from the user terminal, and parse the task processing requirements into multiple task nodes; the task node includes the original instruction to be executed and the corresponding agent identifier;

[0032] S102, based on the agent identifier of the task node, dynamically invoke the corresponding agent to execute the original instruction and generate an execution event; the execution event is an intermediate state or result of the instruction execution process;

[0033] S103, Generate a user-oriented business-level execution state based on the original instruction and the execution event;

[0034] S104, based on the execution status, an execution status message is fed back to the user terminal to drive the user terminal to dynamically render the user interface.

[0035] The server invokes multiple intelligent agents to collaboratively execute target tasks according to the user's task processing requirements. An intelligent agent, as a system or entity possessing environmental awareness and autonomous decision-making capabilities, can judge, select, and take actions based on its own goals and changes in the external environment to achieve a specific purpose. Intelligent agents can be trained using specific training samples on a Foundation LLM based on the Transformer architecture through supervised fine-tuning (SFT).

[0036] Taking the server-side of a virtual code development platform as an example, various intelligent agents can be pre-configured, including planning agents, development agents, and testing agents. The planning agent simulates a product manager role for requirements analysis, the development agent simulates a programmer role for code writing, and the testing agent simulates a tester role for automated testing. Each agent uses a different agent framework to handle heterogeneous instructions. Furthermore, each agent can efficiently interact with the server through a standardized API (Application Programming Interface).

[0037] During the execution of the target task, the server obtains the task processing requirements, presented in natural language or speech form, input by the user through the client-side front-end page. Based on the server's semantic parsing capabilities, the task processing requirements are parsed into multiple structured task nodes according to the intelligent agent framework. Each task node includes the original instruction (action) to be executed and the corresponding intelligent agent identifier (Agent-ID). The original instruction refers to the technical operation that needs to be processed by the underlying intelligent agent, that is, heterogeneous instructions from different intelligent agent frameworks, such as shell commands (such as git commit), file system operations, Docker signals, etc.

[0038] The server iterates through multiple task nodes to obtain the current task node. Based on the agent identifier of the node, it dynamically distributes the original instructions to be executed, enabling the corresponding agent to execute the original instructions. The intermediate states or results of the agents during the instruction execution are obtained as execution events, which can also be called observations.

[0039] To provide users with feedback on task execution progress, the raw instructions and execution events of the underlying intelligent agents are transformed into user-facing business-level execution states. This means converting them into user-understandable execution states based on business semantics, thereby masking the differences between heterogeneous intelligent agents. Execution states can also be referred to as business artifacts or business intentions. Specifically, a physical execution space and a logical interaction space can be defined. The physical execution space includes the process states of the underlying intelligent agents, while the logical interaction space includes the user-understandable business-level execution states.

[0040] For example, based on semantic understanding, heterogeneous raw instructions and the results of instruction execution are transformed into execution states. For instance, text processing commands such as grep, sed, and awk are uniformly identified and encapsulated into execution states such as file query or file modification. Furthermore, through a state machine, intermediate states during instruction execution are transformed into execution states with business semantics. For example, intermediate states of the agent's lifecycle are abstracted and mapped to general business states (e.g., RUNNING, AWAITING_USER_INPUT, STOPPED, DELEGATING are abstracted as executing, requiring user input, completed, and failed, respectively). Based on the server-user session protocol, execution states are encapsulated into execution state messages, which are fed back to the user. This drives the user to dynamically render and update the user interface (UI) based on the received execution state messages, allowing the user to stay informed about the task's progress. This approach decouples the user interface rendering logic from the agent, eliminating the need to synchronously modify the user interface rendering logic when the agent is updated.

[0041] During the execution of long-wheel tasks, an execution status is generated based on heterogeneous original instructions, intermediate states during instruction execution, and results. This execution status is then fed back to the user, driving dynamic rendering and updating of the user interface to provide a clear understanding of the task progress. Compared to only providing the final execution result after the long-wheel task is completed, this approach significantly improves the granularity of task progress updates. Furthermore, unlike directly pushing agent log data (such as JSON logs) to the user, which requires the front-end to handle complex content such as regular expressions and non-standard logic, this system effectively shields the underlying implementation differences between various agents by converting original instructions, intermediate states, and results into business-level execution statuses. This decouples the front-end rendering logic from the agents. Therefore, when the agent framework is upgraded or the definitions of instructions or execution events are changed, there is no need to synchronously modify the front-end rendering code, avoiding front-end rendering crashes caused by agent updates. In addition, agents contain complex intermediate states such as "waiting for input," "in execution," "paused by error," and "subtask delegation." If these intermediate states are directly passed to the front-end, the user interface will struggle to determine the appropriate rendering timing for each state. For example, it's unclear when to display the "Confirm" button and when to display the "Downloading" progress bar.

[0042] The technical solution provided in this disclosure parses task processing requirements into multiple task nodes, dynamically invokes intelligent agents to execute corresponding original instructions based on the intelligent agent identifier of each task node, and treats intermediate states or results of instruction execution as execution events. The original instructions and execution events are converted into execution states that the user can understand. Based on the session protocol between the server and the user, the execution states are encapsulated into execution status messages and fed back to the user, driving the user to dynamically render and update the user interface. This series of operations allows the user to understand the task progress in a timely manner during task execution, shields the underlying implementation differences between different intelligent agents, and decouples the user-side rendering logic from the intelligent agents.

[0043] In one optional implementation, the step of dynamically invoking the corresponding agent to execute the original instruction and generate an execution event based on the agent identifier of the task node includes: broadcasting the original instruction of the task node and the corresponding agent identifier to multiple agents, so that the agents perform the following operations: after matching their own identifier, determining whether the task node has been executed; if it has been executed, obtaining the historical execution status of the task node from the status database; continuing to execute the original instruction based on the historical execution status, and updating the execution event.

[0044] The server iterates through multiple task nodes to obtain the current task node and broadcasts the original instructions and agent identifier of the current task node to multiple agents. After receiving the broadcast information, each agent determines whether the agent identifier of the task matches its own identifier; if the identifiers match, it indicates that the task node needs to be executed by the agent itself, and the agent enters the execution process; otherwise, it abandons the current task node.

[0045] During the execution of the current task node, the agent can determine whether the current task node has already been executed. Specifically, the agent can determine whether the current task node is a new task that has not been received before or a historical task that has been received, based on the description information of the received task (e.g., task name, reception time, etc.). If it is a historical task, the agent retrieves the historical execution state of the current task node from the state database; based on the historical execution state, it continues to execute the original instructions, and during the new execution process, updates the execution event of the current task node according to the intermediate states and results. This approach allows for a more granular and accurate restoration of the overall system's task execution state when the task processing system needs to be restarted due to failures or other reasons, thereby not only improving the overall reliability of the system but also avoiding the loss of task progress due to failures or restarts. If it is a new task, the agent directly executes the current task.

[0046] Figure 2 This is a flowchart of another multi-agent-based task processing method provided according to embodiments of this disclosure. (See also...) Figure 2 A multi-agent-based task processing method in this embodiment may include:

[0047] S201, Obtain the task processing requirements of the target task from the user terminal, and parse the task processing requirements into multiple task nodes; the task node includes the original instruction to be executed and the corresponding agent identifier.

[0048] S202, based on the agent identifier of the task node, dynamically invoke the corresponding agent to execute the original instruction and generate an execution event; the execution event is an intermediate state or result of the instruction execution process;

[0049] S203, Detect whether multiple consecutive original instructions belong to the same instruction combination;

[0050] S204, if they belong to the same instruction combination, then the multiple original instructions are merged into an instruction combination, and the instruction combination and the corresponding execution event are converted into a user-oriented business-level execution state;

[0051] S205, based on the execution status, an execution status message is fed back to the user terminal to drive the user terminal to dynamically render the user interface.

[0052] During the execution state transition process—that is, when the agent's original instructions and execution events are semantically reconstructed to generate a business-level execution state—the original instructions can also be aggregated. For example, based on the order, context, and inter-instruction dependencies of multiple consecutive original instructions, it can be determined whether these instructions belong to the same instruction combination. If they do, the multiple original instructions are merged into an instruction combination. Correspondingly, the intermediate states and results of the instruction combination's execution process are obtained to obtain the corresponding execution events, and the instruction combination and corresponding execution events are semantically reconstructed into a business-level execution state. Taking a version control task node as an example, it can be determined that "git add" and "git commit" belong to the same instruction combination, and then they can be merged into the same instruction combination, reconstructing it into the business-level execution state of "version update".

[0053] By merging multiple consecutive raw instructions into a single instruction combination, the task progress synchronization process can be simplified, allowing users to understand the task execution progress more conveniently and intuitively without having to sort through numerous scattered raw instruction information. On the other hand, it can provide richer and more comprehensive information, allowing users not only to know which step the task has reached, but also to understand the overall logic and intent of the task from the perspective of the instruction combination.

[0054] In one optional implementation, generating a user-oriented business-level execution state based on the original instruction and the execution event includes: detecting whether the original instruction and the execution event contain sensitive information based on a preset sensitive information filter; if sensitive information is contained, performing desensitization processing on the original instruction and the execution event, and generating a user-oriented business-level execution state based on the desensitization result.

[0055] During the execution state transition process, not only is semantic reconstruction performed, but a pre-defined sensitive information filter is also activated. This filter identifies fields in the original instructions, intermediate states generated during instruction execution, and result information, accurately determining whether they include sensitive fields such as user passwords or tokens. Taking the processing of configuration files containing sensitive information as an example, a de-identification mechanism is initiated. A specific de-identification algorithm converts sensitive fields into a format that prevents direct access to the original information. By automatically de-identifying sensitive information, the leakage of sensitive information can be effectively prevented during task progress synchronization, avoiding potential risks caused by data security issues and significantly improving data security during task progress synchronization. It should be noted that this mechanism not only filters sensitive information but also treats intermediate states such as errors generated during task execution as process noise, reducing their weight and filtering them to minimize unnecessary task progress feedback and prevent intermediate errors from interfering with users. In a virtual code development scenario, when a test case fails, instead of frequent error reporting, the corresponding intelligent agent (such as CodingAgent) can be invoked to directly modify the code snippet of the test case and rerun it.

[0056] In one optional implementation, generating a user-oriented business-level execution state based on the original instruction and the execution event includes: if multiple adjacent execution events are all text content, then obtaining the agent identifier corresponding to each adjacent execution event; if the corresponding agent identifiers are the same, then processing each adjacent execution event into an aggregate event, and generating a user-oriented business-level execution state based on the aggregate event.

[0057] During task execution, agents may generate different types of streaming text content within the current time window. On one hand, a single agent may generate different streaming texts while continuously processing multiple raw instructions; on the other hand, multiple agents may also generate streaming texts while processing their respective raw instructions. Multiple adjacent execution events can be retrieved by timestamp. If multiple execution events are all text content, the agent identifier associated with each execution event can be further obtained, i.e., the agent identifier of the task node to which each execution event belongs.

[0058] If all text content originates from the same agent, adjacent execution events are processed into aggregated events, and a user-facing business-level execution status is generated based on these aggregated events. This approach simplifies the task progress synchronization process, allowing users to understand task execution progress more conveniently and intuitively. If the text content originates from different agents, there is no need to aggregate adjacent execution events.

[0059] In one optional implementation, the method further includes: if multiple adjacent execution events correspond to different instruction types, then generating user-oriented business-level execution states for each adjacent execution event.

[0060] In addition, if multiple adjacent execution events correspond to different instruction types, for example, the i-th (i is a positive integer) execution event corresponds to text content generation and the (i+1)-th execution event corresponds to database query operation, then the corresponding business-level execution status is generated for each adjacent execution event to distinguish and display the execution progress of different instruction types to the user.

[0061] The technical solution provided in this disclosure simplifies the task progress synchronization process by merging multiple consecutive original instructions into an instruction combination; it enhances data security by enabling a sensitive information filter to identify and de-identify sensitive fields in original instructions, intermediate states, and result information; simultaneously, when multiple adjacent execution events are text content and come from the same intelligent agent, they are processed into aggregated events to generate business-level states, simplifying progress synchronization; if adjacent execution events correspond to different instruction types, business-level states are generated for each, allowing users to distinguish and display the execution progress of different instruction types.

[0062] In one optional implementation, the step of feeding back execution status messages to the user based on the execution status includes: if multiple execution statuses belong to the same task topic, generating an aggregate status based on the multiple execution statuses and sending the corresponding aggregate status message to the user; in response to the user's query request for the aggregate status message, retrieving the associated multiple execution statuses from the status database and sending the corresponding multiple execution status messages to the user.

[0063] A task theme refers to the core topic surrounding a series of execution states with the same business objective or operational object. For example, determining whether multiple execution states belong to the same task theme: In a real-world scenario, when there are file query, read, and write operations, and these operations all revolve around changing a specific password, the system will categorize the execution states corresponding to these operations under the task theme of "password change".

[0064] If multiple execution statuses belong to the same task theme, they are aggregated into a single aggregate status. This aggregate status integrates key information from multiple execution statuses, providing a more comprehensive and concise reflection of the overall task progress. The aggregate status is then encapsulated into an aggregate status message and sent to the user. Upon receiving the aggregate status message, the user will view it intuitively, allowing them to quickly understand the overall task execution status.

[0065] When users need to delve deeper into the details of task execution, they can initiate a query request for the aggregated status message. In response to this query, the system retrieves multiple execution statuses associated with the aggregated status message from the status database, encapsulates them into corresponding execution status messages, and sends them to the user's client for display. This approach, on the one hand, generates aggregated statuses based on multiple execution statuses of the same task theme, allowing users to quickly and intuitively understand the overall task execution progress; on the other hand, it supports users querying fine-grained execution statuses, flexibly addressing diverse needs and enhancing the system's practicality and adaptability.

[0066] Figure 3a This is a flowchart of another multi-agent-based task processing method provided according to an embodiment of the present disclosure. One embodiment of the multi-agent-based task processing method may include:

[0067] S301, Obtain the task processing requirements of the target task from the user terminal, and parse the task processing requirements into multiple task nodes; the task node includes the original instruction to be executed and the corresponding agent identifier;

[0068] S302, based on the agent identifier of the task node, dynamically invoke the corresponding agent to execute the original instruction and generate an execution event; the execution event is an intermediate state or result of the instruction execution process;

[0069] S303, Generate a user-oriented business-level execution state based on the original instruction and the execution event;

[0070] S304, if the target task is associated with multiple bound user terminals, the execution status is encapsulated into an execution status message and broadcast to the multiple bound user terminals to drive each bound user terminal to dynamically render the user interface.

[0071] Combination Figure 3a and Figure 3b The server-side adopts a layered and decoupled architecture, including a protocol conversion layer and a state bridging layer. The protocol conversion layer has a built-in conversion engine used to realize the bidirectional conversion between the raw instructions and execution events of the underlying intelligent agents and the business-level execution states. The state bridging layer provides intelligent agent runtime management and state persistence services. Its core components include a runtime bridge hub and a state database, which can be a relational database to store execution states.

[0072] The server can traverse multiple task nodes to obtain the current task node. Based on the agent identifier of that node, it distributes the instructions to be executed to the corresponding agents, enabling the agents to execute the original instructions and generate execution events. The protocol conversion layer obtains the corresponding original instructions and execution events from the agents, uses the conversion engine to perform semantic reconstruction on the original instructions and execution events, generates a business-level execution state, and sends the execution state to the runtime bridging center of the state bridging layer. The runtime bridging center then feeds back the execution state to the user end.

[0073] If a target task is associated with multiple bound user clients, these clients can bind to the target task via a subscription mechanism (i.e., the task ID), or via shared session tokens, shared task links, etc., to achieve multi-user sharing of the target task's status. The runtime bridging center retrieves the multiple bound user clients associated with the target task, encapsulates the execution status into an execution status message, and broadcasts the execution status message to the multiple bound user clients. Upon receiving the execution status message, each user client dynamically renders and updates its own user interface. Through a multi-terminal synchronized status distribution mechanism, multiple bound user clients can synchronously view the execution status message, fulfilling the collaborative processing requirements of multiple users.

[0074] In one optional implementation, the method further includes: obtaining a state synchronization request sent by a user terminal through a state synchronization interface, extracting a target task identifier from the state synchronization request; obtaining the historical execution status of the target task from a state database based on the target task identifier, and sending a historical execution status message to the user terminal.

[0075] refer to Figure 3b The server can also provide a state synchronization interface to offer state management capabilities. Clients can actively retrieve state synchronization messages using this interface. When multiple clients are bound, if any client needs to refresh its task execution status due to network interruption or other reasons, it can initiate a state synchronization request. The server receives the request through the state synchronization interface and extracts the target task identifier from it. Based on the target task identifier, it retrieves the historical execution status of the target task from the state database and sends the historical execution status message to the client (i.e., the client that initiated the synchronization request). Through the collaboration between the state database and the state synchronization interface, using the state database as an intermediate cache and combining it with an asynchronous push mechanism for execution status messages, the system's real-time performance and reliability are greatly improved. Furthermore, it prevents the loss of execution status when the session connection is broken, ensuring system stability in multi-user concurrent scenarios.

[0076] In one optional implementation, after sending the historical execution status message to the user terminal, the method further includes: after the historical execution status message is sent, obtaining the new execution status of the target task from memory; deduplicating the new execution status according to the historical execution status; and sending the new execution status message of the target task to the user terminal according to the deduplicated new execution status.

[0077] After synchronizing historical execution status messages to the user client via the status synchronization interface, and once the historical status messages have been sent, the system switches to the real-time status push mode for the target task. In this mode, the runtime bridging center retrieves the new execution status of the target task from memory; the new execution status is deduplicated based on the historical execution status, and then encapsulated into a new execution status message before being sent to the user client. For example, if a user refreshes a page due to a network interruption, the status synchronization interface utilizes the previous execution status to supplement the user with the historical execution status messages missed during the 5 seconds of network interruption, while continuing to receive real-time new execution status messages. This process achieves seamless integration between historical and new execution statuses, further improving the consistency and accuracy of task execution progress synchronization.

[0078] The technical solution provided in this disclosure implements a multi-terminal synchronous status distribution mechanism when a target task is associated with multiple bound user terminals. Through this mechanism, multiple bound user terminals can synchronously view execution status messages, meeting the collaborative processing needs of multiple users. Simultaneously, by cooperating with a status database and a status synchronization interface, using the status database as an intermediate cache carrier, and combining it with an asynchronous push mechanism for execution status messages, the real-time performance and stability of task status processing are also improved.

[0079] In one optional implementation, the method further includes: if it is determined based on the execution status that user interaction is required, then sending an interaction reminder message to the user terminal; obtaining the interaction information input by the user terminal, and generating a new task node based on the interaction information to continue executing the task.

[0080] During task execution, the system determines whether user interaction is required based on the execution status of task nodes, i.e., whether user data is needed. If user interaction is required, an interaction notification message is sent to the user's device. For example, when the execution status displays "User input required," an interaction notification message is generated based on the metadata of the corresponding execution event, causing the user's device to render the corresponding interactive components, such as confirmation buttons or input boxes. Furthermore, the system acquires the user's interaction information input from the front end and generates a new task node based on this information to continue task execution. If no user interaction is required, the task continues directly. This approach ensures smooth task execution, avoids unnecessary interaction interference, and accurately and promptly acquires user input when needed, ensuring the task can continue.

[0081] In one optional implementation, the step of sending an interaction reminder message to the user terminal if user interaction is required based on the execution status includes: if user interaction is required based on the execution status and the target task is associated with multiple bound user terminals, then determining the interaction type; determining the associated role based on the mapping relationship between the interaction type and the virtual role; determining the associated user terminal corresponding to the associated role from the multiple bound user terminals, and sending the interaction reminder message to the associated user terminal.

[0082] When a target task is associated with multiple bound user terminals, each bound user terminal is associated with a virtual role. Taking the virtual code development scenario as an example, it can be associated with roles such as virtual product manager, virtual programmer, and virtual tester. Each virtual role can be associated with multiple interaction types, each interaction type can be associated with multiple intelligent agents, and each user terminal can be associated with at least one virtual role. In this case, if user interaction is required during task execution, the interaction type is first determined based on the corresponding execution status; based on the mapping relationship between interaction types and virtual roles, the corresponding associated role is determined; and the associated user terminal corresponding to the associated role is accurately located from among the multiple bound user terminals. Subsequently, an interaction reminder message is sent only to the associated user terminal, without sending interaction reminder messages to other user terminals, thus effectively avoiding interference with other user terminals. By locating associated user terminals based on the mapping relationship between interaction types and virtual roles, the decoupling of user terminal location from the underlying intelligent agent is achieved, further improving the flexibility of user interaction.

[0083] In one optional implementation, generating a new task node based on the interaction information to continue executing the task includes: obtaining the code snippet already generated for the target task; and calling the code snippet using the interaction information as an input parameter to generate a new task node.

[0084] Taking the virtual code development scenario as an example, after obtaining the user's input interaction information, the system further obtains the code snippets already generated for the target task. A new task node is generated by combining the interaction information and the code snippets. This new task node is used to call the corresponding code snippet using the interaction information as input parameters. By calling the generated code snippets to process the user's input interaction information, the flexibility of virtual code development is further improved.

[0085] Figure 4 This is a schematic diagram of a multi-agent-based task processing device according to an embodiment of this disclosure. This embodiment is applicable to providing feedback to the user on the task execution progress during the collaborative execution of a long-running task by multiple agents. The device can be implemented in software and / or hardware and can be integrated into a server-side electronic device. Figure 4 As shown, a multi-agent-based task processing device 400 of this embodiment may include:

[0086] The requirement parsing module 410 is used to obtain the task processing requirements of the target task from the user terminal and parse the task processing requirements into multiple task nodes; the task node includes the original instruction to be executed and the corresponding intelligent agent identifier.

[0087] The agent invocation module 420 is used to dynamically invoke the corresponding agent to execute the original instruction based on the agent identifier of the task node, and generate an execution event; the execution event is an intermediate state or result of the instruction execution process;

[0088] The execution status generation module 430 is used to generate a user-oriented business-level execution status based on the original instruction and the execution event.

[0089] The message feedback module 440 is used to feed back execution status messages to the user terminal based on the execution status, so as to drive the user terminal to dynamically render the user interface.

[0090] In one optional embodiment, the execution state generation module 430 includes an instruction combination unit, specifically used for:

[0091] Detect whether multiple consecutive original instructions belong to the same instruction combination;

[0092] If they belong to the same instruction combination, the multiple original instructions are merged into an instruction combination, and the instruction combination is converted into a user-oriented business-level execution state.

[0093] In one optional embodiment, the execution status generation module 430 includes a desensitization unit, specifically used for:

[0094] Based on a preset sensitive information filter, it is detected whether the original instruction and the execution event contain sensitive information;

[0095] If sensitive information is contained, the original instructions and execution events are de-identified, and a user-oriented business-level execution status is generated based on the de-identification results.

[0096] In one optional implementation, the execution status generation module 430 includes a text aggregation unit, specifically used for:

[0097] If multiple adjacent execution events are all text content, then obtain the agent identifier corresponding to each adjacent execution event;

[0098] If the corresponding agent identifiers are the same, then each adjacent execution event is processed into an aggregate event, and a user-oriented business-level execution state is generated based on the aggregate event.

[0099] In one alternative implementation, the text aggregation unit is further configured to:

[0100] If multiple adjacent execution events correspond to different instruction types, then user-oriented business-level execution states are generated for each adjacent execution event.

[0101] In one optional implementation, the message feedback module 440 includes:

[0102] The status aggregation unit is used to generate an aggregated status based on the multiple execution statuses if multiple execution statuses belong to the same task topic, and send the corresponding aggregated status message to the user terminal.

[0103] The status query unit is used to respond to the user's query request for the aggregated status message, retrieve multiple associated execution statuses from the status database, and send the corresponding multiple execution status messages to the user.

[0104] In one optional implementation, the agent invocation module 420 is specifically used for:

[0105] The original instructions of the task node and the corresponding agent identifier are broadcast to multiple agents, causing the agents to perform the following operations: after matching their own identifier, they determine whether the task node has been executed; if it has been executed, they retrieve the historical execution status of the task node from the state database; based on the historical execution status, they continue to execute the original instructions and update the execution event.

[0106] In one optional implementation, the message feedback module 440 is specifically used for:

[0107] If the target task is associated with multiple bound user terminals, the execution status is encapsulated as an execution status message and broadcast to the multiple bound user terminals to drive each bound user terminal to dynamically render the user interface.

[0108] In an optional implementation, the message feedback module 440 is further configured to:

[0109] The state synchronization interface is used to obtain the state synchronization request sent by the user terminal, and the target task identifier is extracted from the state synchronization request.

[0110] Based on the target task identifier, the historical execution status of the target task is obtained from the status database, and a historical execution status message is sent to the user terminal.

[0111] In an optional implementation, the message feedback module 440 is further configured to:

[0112] After the historical execution status message is sent, the new execution status of the target task is retrieved from memory;

[0113] The new execution status is deduplicated based on the historical execution status, and a new execution status message for the target task is sent to the user terminal based on the deduplicated new execution status.

[0114] In one optional embodiment, the device 400 further includes a user interaction module, the user interaction module comprising:

[0115] An interactive reminder unit is used to send an interactive reminder message to the user terminal if it is determined based on the execution status that user interaction is required.

[0116] The new task unit is used to obtain the interaction information input by the user terminal and generate a new task node based on the interaction information to continue executing the task.

[0117] In one optional implementation, the interactive reminder unit is specifically used for:

[0118] If the execution status indicates that user interaction is required, and the target task is associated with multiple bound user terminals, then the interaction type is determined.

[0119] Based on the mapping relationship between the interaction type and the virtual character, the associated character is determined;

[0120] The associated user terminal corresponding to the associated role is determined from the plurality of bound user terminals, and the interactive reminder message is sent to the associated user terminal.

[0121] In one alternative implementation, the new task unit is specifically used for:

[0122] Obtain the code snippet already generated for the target task;

[0123] The code snippet is invoked using the interaction information as input parameters to generate a new task node.

[0124] The multi-agent-based task processing device provided in this disclosure can execute the multi-agent-based task processing method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the multi-agent-based task processing method.

[0125] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0126] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0127] Figure 5 This is a block diagram of an electronic device used to implement a multi-agent-based task processing method according to an embodiment of the present disclosure.

[0128] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0129] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0130] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0131] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as multi-agent-based task processing methods. For example, in some embodiments, the multi-agent-based task processing method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the multi-agent-based task processing method described above can be performed. Alternatively, in other embodiments, computing unit 501 may be configured to perform a multi-agent-based task processing method by any other suitable means (e.g., by means of firmware).

[0132] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0133] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0134] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0135] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0136] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0137] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0138] Artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies mainly include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0139] Cloud computing refers to a technology system that enables access to a shared pool of physical or virtual resources via a network. These resources can include servers, operating systems, networks, software, applications, and storage devices, and can be deployed and managed on demand and in a self-service manner. Cloud computing technology can provide efficient and powerful data processing capabilities for applications such as artificial intelligence and blockchain, as well as for model training.

[0140] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0141] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A multi-agent-based task processing method, comprising: Obtain the task processing requirements of the target task from the user's end, and parse the task processing requirements into multiple task nodes; The task node includes the original instruction to be executed and the corresponding agent identifier; Based on the agent identifier of the task node, the corresponding agent is dynamically invoked to execute the original instruction, generating an execution event; the execution event is an intermediate state or result of the instruction execution process. Generate a user-oriented business-level execution state based on the original instructions and the execution events; The execution status message is fed back to the user terminal based on the execution status, so as to drive the user terminal to dynamically render the user interface.

2. The method according to claim 1, wherein, The step of generating a user-oriented business-level execution state based on the original instruction and the execution event includes: Detect whether multiple consecutive original instructions belong to the same instruction combination; If they belong to the same instruction combination, the multiple original instructions are merged into an instruction combination, and the instruction combination is converted into a user-oriented business-level execution state.

3. The method according to claim 1, wherein, The step of generating a user-oriented business-level execution state based on the original instruction and the execution event includes: Based on a preset sensitive information filter, it is detected whether the original instruction and the execution event contain sensitive information; If sensitive information is contained, the original instructions and execution events are desensitized, and a user-oriented business-level execution status is generated based on the desensitization results.

4. The method according to claim 1, wherein, The step of generating a user-oriented business-level execution state based on the original instruction and the execution event includes: If multiple adjacent execution events are all text content, then obtain the agent identifier corresponding to each adjacent execution event; If the corresponding agent identifiers are the same, then each adjacent execution event is processed into an aggregate event, and a user-oriented business-level execution state is generated based on the aggregate event.

5. The method according to claim 4, further comprising: If multiple adjacent execution events correspond to different instruction types, then user-oriented business-level execution states are generated for each adjacent execution event.

6. The method according to claim 1, wherein, The step of feeding back the execution status message to the user based on the execution status includes: If multiple execution states belong to the same task topic, an aggregated state is generated based on the multiple execution states, and the corresponding aggregated state message is sent to the user terminal. In response to the user's query request for the aggregated status message, multiple associated execution statuses are retrieved from the status database, and the corresponding multiple execution status messages are sent to the user.

7. The method according to claim 1, wherein, The step of dynamically invoking the corresponding agent to execute the original instruction and generating an execution event based on the agent identifier of the task node includes: The original instructions of the task node and the corresponding agent identifier are broadcast to multiple agents, causing the agents to perform the following operations: after matching their own identifier, they determine whether the task node has been executed; if it has been executed, they retrieve the historical execution status of the task node from the state database; based on the historical execution status, they continue to execute the original instructions and update the execution event.

8. The method according to claim 1, wherein, The step of feeding back an execution status message to the user terminal based on the execution status to drive the user terminal to dynamically render the user interface includes: If the target task is associated with multiple bound user terminals, the execution status is encapsulated as an execution status message and broadcast to the multiple bound user terminals to drive each bound user terminal to dynamically render the user interface.

9. The method according to claim 8, further comprising: The state synchronization interface is used to obtain the state synchronization request sent by the user terminal, and the target task identifier is extracted from the state synchronization request. Based on the target task identifier, the historical execution status of the target task is obtained from the status database, and a historical execution status message is sent to the user terminal.

10. The method according to claim 9, further comprising, after sending the historical execution status message to the user terminal: After the historical execution status message is sent, the new execution status of the target task is retrieved from memory; The new execution status is deduplicated based on the historical execution status, and a new execution status message for the target task is sent to the user terminal based on the deduplicated new execution status.

11. The method according to claim 1, further comprising: If the execution status indicates that user interaction is required, an interaction reminder message is sent to the user's device. The system obtains the interaction information input by the user and generates a new task node based on the interaction information to continue executing the task.

12. The method according to claim 11, wherein, If the execution status indicates that user interaction is required, then sending an interaction reminder message to the user terminal includes: If the execution status indicates that user interaction is required, and the target task is associated with multiple bound user terminals, then the interaction type is determined. Based on the mapping relationship between the interaction type and the virtual character, the associated character is determined; The associated user terminal corresponding to the associated role is determined from the plurality of bound user terminals, and the interactive reminder message is sent to the associated user terminal.

13. The method according to claim 11, wherein, The step of generating a new task node based on the interaction information to continue task execution includes: Obtain the code snippet already generated for the target task; The code snippet is invoked using the interaction information as input parameters to generate a new task node.

14. A multi-agent-based task processing device, comprising: The requirement parsing module is used to obtain the task processing requirements of the target task from the user terminal and parse the task processing requirements into multiple task nodes; The task node includes the original instruction to be executed and the corresponding agent identifier; The agent invocation module is used to dynamically invoke the corresponding agent to execute the original instruction based on the agent identifier of the task node, and generate an execution event; the execution event is an intermediate state or result of the instruction execution process; An execution status generation module is used to generate a user-oriented business-level execution status based on the original instructions and the execution events. The message feedback module is used to send execution status messages to the user terminal based on the execution status, so as to drive the user terminal to dynamically render the user interface.

15. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-13.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-13.

17. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-13.