Workflow event execution method and apparatus, electronic device, and storage medium

Abstract

The workflow event execution method and device, the electronic device, and the storage medium provided in the embodiments of the present application, the method comprises the following steps: based on the running instance identifier of the target workflow instance, a state query request is sent to an external persistent workflow backend, and a target state snapshot of the target workflow instance is obtained; based on the preset output event record, the event set is filtered to obtain a filtered event set, and based on the comparison result of the current workflow state and the historical workflow state and the filtered event set, a target event stream is obtained, and then the target event stream is output to a client; when the current workflow state is a waiting input state, a set of to-be-input ports is output to the client; an external response request issued by the client for the set of to-be-input ports is received, and the external response request containing a target port identifier is forwarded to the persistent workflow backend, so that when external manual or system intervention is introduced, the workflow recovery execution can be accurately routed and reliably driven.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to workflow event execution methods, apparatus, electronic devices and storage media. Background Technology

[0002] In AI agent orchestration and enterprise automation applications, tasks often involve multi-step execution, external system calls, and manual approvals, resulting in long-cycle workflows. As the system's interaction layer, the gateway needs to manage and track these long-lifecycle tasks. Currently, conventional AI gateways typically handle short-lived model or tool interaction requests in a stateless mode. To support long-cycle workflows, existing solutions usually maintain the task execution context directly in the gateway process's memory or use HTTP long-lived connections to synchronously block and wait for backend tasks to complete. Additionally, some architectures choose to directly integrate a persistent workflow engine within the gateway, introducing relevant underlying dependencies and runtime metadata to meet the needs of workflow state recording and task scheduling.

[0003] However, existing processing methods have certain limitations in practical applications. On the one hand, when the gateway maintains the workflow state in memory, container restarts, elastic scaling, or process crashes can easily lead to the loss of unfinished task contexts. If long-connection synchronous waiting is used, it will occupy the connection pool and thread resources of the gateway instance for a long time, reducing the system's concurrent throughput. Furthermore, directly embedding the persistence engine in a lightweight gateway will increase the system deployment complexity and is not conducive to adapting to lightweight compilation environments such as NativeAOT. On the other hand, for complex workflows that require external intervention, existing gateways usually cannot natively support the workflow's "pause-wait-resume" mode, making it difficult to accurately distinguish between the current active running state of a task and the state waiting for external input. This lack of a state model makes it difficult for the gateway to provide the client with a continuous, deduplicated event stream that reflects state transitions. This makes it easy for existing processing solutions to cause long-cycle persistent workflows to fail to be accurately routed and resumed after receiving external responses. Summary of the Invention

[0004] This application provides a workflow event execution method, apparatus, electronic device, and storage medium that can solve the above-mentioned technical problems.

[0005] To achieve the above objectives, a first aspect of this application proposes a workflow event execution method, the method comprising: Based on the running instance identifier of the target workflow instance, a status query request is sent to the external persistent workflow backend, and a target status snapshot of the target workflow instance is obtained. The target status snapshot includes the current workflow status, event set, and input port set. The event set is filtered based on the preset output event records to obtain a filtered event set. Based on the comparison result between the current workflow state and the historical workflow state and the filtered event set, a target event stream is obtained, and then the target event stream is output to the client. When the current workflow state is in the waiting input state, the set of ports to be input is output to the client; The system receives an external response request from the client for the set of ports to be input, and forwards the external response request containing the target port identifier to the persistent workflow backend, so as to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier.

[0006] In some embodiments, filtering the event set based on preset output event records to obtain a filtered event set, and obtaining a target event flow based on the comparison result of the current workflow state and the historical workflow state and the filtered event set, includes: The event corresponding to the event identifier that is not recorded in the output event record is determined from the event set to obtain the filtered event set; When the current workflow state is inconsistent with the historical workflow state, a composite state event is generated based on the current workflow state. The filtered event set and the synthesized state event are combined to obtain the target event stream; After outputting the target event stream to the client, the event identifier in the filtered event set is updated to the output event record, and the historical workflow status is updated to the current workflow status.

[0007] In some embodiments, after outputting the target event stream to the client, the method further includes: The current workflow state is matched with a preset set of terminal states to obtain a state matching result. The set of terminal states includes at least one of the following: completion state, failure state, and cancellation state. When the state matching result indicates that the current workflow state belongs to the terminal state set, and after confirming that both the filtered event set and the synthesized state event in the target event stream have been output, the process of outputting the workflow event stream to the client ends.

[0008] In some embodiments, before sending a status query request to an external persistent workflow backend based on the running instance identifier of the target workflow instance, the method further includes: Receive a workflow start request sent by the client, the workflow start request including a target backend identifier; Based on the pre-established workflow runner mapping relationship, the workflow start request is routed and forwarded to the persistent workflow backend that matches the target backend identifier; Receive the initial running instance identifier returned by the persistent workflow backend after creating the target workflow instance, and use the initial running instance identifier as the running instance identifier.

[0009] In some embodiments, the set of input ports includes at least two different input ports, and forwarding the external response request containing the target port identifier to the persistent workflow backend to instruct the persistent workflow backend to resume execution of the node corresponding to the target port identifier includes: The external response request is forwarded to the persistent workflow backend to instruct the persistent workflow backend to resume the execution of the target waiting node corresponding to the target port identifier when the target workflow instance is in the waiting input state and the target port identifier is successfully matched, and to keep the nodes corresponding to other unresponsive waiting input ports in the waiting state.

[0010] In some embodiments, sending a status query request to an external persistent workflow backend based on the running instance identifier of the target workflow instance includes: Retrieve the pre-configured polling interval parameter; Based on the polling interval parameter, the status query request carrying the running instance identifier is periodically sent to the persistent workflow backend until the obtained current workflow status is one of the terminal status sets.

[0011] In some embodiments, the target state snapshot and the external response request include a variable service payload, the variable service payload employing a structured data format; the method further includes: Upon receiving the target state snapshot and the external response request, the fixed shell fields in the target state snapshot and the external response request are parsed and routed, and the original structured data format of the variable service payload is maintained during transmission; wherein, the fixed shell fields include the running instance identifier, the current workflow status, the event identifier, and the target port identifier.

[0012] To achieve the above objectives, a second aspect of this application provides a workflow event execution apparatus, the apparatus comprising: The first request sending module is used to send a status query request to an external persistent workflow backend based on the running instance identifier of the target workflow instance, and to obtain a target status snapshot of the target workflow instance, wherein the target status snapshot includes the current workflow status, event set, and input port set. The event stream sending module is used to filter the event set based on preset output event records to obtain a filtered event set, and to obtain a target event stream based on the comparison result of the current workflow state and the historical workflow state and the filtered event set, and then output the target event stream to the client. The input port sending module is used to output the set of ports to be input to the client when the current workflow state is a waiting input state; The second request sending module is used to receive the external response request sent by the client for the set of ports to be input, and forward the external response request containing the target port identifier to the persistent workflow backend, so as to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier.

[0013] To achieve the above objectives, a third aspect of the present application provides an electronic device, the electronic device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the workflow event execution method as described in the first aspect.

[0014] To achieve the above objectives, a fourth aspect of the present application provides a storage medium, which is a computer-readable storage medium storing a computer program that, when executed by a processor, implements the workflow event execution method as described in the first aspect.

[0015] The workflow event execution method, apparatus, electronic device, and storage medium proposed in this application include: First, based on the running instance identifier of the target workflow instance, a status query request is sent to an external persistent workflow backend, and a target status snapshot of the target workflow instance is obtained. The target status snapshot includes the current workflow state, an event set, and a set of ports to be input. Then, the event set is filtered based on preset output event records to obtain a filtered event set. Based on the comparison result between the current workflow state and the historical workflow state and the filtered event set, a target event stream is obtained, and the target event stream is output to the client. Afterward, when the current workflow state is in a waiting-for-input state, the set of ports to be input is output to the client. Finally, an external response request sent by the client for the set of ports to be input is received, and the external response request containing the target port identifier is forwarded to the persistent workflow backend to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier. This application embodiment obtains a state snapshot from an external persistent workflow backend based on the running instance identifier. This eliminates the need for the gateway to maintain the persistent execution state of the workflow in process memory, avoiding task context loss due to gateway restarts or crashes, and reducing the long-term occupation of system connection pools and computing resources by synchronous blocking and waiting. Furthermore, by filtering and deduplicating events in the snapshot based on the output event records, and generating and outputting the target event stream by combining the comparison results of the current state and historical states, the gateway can provide clients with continuous, deduplicated, and effective observation data that reflects key state transitions in a lightweight proxy mode. On this basis, by exposing the set of input ports when the workflow is in the waiting input state, and accurately forwarding the external response request containing the target port identifier to the persistent backend to restore the corresponding node, the system can natively support the "pause-wait-resume" mode of long-cycle workflows. This effectively distinguishes between the active running state and the persistent waiting state of the task, and also ensures that complex processes can be accurately routed and reliably driven to resume execution when external manual or system intervention is introduced.

[0016] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0017] Figure 1 This is a flowchart of a workflow event execution method provided in an embodiment of this application.

[0018] Figure 2 This is a flowchart of a workflow initiation provided in another embodiment of this application.

[0019] Figure 3 yes Figure 1 The flowchart for step 101.

[0020] Figure 4 yes Figure 1 The flowchart for step 102.

[0021] Figure 5 This is another embodiment of the present application providing a flowchart for matching the current workflow status.

[0022] Figure 6 This is a schematic diagram of the state transition logic of a workflow state machine provided in another embodiment of this application.

[0023] Figure 7 This is a logical schematic diagram of a polling event stream generation process provided in another embodiment of this application.

[0024] Figure 8 This is an interactive timing diagram of a three-stage HTTP delegation process provided in another embodiment of this application.

[0025] Figure 9 yes Figure 1 The flowchart for step 104.

[0026] Figure 10 This is an interactive timing diagram of a manual approval recovery process provided in another embodiment of this application.

[0027] Figure 11 This is a flowchart of a structured data format processing method provided in another embodiment of this application.

[0028] Figure 12 This is a schematic diagram of the overall architecture logic of a workflow event processing system provided in another embodiment of this application.

[0029] Figure 13 This is a schematic diagram of the structure of a workflow event execution device provided in another embodiment of this application.

[0030] Figure 14 This is a schematic diagram of the hardware structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0032] It should be noted that although functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart.

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0034] In AI agent orchestration and enterprise automation applications, tasks often involve multi-step execution, external system calls, and manual approvals, resulting in long-cycle workflows. As the system's interaction layer, the gateway needs to manage and track these long-lifecycle tasks. Currently, conventional AI gateways typically handle short-lived model or tool interaction requests in a stateless mode. To support long-cycle workflows, existing solutions usually maintain the task execution context directly in the gateway process's memory or use HTTP long-lived connections to synchronously block and wait for backend tasks to complete. Additionally, some architectures choose to directly integrate a persistent workflow engine within the gateway, introducing relevant underlying dependencies and runtime metadata to meet the needs of workflow state recording and task scheduling.

[0035] However, existing processing methods have certain limitations in practical applications. On the one hand, when the gateway maintains the workflow state in memory, container restarts, elastic scaling, or process crashes can easily lead to the loss of unfinished task contexts. If long-connection synchronous waiting is used, it will occupy the connection pool and thread resources of the gateway instance for a long time, reducing the system's concurrent throughput. Furthermore, directly embedding the persistence engine in a lightweight gateway will increase the system deployment complexity and is not conducive to adapting to lightweight compilation environments such as NativeAOT. On the other hand, for complex workflows that require external intervention, existing gateways usually cannot natively support the workflow's "pause-wait-resume" mode, making it difficult to accurately distinguish between the current active running state of a task and the state waiting for external input. This lack of a state model makes it difficult for the gateway to provide the client with a continuous, deduplicated event stream that reflects state transitions. This makes it easy for existing processing solutions to cause long-cycle persistent workflows to fail to be accurately routed and resumed after receiving external responses.

[0036] Based on this, this application embodiment obtains a state snapshot from the external persistent workflow backend based on the running instance identifier, so that the gateway does not need to maintain the persistent execution state of the workflow in the process memory, avoiding the loss of task context caused by gateway restart or crash, and reducing the long-term occupation of system connection pool and computing resources by synchronous blocking and waiting. Furthermore, by filtering and deduplicating the events in the snapshot based on the output event records, and generating and outputting the target event stream by combining the comparison results of the current state and the historical state, the gateway can provide the client with continuous, deduplicated, and effective observation data that reflects key state transitions in a lightweight proxy mode. On this basis, by exposing the set of input ports when the workflow is in the waiting input state, and accurately forwarding the external response request containing the target port identifier to the persistent backend to restore the corresponding node, the system can natively support the "pause-wait-resume" mode of long-cycle workflows, thereby effectively distinguishing the active running state of the task from the persistent waiting state, and also ensuring that complex processes can be accurately routed and reliably driven to resume execution when external manual or system intervention is introduced.

[0037] The workflow event execution method, apparatus, electronic device, and storage medium provided in the embodiments of this application will be further described below.

[0038] Reference Figure 1 This is an optional flowchart of the workflow event execution method provided in the embodiments of this application. Figure 1 The method described may include, but is not limited to, steps 101 to 104. It is also understood that this embodiment... Figure 1 The order of steps 101 to 104 is not specifically limited; the order of steps can be adjusted or certain steps can be added or removed according to actual needs. The workflow event execution method provided in this application can be applied to a gateway or any processing system with computing resources associated with the gateway (such as a server, smart terminal, computing processor, etc.).

[0039] Step 101: Based on the running instance identifier of the target workflow instance, send a status query request to the external persistent workflow backend and obtain a target status snapshot of the target workflow instance. The target status snapshot includes the current workflow status, event set, and input port set.

[0040] Step 101 will be described in detail below.

[0041] In step 101 of some embodiments, a status query request is sent to an external persistent workflow backend (e.g., one identified as durable-review) based on the runtime instance identifier of the target workflow instance, and a target state snapshot of the target workflow instance is obtained. The runtime instance identifier is an identifier generated and returned by the backend orchestration engine during the workflow startup phase, used to uniquely identify the lifecycle of a long-cycle workflow execution globally. The persistent workflow backend refers to the core engine entity responsible for managing specific workflow definitions, executing task scheduling, and persistently storing runtime instance checkpoints in an external database. Since the execution entity (e.g., the gateway layer) does not directly hold the persistent context state of the workflow in memory, an asynchronous query needs to be initiated to the external backend via a request-response protocol, carrying the runtime instance identifier.

[0042] This target state snapshot refers to a structured data carrier representing the complete and observable state of a target workflow instance at a specific observation point. The target state snapshot includes the current workflow state, the event set, and the set of input ports. The current workflow state characterizes the macroscopic execution phase of the instance at the time of the query; the event set records the sequence of events from various business actions or nodes generated by the backend engine during the execution of the workflow; and the set of input ports encompasses any logical recovery entry points that may exist for external interaction.

[0043] In addition, refer to Figure 2 Before sending a status query request to an external persistent workflow backend based on the running instance identifier of the target workflow instance, the method further includes the following steps 201 to 203.

[0044] Step 201: Receive the workflow start request sent by the client. The workflow start request includes the target backend identifier.

[0045] Step 202: Based on the pre-established workflow runner mapping relationship, route the workflow start request to the persistent workflow backend that matches the target backend identifier.

[0046] Step 203: Receive the initial running instance identifier returned by the persistent workflow backend after creating the target workflow instance, and use the initial running instance identifier as the running instance identifier.

[0047] Steps 201 to 203 are described in detail below.

[0048] In step 201 of some embodiments, a workflow start request sent by the client is first received. The workflow start request includes a target backend identifier. The workflow start request refers to structured instruction data initiated by a front-end page, management backend, or external business caller, intended to trigger a specific long-term persistent task process. The data payload of the workflow start request encapsulates user input, session context, and necessary structured business data. The target backend identifier (BackendId) is a key addressing parameter encapsulated in the shell field of the start request. In a complex architecture where multiple workflow backends may coexist, it uniquely specifies the external physical execution engine or cluster that the task is expected to mount. By explicitly extracting the target backend identifier during the startup phase, a clear destination basis is provided for the targeted distribution of subsequent network requests.

[0049] In step 202 of some embodiments, based on a pre-established workflow runner mapping relationship, the workflow startup request is routed and forwarded to a persistent workflow backend that matches the target backend identifier. The workflow runner mapping relationship refers to the routing addressing dictionary between backend identifiers and specific workflow runner instances constructed by the internal workflow registry module after reading global configuration information during the initialization phase of the execution entity (gateway). Upon receiving the startup request, a matching query is performed in the workflow runner mapping relationship using the extracted target backend identifier as the retrieval key to locate the dedicated runner instance responsible for the target backend. Subsequently, based on the successfully matched runner instance, underlying protocol adaptation is performed, and the workflow startup request is accurately forwarded to the corresponding persistent workflow backend in an asynchronous manner (e.g., sending a POST startup request to a specific API path of the backend).

[0050] In step 203 of some embodiments, the initial running instance identifier returned by the persistent workflow backend after creating the target workflow instance is received, and this initial running instance identifier is used as the running instance identifier. Specifically, when the external persistent workflow backend receives the forwarded start request, it allocates resources in its internal orchestration engine and persistent state storage to create the actual target workflow instance, while generating a globally unique identity string. The execution entity (gateway) receives the confirmation response returned by the backend (e.g., a data packet containing a 202 Accepted status code and the initial running result), parses the initial running instance identifier from it, and logically assigns and establishes it as the running instance identifier that runs throughout the entire lifecycle of the workflow. This running instance identifier is both returned to the client for safekeeping and serves as a core query credential to support polling-based state tracking and event acquisition in subsequent steps.

[0051] In one example, the operations and maintenance personnel enable workflow capabilities in the gateway configuration and configure a workflow backend named durable-review. This backend is a persistent HTTP workflow, the backend address points to the workflow API host, the workflow name is DurableAgentReview, the polling interval is 5 seconds, the timeout is 300 seconds, and the authentication token is resolved via key reference.

[0052] When the gateway starts, the workflow registry reads this configuration. If the global workflow function is enabled, the registry traverses the backend configuration, skips disabled backends, verifies that the backend type is persistent HTTP workflow, removes whitespace from both ends of the backend identifier, detects duplicate identifiers, and creates a persistent HTTP workflow runner. This runner internally stores the backend identifier, workflow name, configuration, event storage, logger, and HTTP client.

[0053] The client then sends a startup request to the gateway, including user input, a session identifier, and an optional structured payload. The gateway locates the corresponding runner based on the backend identifier in the request. The runner writes the backend identifier into the request metadata and then sends a startup request to the backend.

[0054] Upon receiving the request, the backend creates a running instance, generates a globally unique running instance identifier, writes the initial events to persistent state storage, and returns an acceptance response. The returned result includes the running instance identifier, current state, workflow identifier, backend identifier, and event set. Upon receiving the result, the gateway normalizes and fills in any missing fields and records the startup event in the runtime event storage.

[0055] Through steps 201 to 203 above, by using the pre-established mapping relationship to proxy and forward the startup request carrying the backend identifier, not only is the physical and logical decoupling between the lightweight proxy layer and the underlying specific persistence engine achieved, enabling a single gateway to have the scalability to uniformly proxy multi-tenant or multi-type backend tasks, but also by receiving and establishing a globally unique running instance identifier, the reliability of subsequent implementation of cross-process state snapshot query, event stream generation, and accurate external input recovery is improved.

[0056] In another example, the backend can generate a review plan based on user input and distribute tasks to three sub-processes: security review, architecture review, and cost review. These three sub-processes can be executed in parallel or simulated in the order implemented by the backend. After each sub-process is completed, the backend aggregates the review results and sets the workflow status to `waiting_for_input`.

[0057] The backend returns the port to be approved in the state snapshot, for example, the port is identified as human-approval, the summary is "Please approve the aggregated Agent execution plan", and a structured payload of security, architecture and cost review results. At this time, the backend does not need to keep the active thread waiting for approval, but persists the running state and the port to be approved.

[0058] The following section will further describe how to send status query requests to an external persistent workflow backend.

[0059] Reference Figure 3 Based on the running instance identifier of the target workflow instance, a status query request is sent to the external persistent workflow backend, including the following steps 301 to 302.

[0060] Step 301: Obtain the pre-configured polling interval parameters.

[0061] Step 302: Based on the polling interval parameter, periodically send a status query request carrying the running instance identifier to the persistent workflow backend until the current workflow status obtained is one of the terminal status sets.

[0062] Steps 301 to 302 are described in detail below.

[0063] In step 301 of some embodiments, firstly, a pre-configured polling interval parameter is obtained. This pre-configured polling interval parameter refers to a time frequency value set during gateway initialization or routing configuration for a specific external workflow backend, used to regulate the timing of subsequent state synchronization requests to the external engine. In actual configuration, this polling interval parameter can be pre-defined based on the real-time requirements for event observability in specific business scenarios and the carrying capacity of the persistent workflow backend interface.

[0064] In step 302 of some embodiments, a status query request carrying a running instance identifier is periodically sent to the persistent workflow backend based on a polling interval parameter. Specifically, using the obtained polling interval parameter as the time period, asynchronous polling calls containing the running instance identifier of the target workflow instance are continuously initiated to the external persistent workflow backend according to the periodic rhythm (e.g., sending a GET request to a specific status query endpoint of the backend via the HTTP protocol). This periodic polling mechanism based on a fixed rhythm does not require the external persistent workflow backend to have complex active event pushing capabilities (such as long connections or WebSockets). Instead, it uses an active pull method to obtain the latest status snapshot of the workflow instance, thereby ensuring the continuity of the event flow while effectively avoiding the continuous exclusive use of the proxy layer's active computing threads and network connection pool resources during the execution of long-cycle workflows.

[0065] In step 302 of some embodiments, the aforementioned periodic query action is continuously executed until the current workflow state obtained is one of the terminal state sets. The terminal state set refers to a set of state enumeration items used to represent the complete end of the lifecycle of a long-cycle workflow instance. This terminal state set includes completed states, failed states due to exceptions or retry exhaustion, and cancelled states caused by external instruction intervention. After obtaining a snapshot in each round of state query, the current workflow state is extracted and verified. If the state is a non-terminal state such as queuing, running, or waiting for input, the next round of query is triggered after a delay of one polling interval parameter. If it is determined that the current workflow state has fallen into the terminal state set, it indicates that the physical execution process of the workflow instance has terminated. At this time, exit boundary logic is triggered, and subsequent state query requests are stopped.

[0066] Through steps 301 to 302 above, the periodic issuance of status query requests is driven by a pre-configured polling interval parameter, replacing the synchronous waiting mode that is prone to resource exhaustion. This solves the problem of long-term invalid occupation of concurrent resources on the gateway side by long-cycle tasks. At the same time, by introducing a terminal state set as a polling exit boundary condition, it ensures that network requests and observation resources can be released in a timely and accurate manner when the workflow is completed, fails abnormally, or is canceled. Thus, without the need to persist the workflow backend and restructure the architecture to support event push, reliable tracking of the execution status of cross-process long-cycle tasks is achieved with low resource overhead.

[0067] Step 102: Filter the event set based on the preset output event records to obtain the filtered event set. Based on the comparison results between the current workflow state and the historical workflow state and the filtered event set, obtain the target event stream and then output the target event stream to the client.

[0068] Step 102 is described in detail below.

[0069] In step 102 of some embodiments, the event set is filtered based on a preset set of output event records to obtain a filtered event set. The output event record `seenEventIds` refers to an observation variable maintained during the lifecycle of an event stream to control incremental event output; it records the identifiers of events successfully sent to the client. Specifically, for the event set E returned in the target state snapshot, the event identifier corresponding to each event is read iteratively. If an event identifier already exists in the output event record `seenEventIds`, it is determined as a processed duplicate event and deleted; if an event identifier does not exist in the record, it is retained, thereby filtering out a set of events containing only newly added business events.

[0070] Further, based on the comparison results between the current workflow state and the historical workflow state, and the filtered event set, the target event stream is obtained and then output to the client. The historical workflow state `previousStatus` is another associated observation variable maintained to record the workflow state after the previous round of snapshot processing. When constructing the target event stream, on the one hand, the incremental events in the above-mentioned filtered event set are included in the event stream; on the other hand, the currently acquired workflow state is compared with the historical workflow state `previousStatus`. If there is a logical difference between the two (i.e., indicating that the workflow state has undergone a substantial transition during this period), then incremental data events to characterize the state transition are generated based on the comparison result and combined with the filtered event set to obtain the complete target event stream, which is then asynchronously output to the client. This allows for the deterministic generation of a continuous, non-repeating observation event stream based on discretely acquired state snapshots without relying on an external backend to actively provide long-connection push capabilities, as described below.

[0071] Reference Figure 4 The event set is filtered based on the preset output event records to obtain a filtered event set. Based on the comparison results between the current workflow state and the historical workflow state and the filtered event set, the target event flow is obtained, including the following steps 401 to 404.

[0072] Step 401: Determine the events corresponding to the event identifiers that are not recorded in the output event records from the event set, and obtain the filtered event set.

[0073] Step 402: When the current workflow state is inconsistent with the historical workflow state, generate a composite state event based on the current workflow state.

[0074] Step 403: Combine the filtered event set and the synthesized state events to obtain the target event stream.

[0075] Step 404: After outputting the target event stream to the client, update the event identifiers in the filtered event set to the output event records, and update the historical workflow status to the current workflow status.

[0076] Steps 401 to 404 are described in detail below.

[0077] In step 401 of some embodiments, events corresponding to event identifiers not recorded in the output event record `seenEventIds` are determined from the event set to obtain a filtered event set. Specifically, for the event set E contained in the state snapshot obtained from the backend, the event identifier of each business event is read through it, and then the read event identifier is compared and checked with the output event record `seenEventIds`: if an event identifier is found to already exist in `seenEventIds`, it indicates that the event belongs to a processed event repeatedly returned by the backend, and it is filtered and deleted; if an event identifier is determined not to exist in `seenEventIds`, the event is identified as a newly added business event obtained in this round. Through the above comparison and filtering logic, all newly added business events are extracted to form the filtered event set.

[0078] In step 402 of some embodiments, when the current workflow status is inconsistent with the previous status of the historical workflow, a synthetic status event is generated based on the current workflow status. The synthetic status event is compensatory observation data autonomously generated based on the state differences between two adjacent snapshots. The data structure of the synthetic status event includes fields such as the previous status, current status, running instance identifier, and generation time. During the comparison, the current workflow status `currentStatus` read from the current round of snapshots is compared with the recorded historical workflow status `previousStatus`. If the two are inconsistent (e.g., the status transitions from running to waiting for input), even if no new original event is generated in the event set of the backend status snapshot of this round, a synthetic status event carrying `$currentStatus` information will be proactively generated to compensate for the potential lack of state change events in the external workflow backend.

[0079] In step 403 of some embodiments, the filtered event set and the synthesized state events are combined to obtain the target event stream. After completing the deduplication filtering of the original events and the compensation generation for state transitions, all incremental business events in the filtered event set are logically integrated with the synthesized state events to transform the data extracted from the discrete snapshots into a sequence with chronological flow logic, thereby obtaining the target event stream output to the client. This target event stream contains both the actual deduplicated business actions and the state transition nodes that accurately reflect the workflow lifecycle, providing continuous and observable data for the front end.

[0080] In step 404 of some embodiments, after outputting the target event stream to the client, the event identifiers in the filtered event set are updated to the output event record, and the historical workflow status is updated to the current workflow status. After confirming that the target event stream output action has been executed, the maintained observation variables need to be state-advanced to form a data loop. Specifically, the event identifiers of all newly added events in the filtered event set are appended to the output event record seenEventIds; simultaneously, the value of the historical workflow status previousStatus is updated to the current workflow status currentStatus$.

[0081] Through steps 401 to 404 above, the issue of duplicate events on the client side caused by the backend repeatedly returning the same events in consecutive snapshots is effectively avoided by introducing already output event records for identification and deduplication. At the same time, by comparing historical states and dynamically generating synthetic state events, the observability blind spot of the external workflow engine not actively generating events during critical node transitions is filled, ensuring that even without the need for backend support for long connection push, a rigorously deduplicated and coherent incremental event sequence can still be output to the client based on a stateless proxy architecture.

[0082] Reference Figure 5 After outputting the target event stream to the client, the method further includes the following steps 501 to 502.

[0083] Step 501: Match the current workflow status with a preset set of terminal statuses to obtain a status matching result. The set of terminal statuses includes at least one of the following: completion status, failure status, and cancellation status.

[0084] Step 502: When the state matching result indicates that the current workflow state belongs to the terminal state set, and after confirming that the filtered event set and the synthesized state event in the target event stream have been output, the process of outputting the workflow event stream to the client ends.

[0085] Steps 501 to 502 are described in detail below.

[0086] In step 501 of some embodiments, the current workflow state is matched with a preset set of terminal states to obtain a state matching result. The preset set of terminal states refers to a set of state enumeration items predefined in the workflow state machine model, used to characterize that a long-cycle workflow instance has reached the final stage of physical execution in its lifecycle, and no further business logic-driven state transitions will occur. The set of terminal states includes at least one of the following: a completed state (corresponding to the completed state where all steps have been successfully executed), a failed state (corresponding to the failed state where the process terminates due to an exception or exhaustion of retries), and a cancelled state (corresponding to the cancelled state where the process ends prematurely due to external intervention or approval rejection).

[0087] In step 501 of some embodiments, the state matching result refers to the judgment conclusion output after logically determining the attribution of the current workflow state obtained in this round of parsing with a preset set of terminal states. Specifically, the enumerated value of the current workflow state currentStatus is compared with the reference values ​​of each item in the set of terminal states. If the current workflow state currentStatus matches any item in the set, a positive matching result indicating that the workflow has reached the final state is obtained; if it does not match, a negative matching result indicating that the workflow is still actively executing or suspended and waiting is obtained.

[0088] In step 502 of some embodiments, when the state matching result indicates that the current workflow state belongs to the terminal state set, and after confirming that both the filtered event set and the synthesized state events in the target event stream have been output, the process of outputting the workflow event stream to the client ends. In conventional data stream processing logic, once a task is detected to be in a terminal state, the underlying connection is often immediately cut off. However, since this embodiment adopts a polling mechanism based on discrete snapshots, in the last round of snapshot data when the workflow enters the completed, failed, or canceled state, the external persistent workflow backend is very likely to simultaneously return the last batch of newly added original business events that declare the task terminated.

[0089] To prevent data loss due to premature stream closure, this embodiment sets output order restrictions and exit boundaries. Once the workflow is confirmed to have entered the terminal state based on the aforementioned state matching results, the executing entity (gateway layer) does not immediately terminate stream transmission. Instead, it triggers confirmation logic: waiting for the filtered event set obtained in this round of processing and the synthetic state event generated based on the last state transition to be completely and successfully sent to the client. Only after confirming the output of all incremental target event stream data for this round does the process of cleaning up underlying resources, disconnecting polling, and ending the output of workflow event streams to the client begin.

[0090] Reference Figure 6 This is a schematic diagram of the state transition logic of a workflow state machine provided in an embodiment of this application. Figure 6 As shown, the workflow state machine is abstracted into a finite set of states with six dimensions, specifically divided into non-terminal states (including Queued, Running, and Waiting_for_input) and terminal states (including Completed, Failed, and Cancelled). By decomposing the workflow lifecycle into fine-grained states, accurate observation data is provided for event flow generation and polling boundary control on the gateway side.

[0091] Combination Figure 6 The specific transition chain is as follows: after the persistent workflow backend receives the workflow start request forwarded by the gateway and successfully creates a running instance, the workflow first enters the "Queued" state. If a cancellation instruction is received at this stage, the "Cancel before Startup" condition is directly triggered, transitioning to the "Cancelled" state. If the underlying scheduler successfully allocates computing resources and starts execution, it transitions to the "Running" state. In the "Running" state, if all the predetermined steps of the workflow are successfully executed, it transitions to the "Completed" state. If a serious exception occurs or the retry mechanism is exhausted during this period, it transitions to the "Failed" state. If an intervention instruction is received, it transitions to the "Cancelled" state based on the "Cancel during Run" logic.

[0092] To support human-in-the-loop or external asynchronous collaboration mechanisms in complex processes, when a workflow reaches a specific node requiring manual approval or external system input during its "Running" execution, the backend proactively releases the active computation thread and transitions to the "Waiting_for_input" state. In this state, the workflow instance is persistently suspended. Subsequently, based on the different response results submitted by the client or external system to the exposed input port, the workflow will trigger different recovery branches: if a valid and approved approval response is received, the workflow will transition back to the "Running" state to execute subsequent nodes according to the "continue execution after receiving a valid response" logic; in some single-step confirmation scenarios, it can also directly enter the "Completed" state according to the "complete directly after response" logic; conversely, if an exception occurs during response processing, or the response result is approval rejection, it will transition to the "Failed" or "Cancelled" terminal states, respectively.

[0093] Understandable, Figure 6The state machine model shown demonstrates that by modeling "waiting for input / approval" independently, it not only enables the front-end UI and monitoring system to accurately identify resource usage, but also allows the gateway layer to use this state as a trigger condition to expose the set of input ports to the client, thereby ensuring that external approval responses can be accurately routed and drive the reliable migration and recovery of workflow states.

[0094] Through steps 501 to 502 above, by introducing a terminal state set for completion state matching and setting sequential output and confirmation boundaries after sensing the terminal state, the technical problem of traditional stateless gateways being cut off due to premature connection closure at the end of a task is overcome. This ensures that while maintaining the timely release of gateway resources, the client can fully obtain all observable data up to the end of the workflow execution, thereby guaranteeing the integrity and consistency of the global perspective of the asynchronous event stream.

[0095] Reference Figure 7 This is a logical diagram illustrating a polling event stream generation process provided in an embodiment of this application. For example... Figure 7 As shown, when a client initiates a request to subscribe to an event stream, the execution entity (gateway) first performs an initialization operation, initializing the already output event records (such as...) within the current event stream's lifecycle. Figure 7 The "seen event set" and historical workflow status (such as...) Figure 7 (The "lastStatus" in the image). Subsequently, the process enters the main polling loop, periodically sending query requests to the external persistent workflow backend based on the pre-configured polling interval parameter (PollIntervalSeconds) to obtain a snapshot of the target state. After obtaining the snapshot, the gateway first reads the event set in the snapshot and checks whether the event ID of each event is appearing for the first time. If the event ID is not recorded in the seen event set, it is determined to be a new business event, output as the backend's original event to the client, and the seen event set is updated synchronously; if the event ID already exists, it is determined to be a duplicate event returned by the backend and is skipped. This step effectively ensures strict deduplication of incremental events, avoiding duplicate consumption by the client.

[0096] After filtering and outputting the set of business events, the process proceeds to the state transition compensation phase. The gateway logically compares the current workflow state in the snapshot with the recorded historical workflow state (lastStatus). If the comparison shows that the current state is different from lastStatus, it indicates that a phase transition has occurred in the workflow during this period. The gateway will proactively generate and output a synthetic status event (status synthetic event) to characterize this transition, and then overwrite and update the value of lastStatus to the latest current state. If the comparison shows that the state has not changed, the generation and update steps are skipped directly along the negative branch. This design effectively compensates for the blind spot in observation where the external engine may not proactively generate events during state transitions.

[0097] Finally, the process enters the flow end control and exit boundary verification phase. The gateway extracts the current workflow state and determines whether it falls within a preset set of terminal states (i.e., Figure 7 The states shown are completed, failed, or cancelled. If the current state does not belong to any of the above-mentioned terminal states, the process proceeds along the negative branch to the "Wait for the next round of polling" node. After suspending the corresponding polling interval, the next round of state snapshot query is retried. If it is determined that the current state already belongs to any of the above-mentioned terminal states, after confirming that the newly added backend original events and synthetic state events in this round have been successfully sent (i.e., the final event is output), the "End Event Stream" operation is triggered, polling is disconnected, and data output to the client is terminated.

[0098] Reference Figure 8 This is an interactive sequence diagram of a three-stage HTTP delegation process provided in an embodiment of this application. For example... Figure 8 As shown, during the workflow initiation phase, the client first submits a workflow initiation request to the AI ​​Agent gateway. Upon receiving this request, the gateway calls the RunAsync interface of its internal workflow executor to initiate the delegate. Subsequently, the workflow executor sends a start request to the persistent workflow backend (e.g., via a POST call to the / api / workflows / {name} / run endpoint). Upon receiving the start request, the persistent workflow backend creates a corresponding run instance in its underlying state storage and persists the initial state of that workflow instance. After the state storage completes recording, it returns the generated run instance identifier (runId) and the initial state. Based on this, the persistent workflow backend returns an acceptance response (e.g., carrying a 202 Accepted status code) and the initial run result (AgentWorkflowRunResult) to the workflow executor. The workflow executor normalizes this run result, and finally, the gateway returns response data to the client containing the run instance identifier, initial state, and initial events, thus establishing the addressing basis for subsequent interactions.

[0099] During the status query phase, the client, based on the running instance identifier obtained during the startup phase, initiates a request to the AI ​​Agent gateway to query the running status. The gateway triggers the runner to send a status query request to the persistent workflow backend by calling the GetAsync interface of the workflow runner (e.g., by calling the endpoint / api / workflows / {name} / status / {runId} via the GET method). The persistent workflow backend reads a status snapshot of the target workflow instance from the state store based on this identifier. The state store then returns structured information such as the current macro-state, event set, set of input ports, and output results. The persistent workflow backend returns this complete status snapshot (AgentWorkflowRunSnapshot) to the workflow runner. After the runner performs normalization processing on the gateway side, the gateway finally synchronizes the current status snapshot back to the client, thus enabling the stateless agent layer to observe the execution progress of the external persistent engine on demand.

[0100] During the response recovery phase, when a workflow is in a waiting-for-input state due to execution reaching a specific node, the client submits external input or an approval response to the AI ​​Agent gateway based on the input port exposed in the state snapshot. The gateway calls the RespondAsync interface of the workflow runner to handle the response load, and the workflow runner then forwards the response request to the persistent workflow backend (e.g., by calling the / api / workflows / {name} / respond / {runId} endpoint via the POST method). After receiving the external response, the persistent workflow backend writes it to the state store and drives the workflow state machine to transition downwards. After the state store completes the change persistence, it returns the updated state, and the persistent workflow backend then returns a snapshot containing the updated state to the workflow runner. Finally, the workflow runner normalizes the updated snapshot, and the gateway returns the latest state after the workflow resumes execution to the client.

[0101] In one example, the client can directly query the workflow status or subscribe to the event stream. If subscribing to the event stream, the gateway runner calls the backend status query interface at configured polling intervals to obtain a status snapshot. The runner maintains two observation variables, `seenEventIds` and `previousStatus`, throughout the event stream's lifecycle. These variables are only used for gateway-side event output control and do not constitute the persistent execution state of the workflow instance.

[0102] For each snapshot, the runner first iterates through the event set and determines whether the event has already been output based on its event identifier. Events that haven't been output are sent to the client, and their identifiers are written to `seenEventIds`; output events are filtered out. The runner then compares the current status with `previousStatus`. If the status changes from `running` to `waiting_for_input`, the runner generates a status event and sends it to the client. Upon receiving this status event, the client can update the UI, displaying the approval button, the input port, and the review summary.

[0103] When a subsequent state becomes completed, failed, or cancelled, the runner does not immediately close the event stream. Instead, it processes all new events in the final snapshot and outputs the necessary synthetic state events before ending the event stream. If the backend returns the same event identifier in two consecutive snapshots, the client only receives it once. If the backend does not generate a state change event, the client can still learn about the state transition through the gateway's synthetic state events.

[0104] Below is sample code for event stream generation.

[0105] sequenceDiagram Participant Client as Client Participant System as Polling System participant storage as state storage loop polling loop System->>Storage: queryStatus(runId) Storage-->>System: snapshot (events + status) alt has new events loop iterates through events Is System->System: event.id in seenEventIds? alt - Never seen System->>Client: emit(event) System->>System: Add event.id to seenEventIds end end end alt's status has changed. System->>Client: emit(statusEvent(runId, previousStatus,snapshot.status)) end System->>System: previousStatus = snapshot.status alt (Terminated state) System->>Client: Close the stream after all events are emitted. System->>System: break polling else continue polling System->>System: wait(pollInterval) end end The code above illustrates the internal polling control logic for generating an event stream based on a state snapshot. In the continuously executing polling loop, a state query is first initiated from the state store based on the running instance identifier, and a state snapshot containing the event set and the current workflow state is obtained. Subsequently, the event set in the snapshot is traversed, and deduplication is performed by checking whether the event identifier of each event has already been recorded in the output event record (seenEventIds). If an incremental event is determined to be unrecorded, it is output to the client, and the event identifier is simultaneously appended to the output event record.

[0106] Based on this, if a comparison reveals a change in the current workflow state compared to the historical state, a synthetic state event containing state transition information is triggered and output. Subsequently, the maintained historical state (previousStatus) is overwritten and updated to the current snapshot state. At the end of a single polling process, a terminal state exit check is performed: if the workflow is determined to have reached the termination state, it is forcibly waited for all incremental original events and synthetic state events of this round to be issued before safely closing the event stream and exiting the polling mechanism; if the termination state has not been reached, it is suspended and waited according to the preset polling interval (pollInterval) to continue triggering the next round of state queries.

[0107] Step 103: When the current workflow status is waiting for input, output the set of ports to be input to the client.

[0108] Step 103 will be described in detail below.

[0109] In step 103 of some embodiments, when the current workflow state is in a waiting-for-input state, a set of ports to be input is output to the client. The waiting-for-input state is a specific non-terminal state in a finite workflow state machine, representing a persistent suspension phase where the workflow actively pauses subsequent computation threads and releases activity resources when reaching critical nodes requiring human intervention, such as manual approval or external callback verification. When the target state snapshot is parsed and the current workflow state is identified as being in this waiting-for-input state, a corresponding port exposure mechanism is triggered, outputting the set of ports to be input carried in the snapshot to the client according to a predetermined communication protocol. Each port to be input in the set represents a legitimate business recovery entry point recorded by the persistent workflow at the runtime checkpoint. By outputting this set, the monitoring system, approval front-end, or external collaboration system can accurately determine that the current workflow is in a waiting-for-external-intervention state and obtain the entry context information necessary for response verification.

[0110] Step 104: Receive the external response request sent by the client for the set of ports to be input, and forward the external response request containing the target port identifier to the persistent workflow backend, so as to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier.

[0111] Step 104 is described in detail below.

[0112] In step 104 of some embodiments, an external response request from the client for the set of ports to be input is received, and the external response request containing the target port identifier is forwarded to the persistent workflow backend to instruct the persistent workflow backend to resume execution of the node corresponding to the target port identifier. Here, the external response request refers to the structured data payload generated by the client after obtaining and displaying the ports to be input, based on the end-user's approval operation or the confirmation instruction from an external business system; the target port identifier is the unique identifier carried in the request that points to a specific port in the previously exposed set of ports to be input.

[0113] Upon receiving the external response request, the target port identifier carried in the request is used for association matching, and the request is accurately forwarded to the corresponding persistent workflow backend. This allows the persistent workflow backend to accurately locate the corresponding waiting node that is currently in a paused state based on the target port identifier after receiving the response. This, in turn, drives the workflow state machine to migrate backward and reliably resumes the computation and execution of the node and subsequent associated tasks, as described in detail below.

[0114] Reference Figure 9The set of input ports includes at least two different input ports. An external response request containing the target port identifier is forwarded to the persistent workflow backend to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier, including the following steps 901.

[0115] Step 901: Forward the external response request to the persistent workflow backend to instruct the persistent workflow backend to resume the execution of the target waiting node corresponding to the target port identifier when the target workflow instance is in the waiting input state and the target port identifier is successfully matched, and to keep the nodes corresponding to other unresponded input ports in the waiting state.

[0116] Step 901 will be described in detail below.

[0117] In step 901 of some embodiments, targeted processing is performed for complex business scenarios where the set of input ports includes at least two different input ports. These at least two different input ports typically correspond to situations where fan-out or multi-branch parallel processing occurs during workflow orchestration. For example, when executing a specific review plan, tasks are distributed in parallel to multiple independent sub-processes such as security review, architecture review, and cost review. In this scenario, when the external persistent workflow backend suspends the workflow and generates a state snapshot, the returned set of input ports will contain multiple independent logical recovery entries with unique port identifiers. The external response request containing the target port identifier is forwarded to the persistent workflow backend to directionally pass the business response payload submitted by the client for a specific branch to the underlying orchestration engine, thereby triggering local state-driven processes.

[0118] Then, the external response request is forwarded to the persistent workflow backend, instructing it to perform targeted node recovery when the target workflow instance is in a waiting-for-input state and the target port identifier matches successfully. Specifically, after receiving the forwarded external response request, the persistent workflow backend needs to perform multiple deterministic boundary checks. First, it confirms that the current target workflow instance still exists legally and is in a waiting-for-input state, i.e., the waiting_for_input state, rather than having entered a completed or failed terminal state. Subsequently, it performs port identifier attribution and validity checks, i.e., determining whether the target port identifier carried in the request exists in the set of waiting-for-input ports recorded in the current state snapshot, and checking whether it has been consumed or expired, effectively preventing the external response from being misrouted to the wrong workflow instance or the wrong waiting node due to incorrect identifiers or replay operations.

[0119] When the matching condition is met, the persistent workflow backend is instructed to resume execution of the target waiting node corresponding to the target port identifier, while keeping the nodes corresponding to other unresponsive input ports in a waiting state. In specific scenarios where multiple input ports exist concurrently, the target waiting node refers to a specific active thread or execution step in the workflow orchestration logic that is uniquely bound to the target port identifier. Based on the successfully matched identifier, the persistent workflow backend only wakes up and drives the target waiting node to continue execution (e.g., recording the result of a single review and changing the local state of that branch), while for the remaining ports in the set of input ports that have not yet received a valid external response, no additional intervention is made, keeping their corresponding nodes suspended in a waiting state, thus ensuring the execution isolation and independence of state transitions between parallel workflow branches.

[0120] Through step 901 above, in concurrent scenarios involving multiple manual approvals or external input nodes, precise matching of target port identifiers and multiple state checks enable the underlying persistent orchestration engine to perform targeted state transitions and drives only for specific nodes that actually receive legitimate responses, without mistakenly triggering or interfering with the waiting logic of other parallel branches. This mechanism not only significantly improves the routing accuracy of long-cycle workflows in multi-party collaborative processing but also effectively ensures the isolation reliability of complex orchestration tasks during local state progression.

[0121] Reference Figure 10 This is an interactive timing diagram of a manual approval recovery process provided in an embodiment of this application. For example... Figure 10 As shown, when the workflow enters the suspended waiting phase, and the workflow orchestration engine reaches a specific human approval node, it actively suspends the current computation task, saves the "waiting_for_input" state to the persistent state storage, and synchronously writes the specific input port information (e.g., the approval port identified as human-approval). Subsequently, the AIAgent gateway periodically polls to obtain state snapshots through the backend interface. When the persistent state storage returns snapshot data containing the waiting_for_input state and the corresponding set of pending input ports (PendingInputs), the gateway layer transforms it into observable state events and pending input port data, and asynchronously outputs it to the approval interface or chatbot. Based on this, the approval interface displays the workflow review summary and executable approval operation entry points to external approvers.

[0122] During the external response and recovery workflow phase, after evaluating the review summary, the approver submits a response action through the approval interface, including the approval result (approved or rejected), comments, and the operator's identifier. The approval interface sends the encapsulated workflow response (AgentWorkflowResponse) to the AI ​​Agent gateway. Upon receiving this data, the gateway extracts the corresponding runtime instance identifier and target port identifier, and accurately forwards the external response to the workflow orchestration engine by sending a specific forwarding request (e.g., POST / respond / {runId}). After receiving the forwarded response, the workflow orchestration engine performs a validity and legality check on the target port using persistent state storage, and persistently records the approval response after successful verification.

[0123] After verification and recording, the workflow orchestration engine drives the branch flow of the underlying state machine based on the specific approval result. When the approval result is "Approved," the orchestration engine is woken up and resumes the execution of subsequent steps after the current approval node. After the relevant tasks are completed, a "completed" state is written to the persistent state storage. Subsequently, the gateway obtains a snapshot of the "completed" state through a state query and outputs the completion event and final execution result to the approval interface. Conversely, if the approval result is "Approved Rejected," the orchestration engine terminates the subsequent execution steps of the corresponding branch and directly writes a "cancelled" state and the corresponding rejection event record to the persistent state storage. After obtaining a snapshot of the "cancelled" state in subsequent polling, the gateway outputs a cancellation event and the final state result to the approval interface. Through the above process, accurate suspension and highly reliable recovery of the state of long-cycle workflows under manual intervention scenarios are achieved.

[0124] In addition, refer to Figure 11 The target state snapshot and external response request include variable service payloads, which are in a structured data format; the method also includes the following step 1101.

[0125] Step 1101: Upon receiving the target state snapshot and external response request, perform data parsing and routing distribution on the fixed shell fields in the target state snapshot and external response request, and maintain the original structured data format of the variable service payload for transmission; wherein, the fixed shell fields include the running instance identifier, the current workflow status, the event identifier, and the target port identifier.

[0126] Step 1101 will be described in detail below.

[0127] In step 1101 of some embodiments, the target state snapshot and external response request include a variable business payload, which is encapsulated in a structured data format. The variable business payload (the Payload field in the underlying data interaction protocol) refers to dynamically changing data content highly related to specific business logic, generated, transferred, or collected during the execution of specific AI agent orchestration or long-cycle business processes. Examples include user-inputted text parameters, intermediate results generated collaboratively by multiple agents, approval opinions from specific approval nodes, or callback contexts from external systems. Because the business data structures of various workflows differ significantly and evolve frequently, this application uniformly constrains such business data to use a structured data format (e.g., raw JSON text, JsonElement, or JsonNode, etc., common structured representations) to replace the traditional strongly coupled, strongly typed object model of backend business processes.

[0128] Upon receiving a target state snapshot and an external response request, the gateway executes a differentiated processing strategy for the message data, namely, only parsing and routing the data for the fixed shell fields. The fixed shell fields refer to a set of well-defined and fixed-type basic technical control fields necessary for carrying out the gateway scheduling mechanism. These include the running instance identifier (used for instance-level addressing), the current workflow status (used to drive the event flow generation logic), the event identifier (used for incremental deduplication filtering), and the target port identifier (used to limit the routing node for approval recovery). After receiving the data, the gateway performs strongly typed explicit deserialization identification and security verification only on these fixed shell fields, thereby driving underlying protocol-level gateway actions such as state tracking, deduplication compensation, and request forwarding.

[0129] While scheduling and parsing fixed shell fields, the gateway maintains the original structured data format of the variable service payload during transmission. Specifically, when exchanging data across processes or network layers, the gateway does not reference the specific business assemblies of the external workflow backend, does not perform deserialization operations on strongly typed business objects, and does not rely on any runtime reflection or unknown polymorphic metadata parsing mechanisms to probe the internal details of the variable service payload. Instead, the gateway layer treats the variable service payload as a logically decoupled data packet and maintains its original structured data format (e.g., in the form of raw JSON nodes) for direct, unmodulated transmission in the bidirectional communication link between the client and the persistent workflow backend.

[0130] In this application, the data model of the gateway and backend adopts a boundary design of "fixed shell fields + JSON structured carrier". The fixed shell fields are used to carry technical fields that the gateway must understand and route, such as instance identifiers, backend identifiers, workflow identifiers, status, event identifiers, port identifiers, and terminal status. Variable structured business data is uniformly represented as a JSON structured carrier, rather than a strongly typed or polymorphic object from the backend. Requests, responses, execution results, status snapshots, events, input ports, and output payloads can all contain nullable JSON structured fields.

[0131] The data boundary has the following technical constraints: the gateway only performs strong type identification, routing, deduplication, state comparison, and security verification on fixed shell fields; the gateway does not reference backend business assemblies and does not deserialize business payloads into backend business strong types; the gateway does not rely on runtime reflection or unknown polymorphic metadata to parse business payloads; variable business payloads are passed through as JsonElement, JsonNode, raw JSON text, or equivalent JSON structured carriers; the gateway serialization context can be explicitly registered at compile time, so that fixed shell fields form a statically analyzable serialization path; the backend can independently evolve the business payload structure, as long as JSON compatibility is maintained; undefined structured payload fields can be omitted in the JSON output to reduce transmission volume.

[0132] Through these boundaries, the gateway can perform technical processing such as event deduplication, state synthesis, port recovery, and authentication forwarding without needing to understand the internal structure of the backend business objects, thus adapting to NativeAOT or other pre-compiled and tailored deployment environments.

[0133] The core data object can use the field structure shown in the table below.

[0134]

[0135] Through step 1101 above, by limiting the gateway to only parse and route fixed shell fields and decoupling the format of variable business payloads and passing them through in their original form, the lightweight gateway completely eliminates its direct dependence on complex backend business type definitions. This mechanism effectively avoids the risk of deserialization crashes caused by dynamic proxies or runtime reflection in cloud-native lightweight deployment environments such as NativeAOT, ensuring extremely high operational stability of the gateway. At the same time, when the structured business payload of the external persistent workflow backend undergoes field additions or deletions or architectural evolution, the gateway layer does not need to synchronously update references or redeploy, enhancing the architectural decoupling and smoothness of business evolution of the entire long-cycle workflow scheduling system.

[0136] Furthermore, this application's solution manages backend runners uniformly through a workflow registry. During initialization, the registry reads the configuration, filters disabled backends, validates backend types, standardizes backend identifiers, detects duplicate identifiers, and creates corresponding runner instances. At runtime, the registry quickly routes to the corresponding runner based on the backend identifier passed from the client. The registry also supports listing summaries of all registered backends and cascading the release of runner instances implementing the release interface when the gateway is closed, thereby preventing the leakage of HTTP connections, sockets, or other resources.

[0137] In some embodiments, the gateway runner of this application can resolve the actual access token via key reference and append a Bearer Token when sending requests to the backend. The backend base address is injected via configuration and can be restricted to an absolute URL. The runner can disable automatic redirection to prevent workflow requests from being redirected to unexpected targets. The polling interval and timeout are controlled by configuration and can be limited to a preset range to prevent excessive polling from overwhelming the backend or consuming resources indefinitely.

[0138] To further illustrate the feasibility and robustness of the embodiments of this application in complex application environments, the following detailed explanation is provided in conjunction with specific key anomaly scenarios and their corresponding handling mechanisms. First, during the state snapshot polling process, for anomaly scenarios where the external persistent workflow backend may repeatedly return events (i.e., consecutively acquired state snapshots contain the same event identifier), the gateway maintains a set of output event identifiers within the current lifecycle and performs deduplication comparison on the read events, thereby ensuring that only newly added business events appearing for the first time are output, avoiding duplicate processing of approvals, execution actions, or final state events by the client. Simultaneously, for anomaly scenarios where the workflow state undergoes a physical transition (e.g., the backend state changes from running to waiting for input) but the backend fails to synchronously add new events to the event set, the gateway proactively compares the current state with the historical state recorded in the previous round, and autonomously generates a synthetic state event when the two are inconsistent. This allows the client to promptly display the corresponding approval entry or state change prompt without needing to infer the state change based on underlying data.

[0139] Secondly, to address potential port mismatch scenarios during external collaboration, if the target port identifier (PortId) carried in the received external response request does not belong to the set of input ports exposed by the current state snapshot, the backend will directly reject the response request, not drive any workflow state migration backward, and synchronously return an error status or error response. This strong validation logic effectively prevents external responses or illegal requests from being misrouted to incorrect suspended waiting nodes. Furthermore, when executing a state query, if a backend query timeout trigger condition is encountered (i.e., the time for the gateway to query the backend state snapshot exceeds the pre-configured timeout threshold), the gateway will proactively terminate the query operation and expose diagnosable error information to the caller. However, it will not clear the external backend's running instance resources, avoiding indefinite occupation of the gateway's underlying network connection and preserving the feasibility of subsequently re-initiating the query and resuming observation using the running instance identifier (runId).

[0140] Finally, when dealing with anomalies at the overall architecture level, in scenarios where the gateway restarts due to deployment upgrades or process crashes, since the gateway itself does not store persistent workflow execution contexts, it can directly re-initiate queries to the backend based on the backend identifier and running instance identifier provided by the client to obtain the latest state snapshot after restarting. This proves that the execution state of long-cycle workflows is completely independent of the gateway's memory viability. Furthermore, for anomalies where the backend returned results show blank WorkflowId or BackendId, the gateway automatically completes the missing identifiers using the corresponding identifier parameters in the local registry configuration, thus ensuring the integrity of data dimensions when outputting to the client and writing event logs. For scenarios where the backend business payload structure changes frequently (e.g., the backend adds or adjusts specific business fields within the payload), the gateway adopts a strategy of directly passing through the variable business payload as a JSON structured carrier, without performing deserialization operations pointing to the backend business type. This ensures that the continuous evolution of the backend business model does not require the gateway to synchronously update business type references.

[0141] Reference Figure 12 This is a schematic diagram of the overall architecture logic of a workflow event processing system provided in an embodiment of this application. Figure 12 As shown, the system architecture is logically divided into two core parts: the Gateway Layer and the Backend Layer. It uses the AI ​​Agent Gateway to achieve interactive connections with external clients (such as management UI, chatbots, and other terminals), thereby enabling proxy scheduling and event distribution of long-cycle workflows.

[0142] Specifically, within the gateway layer, an integrated API facade serves as a unified traffic entry point, responsible for receiving operation requests from clients and passing them down to the workflow registry. The workflow registry matches the request content with the corresponding route mapping based on the preset configuration and then hands it over to the persistent HTTP workflow runner for core processing. This workflow runner acts as a proxy hub for communication between the gateway layer and external backends. When handling long-cycle tasks and generating event streams, it works in conjunction with a state snapshot poller and a runtime event store. The state snapshot poller triggers asynchronous query operations to external backends according to a set schedule, while the runtime event store records necessary observations such as startup and flow on the gateway side. The entire gateway layer is designed as a lightweight runtime environment and does not directly persist the business execution context of workflow instances.

[0143] Within the backend layer, a backend HTTP interface (BackendApi), a persistent workflow host, a workflow orchestration engine, and a persistent state store are deployed. For cross-layer data and control interaction, the gateway layer's persistent HTTP workflow runner sends contractual instructions such as workflow start (Run), query (Get), and external response (Respond) to the backend HTTP interface via network calls. Simultaneously, the gateway-side state snapshot poller independently initiates "periodic Get state snapshot" requests to the backend. Upon receiving these instructions, the backend HTTP interface drives the backend's persistent workflow host and workflow orchestration engine to execute specific task scheduling, checkpoint setting, and node recovery logic, and performs read / write interactions with the underlying persistent state store. After data loading is complete, the backend HTTP interface returns a data stream containing current progress information—"state snapshot / event / pending input port"—to the gateway layer's persistent HTTP workflow runner for deduplication filtering and event stream reassembly and output.

[0144] Figure 12 The cross-process layered decoupled architecture shown pushes capabilities such as state persistence, task retries, and thread suspension to the backend persistent workflow orchestration engine and state storage unit, while retaining lightweight logic such as request routing, state protocol conversion, event anti-duplicate compensation, and precise response forwarding at the gateway layer. This ensures the high concurrency capacity of the AI ​​Agent gateway and deployment compatibility in the NativeAOT environment, while also achieving highly reliable tracing and execution of long-cycle workflows with human-in-the-loop characteristics.

[0145] Through steps 101 to 104 above, without the application itself storing the persistent execution state of the workflow instance, the periodic polling and incremental filtering comparison algorithm based on state snapshots effectively removes redundant business events and accurately captures the key state transitions of the workflow at each stage, thus providing the client with a continuous and consistent stream of observation events. At the same time, combined with the conditional exposure of the input port and the response forwarding mechanism with the target port identifier, it specifically supports persistent waiting and targeted wake-up of long-cycle workflows in complex multi-branch scenarios such as manual approval or external system callbacks. This avoids the long-term occupation of proxy layer concurrent resources by long connections and the context loss caused by unexpected process restarts. It also improves the routing accuracy and business flow reliability when external interactive systems intervene in persistent orchestration workflows.

[0146] This application also provides a workflow event execution apparatus that can implement the above-described workflow event execution method, see reference. Figure 13 The device 1300 includes: The first request sending module 1310 is used to send a status query request to an external persistent workflow backend based on the running instance identifier of the target workflow instance, and to obtain a target status snapshot of the target workflow instance. The target status snapshot includes the current workflow status, event set, and input port set. The event stream sending module 1320 is used to filter the event set based on the preset output event records to obtain the filtered event set, and to obtain the target event stream based on the comparison result between the current workflow state and the historical workflow state and the filtered event set, and then output the target event stream to the client. The input port sending module 1330 is used to output the set of ports to be input to the client when the current workflow state is waiting for input. The second request sending module 1340 is used to receive external response requests sent by the client for the set of ports to be input, and forward the external response request containing the target port identifier to the persistent workflow backend, so as to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier.

[0147] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, the specific implementation of the workflow event execution device is basically the same as the specific implementation of the workflow event execution method described above, and will not be repeated here.

[0148] This application also provides an electronic device, including: At least one memory; At least one processor; At least one program; The program is stored in memory, and the processor executes at least one program to implement the workflow event execution method described above in this application. The electronic device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), and in-vehicle computers.

[0149] Please see Figure 14 , Figure 14 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1401 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1402 can be implemented in the form of ROM (Read-Only Memory), static storage device, dynamic storage device, or RAM (Random Access Memory). The memory 1402 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1402 and is called and executed by the processor 1401 using the workflow event execution method of the embodiments of this application. The input / output interface 1403 is used to implement information input and output; The communication interface 1404 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1405 transmits information between various components of the device (e.g., processor 1401, memory 1402, input / output interface 1403, and communication interface 1404); The processor 1401, memory 1402, input / output interface 1403 and communication interface 1404 are connected to each other within the device via bus 1405.

[0150] This application embodiment also provides a storage medium, which is a computer-readable storage medium, storing a computer program that, when executed by a processor, implements the above-described workflow event execution method.

[0151] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0152] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0153] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0154] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0156] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0157] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

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

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

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

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

[0162] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A workflow event execution method, characterized in that, Applied to a gateway, the method includes: Based on the running instance identifier of the target workflow instance, a status query request is sent to the external persistent workflow backend, and a target status snapshot of the target workflow instance is obtained. The target status snapshot includes the current workflow status, event set, and input port set. The event set is filtered based on the preset output event records to obtain a filtered event set. Based on the comparison result between the current workflow state and the historical workflow state and the filtered event set, a target event stream is obtained, and then the target event stream is output to the client. When the current workflow state is in the waiting input state, the set of ports to be input is output to the client; The system receives an external response request from the client for the set of ports to be input, and forwards the external response request containing the target port identifier to the persistent workflow backend, so as to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier.

2. The workflow event execution method according to claim 1, characterized in that, The process involves filtering the event set based on preset output event records to obtain a filtered event set, and then obtaining a target event flow based on the comparison result between the current workflow state and the historical workflow state and the filtered event set, including: The event corresponding to the event identifier that is not recorded in the output event record is determined from the event set to obtain the filtered event set; When the current workflow state is inconsistent with the historical workflow state, a composite state event is generated based on the current workflow state. The filtered event set and the synthesized state event are combined to obtain the target event stream; After outputting the target event stream to the client, the event identifier in the filtered event set is updated to the output event record, and the historical workflow status is updated to the current workflow status.

3. The workflow event execution method according to claim 2, characterized in that, After outputting the target event stream to the client, the method further includes: The current workflow state is matched with a preset set of terminal states to obtain a state matching result. The set of terminal states includes at least one of the following: completion state, failure state, and cancellation state. When the state matching result indicates that the current workflow state belongs to the terminal state set, and after confirming that both the filtered event set and the synthesized state event in the target event stream have been output, the process of outputting the workflow event stream to the client ends.

4. The workflow event execution method according to claim 1, characterized in that, Before sending a status query request to the external persistent workflow backend based on the running instance identifier of the target workflow instance, the method further includes: Receive a workflow start request sent by the client, the workflow start request including a target backend identifier; Based on the pre-established workflow runner mapping relationship, the workflow start request is routed and forwarded to the persistent workflow backend that matches the target backend identifier; Receive the initial running instance identifier returned by the persistent workflow backend after creating the target workflow instance, and use the initial running instance identifier as the running instance identifier.

5. The workflow event execution method according to claim 1, characterized in that, The set of input ports includes at least two different input ports. Forwarding the external response request containing the target port identifier to the persistent workflow backend, to instruct the persistent workflow backend to resume execution of the node corresponding to the target port identifier, includes: The external response request is forwarded to the persistent workflow backend to instruct the persistent workflow backend to resume the execution of the target waiting node corresponding to the target port identifier when the target workflow instance is in the waiting input state and the target port identifier is successfully matched, and to keep the nodes corresponding to other unresponsive waiting input ports in the waiting state.

6. The workflow event execution method according to claim 1, characterized in that, The process of sending a status query request to the external persistent workflow backend based on the running instance identifier of the target workflow instance includes: Retrieve the pre-configured polling interval parameter; Based on the polling interval parameter, the status query request carrying the running instance identifier is periodically sent to the persistent workflow backend until the obtained current workflow status is one of the terminal status sets.

7. The workflow event execution method according to claim 1, characterized in that, The target state snapshot and the external response request include a variable service payload, which adopts a structured data format; the method further includes: Upon receiving the target state snapshot and the external response request, the fixed shell fields in the target state snapshot and the external response request are parsed and routed, and the original structured data format of the variable service payload is maintained during transmission; wherein, the fixed shell fields include the running instance identifier, the current workflow status, the event identifier, and the target port identifier.

8. A workflow event execution device, characterized in that, Applied to a gateway, the device includes: The first request sending module is used to send a status query request to an external persistent workflow backend based on the running instance identifier of the target workflow instance, and to obtain a target status snapshot of the target workflow instance, wherein the target status snapshot includes the current workflow status, event set, and input port set. The event stream sending module is used to filter the event set based on preset output event records to obtain a filtered event set, and to obtain a target event stream based on the comparison result of the current workflow state and the historical workflow state and the filtered event set, and then output the target event stream to the client. The input port sending module is used to output the set of ports to be input to the client when the current workflow state is a waiting input state; The second request sending module is used to receive the external response request sent by the client for the set of ports to be input, and forward the external response request containing the target port identifier to the persistent workflow backend, so as to instruct the persistent workflow backend to resume the execution of the node corresponding to the target port identifier.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the workflow event execution method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the workflow event execution method according to any one of claims 1 to 7.

Images