Method and program product for execution control of business processes

Abstract

The present specification discloses a business process execution control method and program product. A business process state area is previously demarcated in a global state memory, a process stage field, a task item cursor field and a task item state field form a control class field, and a state transition function and a node routing function isolated from a large language model output interface are used for deterministic routing and state updating, while the input context and tool capability of the large language model are limited according to a node-level available field list and an available tool list, so that the large language model is limited to a node internal data operation module, and the risk of process out-of-control caused by a probability model is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of software engineering technology, specifically to a method and program product for controlling the execution of a business process. Background Technology

[0002] With the rapid development of large language model technology, an increasing number of computer systems are embedding large language models into the automated processing of business processes. In typical scenarios, the system needs to complete operations such as information collection, external data querying, parameter generation, and result confirmation one by one according to a preset multi-step task sequence, and wait for user confirmation or approval at some key steps before proceeding to the next step. These scenarios place high technical demands on the determinism of process execution order, the security of external tool calls, and the controllability of state updates.

[0003] In practical computer systems engineering, large language models are essentially autoregressive text generation models based on probability distributions, and their output content and behavioral trends are somewhat uncontrollable. When large language models are placed in business process environments that require the execution of multi-step tasks in a strict preset order, their probabilistic generation characteristics may conflict with the rigid constraints of the business process on the execution order. Furthermore, in scenarios where external tools are invoked, if the large language model can select or trigger various tool calls without restriction, tools unrelated to the current task may be incorrectly invoked, thus affecting the correct execution of the business process. In addition, in long-running multi-step business processes, the system needs to reliably locate the current task position, record the processing status of each task, and suspend it at appropriate times to await external input during the process. This places further technical demands on the representation of process states, the control mechanism for state updates, and the determinism of state progression.

[0004] Given the aforementioned technical context, there is a need for a computer implementation scheme that can maintain process control unaffected by the large language model's generation behavior while invoking a large language model to process business data. Summary of the Invention

[0005] This specification provides an execution control method for a business process, applied to a computer control system including a graphical workflow execution engine, multiple execution nodes scheduled by the graphical workflow execution engine, and a tool registry. A business process state area representing a finite state machine is pre-defined, along with state transition functions for updating control-type fields in the business process state area. The business process state area is a portion of memory within the global state memory maintained by the graphical workflow execution engine. The control-type fields include a process stage field, a task item cursor field, and a task item status field for each task item in the task item sequence. The process stage field indicates the current stage of the business process, the task item cursor field locates the currently pending task item within the business process, and the task item status field indicates the processing status of that task item. The calling interface of the state transition functions is isolated from the output interface of the large language model. A node routing function is pre-defined for routing between execution nodes based on the process stage field and the task item cursor field, and the calling interface of the node routing function is isolated from the output interface of the large language model. Each first-type execution node is pre-configured with a list of available fields and a list of available tools. The first-type execution node is used to call the large language model to generate task-related content. The list of available fields is used to limit the business input fields that the first-type execution node can provide when calling the large language model, and the list of available tools is used to limit the tools that the first-type execution node can provide when calling the large language model.The method includes: in response to a received deterministic business event, the graph workflow execution engine reads the process stage field and the task item cursor field from the business process state area, calls the node routing function to determine the current execution node, and schedules the current execution node; if the current execution node is a first-type execution node, the current execution node reads corresponding business input data from the global state memory and / or the received deterministic business event according to the bound list of available fields, constructs a local context based on the read business input data, and determines an available toolset from the tool registry center according to the bound list of available tools; and calls the large language model based on the local context and the available toolset, according to the large... The generated content returned by the language model determines the business output data and writes it into the non-control class field in the global state memory. If the current execution node determines that it meets the corresponding state transition trigger condition, it calls the state transition function to update the fields in the business process state area according to the fields in the business process state area and the received deterministic business event, through the write interface of the business process state area, and returns a scheduling response signal to the graph workflow execution engine. According to the scheduling response signal, the graph workflow execution engine ends the current execution of the current execution node and performs the following actions: continues to determine and schedule the next execution node, or stops the continuous scheduling of subsequent execution nodes and waits for the next deterministic business event, or terminates the execution of the business process.

[0006] In the above method, by setting the control fields, which together constitute the process stage fields, task item cursor fields, and task item status fields, in an independent business process state area, and isolating the calling interfaces of the state transition function and node routing function from the output interface of the large language model, the control of the process no longer passes through the large language model, but is executed by pre-configured deterministic functions based on the protected control state. After the current execution node is determined by the deterministic routing, the first type of execution node can only read business input data and construct a local context according to the list of available fields at the node level, and determine the available toolset according to the list of available tools at the node level, so that the large language model only runs within the input range and tool range limited by the current node. The content generated by the large language model can only be converted into business output data and written to non-control fields, and cannot access the write path of control fields. The update of the control state is still executed by the state transition function through the write interface based on the fields of the business process state area and deterministic business events. Thus, the large language model is restricted to a local data processing module within the node, and the deterministic advancement of the process is achieved through the protected control state and isolated deterministic transition rules.

[0007] Optionally, the deterministic business event includes an event type field and an event payload field; the event type field includes a business action type and / or an event source type; the business action type is used to represent at least one of a task confirmation event, a task skip event, a process cancellation event, a task selection event, and an approval event; the event source type is used to represent at least one of an HTTP callback event, a message queue event, a Webhook event, and a timed trigger event; the event payload field is used to carry business parameters corresponding to the event type field.

[0008] Optionally, the computer control system further includes a business process distribution gateway. In response to a process trigger event that triggers a business process for the first time, the business process distribution gateway determines the business process to be processed based on at least one of a business process identifier, a session identifier, and an event type in the process trigger event, and sends a process trigger instruction to the graphical workflow execution engine. The graphical workflow execution engine creates an instance to host the business process based on the process trigger instruction, and delineates and initializes the business process state area in the global state memory. Further, when initializing the business process state area, a process stage field, a task item cursor field, and a task item status field for each task item can be written therein; the process stage field is set to indicate the initial stage, the task item cursor field points to the first task item in the task item sequence, and the task item status field for each task item is set to indicate an unprocessed state.

[0009] Optionally, the non-control fields in the global state memory may include in-state non-control fields set within the business process state area and out-of-state non-control fields set outside the business process state area. The in-state non-control fields include the task execution result field and the task item information field for each task item in the task item sequence; the task item information field includes at least one of the following: a task item unique primary key field, a task item type field, and a task item name field.

[0010] Optionally, the process stage field can be used to represent one of the following: an initial stage, a task processing stage, a deterministic business event waiting stage, and a termination stage. Further, the termination condition can include a process cancellation termination condition or a task sequence completion termination condition.

[0011] Optionally, the task item cursor field is a program counter field used to indicate the position of the currently pending task item in the task item sequence. When updating the fields in the business process state area through the state transition function, if the deterministic business event represents a task item confirmation event or a task item skipping event, the task item cursor field can be advanced by one task item position according to the arrangement order of the task item sequence. Further, boundary detection is performed after advancement: if it points to a task item, it is updated to the task item processing stage; if it goes out of bounds, it is updated to the termination stage.

[0012] Optionally, the task status field is used to represent one of the following: unprocessed, confirmed, skipped, and canceled status.

[0013] Optionally, when the generated content returned by the large language model can be converted according to preset data structure requirements, the business output data is the task execution result obtained by converting the generated content. When writing the business output data into a non-control class field in the global state memory, the business output data can be written into the task execution result field of the current task to be completed located by the task item cursor field, or into a metadata field that is a non-control class field outside the state area; wherein, the metadata field is used to store response data output to the business process caller or downstream component. When the generated content returned by the large language model cannot be converted according to preset data structure requirements, the business output data is error message data generated according to preset error message rules, and is written into the metadata field.

[0014] Optionally, the node routing function pre-sets node routing relationships, including a first correspondence and a second correspondence. The first correspondence is the correspondence between the process stage field value and the execution node identifier; the second correspondence is the correspondence between the process stage field value, the task item type field value, and the execution node identifier. When the node routing function is called to determine the current execution node, the target routing branch can be determined based on the process stage field. If the target routing branch does not belong to the task item processing branch, the execution node identifier of the current execution node is determined based on the process stage field and the first correspondence. If the target routing branch belongs to the task item processing branch, the current task item to be completed is determined from the task item sequence based on the task item cursor field, the task item type field in the current task item to be completed is determined, and the execution node identifier of the current execution node is determined based on the process stage field, the determined task item type field, and the second correspondence.

[0015] Optionally, when the first type of execution node constructs a local context based on the bound list of available fields, it can create a local message list corresponding to the first type of execution node; extract business field values ​​from the currently pending task item located by the task item cursor field and / or the received deterministic business events according to the list of available fields; construct a local context object based on the extracted business field values; and write the local context object into the local message list to form the local context. Further, restrictive system prompts can also be written into the local message list.

[0016] Optionally, when the current execution node calls the large language model based on the local context and the available toolset, it can bind the available toolset to the large language model to obtain a restricted model instance corresponding to the current execution node, and then call the restricted model instance based on the local context. Further, when calling the restricted model instance based on the local context, a loop counter corresponding to the current execution node can be created; in one loop, the restricted model instance is called based on the local context to obtain a model response message and write the message to the local context; the model response message is parsed to determine if it contains a tool call instruction; if it does not contain a tool call instruction, the model response message is determined to be the generated content returned by the large language model; if it contains a tool call instruction, the tool to be called and the tool call parameters belonging to the available toolset are determined from the tool call instruction, the corresponding tool call is executed and a tool return message is generated, the tool return message is written to the local context and the loop counter is updated; if the loop counter has not reached a preset iteration limit, the restricted model instance is called again based on the local context after writing the model response message and the tool return message. If the loop counter reaches the preset iteration limit and the generated content has not yet been determined, a preset fallback response message can be generated and identified as the generated content returned by the large language model.

[0017] Optionally, when executing a tool call, if the model response message contains multiple tool call instructions, the tool name, tool call parameters, and tool call identifier can be parsed from each tool call instruction; a corresponding asynchronous tool call task can be created for each tool call instruction based on the tool name and the tool call parameters; a timeout constraint can be set for each asynchronous tool call task; if the asynchronous tool call task returns within the timeout constraint, a tool return message can be generated based on the return result of the asynchronous tool call task and the corresponding tool call identifier; if the asynchronous tool call task does not return within the timeout constraint, the corresponding timeout exception can be captured, the timeout exception can be prevented from being passed to the graph workflow execution engine or the state transition function, and a tool return message indicating that the tool call timed out can be generated based on the corresponding tool call identifier.

[0018] Optionally, when determining business output data based on the generated content returned by the large language model and writing it into the non-control class field in the global state memory, the generated content can be input into a preset structured conversion verification process. If the verification passes, the structured data obtained after passing the verification is determined as the task execution result and written into the non-control class field. If the verification fails, error message data is generated according to preset error message rules and written into the non-control class field. Further, when inputting the generated content into the structured conversion verification process, the generated content can be determined as candidate data to be verified, and before passing the structured conversion verification process, the candidate data to be verified is kept in a temporary processing path. The temporary processing path is isolated from the write interface of the control class field in the business process state area, and is also isolated from the target write path used to store valid business output data in the task execution result field and the metadata field. The structured transformation verification process may include: performing direct parsing on the candidate data to be verified; if direct parsing fails, extracting structured data fragments that conform to preset boundary identifiers from the candidate data to be verified and parsing them again; obtaining a data object to be normalized after successful parsing; matching and replacing the field names in the data object to be normalized with preset field alias mapping relationships to generate a data object with normalized field names; inputting the data object with normalized field names into a strongly typed data model corresponding to preset data structure requirements, and performing mandatory field verification, field type verification, default field completion, and field value range verification; generating a type-safe structured data object if the verification requirements are met, and writing it entirely to the target write location. If the structured transformation verification process fails, generating error message data and writing it to the metadata field, prohibiting the writing of candidate data to be verified to the task execution result field, and determining that the state transition trigger condition is not met or keeping the task item cursor field from advancing.

[0019] Optionally, the plurality of execution nodes may further include a second type of execution node, which is an execution node that does not call the large language model to generate task-related content in this execution, and processes the deterministic business events and / or the fields in the business process status area according to the preset deterministic processing logic.

[0020] Optionally, when the current execution node determines that it meets the corresponding state transition trigger condition, it can obtain the corresponding preset state transition trigger condition; read the process stage field, the task item cursor field, and the task item status field of the current task to be completed located by the task item cursor field from the business process status area; read the event type field and the event payload field from the deterministic business event; and determine whether the deterministic business event matches the preset state transition trigger condition corresponding to the current execution node based on the read fields. The preset state transition trigger condition may include at least one of the following: task item processing completion trigger condition, data ready trigger condition, deterministic processing completion trigger condition, process initialization completion trigger condition, and process cancellation trigger condition. When the process cancellation trigger condition and the task item processing completion trigger condition, the data ready trigger condition, or the deterministic processing completion trigger condition are all met simultaneously, the current execution node may preferentially call the state transition function according to the process cancellation trigger condition.

[0021] Optionally, when calling the state transition function to update the fields in the business process state area, a corresponding state transition branch can be determined based on the preset state transition trigger conditions. The state transition branch includes one of the following: process initialization transition branch, task completion transition branch, data ready transition branch, deterministic processing transition branch, and process cancellation transition branch. After determining the state transition branch, at least one of the process stage field, the task item cursor field, and the task item status field of the currently pending task item located by the task item cursor field is updated through the write interface of the business process state area. Specifically, the task item completion transition branch can distinguish between four event actions: confirmation, skip, selection, and approval. Confirmation or skipping updates the task item status field and advances the cursor; selection determines the write data based on the selected object identifier, updates the status, and advances the cursor; approval determines the status update value based on the approval result and advances the cursor. After advancement, the process stage field is updated to either the task item processing stage or the termination stage depending on whether the cursor exceeds the boundary. The data ready transition branch updates the process stage field to the deterministic business event waiting stage and keeps the cursor and task item status unchanged. The process cancels the branch transfer, updates the process stage field to the terminated stage, and keeps the cursor unchanged, without advancing item by item.

[0022] Optionally, the scheduling response signal may include one of a continue scheduling signal, an event waiting signal, and a process termination signal. When the scheduling response signal is a continue scheduling signal, the graph workflow execution engine can read the updated process stage field and task item cursor field from the business process status area using the state transition function; call the node routing function to determine the next execution node based on the read process stage field and task item cursor field; and, if the next execution node is determined, schedule the next execution node during the current continuous scheduling of subsequent execution nodes. When the scheduling response signal is an event waiting signal, the graph workflow execution engine can stop calling the node routing function to determine subsequent execution nodes during the current scheduling process; maintain the updated fields in the business process status area using the state transition function as the basis for reading node routing after the arrival of the next deterministic business event. When the scheduling response signal is a process termination signal, the graph workflow execution engine can stop calling the node routing function to determine the subsequent execution node corresponding to the business process; prohibit further scheduling of the execution node corresponding to the business process; and mark the instance corresponding to the business process as terminated.

[0023] Optionally, when the graph workflow execution engine stops the continuous scheduling of subsequent execution nodes and waits for the next deterministic business event, at least a portion of the state data in the global state memory can be serialized into checkpoint data before stopping the continuous scheduling of subsequent execution nodes, and the checkpoint data can be persistently associated with the instance identifier and / or session identifier corresponding to the business process. After receiving the next deterministic business event, the corresponding checkpoint data can be read according to the instance identifier and / or session identifier, and deserialized to reconstruct the business process state area in the global state memory; the process stage field and the task item cursor field can be read from the reconstructed business process state area, and the corresponding execution node can be determined by calling the node routing function based on the read fields.

[0024] Optionally, the deterministic business event waiting phase may include a candidate object selection waiting phase. The candidate object selection waiting phase indicates that: the current task item to be completed, located by the task item cursor field, is a candidate object selection task item, and the metadata field in the global state memory has been written into the page rendering instruction block corresponding to the candidate object set; the business process is waiting for the next deterministic business event carrying the identifier of the selected object.

[0025] This specification also provides an execution control device for a business process, which includes a graphical workflow execution engine, a business process state area management module, a node routing function module, multiple execution nodes, a state transition function module, and a tool registration center. The modules in the above device embodiments correspond to the steps in the method embodiments.

[0026] This specification also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the execution control method for the business process as described in any of the foregoing embodiments.

[0027] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the execution control method for the business process as described in any of the foregoing embodiments.

[0028] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the execution control method for the business process as described in any of the foregoing embodiments.

[0029] Through the above technical solutions, the business process execution control method provided in the embodiments of this specification can bring the following beneficial effects:

[0030] In terms of process control, by setting control fields in an independent business process state area and isolating the calling interfaces of state transition functions and node routing functions from the output interface of the large language model, the large language model cannot directly affect node routing results or trigger state transitions through its output. Regarding tool call security, by setting a list of available tools for each type of execution node and binding them as restricted model instances, the large language model can only generate tool call instructions within the tool scope limited to the current node. In terms of data security, by distinguishing fields in the global state memory into control fields and non-control fields, the generated content of the large language model can only be converted into business output data and written to non-control fields, preventing access to the write path of control fields. Furthermore, by inputting the generated content of the large language model into a preset structured transformation and verification process and writing it atomically, and by serializing control state data into checkpoint data and persisting it during event waiting, the technical effects of data verification security and cross-request state recovery can also be achieved. Attached Figure Description

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

[0032] Figure 1This is a flowchart illustrating the execution control method for a business process provided in some embodiments of this specification.

[0033] Figure 2 This is a schematic diagram of the structure of a computer control system provided for some embodiments of this specification.

[0034] Figure 3 This is a flowchart illustrating the internal processing of a first type of execution node as provided in some embodiments of this specification.

[0035] Figure 4 This is a schematic diagram of the state transition branch processing provided for some embodiments of this specification.

[0036] Figure 5 This is a complete closed-loop flowchart illustrating the most specific embodiments provided for some examples in this specification. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0038] The embodiments in this specification can be applied to computer systems that require embedding large language models into multi-step deterministic business processes, such as business scenarios involving appointments, approvals, and transaction confirmations, which need to proceed step by step according to a preset task sequence and be confirmed or skipped based on external events. In such scenarios, the business process typically consists of a series of tasks with a sequential order. Each task may require collecting user data, calling external tools to query information, generating structured task content from the large language model, and waiting for user confirmation or approval at key steps before proceeding to the next task. In such business processes, the process progression order, task positioning, tool call scope, and state changes need to maintain a high degree of determinism and controllability. However, as a probabilistic generation model, the output content and behavioral direction of the large language model are inherently uncontrollable and are not suitable for directly undertaking process control responsibilities.

[0039] In some approaches, all external capabilities can be uniformly defined as tools and mounted onto a large language model (MLM). The MLM then autonomously decides whether to invoke a tool and which tool to invoke each time it is called, tracking the interaction process by maintaining a global message history queue. However, this approach can lead to the MLM skipping steps that require user confirmation due to probabilistic sampling and directly triggering subsequent operations, or getting stuck in an infinite retry loop when a tool call fails. Furthermore, as the number of interaction rounds increases, the large amount of context accumulated in the global message history can distract the MLM, causing the initially set business constraints to be overwhelmed by the subsequent dense tool call records. Additionally, the text output by the MLM may have inconsistencies in format and field names; if provided directly to downstream components without validation, it can easily lead to rendering anomalies due to format parsing failures.

[0040] This specification provides an embodiment of a business process execution control method. Its core lies in separating the process routing decisions, state progression, and tool capability boundaries from the generation behavior of a large language model, entrusting these to a pre-configured deterministic mechanism. Specifically, the system delineates an independent business process state area within the global state memory maintained by the graph workflow execution engine. Within this area, a process stage field, a task item cursor field, and a task item status field for each task item are set as protected control fields. The process stage field records the current stage of the business process (e.g., initial stage, task item processing stage, waiting event stage, or termination stage). The task item cursor field points to the position of the currently pending task item in the task item sequence, and the task item status field marks the processing status of each task. Updates to these control fields are executed by state transition functions through the write interface of the business process state area. The calling interfaces of the state transition functions and node routing functions are isolated from the output interface of the large language model, preventing the large language model from triggering state transitions or influencing routing decisions via its output path. Meanwhile, for the first type of execution node that needs to call the large language model, the system pre-sets a list of available fields and a list of available tools for each node—the former limits the range of business input fields that the node can read when calling the large language model, and the latter limits the set of tools that can be used. When the graph workflow execution engine determines the current execution node based on deterministic business events and node routing functions, if it is a first type of execution node, the node only extracts business input data from the range specified in the list of available fields to construct a local context, binds the toolset specified in the list of available tools to the large language model, and then initiates the call; the content generated by the large language model is processed by the current execution node into business output data and written to non-control fields. Subsequently, when it is determined that the state transition trigger condition is met, the current execution node calls the state transition function to update the control fields and returns a scheduling response signal to the graph workflow execution engine, which then decides whether to continue scheduling, suspend and wait, or terminate the process.

[0041] Figure 1 This is a flowchart illustrating a business process execution control method provided in some embodiments of this specification. Figure 1 The method shown may include the following steps:

[0042] Step S110: Receive a deterministic business event, read the control class field, and determine the current execution node.

[0043] In step S110, the graph workflow execution engine, in response to a received deterministic business event, reads the currently stored process stage field and task item cursor field from the business process state area in the global state memory. Deterministic business events can arrive from various sources, such as HTTP callbacks, message queues, webhooks, or timed triggers. Their data structure may include an event type field and an event payload field. The event type field carries the business action type (such as task confirmation, task skipping, process cancellation, task selection, or approval) and / or the event source type; the event payload field carries the business parameters corresponding to the event type.

[0044] The graph workflow execution engine passes the read business process status fields and deterministic business events to the node routing function. The node routing function then determines the identifier of the currently scheduled execution node based on pre-defined node routing relationships. The node routing function pre-sets a first correspondence between process stage field values ​​and execution node identifiers, and a second correspondence between process stage field values, task item type field values, and execution node identifiers. During routing, the node routing function first determines the target routing branch (e.g., initial processing branch, task item processing branch, event waiting processing branch, or termination processing branch) based on the process stage fields. For non-task item processing branches, it directly determines the execution node identifier based on the process stage fields and the first correspondence. For task item processing branches, it also locates the currently pending task item using the task item cursor field, reads its task item type field, and then combines the process stage fields and the second correspondence to determine the execution node identifier. Because the node routing function is a pre-defined deterministic function called by the graph workflow execution engine, its calling interface is isolated from the output interface of the large language model. The large language model cannot replace or influence the routing results through its generated content.

[0045] In some embodiments, the computer control system may include a business process distribution gateway. Upon initial triggering of a process, the business process distribution gateway responds to a process triggering event, determines the business process to be processed based on information such as the business process identifier, session identifier, and event type in the event, and sends a process triggering instruction to the graphical workflow execution engine. The graphical workflow execution engine creates a process instance based on this instruction and delineates and initializes the business process state area in the global state memory. The initialization process includes: writing a process stage field, a task item cursor field, and a task item status field for each task item in the task item sequence into the business process state area; setting the process stage field to indicate the initial stage, setting the task item cursor field to point to the first task item in the task item sequence, and setting the task item status field for each task item to indicate an unprocessed state. In actual engineering, the task item sequence can be predefined during the system configuration phase according to the business process planning, and each task item carries at least information such as a unique primary key, task item type, and task item name.

[0046] In some embodiments, when a business process receives a deterministic business event for the first time after its creation, the node routing function determines the target routing branch as the initial processing branch based on the process stage field of the initial stage, and determines the identifier of the initial processing node according to a first correspondence. After execution, this initial processing node initiates the actual processing of the task item sequence. Simultaneously, after initialization, the initial processing node updates the process stage field to the task item processing stage via a state transition function. From this point on, subsequent node routing can proceed normally based on the process stage field of the task item processing stage and the task item cursor field pointing to the first task item.

[0047] Step S120: Schedule the current execution node; if it is a first-class execution node, call the large language model according to the constraints of the list of available fields and the list of available tools and write it into the non-control class fields.

[0048] In step S120, the graph workflow execution engine schedules the corresponding current execution node based on the execution node identifier determined by the node routing function. The multiple execution nodes include a first type of execution node and a second type of execution node. The first type of execution node is used to call the large language model to generate task-related content; the second type of execution node does not call the large language model in this execution, but instead processes deterministic business events and / or fields in the business process status area according to preset deterministic processing logic, such as the initial processing node for process initialization, the event processing node during the response event waiting phase, and the termination processing node when the process terminates.

[0049] When the current execution node is a first-type execution node, the node performs constraint processing based on the pre-bound list of available fields and list of available tools. Figure 3This is a flowchart illustrating the internal processing of a first type of execution node as provided in some embodiments of this specification. Figure 3 The processing procedure shown may include the following steps:

[0050] First, the first type of execution node creates a local message list corresponding to that node; based on the list of available fields, it extracts business field values ​​from the currently pending task item located by the task item cursor field and / or the received deterministic business events; it constructs a local context object based on the extracted business field values; and it writes the local context object into the local message list to form a local context. The purpose of the list of available fields is to limit the range of fields that the large language model can read in each call to the actual business input fields required by the current node, preventing it from directly reading control fields or other historical task data unrelated to the node in the business process status area. In some embodiments, when constructing the local context, a constraint system prompt can also be written into the local message list. This constraint system prompt is used to constrain the large language model to perform operations such as data extraction, tool call parameter generation, or preset structured format output based on the local context object.

[0051] After constructing the local context, the first type of execution node determines the available toolset from the tool registry based on the list of available tools it is bound to. The tool registry is a unified management module for all registered structured tool objects in the system; each tool object contains a tool description, parameter format, and execution interface. The first type of execution node uses the list of available tools as a filter to select tools that the node is allowed to use by the large language model from the tool registry, forming the available toolset. Then, the available toolset is bound to the large language model, resulting in a restricted model instance corresponding to the current execution node. Therefore, at the physical level, the large language model can only call tools from the available toolset of the current node and cannot trigger other tools in the tool registry that are not bound to the current node.

[0052] Next, the first type of execution node invokes a restricted model instance based on its local context. In some embodiments, this invocation process is executed in a controlled loop: a loop counter is created corresponding to the current execution node; in one loop, the restricted model instance is invoked based on the local context to obtain a model response message, which is then written to the local context; the model response message is parsed to determine if it contains a tool invocation instruction. If no tool invocation instruction is included, the model response message is identified as the generated content returned by the large language model, and the loop ends. If a tool invocation instruction is included, the tool to be invoked and its parameters belonging to the available toolset are determined from the instruction; the corresponding tool invocation is executed, and a tool return message is generated; the tool return message is written to the local context, and the loop counter is updated; if the loop counter has not reached a preset iteration limit (e.g., 3 times), the restricted model instance is invoked again based on the local context after writing the model response message and the tool return message, entering the next round of the loop. If the loop counter has reached the preset iteration limit and the generated content has not yet been determined, a preset fallback response message is generated and identified as the generated content, ensuring that the loop will inevitably terminate.

[0053] In some embodiments, when the model response message contains multiple tool call instructions, the tool name, tool call parameters, and tool call identifier can be parsed from each tool call instruction. A corresponding asynchronous tool call task is created for each tool call instruction, and a timeout constraint (e.g., 5 seconds or 10 seconds) is set for each asynchronous tool call task. If the asynchronous tool call task returns within the timeout constraint, a tool return message is generated based on the return result and the tool call identifier. If it does not return within the timeout constraint, the corresponding timeout exception is captured, and the propagation of the timeout exception to the graph workflow execution engine or state transition function is prohibited. A tool return message indicating a tool call timeout is generated based on the tool call identifier. Finally, each tool return message is written to the local context. In this way, network failures or timeouts of a single tool do not block the processing flow of the entire execution node; instead, they are encapsulated as tool return messages and continue to participate in subsequent loop inference.

[0054] Furthermore, in some embodiments, in concurrent tool call scenarios, the system can also set up concurrent semaphores and idle connection queues for different external tool services. When initiating a tool call, the target external tool service is determined based on the tool name; the number of concurrent tool calls is limited based on the concurrent semaphore corresponding to the target external tool service; a connection is obtained from the corresponding idle connection queue, and a new connection is created if the queue is empty and the concurrent semaphore limit has not been reached; a remote call is initiated to the target external tool service based on the obtained or created connection. If the remote call returns normally, times out, or an exception occurs, the corresponding concurrent semaphore is released; if the connection is in a reusable state, it is returned to the idle connection queue; if the connection is in a non-reusable state, the connection is closed and returning it to the idle connection queue is prohibited.

[0055] After obtaining the generated content returned by the large language model, the first type of execution node determines the business output data based on the generated content and writes the business output data into the non-control class fields in the global state memory. The non-control class fields in the global state memory can include in-state non-control class fields set within the business process state area and out-of-state non-control class fields set outside the business process state area. In-state non-control class fields can include the task execution result field and task item information fields (such as the task item unique primary key field, task item type field, task item name field, etc.) for each task item in the task item sequence; out-of-state non-control class fields can include metadata fields, which are used to store response data output to the business process caller or downstream components.

[0056] In one basic implementation, the first type of execution node can directly parse the generated content into structured data and write it to non-control class fields. In another implementation, the system can configure a structured conversion verification process for the first type of execution node to verify the generated content of the large language model before writing it. Specifically, the generated content is identified as candidate data to be verified, and this candidate data is kept in a temporary processing path until it passes verification. This temporary processing path is isolated from the write interface of the control class fields in the business process status area, and also isolated from the target write path used to store valid business output data in the task execution result field and metadata field. The structured conversion verification process can be configured with preset data structure requirements and target write locations corresponding to the current execution node and / or the current task item to be completed. The preset data structure requirements are used to limit at least one of the following: the set of fields after the generated content is converted, field names, field types, required fields, default field completion rules, and field value ranges. The target write location can be the task execution result field and / or metadata field in the current task item to be completed.

[0057] In some embodiments, the structured transformation validation process may include multi-level processing. The first level of processing performs direct parsing of the candidate data to be validated to determine if it conforms to a preset structured data format (e.g., standard JSON format). If direct parsing fails, structured data fragments conforming to preset boundary markers (e.g., ```json and ``` tags) are extracted from the candidate data and parsed again. If direct parsing or parsing of the structured fragments is successful, the data object to be normalized is obtained. If both fail, the generated content is determined to have failed the validation process. The second level of processing matches the field names in the data object to be normalized with preset field alias mappings, replacing the matched field names (e.g., the camelCase field name "serviceCount" that a large language model might output) with the corresponding standard field names (e.g., "service_count"), generating a data object with normalized field names. The third-level processing inputs the data object with normalized field names into a strongly typed data model that corresponds to the preset data structure requirements; the strongly typed data model performs validation of required fields, field types, missing fields, and field value ranges; if the validation requirements are met, a type-safe structured data object is generated; if not, the generated content is determined to have failed the validation process.

[0058] If the generated content passes the above-described structured transformation and validation process, the type-safe structured data object is converted into the task execution result, and the task execution result is written as a whole to the task execution result field or metadata field according to the target write location. It is important to emphasize that before generating the type-safe structured data object, it is prohibited to write only some fields of the candidate data to be validated to the target write location. That is, an atomic commit method of "writing the whole only after all validations pass" should be used to avoid intermediate data in the target write location where some fields have been written but the remaining fields have not yet been validated.

[0059] If the generated content fails the structured transformation validation process, error message data, including error status and error message fields, is generated according to preset error message rules and written to the metadata field. Simultaneously, writing the candidate data to be validated or part of the parsing results obtained from it to the task execution result field is prohibited. Furthermore, it is determined that the state transition trigger condition corresponding to the current execution node is not met, or the state transition function keeps the task item cursor field unadvanced during this execution. In this way, validation failures both replace the original generated content with a safe error message at the data level and prevent the process from continuing under unreliable data conditions at the control level.

[0060] Furthermore, if parsing exceptions, field normalization exceptions, or strong type validation exceptions occur during the structured transformation validation process, the current execution node can capture these exceptions, prevent them from being passed to the graph workflow execution engine or state transition function, and generate error message data based on the captured exceptions according to preset error message rules. In this way, exceptions within the validation process will not affect the upper-level scheduling logic and state transition logic.

[0061] In some embodiments, when the generated content returned by the large language model can be transformed according to preset data structure requirements, the business output data is the task execution result obtained by transforming the generated content. This result can be written to the task execution result field of the current pending task item located by the task item cursor field, or written to a metadata field that is a non-control type field outside the status area. When the generated content cannot be transformed according to preset data structure requirements, the business output data is error message data generated according to preset error message rules, and written to the metadata field. In addition, the task execution result field can also be used to store the tool return result obtained by the current execution node calling the tool, or the node processing result generated by the current execution node without calling the large language model. When the scheduling response signal indicates a halt to continuous scheduling and waiting for the next deterministic business event, the system can also write a page rendering instruction block to the metadata field. This page rendering instruction block includes event type data and current pending task item data, allowing downstream components to generate an interactive interface corresponding to the currently waiting event.

[0062] When the current execution node is a type II execution node, it does not invoke the large language model during this execution. Instead, it processes the fields in the deterministic business events and business process state area according to preset deterministic processing logic. For example, the initial processing node can perform necessary business preparation operations when the process first enters the task item processing stage; the event processing node can parse and distribute arriving events when the process is in the deterministic business event waiting stage; and the termination processing node can perform cleanup operations when the process meets the termination conditions. If the processing results of the type II execution node need to be written to the global state memory, they are also written to the non-control fields therein.

[0063] Step S130: Determine whether the state transition trigger condition is met. If it is met, call the state transition function to update the control class field and return the scheduling response signal.

[0064] In step S130, after completing node processing, the current execution node obtains the corresponding preset state transition trigger condition. The preset state transition trigger condition is a set of conditions pre-configured for each execution node to determine whether a state transition can be triggered. It may include task item processing completion trigger conditions, data readiness trigger conditions, deterministic processing completion trigger conditions, process initialization completion trigger conditions, and process cancellation trigger conditions. The current execution node reads the process stage field, task item cursor field, and task item status field of the currently pending task item from the business process status area, and reads the event type field and event payload field from the deterministic business event. Based on these fields, it determines whether the preset state transition trigger condition is met.

[0065] Taking the task completion trigger condition as an example, this condition applies to the execution node used to process the current pending task item. Specific judgments may include: the process stage field indicating the task item processing stage; the value of the task item cursor field being within the valid index range of the task item sequence; the task item status field indicating the unprocessed state of the current pending task item; the event type field of the deterministic business event matching the allowed processing action type corresponding to the current pending task item; the business parameters carried by the event payload field of the deterministic business event matching the current pending task item; and the current execution node having completed the node processing corresponding to the current pending task item (i.e., having generated the corresponding business execution result and written it to the task execution result field).

[0066] When determining whether the event type field matches a permitted action type, the permitted action type can be determined from a pre-set action type mapping relationship based on the task type field of the current pending task and / or the execution node identifier of the current execution node, and then the event type field is matched accordingly. Permitted action types can include task confirmation events, task skip events, task selection events, and approval events. When determining whether the business parameters of the event payload field match the current pending task, task matching parameters (such as task identifier) ​​can be read from the event payload field and matched with the task unique primary key field, task type field, or task name field of the current pending task. Through the combination of the above multiple conditions, the task completion trigger condition is considered met only when the control state is correct, the task is indeed the current pending item and has not been processed, the event type and event parameters match, and the node processing has been completed.

[0067] The data readiness trigger condition applies to scenarios in the first type of execution node configured to generate task-related content before calling the state transition function. This condition includes: the current execution node has determined the business output data based on the generated content returned by the large language model, and this business output data has been written to a non-control class field in the global state memory. It is important to note that if the business output data is error message data generated according to preset error message rules, then the data readiness trigger condition is not met. This means that when the generated content of the large language model fails validation, even if a downgraded error message has been returned, the system will not trigger state progression based on the appearance of "data has been generated," but will maintain the current state.

[0068] The deterministic processing completion trigger condition applies to the second type of execution node. This condition includes: the current execution node has determined the deterministic business event and the fields read from the business process state area according to the preset deterministic processing logic, obtaining the deterministic node processing result; and, if the result needs to be written to the global state memory, the writing has been completed. The process initialization completion trigger condition applies to the second type of execution node that initiates the business process into the task item processing stage. This condition includes: the business process state area has been written with the process stage field, the task item cursor field, and the task item status field for each task item, and the task item cursor field is pointing to the first task item in the task item sequence. The process cancellation trigger condition includes: the event type field of the deterministic business event indicates a process cancellation event, or the event payload field carries control instructions for canceling the business process. When both the process cancellation trigger condition and other trigger conditions are met simultaneously, the current execution node can prioritize calling the state transition function according to the process cancellation trigger condition.

[0069] Once the current execution node determines that the state transition triggering condition corresponding to itself is met, the state transition function is called. Figure 4 This is a flowchart illustrating the state transition branch processing provided in some embodiments of this specification. The state transition function determines the corresponding state transition branch based on the triggered conditions that are met, and then updates at least one of the process stage field, task item cursor field, and task item status field of the current task item to be completed through the write interface of the business process status area.

[0070] Figure 4 The branching logic shown can include the following processing steps:

[0071] When the process initialization completion trigger condition is met, the state transition function executes the process initialization transition branch: updating the process stage field to the task item processing stage, and keeping the task item cursor field pointing to the first task item in the task item sequence, so that the process naturally transitions from the initialization state to the task item processing state.

[0072] When the task completion trigger condition is met, the state transition function executes the task completion transition branch. This branch performs different processing actions based on the specific value of the event type field of the deterministic business event. When the event type field indicates a task confirmation event, the task status field of the current task to be completed is updated to the confirmed status; when it indicates a task skipped event, it is updated to the skipped status; after completing the status update, the task cursor field is advanced one task position according to the order of the task sequence.

[0073] When the event type field indicates that the task item selection event is selected, the selected object identifier is read from the event payload field. Based on the identifier, the business output data to be written to the task execution result field or metadata field is determined. After the writing is completed, the task item status field of the current task item to be completed is updated to the confirmed status, and then the task item cursor field is advanced.

[0074] When the event type field represents an approval event, the approval result field is read from the event payload field. Based on the approval result, the status update value of the task item status field is determined (this value can be one of confirmed status, skipped status, or canceled status). The status field is updated to this value before advancing the task item cursor field.

[0075] After advancing the task item cursor field, the state transition function also performs boundary checks: it compares the advanced task item cursor field with the length of the task item sequence; if the advanced cursor points to a valid task item in the task item sequence, the process stage field is updated to the task item processing stage; if the advanced cursor points to a position after the end of the task item sequence (i.e., all task items have been processed), the process stage field is updated to the termination stage.

[0076] When the data-ready trigger condition is met, the state transition function executes the data-ready transition branch. If business output data has been written to non-control fields and the current execution node is configured to generate business output data and wait for subsequent deterministic business events, the process stage field is updated to the deterministic business event waiting stage, while the task item cursor field and the task item status field of the currently pending task item remain unchanged. This means that after the first type of execution node completes the large language model call and data writing, the process does not automatically advance to the next task item, but instead enters the waiting stage, waiting for an external deterministic event (such as user confirmation or selection) to arrive before continuing.

[0077] When the deterministic processing completion trigger condition is met, the state transition function executes the deterministic processing transition branch. This branch selects different transition paths based on the deterministic node processing result of the second type of execution node: if the result indicates that it needs to enter the task item processing process, the process stage field is updated to the task item processing stage; if the result indicates that it needs to continue waiting for a deterministic business event, the process stage field is kept or updated to the deterministic business event waiting stage, and the task item cursor field and the current task item status field remain unchanged; if the result indicates that the current task item to be completed has been completed, the fields in the business process status area are updated according to the task item completion transition branch. Thus, the second type of execution node has the ability to flexibly control the subsequent process direction based on the deterministic determination result.

[0078] When the process cancellation trigger condition is met, the state transition function executes the process cancellation transition branch: updating the process stage field to the termination stage while keeping the value of the task item cursor field unchanged. The process cancellation trigger condition corresponds to the process-level cancellation instruction used to cancel the entire business process; after updating the process stage field to the termination stage, the state transition function no longer advances the task item cursor fields item by item according to the order of the task item sequence to update the status fields of each task item. In other words, process cancellation is a process-level termination operation and does not require traversing the remaining unprocessed task items one by one.

[0079] After the state transition function completes the field update, the currently executing node returns a scheduling response signal to the graph workflow execution engine. The scheduling response signal includes one of the following: a continue scheduling signal, an event wait signal, or a process termination signal. The continue scheduling signal indicates that after the current execution node's current execution is completed, the graph workflow execution engine should determine and schedule the next execution node. The event wait signal indicates that after the current execution node's current execution is completed, the graph workflow execution engine should stop continuously scheduling subsequent execution nodes and wait for the next deterministic business event. The process termination signal indicates that after the current execution node's current execution is completed, the graph workflow execution engine should terminate the execution of this business process.

[0080] Upon receiving any of the above scheduling response signals, the graphical workflow execution engine determines that the current scheduling call of the current execution node has returned, stops executing the node processing logic in the current scheduling call, and then executes subsequent actions according to the type of the received signal.

[0081] When a continuation scheduling signal is received, the graph workflow execution engine reads the updated process stage fields and task item cursor fields from the business process state area via the state transition function; it then calls the node routing function to determine the next execution node based on the read fields; after determining the next execution node, it schedules that next execution node during the current continuous scheduling of subsequent execution nodes. In this way, triggered by a deterministic business event, the system can continuously traverse multiple execution nodes—for example, from the initial processing node to the first type of execution node corresponding to the first task item, and then to the event processing node in the event waiting phase—without needing to suspend and wait for new events after each node completion, thus maintaining efficient continuous progress when processing phases that do not require external waiting.

[0082] Upon receiving an event waiting signal, the graph workflow execution engine stops calling the node routing function to determine subsequent execution nodes during the current scheduling process. It retains the fields updated by the state transition function in the business process state area as the basis for reading node routing after the next deterministic business event arrives. Upon receiving the next deterministic business event, the graph workflow execution engine rereads the process stage field and task item cursor field from the business process state area, calls the node routing function to determine the corresponding execution node, and resumes process scheduling. In some embodiments, before stopping the continuous scheduling of subsequent execution nodes, the graph workflow execution engine can also serialize at least a portion of the state data in the global state memory into checkpoint data and persist the checkpoint data along with the instance identifier and / or session identifier corresponding to the business process. The serialized state data includes at least the process stage field, the task item cursor field, and the task item state field of each task item in the task item sequence. After confirming that the checkpoint data is persisted, the continuous scheduling of subsequent execution nodes is stopped, and the execution resources (such as threads, memory, etc.) occupied by this scheduling are released. Upon arrival of the next deterministic business event, the system reads the corresponding checkpoint data based on the instance identifier and / or session identifier, performs deserialization processing to reconstruct the business process state area in the global state memory, reads the process stage field and task item cursor field from the reconstructed business process state area, and calls the node routing function based on these fields to determine the corresponding execution node, thereby achieving cross-request process state recovery without maintaining long connections or retaining execution threads.

[0083] When a process termination signal is received, the graph workflow execution engine stops calling the node routing function to determine the subsequent execution node corresponding to the business process, prohibits further scheduling of the execution node corresponding to the business process, marks the instance corresponding to the business process as terminated, or keeps the process stage field in the business process status area as a value indicating the termination stage, thereby completely ending the execution of the business process.

[0084] In some embodiments, the deterministic business event waiting phase can be further subdivided into a candidate object selection waiting phase. When the current task to be completed, located by the task item cursor field, is a candidate object selection task (e.g., a tour guide selection task), the first type of execution node, after completing the large language model call, writes the page rendering instruction block corresponding to the candidate object set into the metadata field, and then updates the process stage field to the candidate object selection waiting phase (a type of deterministic business event waiting phase) through the data ready transition branch. In this phase, the graph workflow execution engine stops calling the node routing function to determine the subsequent execution node, maintaining the fields in the business process state area updated by the state transition function; upon receiving the next deterministic business event carrying the selected object identifier (e.g., a tour guide selection event, whose event payload field carries the selected tour guide object identifier), it rereads the fields from the business process state area and calls the node routing function to determine the corresponding execution node. The page rendering instruction block includes event type data and current task to be completed data, which downstream components can use to generate the candidate object display interface. Through the aforementioned candidate selection waiting mechanism, the business process can be naturally suspended at nodes where users need to select from multiple candidates, and accurately resumed in the form of deterministic events after the user completes the selection.

[0085] Figure 5 This is a complete closed-loop flowchart of a specific embodiment provided for some embodiments of this specification. Figure 5 The process shown fully presents the entire process from the arrival of deterministic business events to the final scheduling decision made by the graphical workflow execution engine, covering the collaborative relationship of the various specific implementation mechanisms described in steps S110 to S140 above. Figure 5 The process shown may include the following steps:

[0086] Upon arrival of a deterministic business event in the system, if it is the first trigger of a process, the business process distribution gateway determines the business process to be processed and sends a process trigger command to the graph workflow execution engine. The graph workflow execution engine creates a process instance and defines and initializes the business process state area in the global state memory. Subsequently (or, for non-first triggers, after restoring the state from the checkpoint), the graph workflow execution engine reads the process stage field and task item cursor field from the business process state area and calls the node routing function to determine the current execution node. If the determined current execution node is a first-type execution node, the node extracts business input data from the global state memory and the event according to the list of available fields to construct a local context, determines the available toolset from the tool registry according to the list of available tools and binds it as a restricted model instance, and calls the large language model based on the local context in a controlled loop; it performs structured transformation validation on the generated content. If the validation passes, the type-safe structured data is written as a whole to the non-control class field (task execution result field or metadata field); if the validation fails, error message data is generated, written to the metadata field, and state progression is prevented. If the current execution node is a second-type execution node, it is executed according to deterministic processing logic. After node processing is complete, the currently executing node determines whether the preset state transition trigger conditions are met based on the business process status area fields and deterministic business events. If met, the state transition function is called, and the corresponding transition branch is selected to update the control class fields according to the type of trigger condition met. A scheduling response signal is then returned to the graph workflow execution engine. Upon receiving the signal, the graph workflow execution engine terminates the current node's execution: if it is a continue scheduling signal, the updated fields are read again from the business process status area to continue routing and scheduling the next node; if it is an event waiting signal, the current continuous scheduling is stopped after the status data is serialized into checkpoint data and persisted, and execution resumes after the next deterministic business event arrives; if it is a process termination signal, the business process is terminated.

[0087] The above method embodiment sets the process stage field, task item cursor field, and task item status field as protected control fields in the business process status area, and isolates the calling interfaces of the state transition function and node routing function from the output interface of the large language model. This completely entrusts the routing decision and state advancement of the process to a deterministic mechanism. The large language model is confined to the first type of execution node, only able to read input data within the scope defined by the list of available fields at the node level and call tools according to the set of tools defined by the list of available tools at the node level. Its generated content, after processing, can only be written to non-control fields. Updates to the control state are still executed by the state transition function based on the process status area fields and deterministic business events. Thus, the large language model plays the role of a local data processing module in the process, while the control of the process is always held by deterministic rules, effectively reducing the risks of process control failure, unauthorized calls, and control state pollution that probabilistic models may cause in multi-step deterministic business processes.

[0088] The above describes a business process execution control method provided in the embodiments of this specification. Based on the same technical concept, the embodiments of this specification also provide a business process execution control device. This device includes a graphical workflow execution engine, a business process state area management module, a node routing function module, multiple execution nodes, a state transition function module, and a tool registry center. The graphical workflow execution engine, as the scheduling core, manages the lifecycle of the business process state area in the global state memory, receives deterministic business events, and calls the node routing function module to determine the execution node. After the node execution is completed, it makes subsequent scheduling decisions based on the scheduling response signal. The business process state area management module is responsible for defining the business process state area in the global state memory and maintaining the control fields therein, including process stage fields, task item cursor fields, and task item status fields for each task item. The node routing function module is pre-configured with the correspondence between process stage field values ​​and execution node identifiers, as well as the correspondence between process stage field values, task item type field values, and execution node identifiers. Its calling interface is isolated from the output interface of the large language model. Each first-type execution node is bound to a list of available fields and a list of available tools. The list of available fields limits the business input fields that the node can provide when calling the large language model, and the list of available tools limits the tools that the node can provide when calling the large language model. The content generated by the large language model is processed by the execution node into business output data and then written to non-control class fields. The second-type execution nodes run according to preset deterministic processing logic and do not call the large language model. The calling interface of the state transition function module is isolated from the output interface of the large language model, and the control class fields are updated through the write interface of the business process state area. The tool registry center manages all registered structured tool objects in the system. Further optional configurations and implementation details of each module of the device can be found in the description of the corresponding steps and processing logic in the aforementioned method embodiments, and will not be repeated here.

[0089] This specification also provides a computer device, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement the steps of the execution control method for the business process described in any of the foregoing embodiments. The computer device may be a server, a distributed computing node, or a cloud computing instance, etc.

[0090] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the execution control method for the business process described in any of the foregoing embodiments. This computer program product can be deployed in the form of a software package, container image, or executable module.

[0091] This specification also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of the execution control method for the business process described in any of the foregoing embodiments. The computer-readable storage medium may include a non-volatile storage medium, such as a hard disk, solid-state drive, flash memory, optical disk, etc.

[0092] The above descriptions are merely some embodiments of this specification and are not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A method for controlling the execution of a business process, characterized in that, It is applied to a computer control system including a graphical workflow execution engine, multiple execution nodes scheduled by the graphical workflow execution engine, and a tool registry center; A pre-defined business process state area for representing the finite state machine, and state transition functions for updating control fields in the business process state area are provided. The business process state area is a portion of the global state memory maintained by the graphical workflow execution engine. The control fields include a process stage field, a task item cursor field, and a task item status field for each task item in the task item sequence. The process stage field indicates the current process stage of the business process, the task item cursor field locates the currently pending task item in the business process, and the task item status field indicates the processing status of that task item. The calling interface of the state transition functions is isolated from the output interface of the large language model. A node routing function is pre-configured for routing between execution nodes based on the process stage field and the task item cursor field. The calling interface of the node routing function is isolated from the output interface of the large language model. A list of available fields and a list of available tools are pre-set for each first type of execution node. The first type of execution node is an execution node used to call the large language model to generate task-related content. The list of available fields is used to limit the business input fields that the first type of execution node can provide when calling the large language model, and the list of available tools is used to limit the tools that the first type of execution node can provide when calling the large language model. The method includes: In response to a received deterministic business event, the graph workflow execution engine reads the process stage field and the task item cursor field from the business process status area, calls the node routing function to determine the current execution node, and schedules the current execution node; When the current execution node is a first-type execution node, the current execution node reads the corresponding business input data from the global state memory and / or the received deterministic business events according to the bound list of available fields, constructs a local context based on the read business input data, and determines the available toolset from the tool registry center according to the bound list of available tools; calls the large language model based on the local context and the available toolset, determines the business output data based on the generated content returned by the large language model, and writes it into the non-control class field in the global state memory; If the current execution node determines that it meets the corresponding state transition trigger condition, it calls the state transition function to update the fields in the business process state area according to the fields in the business process state area and the received deterministic business events through the write interface of the business process state area, and returns a scheduling response signal to the graph workflow execution engine. The graphical workflow execution engine, based on the scheduling response signal, ends the current execution of the current execution node and then performs the following actions: continues to determine and schedule the next execution node, or stops the continuous scheduling of subsequent execution nodes and waits for the next deterministic business event, or terminates the execution of the business process.

2. The method according to claim 1, characterized in that, The deterministic business event includes an event type field and an event payload field; the event type field includes a business action type and / or an event source type; the business action type is used to represent at least one of a task confirmation event, a task skip event, a process cancellation event, a task selection event, and an approval event; the event source type is used to represent at least one of an HTTP callback event, a message queue event, a Webhook event, and a timed trigger event; the event payload field is used to carry business parameters corresponding to the event type field.

3. The method according to claim 1, characterized in that, The computer control system further includes a business process distribution gateway, and the method further includes: In response to a process triggering event that triggers a business process for the first time, the business process distribution gateway determines the business process to be processed based on at least one of the business process identifier, session identifier, and event type in the process triggering event, and sends a process triggering instruction to the graph workflow execution engine. The process triggering instruction is used to indicate the business process to be processed. The graphical workflow execution engine creates an instance to carry the business process according to the process triggering instruction, and delineates and initializes the business process state area in the global state memory; The steps of initializing the business process status area by the graphical workflow execution engine include: writing a process stage field, a task item cursor field, and a task item status field for each task item in the task item sequence into the business process status area; setting the process stage field to indicate the initial stage; pointing the task item cursor field to the first task item in the task item sequence of the business process; and setting the task item status field for each task item to indicate that the task item has not been processed.

4. The method according to claim 1, characterized in that, The task item cursor field is a program count field used to indicate the position of the currently pending task item in the task item sequence; The steps of updating the fields in the business process state area through the state transition function include: when the deterministic business event represents a task item confirmation event or a task item skipping event, advancing the task item cursor field by one task item position according to the arrangement order of the task item sequence; after the task item cursor field is advanced by one task item position, comparing the advanced task item cursor field with the length of the task item sequence; and when the advanced task item cursor field points to a task item in the task item sequence, updating the process stage field to the task item processing stage. If the cursor field of the advanced task item points to a position after the end of the task item sequence, the process stage field is updated to the termination stage.

5. The method according to claim 1, characterized in that, The node routing function is pre-configured with node routing relationships, which include a first correspondence and a second correspondence; the first correspondence is the correspondence between the values ​​of process stage fields and the identifiers of execution nodes. The second correspondence is the correspondence between the values ​​of the process stage field, the values ​​of the task item type field, and the execution node identifier; The steps of calling the node routing function to determine the current execution node include: determining the target routing branch based on the process stage field; if the target routing branch does not belong to the task item processing branch, determining the execution node identifier of the current execution node based on the process stage field and the first correspondence; if the target routing branch belongs to the task item processing branch, determining the current task item to be completed from the task item sequence based on the task item cursor field, determining the task item type field in the current task item to be completed, and determining the execution node identifier of the current execution node based on the process stage field, the determined task item type field, and the second correspondence.

6. The method according to claim 1, characterized in that, The first type of execution node reads corresponding business input data from the global state memory and / or received deterministic business events according to the bound list of available fields, and constructs a local context based on the read business input data, including: Create a local message list corresponding to the first type of execution node; extract business field values ​​from the current task to be completed and / or the received deterministic business events located by the task item cursor field according to the available field list; construct a local context object according to the extracted business field values; write the local context object into the local message list to form the local context; The current execution node invokes the large language model based on the local context and the available toolset, including: binding the available toolset to the large language model to obtain a restricted model instance corresponding to the current execution node; and invoking the restricted model instance based on the local context.

7. The method according to claim 6, characterized in that, Invoking the restricted model instance based on the local context includes: Create a loop counter corresponding to the current execution node; in one loop, call the restricted model instance based on the local context to obtain the model response message, and write the model response message into the local context; The system analyzes whether the model response message contains a tool invocation instruction. If the model response message does not contain a tool invocation instruction, it identifies the model response message as the generated content returned by the large language model. If the model response message contains a tool invocation instruction, it determines the tool to be invoked and the tool invocation parameters from the tool invocation instruction, wherein the tool to be invoked belongs to the available toolset. The system executes the tool invocation corresponding to the tool to be invoked and the tool invocation parameters, generates a tool return message, writes the tool return message into the local context, and updates the loop counter. If the loop counter has not reached the preset iteration limit, the system invokes the restricted model instance again based on the local context after writing the model response message and the tool return message.

8. The method according to claim 7, characterized in that, Execute the tool call corresponding to the tool to be called and the tool call parameters, and generate a tool return message, including: When the model response message contains multiple tool call instructions, the tool name, tool call parameters, and tool call identifier are parsed from each tool call instruction; an asynchronous tool call task is created for each tool call instruction based on the tool name and the tool call parameters; a timeout constraint is set for each asynchronous tool call task; if the asynchronous tool call task returns within the timeout constraint, a tool return message is generated based on the return result of the asynchronous tool call task and the corresponding tool call identifier; if the asynchronous tool call task does not return within the timeout constraint, the corresponding timeout exception is captured, the timeout exception is prevented from being passed to the graph workflow execution engine or the state transition function, and a tool return message indicating a tool call timeout is generated based on the corresponding tool call identifier; each tool return message is written to the local context. Executing a tool call corresponding to the tool to be called and the tool call parameters further includes: setting concurrent semaphores and idle connection queues for different external tool services; determining the target external tool service based on the tool name; limiting the number of concurrent tool calls for the target external tool service based on the concurrent semaphore corresponding to the target external tool service when initiating a tool call; acquiring a connection from the idle connection queue corresponding to the target external tool service; creating a new connection if the idle connection queue is empty and the concurrent semaphore limit corresponding to the target external tool service has not been reached; initiating a remote call corresponding to the tool call parameters to the target external tool service based on the acquired connection or the newly created connection; returning the connection to the idle connection queue corresponding to the target external tool service after the tool call is completed; releasing the concurrent semaphore occupied by the target external tool service if the remote call returns normally, times out, or encounters an exception; returning the connection to the idle connection queue corresponding to the target external tool service if the connection is in a reusable state; and closing the connection and prohibiting the return of the connection to the idle connection queue if the connection is in a non-reusable state.

9. The method according to claim 1, characterized in that, Based on the generated content returned by the large language model, the business output data is determined and written into the non-control class fields in the global state memory, including: The generated content is input into a preset structured conversion verification process. If the generated content passes the structured conversion verification process, the structured data obtained after verification is determined as the task execution result, and the task execution result is written as the business output data into a non-control class field in the global state memory. If the generated content fails the structured conversion verification process, error message data is generated according to preset error message rules, and the error message data is written as the business output data into a non-control class field in the global state memory.

10. The method according to claim 9, characterized in that, The generated content is input into a preset structured conversion and verification process, including: The generated content is determined as candidate data to be verified, and before the candidate data to be verified passes through the structured transformation verification process, the candidate data to be verified is kept in a temporary processing path; wherein, the temporary processing path is isolated from the write interface of the control class field in the business process status area, and is isolated from the target write path used to store valid business output data in the task execution result field and the metadata field. The structured data conversion verification process includes: performing direct parsing on the candidate data to be verified to determine whether the candidate data conforms to a preset structured data format; if the direct parsing fails, extracting structured data segments that conform to preset boundary identifiers from the candidate data to be verified, and performing parsing on the extracted structured data segments; if the direct parsing succeeds, or if the parsing of the structured data segments succeeds, obtaining a data object to be normalized; if the direct parsing fails and no parsable structured data segments are obtained, determining that the generated content has not passed the structured data conversion verification process. The structured transformation verification process further includes: matching the field names in the data object to be normalized with a preset field alias mapping relationship; if the field names in the data object to be normalized match the preset field alias mapping relationship, replacing the matched field names with the corresponding standard field names; and generating a data object with normalized field names based on the replaced field names and the field names that do not match the preset field alias mapping relationship. The structured conversion verification process further includes: inputting the data object with normalized field names into a strongly typed data model corresponding to the preset data structure requirements; performing at least one of the following on the data object with normalized field names through the strongly typed data model: mandatory field verification, field type verification, default field completion, and field value range verification; generating a type-safe structured data object if the data object with normalized field names meets the verification requirements of the strongly typed data model; and determining that the generated content has failed the structured conversion verification process if the data object with normalized field names does not meet the verification requirements of the strongly typed data model.

11. The method according to claim 1, characterized in that, The current execution node is determined to meet the corresponding state transition triggering conditions, including: The current execution node obtains its corresponding preset state transition trigger condition; reads the process stage field, the task item cursor field, and the task item status field of the current task item to be completed located by the task item cursor field from the business process status area; and reads the event type field and the event payload field from the deterministic business event; and determines whether the deterministic business event matches the preset state transition trigger condition corresponding to the current execution node based on the read process stage field, task item cursor field, task item status field, event type field, and event payload field. The preset state transition triggering conditions include at least one of the following: task item processing completion triggering condition, data ready triggering condition, deterministic processing completion triggering condition, process initialization completion triggering condition, and process cancellation triggering condition; When the current execution node is the execution node used to process the current pending task item located by the task item cursor field, the task item processing completion triggering conditions include: the process stage field represents the task item processing stage; and the value of the task item cursor field is within the valid index range of the task item sequence; and the task item status field of the current pending task item located by the task item cursor field represents an unprocessed state; and the event type field of the deterministic business event matches the allowed processing action type corresponding to the current pending task item; and the business parameters carried by the event payload field of the deterministic business event match the current pending task item; and the current execution node has completed the node processing corresponding to the current pending task item.

12. The method according to claim 1, characterized in that, Based on the fields in the business process status area and the received deterministic business events, update the fields in the business process status area through the write interface of the business process status area, including: Based on the preset state transition triggering conditions met, the corresponding state transition branch is determined; wherein, the state transition branch includes one of the following: process initialization transition branch, task completion transition branch, data ready transition branch, deterministic processing transition branch, and process cancellation transition branch; If the preset state transition trigger condition is the task item processing completion trigger condition, and the event type field of the deterministic business event indicates a task item confirmation event or a task item skipping event, then the corresponding state transition branch is determined to be the task item completion transition branch. If the event type field indicates a task item confirmation event, then through the write interface of the business process status area, the task item status field of the current task item to be completed, located by the task item cursor field, is updated to the confirmed state. If the event type field indicates a task item skipping event, then through the write interface of the business process status area, the task item status field of the current task item to be completed, located by the task item cursor field, is updated to the skipped state. After the task item status field of the current task item to be completed is updated, then through the write interface of the business process status area, the task item cursor field is advanced by one task item position according to the order of the task item sequence. When the cursor field of the advanced task item points to a task item in the task item sequence, the process stage field is updated to the task item processing stage through the write interface of the business process status area; when the cursor field of the advanced task item points to a position after the end of the task item sequence, the process stage field is updated to the termination stage through the write interface of the business process status area.

13. The method according to claim 1, characterized in that, The scheduling response signal includes one of a continue scheduling signal, an event waiting signal, and a process termination signal; the continue scheduling signal is used to instruct the graphical workflow execution engine to continue determining and scheduling the next execution node after the current execution node has completed its current execution; the event waiting signal is used to instruct the graphical workflow execution engine to stop continuously scheduling subsequent execution nodes and wait for the next deterministic business event after the current execution node has completed its current execution; the process termination signal is used to instruct the graphical workflow execution engine to terminate the execution of the business process after the current execution node has completed its current execution. Upon receiving any one of the continue scheduling signal, the event waiting signal, or the process termination signal, the current scheduling call of the current execution node is determined to have returned, and the node processing logic of the current execution node in the current scheduling call is stopped. After the current execution node completes its current execution, a decision is made based on the received scheduling response signal to determine whether to continue scheduling the next execution node.

14. The method according to claim 13, characterized in that, When the scheduling response signal is the event waiting signal, the graph workflow execution engine, based on the scheduling response signal, stops the current continuous scheduling of subsequent execution nodes and waits for the next deterministic business event, including: Stop calling the node routing function to determine subsequent execution nodes during this scheduling process; retain the fields in the business process state area updated by the state transition function as the basis for reading node routing after the next deterministic business event arrives; before stopping the continuous scheduling of subsequent execution nodes, serialize at least a portion of the state data in the global state memory into checkpoint data, and persist the checkpoint data with the instance identifier and / or session identifier corresponding to the business process; Upon receiving the next deterministic business event, the corresponding checkpoint data is read based on the instance identifier and / or session identifier. The checkpoint data is deserialized to reconstruct the business process state area in the global state memory. The process stage field and the task item cursor field are read from the reconstructed business process state area, and the node routing function is called based on the read process stage field and task item cursor field to determine the corresponding execution node.

15. A computer program product, characterized in that, It stores at least one instruction, which, when executed by a processor, implements the method as described in any one of claims 1-14.

Images