Dialogue flow arrangement method and system based on multi-node conditional routing state diagram

Abstract

The application discloses a kind of conversation flow arrangement method and system based on multi-node conditional routing state diagram. Including: the directed state diagram containing multiple functional nodes and conditional routing edge is constructed, conversation state is divided into two levels of persistent state that cross round survival and transient state that is only single round effective, cross round isolation is realized by routing signal reset at round start and routing signal discard at round end;By type annotation, declare override semantics and additional semantics when defining state field, the framework layer automatically executes the corresponding state merging strategy according to the annotation;In the process of executing graph node, real-time push incremental event through the asynchronous event channel injected at runtime;And according to node type, execute mixed terminal state processing, interactive guide class node self-terminates direct connection graph terminal, and business query class node converges into terminal state converging node for unified processing.The application realizes the deterministic, auditable and high reliability arrangement of conversation flow.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a dialogue flow orchestration method and system based on a multi-node conditional routing state graph. Background Technology

[0002] In conversational query systems targeting vertical industries, such as building energy consumption analysis assistants, intelligent customer service, and medical consultation systems, the system needs to determine the direction of the conversation based on signals from multiple dimensions, including the user's input intent, the completeness of the collected information, and the current business model. This involves guiding the user to supplement information, directly calling the business API to obtain results, or handling non-business topics such as casual conversation.

[0003] The dialogue process of such systems typically includes multiple stages such as intent classification, slot extraction, missing item guidance, API call, and result interpretation, and there are complex conditional jump relationships between different stages.

[0004] In existing technologies, the orchestration of such dialogue flows typically employs the following approach: Option A: LLM End-to-End Free Dialogue Solution This approach delegates all decision-making power in the dialogue to the large language model (LLM), allowing the LLM to decide when to collect information, when to invoke tools, and when to provide results. However, this approach has the following drawbacks: LLM's decision-making is random and uncontrollable: the same input may be executed multiple times and may take different dialogue paths, and it cannot guarantee that critical business processes (such as slot completeness checks) will be executed. LLM cannot provide deterministic process control: when slots are not in full, LLM may directly call the API to generate invalid queries, or it may over-guide users without initiating the necessary queries; The dialogue process is not auditable: it is impossible to extract a deterministic routing decision chain from the free dialogue of an LLM, making it difficult to locate process errors; Event push is deeply coupled with the LLM generation process, making it impossible to independently control the front-end UI state outside of LLM inference.

[0005] Solution B: Linear pipeline solution based on if-else chain Using a traditional if-else conditional chain, each processing stage is executed sequentially in a fixed order, skipping or executing certain steps based on conditions. This approach has the following drawbacks: The flow control logic is scattered throughout the various processing functions, forming deeply nested if-else statements, which result in extremely poor readability and maintainability. Unable to represent multi-branch routes: When there are more than 3 possible results for intent classification and multiple combinations of slot states, linear pipelines cannot naturally represent graph structures. Chaotic state management: All processing stages share the same state dictionary, intermediate variables written in the previous stage may be misread by the subsequent stage, and residual routing signals between different rounds may interfere with each other; It is difficult to expand new dialogue branches: adding a branch requires modifying multiple condition judgments, which violates the open / closed principle.

[0006] Option C: Dialogue Management Scheme Based on Traditional Finite State Machine (FSM) Using traditional finite state machines to define dialogue states and transition conditions, with state transitions driven by table lookups or rule engines, this approach has the following drawbacks: The transition function of a traditional finite state machine (FSM) is typically defined as (current state, event / input) → next state. Its conditional judgments are based on a single event or input, making it difficult to naturally express combined conditional routing based on multiple contextual signals (such as intent classification results, slot completeness, business patterns, etc.). In dialogue systems, routing decisions often require simultaneous consideration of multiple dimensions of information. The binary mapping model of FSM cannot efficiently handle such multidimensional conditions, typically requiring the decomposition of multidimensional logic into numerous intermediate states or complex event combinations, leading to state explosion and scattered logic, significantly reducing the maintainability and scalability of the system.

[0007] Traditional FSMs lack semantic control over the granularity of state fields: all fields must either be replaced entirely or retained entirely, making it impossible to distinguish between different semantics such as routing signals that should be covered or event lists that should be appended. Traditional FSMs typically do not support injecting asynchronous event channels into runtime configurations. Nodes cannot push incremental events outward during execution and can only output results once after the entire FSM has been executed. The persistence of state and transient routing signals are not isolated. The current state of the FSM naturally carries all the information from the previous round. The routing decisions of the previous round may remain in the next round, leading to misrouting.

[0008] Scheme D: ReAct loop scheme based on LangChain agents Using LangChain's agent framework, the LLM autonomously selects tools and decides its next action through a ReAct (Reasoning Acting) loop. This approach has the following drawbacks: The agent's movement trajectory is entirely determined by the LLM, lacking deterministic process guarantees; it cannot guarantee that business constraints such as slot completeness checks must be performed before calling the API. The inference overhead of LLM in the ReAct loop is large; each decision step requires an LLM call, which is an unnecessary overhead for deterministic routing, such as calling the API when all slots are available. The agent cannot precisely control the front-end UI state: the intermediate steps of the ReAct loop are a black box to the front end, and it is impossible to push incremental UI events at specific nodes in the process.

[0009] To address the aforementioned problems with existing solutions, this application proposes a dialogue flow orchestration method and system based on a multi-node conditional routing state graph. Summary of the Invention

[0010] Therefore, the purpose of this invention is to provide a dialogue flow orchestration method and system based on a multi-node conditional routing state graph. This application achieves deterministic decision-making through pure function conditional routing, eliminates signal residue through two-layer state isolation, achieves automatic semantic recognition of field-level merging through type annotations, decouples computation and transmission through asynchronous event channels, and unifies final state behavior through a hybrid final state strategy. These five mechanisms work together to achieve a paradigm shift from probabilistic LLM decision-making to deterministic and auditable orchestration, and can be widely applied to scenarios such as intelligent customer service and vertical domain dialogue systems.

[0011] To achieve the above objectives, the present invention provides a dialogue flow orchestration method based on a multi-node conditional routing state graph, comprising the following steps: S1. Construct a directed state graph, which contains multiple functional nodes and conditional routing edges; S2. Divide the dialogue state into two levels: persistent state and transient state. The persistent state survives across dialogue rounds, while the transient state only exists during the execution of a single-round directed state graph. In the state field definitions of the persistent state and the transient state, merge semantics are declared through type annotations. The merge operation is automatically performed when merging state fields according to the type annotation declaration. S3. In response to user input, a round-isolated bidirectional conversion mechanism is adopted. At the start of the round, the persistent state is converted to the transient state. During the conversion, the routing signal field in the transient state is reset to the initial value. S4. Using the transient state as a state parameter, execute the directed state graph. During the execution of each functional node of the directed state graph, push incremental events outward asynchronously through the event channel injected at runtime. S5. Perform final state processing according to the type of the functional node. After the interactive guidance node is completed, it is directly connected to the end point of the graph. After the business query node is completed, it is merged into the final state aggregation node for unified processing and then connected to the end point of the graph. S6. Write back the transient state after execution to the persistent state. Discard the routing signal field in the transient state during the write-back to achieve routing signal isolation at the end of the round.

[0012] More preferably, the functional nodes of the directed state graph are divided into five categories according to their responsibilities, including: Routing distribution class, including routing distribution nodes; Understanding and analysis categories include intent classification nodes, slot extraction nodes, and process control nodes; Interactive guidance classes, including guidance nodes and chat nodes; Business query categories include event query nodes, diagnostic query nodes, and standard query nodes; The auxiliary classes include mode selection nodes, status query nodes, automatic query nodes, and final state aggregation nodes; The conditional routing edges include 6 conditional routing edges and their corresponding routing functions: The first conditional routing edge originating from the routing distribution node corresponds to the first routing function route_dispatch, which is used for routing based on user input type signals; The second conditional routing edge originating from the mode selection node corresponds to the second routing function route_dispatch, which is used for routing based on the slot completeness signal. The third conditional routing edge originating from the intent classification node corresponds to the third routing function route_classify_intent, which is used for routing based on the intent classification result signal; The fourth conditional routing edge originating from the slot extraction node corresponds to the fourth routing function route_slot_extract, which is used for routing based on intent type signals. The fifth conditional routing edge originating from the process control node corresponds to the fifth routing function route_flow_control, which is used to perform routing based on slot completeness signals and query decision signals. The sixth conditional routing edge originating from the automatic query node corresponds to the sixth routing function route_auto_fetch, which is used to perform routing based on the missing slot signal, the geographic entity gating signal, and the business query mode signal. More preferably, the conditional routing edge is driven by a three-dimensional routing signal, which includes: The intent classification result signal is generated by the intent classification node in the directed state graph calling the large language model, and the values ​​include chat intent, state query intent and business intent. The slot completeness signal is calculated and generated by the process control node or automatic query node, indicating the list of required slots that has not yet been fully collected. The business query mode signal is set by the routing distribution node or the process control node to determine which business API to call.

[0013] More preferably, the routing function corresponding to the automatically queried node performs a triple-priority routing decision: First priority: If the missing slot list is not empty, then route to the bootstrap node; Second priority: If the geographic entity gating flag is true, then route to the bootstrap node; Third priority: If the missing slot list is empty and the geographic entity gating flag is false, then the business query mode signal is routed to the corresponding business query node.

[0014] More preferably, in S2, in the definition of the state fields of the persistent state and the transient state, the merging semantics are declared through type annotations, including: the state fields are defined as overriding semantics and appending semantics; For fields that use overriding semantics, they are marked with the first annotation type, and the framework layer overwrites the old value with the new value returned by the node during merging; For fields that use append semantics, they are annotated with the second annotation type, and the framework layer appends the new list returned by the node to the end of the old list during merging.

[0015] Further preferably, the 10 fields for the semantic coverage include: routing branch signal, intent classification result, query mode signal, query status flag, missing slot list, geographic entity gating flag, user guidance message, current mode, dialogue stage, and slot data; the 4 fields for the semantic appending include: dialogue history, streaming event list, thought step list, and completed mode list, all of which are list-type cumulative fields, and all content generated by each node should be retained.

[0016] More preferably, in S3, during the execution of each functional node in the directed state graph, incremental events are asynchronously pushed outward through an event channel injected at runtime. The event channel is an encapsulation based on an asynchronous queue, providing the following interfaces: The asynchronous write interface is used to write event data to the queue, and it blocks and waits when the queue is full. An asynchronous read interface is used to read event data from a queue; it blocks and waits when the queue is empty. The close interface is used to write a sentinel signal to the queue to terminate the consumption loop.

[0017] A further preferred approach is to implement the push of incremental events using the following dual-coroutine asynchronous architecture: The subtask coroutine executes the directed state graph. During the execution process, each functional node pushes incremental events through the asynchronous write interface. After the directed state graph is completed, a sentinel signal is written through the close interface. The main coroutine consumes events through the asynchronous read interface. When it receives an event that is not a sentinel signal, it outputs it outward. When it receives the sentinel signal, it terminates the consumption loop and waits for the subtask coroutine to complete.

[0018] More preferably, in S5, performing final state processing according to the type of the functional node specifically includes: Self-terminating path: For interactive guidance nodes, including chat nodes, status query nodes and guidance nodes, after the interactive guidance nodes have been executed, they emit option events and completion events on their own, and are directly connected to the end point of the graph through the edges of the directed state graph, without passing through the final state convergence node. Convergence path: For business query nodes, which include event query nodes, diagnostic query nodes, and standard query nodes, the business query nodes are merged into the final state convergence node after execution. The final state convergence node uniformly performs the following post-processing: constructing shortcut options based on the completed mode list and hiding the options of completed modes, emitting option events, emitting completion events, and updating the dialogue stage state; wherein, each dialogue round has one and only one completion event emitted, which is emitted by the termination node, the completion event is emitted by the interaction guidance node of the self-terminating path, and the completion event is emitted by the final state convergence node of the convergence path.

[0019] This invention also provides a dialogue flow orchestration system based on a multi-node conditional routing state graph. The system includes a state graph construction module configured to construct a directed state graph containing multiple functional nodes and conditional routing edges; a state management module configured to divide the dialogue state into persistent and transient levels, perform bidirectional conversion between persistent and transient states, and have cross-round routing signal isolation functionality; a routing execution module configured to execute the directed state graph using transient states as state parameters; an event channel module configured to asynchronously push incremental events outward through runtime-injected event channels during the execution of each functional node; and a final state processing module configured to execute a hybrid final state strategy based on the type of functional node: interactive guidance nodes are directly connected to the graph endpoint, while business query nodes are merged into the final state aggregation node for unified processing and then connected to the graph endpoint.

[0020] Beneficial effects This application proposes a systematic dialogue flow orchestration method and system based on a multi-node conditional routing state graph. It transforms the dialogue flow from a traditional pattern of scattered rules, mixed states, and coupled computations into a deterministic and auditable architecture with node-based routing, two-layer isolation, and channel decoupling. Compared to existing technologies, it has at least the following advantages: 1. This invention innovatively provides a multi-node conditional routing state graph based on three-dimensional signals of intent, slot, and pattern; it innovatively abstracts the routing decision of the dialogue process into a pure function conditional routing driven by three-dimensional signals (intent classification result, slot completeness, and business query pattern), overcoming the limitation of traditional FSM that only supports binary mapping from (state, input) to the next state; the routing decision is completely determined by the state field value, without relying on LLM black-box reasoning, and has determinism, auditability, and unit testability.

[0021] 2. This invention employs a persistent / transient dual-layer state structure and a round isolation mechanism, innovatively dividing the dialogue state into persistent and transient levels. Through a bidirectional conversion mechanism of deep copy outgoing and explicit whitelist write-back, complete isolation of routing signals is achieved at round boundaries. This completely eliminates the misrouting problem caused by cross-round routing signal remnants; when the directed state graph execution fails, the original persistent state remains unaffected, achieving failure isolation and automatic rollback within the graph.

[0022] 3. This invention employs a semantic strategy for merging type annotation declarations. Merging semantics are declared when defining state fields; routing signal fields use overriding semantics, and cumulative fields use append semantics. The framework layer automatically selects the correct merging strategy based on annotations. This solves the pain point of traditional solutions that cannot distinguish merging semantics at the field granularity, and completely eliminates errors caused by manually handling merging logic.

[0023] 4. This invention employs an event channel decoupling based on asyncio.Queue; it designs an EventChannel to encapsulate the asynchronous queue, injecting it into graph nodes through runtime configuration. A dual-coroutine architecture is adopted: the sub-coroutine executes the graph and pushes events, while the main coroutine consumes events and outputs them via SSE; the two are decoupled through a Queue. A None sentinel ensures reliable termination of the consumption loop. This achieves complete decoupling of graph computation from the HTTP transport layer, supporting streaming incremental push without waiting for the directed state graph to complete.

[0024] 5. This invention employs a hybrid final state strategy combining self-termination and aggregation; interactive guidance nodes (chat, status query, guidance) terminate directly to END to avoid misprocessing by aggregation nodes; business query nodes are uniformly aggregated into the final state aggregation node for post-processing, eliminating code duplication. The "whoever terminates, emits done" principle ensures that there is exactly one completion event per round, avoiding duplication or omission.

[0025] In summary, the above five innovative aspects work together to achieve a paradigm shift from "LLM probabilistic decision-making" to "deterministic and auditable orchestration": deterministic and traceable routing, absolute security of cross-round states, independent and scalable nodes, streaming real-time push, and consistent final-state behavior. This can be widely applied to dialogue systems in vertical fields such as intelligent customer service, energy consumption analysis, and medical consultation. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the dialogue flow orchestration method based on a multi-node conditional routing state graph provided by the present invention.

[0027] Figure 2 This is the complete topological structure diagram of the directed state graph in this invention.

[0028] Figure 3 This is a schematic diagram of the dual-coroutine architecture for asynchronously pushing incremental events through the event channel in this invention. Detailed Implementation

[0029] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] like Figure 1 As shown, the dialogue flow orchestration method based on a multi-node conditional routing state graph provided in this embodiment of the invention operates in the following technical environment: Backend runtime environment: Python 3.10+ general programming language, using the Hypertext Transfer Protocol Service framework as the HTTP service framework.

[0031] Large Language Model Service: Called via OpenAI compatible API (DashScope), the model is the Tongyi Thousand Questions series.

[0032] Dialogue orchestration framework: Based on the existing directed state graph engine, 13 nodes and 6 conditional routing edges are established.

[0033] Frontend: It adopts a single-page application frontend framework and receives incremental events pushed by the backend through a server-side event sending protocol.

[0034] Standard database: PostgreSQL relational database.

[0035] Specifically, the following steps are included: S1. Construct a directed state graph, which contains multiple functional nodes and conditional routing edges.

[0036] like Figure 2 As shown, the directed state graph contains 13 functional nodes and 9 edges (including 6 conditional routing edges and 3 END direct connection edges). The 13 nodes are divided into five categories according to their responsibilities: Routing distribution class, including routing distribution nodes; Understanding and analysis categories include intent classification nodes, slot extraction nodes, and process control nodes; Interactive guidance classes, including guidance nodes and chat nodes; Business query categories include event query nodes, diagnostic query nodes, and standard query nodes; The auxiliary classes include mode selection nodes, status query nodes, automatic query nodes, and final state aggregation nodes; The details are shown in Table 1 below: Table 1: Node Classification Table category node Duties Route distribution Routing distribution node The initial branch is determined based on the type of user input (shortcut / free text). Understanding and Analysis Intent classification node, slot extraction node, process control node Intent classification, slot extraction, process control and query decision-making Interactive guidance Guide nodes, chat nodes Missing information guidance, casual conversation responses Business Inquiry Event query node, diagnostic query node, standard query node Event query, diagnostic query, standard benchmarking query Support Mode selection node, status query node, automatic query node, final state aggregation node Mode selection, status query, automatic route query, final state aggregation Example 1: This example will demonstrate the detailed design of the node.

[0037] 1. Dispatch node: Sets branch routing signals based on user input type (action or free text).

[0038] The routing logic is shown in Table 2 below: Table 2: Routing logic table of the route distribution node condition Routing branch signal value Next node The operation is "Mode Setting" and the value is valid. Mode settings Mode selection node The operation is "direct query" and the value is valid. Direct query Automatic node query There is free text Free text Intent classification node 2. The mode selection node (set_mode) handles the business mode selected by the user through quick options. If all slots are available, the query mode is set to route to the automatic query node; otherwise, after sending a mode introduction message and quick options, it is routed to the final aggregation node.

[0039] 3. The intent classification node (classify_intent) calls LLM to classify the intent of the user's free text and returns the intent label (casual chat intent, status query intent, or business intent).

[0040] 4. The slot extraction node (slot_extract) extracts structured slot data through a forced function call, merges it with existing slots, and performs automatic geographic entity completion. The processing flow includes: 1) Call the incremental slot extraction function to extract incremental slots through LLM; 2) Call the slot merge function to merge the increment into the current slot (null value protection: null / empty string will not overwrite existing values); 3) Call the geographic entity auto-completion function to automatically complete the city / business type level; 4) Extraction results of the launch thinking process event report.

[0041] 5. The process control node comprehensively checks the completeness of slots, the results of geographic entity disambiguation, and fetch decisions, constructs guiding messages, and routes them. The processing flow includes: 1) Align the current mode with the current intent; 2) Calculate and obtain missing required slots; 3) Call the geographic entity gating construction function (build_geo_fetch_gate) to obtain the geographic entity gating results and prompts; 4) If all slots are available and there is no gate blocking, make a fetch decision (dual channel: LLM priority + regular expression heuristic fallback). 5) Based on the decision result, route to the automatic query node or the guiding node; 6) Construct a user guidance message, which includes slot snapshots, missing items, gating prompts, etc.

[0042] 6. The state query node (state_query) handles user inquiries about the current status (such as filled information, progress, etc.), generates a response directly, and then terminates itself; it automatically emits option events and completion events and then directly connects to the end point of the graph.

[0043] 7. The off-topic node handles casual conversation topics unrelated to business logic and calls LLM to generate friendly replies.

[0044] 8. The guidance node receives the input constructed by the user's guidance message, calls the LLM stream to generate guidance dialogue, and helps the user fill in missing information or confirm the disambiguation result.

[0045] 9. The automatic query node (auto_fetch) performs geographic entity gating checks and routes requests to either the guidance dialog or the specific business API call node based on the check results. The processing flow includes: (1) Execute the geographic entity auto-completion function to complete the data; (2) Check for missing required slots and obtain a list of missing slots; (3) If there is a missing node, route to the bootstrap node; (4) Call the geographic entity gating construction function to check the gating; (5) If gating is blocked (geographic entity gating flag is true), route to the bootstrap node; (6) Otherwise, the routing signal is routed to the corresponding business query node according to the query mode.

[0046] The server sends an event: Launch thought process event report query preparation status.

[0047] 10. Event Query Node (fetch_event): Calls the MCP event API to retrieve impact event data, and interprets the results using LLM streaming. Final State Strategy: Imports data into the final state aggregation node.

[0048] 11. Diagnostic Query Node (fetch_diagnosis): Calls the model context protocol diagnostic interface to obtain building energy consumption analysis results, supports cache reuse (based on hash fingerprint), and provides streaming interpretation results from large language models. Final State Strategy: Integrates into the final state aggregation node.

[0049] 12. The standard query node (fetch_standard_query) queries standard value data in the relational database, and the large language model interprets the results in a streaming manner. Final state strategy: merge into the final state aggregation node.

[0050] 13. The finalize node provides unified finalization processing for business query nodes. It constructs quick options and emits option events and completion events. The six conditional routing edges and their corresponding routing functions are: based on user input type signal (route_dispatch), based on slot completeness signal (route_set_mode), based on intent classification result signal (route_classify_intent), based on intent type signal (route_slot_extract), based on slot completeness and query decision signal (route_flow_control), and based on a triple signal of missing slot / geographic entity gating / query mode (route_auto_fetch). In addition, there are three direct END edges.

[0051] The conditional routing edges are driven by three-dimensional routing signals, with each conditional edge depending on only one or two dimensions; the three-dimensional routing signals include: The first dimension, the intent classification result signal, is generated by the intent classification node calling the large language model. Its values ​​include casual conversation intent, status query intent, and various business intents (energy consumption query intent, ranking query intent, standard check intent, etc.). This signal is read from the two conditional edges of the intent classification routing function and the slot extraction routing function.

[0052] The second dimension, slot completeness signal: generated by the process control node or automatic query node, indicates the list of required slot names that has not yet been fully collected. This signal is read by both the process control routing function and the automatic query routing function.

[0053] The third dimension, business query mode signal: set by the routing distribution node or process control node, with values ​​including event query mode, standard query mode, diagnostic query mode, etc. The automatic query routing function reads this signal to determine which specific business interface to call.

[0054] All six conditional routing functions are constrained to be pure functions: they only read state field values, return the target node identifier string, do not modify the state, do not call external APIs, and do not emit events. This constraint gives the routing decision the following properties: Determinism: Given the same state field value, the routing result is always consistent; Auditability: The routing decision chain can be fully reconstructed from a snapshot of the state fields; Testability: The routing function can be unit tested independently of the LLM and graph engine.

[0055] The routing function corresponding to the automatically queried node performs a triple-priority routing decision: First priority (highest priority): If the missing slot list is not empty, it means that a slot is missing at this time, so route to the bootstrap node; regardless of the gating status and query mode, ensure that the interface is never called when the slots are incomplete.

[0056] Second priority: If the geographic entity gating flag is true, it means that the geographic entity gating is closed, and the route is sent to the bootstrapping node; if the geographic entity gating flag is false, it means that the geographic entity gating is open, and various query modes can be performed. If the geographic entity gating flag is true (the city or building type has not passed the standard library disambiguation verification), the route is sent to the bootstrapping node to guide the user to confirm or correct the entity information, and the system will never pass the gate even if all slots are available.

[0057] Third priority: If the missing slot list is empty and the geographic entity gating flag is false, then the service query mode signal is routed to the corresponding service query node. After the first two priorities are passed, routing is performed according to the query mode value: event query mode is routed to the event query node, standard query mode is routed to the standard query node, and others are routed to the diagnostic query node.

[0058] This priority system ensures a security strategy of "first ensuring parameter completeness, then ensuring parameter correctness, and finally selecting the calling target".

[0059] S2. Divide the dialogue state into two levels: persistent state and transient state. The persistent state survives across dialogue rounds, while the transient state only exists during the execution of a single-round directed state graph. In the state field definitions of the persistent state and the transient state, merge semantics are declared through type annotations. The merge operation is automatically performed when merging state fields according to the type annotation declaration. The persistent state (AssistantState) is stored in the server-side session dictionary and survives across rounds. Fields include: chat_history (conversation history), slots (structured slots), current_mode (current business mode), completed_types (list of completed query modes), quick_options (quick options), phase (conversation phase), and mcp_result (API call result and cache fingerprint), etc.

[0060] The key fields of the persistent state (AssistantState) are shown in Table 3 below: Table 3: Key Fields of Persistent State Fields meaning Session ID Session unique identifier Dialogue with History Dialogue history (OpenAI message format) Slot data Currently extracted structured slot data Completed Mode List List of patterns that have been successfully queried Fingerprint in each mode slot Slot fingerprints of the most recently successfully queried slots in each mode Current mode Current business model Quick Options List of currently available shortcut options Dialogue phase Current stage (idle / collecting / ready / loading / done) API call result The result of the most recent MCP API call Resulting fingerprint in slot The corresponding slot fingerprint (used for cache reuse) results in The transient state exists only during the execution of a single round of the directed state graph. It adds the following fields to the persistent state fields: routing signal fields (routing branches, intent classification results, query mode, query status flag, missing slot list, geographic entity gating flag, user guidance messages, and unmatched prompt list) and server-sent event accumulation fields (streaming event list and thought process list). These fields are uniformly reset by the persistent-to-transient function at the beginning of each round. Key fields are shown in Table 4 below. Table 4: Key Fields for Transient Parameters Fields Reset value meaning Routing branches None The routing branch of the dispatch node Query mode None Current query mode Query flag? None Should I inquire immediately? Missing slot list [] List of missing required slots Guiding User Messages "" Constructing user messages to guide the conversation List of unmatched prompts [] City / Business Type Mismatch Notice Geographic entity gating sign False Geographic entity gating blocking sign Intent classification results "" Intent classification results Streaming event list [] SSE Event Cumulative List List of thinking steps [] Cumulative list of thinking steps S3. In response to user input, a round-isolated bidirectional conversion mechanism is adopted. At the start of the round, the persistent state is converted to the transient state. During the conversion, the routing signal field in the transient state is reset to the initial value. The two-way conversion mechanism for round-based isolation specifically includes the following processes: Round begins: When transitioning from persistent to transient state, perform the following operations: (1) Deep copy all fields of the persistent state to the transient state so that modifications within the graph do not affect the original persistent state; (2) Extract the current round user input (user text, operation type, operation value) from the load. (3) Reset all routing signal fields to their initial values ​​(set routing branches to null values, intent classification results to empty strings, missing slot lists to empty lists, etc.); (4) Reset all server-sent event accumulation fields to empty lists (set the streaming event list to an empty list and the thinking steps list to an empty list).

[0061] Round ends: Transition from transient to persistent state and perform the following operations: (1) Deep copy the original persistent state (without directly modifying the original object); (2) Only write back persistent business fields (dialogue history, slot data, current mode, list of completed modes, shortcut options, dialogue stage) and output fields (assistant reply messages, streaming event list, thought process list, intent classification results); (3) Explicitly discard all transient routing signal fields (routing branch, query mode, query status flag, missing slot list, user guidance message, unmatched prompt list, geographic entity gating flag).

[0062] Deep copying ensures that the original persistent state is not contaminated when the directed state graph fails (automatic rollback semantics); the routing signal is uniformly reset at the beginning of each round to ensure that the routing decision in each round depends only on the signal of the current round, avoiding the problem of incorrect routing to the bootstrap node caused by the geographical entity gating flag being true in the previous round remaining in the current round; the explicit discarding of transient fields in the transient-to-persistent state function provides double insurance, so that even if the initialization logic of the persistent-to-transient state function is modified, the terminal of the data flow can still prevent signal leakage.

[0063] It should be noted that in the definition of the state fields of the persistent state and the transient state, the merging semantics are declared through type annotations. According to the type annotation declaration, the merging operation is automatically executed when merging state fields. The core problem solved by this step is that after each node in the directed state graph is executed, it returns a partial state dictionary. The framework needs to merge it with the current state. However, different fields have two completely different merging semantics: "overwrite" and "append". Traditional solutions cannot automatically distinguish them at the field granularity.

[0064] During the transition, the routing signal field in the transient state is reset to its initial value; specifically, a dual semantic state merging strategy based on typed dictionaries and type annotations is adopted: This invention defines two types of reduction functions for state fields, and declares merging semantics when defining fields by using a typed dictionary in conjunction with type annotations: the state fields are defined with overriding semantics and appending semantics.

[0065] Override semantic reduction function: Applicable to routing signal fields and single-valued status fields, annotated as "field: type annotation marked as override semantic". When a node returns this field, the framework automatically overrides the old value with the new value.

[0066] Append semantic reduction functions: Applicable to list-type cumulative fields, annotated as "field: type annotation marked as append semantic". When a node returns this field, the framework automatically appends the new list to the end of the old list. An empty list serves as a fallback to prevent null exceptions when either the old or new value is null.

[0067] Field assignment: Coverage semantic fields (10): Route branch, intent classification result, query mode, query status flag, missing slot list, geographic entity gating flag, user guidance message, current mode, dialogue stage, slot data -- routing signals need to be written back to ensure the latest decision takes effect; single-value states also apply to coverage semantics. See Table 5 below: Table 5: Coverage Semantic Fields Table Fields illustrate Routing branches Routing branch signals are written only by the routing distribution node. Intent classification results Intent classification results, only intent classification nodes are written. Query mode Query patterns are written by pattern-selected nodes / automatic query nodes. Query flag? Whether a query should be performed is written by the process control node. Missing slot list The list of missing slots is written by the process control node / automatic query node. Geographic entity gating sign Geographic entity gating flags are written by the automatic query node. Guiding User Messages Guided messages are written by the process control node / automatic query node. Current mode In the current mode, writing is done by multiple nodes (write-after-over). Dialogue phase At the current stage, writing is done by multiple nodes. Slot data Slot data is written by slot extraction nodes / status query nodes, etc. Add four semantic fields: Dialogue History, Streaming Event List, Thinking Steps List, and Completed Pattern List—all are list-type cumulative fields, and all content generated by each node should be retained. See Table 6 below: Table 6: Table of Appendage Semantic Fields Fields illustrate Dialogue with History Conversation history, routing distribution nodes append user messages Streaming event list SSE event list, adding events to each node List of thinking steps List of thought steps, with additional step descriptions for each node. Completed Mode List The pattern list has been completed; the pattern name will be appended to the business query node. The reduction function annotation mechanism eliminates the need for node code to be aware of the merging strategy: nodes only return a portion of their generated state values, and the framework layer automatically selects whether to overwrite or append based on the field annotations. When a node does not modify a certain field, the node's return value does not contain that field, and the framework will not call the reduction function on it, thus avoiding the problem of null values ​​accidentally overwriting valid values.

[0068] like Figure 3 As shown, in S4, the directed state graph is executed using the transient state as the state parameter. During the execution of each functional node of the directed state graph, incremental events are asynchronously pushed outward through the event channel injected at runtime. The event channel is an encapsulation based on an asynchronous queue, providing the following interfaces: The asynchronous write interface is used to write event data to the queue, and it blocks and waits when the queue is full. An asynchronous read interface is used to read event data from a queue; it blocks and waits when the queue is empty. The interface is closed to write an empty sentinel signal to the queue to terminate the consumption loop. This ensures that the sentinel can be enqueued immediately regardless of the queue state.

[0069] Event channel instances are configured and injected into the directed state graph execution context at runtime. Any graph node, after obtaining an event channel reference through configuration parameters, can call the event channel's asynchronous write interface to push events at any time during execution.

[0070] This also includes the following asynchronous architecture using two coroutines when pushing incremental events outward: The subtask coroutine executes the directed state graph. During the execution process, each functional node pushes incremental events through the asynchronous write interface. After the directed state graph is completed, a sentinel signal is written through the close interface. The main coroutine consumes events through the asynchronous read interface. Upon receiving an event that is not a sentinel signal, it outputs it. Upon receiving a sentinel signal, it terminates the consumption loop and waits for the subtask coroutine to complete. Within a `while True` loop, it calls the asynchronous read interface of the event channel to consume events one by one. Upon receiving a non-null event, it outputs it item by item to the send event response stream passed to FastAPI; upon receiving a null sentinel signal, it exits the loop and then waits for the subtask to complete.

[0071] The absence of a sentinel signal ensures reliable termination of the consumption loop—regardless of whether the graph completes normally or exits abnormally, the close interface in the final processing block ensures that the sentinel is always pushed in, preventing the main coroutine from blocking indefinitely. The inter-coroutine blocking / wake-up semantics of the asynchronous queue allow the asynchronous read interface to automatically suspend the main coroutine when the queue is empty without polling. This decoupled architecture allows graph nodes to focus on business computation; the timing and content of event pushes are determined by the nodes themselves, achieving a streaming incremental output user experience.

[0072] S5. Perform final state processing according to the type of the functional node. After the interactive guidance node is completed, it is directly connected to the end point of the graph. After the business query node is completed, it is merged into the final state aggregation node for unified processing and then connected to the end point of the graph. Self-terminating path: For interactive guidance nodes, including chat nodes, status query nodes and guidance nodes, after the interactive guidance node is completed, it emits option events and completion events on its own and is directly connected to the end point of the graph through the edge of the directed state graph without passing through the final state aggregation node. Convergence path: For business query nodes, which include event query nodes, diagnostic query nodes, and standard query nodes, the business query nodes are merged into the final state convergence node after execution. The final state convergence node uniformly performs the following post-processing: constructing shortcut options based on the completed mode list and hiding the options of completed modes, emitting option events, emitting completion events, and updating the dialogue stage state; wherein, each dialogue round has one and only one completion event emitted, which is emitted by the termination node, the completion event is emitted by the interaction guidance node of the self-terminating path, and the completion event is emitted by the final state convergence node of the convergence path.

[0073] The core problem addressed in this step is that nodes with different responsibilities in the dialogue graph have different requirements for termination behavior—interaction guidance nodes should terminate in advance to save computing resources and avoid misprocessing, while business query nodes need unified post-processing to ensure consistency.

[0074] This invention divides the final state processing into two paths based on the node's responsibility: Self-terminating paths are suitable for interactive guidance nodes, including chat nodes, status query nodes, and guidance nodes. These nodes output messages directly to the user, and upon completion, they automatically emit option and completion events. They are directly connected to the endpoint of the directed state graph via edges, without traversing any subsequent nodes. This design ensures that the graph terminates immediately after the guidance node completes, preventing the final state convergence node from mistakenly processing the guidance message as an API call result.

[0075] The aggregation path applies to business query nodes, including event query nodes, diagnostic query nodes, and standard query nodes. The output of these nodes is the result of the API call, which is then aggregated into the final state aggregation node after execution. The final state aggregation node performs the following centralized actions: constructing shortcut options based on the list of completed modes (hiding options for completed modes), emitting option events and completion events, and updating the dialogue stage state.

[0076] The main purpose of this step is to establish the rule of "whoever terminates issues the completion event" to ensure that only one completion event is issued in each dialogue round, avoiding duplication or omission. The aggregation node eliminates the duplication of post-processing code in the three business query nodes, while ensuring that the final state behavior is completely consistent regardless of which interface call path the user takes (event query / diagnostic query / standard query).

[0077] In each dialogue round, there is one and only one completion event. The termination node is responsible for emitting the completion event. The self-terminating path is emitting the completion event by the interaction guidance node, and the convergence path is emitting the completion event by the final state convergence node.

[0078] S6. Write the transient state back to the persistent state after execution is completed. The routing signal field in the transient is discarded during write-back to achieve routing signal isolation at the end of the round.

[0079] Example 2: This example will demonstrate in detail the construction process of the 13-node conditional routing state graph.

[0080] Input: None (static construction process) Output: Compiled directed state graph instance.

[0081] The construction process is as follows: First, a directed state graph builder with transient states as the state type is created; then, 13 functional nodes are registered sequentially (route distribution node, pattern selection node, intent classification node, slot extraction node, flow control node, state query node, chat node, guide node, auto query node, event query node, diagnostic query node, standard query node, and final state convergence node); next, 6 conditional routing edges are added—starting from the route distribution node, pattern selection node, intent classification node, slot extraction node, flow control node, and auto query node respectively, and binding the corresponding pure function routing functions (route distribution function, pattern selection routing function, intent classification routing function, slot extraction routing function, flow control routing function, and auto query routing function); then, 3 direct edges to the graph endpoint are added (chat node to graph endpoint, state query node to graph endpoint, guide node to graph endpoint) and 3 convergence edges (event query node to final state convergence node, diagnostic query node to final state convergence node, and standard query node to final state convergence node); finally, the final state convergence node is connected to the graph endpoint, the compilation method is called to inject the checkpoint memory, and the compiled graph instance is returned.

[0082] Example 3: This example will demonstrate in detail the decision logic of the 6-condition routing function.

[0083] Input: Target node name string; all 7 routing functions are pure functions; the decision logic is as follows: 1. Route dispatch function: If the route branch is "mode setting", it returns "mode selection node"; if it is "direct query", it returns "automatic query node".

[0084] 2. Mode selection routing function: If the missing slot list is empty (slots are complete), return "Auto query node", otherwise return "Final state aggregation node".

[0085] 3. Intent Classification Routing Function: If the intent classification result is "casual chat intent", then return "casual chat node"; otherwise, return "slot extraction node".

[0086] 4. Slot extraction routing function: If the intent classification result is "Status query intent", then return "Status query node"; otherwise, return "Flow control node".

[0087] 5. Flow control routing function: If the missing slot list is empty and the query flag is true, return "Auto query node"; otherwise, return "Guide node".

[0088] 6. Automatic routing function lookup: Implements triple priority determination: Level 1: If the missing slot list is not empty, return "Guide Node"; Level 2: If the geographic entity gating flag is true, return to the "boot node"; Level 3: If the query mode is "Event Query Mode", then return "Event Query Node"; if it is "Standard Query Mode", then return "Standard Query Node"; otherwise, return "Diagnostic Query Node".

[0089] Example 4: This example will demonstrate in detail the two-layer state transition process.

[0090] The inputs are persistent state and user-input load; the output is transient. Perform the following steps: (1) Deep copy all fields of the persistent state to the new transient object; (2) Extract the user text, operation type, and operation value of the current round from the load; (3) Reset all transient routing signal fields to their initial values: route branch is set to null, query mode is set to null, query flag is set to null, missing slot list is set to null, user guidance message is set to null, unmatched prompt list is set to null, geographic entity gating flag is set to false, and intent classification result is set to null. (4) Reset all server-sent event accumulation fields to empty lists -- set both the streaming event list and the thought process list to empty lists.

[0091] Transition from transient to persistent state (transient to persistent state function): The input consists of the transient state and the original persistent state after the graph execution is complete; the output is the updated persistent state. Perform the following steps: (1) Deep copy of the original persistent state; (2) Only write back persistent business fields -- dialogue history, slot data, current mode, list of completed modes, fingerprints of each mode slot, quick options, dialogue stage, interface call result, and result slot fingerprint; (3) Write back the output fields -- assistant reply message, streaming event list, thinking steps list, intent classification results; (4) Discard all transient routing signal fields—routing branch, query mode, query status flag, missing slot list, user guidance message, unmatched prompt list, and geographic entity gating flag—to ensure that transient signals are not leaked to the next round.

[0092] Example 5: This example will demonstrate in detail the process of pushing incremental events outward.

[0093] Input: Persistent state and user input payload. Output: Server sends a stream of events (outputting events one by one to the service framework).

[0094] The overall process is as follows: (1) Create an event channel instance; (2) Call the persistent-to-transient function to convert the persistent state into an intra-graph transient state; (3) Construct a runtime configuration dictionary, in which the thread identifier is set to the session identifier and the event channel is set to the above event channel instance, thereby injecting the event channel into the graph execution context; (4) Define an asynchronous internal function, call the asynchronous call method of the graph in the exception handling block to execute the dialogue flow, and call the transient to persistent state function to write out the persistent state after execution; if an exception occurs, push the "error" event through the asynchronous write interface of the event channel; in the final processing block, ensure that the closing interface of the event channel is called to push the null value sentinel signal. (5) Start the above internal function as a subtask by creating an asynchronous task, so that the graph is executed in the sub-coroutine; (6) The main coroutine calls the asynchronous reading interface of the event channel in an infinite loop to consume events one by one -- each time a non-null value event is received, it is passed to the server to send the event response stream by outputting each item. When a null value sentinel is received, the loop is exited. (7) After exiting the loop, wait for the subtask to complete.

[0095] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A dialogue flow orchestration method based on a multi-node conditional routing state graph, characterized in that, Includes the following steps: S1. Construct a directed state graph, which contains multiple functional nodes and conditional routing edges; S2. Divide the dialogue state into two levels: persistent state and transient state. The persistent state survives across dialogue rounds, while the transient state only exists during the execution of a single-round directed state graph. In the state field definitions of the persistent state and the transient state, merge semantics are declared through type annotations. The merge operation is automatically performed when merging state fields according to the type annotation declaration. S3. In response to user input, a round-isolated bidirectional conversion mechanism is adopted. At the start of the round, the persistent state is converted to the transient state. During the conversion, the routing signal field in the transient state is reset to the initial value. S4. Using the transient state as a state parameter, execute the directed state graph. During the execution of each functional node of the directed state graph, push incremental events outward asynchronously through the event channel injected at runtime. S5. Perform final state processing according to the type of the functional node. After the interactive guidance node is completed, it is directly connected to the end point of the graph. After the business query node is completed, it is merged into the final state aggregation node for unified processing and then connected to the end point of the graph. S6. Write back the transient state after execution to the persistent state. Discard the routing signal field in the transient state during the write-back to achieve routing signal isolation at the end of the round.

2. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 1, characterized in that, The functional nodes of the directed state graph are divided into five categories according to their responsibilities, including: Routing distribution class, including routing distribution nodes; Understanding and analysis categories include intent classification nodes, slot extraction nodes, and process control nodes; Interactive guidance classes, including guidance nodes and chat nodes; Business query categories include event query nodes, diagnostic query nodes, and standard query nodes; The auxiliary classes include mode selection nodes, status query nodes, automatic query nodes, and final state aggregation nodes; The conditional routing edges include 6 conditional routing edges and their corresponding routing functions: The first conditional routing edge originating from the routing distribution node corresponds to the first routing function route_dispatch, which is used for routing based on user input type signals; The second conditional routing edge originating from the mode selection node corresponds to the second routing function route_dispatch, which is used for routing based on the slot completeness signal. The third conditional routing edge originating from the intent classification node corresponds to the third routing function route_classify_intent, which is used for routing based on the intent classification result signal; The fourth conditional routing edge originating from the slot extraction node corresponds to the fourth routing function route_slot_extract, which is used for routing based on intent type signals. The fifth conditional routing edge originating from the process control node corresponds to the fifth routing function route_flow_control, which is used to perform routing based on slot completeness signals and query decision signals. The sixth conditional routing edge originating from the automatic query node corresponds to the sixth routing function route_auto_fetch, which is used for routing based on the missing slot signal, the geographic entity gating signal, and the business query mode signal.

3. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 2, characterized in that, The conditional routing edge is driven by a three-dimensional routing signal, which includes: First dimension: The intent classification result signal is generated by the intent classification node in the directed state graph calling the large language model, and the values ​​include chat intent, state query intent and business intent; The second dimension: The slot completeness signal is calculated and generated by the process control node or the automatic query node, indicating the list of required slots that has not yet been fully collected. The third dimension: The business query mode signal is set by the routing distribution node or the process control node to determine which business API to call.

4. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 2, characterized in that, The routing function corresponding to the automatically queried node performs a triple-priority routing decision: First priority: If the missing slot list is not empty, then route to the bootstrap node; Second priority: If the geographic entity gating flag is true, then route to the bootstrap node; Third priority: If the missing slot list is empty and the geographic entity gating flag is false, then the business query mode signal is routed to the corresponding business query node.

5. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 2, characterized in that, In S2, the state field definitions of the persistent state and the transient state are declared with merge semantics through type annotations, including: the state field is defined with overriding semantics and appending semantics; For fields that use overriding semantics, they are marked with the first annotation type, and the framework layer overwrites the old value with the new value returned by the node during merging; For fields that use append semantics, they are annotated with the second annotation type, and the framework layer appends the new list returned by the node to the end of the old list during merging.

6. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 5, characterized in that, The ten fields for the coverage semantics include: routing branch signal, intent classification result, query mode signal, query status flag, missing slot list, geographic entity gating flag, user guidance message, current mode, dialogue stage, and slot data; the four fields for the append semantics include: dialogue history, streaming event list, thought step list, and completed mode list, all of which are list-type cumulative fields, and all content generated by each node should be retained.

7. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 2, characterized in that, In S3, during the execution of each functional node in the directed state graph, incremental events are asynchronously pushed outward through an event channel injected at runtime. This event channel is a wrapper based on an asynchronous queue and provides the following interfaces: The asynchronous write interface is used to write event data to the queue, and it blocks and waits when the queue is full. An asynchronous read interface is used to read event data from a queue; it blocks and waits when the queue is empty. The close interface is used to write a sentinel signal to the queue to terminate the consumption loop.

8. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 7, characterized in that, This also includes the following asynchronous architecture using two coroutines when pushing incremental events outward: The subtask coroutine executes the directed state graph. During the execution process, each functional node pushes incremental events through the asynchronous write interface. After the directed state graph is completed, a sentinel signal is written through the close interface. The main coroutine consumes events through the asynchronous read interface. When it receives an event that is not a sentinel signal, it outputs it outward. When it receives the sentinel signal, it terminates the consumption loop and waits for the subtask coroutine to complete.

9. The dialogue flow orchestration method based on a multi-node conditional routing state graph according to claim 1, characterized in that, In S5, the final state processing based on the type of the functional node specifically includes: Self-terminating path: For interactive guidance nodes, including chat nodes, status query nodes and guidance nodes, after the interactive guidance nodes have been executed, they emit option events and completion events on their own, and are directly connected to the end point of the graph through the edges of the directed state graph, without passing through the final state convergence node. Convergence path: For business query nodes, which include event query nodes, diagnostic query nodes, and standard query nodes, the business query nodes are merged into the final state convergence node after execution. The final state convergence node uniformly performs the following post-processing: constructing shortcut options based on the completed mode list and hiding the options of completed modes, emitting option events, emitting completion events, and updating the dialogue stage state; wherein, each dialogue round has one and only one completion event emitted, which is emitted by the termination node, the completion event is emitted by the interaction guidance node of the self-terminating path, and the completion event is emitted by the final state convergence node of the convergence path.

10. A dialogue flow orchestration system based on a multi-node conditional routing state graph, characterized in that, include: The state graph construction module is configured to build a directed state graph containing multiple functional nodes and conditional routing edges; The state management module is configured to divide the dialogue state into two levels: persistent state and transient state, perform bidirectional conversion between persistent state and transient state, and have cross-round routing signal isolation function; The routing execution module is configured to execute the directed state graph with transients as state parameters; The event channel module is configured to asynchronously push incremental events outward through runtime-injected event channels during the execution of each functional node; The final state processing module is configured to execute a hybrid final state strategy based on the type of functional node: interactive guidance nodes are directly connected to the graph endpoint, while business query nodes are merged into the final state aggregation node for unified processing and then connected to the graph endpoint.

Images