Task flow execution method, device and electronic equipment

Abstract

The present application provides a task flow execution method, device and electronic equipment, comprising: obtaining state transition rules and jump control strategies corresponding to a task flow; in response to user interaction data, executing a first processing branch and a second processing branch; in the first processing branch, continuing the business execution of the current task node by taking the user interaction data as input parameters; in the second processing branch, processing the user interaction data by using an intent recognition model to identify the target jump intent of the user and the target task node; if the target jump intent is identified, verifying the target jump intent based on the jump control strategy; if the verification is passed, jumping to the target task node; if the verification is not passed, flowing to the next task node according to the business output result and the state transition rules. Under the premise of greatly improving the flexibility of human-computer interaction, data confusion or program crash is effectively avoided, and the safety and stability of the underlying business flow are guaranteed.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of artificial intelligence technology, and in particular to a task flow execution method, apparatus, and electronic device. Background Technology

[0002] Thanks to the rapid development of Large Language Model (LLM) technology, existing single agents already possess relatively mature reasoning and action, reflection, and planning-execution capabilities. A single agent can complete relatively complex tasks through prompt engineering, toolsets, and contextual information. However, when handling highly complex engineering tasks (such as intelligent interactive form filling, intelligent operation and maintenance automation, and audit report generation), it is usually necessary to break down complex tasks and establish an automated task workflow through the hybrid orchestration and collaborative connection of multiple agents and specific functional modules.

[0003] Currently, the industry mainly relies on two solutions to build intelligent agent task flows.

[0004] The first method relies on configuring fixed rules for task flow. This method mainly controls the flow between task nodes by configuring fixed jump rules containing preset purposes and conditional jump rules based on context state judgment.

[0005] The second approach relies on intelligent agents to dynamically build workflows. An intelligent agent collaboration module, driven by a large language model, creates and automatically reconstructs the workflow structure in real time.

[0006] However, the aforementioned existing technologies face the following insurmountable technical defects in practical engineering applications: First, the process of dynamically generating task flows based on large models is affected by its "illusion" characteristics. When faced with highly deterministic tasks, it is prone to logical architecture errors and lacks security and business rigor. Second, the traditional configuration-based task flow is rigid and inflexible. It cannot support flexible human-computer dialogue intervention during execution, nor can it respond to user intentions to dynamically interrupt and jump across nodes. Summary of the Invention

[0007] This specification provides a task flow execution method, apparatus, and electronic device, which significantly improves the flexibility of human-computer interaction, effectively avoids data chaos or program crashes, and ensures the security and stability of underlying business processes.

[0008] One aspect of this specification provides a task flow execution method, including: Obtain the state transition rules and jump control strategies corresponding to the task flow, wherein the jump control strategies include verification conditions for jumps to task nodes; During the execution of the current task node, in response to the received user interaction data, a first processing branch and a second processing branch are executed respectively; wherein, in the first processing branch, the user interaction data is used as input parameters to continue the business execution of the current task node; in the second processing branch, the user interaction data is processed using an intent recognition model to identify the user's target jump intent and the target task node; If the target redirection intent is identified, the target redirection intent is validated based on the redirection control policy; If the verification passes, the execution of the business in the first processing branch is interrupted, and the current task flow is forced to jump to the target task node; If the verification fails, the jump intention is rejected. After the current task node of the first processing branch has completed execution and generated the business output result, the process flows to the next task node according to the business output result and the state transition rule.

[0009] Furthermore, the jump control policy includes an exclusive execution flag configured on the task node, and a jump restriction list defining the mapping of prohibited jump relationships between nodes; the verification of the target jump intent based on the jump control policy includes: Check if the current task node has an active exclusive execution flag; Based on the mapping of prohibited jump relationships between nodes in the jump restriction list, check whether the target task node belongs to the range of nodes that are prohibited from being directly jumped into by the current task node; If the current task node does not have an active exclusive execution flag, and the target task node is not among the nodes that are prohibited from being directly jumped to by the current task node, then the verification is deemed to have passed; otherwise, the verification is deemed to have failed.

[0010] Furthermore, the step of transferring the data to the next task node based on the business output result and the state transition rules includes: The business output result is matched and judged with the subtask triggering condition corresponding to the current task node; If a match is found, the subtask flow configuration information corresponding to the subtask triggering condition is parsed, and the subtask node set and the corresponding sub-state transition rule are extracted. The set of subtask nodes and the sub-state transition rules are dynamically merged into the currently acquired state transition rules for path reconstruction, and the starting node in the set of subtask nodes is used as the next task node in the flow.

[0011] Furthermore, the step of using the user interaction data as input parameters to continue the business execution of the current task node includes: Identify the types of functional components pre-attached to the current task node; If the functional component type is indicated as a deterministic function, then the corresponding system function is loaded according to the input parameters to generate the business output result, and the format of the business output result is validated. If the functional component type is indicated as a large language model agent, then the prompt word template and tool table corresponding to the current task node are loaded, and the large language model agent is called to process the input parameters to generate the business output result.

[0012] Furthermore, the step of processing the user interaction data using an intent recognition model to identify the user's target navigation intent and target task node includes: The intent recognition model is invoked to perform semantic parsing on the user interaction data, and the corresponding structured intent data is output. Verify whether the structured intent data carries a task status exit instruction; If the task status exit instruction is carried, the target jump intention and the target task node to which it points are extracted from the structured intent data.

[0013] Furthermore, before obtaining the state transition rules and jump control strategies corresponding to the task flow, the method further includes: Load the configurable task flow file and parse and extract the task node list and flow constraint field from the configurable task flow file; Based on the task node list and the flow constraint field, a finite state machine with legal state transition mapping relationships is established through directed graph mapping to generate the state transition rules. The security control configuration section in the configurable task flow file is parsed to extract the node-level jump restriction list or exclusive execution flag to generate the jump control policy.

[0014] Further, the loading of the prompt word template and tool table corresponding to the current task node, and the invocation of the large language model agent to process the input parameters to generate the business output result, includes: Obtain the output format constraint specifications and the maximum iteration count threshold associated with the current task node; Based on the prompt word template, the input parameters, and the tool table, an inference scheduling task for a large language model is initiated. During the execution of the inference scheduling task, the iteration parameters are monitored in real time. If the number of scheduling rounds exceeds the maximum number of iterations threshold, or if the generated interim results fail to pass the verification of the output format constraint specification, an anomaly interception defense is triggered. If result data that conforms to the output format constraint specification is obtained within the maximum number of iterations threshold, it is confirmed as the business output result.

[0015] Furthermore, after the process proceeds to the next task node based on the business output result and the state transition rule, the method further includes: Determine whether the next task node reached by the flow is a preset task flow end node; If it is determined to be a non-ending node, then the next task node is taken as the new current task node, and a new task flow cycle begins. If it is determined to be an end node, the task flow is terminated and the overall task result is output.

[0016] On the other hand, a task flow execution device is provided, comprising: The acquisition module is used to acquire the state transition rules and jump control strategies corresponding to the task flow. The jump control strategies include verification conditions for jumps to task nodes. The first execution module is used to execute a first processing branch and a second processing branch respectively in response to received user interaction data during the execution of the current task node; wherein, in the first processing branch, the user interaction data is used as input parameters to continue the business execution of the current task node; in the second processing branch, the user interaction data is processed using an intent recognition model to identify the user's target jump intent and the target task node; The verification module is used to verify the target redirection intent based on the redirection control policy if the target redirection intent is identified. The jump module is used to interrupt the business execution of the first processing branch and force the current task flow to jump to the target task node if the verification passes. The execution module is used to reject the jump intention if the verification fails, and after the current task node of the first processing branch has been executed and the business output result has been generated, it flows to the next task node according to the business output result and the state transition rule.

[0017] On the other hand, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the above-described method.

[0018] On the other hand, embodiments of this specification also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0019] On the other hand, embodiments of this specification also provide a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method.

[0020] The following beneficial technical effects can be achieved by using the embodiments of this specification: By introducing parallel branches for regular business processing and intent recognition during task node execution, dynamic human-machine intervention capabilities are achieved during the task flow without altering the basic task functional logic. When a user requests a business change midway through the process, the system can accurately identify and process their state transition intent, overcoming the lack of interactive intervention mechanisms in traditional static task flows.

[0021] Meanwhile, a mandatory state verification mechanism during the execution phase is used to establish security protection. This ensures that while introducing the natural interaction flexibility of the large language model, jump requests that violate core business constraints are intercepted, preventing context data breaks, program deadlocks, and business logic crashes caused by arbitrarily crossing nodes. This solution, while ensuring the rigor of software workflow and data security, meets the flexible operation needs of users in complex business scenarios, significantly improving the fault tolerance and overall operational stability of hybrid orchestration-based intelligent agent task flows in response to unexpected situations.

[0022] In addition to the technical problems solved by at least one embodiment of this application, the technical features constituting the technical solution, and the beneficial effects brought about by the technical features of these technical solutions as described above, other technical problems that can be solved by at least one embodiment of this application, other technical features included in the technical solution, and the beneficial effects brought about by these technical features will be further described in detail in the specific embodiments. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This specification shows a flowchart illustrating a task flow execution method provided in an embodiment. Figure 2This document illustrates a flowchart of a method for performing verification on a target redirection intent, as provided in an embodiment of this specification. Figure 3 This specification illustrates a flowchart of a method for triggering subtask execution according to an embodiment. Figure 4 This specification illustrates a flowchart of a service execution process for the current task node provided in an embodiment. Figure 5 This document illustrates a flowchart of the initialization process for rules and control strategies provided in an embodiment of this specification. Figure 6 This specification illustrates a flowchart of a process for generating business output results, as provided in an embodiment. Figure 7 A schematic diagram of a task flow execution apparatus provided in an embodiment of this specification is shown; Figure 8 A schematic diagram of a computer device provided in an embodiment of this specification is shown.

[0024] [Explanation of Figure Markers]: 701. Acquisition Module; 702. First Execution Module; 703. Verification module; 704, Jump Module; 705. Second Execution Module; 802. Computer equipment; 804. Processing equipment; 806. Storage resources; 808. Drive mechanism; 810. Input / Output Module; 812. Input devices; 814. Output devices; 816. Presentation equipment; 818. Graphical User Interface; 820. Network interface; 822. Communication link; 824. Communication bus. Detailed Implementation

[0025] The present specification will now be described in detail with reference to the specific embodiments shown in the accompanying drawings. However, these embodiments do not limit the scope of this specification, and any structural, methodological, or functional modifications made by those skilled in the art based on these embodiments are included within the scope of protection of this specification.

[0026] It should be understood that in the description of the specific embodiments in this specification, terms such as "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature.

[0027] In the specific embodiments described in this specification, unless otherwise explicitly stated and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a movable connection, a detachable connection, or an integral part; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this specification according to the specific circumstances.

[0028] In the specific embodiments described herein, unless otherwise expressly specified and limited, the term "above" or "below" the second feature may include direct contact between the first and second features, or contact between the first and second features not in direct contact but through another feature between them.

[0029] In the specific implementation of this specification, unless otherwise expressly specified and limited, the term "more" means two or more.

[0030] This specification provides the operational steps of the methods described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the methods shown in the embodiments or drawings can be executed sequentially or in parallel.

[0031] In related technologies, the following drawbacks exist in building intelligent agent task flows within the industry: First, the process of dynamically creating task flows based heavily on large models presents risks to rigor and security. Large language models are essentially probabilistic generative models, inevitably exhibiting "illusion" phenomena during automatic orchestration and reconstruction of nodes. When faced with tasks requiring extremely high determinism, task flows created freely by agents are prone to flawed business logic or architectural inconsistencies, leading to inaccurate and uncontrollable task results. Furthermore, existing dynamic frameworks have complex internal architectures, high coupling, and significant communication overhead; failure of any single module can cause the entire workflow to collapse.

[0032] Secondly, existing configuration-based task flows lack flexible human-computer interaction intervention and dynamic state transition mechanisms during operation. Once the flow rules of the underlying agent's atomic capabilities are statically configured and activated, the system can only rigidly execute according to fixed paths or preset context conditions. When encountering situations where user dialogue interaction needs to be introduced midway through task execution, or when user intent changes and requires a forced interruption of the current step and a jump to a specific historical / previous state node, the existing system cannot provide effective technical support.

[0033] To address the aforementioned technical problems, embodiments of this specification provide a task flow execution method. To make the objectives, technical solutions, and advantages of this application clearer, before specifically describing the task flow execution method provided in the embodiments of this specification, a brief description of the overall system architecture upon which this method is based will first be given.

[0034] The overall system solution upon which the embodiments in this specification are based is divided into, from front to back, an interaction layer, a core operation layer, a parsing and loading layer, and a configuration layer. The specific operational logic and functional component coordination of each layer are described below: (1) Configuration layer The configuration layer is responsible for providing highly configurable underlying data support, primarily by pre-defining the task flow framework through configuration files (such as YAML format). To meet complex business scenarios, the configuration layer supports separate, deep configuration, specifically including: Independent configuration of main and sub-flows: Supports the compilation of the main task flow. For dynamic scenarios where the branch direction can only be confirmed after running the main flow and obtaining the result, it supports the independent mounting configuration of sub-task flows.

[0035] Perception Module Configuration: Supports defining independent configuration files for intent recognition modules (such as intent recognition agents or independent intent recognition models) that undertake state perception tasks.

[0036] Access control security configuration: Configure the mandatory isolation attribute for task nodes. For critical nodes that do not support arbitrary jumping, a "jump restriction list" can be defined at the configuration layer; for specific nodes that are currently running and must not be interrupted by external conversations, an "exclusive execution flag" can be configured at the configuration layer to implement underlying jump permission control.

[0037] (2) Parse the loading layer

[0038] The parsing and loading layer acts as a hub connecting static configuration and dynamic execution, performing syntax and semantic parsing of the configuration file. Specifically, this parsing includes obtaining the state transition relationships between nodes within the task flow, flow constraints, and subtask association mappings. Simultaneously, this layer is responsible for deep parsing of the action attributes associated with nodes (including action type, output format specifications, and output parameters).

[0039] Depending on the type of action, the parsing loading layer performs dual-track loading: for deterministic static applications, it dynamically loads the underlying system functions based on the function names in the configuration file; for non-deterministic semantic interaction applications, it loads and instantiates the large language model and the corresponding general atomic intelligent agent class static information, providing a basic support environment for subsequent task flow.

[0040] (3) Interaction layer

[0041] As the business front end of human-computer interaction, the interaction layer is responsible for capturing the user's interaction data and original intent input throughout the entire process. It is also responsible for visualizing and confirming the node status, interaction information checklist, confirmation instructions, and business calculation results generated by the core operation layer.

[0042] (4) Core operating layer

[0043] The core operating layer is the central layer of this technical solution, encompassing five core components that work together: Finite State Machine (FSM), Intent Recognition Module, State Transition Control Module, Function Execution Unit, and Intelligent Agent Module.

[0044] 4.1 Intent Recognition Module: Throughout the task flow, this module is responsible for sensing and capturing whether the user has an explicit intent to jump across nodes (for example, if the current stage is "Node 4 - Financial Approval", the user actively enters a request to jump back to "Node 2 - Re-enter the form"). This module does not participate in business processing, but only focuses on the accurate extraction of user status perception and jump intent.

[0045] 4.2 State Transition Control Module: This module integrates two information sources: first, it receives regular "finite state machine underlying state transition requests" occurring during the interaction and flow process; second, it receives abnormal "jump-out requests" parsed and transmitted by the aforementioned "intent recognition module." This control module uses the exclusive execution flag (token ring) configured in the backend and the jump restriction list as security verification boundaries to determine whether to intercept or allow the aforementioned jump requests, strictly preventing illegal state transitions or those that could lead to business deadlock.

[0046] 4.3 Function Execution Unit: For deterministic nodes with strong structure and strong computational logic in the task flow (action type is system function), it is responsible for completing the computation derivation based on the dynamic function body and execution parameters passed in from the parsing loading layer.

[0047] 4.4 Intelligent Agent Module: For weakly structured nodes in the task flow that require reasoning and decision analysis, the module loads the prompt word templates, toolsets, and contextual background information bound to the node, executes large language model instantiation and reasoning scheduling, thereby dynamically completing the fuzzy task of the specific node and outputting standardized generated results.

[0048] Based on the above-mentioned overall system architecture, the task flow execution method in the embodiments of this specification will be further described in detail below.

[0049] To facilitate understanding, let's first explain task flow. Task flow can be understood as a directed flowchart that combines multiple discrete processing steps according to specific business logic and sequential dependencies to achieve a complete business objective. In a task flow, each discrete processing step corresponds to a specific "task node," responsible for handling a particular segment of business logic.

[0050] Taking a banking business scenario as an example, let's establish an "automatic approval task flow for online credit card applications". The starting point of this task flow can be the "facial recognition and document verification" node to obtain user information; after successful verification, it flows to the "central bank credit data retrieval" node (which acts as a deterministic function component to query and calculate credit scores); then it flows to the "risk control model evaluation" node (which can act as a large language model intelligent agent component to deeply analyze whether there is an abnormal correlation between the user's occupation and recent bank statements); finally, it converges to the "credit limit generation and card issuance" node to give the final credit limit.

[0051] For example, consider constructing a "task flow for appealing account freezes due to abnormal transactions." The node sequence is as follows: an "identity authentication verification" node requiring the user to enter their password; an "abnormal record parsing" node that calls a large model to analyze the appeal reasons; a conditional judgment branch that triggers triage based on the risk level of the parsed data; a high-risk transfer to the "human agent intervention" node / a low-risk transfer to the "system automatic unfreezing" node; and finally, an ending node where the task is completed and a notification is sent. These nodes and the connections between them together constitute a closed-loop bank task flow.

[0052] The methods provided in the embodiments of this specification can be executed by an electronic device with data computing, storage, and logic processing capabilities. Specifically, this electronic device may be a backend server, a cloud computing node, a personal computer device, or a mobile terminal, etc. For the sake of generality and ease of description, the electronic device will be consistently used as the subject performing the actions in the following embodiments. See also Figure 1 The method includes the following steps: Step 101: Obtain the state transition rules and jump control strategy corresponding to the task flow, wherein the jump control strategy includes the verification conditions for jumps to task nodes; Step 102: During the execution of the current task node, in response to the received user interaction data, execute the first processing branch and the second processing branch respectively; wherein, in the first processing branch, the user interaction data is used as input parameters to continue the business execution of the current task node; in the second processing branch, the user interaction data is processed using an intent recognition model to identify the user's target jump intent and the target task node; Step 103: If the target redirection intention is identified, the target redirection intention is verified based on the redirection control policy.

[0053] If the verification passes, proceed to step 104; if the verification fails, proceed to step 105.

[0054] Step 104: Interrupt the execution of the first processing branch and force the current task flow to jump to the target task node; Step 105: Reject the jump intention. After the current task node of the first processing branch has completed execution and generated business output results, the process flows to the next task node according to the business output results and the state transition rules.

[0055] Specifically, the electronic device first obtains the state transition rules and jump control policies corresponding to the task flow. The task flow consists of pre-configured task nodes and flow logic. The state transition rules limit the legal flow between task nodes and their triggering conditions. The jump control policy includes verification conditions for task node jumps. These verification conditions are used to determine whether there are security constraints that prevent specific task nodes from being forcibly jumped out or directly jumped into during the lifecycle of the task flow.

[0056] While the current task node is running, the electronic device receives user interaction data input by the user. In response to the received user interaction data, the electronic device initiates a dual-branch processing mechanism in parallel within the underlying computing environment, executing the first processing branch and the second processing branch respectively.

[0057] During the execution of the first processing branch, the electronic device uses the acquired user interaction data as input parameters for the underlying action code of the current task node. Since the current task node may be in a suspended or blocked state while waiting for external input feedback, the admission of the input parameters triggers the current task node to continue to launch its own business logic code to perform calculations, thus advancing the business flow process of the current task node.

[0058] Simultaneously, during the execution of the second processing branch, the electronic device uses an independently invoked intent recognition model to process the user interaction data synchronously. The intent recognition model extracts and matches features from the natural language semantic dimension of the text content to determine whether the user interaction data contains intervention instructions that deviate from the normal operating trajectory of the current task node, thereby identifying the user's target jump intent and the target task node explicitly pointed to by that intent.

[0059] If the electronic device identifies a target jump intention in the second processing branch, it extracts the target task node and performs a state validity check on the target jump intention based on the pre-acquired jump control policy. The check process involves determining whether the state transition relationship between the current task node and the target task node satisfies the security constraint logic defined in the jump control policy.

[0060] If the verification passes, it indicates that the cross-node jump request is within the scope of legal permissions. The electronic device then triggers the underlying system interrupt mechanism, forcibly suspending the execution progress of the business code currently being executed on the current task node in the first processing branch. For example, it cleans up the temporary data generated by the current execution stack, resets the run pointer, forcibly jumps the current task flow execution path to the target task node, and then starts the initialization steps corresponding to the target task node.

[0061] If the verification fails, it indicates that the jump request violates the security restrictions set in the jump control policy (e.g., the current task node is configured to be uninterruptible, or the target task node is a node that is prohibited from being jumped to from the current task node). The electronic device will then refuse to process the jump intent command. After skipping the illegal jump request, the electronic device ensures the original operational continuity of the first processing branch, waiting for the current task node in the first processing branch to complete the full calculation of the business logic code in conjunction with the user interaction data, and finally generate the business output result. After the business output result is generated, the electronic device extracts the business output result, retrieves the matching flow trigger path in its corresponding state transition rules, and automatically flows to the next task node pointed to by the path according to the standard operating logic of the finite state machine.

[0062] The task flow execution method provided in the embodiments of this specification can achieve the following beneficial technical effects: By introducing parallel branches for regular business processing and intent recognition during task node execution, dynamic human-machine intervention capabilities are achieved during the task flow without altering the basic task functional logic. When a user requests a business change midway through the process, the system can accurately identify and process their state transition intent, overcoming the lack of interactive intervention mechanisms in traditional static task flows.

[0063] Meanwhile, a mandatory state verification mechanism during the execution phase is used to establish security protection. This ensures that while introducing the natural interaction flexibility of the large language model, jump requests that violate core business constraints are intercepted, preventing context data breaks, program deadlocks, and business logic crashes caused by arbitrarily crossing nodes. This solution, while ensuring the rigor of software workflow and data security, meets the flexible operation needs of users in complex business scenarios, significantly improving the fault tolerance and overall operational stability of hybrid orchestration-based intelligent agent task flows in response to unexpected situations.

[0064] In some embodiments of this specification, to further ensure the legitimacy of the task flow state during cross-stage transitions, the jump control strategy constrains the process from two dimensions: preventing interruption of the task itself and preventing jumps into the target. Specifically, the jump control strategy includes an exclusive execution flag configured on the task node and a jump restriction list that defines the prohibited jump relationship mapping between nodes. The exclusive execution flag, as a node-level state lock, is typically configured on specific task nodes that are performing sensitive data writing or need to maintain business continuity without interruption. The jump restriction list, in the form of a data dictionary or mapping matrix, records start and end node pairs that lack necessary prior business support and are prohibited from direct crossing.

[0065] Accordingly, see Figure 2 The target redirection intent is validated based on the redirection control policy, including the following steps: Step 201: Check whether the current task node has an active exclusive execution flag; Step 202: Based on the mapping of prohibited jump relationships between nodes in the jump restriction list, check whether the target task node belongs to the range of nodes that are prohibited from being directly jumped into by the current task node; Step 203: If the current task node does not have an active exclusive execution flag, and the target task node is not in the range of nodes that are prohibited from being directly jumped to by the current task node, then the verification is determined to be successful; otherwise, the verification is determined to be unsuccessful.

[0066] For example, the electronic device reads the runtime attributes of the current task node and checks whether the current task node has an active exclusive execution flag. This step is used to determine whether the current task node is holding underlying flow control. Once the value of the exclusive execution flag is set to active, it indicates that the current program's runtime cycle must be strictly protected, and responses to outward state jumps caused by the node's internal processes are prohibited.

[0067] The following example illustrates the situation where the exclusive execution flag is in effect.

[0068] As an example, if an electronic device suddenly terminates the process and jumps to another node while performing cross-table data joins and updates bill status, it could easily lead to a serious failure due to inconsistent fund status. Therefore, jumping is not allowed during the execution lifecycle of this write operation. So, when the "database transaction commit" node is launched, the electronic device sets its associated exclusive execution flag to be active, forcibly blocking any external intentional jump requests until the database transaction is committed and resources are released, at which point the flag is reset to inactive.

[0069] As another example, for a current task node performing "core report file generation," if an interruption occurs during the file stream writing process—where the electronic device is writing the multidimensional data results aggregated in memory to physical storage—the resulting physical file structure may be corrupted or its content truncated. Therefore, to ensure the integrity of the output file, skipping is not allowed during this process, so the exclusive execution flag attached to this node is set to be active.

[0070] In addition, the electronic device performs a second level of checks based on the prohibited jump relationship mapping between nodes in the jump restriction list. The electronic device takes the current task node in the first processing branch as the starting object and the target task node parsed from the second processing branch as the pointing object, and queries the jump restriction list to see if there is a prohibited mapping rule from the current task node to the target task node, so as to check whether the target task node belongs to the node range that is prohibited from being directly jumped to from the current task node.

[0071] Based on the verification results of the above two inspection processes, if the electronic device confirms that there is no exclusive execution flag in the current task node's attributes that is in an active state, meaning that the current task node is allowed to be suspended or interrupted, and the corresponding prohibited mapping relationship is not matched in the jump restriction list, meaning that the target task node does not belong to the range of nodes that are prohibited from being directly jumped into by the current task node, then the verification of the target jump intention is deemed to have passed.

[0072] Otherwise, if the electronic device detects that the current task node has an active exclusive execution flag, or finds a prohibited jump mapping relationship between the two in the jump restriction list, the electronic device will determine that the verification of the target jump intention has failed as long as either restriction trigger condition is met. The electronic device will then discard the cross-stage jump request and keep the control flow suspended in the first processing branch.

[0073] As can be seen, this embodiment employs a two-layer combined verification method, combining an exclusive execution flag and a jump restriction list. On one hand, the exclusive execution flag effectively protects the stable execution of high-priority or critical irreversible actions, preventing business errors caused by users arbitrarily jumping out of the system. On the other hand, the jump restriction list blocks non-compliant business traversal paths, preventing subsequent workflows from lacking contextual support due to bypassing necessary prerequisite nodes. This control strategy precisely decentralizes security restrictions to specific node mapping relationships and real-time operational status, replacing complex hard-coded constraints with objective and configurable data structures. This significantly improves the system's ability to automatically intercept invalid intentions or high-risk intervention behaviors, while ensuring that the underlying state evolution logic of the entire task flow system remains within strict security boundaries despite its high degree of interactive freedom.

[0074] In some embodiments of this specification, considering that in actual business scenarios, the subsequent paths of certain task nodes cannot be statically and uniquely fixed in the early stages of task flow initiation, it is necessary to dynamically attach lower-level processes based on the real-time output data generated by the node's operation. To meet the above requirements, this embodiment provides a specific design for the process of flowing to the next task node based on business output results and state transition rules. See details. Figure 3 Based on the business output results and the state transition rules, the process flows to the next task node, including: Step 301: Match the business output result with the subtask triggering condition corresponding to the current task node; Step 302: If a match is found, parse the subtask flow configuration information corresponding to the subtask triggering condition, and extract the subtask node set and the corresponding sub-state transition rules; Step 303: Dynamically merge the set of subtask nodes and the sub-state transition rules into the currently acquired state transition rules for path reconstruction, and use the starting node in the set of subtask nodes as the next task node to be transferred.

[0075] Specifically, the electronic device extracts the business output results generated after the first processing branch is completed, reads the pre-configured subtask trigger conditions of the current task node, and performs cross-comparison and matching judgment between the business output results and the corresponding subtask trigger conditions of the current task node. In actual execution, this matching judgment process can be to perform regular expression validation on the standard fields in the business output results, or to determine the output values ​​using relational operators or threshold ranges, in order to verify whether the output characteristics meet the startup requirements of a specific lower-level business branch.

[0076] If the electronic device matches the given condition based on computation, it indicates that the current task flow has the prerequisite for deriving specific sub-level business logic. The electronic device parses the sub-task flow configuration information corresponding to the triggering condition of this sub-task. By parsing the configuration information entity (e.g., a data structure in XML, JSON, or YAML format), it extracts all the node structures that constitute the subordinate business logic to form a sub-task node set, and simultaneously extracts the sub-state transition rules used to limit the dependencies and execution order of each node in this set.

[0077] After completing the above parsing and extraction, the electronic device dynamically integrates the extracted subtask node set and sub-state transition rules as new content into the currently acquired state transition rules. This process involves reconstructing the paths of the directed edges and node topology of the original state machine, seamlessly integrating the sub-processes into the main process framework.

[0078] After the path reconstruction operation takes effect, the electronic device extracts the starting node of the first execution stage in the set of subtask nodes and determines the starting node as the next task node for the current task flow to continue downward.

[0079] To further illustrate the process of dynamic matching and real-time path reconstruction, we will take the IT automated operation and maintenance troubleshooting scenario as an example.

[0080] For example, suppose the current task node is a "server network status detection" node, whose main process is originally planned to transition to the daily data synchronization node after the detection is completed. After the electronic device executes the instructions of the current task node, it generates a detection log containing a specific packet loss rate status code as the business output result. Subsequently, the electronic device matches this business output result with various pre-configured exception sub-task triggering conditions of the current task node (such as a preset packet loss rate greater than 80%) for judgment.

[0081] If the electronic device identifies a packet loss rate of 95% in the service output, thus matching the above conditions, it indicates a severe network blockage on the current server, requiring immediate in-depth diagnostics and preventing the continuation of the original data synchronization main process. At this point, the electronic device parses the subtask flow configuration information (i.e., pre-configured subtask flows specifically designed to handle high packet loss) corresponding to the "high packet loss rate" trigger condition from the policy library. It extracts a set of subtask nodes, such as "capture system routing table," "execute network card driver reset," and "generate and push diagnostic report," and simultaneously extracts sub-state transition rules that define the dependencies between these three nodes.

[0082] Next, the electronic device uses the extracted set of subtask nodes and sub-state transition rules as a new exception handling branch, dynamically merging them into the currently acquired main process state transition rules in the current running memory for path reconstruction. Due to the path reconstruction, the electronic device blocks the flow action that originally pointed to the daily data synchronization node, and determines the starting node (i.e., the "capture system routing table" node) that plays the role of pre-collection in the set of subtask nodes as the next task node in the current task flow, thereby completing the dynamic switch from daily inspection to in-depth diagnosis.

[0083] As can be seen, in this embodiment, by associating the real-time business output results of nodes with the conditional triggering of subtask flows, the static task flow is given the ability to dynamically extend and reconstruct its topology during the runtime phase. This execution logic breaks the limitation of traditional process engines that must exhaustively enumerate all possible branches in static configuration, and eliminates the system memory redundancy caused by preloading a large execution flow to accommodate extremely low probability bypass branches.

[0084] Meanwhile, under this scheme, the system only parses specific configuration information and dynamically merges lower-level subtask flow nodes when the corresponding business thresholds or state prerequisites are precisely met, thus achieving on-demand execution of subtask flow nodes. This ensures the continuity of the workflow while providing a lightweight, highly flexible, and easy-to-maintain processing method for handling complex businesses that require multi-level logical judgment and filtering (such as hierarchical approval, multi-condition triggered operation and maintenance troubleshooting sub-processes, etc.).

[0085] To accommodate the varying complexity of computational tasks across different business scenarios, this specification provides examples illustrating the specific execution methods for the current task node. See also... Figure 4 The user interaction data is used as input parameters to continue the business execution of the current task node, including: Step 401: Identify the types of functional components pre-attached to the current task node; Step 402: If the functional component type indicates a deterministic function, then load the corresponding system function according to the input parameters to generate the business output result, and perform format validation on the business output result; Step 403: If the functional component type is indicated as a large language model agent, then load the prompt word template and tool table corresponding to the current task node, and call the large language model agent to process the input parameters to generate the business output result.

[0086] Specifically, the electronic device reads the underlying configuration metadata of the current task node and identifies the types of pre-mounted functional components. The functional component type defines the method of accessing computing resources and the operating mode adopted by the node after receiving input data. Based on the identification results, the electronic device performs one of these two types of operations in the runtime environment.

[0087] If the functional component type is indicated as a deterministic function, it means that the node executes a fixed-rule calculation with a strict mapping between input and output, or an internal standard system microservice call. The electronic device loads the corresponding system function body it is bound to based on the input parameters and allocates a computation thread. The input parameters are passed as arguments to the system function to execute the computation logic, thereby generating a preliminary business output result. Before transmitting this result outwards, the electronic device performs a mandatory format validation operation on this preliminary business output result. This format validation process specifically compares the output content using preset data type mappings, boundary range judgments, or JSON schema checks to confirm the format is valid before accepting it as the final business output result.

[0088] If the functional component type is indicated as a large language model agent, it means that this node is configured to undertake tasks such as natural language understanding, autonomous planning, or unstructured data processing. The electronic device extracts and loads the prompt word template bound to the current task node and its accompanying tool table from a preset business configuration library. The prompt word template defines the system-level instruction context and constraints for this stage, while the tool table contains external interface definitions that allow the model to trigger calls within the node's workflow. Subsequently, the electronic device instantiates a running instance of the agent module in its memory runtime environment, filling the prompt word template with input parameters carrying the user's true intent. This agent module uses a large language model for inference operations, driving the interfaces within the tool table to obtain real-time auxiliary data as needed, and finally integrating the entire inference process to output the corresponding text or structured instructions as the final business output.

[0089] As can be seen, in this embodiment, by identifying the component types of task nodes and providing differentiated branch execution strategies, a single task flow can be used to orchestrate traditional deterministic computational logic and cutting-edge large-scale model generative tasks. For deterministic function nodes, the rigor and accuracy of structured data flow in conventional business processes are strictly guaranteed; while for agent nodes, by standardizing the loading of prompt word templates and tool tables and performing dynamic instantiation, task nodes are endowed with powerful unstructured data processing and autonomous solution capabilities. This hybrid design architecture, which is highly compatible with determinism and flexibility, retains the precise control of state transitions in traditional software engineering while introducing AI agents to improve the flexibility of scenario response, thereby optimizing the execution results of intelligent workflows under heterogeneous and complex business conditions.

[0090] To accurately capture users' cross-process needs in complex dialogue or operational environments, this embodiment details the specific steps for processing user interaction data using an intent recognition model. Processing the user interaction data using the intent recognition model to identify the user's target navigation intent and target task node includes: calling the intent recognition model to perform semantic parsing on the user interaction data and outputting corresponding structured intent data; verifying whether the structured intent data carries a task status exit instruction; if it does, extracting the target navigation intent and the target task node it points to from the structured intent data.

[0091] Specifically, after receiving user interaction data containing natural language features or front-end interface operation behaviors, the electronic device invokes a pre-loaded intent recognition model, inputting the user interaction data into the model for semantic parsing. In practical applications, this intent recognition model can be a pre-trained semantic model based on the Transformer architecture, or a classification extraction network specifically fine-tuned for vertical business domains. The electronic device uses the model's word embedding vector mapping and attention mechanism to calculate and transform the ambiguous expressions in the original user data into a computer-readable standardized format, outputting the corresponding structured intent data. In engineering implementation, the generated structured intent data is usually presented as a JSON sequence or a pre-defined schema structure, which encapsulates standard fields such as intent slots, execution action codes, and confidence scores.

[0092] Subsequently, the electronic device verifies the generated structured intent data to check whether the structured intent data actually carries a task state exit instruction (for example, a boolean value representing a forced interrupt transfer is True).

[0093] If, after verification, the corresponding field is confirmed to carry a task status exit instruction, it indicates that the user's current interaction intent has deviated from the current task node, requiring a business logic jump. Based on this determined result, the electronic device initiates the deep extraction logic of the parsing engine, using algorithms such as entity alignment or mapping relationship comparison to extract the target jump intent and the unique identifier of the specific target task node (such as node ID or Uniform Resource Locator) from the slot parameters of the structured intent data.

[0094] As can be seen, this embodiment can accurately capture user requests initiated temporarily at any stage of the workflow (such as suddenly requesting to "cancel the current form" or "return to the homepage"). This avoids underlying computing resources mistaking user transition inputs (such as voice input) for regular input parameters of the current node, which could lead to logical errors. This improves the parsing accuracy of the workflow engine in handling jumpy dialogue requests and the stability of the process.

[0095] In some embodiments of this specification, in order to ensure that the system can accurately and securely control task flow according to business needs during runtime, it is also necessary to initialize the state transition rules and control strategies before executing task flow orchestration. See also Figure 5 Before obtaining the state transition rules and jump control strategies corresponding to the task flow, the following steps are also included: Step 501: Load the configurable task flow file and parse and extract the task node list and flow constraint fields from the configurable task flow file; Step 502: Based on the task node list and the flow constraint field, a finite state machine with legal state transition mapping relationship is established through directed graph mapping to generate the state transition rules; Step 503: Parse the security control configuration section in the configurable task flow file, extract the node-level jump restriction list or exclusive execution flag, and generate the jump control policy.

[0096] Specifically, the electronic device preloads a configurable task flow file. This configurable task flow file is typically written in a standard declarative text data format such as JSON, YAML, or XML, recording the static topology of the entire business process graph. The electronic device uses an embedded parser to parse and extract the task node list and flow constraint fields from this configurable task flow file. The task node list lists all the identifiers of the computational nodes included in this business orchestration, while the flow constraint fields record declarative information such as the start and end points of connections between nodes and trigger condition thresholds.

[0097] Based on the list of task nodes and the flow constraint field, the electronic device can construct a graph. During graph construction, task nodes are treated as vertices of the graph, and the flow constraint field is interpreted as directed edges connecting these vertices. By traversing these nodes and their connections, a finite state machine with valid state transition mappings is established. This finite state machine is written into memory using underlying data structures (such as an adjacency matrix or a hash routing table).

[0098] Furthermore, the electronic device further parses the configuration file to identify the security control configuration section in the configurable task flow file. It then reads the parameters recorded in this configuration section to extract node-level jump restriction lists or exclusive execution flags bound to specific nodes. The jump restriction list explicitly defines the set of black-box targets prohibited from transferring traffic from a particular node; while the exclusive execution flag declares a strong constraint attribute that prevents external attempts to interrupt a node (such as the payment calculation or data storage stage) during its runtime lifecycle. The electronic device integrates these extracted restrictive parameters into interception rules for verification, thereby generating a jump control strategy tailored to the current task flow to ensure that the business flow proceeds according to regulations.

[0099] As can be seen, in this embodiment, a pre-configured task flow file is read and parsed before the formal execution of the business process. By converting the nodes and conditions in the configuration file into a finite state machine, when the business process is subsequently changed or new steps are added, technical personnel only need to modify the contents of the configuration file, without having to modify the underlying system code, thus improving development efficiency.

[0100] Furthermore, the security control configuration section in the configurable task flow file is parsed to extract node-level jump restriction lists or exclusive execution flags to generate jump control policies. When faced with subsequent user jump requests, this effectively intercepts unreasonable or dangerous jump behaviors, thereby reducing business errors and ensuring the security and stability of business operations.

[0101] In some embodiments of this specification, strict monitoring restrictions are set for the instantiation and inference processes of large language model agents. See details... Figure 6 Load the prompt word template and tool table corresponding to the current task node, and call the large language model agent to process the input parameters to generate the business output result, including: Step 601: Obtain the output format constraint specifications and the maximum iteration count threshold associated with the current task node; Step 602: Initiate an inference scheduling task for a large language model based on the prompt word template, the input parameters, and the tool table; Step 603: During the execution of the inference scheduling task, the iteration parameters are monitored in real time. If the number of scheduling rounds exceeds the maximum number of iterations threshold, or the generated interim results fail to pass the verification of the output format constraint specification, an anomaly interception defense is triggered. If result data that conforms to the output format constraint specification is obtained within the maximum number of iterations threshold, it is confirmed as the business output result.

[0102] Specifically, before executing the instantiation process of the intelligent agent, the electronic device obtains the output format constraint specifications and the maximum iteration count threshold associated with the current task node. The output format constraint specifications define the data structure mapping standards that the application system can correctly parse (e.g., it must contain specific JSON nesting levels, key field types, or specific enumeration identifiers); the maximum iteration count threshold is used to define the highest tolerance limit for the intelligent agent to complete logical thinking and repeatedly call external tools at the current node.

[0103] The electronic device combines and encapsulates the aforementioned loaded prompt word template, input parameters carrying business data, and alternative tool tables to initiate an inference scheduling task for the large language model. During the actual execution of this inference scheduling task, the large language model generates text content, or, when necessary, initiates query requests to external interfaces based on the tool tables for logical correction.

[0104] During this period, the electronic device allocates a dedicated thread in the background to monitor iteration parameters in real time during the execution of the inference scheduling task. Specific monitoring actions include accumulating the number of requests to the large language model tool and the number of self-reflection iterations. If the electronic device detects that the current scheduling round exceeds the maximum iteration count threshold, it indicates that the model has entered an infinite loop or is logically blocked at this step; or if engineering verification algorithms such as regular expression matching reveal that the generated interim results have not passed the output format constraint specifications (e.g., returning a piece of casual text or missing core business code fields), the electronic device immediately terminates the current model inference process and triggers anomaly interception and defense.

[0105] Conversely, if the electronic device monitors the inference process within the maximum iteration count threshold and successfully obtains complete result data that conforms to the output format constraints, it can directly obtain the result data, confirm it as the business output result of the current task node, and allow it to continue advancing the main business flow.

[0106] As can be seen, this embodiment performs real-time monitoring during the model's inference process. If the number of times the model is repeatedly called exceeds the limit, or if the intermediate results do not conform to the predetermined format, an anomaly interception defense is triggered. Only results that meet the standard requirements within the specified number of attempts are recognized by the system as the final result. This successfully integrates the originally somewhat divergent and uncontrollable AI generation capabilities into a rigorous business processing framework, both enhancing the system's business processing capabilities with the help of a large model and ensuring the system's reliability and stability.

[0107] In some embodiments of this specification, after the electronic device moves to the next task node according to the service output results and state transition rules, the electronic device reads the identifier field bound to the next task node and then determines whether the next task node reached is a preset task flow end node.

[0108] If the electronic device determines that the identifier field is not an end feature, that is, it determines that it is a non-end node, and takes the next task node as the new current task node, and enters a new task flow cycle.

[0109] If the electronic device detects that the identifier field matches the end characteristic, it determines it to be an end node, indicating that the preset orchestration logic of the current business main line has been fully executed and closed. This terminates the task flow and outputs the overall task result. For example, the electronic device converts the core business products collected and merged throughout the entire business process into standard protocol packets and outputs the overall task result.

[0110] As can be seen, in this embodiment, when each business operation is completed and the next step is initiated, it is automatically checked whether the new step is the end point of the business process. This ensures that long, multi-step business processes can be executed smoothly and automatically without requiring manual confirmation at each step, while also clearly defining the boundaries for stopping the business process, thus improving the rigor and automation efficiency of the business flow.

[0111] Based on the same inventive concept, embodiments of this specification also provide a task flow execution device, see [link to documentation]. Figure 7 ,include: The acquisition module 701 is used to acquire the state transition rules and jump control strategies corresponding to the task flow, wherein the jump control strategies include verification conditions for jumps to task nodes. The first execution module 702 is used to execute a first processing branch and a second processing branch respectively in response to received user interaction data during the execution of the current task node; wherein, in the first processing branch, the user interaction data is used as input parameters to continue the business execution of the current task node; in the second processing branch, the user interaction data is processed using an intent recognition model to identify the user's target jump intent and the target task node; Verification module 703 is used to verify the target redirection intention based on the redirection control policy if the target redirection intention is identified. The jump module 704 is used to interrupt the business execution of the first processing branch and force the current task flow to jump to the target task node if the verification passes. The second execution module 705 is used to reject the jump intention if the verification fails, and after the current task node of the first processing branch has been executed and the business output result has been generated, it flows to the next task node according to the business output result and the state transition rule.

[0112] The beneficial effects obtained by the above-described device are the same as those obtained by the above-described method, and will not be described in detail in the embodiments of this specification.

[0113] like Figure 8The diagram shown is a structural schematic of a computer device according to an embodiment of this specification. The task flow execution method of this invention can be applied to the computer device in this embodiment. The computer device 802 may include one or more processing devices 804, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads.

[0114] The computer device 802 may also include any storage resource 806 for storing any kind of information such as code, settings, data, etc.

[0115] Non-limiting, for example, storage resource 806 may include any one or more of the following: any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc.

[0116] More generally, any storage resource can use any technology to store information.

[0117] Furthermore, any storage resource can provide volatile or non-volatile retention of information.

[0118] Furthermore, any storage resource can represent a fixed or removable component of the computer device 802.

[0119] In one scenario, when processing device 804 executes associated instructions stored in any storage resource or combination of storage resources, computer device 802 can perform any operation of the associated instructions. Computer device 802 also includes one or more drive mechanisms 808 for interacting with any storage resource, such as hard disk drive mechanisms, optical disk drive mechanisms, etc.

[0120] Computer device 802 may also include an input / output module 810 (I / O) for receiving various inputs (via input device 812) and providing various outputs (via output device 814). A specific output mechanism may include a presentation device 816 and an associated graphical user interface (GUI) 818. In other embodiments, the input / output module 810 (I / O), input device 812, and output device 814 may be omitted, and the device may function solely as a computer device within a network. Computer device 802 may also include one or more network interfaces 820 for exchanging data with other devices via one or more communication links 822. One or more communication buses 824 couple the components described above together.

[0121] Communication link 822 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 822 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0122] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0123] This specification also provides computer-readable instructions, wherein when a processor executes the instructions, the program therein causes the processor to perform the above-described method.

[0124] This specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method.

[0125] It should be understood that in the various embodiments of this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0126] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the embodiments of this specification, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0127] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the embodiments in this specification.

[0128] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0129] In the embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0130] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described in this specification, depending on actual needs.

[0131] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0132] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this specification, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this specification. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0133] This specification describes the principles and implementation methods of the embodiments using specific examples. The above descriptions of the embodiments are only for the purpose of helping to understand the methods and core ideas of the embodiments in this specification. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments in this specification. Therefore, the content of this specification should not be construed as a limitation on the embodiments in this specification.

Claims

1. A task flow execution method, characterized in that, include: Obtain the state transition rules and jump control strategies corresponding to the task flow, wherein the jump control strategies include verification conditions for jumps to task nodes; During the execution of the current task node, in response to the received user interaction data, a first processing branch and a second processing branch are executed respectively; wherein, in the first processing branch, the user interaction data is used as input parameters to continue the business execution of the current task node; in the second processing branch, the user interaction data is processed using an intent recognition model to identify the user's target jump intent and the target task node; If the target redirection intent is identified, the target redirection intent is validated based on the redirection control policy; If the verification passes, the execution of the business in the first processing branch is interrupted, and the current task flow is forced to jump to the target task node; If the verification fails, the jump intention is rejected. After the current task node of the first processing branch has completed execution and generated the business output result, the process flows to the next task node according to the business output result and the state transition rule.

2. The method according to claim 1, characterized in that, The jump control strategy includes an exclusive execution flag configured on the task node, and a jump restriction list that defines the mapping of prohibited jump relationships between nodes; The step of verifying the target redirection intent based on the redirection control policy includes: Check if the current task node has an active exclusive execution flag; Based on the mapping of prohibited jump relationships between nodes in the jump restriction list, check whether the target task node belongs to the range of nodes that are prohibited from being directly jumped into by the current task node; If the current task node does not have an active exclusive execution flag, and the target task node is not among the nodes that are prohibited from being directly jumped to by the current task node, then the verification is deemed to have passed; otherwise, the verification is deemed to have failed.

3. The method according to claim 1, characterized in that, The process of transferring the data to the next task node based on the business output result and the state transition rules includes: The business output result is matched and judged with the subtask triggering condition corresponding to the current task node; If a match is found, the subtask flow configuration information corresponding to the subtask triggering condition is parsed, and the subtask node set and the corresponding sub-state transition rule are extracted. The set of subtask nodes and the sub-state transition rules are dynamically merged into the currently acquired state transition rules for path reconstruction, and the starting node in the set of subtask nodes is used as the next task node in the flow.

4. The method according to claim 1, characterized in that, The step of continuing the business execution of the current task node by using the user interaction data as input parameters includes: Identify the types of functional components pre-attached to the current task node; If the functional component type is indicated as a deterministic function, then the corresponding system function is loaded according to the input parameters to generate the business output result, and the format of the business output result is validated. If the functional component type is indicated as a large language model agent, then the prompt word template and tool table corresponding to the current task node are loaded, and the large language model agent is called to process the input parameters to generate the business output result.

5. The method according to claim 1, characterized in that, The process of using an intent recognition model to process the user interaction data to identify the user's target navigation intent and target task node includes: The intent recognition model is invoked to perform semantic parsing on the user interaction data, and the corresponding structured intent data is output. Verify whether the structured intent data carries a task status exit instruction; If the task status exit instruction is carried, the target jump intention and the target task node to which it points are extracted from the structured intent data.

6. The method according to claim 1, characterized in that, Before obtaining the state transition rules and jump control strategies corresponding to the task flow, the method further includes: Load the configurable task flow file and parse and extract the task node list and flow constraint field from the configurable task flow file; Based on the task node list and the flow constraint field, a finite state machine with legal state transition mapping relationships is established through directed graph mapping to generate the state transition rules. The security control configuration section in the configurable task flow file is parsed to extract the node-level jump restriction list or exclusive execution flag to generate the jump control policy.

7. The method according to claim 4, characterized in that, The process of loading the prompt word template and tool table corresponding to the current task node, and calling the large language model agent to process the input parameters to generate the business output results includes: Obtain the output format constraint specifications and the maximum iteration count threshold associated with the current task node; Based on the prompt word template, the input parameters, and the tool table, an inference scheduling task for a large language model is initiated. During the execution of the inference scheduling task, the iteration parameters are monitored in real time. If the number of scheduling rounds exceeds the maximum number of iterations threshold, or if the generated interim results fail to pass the verification of the output format constraint specification, an anomaly interception defense is triggered. If result data that conforms to the output format constraint specification is obtained within the maximum number of iterations threshold, it is confirmed as the business output result.

8. The method according to claim 1, characterized in that, After the process proceeds to the next task node based on the business output result and the state transition rules, the method further includes: Determine whether the next task node reached by the flow is a preset task flow end node; If it is determined to be a non-ending node, then the next task node is taken as the new current task node, and a new task flow cycle begins. If it is determined to be an end node, the task flow is terminated and the overall task result is output.

9. A task flow execution device, characterized in that, include: The acquisition module is used to acquire the state transition rules and jump control strategies corresponding to the task flow. The jump control strategies include verification conditions for jumps to task nodes. The first execution module is used to execute a first processing branch and a second processing branch respectively in response to received user interaction data during the execution of the current task node; wherein, in the first processing branch, the user interaction data is used as input parameters to continue the business execution of the current task node; in the second processing branch, the user interaction data is processed using an intent recognition model to identify the user's target jump intent and the target task node; The verification module is used to verify the target redirection intent based on the redirection control policy if the target redirection intent is identified. The jump module is used to interrupt the business execution of the first processing branch and force the current task flow to jump to the target task node if the verification passes. The second execution module is used to reject the jump intention if the verification fails, and after the current task node of the first processing branch has been executed and the business output result has been generated, it flows to the next task node according to the business output result and the state transition rule.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 8.

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

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 8.

Images