Intelligent agent arrangement system and method based on graph structure and responsive programming technology

Abstract

The invention belongs to the technical field of artificial intelligence middleware and cloud computing task arrangement, and discloses an agent arrangement system and method based on a graph structure and a response type programming technology. Comprising a graph structure construction and compiling unit, a node operation unit, a routing and confluence control unit, a graph signal and event management unit and a response type operation and execution regulation and control unit, and an execution path has integrity and verifiability before deployment through analysis of a service graph, topology verification and confluence supplementation of parallel branches; the nodes trigger execution according to graph signals and write products into a result data area or a shared data area, and the routing and confluence control determines a convergence mode of signal transmission and parallel branches according to a connection predicate and a confluence rule. The event management unit generates a structured event for a node operation state, and the operation regulation and control unit schedules through a leading edge queue and in-transit counting and feeds back a back pressure signal to the upstream when a load changes, so that stable propulsion of a graph structure is realized.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence middleware and cloud computing task orchestration technology, specifically an intelligent agent orchestration system and method based on graph structure and reactive programming technology. Background Technology

[0002] Existing software platforms supporting the operation of intelligent applications typically use nodes and directed connections to construct graph orchestration links, control execution paths through routing conditions, and support parallel branches in some scenarios to complete tasks such as model invocation, tool invocation, retrieval processing, and result feedback.

[0003] Existing graph orchestration systems mostly rely on runtime scheduling to drive the execution of each node, paying insufficient attention to compile-time topology verification, inter-node dependency review, and parallel branch convergence processing. When the graph structure is complex, isolated nodes, unreachable paths, or parallel branches lacking clear merging relationships often only become apparent during runtime, affecting the stability and predictability of the execution chain.

[0004] Meanwhile, in existing systems, node inputs and outputs, shared data, and operating status are usually managed separately by each node, and there is a lack of unified organization for event recording methods and traceability information. In high-concurrency or multi-branch scenarios, changes in downstream processing capabilities are difficult to effectively feed back to the upstream along the graph structure, resulting in weak rhythm control capabilities between nodes, and the aggregation method of parallel branches is also difficult to adapt to the convergence requirements of different business scenarios. Summary of the Invention

[0005] The purpose of this invention is to provide an intelligent agent orchestration system and method based on graph structure and reactive programming technology to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: an intelligent agent orchestration system based on graph structure and reactive programming technology. This system uses a business execution graph (ReactiveGraph) as a unified carrier and is divided into five main functional units: a graph structure construction and compilation unit, a node operation unit, a routing and merging control unit, a graph signal and event management unit, and a reactive operation and execution control unit. The graph structure construction and compilation unit is responsible for parsing the business graph definition submitted by the user through a declarative document or visual interface into a structured set of nodes, a set of connections, and node metadata. During compilation, it performs topology integrity verification on the parsed results. This verification includes reachability analysis based on the entry node, input / output contract consistency checks, and static reachability judgment of routing predicates. Nodes and connections determined to be isolated or not participating in path execution are removed from the topology by this unit, and the reasons for removal are recorded in the compilation log for auditing or feedback. For the verified topology, this unit further identifies the set of parallel branches: if no merging node is explicitly configured for the parallel branch in the external definition, this unit inserts a merging node (JoinBarrier) at the candidate merging position and writes a merging node for that merging node. The merging rule metadata (such as enumerated merging strategies or window parameters based on trigger number / time window) is used to solidify the convergence semantics of parallel branches. After completing topology verification and merging completion, this unit merges the execution operators within the path or merging domain—including node execution logic, routing judgment logic on connections, event logic triggered by node execution status, and scheduling logic for the advancement graph execution—into several schedulable execution units (ExecutionUnits) according to predetermined rules. The execution units, along with related node / connection descriptions, merging lists, and signal / event field definitions, are encapsulated into executable graph artifacts (GraphArtifacts) for runtime loading and versioning management. The above compile-time behavior ensures the consistency of runtime semantics and provides clear execution boundaries for runtime scheduling. The node execution unit provides an execution entry point and local data management for each agent node in the business execution graph during runtime. Each node execution unit is configured with three types of logically partitioned storage areas during runtime: the ResultBucket, which stores the structured products of the node execution for downstream consumption or as the final output; the SharedBucket, which stores context or intermediate products declared to be readable across nodes; and the MetadataBucket, which records information required for scheduling and auditing, such as execution identifiers, traceability information, retry counts, timestamps, and status codes. During runtime, when a node receives a graph signal from upstream and parses its payload, the node's execution unit triggers the corresponding agent logic according to the node definition or input contract, writes the structured results generated by the execution into the result data area or shared data area, and records the execution identifier and traceability information in the metadata area; at the same time, it constructs a successor graph signal for downstream and submits it to the runtime scheduling queue to advance graph execution. To support fault recovery and idempotency of repeated execution, the node's execution unit retains idempotency keys, checkpoint identifiers and execution history in the metadata area so that retry, replay or compensation strategies can be executed according to the configuration when an anomaly occurs. The routing and merging control unit, during runtime, determines the downstream assignment of each received graph signal based on the routing predicates fixed at compile time. The evaluation of the routing predicates uses the payload field in the graph signal and necessary metadata as input. When multiple upstream graph signals arrive at the same target node, the merging control unit aggregates the payloads from each upstream according to the merging rules configured at the target node. The merging rules can adopt an all-arrival, any-priority, or window strategy based on trigger number / time window. During merging, the aggregation result is assembled into a complete input according to the input contract of the target node and then passed to the target node for processing. In the case of missing branches or timeouts in the definition, the merging control unit can apply default values, compensation logic, or record the missing and continue strategies according to the missing handling configuration of the merging node, and write the relevant decisions into the event for auditing. The graph signal and event management unit defines the graph signal format transmitted along the edge and solidifies the runtime parsing semantics in the compiled artifact. The graph signal includes at least an identifier field (such as traceId, vertexId, edgeId, timestamp, retry round) and a service payload field for tracing and routing. Key state changes of node execution (such as start, success, failure, retry, timeout, degradation, and backpressure trigger) are generated into structured events by this unit. The structured events carry the necessary tracing identifier and the corresponding data area reference or summary (used to locate records in ResultBucket / MetadataBucket) and are submitted to the event stream asynchronously. The event stream serves as a unified observation and audit entry point and can be subscribed to by the built-in monitoring module or external persistent components to support runtime alarms, log archiving, and audit link reconstruction. The event writing and forwarding strategy is configurable to adapt to the reliability and latency requirements of different deployment environments. The Responsive Runtime and Execution Control Unit is responsible for runtime scheduling, flow control, and situational awareness. This unit maintains a FrontierQueue for managing currently ready vertices or executable units and an In-flightCounter for recording the number of tasks in transit. The In-flightCounter supports granular statistics based on graph paths or namespace dimensions for fine-grained flow control decisions. During runtime, it continuously monitors downstream processing capabilities (e.g., queue length, processing latency, and concurrency) and the status of the In-flightCount. When the decision condition meets the pre-configured backpressure trigger standard (this standard is a configurable parameter and can be deployed...), it will trigger the response. When configured at the workpiece level, this unit generates and propagates a backpressure signal carrying contextual information along the upstream direction of the affected path. The backpressure signal includes at least the congestion level, the affected path identifier, and a timestamp. After receiving the backpressure signal, the upstream node can adjust the signal transmission rhythm according to its own operating parameters and strategies (e.g., reduce concurrency, reduce prefetching, or extend the backoff interval), enable temporary discardable buffers, or trigger predefined degradation / circuit break logic, thereby achieving local congestion mitigation and protecting the overall system SLA at the link level. The aforementioned backpressure judgment threshold, propagation strategy, and upstream response strategy are all configurable items to balance throughput and stability in different business scenarios.

[0007] Furthermore, the graph structure construction and compilation unit is used for: This unit is used to transform user business definitions into graphical artifacts that can be loaded and executed at runtime, and to perform necessary static verification and completion of the graphical structure during compilation; specifically, this unit includes the following functional flow: Declaration parsing and construction: Receives a declarative or visual business graph definition, parses it and generates a set of nodes, a set of connections and node metadata. The node metadata includes, but is not limited to, node identifier, node type, input or output contract and configuration items. The parsing result serves as input data for subsequent verification and compilation. Topology verification and pruning: Based on the node and connection information obtained from parsing, the topology integrity of the business execution graph is verified, isolated nodes, contract mismatches or logically unreachable connections are identified and marked, and nodes or connections that are determined not to participate in path execution are removed, while the reasons for removal are recorded for auditing or modification prompts. Parallel branch identification and merging deployment: After topology verification, the graph structure is traversed to identify the set of branches that can be executed in parallel; for parallel branches that do not have explicitly configured merging points externally, merging nodes (JoinBarrier) are automatically inserted at candidate positions, and metadata of merging rules (such as all arrivals, any priority, or window strategy based on trigger number / time window) are attached to the merging nodes to ensure that the convergence point of the parallel branch has a well-defined semantic. Operator fusion and execution unit generation: Taking the verified and completed nodes, connections, and metadata of the merging nodes as input, the node execution logic, the routing judgment logic on the connection, the event logic triggered by the node execution state, and the scheduling logic of the advancing graph execution are combined into several schedulable execution units according to the directed path or merging domain of the graph; the execution unit is represented by a serializable data structure, including the execution unit identifier, the operator sequence constituting the unit, the identifier of the associated node or edge, and the necessary runtime field definitions; Executable graph artifact output: The above set of execution units, along with node or connection descriptions, merging lists, and graph signal field definitions, are encapsulated into an executable graph artifact, which is output as the compilation result for runtime loading, versioning, and deployment; The above design maintains a clear division of labor among the functional components: the output is used for verification, verification and pruning ensure topological consistency, merging deployment ensures parallel convergence semantics, operator fusion solidifies the execution logic into running units, and the workpiece output is responsible for runtime docking. By performing topology verification and merging completion during compilation, runtime anomalies caused by topology errors or missing merging semantics can be reduced. By merging multiple types of execution-related operators into schedulable execution units and producing standardized executable artifacts, it is beneficial to unify runtime scheduling boundaries and deployment processes, and to improve runtime observability and consistency.

[0008] Furthermore, the node execution unit provides the runtime execution entry point and local data management for each intelligent agent node in the business execution graph. Each node has three logically distinct storage areas during runtime: ResultBucket, SharedBucket, and MetadataBucket. The ResultBucket stores the processing results generated by a single execution of the node in a structured format; the SharedBucket stores context or intermediate products declared to be readable across nodes; and the MetadataBucket records identification and status information related to execution tracing and scheduling. In the execution flow, when a node receives a graph signal from upstream that contains an execution payload, the node execution unit first parses the payload and triggers the corresponding execution logic according to the node's input contract to generate a processing result. Subsequently, the node execution unit writes the processing result into the result data area or shared data area according to its declared purpose, and writes the execution identifier, timestamp, and necessary traceability information into the metadata area. At the same time, the node execution unit constructs subsequent graph signals and hands them over to the routing and merging control unit or runtime queue to advance downstream execution. The node execution unit also maintains data and event collaboration with the graph structure construction and compilation unit, the routing and merging control unit, and the graph signal and event management unit to ensure that the contracts defined during compilation are adhered to during runtime and are easy to audit and trace. Clearly defining the data partitioning and execution entry points at the node level is beneficial for achieving clear semantic division of data between nodes during runtime, ensuring traceability and auditability of the execution process, and providing usable runtime basis for routing decisions, merging and aggregation, and fault location.

[0009] Furthermore, the routing and merging control unit: This unit is used at runtime to directionally dispatch graph signals based on the connection semantics fixed at compile time and complete input aggregation at the merging point. Specifically, it includes the following responsibilities and operational logic: Routing determination: For each signal received at runtime, the routing determination module evaluates the fields carried by the signal and the predefined routing predicates fixed at compile time to determine the set of downstream edges to be scheduled. The routing predicates are fixed together with the graph's metadata during the compilation stage to ensure the consistency and traceability of the routing decisions at runtime. Merging and Aggregation: When two or more graph signals from different upstream edges arrive at the same target node, the merging management module aggregates the loads from each upstream according to the merging rules configured at the target node to form the complete input of the target node. The merging rules are limited in an enumerated manner to one of the following: all arrivals, any priority, or a window based on the number of triggers or a time window. The rules are written into the target node's metadata at compile time or configuration time for runtime use. Missing Branches and Window Handling: When a window strategy is adopted or not all branches to be collected have arrived, the merging management module takes a predefined action according to the missing branch handling strategy configured for the target node (using the default value, filling according to the compensation rule, or recording the missing branches and continuing processing); window parameters (trigger number or time window) and missing branch handling strategy are configurable items; Delivery and coordination of aggregation results: After the merging is completed, the merging management module encapsulates the aggregation result into the payload of the subsequent graph signal and delivers it to the target node through the routing unit or runtime queue; during the aggregation and routing decision process, relevant decision information and metadata are recorded and reported asynchronously through the event management unit for observation and auditing; Placing routing decisions and merging aggregation in a dedicated unit and fixing routing predicates and merging metadata at compile time ensures that the routing semantics and merging semantics at runtime remain consistent with those at design time, facilitating deterministic input assembly, error traceability, and audit support under complex parallel paths.

[0010] Furthermore, the Graph Signal and Event Management Unit: This unit is responsible for defining the graph signal format transmitted along the connections in the business execution graph and generating structured events when key state changes occur during node execution. These events are used for runtime tracing and observation. Its specific functions and operating logic are as follows: Graph signal format definition and maintenance: During compilation or deployment, define and solidify a set of graph signal fields for transmission on edges. These fields include at least an identifier for tracing and routing and a payload pointer. This signal format is delivered to runtime along with the executable graph artifact to ensure consistent parsing semantics between producers and consumers. Structured event generation: When a node undergoes state changes such as execution start, execution end, retry, exception, or degradation, this unit constructs a structured event according to the pre-agreed event semantics. The event includes at least the event type identifier, source graph signal identifier (traceId), involved vertex identifier (vertexId), involved edge identifier (edgeId), event timestamp, event sequence number, and minimum traceability information such as payload pointer or summary for locating node artifacts or metadata. Asynchronous publishing and consumption: The structured events are submitted to the event stream or message channel in an asynchronous, non-blocking manner for consumption or archiving by downstream subscribers, monitoring or alarm systems or persistent components; The event management unit collaborates with the node operation unit, routing and merging control unit, and observation or auditing modules: the tracing and referencing information recorded in the event is used to associate the runtime state with node data (such as ResultBucket / MetadataBucket), thereby supporting audit link reconstruction, fault location, and runtime status analysis; event generation should not block the normal transmission of graph signals; The field set, retention policy, and event level (such as normal events and alarm events) of an event can be configured at compile time or runtime. By fixing the graph signal format at compile time and generating associative structured events at runtime, this unit provides a unified data semantics and interface for tracing the execution path, diagnosing anomalies, and auditing the runtime state, which facilitates traceable data association and subsequent analysis in complex concurrency and branching scenarios.

[0011] Furthermore, the responsive operation and execution control unit: This unit is responsible for runtime scheduling management and flow control assurance, specifically including functions such as front-end queue management, in-transit task statistics, downstream capacity monitoring, and backpressure propagation, to maintain the orderly advancement of graph signals in the business execution graph. Its main functions and workflow are as follows: Frontier queue and in-flight counter: The runtime maintains a frontier queue for managing all ready vertices and maintains an in-flight counter for the execution path or namespace dimension in the graph; the in-flight counter is an atomic counter used to accurately count the number of tasks currently in progress, thereby providing real-time quantitative basis for flow control judgment; Capacity monitoring and judgment conditions: During runtime, the downstream processing capacity is continuously monitored. The collected indicators include, but are not limited to, downstream queue length, processing latency or throughput. Preset thresholds are used as judgment conditions to determine whether to trigger the back pressure mechanism. The type and specific value of the threshold indicators are configurable. Backpressure generation and upstream transmission: When the judgment condition is met (e.g., a decrease in downstream carrying capacity is detected or the in-transit execution counter exceeds a preset threshold), this unit generates and transmits a backpressure signal along the upstream path of the service execution graph; the backpressure signal carries the necessary context information to identify the affected path and the degree of congestion, and example fields include congestion level, affected path identifier and timestamp; Upstream response strategy: After receiving the backpressure signal, the upstream node takes corresponding actions according to the node configuration, such as adjusting the signal transmission rate according to the configuration, enabling or expanding the temporary drop-able buffer, or triggering degradation or circuit breaker strategies; the specific rate control or drop-able strategy is determined by the node's operating parameters and an example implementation is given in the embodiment; Event logging and collaboration: Key decisions and state changes during backpressure triggering and response will be generated as structured events and asynchronously logged by the event management unit for observation, auditing, and subsequent analysis. This unit works in collaboration with the aforementioned graph structure construction and compilation unit, routing and merging control unit, and node execution unit to ensure that the runtime flow control strategy is semantically consistent with the design time. In a highly parallel and asynchronous graphical orchestration environment, explicit in-transit statistics and threshold-based backpressure mechanisms can achieve early detection and local mitigation of local congestion during runtime, thereby helping to maintain the stability and controllability of overall execution. The judgment threshold and backpressure context parameters are configurable items, which can be traded off and optimized in different business scenarios.

[0012] This invention also provides an intelligent agent orchestration method based on graph structure and reactive programming technology. This method is based on the aforementioned system and includes the following main steps that work sequentially and collaboratively: Graph Construction and Compilation: Receives business graph definitions provided by users through declarative definitions or visual orchestrators, parses and generates node tables, connection tables, and node metadata; performs topology integrity verification on the business execution graph based on the parsing results, identifying and eliminating isolated nodes, connections with contract mismatches, or connections that are logically not involved in path execution; after topology verification, traverses the graph structure to identify sets of branches that can be executed in parallel; for sets of parallel branches without explicitly configured merging points, inserts merging nodes at candidate positions and attaches merging rule metadata to them; using the verified and completed merging nodes and connections, along with their metadata, as input, merges node execution logic, connection routing judgment logic, event triggering logic, and scheduling logic for advancing graph execution into schedulable execution units according to predetermined rules, and encapsulates these execution units into standardized executable graph artifacts for runtime loading and deployment; Execution environment initialization: Deploy the executable graph artifact to the runtime environment; create or allocate result data area, shared data area and metadata area for each node in the business execution graph at runtime, and initialize the front queue for managing ready vertices and the in-transit execution counter for counting the number of tasks in transit; configure backpressure determination parameters and monitoring items at runtime. The above initialization steps enable the runtime to obtain the graph's structural information, node data area and flow control parameters so that the semantics and runtime metrics fixed at compile time can be used for coordinated scheduling in the subsequent execution phase. Graph signal-driven execution: The initial graph signal is generated by the entry node and transmitted hop-by-hop along the graph connections; each node parses the payload after receiving the graph signal and triggers the corresponding execution logic according to the node's input contract. The execution result is written to the result data area or shared data area according to the declaration, and the subsequent graph signal is constructed and promoted downstream; when multiple parallel branches converge to the same merging node, the upstream graph signal payload is aggregated to form a complete input according to the merging rules preset at the merging node (e.g., all arrive, any priority, or window strategy based on trigger number / time window); during execution, the downstream processing capacity and in-transit counter are continuously monitored. When the judgment condition meets the backpressure triggering standard, the backpressure signal carrying context information such as path identifier and congestion level is transmitted along the upstream path of the graph. The upstream node adjusts the graph signal transmission strategy or enables temporary discardable buffers accordingly; all key decision points, merging and abnormal events are generated as structured events by the event management unit and recorded asynchronously in the event stream for observation and auditing.

[0013] Furthermore, the process of converting declarative or visual business graph definitions into standardized graph artifacts for runtime loading and execution, and performing static verification and necessary completion of the graph structure during compilation, includes the following sub-steps: Declaration parsing: Receives a declarative or visual business graph definition, parses it to generate a node table, a connection table, and node metadata. The node metadata includes at least the node identifier, node type, and input or output contract. The parsing result serves as the structured input for subsequent verification and compilation. Topology verification and pruning: Based on the node table and connection table, perform topology integrity verification on the business execution graph, identify and mark isolated nodes, contract mismatches, or logically unreachable connections; remove nodes or connections that are determined not to participate in path execution and record the reasons for removal for auditing or feedback modification. Parallel branch identification and merging deployment: After topology verification, the graph structure is traversed to identify the set of branches that can be executed in parallel; for the set of parallel branches for which merging points are not explicitly configured externally, merging nodes are inserted at candidate positions and merging rule metadata (such as all arrivals, any priority, or window strategy based on trigger number / time window) is attached to them to clarify the convergence semantics of parallel branches. Execution unit generation: Taking the verified and completed nodes, connections and their metadata as input, the node execution logic, connection routing judgment logic, event triggering logic and scheduling advancement logic are combined into several schedulable execution units according to the directed path or merging domain; the execution unit is represented by a serializable data structure, which includes runtime necessary fields such as execution unit identifier, constituent operator sequence and associated node / edge identifier; Executable graph artifact generation: The above set of execution units, along with node / connection descriptions, merging lists, and graph signal field definitions, are encapsulated into an executable graph artifact, which is then used as the compilation output for runtime loading, versioning, and deployment.

[0014] Furthermore, execution environment initialization: This is used to deploy the executable graph artifacts generated during compilation to the runtime and establish the necessary runtime data structures and flow control parameters for subsequent execution, including the following sub-items: Artifact Deployment: The executable graph artifact is loaded and deployed in the target runtime environment. At runtime, the node, connection, merging and graph signal field definitions in the artifact are read to construct the runtime semantic model. Node data area initialization: Create or allocate three logically distinct data areas for each node in the business execution graph at runtime: ResultBucket for storing the results of a single execution, SharedBucket for sharing across nodes, and MetadataBucket for recording traceability and runtime status. The existence of the above data areas and their initial quotas, access permissions, and other configurations are issued along with the artifacts or runtime configurations. Queue and counter establishment: Initialize the frontier queue for managing the set of ready vertices; and initialize the in-flight counter for recording the number of tasks in transit. The in-flight counter is an atomic counting structure and can be counted separately according to the graph path or namespace dimension to support granular flow control judgment. Back pressure parameter configuration: Configure back pressure determination parameters for runtime. The back pressure parameters include at least a set of thresholds for determining back pressure triggering and back pressure propagation rules (e.g., the signal format and included context fields transmitted along the upstream path). The thresholds and propagation rules are configurable items and can be adjusted according to the workpiece version or runtime strategy. Collaborative pointing and audit association: During the initialization process, the above data areas, queues, counters and back pressure parameters should be associated with the routing and merging metadata embedded in the drawing workpiece so that they can be executed according to compile-time semantics at runtime; at the same time, the initialization actions and initial mapping relationships should be recorded in the audit log for subsequent traceability and diagnosis.

[0015] Furthermore, this section describes the runtime-based graph signal-based advancement and cooperative processing flow, serving as a runtime implementation of compile-time semantics and runtime resources. This execution process includes the following key points: Signal generation and hop-by-hop transmission: The entry node generates an initial graph signal (including load and traceability identifier) ​​based on the access request or triggering condition. The initial graph signal is transmitted hop-by-hop to the downstream node along the connection of the service execution graph. During runtime, the enqueueing and dequeueing of signals are processed according to the connection and routing semantics fixed in the graph workpiece. Node reception and execution: After receiving the graph signal, each node parses the payload and triggers the corresponding execution logic according to the node's input contract. The node stores the structured processing results generated by the execution into the node's data management structure (e.g., result data area or shared data area) according to the declaration, and constructs subsequent graph signals to drive downstream nodes to continue execution; necessary metadata during node execution is written to the metadata area for traceability and scheduling. When graph signals from multiple upstream edges arrive at the same target node, the loads of the multiple upstream graph signals are aggregated according to the merging rules pre-configured at the target node to form the complete input of the target node. The merging rules can adopt enumerated semantics (e.g., all arrivals, any priority, or window strategy based on trigger number / time window). The missing branch handling strategy and window parameters of the merging can be configured at compile time or runtime. Runtime monitoring and back pressure: The runtime continuously monitors downstream processing capacity and in-transit execution counts, etc. When the judgment condition (determined by configurable thresholds and rules) is met, the runtime generates and transmits a back pressure signal carrying context information along the upstream path of the graph structure. The upstream node adjusts its graph signal transmission strategy or enables temporary discardable buffers or other rate limiting measures based on the received back pressure information. The back pressure signal and judgment threshold are configurable items, and their specific format and propagation rules are shown in the embodiments. Event logging and collaboration: Key decisions, collaborative behaviors, backpressure triggers, and abnormal events during the execution process are generated into structured events by the event management unit and written to the event stream asynchronously. The event and the metadata in the node data area are linked to facilitate subsequent auditing, fault location, and operational status analysis.

[0016] The beneficial effects of this invention are as follows: 1. This invention performs static verification of node sets, connection relationships, and metadata during the graph structure compilation phase, and preprocesses isolated nodes, connections not involved in the execution path, and parallel branches with unclear convergence relationships. This ensures that the business execution graph is structurally complete and has clearly defined path relationships before it is put into operation. For cases where no merging point is configured in a parallel path segment, the system automatically fills in the merging node and solidifies the corresponding convergence conditions into the graph artifact. This ensures that the multi-branch task link has clear convergence criteria before operation, reducing operational anomalies caused by missing paths, unclear convergence relationships, or incomplete parallel structure configuration. At the same time, the node execution logic, routing judgment logic, event triggering logic, and scheduling advancement logic are unified in the compilation phase, making the execution link more coherent during runtime and improving the operational stability of the graph structure orchestration software platform in complex task scenarios.

[0017] 2. This invention configures result data area, shared data area, and metadata area for each intelligent agent node, enabling node execution results, cross-node shared information, and runtime records to have a unified data carrying structure. After receiving the graph signal, the node triggers execution according to the input contract and generates a successor graph signal with a consistent structure, thereby making the data transmission relationship, sharing relationship, and state association relationship between multiple nodes clearer. When multiple upstream branches converge to the same target node, the system performs load aggregation according to the target node's preset merging rules, making the convergence timing and combination method of parallel branches have a clear basis. Through a unified routing decision mechanism, the flow judgment of the compilation stage and the runtime stage are kept consistent, thereby improving the data organization consistency and path advancement controllability when multiple branches and multiple types of intelligent agents are executed collaboratively, which is conducive to enhancing the software collaboration capability of the intelligent application operation support platform.

[0018] 3. This invention defines the data structure of graph signals in a unified manner, enabling load transfer, routing judgment, and link tracing to be based on a unified format, thereby maintaining the continuity of path associations between nodes. The system generates structured events in node start, end, retry, and exception states, and writes them to the event stream asynchronously, allowing runtime observation, process auditing, and execution replay to be performed synchronously without interfering with the main link's progress. At the same time, the system monitors the overall load of the graph structure through the leading edge queue and in-transit execution count, and feeds back pressure signals to the upstream when the downstream processing capacity decreases or the in-transit count reaches a threshold. This allows upstream nodes to adjust their signal transmission strategies or enable buffer control in a timely manner, thereby suppressing the spread of local congestion to the global level and improving the system's throughput coordination capability and operational stability in high-concurrency, multi-branch task scenarios. It is more suitable for deployment as an intelligent agent orchestration middleware or a graph structure task orchestration and execution platform. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the diagram construction and compilation process of this invention; Figure 2 This is a flowchart illustrating the execution process of this invention. Figure 3 This is a flowchart of the back pressure and event management process of the present invention. Detailed Implementation

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

[0021] like Figures 1 to 3 As shown, this embodiment of the invention provides an intelligent agent orchestration system based on graph structure and reactive programming technology, including the following interdependent units that cooperate around a graph structure: The graph structure construction and compilation unit is used to generate a business execution graph containing multiple intelligent agent nodes and directional connections between nodes according to the business definition, and to perform topology verification on the business execution graph to identify and delete isolated nodes and connections that do not participate in path execution. In the identified parallel branches, if no merging node is explicitly configured externally, a merging node is automatically inserted. The verified and completed nodes and connections and their metadata are taken as input, and the node execution logic, connection routing judgment logic, event triggering logic, and scheduling logic for advancing graph execution are merged into a schedulable execution unit and output as an executable graph artifact, which is used for runtime loading. The node operation unit is used to provide a data management structure and execution entry point for each intelligent agent node in the business execution graph. The data management structure includes a result data area, a shared data area, and a metadata area. When a node receives a graph signal from upstream, the node operation unit calls the corresponding intelligent agent logic according to the payload in the graph signal and generates a subsequent graph signal. The generated structured result is written into the result data area or the shared data area, and the execution identifier and traceability information are written into the metadata area. The routing and merging control unit is used to determine the downstream path of the graph signal based on the routing predicate on the connection relationship, and when multiple upstream graph signals arrive at the same target node, it aggregates the loads of multiple upstream graph signals according to the merging rules of the target node to form the complete input of the target node; The graph signal and event management unit is used to define and maintain the graph signal format flowing on the edges and generate structured events when events such as the start, end, retry, exception and degradation of node execution occur, and write the events to the event stream in an asynchronous manner. The responsive operation and execution control unit is used to maintain the leading queue and the in-transit execution count. When it detects a decrease in downstream carrying capacity or an in-transit count exceeding a preset threshold, it transmits a backpressure signal carrying context information along the upstream path of the graph structure so that the upstream node can adjust the graph signal transmission rate or enable a dropable buffer.

[0022] The business definition received by the graph structure construction and compilation unit is a structured description, including a node table, a connection table, and an ingress / exgress set. Node table: Each record must contain at least a node identifier (nodeId), a node type (nodeType), an input contract (inputContract), an output contract (outputContract), and a runtime configuration (config, indicating the required field names); among which the input contract and output contract are used to describe the structural definition of field names and data types or references; Link table: Each record contains at least a link identifier (edgeId), source node (src), destination node (dst), route predicate (routePredicate), and optional link metadata (metadata). The route predicate can be distinguished into two categories: statically determined at compile time and evaluated at runtime. Entry / exit set: used to define the starting point of accessibility and business boundaries; After parsing, the compilation unit performs static verification on the topology and records all changes in the compilation log. Reachability verification: Starting from the ingress set, a directed reachability analysis is performed. Any node that is not reachable by the ingress is marked as an isolated node and removed from the topology. The removal operation records the removed object, the reason for the judgment, and the timestamp in the compileLog. Whether it is automatically removed or only recorded is determined by the compilation configuration, which is reflected in the artifact metadata. Contract consistency verification: Verify the field compatibility between the source node output contract and the destination node input contract for each connection. For incompatible cases, the compilation unit takes one of three actions based on the configuration: mark and remove, mark in the artifact that runtime adaptation is required, or cause compilation to fail and return an error. All actions are clearly recorded in the compileLog. Static route pruning: Prune the connections corresponding to route predicates that can be determined to be always false or always unreachable at compile time and record the reasons; retain those that cannot be statically determined and mark them in the artifact as requiring runtime evaluation; For the verified topology, the compilation unit identifies parallel branches and inserts merging nodes (JoinBarrier) when necessary. Parallel branch identification criteria: When two or more paths originating from a common upstream and not dependent on each other point to a common structure or have aggregation requirements, they are determined to be a set of parallel branches. The specification also lists the determination method based on hierarchical partitioning for implementation and review comparison. Automatic merging node insertion conditions: If the merging node is not explicitly configured at the convergence point of parallel branches and the business definition or topology shows convergence semantics, then the merging node is inserted at a candidate position near the downstream. The insertion position is based on the principle of minimal modification to the original semantics, and the insertion basis is recorded in the artifact. Merging metadata: For each inserted merging node, the merging mode (joinMode, enumerated as all / any / window), window parameter definition, missing branch handling strategy (such as using default value, compensation, or record and continue) and other necessary configuration fields are written in the artifact. The compilation unit merges consecutive operators within appropriate intervals of the topology into an ExecutionUnit according to the rules, and describes the generated results and audit information in the artifact; Merging is only allowed when the following conditions are met simultaneously: the merge interval does not contain any merging nodes or nodes requiring manual intervention; adjacent operators within the interval are contract-compatible, resource-constraint-compatible, and do not violate node-level isolation or concurrency limits; the preconditions and postconditions of the merge boundary can be verified at compile time or runtime. Boundary determination: If any prerequisite is not met, the boundary of the ExecutionUnit is set at that location and will no longer be crossed for merging; ExecutionUnit description: Each ExecutionUnit contains a unit identifier, a list of nodes, a list of connections, necessary preconditions, resource hints, and audit information for the merge decision (including the merged node, the reason for merging, and the basis for merging); Audit log: The merge decision and basis are written to the compileLog and output with the workpiece; The compilation unit encapsulates the verified and processed information into a GraphArtifact and specifies the loading and verification process at runtime; Artifact composition: Includes a verified and completed set of nodes, a set of connections, a merge list, an ExecutionUnit list, signal and event definitions, a compileLog, and artifact metadata (version number, generation time, compiler identifier, verification summary); Load verification: Before loading the artifact, the runtime should verify the artifact version compatibility, the integrity of node / connection references, and the acceptance status of key changes in the compileLog; If the verification fails, strategies such as refusing to load or prompting manual confirmation can be adopted according to the artifact metadata; Version management: The artifact contains version information to support smooth replacement or rollback, and the relevant rollback process and limitations are recorded in the artifact metadata; To ensure the controllability and recoverability of changes during runtime and compilation, the following measures are disclosed: The compile log is output with the artifact and records detailed entries for all trimming, merging, insertion, and consolidation decisions; this log serves as an auditing basis and is used to review response materials. For elements that are clipped or automatically inserted, the original definition or reference is retained in the artifact so that users can explicitly modify and recompile in subsequent versions; If incompatibility or resource bottlenecks are found during runtime due to merging, the ExecutionUnit can be split back to the original granularity for execution, provided that the runtime configuration allows, by using the operator sequence information retained in the artifact.

[0023] The runtime unit is responsible for receiving graph signals from upstream, triggering the execution logic of agents corresponding to nodes, managing local data access of nodes, and generating and distributing subsequent graph signals during operation. The runtime unit includes the following core modules: an execution entry point (for receiving and parsing graph signals), an agent adaptation / execution module (for scheduling specific logic according to node type), a local data manager (VertexStorage), and a snapshot / checkpoint support module for idempotency and recovery. VertexStorage has three types of logical storage areas, each used for different purposes, with the following names and meanings: During runtime, each node maintains the following three logical storage areas in VertexStorage: ResultBucket: This area stores the structured results produced by this node's execution (e.g., formatted business products or intermediate results for direct downstream consumption). Data in the ResultBucket is organized at the granularity of a single execution, and the data written should be readable by downstream processes within the same execution cycle or referenced by subsequent merging / routing logic. SharedBucket: Used to store context or intermediate artifacts that can be read by other nodes in the same graph. SharedBucket is suitable for scenarios where data is shared across nodes. Its consistency level can be set according to the path strategy (e.g., weak consistency or eventual consistency through event log compensation), and the visibility and lifecycle of the shared data can be marked in the artifact or node configuration. MetadataBucket: This area records information needed for tracing and scheduling. Typical fields include execution identifier (executionId or idempotent key), traceId, vertexId, current execution status code (e.g., pending execution, running, success, failure, degradation), retry count, timestamp, and reference pointers to location result data or shared data. The information in the MetadataBucket is also used by auditing, retry judgment, and recovery logic. The runtime unit provides an atomic, idempotent read / write interface (StorageAccessor) through a local data manager, and supports snapshot and checkpoint mechanisms for lossless playback or compensation during fault recovery. The following key points are explicitly stated: Write conventions: Critical write operations to ResultBucket and MetadataBucket should be performed with atomic transactions or equivalent semantics to avoid inconsistencies between metadata and artifacts caused by partial writes; writes to SharedBucket can adopt an eventual consistency strategy in conjunction with synchronization / compensation mechanisms. Idempotency: Each node execution should carry or generate a unique execution identifier (idempotency key). Write operations must be based on this idempotency key to achieve idempotent writes and avoid repeated executions that could have side effects on the outside. Checkpoints and snapshots: The running unit supports persisting critical states and necessary data as checkpoints at appropriate times, so that execution can be replayed or resumed at checkpoints after a node failure or restart; When the execution entry point of the execution unit receives a graph signal from upstream, and the graph signal contains an execution payload, the execution unit processes it according to the following steps (each item in the process has its fields and decision conditions specified in the specification): Parsing and Verification: Parse the received graph signal, extract the payload and necessary traceability fields (such as traceId, edgeId, enqueue timestamp, retry rounds), and verify the field integrity and type compatibility of the payload according to the node's input contract. If the verification fails, record the exception according to the error handling strategy configured by the node and trigger retry or degradation processing according to the configuration. Triggering execution logic: Based on the node's nodeType (e.g., types defined in the disclosure such as AiAgent, FunctionAgent, HumanAgent, BarrierAgent, etc.), the running unit invokes the corresponding agent logic: For I / O intensive tasks (such as external retrieval, network calls, and model inference), an asynchronous client call method is used, and the waiting is handed over to the runtime non-blocking scheduler. For CPU-intensive tasks (such as complex aggregation and scoring calculation), they should be executed synchronously or asynchronously in a controlled computing pool, adhering to concurrency limits, timeouts, and backoff strategies. During node execution, the idempotency key and execution context of this execution should be maintained so that the idempotency key can be used to determine whether the action is repeated during retries or replays. Product writing: After execution, the structured output products are written to the ResultBucket (if the product is only for internal downstream use and needs to be shared across nodes, it is written to the SharedBucket at the same time or instead); if necessary, the product is serialized or digested before writing to reduce storage and transmission overhead. Metadata update: Record the execution identifier, start / end timestamp, execution status, traceability information that can be used for auditing, and references or summary pointers to artifacts in ResultBucket / SharedBucket in the MetadataBucket; if an exception occurs or a degradation is triggered, record the exception code and the selected handling strategy in the metadata at the same time. Successor graph signal construction and distribution: Based on the node's output contract and the graph's advancement rules, the running unit constructs the successor graph signal. The successor signal payload consists of the node's output product or specified output fields, and necessary traceability and routing metadata (such as traceId, originVertexId, retryCount, etc.) are added to the signal header. This successor graph signal serves as the input for runtime scheduling to drive the downstream nodes of the service execution graph to continue execution. Persistence and Auditing: After writing and signal sending are completed, key execution items (including the product references of ResultBucket, the execution records of MetadataBucket, and the summary of subsequent signals) will be stored. The running unit should perform exception handling according to the node running configuration and the strategy in the artifact: for recoverable exceptions, perform a limited number of retries according to the configuration and update the retry count of MetadataBucket before each retry; for exceptions that reach the retry limit or are determined to be unrecoverable, perform degradation measures according to the node configuration (such as writing the default artifact, triggering bypass logic or sending a failure signal upstream), and record relevant information in MetadataBucket and event channel for auditing purposes; The execution unit adheres to the concurrency limits and resource isolation requirements declared in the node configuration: for nodes requiring isolation, the execution unit runs in a separate execution context; for nodes that allow parallelism, concurrency control is achieved through a controlled computing pool, atomic counters, and a leading queue. For concurrency-related decisions and runtime statistics, the execution unit retains necessary metrics in the MetadataBucket or runtime monitoring module so that the responsive execution unit can perform flow control or backpressure processing.

[0024] The routing and merging control unit takes the following information as input and it is either solidified in the workpiece or referenced during runtime: Each connection in the connection table corresponds to a route predicate, which takes the payload field of the graph signal and necessary traceability / metadata fields (such as traceId, vertexId, edgeId, timestamp, retry rounds, etc.) as input; The joinMode rule configured at the target node has three possible values: at least, all (all), any (any), and window. Optional connection-level metadata (such as priority or specific route hints) and input contracts for target nodes are used to assemble the aggregation results; When a graph signal is received at runtime, the routing and merging control unit first evaluates the routing predicates for each outgoing edge set corresponding to that graph signal: For predicates that can be statically determined at compile time, the static conclusion is directly adopted based on the compilation result; for predicates that need to be evaluated at runtime, the evaluation is performed based on the real-time load and metadata. Outgoing edges that satisfy the predicate are considered candidate downstream paths; if multiple candidate paths exist, the actual downstream edge is determined according to the priority declared in the artifact or the arrival order and other configured rules; the routing determination results are recorded in the runtime log or event stream for auditing purposes. When two or more graph signals from different upstream edges arrive at the same target node, the merging control unit performs load aggregation on the upstream graph signals according to the merging rules configured at the target node, as follows: All Arrival Mode: After receiving and confirming valid graph signals from all upstream branches defined as necessary to arrive, the merging unit assembles the loads of each branch into a complete input item by item according to the input contract of the target node; if not all arrive within the preset timeout period, it processes the missing branch handling strategy of the target node (e.g., using default values, performing compensation, or recording and continuing) and records the corresponding events. Any priority mode: When a valid graph signal is issued from any upstream branch and the priority selection rule is met, the merging unit takes the load of that branch as the merging result and triggers downstream execution; the priority selection rule can be the connection priority, arrival order or other configured criteria declared in the workpiece; Window mode: When the triggering conditions configured according to the target node (such as reaching a specified number of arrivals or the time window being closed) are met, the merging unit will aggregate the upstream loads collected within the window range. The aggregation method is defined according to the input contract of the target node (such as merging arrays, merging key-value tables, or selecting according to field priority); the window triggering parameters (trigger number, window duration, and handling of late signals) are explicitly recorded in the workpiece. After the merging is triggered, the routing and merging control unit encapsulates the aggregation result into a new graph signal payload and adds necessary traceability information (at least including traceId, originVertexId, merging round or window identifier, and timestamp) to the graph signal header. The generated subsequent graph signal is transmitted to the target node according to the existing routing rules or the next-hop information specified in the workpiece to drive the execution of the target node. Decisions when aggregation fails, branches are missing, or degradation occurs are also recorded in the form of structured events and sent to the event management unit. The routing and merging control unit records and exposes the following: the evaluation results of the routing predicate, the identifier of the selected downstream edge, the merging trigger time and the list of participating branches, a summary of the merging load, and the handling measures taken due to missing or timeout. This information is used for operational observation, fault location, and explanation to the reviewer. If an incompatibility between the load and the target input contract is detected during the merging process, the merging unit should handle it according to the adaptation or degradation strategy defined in the workpiece and record the specific exception code and the handling result.

[0025] The graph signal and event management unit includes at least the following fields: traceId: A globally unique identifier used to identify a single business request or execution path; signalId: A unique identifier for this signal (can be used in conjunction with traceId to distinguish multiple signals under the same trace); originVertexId / originEdgeId: Records the vertex or edge identifier from which the signal originates; timestamp: The timestamp when the signal was generated or delivered; retryCount / round: Number of retry rounds or iterations; payload: The execution payload or artifact reference it carries (when the payload is large, the payload can be an artifact pointer or digest). routeMeta: Necessary metadata for route determination (if required), such as priority or context labels; When a node undergoes a status change such as execution start, execution end, retry, exception, cancellation, timeout, or degradation, the event management unit generates a structured event. Each structured event contains at least the following fields: eventType: Event type identifier (e.g., START, SUCCESS, FAILURE, RETRY, TIMEOUT, CANCEL, DEGRADATION, BACKPRESSURE, etc.); sourceTraceId: The traceId of the GraphSignal associated with the event; vertexId: The identifier of the vertex involved; edgeId (if applicable): The connection identifier involved; eventTimestamp: The time the event occurred; eventSeq / roundNo: Event round number or sequence number, used to distinguish events generated by repetition or retries; payloadDigestOrPointer: A digest or reference used to identify or point to the location of node artifacts or metadata (such as a reference in ResultBucket or SharedBucket). statusDetail (if applicable): A brief status description or error code (for exceptions or degradation events, the error code or degradation policy identifier should be included); minimalProvenance: necessary traceability information fragments (composed of reusable traceId, originVertexId, and relevant timestamps) to reconstruct the execution path during auditing; Events are generated at key callback points during node execution: corresponding structured events of the following types are generated at execution start, normal completion, abnormal termination, retry trigger point, timeout determination point, and degrade / rollback execution point; the event object should carry the minimum traceability information corresponding to the current GraphSignal (at least including traceId, vertexId, event timestamp, and round), and point to or summarize the associated product location (for audit association); the event is immediately handed over to the event writing channel for asynchronous processing after generation, and event generation should not block the main execution flow of the node; The payloadDigestOrPointer field in the event is used to point to the location of the artifact or metadata in the node's ResultBucket or MetadataBucket; The event management unit can record references (URIs or database identifiers) to artifacts in the ResultBucket in the event, so that the actual artifacts and related metadata can be quickly located through the event during auditing; The event stream is available for downstream subscribers to consume in real time and can also be received and archived by the persistent component to form an audit log. The events contain minimal source information when written, which is sufficient to associate the event chain with the records in the GraphArtifact, compileLog and node storage area during auditing, making it easier to reconstruct the execution path and analyze anomalies. If an unrecoverable error occurs in the event write channel (such as persistence failure or transmission error), the event management unit should compensate or alarm according to the strategy specified in the artifact (such as rewriting, writing the event to disk, or triggering an alarm); the failure of event writing should not affect the execution of the node's main process, and the corresponding write exception should be recorded in the MetadataBucket for subsequent troubleshooting.

[0026] Among them, the responsive operation and execution control unit: The control unit maintains the following runtime data structures: Frontier Queue: used to manage the set of vertices that are currently ready and can be scheduled for execution; queue items contain minimum necessary information such as vertex identifier, signal identifier, and priority / arrival time; In-flight Counter: implemented using atomic counters, used to record the number of graph signals that are currently executing or have been enqueued but not yet completed. This counter can be counted and summarized by path dimension or namespace dimension to support local and global flow control determination. The increment and decrement of the counter are atomically updated at enqueue / dequeue, execution start and execution completion to ensure consistent statistics in a concurrent environment; The control unit continuously monitors the downstream processing capacity. Commonly used monitoring indicators include, but are not limited to: downstream queue length, single-node processing latency, in-transit execution counter value, failure / retry rate, and resource utilization (such as execution pool saturation). Preset thresholds are set for the above indicators as judgment conditions. The thresholds are configurable parameters and can be set independently by path or namespace. When any judgment condition is detected to meet the preset threshold (e.g., the in-transit count exceeds the threshold or the processing latency exceeds the standard), the backpressure propagation process is triggered. When backpressure is triggered, the control unit propagates the backpressure signal along the upstream path of the service execution graph, following the reverse path of the directed connection direction of the graph (i.e., notifying level by level along the upstream edge that caused the congestion path); the minimum required fields of the backpressure signal include: Congestion Level: An enumeration or level identifier that represents the severity of congestion; AffectedPathId or pathIdentifiers: Indicates the affected path or namespace, used to make the upstream respond at the path level; Timestamp: The time the signal was generated; Upon receiving a backpressure signal, the upstream node takes configurable countermeasures based on the workpiece or node configuration, including but not limited to: adjusting the signal transmission rate: reducing the signal transmission frequency or increasing the transmission interval (throttling); enabling a discardable buffer: writing the signal to be transmitted into a small discardable buffer and discarding the least important item when the buffer overflows; switching to degradation or bypass logic: switching to a predefined degradation path or using caching / static rules to reduce downstream pressure, if the configuration allows; local degradation recording and reporting: reporting the adjustment actions taken, the current in-transit count, and the signal summary to the event stream or monitoring channel for centralized observation; preset thresholds, backpressure transmission rules, upstream response strategies, and optional fields for backpressure signals are all configurable parameters. The configuration is issued along with the executable graph workpiece or runtime deployment strategy. When triggering backpressure, propagating backpressure, and upstream response, the control unit must write key events and summaries into the event stream and runtime log for real-time observation, historical tracing, and review.

[0027] This invention also provides an intelligent agent orchestration method based on graph structure and reactive programming technology. This method, based on the aforementioned system, specifically includes the following steps: Graph Construction and Compilation: Receives a declarative or visual business graph definition, which includes at least a node table, a connection table, an ingress / exgress set, and the input / output contracts and runtime configurations of the nodes; Parse the business graph definition to generate a node list, a connection list, and node metadata; Perform static verification on the generated topology: perform ingress reachability analysis, connection contract consistency check, and compile-time decidability analysis of routing predicates; remove nodes / connections determined to be isolated or not participating in path execution from the topology and record the reason for removal in the compilation log; For the verified topology, identify the set of parallel branches; for parallel branches that do not have a clearly configured merging point and need to be merged, insert a merging node (JoinBarrier) at the candidate position and mark the merging mode (all / any / window) and missing branch handling strategy in the merging metadata; The verified and completed merge nodes and connections, along with their metadata, are used as input. Mergeable continuous operators within the topology are generated as ExecutionUnits according to predetermined rules (the merging prerequisites are explicitly defined in the artifact). The ExecutionUnit set, merging description, and compilation log are then encapsulated into an executable graph artifact (GraphArtifact) for subsequent deployment and runtime loading. Execution environment initialization: Deploy the executable graph artifact in the runtime environment (the runtime is based on a reactive streaming framework), and load the nodes, connections, ExecutionUnits and metadata in GraphArtifact by the runtime; For each node in the business execution graph, a result data area (ResultBucket), a shared data area (SharedBucket), and a metadata area (MetadataBucket) are created or allocated at runtime, and their identifiers and access interfaces are registered at runtime; Initialize the runtime structure for scheduling and flow control, including the frontier queue for managing ready vertices, the atomic in-transit execution counter for recording the number of tasks in transit (which can be counted separately by path or namespace), and the preset thresholds and parameters (thresholds, backpressure propagation rules) for backpressure determination. Initialize checkpoint / snapshot mechanisms, event flow channels, and observation / audit access points as needed; Graph signal-driven execution: The ingress node generates an initial graph signal (GraphSignal), which contains at least traceId, signalId, payload, and necessary routing metadata, and is passed hop-by-hop along the connection; When a node receives a graph signal and the payload satisfies its input contract, the node execution unit: parses the payload, verifies the idempotent key, triggers the corresponding agent logic (AiAgent, FunctionAgent, HumanAgent or BarrierAgent) according to the node type, and writes the structured result to ResultBucket or SharedBucket after execution, and writes the execution identifier, status and traceability information to MetadataBucket. The node generates or sends a successor graph signal based on the routing predicate and merging rules; when multiple upstream branches return to the same merging node, the upstream loads are aggregated according to the merging rules (all / any / window) configured at the merging node to form the complete input of the target node, and then the downstream execution is triggered. All critical execution events (start, success, failure, retry, degradation, backpressure trigger, etc.) are generated into structured events by the graph signal and event management unit and written to the event stream asynchronously for use by the monitoring, auditing and persistence components.

[0028] Graph construction and compilation include: After receiving a declarative or visual business graph definition, the compilation unit parses the definition into a node table, a join table, and node metadata. The parsing should explicitly record at least the following: A node entry must include at least the following runtime configuration items: nodeId, nodeType, input / output contract, concurrency / timeout / retry; Link entries must include at least edgeId, src, dst, and routePredicate; routePredicate should be marked as such to indicate whether it can be statically determined at compile time; Inlet / outlet sets and global configurations (e.g., default merging strategy, global timeout threshold); The parsing results serve as direct input for subsequent topology verification, merging determination, and ExecutionUnit generation, and are written to the initial compilation log (compileLog). Based on the node table and the join table, the compilation unit performs topology integrity checks on the business execution graph and processes it according to the following rules: Entry point reachability analysis: A directed reachability traversal is performed starting from the entry point set; nodes that are not reachable from the entry point and their related connections are determined as isolated nodes / connections, and are automatically removed or only warned according to the compilation configuration; the removal operation and the reason for the determination are recorded in the compileLog; Contract consistency verification: For each connection, the output contract of the source node is compared with the input contract of the target node to check whether the fields are compatible. If incompatible fields are found, they are processed according to the rules pre-defined in the artifact. The processing methods may include: marking the connection as invalid and deleting it; indicating in the artifact that adaptation needs to be performed at runtime; or terminating the compilation and returning an error message when the contract requirements cannot be met. All verification and processing results are recorded in the artifact and output along with the artifact. Static route pruning: Prunes and records connections that can be determined to be always false or always unreachable at compile time using routePredicate; retains predicates that need to be evaluated at runtime and marks them as runtime-eval in the artifact; For the verified topology, the compilation unit identifies parallel branches and inserts merging nodes as necessary, specifically including: Parallel branch identification criteria: When two or more paths branching off from the same upstream and do not depend on each other in sequence, and their final destinations have a convergence requirement, they are identified as a set of parallel branches; in practice, a hierarchical partitioning-based identification method can also be used. Automatic merge insertion conditions: If a merge node is not explicitly configured at the convergence point of parallel branches and the business semantics or topology require load aggregation, the compilation unit will insert a JoinBarrier at a candidate position near the downstream. The insertion principle is to minimize changes to maintain the original semantics. Merging metadata record: For each inserted merging node, write joinMode (values ​​include all, any, window), window parameter (if applicable), missing branch handling strategy (e.g., using default value or triggering compensation) and timeout setting into the artifact so that the merging semantics can be executed accurately at runtime; Insert record: The basis for the merge insertion, the candidate position and the final position, and the audit information are written to the compileLog; The compilation unit merges consecutive operators within appropriate intervals of the topology into an ExecutionUnit according to predetermined rules, as follows: Merge prerequisites: Merges are permitted only if the following conditions are met simultaneously; The merged interval does not contain any merging nodes or nodes requiring manual intervention; Within the merge interval, the input and output contracts of adjacent operators must be compatible; if there are fields that cannot be directly matched, they must be handled by the adaptation rules declared in the artifact to ensure that the path can still be executed at runtime. The merge does not violate any node's declared concurrency limits or isolation requirements in its configuration; The preconditions and postconditions of the merge boundary can be verified at compile time or runtime. Boundary determination: If any premise is not met, then the boundary of ExecutionUnit is set at that point and will not be crossed during merging; ExecutionUnit Description: Each ExecutionUnit contains a unit identifier, a list of nodes, a list of connections, necessary preconditions / postconditions, resource hints, and audit information for the merge decision (including the reasons and basis for the merge). Audit and rollback information: The merge decision, the list of merged nodes and the basis are written to the compileLog for runtime verification or rollback to the original granularity if necessary; The compilation unit encapsulates the verified and completed nodes and connections of the merged node, ExecutionUnit, and related metadata into a GraphArtifact, and specifies the composition and loading verification process of the artifact: Artifact composition: GraphArtifact should include at least: a validated and completed set of nodes and a set of connections, a merge list and metadata (joinMode, window parameters), a list of ExecutionUnits and a description of each unit, static evaluation results of routePredicate and runtime-eval annotations, compileLog (including audit records of pruning, insertion, merging, etc.) and artifact metadata (version number, generation time, compiler identifier and validation summary). Output and Load Verification: After the artifact is output, the runtime should verify the artifact's integrity and version compatibility before loading; the loading verification items include reference integrity, artifact signature / verification code, and acceptance status of key changes in the compileLog; if the verification fails, the loading should be rejected or manual confirmation should be prompted according to the strategy defined in the artifact metadata. Auditing and Rollback: The compileLog is output with the artifact, recording in detail the basis and timestamps for clipping, merging, insertion, and consolidation; for clipped or automatically inserted elements, the artifact retains the original definition or reference for explicit modification and recompilation later; the artifact supports version management for smooth replacement or rollback, and version differences are listed in the artifact metadata for review purposes. All decision thresholds, merging and missing handling strategies, ExecutionUnit merging applicability parameters, and artifact output strategies are configurable items and are distributed with GraphArtifact or deployment configuration; compileLog serves as the audit basis for compile-time changes and should include detailed entries for each pruning, insertion, and merging operation and their decision criteria; for pruned or automatically inserted elements, GraphArtifact should retain the original definition or reference for subsequent manual intervention and recompilation; the interface, field format, and version compatibility rules between artifacts and runtime are specified in the artifact field description table in the appendix.

[0029] The execution environment initialization includes: To facilitate the stable operation of the business execution graph driven by executable graph artifacts at runtime, after deploying the graph artifact to the runtime environment, the system completes the initialization of the execution environment according to the following steps; GraphArtifact Deployment: At runtime, the specified GraphArtifact is loaded from the versioned artifact repository, and validations are performed on artifact integrity, version compatibility, reference integrity, and key change status in the compileLog. If the validation passes, the artifact content is imported into the runtime metadata storage; if it fails, loading is rejected according to the artifact metadata policy or manual confirmation is prompted. Creation or allocation of node data areas: At runtime, three types of logical data areas (collectively referred to as VertexStorage) are created or allocated for each node in the business execution graph: ResultBucket: Used to store the structured processing results or product references of a single execution of this node; the products of each execution are organized with idempotent keys or execution identifiers; SharedBucket: A context or intermediate artifact shared across nodes, managed according to the visibility and lifecycle rules declared in the artifact; Metadata Bucket: Used to record traceability information and runtime status (e.g., traceId, executionId, execution status code, retry count, timestamp, and artifact location pointer). Frontier queue and in-flight counter initialization: The runtime initializes the frontier queue used to manage the set of ready vertices. The queue entries contain minimal routing metadata to support fast scheduling. At the same time, the in-flight counter used to record the number of tasks in transit is initialized. The in-transit execution counter is implemented using an atomic update mechanism, and the count can be statistically analyzed and summarized according to the graph path or the namespace dimension. The counter is updated atomically at the enqueue, dequeue, execution start and execution completion points to ensure statistical consistency in a concurrent environment; Back pressure parameter configuration: Initialize back pressure related parameters at runtime according to the deployment configuration. Back pressure parameters are configurable items and must include at least: Trigger threshold (used to determine whether back pressure is triggered, such as in-transit count threshold, processing delay threshold, or queue length threshold). Propagation rules (defining the range and step rules of back pressure signal propagation along the upstream path, as well as the minimum required field format of the signal); The default response policy identifier (indicating the default handling that upstream nodes can take when receiving backpressure, such as throttling, enabling drop-able buffers, or degrading paths) allows backpressure parameters and thresholds to be configured independently by path or namespace and distributed with GraphArtifact or runtime deployment configuration items. Verification and Startup Preparation: After completing the above initialization, the runtime should perform a load verification: verify that the data areas of each node have been allocated and are accessible, the initial states of the leading queue and the in-transit counter are consistent, the backpressure parameters have taken effect and the event stream / observation channel is available; if the verification passes, the runtime will enter the ready state and accept the entry signal to start the execution of the graph; if the verification fails, it will roll back according to the deployment strategy or prompt manual handling, and record the reason in the compileLog / run log; all initialization actions, quota allocation, threshold settings and verification results are recorded in the runtime log and event stream for auditing and operation and maintenance. The backpressure parameters and the in-transit counter threshold are configurable items, and their modifications should be issued in the form of versioned artifacts or runtime configuration changes and the change history should be recorded.

[0030] The execution driven by the graph signal includes: Upon receiving an external business request or triggering event, the ingress node generates an initial graph signal (GraphSignal). This GraphSignal contains at least the following fields: traceId, signalId, originVertexId, timestamp, payload, and necessary routing metadata (routeMeta). When the payload is large, artifact references or digest pointers can be used in the signal to avoid transmitting large objects. The initial GraphSignal is submitted to the runtime's front queue, and the runtime sends it hop-by-hop to downstream connections in the graph according to the scheduling strategy. After receiving a GraphSignal, a node first extracts the payload and traceability fields from the signal, and then performs field integrity and type compatibility checks based on the input contract defined by the node in the artifact. The input contract includes a list of required fields, optional fields, and field type constraints. If the verification fails, the node will execute the configured error handling policy: record the exception event, perform degradation according to the configuration, or return an error response; for recoverable exceptions, a retry policy can be triggered, and retry information is recorded in the MetadataBucket. Once the input contract verification passes, the node execution unit triggers the execution logic corresponding to the node type (e.g., AiAgent, FunctionAgent, HumanAgent, BarrierAgent), and maintains the idempotency identifier (executionId) of this execution during the execution process. After execution, the node writes the structured output artifacts to the ResultBucket (if the artifacts need to be shared across nodes, they are also written to the SharedBucket or alternatively), and writes the execution identifier, status, start / end timestamps and artifact references to the MetadataBucket. The write operation should follow idempotency and atomic semantics to avoid duplicate side effects. Nodes construct successor GraphSignal based on their output contract and the routing predicate on the connection. The payload of the successor signal is the product or product reference, and the signal header carries the necessary traceability information (such as traceId, originVertexId, parentSignalId, retryCount). For each outgoing edge, its routing predicate is evaluated at runtime: predicates that can be statically determined at compile time are evaluated at compile time, and predicates that need to be evaluated at runtime are evaluated according to the current load and metadata. Edges that satisfy the predicate are the actual delivery paths. If there are multiple edges that satisfy the predicate, the delivery order or parallel delivery is determined according to the priority or arrival order agreed in the artifact. When the GraphSignals of multiple upstream branches reach the same target node (usually a JoinBarrier or a merging point configured in the artifact), the merging control unit performs aggregation according to the merging rules configured at the target node. The merging rules include at least three types: all arrivals, any priority, and window. Specific parameters (such as window size, timeout, and default values ​​for missing branches) are specified in the artifact metadata. During aggregation, the merging unit performs field alignment and assembly according to the input contract of the target node. If there are field conflicts or missing fields, the missing handling strategy of the merging node is adopted to fill in default values, wait for timeout and then degrade, or trigger compensation logic, and the processing decision is recorded in the event stream. During runtime, the system continuously monitors downstream processing capacity metrics (such as downstream queue length, node processing latency, in-transit execution count, and retry rate), and uses the in-transit execution counter and other metrics against preset thresholds for judgment. When preset judgment conditions are met (such as in-transit count exceeding the threshold, processing latency exceeding the threshold, or cascading failure rate increasing), the control unit propagates a backpressure signal along the upstream path of the business execution graph. The backpressure signal contains at least a congestion level field, an affected path identifier, and a timestamp, and carries necessary traceId tracing information. The upstream node receiving the backpressure signal executes response measures according to its configuration (such as reducing the signal transmission rate, enabling a dropable buffer, or switching to a degraded path), and writes the actions taken and current key metrics into the MetadataBucket and event stream for centralized observation. When a node starts, completes, retryes, encounters an exception, or degrades, a structured event is generated by the graph signal and event management unit. The event includes at least the following fields: eventType, sourceTraceId, vertexId, edgeId (if applicable), eventTimestamp, eventSeq, and payload pointer or digest. The event is written to the event stream asynchronously and non-blockingly. The event writing strategy and persistence backend are configurable. The event stream is used for both real-time monitoring and post-event auditing and revisiting. Each node execution should carry a unique idempotent key or executionId. All downstream calls to external side effects must be idempotent based on this idempotent key. Retry and backoff strategies are executed according to node configuration, and retry counts and backoff intervals are recorded in the MetadataBucket. For unrecoverable exceptions that exceed the retry limit, degradation or bypass logic is executed according to node configuration, and corresponding event records are generated. Checkpoints and snapshot mechanisms can persist critical states at appropriate times for lossless replay or compensation after failure.

[0031] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0032] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An intelligent agent orchestration system based on graph structure and reactive programming technology, characterized in that: This includes the following interdependent units that work collaboratively around a graph structure: The graph structure construction and compilation unit is used to generate a business execution graph containing multiple intelligent agent nodes and directional connections between nodes according to the business definition, and to perform topology verification on the business execution graph to identify and delete isolated nodes and connections that do not participate in path execution; in the identified parallel branches, if no merging node is configured externally, a merging node is automatically inserted; taking the verified and completed merging node nodes and connections and their metadata as input, the node execution logic, connection routing judgment logic, event triggering logic, and scheduling logic for advancing graph execution are merged into a schedulable execution unit and output as an executable graph artifact, which is used for runtime loading; The node operation unit is used to provide a data management structure and execution entry point for each intelligent agent node in the business execution graph. The data management structure includes a result data area, a shared data area, and a metadata area. When a node receives a graph signal from upstream, the node running unit calls the corresponding agent logic based on the payload in the graph signal and generates a subsequent graph signal. The generated structured result is written into the result data area or shared data area, and the execution identifier and traceability information are written into the metadata area. The routing and merging control unit is used to determine the downstream path of the graph signal based on the routing predicate on the connection relationship, and when multiple upstream graph signals arrive at the same target node, it aggregates the loads of the multiple upstream graph signals according to the merging rules of the target node to form the complete input of the target node; The graph signal and event management unit is used to define and maintain the graph signal format flowing on the edges and generate structured events when events such as the start, end, retry, exception, and degradation of node execution occur. The responsive operation and execution control unit is used to maintain the leading queue and the in-transit execution count, and transmits a back pressure signal carrying context information along the upstream path of the graph structure when it detects a decrease in downstream carrying capacity or an in-transit count exceeding a preset threshold.

2. The intelligent agent orchestration system based on graph structure and reactive programming technology according to claim 1, characterized in that: The graph structure construction and compilation unit is used for: A business execution graph containing multiple intelligent agent nodes and directional connections between nodes is generated based on the business definition. The business execution graph is then topologically verified to identify and delete isolated nodes and connections that do not participate in path execution. When no merging node is explicitly configured in the identified parallel branches, the graph structure construction and compilation unit further inserts the merging node. The graph structure construction and compilation unit takes the verified nodes and connections and their metadata as input, and merges the node execution logic, the routing judgment logic on the connection, the event logic triggered by the node execution state, and the scheduling logic for advancing the graph execution into a schedulable execution unit according to a predetermined path, and outputs it as an executable graph artifact.

3. The intelligent agent orchestration system based on graph structure and reactive programming technology according to claim 2, characterized in that: The node operation unit is used to: provide a data management structure and execution entry point for each intelligent agent node in the business execution graph; the data management structure includes a result data area, a shared data area and a metadata area, the result data area is used to store the structured processing results of a single execution of the node, and the shared data area is used to store the context or intermediate products that can be read by other nodes; The metadata area is used to store execution identifiers and execution status information for tracing or scheduling. When the node receives a graph signal from upstream and the graph signal contains an execution payload, the node's running unit triggers the execution logic corresponding to the node based on the received payload and generates a subsequent graph signal. The structured result generated by the execution and the corresponding execution identifier are written into the result data area and the metadata area, respectively. The successor graph signal is used to drive the downstream nodes of the service execution graph to continue execution.

4. The intelligent agent orchestration system based on graph structure and reactive programming technology according to claim 3, characterized in that: The routing and merging control unit is used for: Based on the predefined routing predicates on the connection relationship, the downstream edge to which each received graph signal should be delivered is determined; and when two or more graph signals from different upstream edges arrive at the same target node, the loads of the multiple upstream graph signals are aggregated according to the merging rules configured at the target node to form the complete input of the target node; the merging rules include all arrivals, any priority, and window; The complete input is passed to the target node as a successor graph signal payload to drive downstream execution.

5. The intelligent agent orchestration system based on graph structure and reactive programming technology according to claim 4, characterized in that: The graph signal and event management unit is characterized by: Define and maintain the graph signal format transmitted along the connection; when a node experiences an execution start, execution end, retry, exception, or degradation state change, the unit generates a structured event, which contains at least the following fields: event type identifier, source graph signal identifier, involved vertex identifier, involved edge identifier, event timestamp, event round or sequence number, and a payload summary or pointer to identify or point to the location of the node's artifacts or metadata; the structured event is asynchronously written to the event stream for consumption or archiving by downstream subscribers or persistent components; the event contains minimal tracing information corresponding to the involved graph signal when written so as to associate the execution path in subsequent auditing.

6. The intelligent agent orchestration system based on graph structure and reactive programming technology according to claim 5, characterized in that: The responsive operation and execution control unit maintains a frontier queue for managing currently ready vertices and an in-transit execution counter for recording the number of tasks in transit. The in-transit execution counter is an atomic counter and can be counted separately according to the path or namespace dimension of the graph. The unit monitors the downstream processing capacity and uses a preset threshold as a judgment condition. When the responsive operation and execution control unit detects a decrease in downstream carrying capacity or an execution counter value exceeding a preset threshold, it transmits a backpressure signal carrying contextual information along the upstream path of the service execution graph. The backpressure signal includes at least a congestion level field, an affected path identifier, and a timestamp. The backpressure signal is used by upstream nodes as a trigger for adjusting the transmission rhythm of other signals or switching to a droppable buffer strategy. The preset threshold and the contextual information of the backpressure signal are configurable parameters.

7. A method for orchestrating intelligent agents based on graph structure and reactive programming techniques, characterized in that: Including the intelligent agent orchestration system based on graph structure and reactive programming technology as described in any one of claims 1 to 6, the system comprising: Graph Construction and Compilation: Receives declarative or visual business graph definitions, generates a node list, a connection list, and node metadata, performs topology verification and removes isolated nodes and connections that do not participate in path execution, inserts merging nodes for identified parallel branches in cases where no merging point is explicitly configured externally, and then merges the node execution logic, routing judgment logic, event triggering logic, and scheduling advancement logic into a schedulable execution unit and generates an executable graph artifact. Execution environment initialization: Deploy the executable graph artifact in the runtime environment, initialize the result data area, shared data area and metadata area for each node in the business execution graph, and establish the front queue, in-transit execution counter and back pressure parameters; Graph signal-driven execution: The entry node generates an initial graph signal and transmits it along the connection relationship. After receiving the graph signal, each node executes business logic according to the graph signal payload and generates subsequent graph signals. When multiple branches return to the merging node, the payloads of multiple graph signals are aggregated according to the preset merging rules. During the execution process, when downstream resource congestion or abnormal transit count is detected, a back pressure signal is fed back upstream along the graph structure. The upstream node adjusts the graph signal transmission rate or enables the discardable buffer accordingly, and records the execution event and abnormal event through the event management unit.

8. The intelligent agent orchestration method based on graph structure and reactive programming technology according to claim 7, characterized in that: The graph construction and compilation include: The declaration parsing function parses the received declarative or visual business diagram definition into node tables, join tables, and node metadata. Topology verification and pruning: Based on the node table and connection table, the business execution graph is verified for topology integrity and nodes or connections that are determined to be isolated or not involved in path execution are removed. Parallel branch identification and merging deployment: Identify sets of branches that can be executed in parallel; for sets of parallel branches for which merging points are not explicitly configured externally, insert merging nodes at candidate positions; The execution unit is generated by taking the verified and supplemented nodes and connections and their metadata as input, and merging the node execution logic, routing judgment logic, event triggering logic and scheduling advancement logic into a schedulable execution unit. Executable graph artifact generation: The set of execution units is encapsulated into an executable graph artifact and output for loading at runtime.

9. The intelligent agent orchestration method based on graph structure and reactive programming technology according to claim 8, characterized in that: The execution environment initialization includes: Deploy the executable graph artifact in the runtime environment; create or allocate a result data area for storing node execution results, a shared data area for cross-node sharing, and a metadata area for recording traceability and runtime status for each node in the business execution graph at runtime; initialize a front queue for managing the set of ready vertices; initialize an in-transit execution counter for recording the number of tasks in transit, which can be counted separately according to graph path or namespace dimension; configure backpressure parameters for runtime, the backpressure parameters including a threshold for determining backpressure triggering and backpressure propagation rules; the backpressure parameters and the threshold of the in-transit execution counter are configurable items.

10. The intelligent agent orchestration method based on graph structure and reactive programming technology according to claim 9, characterized in that: The execution of the graph signal-driven process includes: An initial graph signal is generated by the entry node and transmitted hop-by-hop along the connection of the service execution graph. After receiving the graph signal, each node triggers the corresponding node execution logic according to the graph signal payload and the node's input contract, and generates subsequent graph signals to be transmitted downstream. When graph signals from multiple upstream branches arrive at the same target node, the payloads of multiple upstream graph signals are aggregated according to the merging rules configured at the target node to form the complete input of the target node. During execution, the downstream processing capacity and the in-transit execution count are monitored during runtime, and a back pressure signal is transmitted upstream along the graph structure when the preset judgment conditions are met. The back pressure signal is used by the upstream node to adjust the graph signal transmission strategy or enable temporary buffering. Key decisions and anomalies during execution are recorded in the form of structured events and asynchronously written into the event stream by the event management unit.

Images