Scheduling method and device of agent system and electronic equipment

Abstract

The disclosure provides a scheduling method of an agent system, and relates to the technical field of computers, and particularly relates to the technical fields of agents, large models, human-computer collaboration, task scheduling and the like. The specific implementation scheme is: in response to a human-computer interaction request triggered in a workflow execution process, directing the human-computer interaction request to a preset unified routing entry node; through the unified routing entry node, performing intent classification on the human-computer interaction request based on the stage context of the current workflow, and generating a routing decision instruction according to the intent classification result; according to the routing decision instruction, performing a corresponding process scheduling operation, and routing the workflow to a corresponding target agent graph node. The disclosure can realize centralized processing of human-computer interaction requests and unified scheduling of workflows, simplify workflow routing logic, and guarantee the accuracy of intent classification and process scheduling.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of intelligent agents, large models, human-computer collaboration, and task scheduling. Background Technology

[0002] In the field of intelligent agents, existing workflow engines have many shortcomings in handling dynamic human-computer interaction requests. Traditional solutions mostly rely on preset fixed processes or pure natural language dialogue frameworks. The former can only achieve human-in-the-Loop (HIL) confirmation through structured buttons, and cannot understand the needs of free text, nor can it support cross-stage jumps; the latter, although capable of free dialogue, lacks a clear process pause and resume mechanism, and cannot guarantee reliable confirmation of key business nodes. In addition, the callback-driven approach commonly used in asynchronous task scenarios faces the risk of callback loss or permanent process deadlock due to network jitter or service restarts. When the workflow contains multiple layers of subgraphs, the parent graph cannot be aware of the human confirmation status within the subgraphs, and the recovery logic requires manual coordination, resulting in opacity issues. Summary of the Invention

[0003] This disclosure provides a scheduling method, apparatus, and electronic device for solving at least one of the above-mentioned technical problems of an intelligent agent system.

[0004] According to a first aspect of this disclosure, a scheduling method for an intelligent agent system is provided, wherein the method includes: In response to a human-computer interaction request triggered during workflow execution, the human-computer interaction request is directed to a preset unified routing entry node; Through the unified routing entry node, the human-computer interaction request is classified according to the stage context of the current workflow, and a routing decision instruction is generated based on the intent classification result. Based on the routing decision instruction, the corresponding process scheduling operation is executed to route the workflow to the corresponding target intelligent agent graph node.

[0005] According to a second aspect of this disclosure, a scheduling apparatus for an intelligent agent system is provided, wherein the apparatus includes: The unified routing module is used to respond to human-computer interaction requests triggered during workflow execution and direct the human-computer interaction requests to a preset unified routing entry node; The intent classification module is used to classify the human-computer interaction request based on the current workflow stage context through the unified routing entry node, and generate routing decision instructions based on the intent classification results. The routing and scheduling module is used to execute the corresponding process scheduling operation according to the routing decision instruction, and to route the workflow to the corresponding target intelligent agent graph node.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and 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, which, when executed by the at least one processor, enables the at least one processor to perform the above-described method.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described above.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described above.

[0009] 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

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a scheduling method for an intelligent agent system provided in the first embodiment of this disclosure; Figure 2 This is an exemplary process diagram of S102; Figure 3 This is a flowchart illustrating the bubbling and recovery mechanism of multi-level subgraphs; Figure 4 This is a flowchart illustrating the asynchronous task scheduling mechanism; Figure 5 This is an exemplary flowchart of S104; Figure 6 This is a schematic diagram of the optimistic concurrency control mechanism; Figure 7 This is a block diagram of an electronic device used to implement the methods of the embodiments of this disclosure. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0012] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0013] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0014] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0015] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0016] The scheduling method for the intelligent agent system disclosed herein can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the scheduling method for the intelligent agent system provided herein can be executed by a server.

[0017] In the first disclosed embodiment, see Figure 1 , Figure 1 This diagram illustrates a flowchart of a scheduling method for an intelligent agent system according to a first embodiment of the present disclosure. The method includes: S101. In response to a human-computer interaction request triggered during workflow execution, the human-computer interaction request is directed to a preset unified routing entry node.

[0018] Among them, the unified routing entry node refers to the single entry node where all interruption and recovery scenarios in the workflow converge. It is driven by the Large Language Model (LLM) and is used to perform unified intent classification and routing decisions for various human-computer interaction requests.

[0019] Workflow refers to a directed graph structure consisting of multiple intelligent agent nodes connected in a specific logical order, used to complete a certain business task.

[0020] Human-computer interaction requests refer to events triggered by users or the system during workflow execution that require interruption of the current process for interaction. For example, human-computer interaction requests may include at least one of the following types: structured manual confirmation requests, i.e. confirmation instructions submitted through preset buttons or forms; free text interaction requests, i.e. natural language text entered by the user; asynchronous task callback requests, i.e. callback notifications triggered by the completion of external asynchronous tasks, etc. Of course, other types of requests are also possible, and no further limitations are imposed.

[0021] The workflow may include a main agent graph and at least one layer of sub-agent graphs; both the main agent graph and the sub-agent graphs contain at least one agent graph node; the agent graph node includes at least one of a unified routing entry node, a human intervention node, and a business execution node. The human intervention node refers to a key node where the workflow execution needs to be paused and await user confirmation or input.

[0022] In this disclosure, the workflow is not a linear process that is executed all at once, but rather has human intervention nodes or asynchronous task waiting points set at multiple key nodes. When the workflow starts executing and enters the human intervention waiting state (HILPending state), a human-computer interaction request can be triggered.

[0023] Taking a free text interaction request as an example, when a user sends free text, such as "change style to humor" or "change topic type," while the workflow is in a human intervention waiting state, the system first captures the type of the current human intervention node, writes the type into the corresponding free text data slot (free_text_hil_type slot), then clears the current workflow's human intervention waiting state flag (HilPending flag), and finally directs the free text interaction request to the preset unified routing entry node. This process ensures that free text can bypass the conventional structured human confirmation recovery path and be sent to the intent classification node for processing.

[0024] For structured manual confirmation requests, such as when a user clicks the "Confirm" or "Cancel" button, the system also directs them to a unified routing entry node. For asynchronous task callback requests, the system treats them as a special type of human-computer interaction request and also converges them to the same entry node. Through the above design, this application converges all process interruptions and various recovery scenarios (including structured manual confirmation, free text interaction, asynchronous task callbacks, etc.) into a single unified routing entry node, achieving a unified interruption handling logic.

[0025] It should be noted that this disclosure supports users initiating various human-computer interaction requests at any time, and these requests can be submitted at any time. This interaction is not constrained by the execution progress of background asynchronous tasks. Unlike traditional solutions where the interaction channel is locked during the execution of asynchronous tasks and users can only passively wait for the task to complete, this disclosure does not prohibit human-computer interaction requests due to incomplete tasks. After receiving a human-computer interaction request, the system will normally send it to the unified routing entry node for processing. At the same time, it will provide a response feedback at the current stage based on the asynchronous task scheduling logic, ensuring the continuous operation of background tasks while allowing users to modify business parameters and adjust the process execution intent midway. This effectively breaks down the interaction barriers during the task execution stage and greatly improves the flexibility of human-computer collaborative interaction and the timeliness of responding to business needs.

[0026] S102. Through a unified routing entry node, the intent of the human-computer interaction request is classified based on the stage context of the current workflow, and a routing decision instruction is generated based on the intent classification result.

[0027] The routing decision instruction refers to structured control information generated by the unified routing entry node based on the intent classification result of the human-computer interaction request. It is used to instruct subsequent process scheduling operations and determine the path of the human-computer interaction request. For example, the routing decision instruction can include two components: first, the intent classification result, i.e., the user intent category output by the large language model, including but not limited to confirmation type, rejection type, parameter modification type, or cross-stage jump type; second, business semantic parameters, i.e., structured field values ​​extracted from the human-computer interaction request and associated with the intent classification result, such as the name and value of the field to be modified under the parameter modification type, or the target stage identifier under the cross-stage jump type. The routing decision instruction is transmitted internally in the system in the form of key-value pairs or structured data objects, serving as the sole input basis for conditional edge functions or process schedulers. By encapsulating the intent classification result and business semantic parameters into a unified routing decision instruction, this disclosure achieves a seamless transition from semantic understanding to process control, enabling subsequent scheduling operations to accurately determine the target graph node, parameter update method, and process jump direction based on the user intent, avoiding the complexity and inconsistency risks caused by multi-stage parsing or intermediate state caching.

[0028] The unified routing ingress node is configured with a differentiated context policy, which includes at least one of the following: When classifying execution intents, only the current workflow's stage context is injected; When classifying execution intent, filter at least one of the following: user memory data, knowledge base data, and tool list data; For other business execution nodes, inject at least one of the following: complete user memory data, knowledge base data, and tool list data.

[0029] The phase context refers to information related to the current workflow execution phase, including the user's current phase (such as the script generation phase or design phase), the manual intervention items currently being confirmed, and the list of optional user actions.

[0030] Differentiated context strategies refer to employing different context injection strategies for different types of intelligent agent nodes. For example, when performing intent classification at the unified routing entry node, only the current workflow stage context is injected, such as: which stage the user is currently in, what they are confirming, and what optional operations are available, without injecting at least one of the user memory data, knowledge base data, and tool list data, thereby reducing interference and improving classification speed and accuracy. For other business execution nodes, such as script generation nodes and design nodes, at least one of the complete user memory data, knowledge base data, and tool list data can be injected to ensure that they can utilize all available information to complete complex tasks.

[0031] At the unified routing entry node, the system first obtains the current workflow's stage context. This stage context includes the user's current stage, such as the script writing stage; the specific matter being confirmed, such as script content confirmation; and the currently available operation list, such as "confirm submission" or "modify parameters." Unlike related technologies where intent classification nodes need to carry a large amount of context such as user memory, knowledge base, and tool list, the unified routing entry node in this application adopts a differentiated context strategy, injecting only the aforementioned stage context, without injecting user memory data, knowledge base data, and tool list data. The technical effect of this is to reduce interference from irrelevant information, improve the speed and accuracy of intent classification, and significantly reduce token consumption.

[0032] Furthermore, the system inputs the human-computer interaction request along with the current workflow's stage context into a large language model for intent classification. Taking a free text interaction request as an example, the large language model outputs intent classification results based on the free text content and stage context. For example, the intent classification results may include at least one of the following: confirmation, rejection, parameter modification, and restart from. Confirmation indicates that the user agrees to the current stage's operation and wishes to proceed to the next stage; rejection indicates that the user abandons the current process; parameter modification indicates that the user wishes to adjust a parameter, such as "reducing the duration to 30 seconds"; and restart from a previous stage indicates that the user wishes to return to a previous stage, such as "changing the topic to a technology-related one" to start over.

[0033] After obtaining the intent classification result, the large language model also extracts business semantic parameters corresponding to the intent classification result from the human-computer interaction request and stage context. For example, for parameter modification type, the large language model extracts the specific field to be modified, such as "duration" and the modified value, such as "30 seconds"; for cross-stage jump type, the large language model extracts the target stage identifier, and the system outputs the intent classification result and semantic parameters as routing decision instructions.

[0034] S103. Based on the routing decision instruction, execute the corresponding process scheduling operation to route the workflow to the corresponding target intelligent entity graph node.

[0035] After generating the routing decision instruction, the system calls a pre-defined conditional edge function. This function takes the intent classification result and business semantic parameters from the routing decision instruction as input to determine the target intelligent agent graph node to which the next step should be taken. Through conditional edge distribution, accurate routing of the corresponding requirements in the human-computer interaction request is achieved.

[0036] Among them, process scheduling operation refers to various actions that dynamically adjust the execution path of the current workflow according to the routing decision instructions. Its function is to guide the workflow to the graph node position that matches the user's intention, so as to realize the process advancement, rollback, modification or termination operations. For example, the process scheduling operation includes, but is not limited to, the following: When the intent classification result in the routing decision instruction is a confirmation type, the process scheduling operation advances the workflow from the current manual intervention node to the next business execution node of that node, allowing the process to continue flowing in the preset direction; when the intent classification result is a rejection type, the process scheduling operation jumps the workflow to the process termination node, ending the current session or business instance; when the intent classification result is a parameter modification type, the process scheduling operation redirects the workflow to the business execution node corresponding to the current stage according to the business semantic parameters carried in the routing decision instruction, such as the same script generation node, and triggers that node to re-execute with the updated parameters, thereby achieving online parameter correction without reverting to the process starting point; when the intent classification result is a cross-stage jump type, the process scheduling operation directly jumps the workflow to the manual intervention node or business execution node corresponding to the target stage according to the target stage identifier in the business semantic parameters, allowing the process to continue execution from the specified stage. The above process scheduling operations can be implemented through preset conditional edge functions and edge mapping relationships between each graph node, ensuring the continuity and consistency of workflow execution. Through process scheduling operations, this disclosure achieves accurate and flexible response to various user intentions, significantly improving the scheduling capability of intelligent agent systems for human-computer interaction requests.

[0037] The method disclosed herein centrally processes human-computer interaction requests by pre-setting a unified routing entry node, accurately classifies user intents by combining the stage context in the global context, generates routing decision instructions, and dynamically schedules the workflow to the target graph node. This significantly improves the response efficiency and routing accuracy of the intelligent agent scheduling system to dynamic interaction requests, ensures that the process execution path is highly consistent with the user intent, effectively avoids process deviations caused by missing context or incorrect intent recognition, and realizes the continuity, flexibility, and intelligence of workflow execution, providing a reliable guarantee for efficient process scheduling in complex business scenarios.

[0038] In some examples, the human-computer interaction request includes a free-text interaction request input by the user; when the current workflow is in a state of waiting for human intervention, S101 includes: Step 1: In response to the triggered free text interaction request, capture the type of the current human intervention node and write the type of the human intervention node into the corresponding data slot; Step 2: Clear the manual intervention waiting status indicator in the current workflow and direct free text interaction requests to the unified routing entry node.

[0039] Free-text interaction requests refer to unstructured text information entered by users in natural language, such as "change the style to humor" or "reduce the duration to 30 seconds." Unlike structured manual confirmation requests (such as clicking a preset button), free-text interaction requests can express more complex and flexible intentions.

[0040] The HIL Pending state refers to an intermediate state in which the workflow pauses its current process and waits for user confirmation, modification, or cancellation when it reaches the human intervention node. In this state, the workflow will not proceed automatically, but rather control will be handed over to the user.

[0041] The HIL Type refers to the specific type identifier of the currently triggered waiting node, such as a script confirmation node (script_hil), parameter collection node, or design review node, etc., without further limitation. Different types of manual intervention nodes correspond to different matters to be confirmed and optional operations.

[0042] A data slot is a key-value pair storage area in the graph state used to temporarily store parameters or state information extracted during user interactions. Each data slot has a unique name, such as a free text interaction request corresponding to a free text type data slot (free_text_hil_type Slot), which supports read and overwrite operations.

[0043] The manual intervention waiting status flag is a flag in the workflow status used to indicate whether the current workflow is in a manual intervention waiting state. When the flag is true, it means that the workflow has been paused and is waiting for a user response; when the flag is cleared, it means that the workflow has exited the waiting state and can continue execution or be rerouted.

[0044] Specifically, regarding step one, when the workflow reaches a certain human intervention node, such as the script confirmation node in the script generation stage, the system automatically sets the Hil Pending flag to true and pauses workflow execution, waiting for user input. At this time, if the user enters free text in the interactive interface and submits it, the system first recognizes that the input is a free text interactive request, rather than a structured button request.

[0045] The system immediately reads the human intervention node type (HILType) recorded in the current workflow status. This HILType value is written into a pre-defined dedicated data slot. The purpose of this data slot is to ensure that subsequent processes know at which stage and under which type of human intervention node the current free text was entered, so as to correctly interpret the user's intent.

[0046] Furthermore, regarding step two, after writing the manual intervention node type into the data slot, the system performs a clearing operation, setting the Hil Pending flag in the current workflow from "true" to "false". This removes the workflow's current "waiting for structured confirmation" state, preventing it from following the original structured manual confirmation recovery path and allowing free text interaction requests to be routed to the unified routing entry node for reclassification of intent.

[0047] Subsequently, the system directs the free text interaction request, including the text content entered by the user and the current workflow stage context, to a unified routing entry node. This node is driven by a large language model and will perform semantic understanding and intent classification on the free text.

[0048] Thus, by capturing the current human intervention node type and writing it into a dedicated data slot, the system can accurately know at which stage and specific node the user entered the free text, providing crucial contextual information for the subsequent accurate intent classification by the large language model. Secondly, by clearing the human intervention waiting status indicator, the system breaks the rigid mode of traditional structured human confirmation that can only be restored through preset buttons, enabling free text to be dynamically rerouted to a unified routing entry node, rather than being forcibly sent to a recovery path that can only handle structured confirmation.

[0049] See in some examples Figure 2 , Figure 2 An exemplary flow diagram of S102 is shown, which includes: S1021. Input the human-computer interaction request and the current workflow stage context into the large language model for intent classification to obtain the intent classification result.

[0050] At the unified routing entry node, the system first obtains the stage context of the current workflow. This stage context includes the name of the stage the user is currently in and the specific items being confirmed. The human-computer interaction request is concatenated with the stage context of the current workflow to construct a structured input text. Then, the large language model interface is called for inference. Based on its semantic understanding capabilities, the large language model outputs the intent classification result.

[0051] For example, for the free text "change style to humor", the large language model outputs an intent classification result as parameter modification type; for the free text "okay", the output intent classification result is confirmation type; for the free text "change topic to technology type", the output intent classification result is cross-stage jump type; for the free text "never mind, I won't do it", the output intent classification result is rejection type.

[0052] S1022. Based on the human-computer interaction request and the current workflow stage context, extract the business semantic parameters corresponding to the intent classification result, and use the intent classification result and business semantic parameters as routing decision instructions.

[0053] Among them, business semantic parameters refer to structured field data extracted from human-computer interaction requests and associated with intent classification results. These parameters can be directly understood and used by the workflow execution engine, or can directly instruct conditional edge functions to obtain calculation results. Business semantic parameters are a quantitative expression of key information implicit in the user's natural language, such as the operation object, target value, and jump position. Their specific types correspond to the intent classification results and include at least one or more of the following types: Parameter modification semantic parameters are used to indicate the name and value to be updated of a business field in the workflow. For example: {field:“duration”,value:30} means to modify the duration to 30 seconds; or {field:“style”,value:“humor”} means to modify the style to humor. The target-type semantic parameter indicates the target stage or node to which the workflow needs to jump, for example: {target_stage:“param_collect”}, which means jumping to the parameter collection stage; and the acknowledgment / rejection semantic parameter, which is usually empty or contains only a boolean flag, to indicate an operation that does not require additional parameters.

[0054] Business semantic parameters can be encapsulated in key-value pair or JSON object format and passed to subsequent conditional edge functions or business execution nodes through data slots. By transforming the operational intent contained in free text or structured requests into standardized business semantic parameters, this disclosure achieves a precise mapping between the output of a large language model and workflow control logic, avoiding scheduling errors caused by semantic ambiguity or inconsistent formats, and significantly improving the accuracy and executability of routing decisions.

[0055] Business semantic parameters refer to structured field values ​​extracted from user human-computer interaction requests, used to support further execution of intent classification results. For example, for intents involving parameter modification, business semantic parameters may include the name of the field to be modified and its modified value; for intents involving cross-stage jumps, business semantic parameters may include the target stage identifier, etc., without further limitation.

[0056] While obtaining the intent classification result, the large language model also needs to extract the business semantic parameters corresponding to the intent classification result from the human-computer interaction request. This process is also completed by the large language model, but the system explicitly limits the large language model to extract parameters only from the currently received human-computer interaction request through the design of prompt words.

[0057] For example, when the intent classification result is a parameter modification type, the large language model extracts the business semantic parameter from the free text "style to humor": {field: "style", value: "humor"}; for "duration reduced to 30 seconds", it extracts {field: "duration", value: 30}. When the intent classification result is a cross-stage jump type (restart_from), it extracts the business semantic parameter from the free text "topic changed to technology type": {target_stage:"param_collect"}. For confirmation or rejection types, it is usually not necessary to extract additional business semantic parameters, or empty parameters can be extracted.

[0058] The intent classification results and business semantic parameters are encapsulated into a structured routing decision instruction object, which will be parsed by the conditional edge function in the subsequent step S103 to determine the specific jump target of the workflow.

[0059] In some examples, after extracting the business semantic parameters corresponding to the intent classification results based on the human-computer interaction request and the stage context of the current workflow, the method further includes: S1023. Write the extracted business semantic parameters into the corresponding data slots and perform parameter protection operations.

[0060] Among them, parameter protection operations refer to a set of security measures implemented to ensure that critical fields in the workflow are not accidentally overwritten or incorrectly extracted, including field read-only marking, prompt words to limit the extraction source, and overwrite writing method updates.

[0061] After extracting the business semantic parameters, the system needs to write these parameters into the data slots in the workflow state so that subsequent business execution nodes can read and use these parameters. To prevent parameters from being overwritten by errors or extracted from error sources, this disclosure designs parameter protection operations. Specifically, in some examples, S1023 includes: Sub-step 1: Mark the workflow key fields in the data slot as read-only; Among them, key fields refer to fields that play a decisive role in the workflow status and cannot be modified arbitrarily by users, such as business type identifier (function_type) or process control flag.

[0062] Specifically, the workflow status contains some key fields, such as business type identifiers or process control flags, which cannot be arbitrarily modified by users using free text. The system pre-marks these key fields as read-only. When subsequent parameter write operations attempt to modify these fields, the system will refuse to write or ignore the operation, thereby ensuring the logical consistency of the workflow.

[0063] Sub-step two: In the prompt words input to the large language model, restrict the large language model to extract business semantic parameters only from the currently received human-computer interaction request.

[0064] Among them, prompts refer to text instructions input to the large language model, which are used to guide the large language model to understand user input and generate output in the expected way.

[0065] To prevent the large language model from conjuring parameter values ​​from historical dialogue records, user memory, or knowledge bases, the system explicitly adds a limiting statement to the prompt when calling the large language model, such as: "Please extract parameters only from the current user input message, and do not extract them from historical records or memory data." This limitation ensures that the semantic parameters extracted by the large language model are entirely derived from the user's current input, avoiding interference from residual historical values.

[0066] Sub-step 3: Update business semantic parameters using data slot overwrite method.

[0067] Among them, overwrite (SetSlot) refers to the operation method of directly replacing the original value in the data slot with the newly extracted parameter value, without merging or retaining the historical value.

[0068] Once the extracted business semantic parameters pass validation, the new parameter values ​​are written to the corresponding data slots using an overwrite method. This means the old values ​​in the data slots are directly replaced with the new values, without merging, appending, or retaining historical versions. This writing method is concise and efficient, and effectively eliminates inconsistencies caused by residual old values. For example, if a data slot originally stores a style field: "formal", and the user enters "change style to humor", the system extracts style: "humorous" and directly overwrites it, updating the value in the data slot to style: "humorous".

[0069] By performing parameter protection operations, including marking key workflow fields as read-only, limiting the large language model to extract parameters only from the currently received human-computer interaction requests in the prompt words, and updating parameters by using data slot overwrite, the system effectively prevents key fields from being accidentally tampered with, eliminates classification interference and state inconsistency caused by historical value residues, and significantly improves the security and reliability of the system when processing free text rerouting.

[0070] In some examples, S103 includes: By using a pre-defined conditional edge function, the workflow is redirected to the target intelligent agent graph node based on the intent classification result and business semantic parameters in the routing decision instruction.

[0071] Among them, the conditional edge function refers to an edge defined in the workflow graph. This edge is not a fixed one-way connection, but a function that calculates and returns one or more target node identifiers based on the current input state. The output of the conditional edge function determines the execution direction of the next step of the workflow.

[0072] A target agent graph node refers to the agent graph node that the workflow will execute or jump to next, determined by the conditional edge function based on the routing decision instruction. This node can be any one of a unified routing entry node, a manually intervened node, or a business execution node.

[0073] Furthermore, in the workflow, the connection between each intelligent agent graph node is not a single fixed edge, but a dynamic routing is achieved through conditional edge functions. The system pre-registers conditional edge functions in the main intelligent agent graph and each layer of sub-intelligent agent graphs. The function takes the routing decision instruction generated in step S102 as input, calculates and returns the identifier of the target intelligent agent graph node based on the intent classification result and business semantic parameters in the instruction.

[0074] For example, the mapping logic of a conditional edge function may include at least one of the following: When the intent classification result is a confirmation type, the conditional side function advances the workflow to the next business execution node in the current stage. For example, at the human intervention node in the script generation stage, if the user enters "OK" or clicks the "Confirm" button, the conditional side function sets the target node to the starting node of the design stage, thereby achieving natural progress of the process.

[0075] When the intent classification result is a rejection type, the conditional edge function will jump the workflow to the process termination node, end the current business workflow, and no longer execute subsequent nodes.

[0076] When the intent classification result is a parameter modification type, the conditional edge function first extracts the fields to be modified and the modified values ​​from the business semantic parameters, writes these parameters into the corresponding data slots, and then routes the workflow to the business execution node corresponding to the current stage, so that the node can re-execute the business logic using the updated parameters.

[0077] When the intent classification result is a cross-stage jump type, the conditional edge function extracts the target stage identifier from the business semantic parameters, and then the workflow directly jumps to the manual intervention node or business execution node corresponding to the target stage.

[0078] By using pre-defined conditional side functions, the intent parsed from natural language is transformed into specific workflow path selections. This allows the workflow to respond in real-time to users' free text commands, overcoming the limitations of traditional workflows that can only execute along fixed pre-defined paths. Furthermore, for parameter modification types, the conditional side functions write the modified parameters to the data slot and then reroute to the current business execution node. This achieves precise parameter updates and result regeneration without interrupting the entire process, avoiding the tedious process of users having to start from scratch. Moreover, for cross-stage jump types, the conditional side functions directly jump to the user-specified target stage without canceling the entire process, significantly improving the operational flexibility and user experience of human-computer collaboration. Finally, for nested workflows, the conditional side functions can route across the levels of the main graph and subgraphs. Combined with the checkpoint bubbling and recovery mechanism for subgraph scope isolation, multi-level transparent jumps are achieved, with the parent graph unaware of the complex details within the subgraph.

[0079] For nested workflows containing a main agent graph and sub-agent graphs, the execution scope of conditional edge functions can span levels. For example, when a user triggers a cross-stage jump intent in the main agent graph, the conditional edge function can directly jump the workflow from the current subgraph to another subgraph or node in the main agent graph. In this process, the conditional edge function is responsible for determining whether to trigger the subgraph entry, pause, or exit operation based on the intent classification result.

[0080] The workflow includes a main agent graph and at least one layer of sub-agent graphs; both the main agent graph and the sub-agent graphs contain at least one agent graph node; the agent graph node includes at least one of a unified routing entry node, a manual intervention node, and a business execution node.

[0081] The master agent graph, or parent graph for short, is the top-level workflow diagram that contains the skeleton of the entire business process. The master agent graph can contain at least one child agent graph, forming a nested structure.

[0082] A sub-agent graph, or simply a subgraph, is a workflow graph nested within a main agent graph or other sub-agent graphs. It is used to implement relatively independent and reusable sub-processes. A sub-agent graph also contains at least one agent graph node.

[0083] Intelligent agent graph nodes refer to the basic execution units in a workflow graph. Functionally, they can be divided into unified routing entry nodes, manual intervention nodes, and business execution nodes. Unified routing entry nodes are responsible for aggregating and processing all interruption and recovery requests; manual intervention nodes are used to pause the workflow and wait for user confirmation or input; business execution nodes are used to call specific large language models or tools to complete a business task, such as script generation, parameter collection, and design generation.

[0084] See in some examples Figure 3 , Figure 3 The flowchart shown illustrates the multi-layered subgraph bubbling and recovery mechanism. This method also includes: S001. When the sub-agent graph reaches the manual intervention node and triggers the workflow pause operation, save the sub-graph scope checkpoint corresponding to the sub-agent graph. S002. Report the identifier and pause state of the sub-agent graph as a bubbling state to the main agent graph; S003. The main agent graph stores the main graph checkpoints containing the bubbling state. S004. If it is necessary to restore the workflow, load the subgraph scope checkpoint corresponding to the sub-agent graph saved in the main graph checkpoint and continue to execute the workflow.

[0085] It should be noted that S001-S004 can be executed or triggered at any time after the workflow begins, without any specific limitation. Furthermore, in some examples, at least one step in S001-S004 can be omitted or its execution order can be changed, without any limitation here.

[0086] A subgraph scoped checkpoint is a state snapshot saved separately for the sub-agent graph. Its key follows the format "Session ID: Sub-agent Graph Identifier," such as "sessionID:ScriptAgent." This subgraph scoped checkpoint is independent of the main graph checkpoint of the main agent graph, with isolated scopes, allowing graph states at different levels to be stored and restored independently. A subgraph scoped checkpoint contains at least the current execution position of the subgraph, i.e., the node identifier corresponding to the pause point; and all state data within the subgraph, including the current value of data slots and node execution progress.

[0087] A main graph checkpoint is a snapshot of the state of the main agent graph. When a subgraph reports its bubbling state, the main agent graph persists its own state, including the identifier of the currently executing subgraph, the paused state of the subgraph, and the main graph's own business data, as a main graph checkpoint. Main graph checkpoints and subgraph scope checkpoints are independent and stored separately.

[0088] Bubble states refer to the state information passed up to the parent graph (main agent graph or higher-level subgraph) after a child agent graph triggers a pause operation. A bubbling state includes at least the child agent graph's identifier (ActiveSubAgentID) and the pause status (Status=Paused or Waiting), and may also include the HilPending status. Bubble states allow the parent graph to perceive that a manual pause has occurred within the subgraph without needing to know the specific reason for the pause or the execution details within the subgraph.

[0089] The latest data slot data refers to the business parameters that the parent graph may have updated due to user interaction or asynchronous tasks during the subgraph's pause. These latest values ​​should be incorporated into the subgraph's checkpoints when the subgraph resumes to ensure that the subgraph can continue execution using the latest parameters.

[0090] Specifically, for S001, when the main workflow graph calls a sub-agent graph and begins execution, the sub-agent graph executes sequentially according to the node order defined within it. When the sub-agent graph reaches a manual intervention node, that node triggers a workflow pause operation. At this point, the sub-agent graph first saves a sub-graph scope checkpoint. The key-value format of this checkpoint can be "sessionID:sub-agent graph identifier", such as "session123:ScriptAgent". This checkpoint records the current execution position of the sub-graph, i.e., the pause point, as well as the sub-graph's internal state data, such as existing data slot values ​​and intermediate calculation results. Because the checkpoint uses scope-isolated key-value pairs, checkpoints in different sub-graphs or the main graph do not interfere with each other.

[0091] For S002, after saving the subgraph scope checkpoint, the sub-agent graph reports its identifier and pause state as a bubbling state to the upper-level parent graph. The reporting method can be through a callback interface pre-registered by the parent graph, or by modifying a specific field in the parent graph state and setting the HilPending flag to true.

[0092] For S003, after the main agent graph receives the bubbling state reported by the subgraph, it immediately saves a main graph checkpoint. This checkpoint can contain the parent graph's own state, such as the current data slot value and execution progress, as well as information about the bubbling state reported by the subgraph, namely the subgraph identifier and pause status. After saving, the main agent graph can exit the execution loop and release the memory resources occupied by the current worker node to support the elastic scheduling of stateless business execution nodes (Workers).

[0093] For S004, when the user sends a subsequent interaction request, the main graph checkpoint is first loaded from persistent storage. The sub-agent graph identifier stored therein is parsed out. Then, based on this identifier, a key-value pair for the sub-graph scope checkpoint (such as "sessionID:ScriptAgent") is constructed, and the corresponding sub-graph scope checkpoint is loaded from storage. After successful loading, the system continues execution of the sub-agent graph from the pause position recorded in the checkpoint, while using the state data stored in the checkpoint, including the updated parameter values, for subsequent processing. Since the parent graph only stores the sub-graph identifier and pause state, without needing to understand the complex logic inside the sub-graph, the entire recovery process is completely transparent to the parent graph.

[0094] In some examples, after S003 and before S004, the method also includes: Load the subgraph scope checkpoint of the sub-agent graph and merge the latest data slot data of the main agent graph into the subgraph scope checkpoint.

[0095] It should be noted that this step can be omitted in some examples, but it is not limited here.

[0096] Specifically, when a subgraph is paused, the main graph may update some values ​​in its data slots due to other interactions, such as a user modifying global parameters via a button on the main graph interface. To ensure that the parameters used after the subgraph resumes are up-to-date, the system reads the latest data slot data from the main graph checkpoint after loading the subgraph's scope checkpoint. This includes the latest duration parameters and style parameters. These values ​​are then merged into the corresponding data slots in the subgraph's scope checkpoint. The merging process typically uses an overwrite method, replacing the old values ​​in the subgraph with the latest values ​​from the parent graph. This ensures the consistency and real-time performance of parameters in multi-level nested scenarios.

[0097] Through the aforementioned multi-layered subgraph bubbling and recovery mechanism, the checkpoints of subgraphs and their parent graphs are independent of each other, allowing the states of different levels and subgraphs to be stored and recovered independently, avoiding state chaos and conflicts. Subgraphs report their own identifiers and paused states to the parent graph via bubbling, enabling the parent graph to perceive only the minimal information of "which subgraph is paused," without needing to understand the pause reasons, execution details, or node structures within the subgraph. This achieves transparency from the parent graph to manual intervention within the subgraph, solving the opaque problem in existing technologies where the parent graph cannot perceive the paused states of subgraphs and recovery logic requires manual coordination. The main graph stores... Once the main graph checkpoint in the bubbling state is completed, memory resources can be released, supporting elastic scaling and failover of stateless workers and improving the production-grade reliability of the system. During recovery, the corresponding subgraph scope checkpoint is accurately loaded based on the subgraph identifier in the main graph checkpoint, and the latest data slot data of the parent graph is merged to ensure that the subgraph can continue execution with the latest parameter values ​​after recovery, avoiding business errors caused by parameter inconsistencies. This mechanism supports multi-level nesting, and each subgraph can independently save checkpoints and bubble them up to the next level. During recovery, checkpoints are loaded layer by layer from top to bottom and the latest data is merged, realizing transparent and reliable recovery of complex nested workflows.

[0098] See in some examples Figure 4 , Figure 4 The flowchart of the asynchronous task scheduling mechanism shown includes the following steps before S103: S011. Read the preset task status slot and check if there are any unfinished asynchronous tasks.

[0099] S012. In response to the detection of an incomplete asynchronous task, the human-computer interaction request is routed to the response processing in the current stage without re-entering the workflow pipeline.

[0100] It should be noted that S011-S012 can be executed or triggered at any time after the workflow begins, without any specific limitation. Furthermore, in some examples, at least one step in S011-S012 can be omitted or its execution order can be changed, without any limitation here.

[0101] Asynchronous tasks refer to tasks initiated by the intelligent agent system that require a relatively long time to execute in the background without blocking the main workflow, such as video generation, batch inference of large language models, and external API calls. Asynchronous tasks typically return a task identifier (Task ID) immediately after starting, but the actual execution result needs to wait for a period of time to be obtained.

[0102] The Task Status Slot is a predefined data slot in the GraphState used to store the status of currently executing asynchronous tasks. The task status can include enumerated values ​​such as "not started", "in progress", "completed", and "failed". The system can quickly determine whether there are any unfinished asynchronous tasks by reading this slot.

[0103] The response processing within the current stage refers to the process where, when the system detects an incomplete asynchronous task, it does not send the user's human-computer interaction request to the unified routing entry node for intent classification and process rerouting. Instead, it directly returns a response message to the user within the current stage. This approach avoids incorrectly re-entering the workflow pipeline before the asynchronous task is completed, which could lead to state conflicts.

[0104] A workflow pipeline refers to the complete workflow execution path that starts from the unified routing entry node and goes through a series of processing steps such as intent classification, conditional edge distribution, and business execution nodes. The system will skip this pipeline if the asynchronous task is not completed.

[0105] For S011, before executing workflow scheduling, that is, before sending the human-computer interaction request to the unified routing entry node for intent classification, the system first reads the preset task status slot in the workflow status. The task status slot records whether there is an asynchronous task being executed in the current session and the current status of the task.

[0106] Specifically, suppose a user initiates an asynchronous video generation task through an intelligent agent system. Upon task startup, the system sets the task status slot to "in progress" and generates a unique task identifier, storing it in persistent storage. When the user later sends another message, such as "Is it ready?", the system executes step S011 before step S103, reading the task status slot. If the slot value is "in progress," the detection result is "an unfinished asynchronous task exists"; if the slot value is "completed" or "empty," the detection result is "no unfinished asynchronous task exists."

[0107] Regarding S012, if step S011 detects an incomplete asynchronous task, i.e., the task status slot is "in progress," the system determines that it is not appropriate to re-enter the workflow pipeline at this time, because the result of the asynchronous task is not yet ready, and any operation attempting to advance the workflow may result in errors or conflicts. Therefore, the system directly routes the received human-computer interaction request to the response processing within the current stage.

[0108] For example, the response processing within the current stage may include: the system generating a preset or dynamically generated response message based on the current workflow stage context. This response does not change the workflow state, nor does it trigger any node jumps. The response is then returned to the user, and the current workflow remains in a paused state, still waiting for the asynchronous task to complete. Of course, the response processing can also take other forms, which are not limited here.

[0109] Furthermore, following S012, the method also includes: S013. When a human-computer interaction request is received again in the same session, query the asynchronous task status recorded in the preset persistent storage.

[0110] S014. If the asynchronous task has been completed, update the completion result of the asynchronous task to the task status slot and trigger the workflow to resume execution.

[0111] It should be noted that S013-S014 can be executed or triggered at any time after the workflow begins, without any specific limitation. Furthermore, in some examples, at least one step in S013-S014 can be omitted or its execution order can be changed, without any limitation here.

[0112] Among them, persistent storage (TaskDAO) refers to an external storage system that is independent of the worker node's memory, such as a relational database, key-value store, or distributed file system, used to store the state information of asynchronous tasks for a long time. The data in persistent storage will not be lost due to worker node restarts or network fluctuations.

[0113] In some examples, asynchronous tasks are also configured with callback notifications, which are used to write the state of the asynchronous task to persistent storage in advance when the asynchronous task completes. In this case, the callback notification is not a necessary condition for triggering the resumption of workflow execution.

[0114] Callback notification refers to an HTTP request or message queue notification sent proactively by the external service executing the asynchronous task to the intelligent agent system after the asynchronous task is completed. It is used to inform the system that the task has been completed and to carry the task result. In this disclosure, callback notification is designed as an optional advance notification mechanism, rather than a necessary condition for triggering workflow recovery.

[0115] Optional configurations for callback notifications include: In some examples, asynchronous tasks are also configured with callback notifications. A callback notification refers to an external service that executes an asynchronous task proactively sending an HTTP request or message to a pre-defined callback address of the agent system when the asynchronous task is completed. This request or message carries the task identifier and the task result. Upon receiving the callback, the system writes the task status to persistent storage, for example, updating the task status to "completed," and saves the task result.

[0116] In this disclosure, callback notifications are not a necessary condition for triggering workflow resumption. Even if callback notifications are completely lost due to network jitter, service restarts, or external service failures, the lazy recovery mechanism in steps S013 and S014 above will still function normally. When the user next actively sends a human-computer interaction request, the system will query persistent storage to find that the task has been completed and automatically populate the status and trigger recovery. In other words, callback notifications are only used to "in advance notify" the system that the task has been completed to reduce user waiting time, but the correctness and robustness of the system do not depend on callback notifications.

[0117] Regarding S013, after step S012, the workflow remains in a state of waiting for the asynchronous task to complete. When the user sends another human-computer interaction request in the same session later, such as asking "Is it done?" again, the system will not rely solely on the task status slot in memory, but will actively query the actual status of the asynchronous task recorded in the preset persistent storage.

[0118] Specifically, the system uses the previously saved task identifier as the query key to send a query request to persistent storage (such as a database or Redis). The persistent storage stores the latest state of the asynchronous task, which may be written by callback notifications or updated periodically by the system through polling. The design of persistent storage ensures that the task state will not be lost even if the worker node restarts or there is network jitter.

[0119] Regarding S014, if step S013 queries the persistent storage and finds that the asynchronous task has been completed, i.e., the status is "completed", the system can perform the following two operations: First, the results of asynchronous tasks, such as the Uniform Resource Locator (URL) of the generated video file or the content of the generated text, are written to the relevant data slots in the workflow status, and the task status slot is updated from "in progress" to "completed". This operation is called "auto-backfill status", which enables the workflow to use the output of asynchronous tasks.

[0120] Second, the system triggers workflow resumption. Based on the current stage context and the results of asynchronous tasks, the system determines the next execution direction. For example, after video generation is complete, the workflow can automatically advance to the next stage, such as "video preview" or "release confirmation," which is the lazy recovery mechanism. If the asynchronous task is still not completed, for example, if the status is still "in progress" after querying, the system repeats step S012 and routes back to the response processing within the current stage without triggering workflow resumption.

[0121] Through the aforementioned asynchronous task scheduling mechanism, firstly, by reading the task status slots before routing decisions to detect incomplete asynchronous tasks and routing human-computer interaction requests to the response processing within the current stage without re-entering the workflow pipeline, the system effectively avoids erroneously advancing the workflow or performing intent classification before asynchronous tasks are completed, preventing state conflicts and invalid scheduling. Secondly, by querying the real status of asynchronous tasks recorded in the preset persistent storage when receiving human-computer interaction requests again in the same session, and only filling the status slots with the results and triggering workflow recovery after the task is completed, a lazy recovery mechanism is implemented. Users only need to send messages normally to automatically complete the polling and recovery of task status without relying on external callbacks. Thirdly, the callback notification is designed as an optional advance notification mechanism, not a necessary condition for triggering workflow recovery. This allows the system to detect task completion and process it correctly through lazy recovery even if callbacks are lost, thus completely eliminating the risk of permanent process deadlock due to callback loss in existing technologies and significantly improving the system's robustness and fault tolerance. Finally, by saving task status through persistent storage, worker nodes can resume execution statelessly, supporting failover and elastic scaling. The asynchronous task scheduling mechanism disclosed herein greatly enhances the reliability and stability of the intelligent agent workflow system in handling asynchronous tasks while ensuring smooth user interaction.

[0122] In some examples, the method also includes: By using the mutex lock corresponding to the session identifier, multiple human-computer interaction requests in the same session are serialized.

[0123] It should be noted that this step can be executed or triggered at any time after the workflow begins, without any specific limitation. Furthermore, in some examples, this step can be omitted or its execution order can be changed, which is not limited here.

[0124] The Session ID is a string used to uniquely identify a user session. Multiple interaction requests from the same user on the same terminal or browser belong to the same session. The Session ID is used throughout the entire workflow lifecycle to associate multiple human-computer interaction requests, callback requests, and confirmation requests from the user.

[0125] A mutex lock is a synchronization mechanism used to prevent multiple requests from accessing shared resources simultaneously. In this application, each session identifier corresponds to a mutex lock. The system acquires the lock before starting to process a request and releases the lock after processing. If another request from the same session arrives when the lock is already occupied, the new request waits or is queued until the lock is released.

[0126] Serialization refers to processing multiple requests in the same session sequentially according to their arrival order, rather than executing them concurrently. Serialization can avoid data inconsistencies or state conflicts caused by multiple requests modifying the workflow state at the same time.

[0127] Specifically, when the system receives a user's human-computer interaction request, it first extracts the session identifier associated with the request. The system maintains a mapping table with the session identifier as the key and a mutex lock as the value. Before processing the request, the system acquires the mutex lock corresponding to the session identifier. If, during lock acquisition, it is found that the lock is already held by another request in the same session, the current request enters a waiting queue until the lock is released. Only after the lock is successfully acquired does the system begin processing the request, including directing it to the unified routing entry node, intent classification, and process scheduling. After the request is processed, the system releases the mutex lock, allowing the next waiting request to continue execution.

[0128] Through this mechanism, multiple requests in the same session, such as a user first sending the free text "Style changed to humor" and then immediately clicking the confirmation button, while the asynchronous task callback arrives at the same time, will not be executed concurrently. Instead, these human-computer interaction requests will be processed serially, thus completely avoiding the data inconsistency problem caused by multiple requests concurrently overwriting the graph state.

[0129] In some examples, the method also includes: When a workflow is paused, the business execution node executing the workflow releases its state in memory and persists the graph state of the current workflow to a preset graph state storage checkpoint.

[0130] Subsequently, any business execution node can load the graph state from the graph state storage checkpoint and resume execution.

[0131] It should be noted that this step can be executed or triggered at any time after the workflow begins, without any specific limitation. Furthermore, in some examples, this step can be omitted or its execution order can be changed, which is not limited here.

[0132] Stateless worker nodes refer to execution units that do not store any local memory state. When a workflow is paused due to manual intervention or asynchronous tasks, the worker node persists its graph state to external storage and then releases its own memory resources. Any other worker node can then load the graph state from external storage and continue execution without relying on the original worker node.

[0133] Graph state refers to the collection of all state data generated during workflow execution, including the current execution position (current node identifier), the values ​​of each data slot, references to subgraph scope checkpoints, task state slots, etc.

[0134] A graph state storage checkpoint (CheckpointStore) refers to an external storage unit used to persistently store graph state. This storage unit can be a relational database, key-value store, or distributed file system, without limitation. Each checkpoint is typically associated with a session identifier, allowing the system to quickly load the corresponding graph state based on the session identifier.

[0135] Specifically, when a workflow is paused due to manual intervention, such as when the sub-agent graph reaches the script_hil node, or when it is in a waiting state due to an incomplete asynchronous task, the business execution node (Worker) currently executing the workflow can perform the following operations: First, the graph state of the current workflow is serialized into a storable format, such as JSON, and written into a preset graph state storage checkpoint. This checkpoint is associated with a session identifier and can be retrieved using a unique key (such as the session identifier).

[0136] Second, the business execution node releases all memory resources it occupies, including but not limited to caches, temporary variables, and network connections for large language model inference, which is also known as release-style state management.

[0137] It should be noted that this step can be executed or triggered at any time after the workflow begins, without any specific limitation. Furthermore, in some examples, this step can be omitted or its execution order can be changed, which is not limited here.

[0138] When the workflow needs to be resumed later, such as when a user sends free text to trigger resumption, or when an asynchronous task completes, the system can start from any available business execution node, not necessarily the node used when it was paused. Based on the session identifier, it loads the previously saved graph state from the graph state storage checkpoint and continues execution from the execution position recorded in the checkpoint. Even if the original worker node crashes or is rescheduled, the new worker node can still resume the workflow from the persistent checkpoint without losing state, significantly improving the system's production-grade resilience and availability.

[0139] See in some examples Figure 5 , Figure 5 The flowchart shown illustrates the optimistic concurrency control mechanism, which also includes: S021. If a new human-computer interaction request is received, allocate a new execution token to the human-computer interaction request.

[0140] The execution token refers to an incrementing version number or unique identifier used in an optimistic concurrency control mechanism. Each time a new human-computer interaction request is received, the system assigns a new execution token to that request. The business execution node currently executing the workflow holds the execution token assigned to it at the start of execution. By comparing the currently held token with the newly generated token, it can be determined whether a new request has jumped the queue or preempted the request.

[0141] When the system receives a new human-computer interaction request, in addition to acquiring a session-level mutex lock, it will also allocate a new execution token for the request. The execution token can be a monotonically increasing integer or a globally unique identifier. The execution token will then be associated with the request and passed throughout the request processing.

[0142] S022. If the business execution node currently executing the workflow detects that the execution token it currently holds is inconsistent with the newly generated execution token, it is determined that the token is lost.

[0143] In the context of stateless recovery, the following situation may occur: an old worker node is executing a task that takes a long time, and during the execution of the task, a new interaction request arrives in the same session. When the new request arrives, the system assigns it a new execution token, while the old worker node still holds the token with the previous version number. The system can either record the latest token value in shared storage, which is associated with the session identifier, or have the new request update the token value when acquiring the mutex lock.

[0144] Before an old worker node completes its current step and prepares to continue executing subsequent process scheduling, it checks whether the latest token value of the current session is consistent with the token value it holds. If they are inconsistent, it determines that "token is lost".

[0145] S023. Pause the current execution and save the workflow's graph state to the preset graph state storage checkpoint.

[0146] It should be noted that S021-S023 can be executed or triggered at any time after the workflow begins, without any specific limitation. Furthermore, in some examples, at least one step in S021-S023 can be omitted or its execution order can be changed, without any limitation here.

[0147] Once the old worker node detects a lost token, indicating that a new request has taken over control of the session, it should immediately pause execution, save the current workflow graph state to the graph state store checkpoint, release all memory resources, and exit. Subsequently, the worker node handling the new request will load the latest graph state from the graph state store checkpoint and continue execution, thus avoiding conflicts caused by simultaneous state modifications by both the old and new nodes.

[0148] Through an optimistic concurrency control mechanism, a new execution token is allocated when a new human-computer interaction request arrives. When the original execution node detects that the token is lost, it actively suspends execution and saves the checkpoint. This effectively solves the conflict between long-running tasks and new preemptive requests, avoids zombie nodes from continuing to execute invalid operations or overwriting the updates of new requests, and further enhances the system's concurrency security and response timeliness.

[0149] The following is a specific example illustrating the specific flow of the method provided in this disclosure: When a user initiates a request to generate a 60-second personal documentary, the system starts the corresponding workflow, which is configured with a four-stage workflow: "script generation - material selection - music composition - video export". The "material selection" workflow calls a sub-graph, which is used for editing by scene category, while the "music composition" workflow is an asynchronous task.

[0150] During the script generation phase, the system provides an initial draft: "Majestic snow-capped mountains, tranquil lakes, pleasant journey." If the user is dissatisfied, they can directly input a free-text interaction request while in a manual intervention waiting state: "Make it more lively, add a line of dialogue." The system captures the node type (script_hil), clears the waiting flag, and directs the free-text interaction request to the unified routing entry point. The unified routing entry point only injects the stage context (currently script confirmation, optional modification), without injecting historical memory or tool lists. The large language model outputs the intent classification result as "modify," with business semantic parameters: {style:"lively", extra:"dialogue A"}. The conditional edge function jumps back to the script generation node, overwrites the written parameters, and generates a new script after 5 seconds. The user confirms, the process progresses, thus achieving free-text rerouting and differentiated context.

[0151] Upon entering the material selection stage, the system calls the sub-image for "scene-based editing." Within the sub-image, there are three parallel editing nodes: "Seaside," "Forest," and "City." Execution pauses when reaching the "City" node because the material contains numerous street scenes, requiring user confirmation of which to retain. The sub-image saves its scope checkpoint and bubbles its identifier and paused state to the main image. The main image releases memory after saving the checkpoint. The user sends: "Keep only night scenes in the city section, remove daytime street scenes." The system routes back to the sub-image based on its identifier, loads the sub-image checkpoint, merges the latest data slot in the main image ("Keep only night scenes"), and resumes from the pause point. The sub-image automatically selects night scene clips, remaining unaffected by the parent image, thus achieving multi-layered sub-image bubbling and transparent recovery.

[0152] An asynchronous task is triggered during the music composition stage: automatically matching and mixing background music, approximately 3 minutes. The system stores the task status in the database, and the workflow waits.

[0153] Thirty seconds later, the user asks, "Is it ready?" The system reads the task status slot and finds it in progress, directly replying, "Matched 'Starry Sea,' mixing in progress, 35%," without entering the pipeline. The user then sends, "Let's change to some light music." The system detects that the asynchronous task is incomplete but allows parameter modification, notifies the synthesis service to update the track (or marks it for re-matching), and replies, "Changed, please wait." Two and a half minutes later, the task is completed, and the callback is written to the status. The user asks again, the system queries the database and finds it complete, automatically fills in the audio link and triggers recovery, presenting the 60-second final product. If the callback is lost, the next query will still recover, thus achieving lazy recovery of asynchronous tasks. At any point during the execution of this public workflow, the user can trigger a human-computer interaction request at any time, and the system can schedule and adjust operations such as modifying protection parameters at any time according to the request.

[0154] Before exporting the video, the user quickly sends two consecutive messages: "Add title 'My Trip' to the intro" and "Add date xxxx.xx.xx to the outro." A mutex lock serializes the process: the first message acquires token 1 and is processed; the second message arrives and acquires token 2 to update the shared token. Before the first message is submitted, a token inconsistency (loss) is detected, and the state (including the added title) is actively paused and saved. The second message loads this state, adds the date, and then submits. Ultimately, the intro has a title, and the outro has a date, with no overwriting or loss.

[0155] Through the above, users can modify scripts, filter materials, and change background music at any time using natural language, even while asynchronous tasks are running. Multi-level subgraphs can be transparently resumed when paused, and concurrent requests are secure. The entire process supports users initiating free text interaction and flexibly adjusting business parameters at any time during asynchronous task execution. Furthermore, it relies on mechanisms such as multi-level subgraph management, lazy recovery of asynchronous tasks, concurrency security control, and state persistence to ensure stable and orderly workflow execution.

[0156] The method disclosed herein significantly reduces token consumption and improves classification speed and accuracy by uniformly guiding various human-computer interaction requests to a unified routing entry node driven by a large language model and injecting only the current workflow stage context for intent classification. For free text interaction requests, this disclosure captures the current human intervention node type and clears the waiting flag while the human intervention is waiting, then routes the request to the unified routing entry node. The large language model identifies intents such as confirmation, rejection, parameter modification, or cross-stage jump and extracts business semantic parameters. Combined with a parameter protection mechanism, it achieves accurate routing of modified values ​​and jump targets, overcoming the shortcomings of rigid interaction and inability to jump across stages in existing technologies. For nested workflows containing a main agent graph and sub-agent graphs, this disclosure saves the subgraph scope checkpoint when the subgraph is paused and bubbles up its identifier and pause status to the main graph. The main graph saves the main graph checkpoint containing the bubbling status. Upon resumption, the subgraph scope checkpoint is loaded according to the subgraph identifier and the latest data slot data of the main graph is merged, achieving transparent resumption of the parent graph in multi-layer nested scenarios without the parent graph being aware of the internal details of the subgraph. For asynchronous tasks, this disclosure detects incomplete tasks by reading task status slots, routes interaction requests to the current stage of response processing, and queries the task status in persistent storage during subsequent interactions. Upon task completion, the slot is automatically updated and recovery is triggered. Callback notifications are only used for pre-writing status and not as necessary triggering conditions, completely eliminating the risk of process deadlock caused by lost callbacks. Furthermore, this disclosure uses session-level mutex locks to serialize multiple human-computer interaction requests within the same session, avoiding concurrent conflicts. When the workflow is paused, the memory state of the business execution node is released and the graph state is persistently stored, supporting the subsequent resumption of execution by any worker node. Combined with an execution token mechanism, a new token is allocated when a new request arrives; if the original execution node detects a token inconsistency, it pauses and saves its state, achieving scalability and failover. In summary, this disclosure uniformly handles various interruption and recovery scenarios, significantly improving interaction naturalness, system robustness, concurrency security, and scalability.

[0157] In the disclosed second embodiment, see Figure 6 ,like Figure 1 The principle shown Figure 6 This illustration shows a scheduling device 60 for an intelligent agent system according to a second embodiment of the present disclosure, wherein the device includes: The unified routing module 601 is used to respond to human-computer interaction requests triggered during workflow execution and direct the human-computer interaction requests to a preset unified routing entry node; The intent classification module 602 is used to classify the human-computer interaction request based on the current workflow stage context through the unified routing entry node, and generate routing decision instructions based on the intent classification results. The routing scheduling module 603 is used to execute the corresponding process scheduling operation according to the routing decision instruction, and to route the workflow to the corresponding target intelligent body graph node.

[0158] In some examples, the unified routing ingress node is configured with a differentiated context policy, which includes at least one of the following: When classifying execution intents, only the current workflow's stage context is injected; When classifying execution intent, filter at least one of the following: user memory data, knowledge base data, and tool list data; For other business execution nodes, inject at least one of the following: complete user memory data, knowledge base data, and tool list data.

[0159] In some examples, human-computer interaction requests include free-text interaction requests with user input; the unified routing module 601 is used for: In response to the triggered free text interaction request, capture the type of the current human intervention node and write the type of the human intervention node into the corresponding data slot; Clear the manual intervention waiting status indicator in the current workflow and direct free text interaction requests to the unified routing entry node.

[0160] In some examples, the intent classification module 602 is used for: The human-computer interaction request and the current workflow stage context are input into the large language model for intent classification to obtain the intent classification result; Based on the human-computer interaction request and the current workflow stage context, business semantic parameters corresponding to the intent classification result are extracted, and the intent classification result and business semantic parameters are used as routing decision instructions.

[0161] In some examples, the device also includes: The parameter protection module is used to write the extracted business semantic parameters into the corresponding data slots and perform parameter protection operations.

[0162] In some examples, the parameter protection module is specifically used for: Mark the workflow key fields in the data slot as read-only; In the prompt words input to the large language model, the large language model is limited to extracting business semantic parameters only from the currently received human-computer interaction request; Business semantic parameters are updated using a data slot overwrite method.

[0163] In some examples, the routing scheduling module 603 is used to redirect the workflow to the target intelligent agent graph node based on the intent classification result and business semantic parameters in the routing decision instruction through a preset conditional edge function.

[0164] In some examples, the workflow includes a main agent graph and at least one layer of sub-agent graphs; both the main agent graph and the sub-agent graphs contain at least one agent graph node; the agent graph node includes at least one of a unified routing entry node, a human intervention node, and a business execution node.

[0165] In some examples, the device also includes a subgraph bubbling recovery module for: When the sub-agent graph reaches the human intervention node and triggers a workflow pause operation, save the sub-graph scope checkpoint corresponding to the sub-agent graph. The identifier and pause state of the sub-agent graph are reported to the main agent graph as bubbling states; The main agent graph stores the main graph checkpoints, including the bubbling state. If the workflow needs to be restored, the workflow continues to execute by loading the subgraph scope checkpoint corresponding to the sub-agent graph based on the identifier of the sub-agent graph saved in the main graph checkpoint.

[0166] In some examples, the device also includes a data merging module for: loading subgraph scope checkpoints of the sub-agent graph and merging the latest data slot data of the main agent graph into the subgraph scope checkpoints.

[0167] In some examples, the device also includes an asynchronous task module for: Read the preset task status slots to check if there are any unfinished asynchronous tasks. In response to the detection of an incomplete asynchronous task, the human-computer interaction request is routed to the response processing in the current stage.

[0168] In some examples, the device also includes an asynchronous recovery module for: When a human-computer interaction request is received again in the same session, query the asynchronous task status recorded in the preset persistent storage; If the asynchronous task has been completed, the completion result of the asynchronous task will be updated to the task status slot, and the workflow will be triggered to resume execution.

[0169] In some examples, the device also includes a serial module for: By using the mutex lock corresponding to the session identifier, multiple human-computer interaction requests in the same session are serialized.

[0170] In some examples, the device also includes a persistence module for: When a workflow is paused, the business execution node executing the workflow releases its state in memory and persists the graph state of the current workflow to a preset graph state storage checkpoint.

[0171] In some examples, the device also includes a token distribution module for: If a new human-computer interaction request is received, a new execution token is assigned to the human-computer interaction request; If a business execution node currently executing a workflow detects that its current execution token is inconsistent with the newly generated execution token, it is determined that the token is lost. Pause the current execution and save the workflow's graph state to the preset graph state storage checkpoint.

[0172] 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.

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

[0174] Computer instructions stored on a non-transitory computer-readable storage medium are used to cause a computer to perform the above-described method.

[0175] Computer program products include computer programs that, when executed by a processor, implement the methods described above.

[0176] Figure 7 A schematic block diagram of an example electronic device 700 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.

[0177] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from a storage unit into random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0178] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0179] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 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 701 performs the various methods and processes described above, such as the methods described above. For example, in some embodiments, the methods described above can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, the computing unit 701 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0180] Various embodiments 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), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments 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.

[0181] 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.

[0182] 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.

[0183] 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).

[0184] 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 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.

[0185] 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.

[0186] 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.

[0187] 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 scheduling method for an intelligent agent system, wherein, The method includes: In response to a human-computer interaction request triggered during workflow execution, the human-computer interaction request is directed to a preset unified routing entry node; Through the unified routing entry node, the human-computer interaction request is classified according to the stage context of the current workflow, and a routing decision instruction is generated based on the intent classification result. Based on the routing decision instruction, the corresponding process scheduling operation is executed to route the workflow to the corresponding target intelligent agent graph node.

2. The method according to claim 1, wherein, The unified routing ingress node is configured with a differentiated context policy, which includes at least one of the following: When classifying execution intents, only the current workflow's stage context is injected; When classifying execution intent, filter at least one of the following: user memory data, knowledge base data, and tool list data; For other business execution nodes, inject at least one of the following: complete user memory data, knowledge base data, and tool list data.

3. The method according to claim 1 or 2, wherein, The human-computer interaction request includes a free text interaction request input by the user; The step of responding to a human-computer interaction request triggered during workflow execution and directing the human-computer interaction request to a preset unified routing entry node includes: In response to a triggered free text interaction request, the type of the current human intervention node is captured, and the type of the human intervention node is written into the corresponding data slot; Clear the manual intervention waiting status indicator of the current workflow and redirect the free text interaction request to the unified routing entry node.

4. The method according to any one of claims 1-3, wherein, The step of classifying the human-computer interaction request based on the current workflow stage context through the unified routing entry node, and generating routing decision instructions based on the intent classification results, includes: The human-computer interaction request and the current workflow stage context are input into a large language model for intent classification to obtain the intent classification result; Based on the human-computer interaction request and the stage context of the current workflow, business semantic parameters corresponding to the intent classification result are extracted, and the intent classification result and the business semantic parameters are used as the routing decision instruction.

5. The method according to claim 4, wherein, After extracting the business semantic parameters corresponding to the intent classification result based on the human-computer interaction request and the stage context of the current workflow, the method further includes: The extracted business semantic parameters are written into the corresponding data slots, and parameter protection operations are performed.

6. The method according to claim 5, wherein, The extracted business semantic parameters are written into the corresponding data slots, and parameter protection operations are performed, including: Mark the workflow key fields in the data slot as read-only; In the prompt words input to the large language model, the large language model is limited to extracting the business semantic parameters only from the currently received human-computer interaction request; The business semantic parameters are updated using a data slot overwrite method.

7. The method according to any one of claims 1-6, wherein, The step of executing the corresponding process scheduling operation according to the routing decision instruction to route the workflow to the corresponding target intelligent agent graph node specifically includes: Using a preset conditional edge function, the workflow is redirected to the target intelligent agent graph node based on the intent classification result and business semantic parameters in the routing decision instruction.

8. The method according to any one of claims 1-7, wherein, The workflow includes a main agent graph and at least one layer of sub-agent graphs; both the main agent graph and the sub-agent graphs contain at least one agent graph node; the agent graph node includes at least one of a unified routing entry node, a manual intervention node, and a business execution node.

9. The method according to claim 8, wherein, The method further includes: When the sub-agent graph reaches the human intervention node and triggers a workflow pause operation, the sub-graph scope checkpoint corresponding to the sub-agent graph is saved. The identifier and pause state of the sub-agent graph are reported to the main agent graph as bubbling states; The main agent graph stores main graph checkpoints containing the bubbling state; If the workflow needs to be restored, the workflow is continued by loading the subgraph scope checkpoint corresponding to the sub-agent graph based on the identifier of the sub-agent graph saved in the main graph checkpoint.

10. The method according to claim 9, wherein, After the main agent graph saves the main graph checkpoints containing the bubbling state, the method further includes, in the event that the workflow needs to be resumed, loading the subgraph scope checkpoints corresponding to the sub-agent graph based on the identifiers of the sub-agent graphs saved in the main graph checkpoints, and before continuing the workflow based on the paused state: Load the subgraph scope checkpoint of the sub-agent graph and merge the latest data slot data of the main agent graph into the subgraph scope checkpoint.

11. The method according to any one of claims 1-10, wherein, Before classifying the human-computer interaction request based on the current workflow stage context through the unified routing entry node, and generating a routing decision instruction based on the intent classification result, the method further includes: Read the preset task status slots to check if there are any unfinished asynchronous tasks. In response to the detection of an incomplete asynchronous task, the human-computer interaction request is routed to the response processing in the current stage.

12. The method according to claim 11, wherein, In response to detecting an incomplete asynchronous task, after routing the human-computer interaction request to the response processing within the current stage, the method further includes: When a human-computer interaction request is received again in the same session, query the asynchronous task status recorded in the preset persistent storage; If the asynchronous task has been completed, the completion result of the asynchronous task is updated to the task status slot, and the workflow is triggered to resume execution.

13. The method according to any one of claims 1-12, wherein, The method further includes: By using the mutex lock corresponding to the session identifier, multiple human-computer interaction requests in the same session are serialized.

14. The method according to any one of claims 1-13, wherein, The method further includes: When the workflow is paused, the business execution node executing the workflow releases its state in memory and persists the graph state of the current workflow to a preset graph state storage checkpoint.

15. The method according to any one of claims 1-14, wherein, The method further includes: If a new human-computer interaction request is received, a new execution token is assigned to the human-computer interaction request; If the business execution node currently executing the workflow detects that the execution token it currently holds is inconsistent with the newly generated execution token, it is determined that the token is lost. Pause the current execution and save the graph state of the workflow to a preset graph state storage checkpoint.

16. A scheduling device for an intelligent agent system, wherein, The device includes: The unified routing module is used to respond to human-computer interaction requests triggered during workflow execution and direct the human-computer interaction requests to a preset unified routing entry node; The intent classification module is used to classify the human-computer interaction request based on the current workflow stage context through the unified routing entry node, and generate routing decision instructions based on the intent classification results. The routing and scheduling module is used to execute the corresponding process scheduling operation according to the routing decision instruction, and to route the workflow to the corresponding target intelligent agent graph node.

17. 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 executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-15.

18. 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-15.

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

Images