A workflow engine management method and system for an AI service platform

Abstract

The application discloses a kind of workflow engine management method and system for AI service platform, it is related to computer workflow execution control and abnormal recovery technical field.Workflow control end establishes workflow execution batch, and workflow topology, node execution configuration, model service, prompt configuration, retrieval index, interface contract and external action control version are bound with batch number;Node task is issued according to workflow topology, and node execution serial number, predecessor input reference, remote call number, output object, content digest and call receipt are recorded, and node consumption relationship is formed;Node input, version, output and receipt are checked, and node result reuse state is formed;When node interruption, version invalidation, digest conflict, call state is unknown and input reference invalid, according to exception node and node consumption relationship, form affected execution branch;Reverse check node result and external action state, register recovery anchor point and recovery entry, and reissue node task according to recovery entry.

Description

Technical Field

[0001] This invention relates to the field of computer workflow execution control and anomaly recovery technology, specifically a workflow engine management method and system for an AI service platform. Background Technology

[0002] AI service platforms typically utilize workflow engines to connect nodes such as data preprocessing, knowledge retrieval, model inference, result verification, and external tool invocation according to dependencies, and control the execution of workflow instances based on the node's running status. Existing workflow engines, when encountering node timeouts, service interruptions, or instance anomalies, usually reschedule from failed nodes based on their success, failure, or incomplete execution status, or directly reuse the output of completed nodes.

[0003] The output of AI service nodes depends not only on the input data but also on the model version, prompt configuration, retrieval index, service instance, and the execution status of external interfaces. After a workflow interruption, these operating conditions may have changed, and external interfaces may still be in a state where the request has been executed but no response has been returned. Existing node status records are insufficient to indicate whether completed results still match the current execution conditions, or whether the result has been consumed by downstream nodes. This makes it difficult for the workflow engine to accurately determine the scope of reusable nodes and the entry point for resuming execution, easily leading to the continued transmission of invalid intermediate results, the mixing of different versions of results, and repeated calls to external services. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a workflow engine management method and system for AI service platforms, in order to solve the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a workflow engine management method for an AI service platform, comprising the following steps: S1. The workflow control terminal establishes a workflow execution batch, reads the workflow topology version and the node execution configuration version corresponding to each node, and reads the corresponding model service version, prompt configuration version, retrieval index snapshot version, interface contract version and external action control version according to the node type, and binds each version reference to the batch number. S2. Distribute node tasks to node services according to the workflow topology, record the node execution sequence number, predecessor input reference, service instance number, output object number and output content summary, record the remote call number and call receipt when a node makes a remote call, and form node consumption relationship based on the subsequent node's record of reading the output object. S3. Verify the node's input references, version references, output objects, output content summaries, call receipts, and external action receipts to establish the node result reuse status, and register nodes lacking necessary records as pending verification status. S4. When a preset execution exception occurs during workflow execution, the preset execution exception is any one of node interruption, version failure, output summary conflict, unknown call status, and input reference failure. Starting from the abnormal node and node consumption relationship, the successor node that has read the failed output is identified, the affected execution branch is formed, and the reusable state that the affected node has formed is revoked. S5. Verify the reuse status of node results and external action status along the actual predecessor input paths of each affected execution branch. Register the nearest node with reusable output as the recovery anchor point, register the first node that needs to be re-executed after each recovery anchor point as the recovery entry point, and reissue the node task according to the recovery entry point.

[0006] Furthermore, S1 includes: Write the workflow topology version to the version reference list, and write the node execution configuration version, as well as the model service version, prompt configuration version, retrieval index snapshot version, interface contract version, and external action control version to the version reference list according to the node number. Verify the availability status, input field types, output field types, and object type correspondences of each version in the version reference list; After verification, the version reference list and batch number are written into the batch version record, and the batch version record is set to a frozen state. When frozen, the node task references the version corresponding to the node number in the batch version record.

[0007] Furthermore, S2 includes: A node task is identified by its batch number, node number, and node execution sequence number. The predecessor input reference of the starting node is written with the batch input object number, input content summary and input object type; the predecessor input reference of a non-starting node is written with the predecessor node number, predecessor execution sequence number, output object number, output content summary and output object type. When the output object has been persistently written, and the node's completion message matches the node execution sequence number, output object number, and output content summary in the object's metadata, a node output commit record is formed.

[0008] Furthermore, S2 also includes: Before a successor node reads the output object of its predecessor, it sends an input binding message; after reading is completed, it sends a read completion message; and after entering the execution phase, it sends a start confirmation message. Both the read completion message and the start confirmation message reference the same input binding message. When the batch number, successor node number, successor execution sequence number, predecessor execution sequence number and output object number recorded in the input binding message are consistent with the node task and node output submission record, and the actual output object number and read content summary recorded in the read completion message are consistent with the node output submission record, the node consumption relationship is written to the consumed status. Write the "bound but not read" state only when an input binding message is generated; write the "read but not started" state when both an input binding message and a read completion message are generated but no start confirmation message is generated; write the "consumption conflict" state when there is an inconsistency between the execution sequence number, output object number, and content summary.

[0009] Furthermore, S3 includes: If a node execution record has one of the following issues: version inconsistency, invalid input reference, output summary conflict, duplicate external effect, or call number conflict, the node result reuse status will be written to the non-reusable status. When the node input reference, version reference, node output commit record and corresponding node type call receipt are complete and there are no conflicts as mentioned above, the node result reuse status is written to the reusable status. If there is no conflict as described above and there are missing node completion messages, object metadata, call completion receipts, and external action receipts, the node result reuse status is written to the pending status, and the missing records are retrieved after the corresponding basic service is restored to accessibility.

[0010] Furthermore, S4 includes: After an exception record is generated, the output object of the exception node is written to the "prohibit new binding" state, and new node tasks that reference the output object are stopped. When a node's consumption relationship is in either the consumed state or the read-but-not-started state, the corresponding successor node will be included in the affected execution branch. When a node consumption relationship is in a bound but unread state, cancel the corresponding input binding and pending task, include the corresponding successor node in the affected execution branch, and stop extending downwards along that successor node; When the output of the affected node has been read by the next node, continue to identify the successor node along the corresponding node consumption relationship, and revoke the reusable state that the affected node has formed.

[0011] Furthermore, S4 also includes: When the affected execution branch passes through an external action node, it reads the external action call record and the external action control version. When an external action receipt records a unique external object number and the external action control version records an irrevocable flag, the external action node is registered as an external effect boundary. When the external action control version records the cancellation interface, the external action node is registered as a node to be cancelled. The external action token, external object number and cancellation status in the cancellation completion receipt are consistent with the external action call record, and the external object status after cancellation is consistent with the status record before the action. The external effect boundary is then released. When the interface gateway and external tool services are in an accessible state, the status is checked three times consecutively according to the cycle of the workflow control terminal performing accessibility status verification on the basic services. If a clear processing status is still not returned, the automatic recovery of the corresponding execution branch is stopped.

[0012] Furthermore, S5 includes: Starting from the unreusable nodes in the affected execution branches, verify the actual predecessor input references level by level in reverse along the node execution records; If the predecessor node is in a reusable state, the result reuse record has not been revoked, the output object exists, the output content summary is consistent with the verification, the version reference is consistent with the batch version record, and there is no consumption conflict in the node consumption relationship, then write the predecessor node into the recovery anchor candidate record. Based on the node hierarchy referenced by the actual predecessor input, select the candidate record of the recovery anchor point closest to the unreusable node as the recovery anchor point; Read backward from the recovery anchor point along the corresponding affected execution path, and register the first node that needs to be re-executed as the recovery entry point.

[0013] Furthermore, S5 also includes: Based on the recovery anchor point, recovery entry point, node result reuse status and external effect boundary, a recovery execution list is formed. The recovery execution list registers one of the following processing actions for each node: reuse, re-execution, waiting for verification, cancellation of external actions, and termination of branches. The nodes that need to be re-executed retain their original node numbers and generate new node execution sequence numbers. The newly formed predecessor input references point to the original output objects registered for reuse and the new output objects formed in this re-execution, respectively. The original non-reusable output object is written with an invalidation flag and a replacement execution sequence number. The late message returned by the original node execution sequence number continues to be written to the original node execution record, and the running status corresponding to the new node execution sequence number is not updated.

[0014] The present invention also provides a workflow engine management system for an AI service platform, comprising: The workflow control terminal is used to create workflow execution batches, read the workflow topology version and the node execution configuration version corresponding to each node, and read the corresponding model service version, prompt configuration version, retrieval index snapshot version, interface contract version and external action control version according to the node type, and bind each version reference to the batch number; The node execution processing unit is used to issue node tasks according to the workflow topology, record the node execution sequence number, predecessor input reference, service instance number, output object number and output content summary, record the remote call number and call receipt when a node makes a remote call, and form node consumption relationship based on the subsequent node's reading record of the output object; The result reuse verification unit is used to verify the node's input reference, version reference, output object, output content summary, call receipt and external action receipt to form the node result reuse status; The exception branch processing unit is used to form the affected execution branch based on the exception node and the node consumption relationship when an exception occurs during workflow execution, and to cancel the result reuse status of the affected node. The recovery execution unit is used to verify the reuse status of node results and the status of external actions in reverse along the affected execution branch, register the recovery anchor point and recovery entry point, and reissue the node task according to the recovery entry point.

[0015] Compared with existing technologies, the present invention provides a workflow engine management method and system for AI service platforms, which has the following beneficial effects: 1. By establishing workflow execution batches, the workflow topology version, node execution configuration version, model service version, prompt configuration version, retrieval index snapshot version, interface contract version, and external action control version are frozen and bound. Combined with node input references, output content summaries, call receipts, and node consumption relationships, a node result reuse status is formed. When a workflow exception occurs, the affected execution branch is formed according to the actual consumption range of the failed output, and the recovery anchor point and recovery entry point are determined in reverse. This solves the technical problem of existing workflow engines that it is difficult to determine whether completed results can continue to be reused and where to start the recovery execution after version changes and node exceptions. It also avoids the mixed use of node results from different versions and the continued propagation of failed results.

[0016] 2. By verifying the receipts, completion receipts, external action tokens, and external object numbers of external tool calls, and by establishing external effect boundaries based on the undoing capability of external actions, nodes that have already formed external effects will not be executed repeatedly due to lost responses. At the same time, parallel branches unaffected by invalid inputs can retain their original outputs, and re-executed nodes use new node execution sequence numbers and are isolated from the original execution records, thereby improving the continuity, traceability, and execution consistency of the AI ​​service workflow anomaly recovery process. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a workflow engine management method for an AI service platform according to the present invention. Figure 2This is a schematic diagram of the structure of a workflow engine management system for an AI service platform according to the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1: Figure 1 A workflow engine management method for an AI service platform is presented, which involves executing the following steps in sequence: S1. The workflow control terminal establishes a workflow execution batch, reads the workflow topology version and the node execution configuration version corresponding to each node, and reads the corresponding model service version, prompt configuration version, retrieval index snapshot version, interface contract version and external action control version according to the node type, and binds each version reference to the batch number. S2. Distribute node tasks to node services according to the workflow topology, record the node execution sequence number, predecessor input reference, service instance number, output object number and output content summary, record the remote call number and call receipt when a node makes a remote call, and form node consumption relationship based on the subsequent node's record of reading the output object. S3. Verify the node's input references, version references, output objects, output content summaries, call receipts, and external action receipts to establish the node result reuse status, and register nodes lacking necessary records as pending verification status. S4. When a preset execution exception occurs during workflow execution, the preset execution exception is any one of node interruption, version failure, output summary conflict, unknown call status, and input reference failure. Starting from the abnormal node and node consumption relationship, the successor node that has read the failed output is identified, the affected execution branch is formed, and the reusable state that the affected node has formed is revoked. S5. Verify the reuse status of node results and external action status along the actual predecessor input paths of each affected execution branch. Register the nearest node with reusable output as the recovery anchor point, register the first node that needs to be re-executed after each recovery anchor point as the recovery entry point, and reissue the node task according to the recovery entry point.

[0020] S1 is specifically implemented as follows: The workflow control terminal receives the workflow definition file that has passed the release validation. Release validation checks the nodes and connections recorded in the workflow definition file, verifying that node numbers are unique within the current definition file, that both predecessor and successor node numbers point to actual existing nodes, that there are no directed loops in the node connections from successor nodes back to predecessor nodes, that the starting node can reach the ending node along the connections, that each exit of a branch node registers the branch entry conditions, that the merging node registers all input sources, and that the output object type of the predecessor node matches the input object type of the successor node. If any validation item is not met, the workflow definition file remains unreleased and the workflow batch creation process is not initiated.

[0021] After the release verification passes, the workflow release repository generates a workflow topology version for the workflow definition file. Each workflow topology version corresponds to a frozen topology snapshot, which records node numbers, node types, predecessor node numbers, successor node numbers, input object types, output object types, branch entry conditions, and merging relationships. When nodes are added, deleted, connection relationships change, input object types change, output object types change, or branch entry conditions change, the workflow release repository generates a new workflow topology version.

[0022] Modifying only the file name, file location, and description does not create a new workflow topology version. The workflow release repository generates a release sequence number and content verification identifier upon version entry. The workflow control terminal uses the subsequently read release sequence number and content verification identifier to identify the topology snapshot, avoiding using file modification time as the version identifier.

[0023] The workflow control terminal reads the node execution configuration version according to the node number in the workflow topology version. The node execution configuration version is generated by the node release repository after the node program passes startup verification, and is bound to the corresponding node number through the node version reference table. The node version reference table records the node runtime program identifier, runtime component identifier, startup parameter file identifier, environment configuration file identifier, and resource limit configuration identifier item by item.

[0024] When any identifier changes, the node release repository generates a new node execution configuration version. The node execution configuration version remains unavailable if the node runtime fails to load, startup parameters are missing, environment configuration files cannot be read, or resource limitation configurations are unacceptable to the runtime environment.

[0025] In a workflow topology version, each model inference node is bound to a model service version. The model service version is generated by the model service after it has completed model file loading, runtime probing, and output field verification. The model service version records the model identifier, weight release batch, adaptor component identifier, and output field definitions, and is bound to the corresponding model inference node via the model node number. If the model service only returns a network address but not the model service version, the corresponding model inference node will not pass version verification. When a workflow contains multiple model inference nodes, each model inference node stores its own model service version; a single generic version is not used to replace the actual model version called by different nodes.

[0026] The hint configuration version is generated by the hint configuration repository after the hint configuration file is published and is bound to the corresponding model inference node. The hint configuration file records the hint content, variable names, variable binding sources, variable population positions, output constraints, and stop flags. Variable binding sources are limited to registered fields in the predecessor input object and fixed configuration values ​​written during publication. Every required variable in the hint configuration file has a binding source. The hint configuration version passes verification when the variable type matches the input field type registered in the model service version. If there are unbound required variables, duplicate variable names, or inconsistent variable types, the hint configuration version remains unavailable.

[0027] In the workflow topology version, each knowledge retrieval node is bound to a retrieval index snapshot version. The retrieval index snapshot version is generated by the retrieval service after writing index data, sealing the index file, and verifying read operations, and is then bound to the corresponding knowledge retrieval node. Once the retrieval index snapshot enters the sealed state, it is only available for reading and does not accept new data or overwrite writes. The workflow control terminal can use the snapshot number to read index metadata. When the actual snapshot number returned by the retrieval service matches the bound number, the retrieval index snapshot version passes verification. If the frozen snapshot does not exist, is in a reconstruction state, or the actual returned snapshot number is inconsistent, the corresponding knowledge retrieval node fails version verification.

[0028] The interface contract version is generated by the interface release repository based on the interface definition file and bound to the node number that actually calls the corresponding interface. The interface contract version records the interface address, request method, request field names, request field types, required field status, response field names, response field types, error codes, and version validity status. The workflow control end maps the request fields in the interface contract version to the node input fields one by one, and the response fields to the node output fields one by one. When the request field names, field types, and required field statuses match the node input object type, and the response field names and field types match the node output object type, the corresponding interface contract version is registered as available.

[0029] When a node task executes an API call, it retrieves the required request fields recorded in the API contract version from the node input object and forms a call request according to the request field types. After the API returns, it writes the returned content to the node output object according to the response field names and response field types. If a required request field is missing, the request field types are inconsistent, the response field cannot be written to the node output object, or the API contract version is in an inactive state, the corresponding node task is stopped from being issued, and the inconsistent API contract status is recorded.

[0030] The external action control version is generated after the external tool interface completes duplicate request verification and receipt verification, and is bound to the node that changes the external system data. The external action control version records the external action token field, received receipt field, completed receipt field, external object number field, duplicate request processing method, pre-action status reading method, pre-action status field, cancellation interface identifier, cancellation completion receipt field, cancellation status return field, and irrevocable flag.

[0031] The interface gateway can recognize external action tokens and return the original processing status when the same external action token is submitted repeatedly. When the external tool interface can return receipt and completion receipts, the external action control version passes the basic verification. When an external action can be undone, the pre-action status reading method, pre-action status field, undone interface identifier, undone completion receipt field, and post-undone status return field must be complete. When an external action cannot be undone, the external action control version writes an irrevocable flag and does not register invalid undone interface identifiers.

[0032] The workflow control terminal establishes a version verification record, writing the workflow topology version, the execution configuration version of each node, the model service version, the prompt configuration version, the retrieval index snapshot version, the interface contract version, and the external action control version into the same version reference list according to the node number. Version verification passes when each version in the version reference list is in an available state and the input fields, output fields, and object types between versions correspond.

[0033] If any version is missing, withdrawn, in a stopped service state, or has inconsistent fields, the workflow control terminal generates a version blocking record. The version blocking record records the workflow definition number, node number, blocked version type, blocked version number, blocking reason, and discovery time, and stops the creation of workflow execution batches. After the blocked version is restored, the workflow control terminal re-verifies the complete version reference list, not just the single version that was previously blocked.

[0034] After version verification is successful, the workflow control terminal generates a batch number. The batch number is formed by concatenating the platform instance number, creation date, daily sequence number, and verification segment. The platform instance number originates from the running instance identifier of the workflow control terminal, the creation date comes from the platform's unified time service, the daily sequence number is generated from the database batch sequence, and the verification segment is generated by the platform's security component. When the unified time service is unavailable, the workflow control terminal stops creating new workflow execution batches to prevent discrepancies between batch creation times and subsequent version exit times.

[0035] The workflow control terminal writes the batch number and version reference list into the batch version record and freezes the batch version record. In the frozen state, subsequent node tasks only reference the version corresponding to the node number in the batch version record. Normal updates to service registration information and configuration repositories do not change the version reference of the current batch. After the batch version record is formed, the workflow control terminal provides S2 with the batch number, workflow topology version, and node version reference table as the basis for node task distribution and node execution record establishment.

[0036] When a frozen version is forcibly terminated during batch execution, the version provider sends a version termination notification. The notification records the terminated version number, reason for termination, termination time, and affected node numbers. The workflow control terminal verifies that the terminated version number matches the batch version record, then writes the corresponding node into the version invalidation record. It does not overwrite the original batch version record with a new version, nor does it directly revoke other nodes that do not reference that version. If the version provider does not send a version termination notification, the workflow control terminal reads the health check results from the service registry.

[0037] In this embodiment, the health check cycle is five seconds, derived from the probe configuration already in operation in the platform service registry. If the same frozen version returns unavailable for three consecutive health check cycles, the workflow control terminal generates a version failure record. Three consecutive cycles correspond to a continuous unavailability time of fifteen seconds, which is determined through service disconnection and network jitter tests to eliminate false judgments caused by single probe timeouts. The version failure record serves as input for S3 to form the node result reuse status and for S4 to identify affected execution branches, and does not directly re-execute the node task in the S1 stage.

[0038] S2 is specifically implemented as follows: The workflow control terminal reads the workflow execution batch, frozen workflow topology version, and node version reference table generated by S1, and determines the actual node connection relationships entered in this execution based on the workflow topology version. Nodes without predecessor nodes in the workflow topology version are used as starting nodes, and the input of the starting node comes from the batch input object corresponding to the workflow execution batch. The batch input object is formed by the AI ​​service platform receiving the original request and writing it into the object storage. After the object storage completes the persistent write, it returns the input object number and simultaneously saves the input content summary and input object type.

[0039] The workflow controller writes the input object number, input content summary, and input object type to the batch input reference. The starting node uses the batch input reference as its predecessor input reference. No starting node task is generated if the batch input object has not yet been persisted, the input content summary is missing, or the input object type is inconsistent with the input object type registered by the starting node.

[0040] The workflow control terminal generates node tasks according to the connection order in the workflow topology version. Each node task contains the batch number, node number, current node execution sequence number, predecessor input reference, node execution configuration version, target service type, and task distribution sequence number. The node execution sequence number increments independently within the same batch and for the same node number. The first execution uses the first execution sequence number, and subsequent executions after anomaly recovery use the new execution sequence number. The node task, call receipt, and output object corresponding to the original execution sequence number are retained and not overwritten by the data corresponding to the new execution sequence number.

[0041] The predecessor input reference of a non-starting node originates from the node output commit record formed by the predecessor node. The node output commit record is formed when the output object is persisted, the object storage returns the output object number, the output object number in the node completion message matches the object metadata, and the output content digest in the node completion message matches the output content digest saved in the object storage. The node output commit record includes the predecessor node number, predecessor execution sequence number, output object number, output content digest, and output object type. The node output commit record only indicates that the predecessor output has been committed; it does not replace the node result reuse state formed by S3.

[0042] When a current node has multiple actual predecessor nodes, the workflow control terminal reads the node output commit records of each predecessor node and writes them into the predecessor input references one by one. When there are branch nodes in the workflow topology, the workflow control terminal determines the selected connection for this execution based on the branch entry records written by the branch nodes. Connections not selected are not written into the predecessor input references of subsequent nodes. Merging nodes only wait for the predecessor input references corresponding to the branches actually entered in this execution, and do not wait for outputs from branches not entered.

[0043] If any actual predecessor node has not yet formed a node output commit record, the output object has been marked as invalid, or the type of the output object is inconsistent with the type of the input object registered by the current node, the current node remains in the pending state and does not generate a task distribution message.

[0044] After a node task is written to the message queue, the message queue generates a unique task distribution sequence number for the task. When a node service receives a task, the message queue generates a task reception sequence number, and the node service returns a task reception message to the workflow control end. The task reception message contains the batch number, node number, node execution sequence number, task distribution sequence number, task reception sequence number, and service instance number. The service instance number is derived from the identifier of the running instance that actually received the node task and is not replaced by the service name or network address.

[0045] After verifying that the batch number, node number, node execution sequence number, and task distribution sequence number in the task reception message match the node task, the workflow control terminal establishes a node execution record and writes the node's running status to "in execution." When the same task distribution sequence number is returned repeatedly in the task reception message, the workflow control terminal uses the reception message corresponding to the valid task reception sequence number stored in the message queue as the standard, and writes the remaining reception messages into the duplicate reception record, without creating a new node execution record.

[0046] When messages are received repeatedly from different service instances, the workflow control terminal sends a stop execution notification to the invalid service instance to prevent the execution sequence number of the same node from being processed by multiple service instances simultaneously.

[0047] When the node service does not return a task receipt message, the workflow control terminal queries the message queue for the retrieval record. If the task is still in an unretrieved state, the node remains in a pending state and continues to wait using the original node execution sequence number. If a retrieval record has been created in the message queue, but the workflow control terminal has not received the corresponding task receipt message, the node enters a pending state, and the workflow control terminal retrieves the task receipt message from the message queue based on the task issuance sequence number.

[0048] Before the task is completed, the same node task will not be reissued to other service instances. If the message queue explicitly returns that the original task has not been claimed and the original task message has expired, the workflow control terminal will cancel the original task issuance sequence number and generate a new task issuance sequence number for the same node.

[0049] During node execution, a remote call number is generated each time the model service, retrieval service, and external tool service are invoked. The remote call number is composed of the batch number, node number, node execution sequence number, and call sequence number. Within the same node execution sequence number, the call sequence number increments according to the actual order in which the requests were issued; different node execution sequences do not share a call sequence number. Nodes that have not performed a remote call do not generate a remote call number, and an empty number is not used as evidence that a remote call has been completed.

[0050] When an external action node first generates a request to modify external system data, the workflow control terminal generates an external action token based on the batch number, node number, and external action sequence number, and writes the external action token to the node task and external action call record. The external action sequence number increments sequentially according to the actual order in which the external action request is generated within the same batch number and node number range, and the generated external action token remains unique within the interface gateway management scope.

[0051] For the same external action, the processing status query, call receipt retrieval, and resending after the interface gateway explicitly returns that the original request was not received, all use the original external action token and do not add an external action sequence number; different external actions generate new external action sequence numbers and external action tokens respectively. Before receiving an external action request, the interface gateway verifies whether the external action token already exists. If the external action token already exists, it returns the original reception status, processing status, and external object number corresponding to that token, without creating a new external action record.

[0052] When the external action control version registration is valid and revoked via the interface, the workflow control terminal obtains the current state of the target external object according to the pre-action state reading method before sending the external action request, and forms a pre-action state record. The pre-action state record contains the external action token, the target external object identifier, the object's existence status, the state version number, the state content summary, and the time the state was obtained.

[0053] When an external action involves creating an object, the pre-action state record writes the object's existence status to the non-existent status. When an external action involves updating, deleting, or changing the status of an existing object, the pre-action state record writes the object's existence status to the existing status, and saves the state version number and state content summary before the action execution. If an external action that can be undone has not yet formed a pre-action state record, no corresponding external action request is sent, and the node is written to the pending state.

[0054] The external action call record contains the remote call number, external action token, action pre-state record number, call reception receipt, call completion receipt, external action receipt, and external object number.

[0055] After receiving a request, the remote service returns a call reception receipt, which includes the remote call number, service instance number, reception time, and reception result. After completing processing, the remote service returns a call completion receipt, which includes the remote call number, response number, completion time, and result reference. The result references for model and retrieval services correspond to the temporary number of the service output object, while the result references for external tool services correspond to the external object number or external processing record number. The workflow control terminal associates the call reception receipt and call completion receipt according to the remote call number. If the remote call numbers in the two receipts are inconsistent, they are saved separately and not included in the same remote call.

[0056] When a call receive receipt exists but a call completion receipt is missing, the workflow control terminal retains the original remote call number and queries the remote service processing status using the original remote call number, without immediately generating a new remote call number. If the remote service explicitly returns that the request was not received, the current remote call record is written to the "not received" status; if the remote service returns "processing," the current remote call record is written to the "processing" status; if the remote service returns "completed," the original call completion receipt is retrieved. If the query result cannot be obtained, the current node enters a pending state, and S3 combines this with the call record to form a node result reuse status.

[0057] After completing its processing, a node writes the complete output data to object storage. When a node produces multiple field results, each field result is written to the same output object according to the structure registered by the node's output object type, preventing subsequent nodes from selecting from multiple unbound objects.

[0058] Before the output content summary is generated, the object storage performs normalized serialization on the complete output data according to the fixed serialization rules corresponding to the output object type in the node execution configuration version. Object fields are arranged in the order registered for the output object type. Character data uses a unified character encoding, and numerical data is written according to the representation format registered for the corresponding field type. Null values ​​are marked with a unified null value marker. Ordered data retains its original order, while unordered data is sorted according to the element identifier or the normalized element content. Business time data belonging to the fields registered for the output object type is retained in the summary input; object storage address, object write time, service instance runtime identifier, and temporary information generated during the write process are not written to the summary input.

[0059] Object storage uses fixed digest rules recorded in the node execution configuration version to form an output content digest for the complete, normalized, and serialized output data. Under the same node execution configuration version, data with the same output object type and identical output field content forms the same output content digest. After completing the persistent write, object storage generates an output object number and writes the batch number, node number, node execution sequence number, output object type, output content digest, and write time into the object metadata; temporary addresses returned during the write process are not used as output object numbers.

[0060] After obtaining the output object number, the node service sends a node completion message. The node completion message includes the batch number, node number, node execution sequence number, output object number, output content summary, and the remote call number associated with this execution. The workflow control terminal reads the object metadata and complete output data from the object storage, verifying the batch number, node number, node execution sequence number, output object number, output object type, and output content summary. If all match, a node output commit record is created; if any item is inconsistent, no node output commit record is created, and an output summary conflict record or output reference conflict record is written for further processing by S3 and S4.

[0061] When the same node returns a node completion message with the same sequence number, the workflow control terminal first checks the output object number and the output content summary. When the duplicate message corresponds to the same output object number and the same output content summary, only one node output submission record is retained; when the duplicate message corresponds to different output object numbers or different output content summaries, none of the outputs are selected to continue execution, the current node enters the pending verification state, and all conflicting messages and object references are saved.

[0062] Before a successor node reads the predecessor's output object, it sends an input binding message to the workflow control terminal. The input binding message includes the batch number, successor node number, successor execution sequence number, predecessor node number, predecessor execution sequence number, output object number, and an output content summary. The workflow control terminal verifies that the input binding message matches the predecessor node's node output submission record before allowing the successor node to read the corresponding output object. Successor nodes must not read the most recently generated output object based on the predecessor node number; they must read it according to the predecessor execution sequence number and output object number specified in the predecessor input reference.

[0063] After a successor node completes object reading and verifies the read content summary, it sends a read completion message. The read completion message includes the input binding message number, the actual output object number read, the read content summary, and the read completion time. When a successor node uses this input to enter the execution phase, it sends a start confirmation message, which includes the successor node number, the successor execution sequence number, the task reception sequence number, and the input binding message number.

[0064] The workflow control terminal establishes node consumption relationships based on input binding messages, read completion messages, and start confirmation messages. The read completion message and start confirmation message reference the same input binding message. The batch number, successor node number, successor execution sequence number, predecessor node number, predecessor execution sequence number, and output object number recorded in the input binding message must match the node output submission records of the node task and the predecessor node, respectively. When the actual output object number recorded in the read completion message matches the output object number in the input binding message, and the read content summary matches the output content summary of the predecessor node, the node consumption relationship is written to the consumed state.

[0065] Only when an input binding message is received is the node consumption relationship written to the "bound but not read" state; when the input binding message and the read completion message referencing the input binding message are complete, but the start confirmation message referencing the same input binding message is missing, the node consumption relationship is written to the "read but not started" state; when the input binding message is inconsistent with the node task and the node output submission record, the read completion message or the start confirmation message references other input binding messages, the actual output object number is inconsistent, and the read content summary is inconsistent, the node consumption relationship is written to the "consumption conflict" state, and subsequent nodes stop processing the input.

[0066] When a predecessor node connects to multiple successor nodes, the workflow control terminal establishes node consumption relationships according to the successor node number and execution sequence number. When a successor node reads multiple predecessor outputs, each predecessor output forms a separate node consumption relationship. After the node consumption relationships are formed, S3 establishes the node result reuse status based on the predecessor input reference, call receipt, node output commit record, and node consumption relationship. S4 identifies the successor nodes actually affected by the failed output based on the consumed status and consumption conflict status.

[0067] S3 is specifically implemented as follows: The workflow control terminal uses batch number, node number, and node execution sequence number to locate node execution records and reads node input references, node execution configuration versions, node output submission records, remote call records, and batch version records. The node input reference of the starting node corresponds to the batch input reference formed by S2, and the node input reference of non-starting nodes corresponds to the predecessor input reference. Remote call records are stored according to node type, including model call records, retrieval call records, and external action call records. Based on the above records, the workflow control terminal establishes the node result reuse status, which is divided into reusable status, non-reusable status, and pending verification status.

[0068] The three states are formed according to a fixed priority order. If any deterministic anomaly exists (version inconsistency, invalid input reference, output digest conflict, duplicate external effects, or call number conflict), the node enters a non-reusable state and will not be able to transition to a reusable state even if other records are complete. If no deterministic anomaly exists and all records required for the node type are complete, the node enters a reusable state. If no deterministic anomaly exists but necessary records are temporarily missing, basic services are temporarily inaccessible, or remote calls are still being processed, the node enters a pending state. This priority order is used to avoid different processing conclusions when the same node simultaneously meets multiple state conditions.

[0069] The workflow control terminal first performs node input verification. If the batch input object corresponding to the starting node exists in the object storage, the input summary matches, and the input object type matches the type registered with the starting node, the starting node input verification passes. For each predecessor input reference of a non-starting node, if it corresponds to an actual existing node output submission record, and the predecessor execution sequence number, output object number, output summary, and output object type are consistent, and the predecessor node is not in a non-reusable state, the non-starting node input verification passes.

[0070] When multiple predecessor inputs are referenced, each one is verified individually; passing one does not guarantee passing all inputs. If any input object is missing, the digest is inconsistent, the object type is mismatched, the execution sequence number is inconsistent, or the predecessor node has entered a non-reusable state, the current node enters a non-reusable state. If object storage is temporarily inaccessible, the current node enters a pending verification state; access failure is not automatically considered as an object being missing.

[0071] For data processing nodes that do not call remote services, after the input verification is passed, the workflow control terminal checks whether the node execution configuration version is consistent with the corresponding node's node execution configuration version in the batch version record, and checks whether there is a forced invalidation record for that version. If the service instance is normally taken offline but the node execution configuration version is not marked as file corruption, safe exit, or invalid running results, it will not affect the eligibility for reuse of the already generated results.

[0072] When a node's execution configuration version is consistent, there are no forced failure records, the node's output commit records are complete, the output object still exists, and the output content summary is consistent, the data processing node enters a reusable state. When a node's execution configuration version is inconsistent, there are forced failure records, the output object is missing, or the output content summary conflicts, the data processing node enters a non-reusable state. When any one of the node's completion message, object metadata, or output content summary is temporarily missing, the data processing node enters a pending verification state.

[0073] For model inference nodes, the workflow control terminal reads the model call record after completing node input verification. Each model call record corresponds to a remote call number and includes the model service version, model instance number, prompt configuration version, actual input object number, actual input content summary, call reception receipt, call completion receipt, and service response number. When a model inference node uses the output of a knowledge retrieval node, the model call record also includes the retrieval index snapshot version; if the model inference node does not use the retrieval results, writing the retrieval index snapshot version is not required.

[0074] The workflow control end verifies each actual input object number and actual input content summary in the model call record against the node input reference item by item. The actual input matches the node input reference; the model service version matches the batch version record; the prompt configuration version matches the batch version record; the model instance number corresponds to the service instance that actually performed the call; the call reception receipt and call completion receipt use the same remote call number; and the node output submission record is complete and the output content summary matches the verification. When these conditions are met, the model inference node enters a reusable state.

[0075] If any of the following is inconsistent: model service version, prompt configuration version, or applicable retrieval index snapshot version; the actual input object is inconsistent with the node input reference; there is a conflict in the remote call number; or there is a forced invalidation record in the model service version, the model inference node will enter an unusable state.

[0076] When the model service version is the same but the model instance number is temporarily missing, when the call receipt exists but the call completion receipt has not yet been returned, or when the service response number exists but the node output submission record has not been completed, the model inference node enters the pending state. The model instance number is only used to confirm which running instance actually completed the call and does not revoke the already formed reusable state even if the original model instance exits normally after the call is completed. Only when the model service version is explicitly marked as output untrustworthy, file corrupted, or security-forced invalid, will a completed model inference node enter the unreusable state.

[0077] For knowledge retrieval nodes, the workflow control terminal reads the retrieval call record. This record includes the remote call number, retrieval service instance number, actual retrieval index snapshot version, retrieval request number, retrieval response number, call receipt receipt, and call completion receipt. Once the node input verification is successful, the actual retrieval index snapshot version matches the batch version record, the call receipt receipt and call completion receipt use the same remote call number, the retrieval response object has formed a node output submission record, and the output content summary is verified to be consistent, the knowledge retrieval node enters a reusable state.

[0078] When the retrieval service automatically uses other index snapshots, the retrieval response number corresponds to different remote call numbers, there are conflicts in the retrieval output summary, or there are data corruption and invalid records in the retrieval index snapshot version, the knowledge retrieval node enters a non-reusable state.

[0079] Nodes that have completed a retrieval and generated full output will not automatically enter a non-reusable state simply because the corresponding index snapshot stops providing new queries at a later time. The workflow control end verifies existing retrieval results based on the actual retrieval index snapshot version and output content summary already saved in the retrieval call record. Existing retrieval results only enter a non-reusable state when the index snapshot is explicitly marked as corrupted, published incorrectly, or the results are invalid.

[0080] When a knowledge retrieval node has not yet completed its retrieval and the frozen retrieval index snapshot is temporarily unreadable, the node enters a pending state. When the retrieval service explicitly returns that the snapshot has been deleted and cannot be recovered, the node enters a non-reusable state. This process distinguishes between whether existing retrieval results can be reused and whether subsequent retrievals can be performed again, avoiding the direct negation of existing, fully saved output based solely on the snapshot's current inaccessibility.

[0081] For nodes that modify external system data, the workflow control terminal, in addition to performing node input verification and node execution configuration version verification, also reads external action call records. These records contain the remote call number, external action token, pre-action status record number, call reception receipt, call completion receipt, external action receipt, and external object number. The call reception receipt indicates that the interface gateway has received the request corresponding to the external action token; the call completion receipt indicates that the external tool service has completed processing; and the external action receipt indicates that the external system has created the corresponding external object.

[0082] The call receipt, call completion receipt, and external action receipt all use the same remote call number and the same external action token. The external object number is unique. When the returned object in the node's output submission record is consistent with the external action receipt, the external action node enters the reusable state.

[0083] When the interface gateway explicitly returns that the request was not received, the node has no reusable execution result and enters a non-reusable state. If the call reception receipt exists but the call completion receipt is missing, the node enters a pending state and queries the processing status using the original remote call number and the original external action token. If the call completion receipt exists but the external action receipt is missing, it continues to query the original external object without resending the external action request.

[0084] The same external action token can correspond to multiple different external object numbers, and the same remote call number can correspond to different processing results. When the external object number in the node's output commit record is inconsistent with the external action receipt, the external action node enters a non-reusable state and stops issuing tasks to the next execution branch. Whether an external action can be undone is not a condition for S3 to determine whether the result can be reused. The undone interface and the irrevocable flag are used by S4 and S5 when identifying the affected execution branch and forming a recovery entry point.

[0085] When necessary records are temporarily missing, the workflow control terminal retrieves the records according to the five-second health check cycle registered in S1, with each node awaiting verification retrieving records for three consecutive cycles. The retrieving objects are determined by the node type: data processing nodes retrieve node completion messages and object metadata; model inference nodes retrieve model call completion receipts and service response records; knowledge retrieval nodes retrieve retrieval call completion receipts and retrieval response records; and external action nodes retrieve call completion receipts and external action receipts. After all necessary records are retrieved in any cycle, the node result reuse verification is re-executed.

[0086] If, after three consecutive cycles, a critical record proving the node's completion is still missing, and the corresponding underlying service is accessible, the node transitions from a pending state to a non-reusable state, and the missing record type and last retrieval time are written. When object storage, interface gateway, model service, and retrieval service are all inaccessible, the workflow control terminal pauses the retrieval cycle count, resuming retrieval only after the underlying services are restored, avoiding misinterpreting infrastructure interruption as a single node's result failure. If the remote service explicitly returns that the call is still in progress, the node remains in a pending state until the node lease expires or the remote service returns a completed, unreceived, or failed state.

[0087] Once the node result reuse status is established, the workflow control terminal generates a result reuse record. The result reuse record uses the batch number, node number, and node execution sequence number as unique references, and includes the node result reuse status, status formation basis, input reference number, output object number, version reference, remote call number, relevant receipt number, and formation time.

[0088] When a result reuse record already exists for the same execution sequence number, subsequent record retrieval only updates that result reuse record and does not create a new parallel state. When a node enters a reusable state and receives a version-forced invalidation record, an upstream input invalidation notification, or an output summary conflict notification, the workflow control end marks the original result reuse record as revoked and forms a non-reusable state, allowing S4 to identify the affected execution branch along the node consumption relationship.

[0089] S4 is specifically implemented as follows: When the workflow control terminal receives any of the following exceptions: node interruption, version failure, output digest conflict, unclear call status, or invalid input reference, it generates an exception record. The exception record uses the batch number, the exception node number, and the exception execution sequence number as location information, and includes the exception type, the time of exception discovery, the corresponding version number, the output object number, the remote call number, and the related result reuse record number.

[0090] The running heartbeat cycle and the maximum silent duration of the node lease are written into the node execution configuration version. The running heartbeat cycle is determined based on the node service running detection configuration, and the maximum silent duration of the node lease is determined based on the normal execution silent records of the corresponding node type, the longest wait records of remote services, and the results of node interruption tests. After the node execution configuration version takes effect, the running heartbeat cycle and the maximum silent duration of the node lease remain unchanged for the same node execution sequence number during this execution.

[0091] A node interruption occurs when a node task has been generated, a task reception message has been received, the lease expiration time in the node execution record has arrived, and no running heartbeat from the corresponding service instance has been received for three consecutive running heartbeat cycles. The lease expiration time in the node execution record is determined based on the task reception time and the maximum silent duration of the node lease registered in the node execution configuration version. The batch number, node number, node execution sequence number, and service instance number in the running heartbeat must be consistent with the node execution record. When the heartbeat reception service is inaccessible as a whole, the accumulation of missing heartbeats is paused, and platform communication failures are not considered as single node interruptions.

[0092] Version failure is determined based on the version failure record generated in S1. Normal service instance shutdown, load migration, and version ceasing to accept new tasks do not directly invalidate completed node results; only when a version exit notification or version failure record explicitly states file corruption, forced exit for security reasons, or unreliable existing results does a version failure exception affect existing results. Output digest conflicts are determined based on the output digest conflict record generated in S2.

[0093] The unclear call status is determined based on the S3 retrieval result. This means the call receipt already exists, but the call completion receipt and the result receipt required by the node type cannot be obtained after three consecutive retrieval cycles, even if the corresponding basic service is accessible. An invalid input reference occurs after the result reuse record of the predecessor node is revoked. The workflow control terminal writes the current node referencing that result into the input reference invalidation exception based on the predecessor input reference.

[0094] After an anomaly record is generated, the workflow control terminal first writes the output object corresponding to the anomaly node to a "prohibit new binding" state. Once the "prohibit new binding" state is established, the workflow control terminal no longer accepts new input binding messages from subsequent nodes for that output object, and tasks from subsequent nodes that have entered the message queue but have not yet been claimed are written to a "pending cancellation" state. Subsequently, the workflow control terminal reads the node consumption relationship formed by S2 starting from the anomaly node, without directly identifying all subsequent nodes in the workflow topology version as affected nodes.

[0095] When a node's consumption relationship is in the consumed state, it indicates that the successor node has read the output of the abnormal node and entered the execution phase. The workflow control end includes this successor node in the affected execution branch. When a node's consumption relationship is in the read-but-not-started state, it indicates that the successor node has obtained the output object but has not yet started processing it. The workflow control end also includes this successor node in the affected execution branch and cancels the corresponding node task to prevent it from continuing to start using invalid input.

[0096] When a node consumption relationship is in a bound but unread state, the workflow control terminal cancels the corresponding input binding and pending task, writes the successor node into the affected execution branch, but does not continue to expand downwards along that successor node. Successor nodes in a topology without a node consumption relationship are not included in the affected execution branch.

[0097] When a node's consumption relationship is in a conflict state, or when there are missing input binding messages, read completion messages, and start confirmation messages, the workflow control end will write the corresponding successor node to a consumption pending verification state and read the object storage access record and node execution log. If the object storage access record simultaneously records the successor node number, successor execution sequence number, and corresponding output object number, it is determined that the successor node has read the invalid output and will be included in the affected execution branch. If the object access record does not exist and the node has not generated a start confirmation message, the input binding and pending tasks for that node will be canceled, and it will not continue to expand downwards. When the object storage access service is temporarily inaccessible, consumption verification will be suspended, and the affected execution branch will remain frozen.

[0098] For successor nodes that have already been included in the affected execution branch and have formed node output commit records, the workflow control terminal continues to read the node consumption relationships with the output object of that node as the predecessor input, and verifies them level by level according to the same rules. The same batch, the same node number, and the same node execution sequence number are only included in the affected execution branch once. When multiple propagation paths intersect at the same merging node, the workflow control terminal merges the corresponding node consumption relationship numbers and does not repeatedly revoke the same result reuse record.

[0099] The workflow control terminal writes the previous-level failure input, the corresponding node consumption relationship number, the reason for inclusion, and the branch freeze time for each node in the affected execution branch. When no output object of a successor node is read by the next node, the affected scope ends at that node. When the output of a successor node has been read by the next node, the failure impact continues to propagate along the corresponding node consumption relationship. The affected execution branch formed in this way reflects the actual scope of use of the failure result and does not expand the scope of impact with unexecuted backup connections or unentered conditional branches.

[0100] When an affected node is already in a reusable state, the workflow control terminal writes the original result reuse record to the revoked flag and saves the failed input number, exception record number, and revocation time. If an affected node has already generated a node output commit record but has not yet entered a reusable state, the node is written to the non-reusable state. When an affected node is in execution, the workflow control terminal first writes a branch freeze record, then sends a stop execution notification, and stops issuing new tasks to the node's successor nodes.

[0101] After a stop execution notification is issued, if the affected node still returns a node completion message and output object, the workflow control terminal retains the corresponding output object and node completion message, but writes them to the frozen output state. This prevents the output from becoming reusable and disallows subsequent nodes to read it. By freezing the branch before sending the stop execution notification, delays in node stoppages are avoided from being mistakenly considered normal completions.

[0102] When an affected node is in a pending verification state, the workflow control terminal maintains the branch freeze and completes the verification according to the S3 record retrieval rules. If a node transitions to a non-reusable state, it remains in the affected execution branch; if a node transitions to a reusable state and does not reference other failed inputs, the node is removed from the affected execution branch, and the consumption verification of its successor nodes is restored. The workflow control terminal does not directly determine the recovery entry point before the pending verification state has ended.

[0103] Parallel branches are processed according to the actual node consumption relationships. When a predecessor node connects to multiple parallel nodes, only branches that have been bound, read, and consumed invalid outputs are included in the affected execution branches; parallel branches that have not read the output retain the reused state of the original node's results. When multiple parallel branches enter a merging node, the merging node is included in the affected execution branches as soon as one of its predecessor input references has become invalid; the output objects of other valid branches remain reusable. When the merging node is subsequently re-executed, the original output objects of the valid branches and the new output objects generated by the re-executed branches are referenced respectively.

[0104] When the affected execution branch passes through a node that modifies external system data, the workflow control terminal reads the external action call record and the external action control version. If the interface gateway explicitly returns that the request was not received, the external action node is treated as not yet executed, and the node is retained in the affected execution branch. The external effect is considered to have existed when an external action receipt has been generated and the external object number is unique.

[0105] When the external action control version records an irrevocable flag, the workflow control end forms an external effect boundary for that node, recording the external action token, external object number, and boundary node execution sequence number; the affected scope can continue to verify the actual consumer node after that node, but S5 must not set the recovery entry before the external effect boundary.

[0106] When an external action control version registration is valid and the interface is revoked, the workflow control terminal writes the corresponding node into the pending revocation record. The external effect boundary is then released only after S5 obtains the revocation completion receipt. If a call receipt exists but the call completion receipt and external action receipt are missing, the workflow control terminal uses the original remote call number and the original external action token to query the interface gateway and external tool service. If the query confirmation request is not received, it is treated as if the action has not yet been executed; if the query confirms that the external object has been formed, it is treated as if the external effect already exists.

[0107] When the interface gateway and external tool service are accessible, the workflow control terminal performs status updates according to the five-second basic service health check cycle registered in S1. If three consecutive status updates fail to obtain a clear status of "request not received," "processing," or "processing completed," the external action node enters an "unknown call status" state. The workflow control terminal then stops the automatic recovery of that execution branch and retains all call receipts and query records. When the interface gateway or external tool service is completely inaccessible, the accumulation of update counts is paused, and updates will resume according to the aforementioned cycle after the service is restored. When the same external action token corresponds to multiple different external object numbers, a duplicate external effect anomaly is formed, and the automatic recovery of that execution branch is stopped.

[0108] After an affected execution branch is formed, the workflow control terminal generates an affected branch record. The affected branch record includes the exception record number, affected node number and execution sequence number, failure input number, node consumption relationship number, record of revoked result reuse, tasks to be cancelled, frozen outputs, external actions to be undone, and external effect boundaries. When a new exception within the same batch hits an already frozen affected execution branch, the new exception record number is appended to the original affected branch record, without repeatedly undone already processed node results. The affected branch record serves as the S5 reverse verification recovery anchor point and input for forming the recovery entry point.

[0109] S5 is implemented as follows: The workflow control terminal reads the affected branch records generated by S4 and forms a recovery verification range according to the actual transmission direction of the failed input. The recovery verification range includes unreusable nodes, nodes awaiting verification, external actions to be undone, and external effect boundaries in the affected execution branches, excluding conditional branches that did not enter the current execution and topological connections that did not form node consumption relationships.

[0110] The workflow control end starts from the unreusable node in the affected execution branch and performs reverse verification step by step along the predecessor input references in the node execution record. Reverse verification uses the batch number, node number, and node execution sequence number to locate the node, and does not determine the order based on node number size, task completion time, or the arrangement in the workflow definition file. The same node execution sequence number is read only once in a single reverse verification, and the execution sequence number of a node that has already been verified is not added again to the current recovery verification path.

[0111] For each predecessor node read, the workflow control terminal sequentially checks whether the node's result reuse record is in a reusable state, whether the result reuse record has not been revoked, whether the output object still exists, whether the output content summary matches the review summary in the object storage, whether the output object type matches the input object type of the successor node, whether the version used by the node matches the batch version record, and whether there are any consumption conflicts in the node consumption relationship. When the predecessor node is an external action node, the external action receipt and external object number are also checked to ensure they are complete. When all the above items are satisfied, the node becomes a candidate record for recovery anchor points.

[0112] If a node is in a reusable state, but its output object is no longer readable, its output summary has changed, or its result reuse record has been revoked, no candidate record for a recovery anchor point will be generated. When a node is in a pending verification state, reverse verification is paused at that node, and the workflow control end completes the status verification according to the S3 supplementary rules, without skipping the pending verification node to continue selecting a recovery anchor point. When a pending verification node transitions to a reusable state, reverse verification continues; when it transitions to a non-reusable state, it continues to backtrack to its predecessor node.

[0113] The workflow control terminal verifies each actual failed input propagation path separately and selects the candidate recovery anchor record closest to the currently unreusable node as the recovery anchor for that path. The distance is based on the node level referenced by the actual predecessor input. When the currently unreusable node has multiple actual predecessor branches, each predecessor branch forms a recovery anchor. Multiple recovery anchors are written to the same recovery anchor record. The recovery anchor record records the recovery anchor node number, recovery anchor execution sequence number, output object number, output content summary, corresponding failed input, and corresponding affected branch.

[0114] When a given preceding branch has no reusable node, the branch backtracks to the batch input reference formed in S2 and uses the batch input object as the recovery anchor point for that branch. If other preceding branches already have reusable outputs, their respective recovery anchor points are retained, and it is not required that all branches return to the workflow start node. By saving the recovery anchor points of each input branch separately, when the merge node is re-executed, it can simultaneously reference the original outputs of the undone branches and the new outputs generated by the re-executed branches.

[0115] After a recovery anchor is formed, the workflow control end reads nodes from the recovery anchor forward along the affected execution branches. The first node after the recovery anchor that is in a non-reusable state and needs to be re-executed forms the recovery entry point. When there are multiple independent affected branches, each branch forms a separate entry node, and all entry nodes are written to the same recovery entry record. The recovery entry record records the entry node number, the original node execution sequence number, the corresponding recovery anchor, the failed input number, the reason for re-execution, and the input object to be obtained. When there is only one affected execution branch, the recovery entry record only registers one entry node.

[0116] When a node in a read-but-not-started state exists between the recovery anchor point and a non-reusable node, the workflow control terminal cancels the original node task and uses that node as the recovery entry point. When a node in a bound-but-not-read state exists between the recovery anchor point and a non-reusable node, the original input binding is canceled, and input references are re-formed based on the reuse status of its predecessor result; if the predecessor result is still reusable, that node serves as the recovery entry point; if the predecessor result is not reusable, the verification continues forward. Nodes located outside the affected execution branch and maintaining a reusable state are not written to the recovery entry record.

[0117] When reverse verification reaches the external effect boundary, the workflow control end reads the external action call record and the external action control version. If the external action receipt confirms that the external object has been formed and the external action control version is marked as irreversible, the recovery anchor point must not be located before that external effect boundary. Nodes after the external effect boundary continue to recover only if all their required inputs can be reconstructed from the external action receipt, the external object number, and other reusable outputs. When the above conditions are met, the external effect boundary is registered as the recovery anchor point for that branch, and the first non-reusable node after the boundary is registered as the recovery entry point.

[0118] Nodes after the boundary of an external effect still depend on inputs that have failed and must be regenerated before the boundary. If the external effect cannot be undone, the workflow control end does not re-execute nodes before the boundary of the external effect; instead, it writes the branch to the terminated branch state. The terminated branch record includes the external action token, external object number, failed input number, and termination reason, preventing a second set of results inconsistent with the existing external effect from being generated after re-executing the upstream node.

[0119] When the external action control version registration is valid and an interface for revocation is established, the workflow control terminal initiates a revocation request using the original external action token and the original external object number. After the revocation interface returns a revocation completion receipt, the workflow control terminal verifies whether the external action token, external object number, and revocation result in the receipt are consistent with the original external action call record, and obtains the current object status according to the revocation status return field recorded in the external action control version.

[0120] When the object's existence status in the pre-action state record is "non-existent," the current object state indicates that the external object formed by the original external action no longer exists, and the external object is registered to restore to its pre-action state. When the object's existence status in the pre-action state record is "existent," the current object's state version number and state content summary are consistent with the pre-action state record, and the external object is registered to restore to its pre-action state.

[0121] When the cancellation completion receipt verification is successful and the external object is restored to its pre-action state, the external effect boundary is removed, allowing continued reverse verification back to that node. If the cancellation completion receipt is missing, the cancellation result verification is inconsistent, the current object state cannot be obtained, or the current object state is inconsistent with the pre-action state record, the external effect boundary is maintained, and the node is not crossed to form a restoration anchor point.

[0122] After the recovery anchor point record and recovery entry record are formed, the workflow control end establishes a recovery execution list. The recovery execution list registers one processing action for each node in the affected execution branch according to the node number and node execution sequence number: reuse, re-execution, pending verification, undoing external actions, and terminating the branch. Nodes that remain reusable and are located before the recovery entry are registered for reuse; nodes that are in a non-reusable state from the recovery entry are registered for re-execution; nodes that have not yet completed S3 status verification are registered for pending verification; nodes that need to remove external effect boundaries are registered for undoing external actions; branches with irreversible external effects and cannot continue execution are registered for branch termination.

[0123] During the same data write process, the workflow control terminal saves the recovery anchor point record, recovery entry record, and recovery execution list. If any record fails to be written, the affected execution branch remains frozen and no recovery task is issued. After all three types of records have been written, a recovery batch number is generated for this recovery. The recovery batch number is associated with the original workflow execution batch and does not change the original batch number or batch version record.

[0124] Nodes requiring re-execution retain their original node numbers, and new node execution sequence numbers are generated. The new node execution sequence number and the original execution sequence number are saved separately; the original node execution record, remote call record, output object, and result reuse record are not overwritten. The workflow control terminal regenerates predecessor input references based on the restored execution list. These predecessor input references only point to the original output objects registered for reuse and the new output objects generated after this re-execution.

[0125] When a merging node has multiple input branches, each preceding input reference stores the corresponding node execution sequence number, output object number, and output content summary, and does not automatically read the last written output object according to the node number.

[0126] The original non-reusable output objects remain stored in object storage, and an invalidation flag, corresponding exception record number, and alternative execution sequence number are written into the object metadata. Subsequent nodes must not read output objects with invalidation flags. When the original node's execution sequence number returns a delayed task receive message, node completion message, and call receipt after the recovery task is issued, the workflow control end still writes the delayed message to the original node's execution record, and does not allow it to update the running status of the new node's execution sequence number, nor does it use delayed output to replace the output generated by the recovery task.

[0127] When re-executing model inference and knowledge retrieval nodes, the frozen model service version, prompt configuration version, and retrieval index snapshot version from the batch version record will continue to be used. If a frozen version can no longer provide services, the workflow control end will stop the automatic recovery of the corresponding branch and write a version not executable record, without automatically replacing the frozen version with a new version. This process prevents the mixing of different model versions, prompt configurations, and retrieval snapshots during the recovery process.

[0128] When a remote call node is re-executed, the workflow control terminal generates a new remote call number based on the new node execution sequence number. If the interface gateway explicitly returns that the original external action request was not received, the re-executed external action node sends the request using the original external action token and writes the new remote call number and the original external action token together into the external action call record. If the original external action has been completed and formed a unique external object, and the external action has not been canceled, the external action request is not sent again; subsequent nodes directly reference the original external action receipt and the external object number.

[0129] If the original external action has obtained a cancellation completion receipt, and the cancellation completion receipt is consistent with the original external action call record, and the external object has been restored to its pre-action state, then the corresponding external action node is re-executed, an external action sequence number is added, and a new external action token is generated. The new remote call number and the new external action token are written together into the external action call record corresponding to this re-execution.

[0130] After the workflow control terminal issues the recovery task according to the recovery entry record, it continues to process subsequent execution using the node execution record formation rules of S2, the node result reuse status formation rules of S3, and the affected execution branch identification rules of S4. Once all nodes in the recovery task have reached a reusable state, the nodes awaiting verification have completed their state transitions, the external actions awaiting cancellation have received cancellation completion receipts, and the predecessor input references of all merging nodes point to valid node execution sequence numbers, the workflow control terminal unfreezes the affected execution branches and writes a recovery completion record.

[0131] The recovery completion record includes the recovery batch number, recovery entry point, re-execution node, reused output object, undoed external actions, and recovery completion time. If an exception occurs again at the re-execution node, the workflow control end creates a new exception record with the new node execution sequence number and associates the new exception record with the current recovery batch number, without modifying the previous exception record, recovery anchor record, or recovery execution list.

[0132] Example 2: Figure 2 A schematic diagram of a workflow engine management system for an AI service platform is provided according to the present invention. The workflow engine management system for an AI service platform includes: The workflow control terminal is used to create workflow execution batches, read the workflow topology version and the node execution configuration version corresponding to each node, and read the corresponding model service version, prompt configuration version, retrieval index snapshot version, interface contract version and external action control version according to the node type, and bind each version reference to the batch number; The node execution processing unit is used to issue node tasks according to the workflow topology, record the node execution sequence number, predecessor input reference, service instance number, output object number and output content summary, record the remote call number and call receipt when a node makes a remote call, and form node consumption relationship based on the subsequent node's reading record of the output object; The result reuse verification unit is used to verify the node's input reference, version reference, output object, output content summary, call receipt and external action receipt to form the node result reuse status; The exception branch processing unit is used to form the affected execution branch based on the exception node and the node consumption relationship when an exception occurs during workflow execution, and to cancel the result reuse status of the affected node. The recovery execution unit is used to verify the reuse status of node results and the status of external actions in reverse along the affected execution branch, register the recovery anchor point and recovery entry point, and reissue the node task according to the recovery entry point.

[0133] In this embodiment, the workflow control terminal establishes data transmission connections with the node execution processing unit, the result reuse verification unit, the abnormal branch processing unit, and the recovery execution unit, respectively. Each component can be deployed within the same workflow control server or on different servers connected via the platform's internal network. When using distributed deployment, each component is associated with the same workflow execution process according to batch number, node number, and node execution sequence number.

[0134] The workflow control unit sends the batch number, frozen workflow topology version, and node version reference table to the node execution processing unit. The node execution processing unit generates node tasks based on the workflow topology version and sends the node tasks to the corresponding node service. The node execution processing unit receives the task reception message, call receipt, node completion message, and output object reference returned by the node service. Based on the data returned by the node service, the node execution processing unit forms node execution records, node output submission records, and node consumption relationships, and sends the node execution records and node output submission records to the result reuse verification unit, while simultaneously sending the node consumption relationships to the exception branch processing unit.

[0135] The result reuse verification unit reads batch version records from the workflow control terminal and node input references, node output submission records, remote call records, and external action receipts from the node execution processing unit, forming result reuse records corresponding to reusable, non-reusable, and pending verification states. The result reuse verification unit sends the result reuse records to the workflow control terminal; when a result reuse record is revoked, it sends the corresponding node number, node execution sequence number, failure input number, and revocation reason to the exception branch processing unit.

[0136] The exception branch processing unit reads node consumption relationships from the node execution processing unit and reads non-reusable status and result reuse record cancellation information from the result reuse verification unit. When node interruption, version failure, output digest conflict, unclear call status, or invalid input references occur, the exception branch processing unit sends a prohibition on adding new bindings, a pending task cancellation instruction, and an execution branch freeze instruction to the node execution processing unit, and forms an affected branch record based on the actual node consumption relationships. After the affected branch record is formed, the exception branch processing unit sends the affected node, invalid input, pending undoable external action, and external effect boundary to the recovery execution unit.

[0137] The recovery execution unit reads the result reuse record, predecessor input reference, and external action status based on the affected branch record to form a recovery anchor record, a recovery entry record, and a recovery execution list. The recovery execution unit sends the recovery execution list to the workflow control terminal and calls the node execution processing unit through the workflow control terminal. The node execution processing unit generates a new node execution sequence number and node task for the re-executed node based on the recovery entry, and distributes the node task to the corresponding node service. New node execution records generated during recovery execution continue to be sent to the result reuse verification unit. If the re-executed node experiences an anomaly again, the anomaly branch processing unit generates a new affected branch record based on the new node execution sequence number.

[0138] Once all nodes in the recovery execution list have completed their corresponding processing actions, the recovery execution unit sends a recovery completion record to the workflow control terminal. The workflow control terminal then unfreezes the corresponding execution branch based on the recovery completion record and continues to control subsequent node tasks according to the frozen workflow topology version.

[0139] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0140] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented in whole or in part by a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions of the embodiments of this application are implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted wirelessly or wiredly from one website, computer, server, or data center to another website, computer, server, or data center. Wired methods include optical fiber, twisted pair, coaxial cable, etc. Wireless methods include infrared, microwave, etc. Available media include any available media that can be accessed by a computer or data storage devices such as servers and data centers that contain one or more sets of available media. Available media can be magnetic media (floppy disks, hard disks, magnetic tapes), optical media (DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0141] The above content is only a specific embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A workflow engine management method for an AI service platform, characterized in that, Perform the following steps in sequence: S1. The workflow control terminal establishes a workflow execution batch, reads the workflow topology version and the node execution configuration version corresponding to each node, and reads the corresponding model service version, prompt configuration version, retrieval index snapshot version, interface contract version and external action control version according to the node type, and binds each version reference to the batch number. S2. Distribute node tasks to node services according to the workflow topology, record the node execution sequence number, predecessor input reference, service instance number, output object number and output content summary, record the remote call number and call receipt when a node makes a remote call, and form node consumption relationship based on the subsequent node's record of reading the output object. S3. Verify the node's input references, version references, output objects, output content summaries, call receipts, and external action receipts to establish the node result reuse status, and register nodes lacking necessary records as pending verification status. S4. When a preset execution exception occurs during workflow execution, the preset execution exception is any one of node interruption, version failure, output summary conflict, unknown call status, and input reference failure. Starting from the abnormal node and node consumption relationship, the successor node that has read the failed output is identified, the affected execution branch is formed, and the reusable state that the affected node has formed is revoked. S5. Verify the reuse status of node results and external action status in reverse along each actual predecessor input path of the affected execution branch. Register the nearest node with reusable output as the recovery anchor point, register the first node that needs to be re-executed after each recovery anchor point as the recovery entry point, and reissue the node task according to the recovery entry point.

2. The workflow engine management method for an AI service platform according to claim 1, characterized in that, S1 includes: Write the workflow topology version to the version reference list, and write the node execution configuration version, as well as the model service version, prompt configuration version, retrieval index snapshot version, interface contract version, and external action control version to the version reference list according to the node number. Verify the availability status, input field types, output field types, and object type correspondences of each version in the version reference list; After verification, the version reference list and batch number are written into the batch version record, and the batch version record is set to a frozen state. When frozen, the node task references the version corresponding to the node number in the batch version record.

3. The workflow engine management method for an AI service platform according to claim 1, characterized in that, S2 include: A node task is identified by its batch number, node number, and node execution sequence number. The predecessor input reference of the starting node is written with the batch input object number, input content summary and input object type; the predecessor input reference of a non-starting node is written with the predecessor node number, predecessor execution sequence number, output object number, output content summary and output object type. When the output object has been persistently written, and the node's completion message matches the node execution sequence number, output object number, and output content summary in the object's metadata, a node output commit record is formed.

4. The workflow engine management method for an AI service platform according to claim 3, characterized in that, S2 also includes: Before a successor node reads the output object of its predecessor, it sends an input binding message; after reading is completed, it sends a read completion message; and after entering the execution phase, it sends a start confirmation message. Both the read completion message and the start confirmation message reference the same input binding message. When the batch number, successor node number, successor execution sequence number, predecessor execution sequence number and output object number recorded in the input binding message are consistent with the node task and node output submission record, and the actual output object number and read content summary recorded in the read completion message are consistent with the node output submission record, the node consumption relationship is written to the consumed status. Write the "bound but not read" state only when an input binding message is generated; write the "read but not started" state when both an input binding message and a read completion message are generated but no start confirmation message is generated; write the "consumption conflict" state when there is an inconsistency between the execution sequence number, output object number, and content summary.

5. A workflow engine management method for an AI service platform according to claim 3, characterized in that, S3 include: If a node execution record has one of the following issues: version inconsistency, invalid input reference, output summary conflict, duplicate external effect, or call number conflict, the node result reuse status will be written to the non-reusable status. When the node input reference, version reference, node output commit record and corresponding node type call receipt are complete and there are no conflicts as mentioned above, the node result reuse status is written to the reusable status. If there is no conflict as described above and there are missing node completion messages, object metadata, call completion receipts, and external action receipts, the node result reuse status is written to the pending status, and the missing records are retrieved after the corresponding basic service is restored to accessibility.

6. The workflow engine management method for an AI service platform according to claim 4, characterized in that, S4 includes: After an exception record is generated, the output object of the exception node is written to the "prohibit new binding" state, and new node tasks that reference the output object are stopped. When a node's consumption relationship is in either the consumed state or the read-but-not-started state, the corresponding successor node will be included in the affected execution branch. When a node consumption relationship is in a bound but unread state, cancel the corresponding input binding and pending task, include the corresponding successor node in the affected execution branch, and stop extending downwards along that successor node; When the output of the affected node has been read by the next node, continue to identify the successor node along the corresponding node consumption relationship, and revoke the reusable state that the affected node has formed.

7. A workflow engine management method for an AI service platform according to claim 6, characterized in that, S4 also includes: When the affected execution branch passes through an external action node, it reads the external action call record and the external action control version. When an external action receipt records a unique external object number and the external action control version records an irrevocable flag, the external action node is registered as an external effect boundary. When the external action control version records the cancellation interface, the external action node is registered as a node to be cancelled. The external action token, external object number and cancellation status in the cancellation completion receipt are consistent with the external action call record, and the external object status after cancellation is consistent with the status record before the action. The external effect boundary is then released. When the interface gateway and external tool services are in an accessible state, the status is checked three times consecutively according to the cycle of the workflow control terminal performing accessibility status verification on the basic services. If no clear processing status is returned, the automatic recovery of the corresponding execution branch is stopped.

8. A workflow engine management method for an AI service platform according to claim 6, characterized in that, S5 include: Starting from the unreusable nodes in the affected execution branches, verify the actual predecessor input references level by level in reverse along the node execution records; If the predecessor node is in a reusable state, the result reuse record has not been revoked, the output object exists, the output content summary is consistent with the verification, the version reference is consistent with the batch version record, and there is no consumption conflict in the node consumption relationship, then write the predecessor node into the recovery anchor candidate record. Based on the node hierarchy referenced by the actual predecessor input, select the candidate record of the recovery anchor point closest to the unreusable node as the recovery anchor point; Read backward from the recovery anchor point along the corresponding affected execution path, and register the first node that needs to be re-executed as the recovery entry point.

9. A workflow engine management method for an AI service platform according to claim 8, characterized in that, S5 also includes: Based on the recovery anchor point, recovery entry point, node result reuse status and external effect boundary, a recovery execution list is formed. The recovery execution list registers one of the following processing actions for each node: reuse, re-execution, waiting for verification, cancellation of external actions, and termination of branches. The nodes that need to be re-executed retain their original node numbers and generate new node execution sequence numbers. The newly formed predecessor input references point to the original output objects registered for reuse and the new output objects formed in this re-execution, respectively. The original non-reusable output object is written with an invalidation flag and a replacement execution sequence number. The late message returned by the original node execution sequence number continues to be written to the original node execution record, and the running status corresponding to the new node execution sequence number is not updated.

10. A workflow engine management system for an AI service platform, used to implement the workflow engine management method for an AI service platform as described in claims 1 to 9, characterized in that, include: The workflow control terminal is used to create workflow execution batches, read the workflow topology version and the node execution configuration version corresponding to each node, and read the corresponding model service version, prompt configuration version, retrieval index snapshot version, interface contract version and external action control version according to the node type, and bind each version reference to the batch number; The node execution processing unit is used to issue node tasks according to the workflow topology, record the node execution sequence number, predecessor input reference, service instance number, output object number and output content summary, record the remote call number and call receipt when a node makes a remote call, and form node consumption relationship based on the subsequent node's reading record of the output object; The result reuse verification unit is used to verify the node's input reference, version reference, output object, output content summary, call receipt and external action receipt to form the node result reuse status; The exception branch processing unit is used to form the affected execution branch based on the exception node and the node consumption relationship when an exception occurs during workflow execution, and to cancel the result reuse status of the affected node. The recovery execution unit is used to verify the reuse status of node results and the status of external actions in reverse along the affected execution branch, register the recovery anchor point and recovery entry point, and reissue the node task according to the recovery entry point.

Images