Cross-system dynamic workflow orchestration method and system based on user intent recognition

Abstract

This invention belongs to the field of artificial intelligence and software engineering technology, specifically a method and system for cross-system dynamic workflow orchestration based on user intent recognition. The method includes: introducing confidence assessment and a multi-round clarification mechanism; performing zero-sample API semantic alignment through a shared embedding space and combining it with reliability weights for retrieval; dynamically generating a directed acyclic graph workflow; employing the Saga pattern during execution to ensure cross-system transaction consistency; performing local replanning through influence domain analysis when a node fails, replacing only the affected subgraph; and finally aggregating the results and updating the API reliability weights based on an exponential moving average. This invention solves the problems of error-prone intent understanding, static and inflexible workflows, lack of cross-system transaction guarantees, and inability to self-optimize in existing technologies, achieving highly robust, adaptive, and strongly consistent intelligent workflow orchestration.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and software engineering technology, and in particular to a cross-system dynamic workflow orchestration method and system based on user intent recognition. Background Technology

[0002] In existing technologies, the main solutions fall into the following categories: ① Intent-driven network service orchestration solutions (such as CN118301014A), which translate user intents into network QoS indicators to drive network resource configuration; ② Workflow generation solutions based on large models (such as CN121501271A), which use LLM to determine tool nodes from the tool library and generate workflows at once; ③ Data analysis solutions based on multi-layer intent recognition and multi-agent collaboration (such as CN121524343A); ④ Automated workflow management solutions based on dynamic state machines (such as IN202511071113A).

[0003] However, the aforementioned existing technical solutions have at least the following drawbacks: First, they lack sufficient intent recognition capabilities, lack confidence assessment and clarification mechanisms, and cannot handle semantically ambiguous or multi-task compound user requests. Second, the workflow is statically generated, lacking dynamic adaptive adjustment capabilities during the execution phase, often requiring a complete restart or manual intervention when node calls fail. Third, the transaction consistency guarantee for cross-system calls is imperfect, lacking a systematic automatic rollback mechanism, which easily leads to data inconsistency between multiple systems. Fourth, API selection lacks historical experience accumulation, making it impossible to dynamically optimize the selection strategy based on runtime feedback. Summary of the Invention

[0004] This invention proposes a cross-system dynamic workflow orchestration method and system based on user intent recognition, aiming to solve the technical problems in the prior art, such as insufficient intent recognition capability, lack of confidence assessment and clarification mechanism, which leads to semantic ambiguity or user requests with multiple tasks being easily misunderstood.

[0005] In a first aspect, the present invention provides a cross-system dynamic workflow orchestration method based on user intent recognition, including: S1. Obtain the user's natural language request, perform confidence aggregation calculation on the structured sub-intent output by the large language model to obtain the overall confidence score, and when the overall confidence score is lower than a preset threshold, trigger multiple rounds of clarification dialogue, and re-send the context of the user's reply into the large language model for parsing until the overall confidence score reaches the target or the preset number of clarification rounds is reached. S2, the parsed user intent and API description are mapped to the same embedding space through a shared encoder to calculate semantic similarity, and combined with the reliability weights of each API node obtained from the API capability graph for comprehensive ranking, and the matching API node is retrieved from the vector index library; S3, based on the retrieved API nodes, constructs an initial directed graph by combining intent logic dependencies and API data dependencies. After redundancy pruning, parallel route identification, and topology sorting verification, it generates an executable directed acyclic graph workflow. S4. Schedule and execute API nodes according to the topological order of the directed acyclic graph workflow. If an API node fails to execute, call the compensation operations of the successfully registered API nodes in reverse topological order. S5. When an API node in the workflow fails to execute, a breadth-first search is used to determine the set of affected downstream nodes. After filtering out the failed APIs, the search is repeated. The workflow is regenerated only for the affected subgraphs, and a format conversion node is inserted to connect the existing execution results. S6 collects and aggregates the execution results of each node in topological order, and updates the reliability weight of the corresponding API node in the API capability graph using an exponential moving average formula based on the success or failure of this execution.

[0006] The technical advantages of the cross-system dynamic workflow orchestration method based on user intent recognition disclosed in this invention are as follows: Through multi-granularity hierarchical intent recognition and a confidence-driven multi-round clarification mechanism, workflow generation errors caused by intent misunderstanding are fundamentally avoided, improving system accuracy and user experience. Through an adaptive local replanning mechanism during execution, affected subgraphs can be accurately located and replaced when nodes fail, avoiding the regeneration and execution of the entire workflow and greatly improving the system's fault tolerance and recovery efficiency. Through a cross-system compensation transaction mechanism based on the Saga pattern, pre-configured compensation operations are provided for each cross-system call, ensuring eventual data consistency for long-process businesses in distributed, heterogeneous system environments. Through an API reliability weight adaptive update mechanism based on historical execution statistics, the system can gradually optimize API selection strategies as usage accumulates, continuously improving workflow orchestration quality and execution success rate. Furthermore, through zero-sample API semantic alignment based on a shared embedding space, new APIs can be seamlessly integrated into the system with only a functional description, eliminating the need for manual configuration of mapping rules and reducing system maintenance and expansion costs.

[0007] Furthermore, the confidence aggregation calculation in S1 is performed using a weighted summation method, and its mathematical expression is: ; in It is the confidence score of the i-th sub-intent field. The preset weight is the weight corresponding to the i-th sub-intent field.

[0008] Furthermore, the scoring function of the comprehensive ranking in S2 ; in The cosine similarity function is used. and These are the intent vector and the API description vector, respectively. For balance coefficient, The reliability weight is persistently stored using the API identifier as the key, with an initial value of 1.0.

[0009] Furthermore, the parallel route identification in S3 includes: identifying API node pairs that have no path relationship and no resource contention, determining that they can be executed in parallel, and inserting virtual nodes representing the start of parallel branches in the directed acyclic graph. and virtual nodes representing the convergence of parallel branches ; and inserting conditional route virtual nodes carrying JSONPath conditional expressions. It is used to select the execution path based on the output data of the predecessor node at runtime.

[0010] Furthermore, S4 specifically includes: Maintain a transaction log entry for each API node to record the correspondence between forward operations and compensation operations. Update the status after a node executes successfully, and trigger the compensation process when a node fails to execute. Traverse the transaction log in reverse order and call the compensation operation in reverse topology order.

[0011] Furthermore, in S4, for a node that fails to execute, if the API node is marked as idempotent, an exponential backoff strategy is adopted for retrying, with a maximum of 3 retries and a waiting time sequence of 1 second, 2 seconds, and 4 seconds; if a non-idempotent API node fails to call, it is directly marked as failed and a compensation process is triggered without retrying.

[0012] Furthermore, in S5, the breadth-first search uses a forward traversal method to determine the set of all downstream nodes that directly or indirectly depend on the failed nodes; the format conversion nodes are automatically inserted based on the data type compatibility matrix, which contains the mapping relationship between JSON to XML conversion and basic numeric type conversion.

[0013] Furthermore, the exponential moving average formula in S6 is: ; in The attenuation coefficient is... This is the success label, set to 1 when the node executes successfully and 0 when it fails. and These are the reliability weights before and after the update, respectively. The updated reliability weights are persisted using Redis's hash table command.

[0014] Furthermore, the method also includes setting up manual confirmation mechanisms at the following key decision points: displaying the parsing results to the user and requesting confirmation after the intent parsing is completed; displaying intermediate results and requesting confirmation after parallel nodes with no data dependencies have been executed; and generating an operation draft and requesting the user to review and confirm it before calling an API with a preset significant impact.

[0015] Secondly, the present invention provides a cross-system dynamic workflow orchestration system based on user intent recognition, the system being used to execute the method, the system comprising: An intent recognition module, used to perform S1, includes at least a large language model parsing engine, a confidence aggregator, and a multi-turn clarification dialogue manager; The API semantic alignment module, used to perform S2, includes at least a shared language encoder, a vector index library, and an API capability graph maintainer. The workflow generation module, used to execute S3, includes at least an initial graph builder, a redundancy pruner, a parallel route identifier, and a topology sorting verifier. The execution engine module, used to execute S4, includes at least an execution scheduler, a compensation transaction manager, and a real-time status monitoring unit. An adaptive replanning module, used to perform S5, includes at least an influence domain analyzer, an alternative API retriever, a local DAG generator, and an interface aligner. The result aggregation module is used to perform S6, and it includes at least a result collector and aggregator, an execution report generator, and an API capability graph updater.

[0016] The technical effects of the system disclosed in this invention are: (1) Through confidence-weighted aggregation and multi-round clarification mechanism, the system can quantitatively evaluate each sub-intent field of the LLM output. When the overall confidence is lower than the threshold, it automatically initiates a targeted clarification dialogue instead of directly executing or simply rejecting. This fundamentally solves the problem of misunderstanding caused by ambiguous requests and complex tasks, and improves the accuracy of intent parsing in complex scenarios to an engineerable level.

[0017] (2) Through zero-sample API semantic alignment with a shared embedding space, the system does not need to predefine mapping rules for each new API, and can achieve retrieval and matching based solely on the functional description text. Combined with the comprehensive ranking based on reliability weights, new APIs can be plugged and played, reducing system maintenance costs and maintaining retrieval efficiency as the API library expands.

[0018] (3) By using a compensation transaction manager based on the Saga pattern and an idempotent retry strategy, the system pre-sets a reverse compensation operation for each cross-system call and performs compensation in reverse order of topology when a node fails, ensuring the eventual consistency of data in long-process business under heterogeneous distributed environment and avoiding manual reconciliation and dirty data residue.

[0019] (4) Through influence domain BFS analysis and local DAG replanning, when a single API node fails, the system only regenerates the affected subgraph and automatically inserts format conversion nodes to connect the existing execution results. Compared with the global regeneration scheme, this mechanism reduces the failure recovery latency by an order of magnitude (<2 seconds in typical scenarios) and retains the execution results of successful nodes, significantly improving the fault tolerance of the workflow.

[0020] (5) By updating the API reliability weights through exponential moving average, the system writes the success / failure feedback of each execution into the API capability graph in a decaying cumulative manner, so that APIs with stable historical performance and long-term reliability can obtain higher ranking scores. This mechanism realizes continuous self-optimization without manual annotation, and a single anomaly will not cause drastic fluctuations in weights, ensuring the smooth evolution of the orchestration strategy. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the cross-system dynamic workflow orchestration method based on user intent recognition proposed in an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of the multi-granularity hierarchical intent recognition module provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the execution engine workflow and state machine provided in an embodiment of the present invention. Detailed Implementation

[0022] 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.

[0023] This invention aims to address the following technical problems existing in the prior art: First, insufficient intent recognition capability and lack of confidence assessment and clarification mechanisms, leading to misunderstandings of semantically ambiguous or multi-task complex user requests; Second, the workflow is statically generated, lacking dynamic adaptive adjustment capabilities during the execution phase, often requiring overall restart or manual intervention when node calls fail; Third, inadequate transaction consistency guarantees across system calls, lacking a systematic automatic rollback mechanism, easily leading to data inconsistencies between multiple systems; Fourth, API selection lacks historical experience accumulation, making it impossible to dynamically optimize selection strategies based on runtime feedback.

[0024] As attached Figure 1 As shown in the figure, this embodiment provides a cross-system dynamic workflow orchestration system based on user intent recognition, which consists of six core modules: intent recognition module, API semantic alignment module, workflow generation module, execution engine module (including a compensating transaction manager), adaptive replanning module, and result aggregation module. This system is used to execute a cross-system dynamic workflow orchestration method based on user intent recognition, which specifically includes the following steps: Step S1: Multi-granularity hierarchical intent recognition As attached Figure 2 As shown, this step aims to accurately and reliably convert a user's natural language request into a structured, machine-readable intent.

[0025] Components: The intent recognition module consists of four sub-components connected in series: ① Lightweight multi-label text classifier; ② Large Language Model (LLM) parsing engine; ③ Confidence aggregator; ④ Multi-turn clarification dialogue manager.

[0026] Working principle: This step adopts a four-layer serial architecture of "coarse → fine → verification → clarification".

[0027] Coarse-grained classification: The system receives the user's raw natural language request Q. First, a lightweight multi-label text classifier quickly classifies Q, predicting its domain label d∈D (e.g., "scientific research management", "financial reimbursement", etc.). This step has an inference latency of less than 10ms, aiming to quickly narrow down the scope for subsequent retrieval and parsing. This classifier can use the FastText model for extremely low latency (<5ms), or the DistilBERT model for higher accuracy (approximately 50ms latency). The domain label set D is predefined by the business side and supports dynamically adding new domains through supplementary training samples and online fine-tuning.

[0028] Fine-grained parsing: The original request Q and coarse-grained domain labels d are fed together into the large language model parsing engine. This engine uses the structured output capabilities of the LLM (such as OpenAIFunctionCalling, AnthropicToolUse interface, or locally deployed open-source LLMs like Qwen2.5-7B-Instruct) to parse natural language into machine-processable sub-semantics. Figure 3 Tuple set Intent={( , , )}.in, Indicates the target action (selected from the enumeration values). Represents the action object string, This represents an array of constraints for the sub-intent. The output JSON schema must be explicitly specified in the prompt.

[0029] Confidence quantification: The confidence aggregator performs a weighted calculation of the confidence score for each field in the LLM output to obtain the overall confidence score `conf`, which ranges from (0,1). The mathematical expression for the overall confidence score is: ; in It is the confidence score of the i-th sub-intent field. The preset weight is the weight corresponding to the i-th sub-intent field.

[0030] Multi-round clarification: Determine if the conf value is below a preset threshold (e.g., 0.8). If so, the multi-round clarification dialogue manager is activated, analyzing the sources of uncertainty during LLM parsing and generating targeted clarification questions for ambiguous parts. The system engages in multiple rounds of dialogue with the user, recording the user's response in each round. With historical context ctx={( , ),...,( , )} splice together to form a new request It is then re-sent into the LLM parsing engine, where For the (j-1)th question, This corresponds to the (j-1)th answer. This process will be repeated a maximum of 3 times. If the result still does not meet the standard, the current answer with the highest confidence will be used to continue the process. All clarification history is stored in the form of a list {question, answer} for later steps to follow.

[0031] Step S2: Intent semantic vectorization and API retrieval This step aims to map the structured intent obtained in the previous step to a specific API.

[0032] Components: The API semantic alignment module consists of three sub-components: ① shared language encoder; ② vector index library (such as FAISS); ③ API capability graph maintainer.

[0033] How it works: A shared language encoder (e.g., using sentence-transformers / all-MiniLM-L6-v2, vector dimension d=384) converts the structured intent description I output by S1 and the functional description text of all registered APIs. Projecting them into the same high-dimensional embedding space, intention vectors are generated respectively. and API description vector By calculating cosine similarity This measures the semantic match between the intent and the API functionality. The final API ranking scores are as follows: ; in The cosine similarity function is used. For balance coefficient, The reliability weights are persistently stored using the API identifier as the key, with an initial value of 1.0. The API capability graph is a directed graph. (V, E), where node V represents an API and edge E represents the data dependencies between APIs. This approach achieves zero-sample API alignment, meaning a new API can be retrieved simply by providing its functional description text, without requiring manual configuration of mapping rules.

[0034] Step S3: Dynamic workflow DAG generation.

[0035] Working principle: The workflow generation module takes the set of API nodes retrieved by S2 as input and executes a four-stage process to generate a DAG.

[0036] Initial graph construction: Merging two types of dependencies: ① From the intent constraints of S1 ① Logical dependency edges parsed from the API capability graph; ② From the API capability graph The data dependencies obtained are used to construct the initial directed graph. .

[0037] Redundancy pruning: Perform constraint matching checks (e.g., check if the input and output types of an API match the context) and feature deduplication (e.g., if multiple APIs have similar functions, only keep the one with the highest overall score) to remove unqualified nodes.

[0038] Parallel route identification: analysis There are no node pairs with path relationships in the data. , ),Right now ( , )and ( , If all values ​​are false and there is no resource contention (based on the target system resource identifier and read / write operation type during API registration), then they can be executed in parallel. Therefore, virtual nodes are inserted into the DAG. (Parallel branch start) and (Parallel branch convergence). Simultaneously, for nodes containing runtime branching logic, insert conditional routing virtual nodes. This node carries a JSONPath conditional expression, which is used to select the correct outgoing edge based on the output data of the predecessor node during execution.

[0039] Topological sorting verification: The Kahn algorithm is used to detect cycles in the final DAG. If no cycles are found, the topological sequence τ is output as the sole scheduling basis for subsequent executions, ensuring that preorder nodes that depend on data always execute before their subsequent nodes. The above graph operations can be implemented using the PythonNetworkX library.

[0040] Step S4: Cross-system execution and compensation transaction management.

[0041] As attached Figure 3 As shown, this step is responsible for the specific execution of the workflow and ensuring transaction consistency.

[0042] Components: The execution engine module includes: ① execution scheduler; ② compensation transaction manager; ③ real-time status monitoring unit.

[0043] Working principle: Scheduling execution: The execution scheduler schedules nodes in an asynchronous, non-blocking manner (e.g., using Python asyncio) according to topological order τ. When encountering... When a node is triggered, use asyncio.gather to concurrently trigger all its child nodes; The node waits for all parallel branches to complete (asyncio.wait(return_when=ALL_COMPLETED)); The node then evaluates its JSONPath expression and selects and activates the corresponding downstream branch.

[0044] Saga (Distributed Transaction Mode) Transaction Management: Compensation Transaction Manager for each API node Maintain a transaction log entry ( , , ,status), where It is a forward operation (the actual API call). This corresponds to the compensation operation. This pair of operations is pre-registered before the node executes. After successful execution, the node updates its status to "committed"; if execution fails, the compensation process is triggered. The compensation process iterates in reverse order. A list, for each node in the committed state. Call its compensation operation in reverse topological order. This allows changes that have already taken effect to be revoked, and the state of each system to be rolled back to its initial state before the workflow started.

[0045] Exception handling and retries: The real-time status monitoring unit maintains the state machine of each node (e.g., pending → running → succeeded / failed). For failed nodes, if their API is marked as such during registration... =True (idempotent) will initiate an exponential backoff retry strategy (e.g., using the tenacity library, a maximum of 3 retries with waiting times of 1 second, 2 seconds, and 4 seconds). If a non-idempotent API call (such as a deduction operation) times out or fails, it will be marked as failed without retrying, and the Saga compensation process will be triggered immediately.

[0046] Step S5: Adaptive Local Replanning During Execution Working principle: When a non-retry node in S4 is a failed node If the execution fails, the adaptive replanning module is activated to perform a "surgical" local replacement.

[0047] Impact domain analysis: The impact domain analyzer uses... Starting from the first element, use the BFS algorithm to traverse the DAG forward to determine all direct or indirect dependencies. The set of affected downstream nodes in the output It has been successfully executed and does not depend on... Node set Then it remains unchanged.

[0048] Local replanning: Replacing the API retriever with With the functional requirements as the goal, the retrieval logic of S2 is reused, but will be... The API identifier is added to the filter list (Pythonset) to ensure that search results exclude APIs known to fail. The local DAG generator only uses... As input, re-execute the S3 workflow generation process to generate a new locally directed acyclic graph. .

[0049] Interface alignment: Due to the API replacement, the newly generated local directed acyclic graph The input / output interfaces may be related to The output results are incompatible. The interface aligner performs two-stage alignment: type-level alignment and field semantic-level alignment.

[0050] (1) Type-level alignment: Maintain a data type compatibility matrix (e.g., JSON) XML conversion, int float conversion, string conversion (date formatting, etc.), automatically insert one or more format conversion nodes. It converts the syntax structure of upstream data into the format required by downstream APIs.

[0051] (2) Field semantic alignment: When the upstream output field name (such as employeeName) is inconsistent with the downstream required field name (such as staffFullName), the interface aligner performs the following automated mapping process: Step 1 (Semantic Vector Matching): Reuse the shared encoder in S2 to map the upstream output field names and their description texts, as well as the downstream required field names and their description texts, to the same embedding space, and calculate the cosine similarity. If the similarity exceeds a preset threshold (e.g., 0.85), the field mapping relationship is automatically established.

[0052] Step 2 (Knowledge Base Query): If semantic matching fails, the interface aligner queries the field mapping knowledge base (using (source API identifier, source field name, target API identifier, target field name) as the key, storing historical successful mapping records and their confidence levels). If historical mapping records exist, they are applied directly.

[0053] Step 3 (LLM-assisted mapping): If the first two steps fail to obtain a reliable mapping, the interface aligner calls a lightweight LLM with the following input context: "The upstream output field employeeName (meaning: employee name) needs to be mapped to the downstream field staffFullName (meaning: employee's full name). Please determine if there is a match and the conversion rules." The LLM outputs a structured result (match / no match / requires simple format transformation), and the system generates mapping rules accordingly.

[0054] Step 4 (Manual Verification): If all the above automated methods fail or the overall confidence level is below the threshold (e.g., 0.6), the conflicting fields and candidate mapping suggestions are displayed to the user, requesting manual confirmation. The confirmed mapping rules are automatically stored in the knowledge base for reuse in similar scenarios in the future.

[0055] Through the aforementioned four-level progressive mechanism of semantics-knowledge-LLM-human intervention, the interface aligner can achieve automatic field-level stitching during cross-system API replacement without the need for pre-configured mapping rules, significantly improving the success rate and automation level of local replanning. If, after all steps, there are still required fields that cannot be mapped, the system terminates the current local replanning, reports the specific reason, and reverts to manual intervention mode.

[0056] Step S6: Result aggregation and API capability graph update.

[0057] Working principle: Result Aggregation: The result collector and aggregator traverses all successfully executed nodes in topological order τ, collecting the output data of each node. The node ID is stored in a dictionary. Downstream nodes retrieve the required input from this dictionary through a parameter name mapping. For parallel branches, The node is responsible for collecting the output of all upstream branches and processing it according to the aggregation method specified by the intent constraint (e.g., concatenation, merging). Finally, optionally, LLM is invoked to format the structured execution result data into a user-understandable natural language summary.

[0058] Execution report generation: The execution report generator records the overall status (success / failure), latency of each node, number of retries, compensation status and other metadata of this workflow execution, and appends them to a local file (such as logs / workflow_exec.jsonl) in JSONLines format. It can also be asynchronously pushed to a monitoring system (such as Grafana / Prometheus) via a message queue.

[0059] API Capability Graph Update: The API Capability Graph Updater updates the graph based on the results of this execution, using an Exponential Moving Average (EMA) formula. Reliability weights of relevant APIs : ; in The attenuation coefficient is... This is the success label, set to 1 when the node executes successfully and 0 when it fails. and These represent the reliability weights before and after the update, respectively. The updated reliability weight is persistently stored using a Redis hash table command. This formula ensures that historical weights dominate, and a single failure will not cause a sudden drop in weight, guaranteeing the stability of the evaluation. Updated The dictionary is persisted using the Redis HSET command to ensure data integrity after a system restart. During S2 retrieval, the system batch-reads all APIs within the current domain from Redis. Value. Additionally, if new, undocumented data dependencies are discovered during execution, they are added incrementally. In this way, the API capability graph will be gradually improved as the system is used.

[0060] In a specific implementation scenario: Taking the research project approval process as an example, this process involves five independent systems: OA (Office Automation), research project management system, financial system, human resources system, and contract management system. Researcher Xiao Zhang enters a natural language request into the OA intelligent assistant: "Help me apply for a research project, titled 'Application of Artificial Intelligence in Medical Imaging,' with a budget of 500,000 yuan, myself as the project leader, and XX University as the collaborating institution. After approval, automatically sign the contract and prepare the budget." The system execution flow is as follows: S1: LLM resolves the sub-intent: {( "Application of Artificial Intelligence in Medical Imaging", {Budget: 500,000} ,“Xiao Zhang”,{...}),( The confidence level is 0.85, and no clarification is required.

[0061] S2-S3: The system retrieves and generates a DAG, which includes five API calls. The graph identifies that "duplicate checking" and "qualification verification" have no dependency relationship, so v_fork nodes are inserted before them to achieve parallelism and improve efficiency.

[0062] Human-in-the-Loop: The system incorporates a human confirmation mechanism at three key decision points: ① After intent parsing is completed, the parsed project information and subsequent operations are shown to Xiao Zhang, and the process continues after confirmation; ② After "duplicate check" and "qualification verification" are completed, the results are shown, and the system is submitted for approval only after confirmation; ③ After approval, a draft contract is shown for review, and the contract is officially signed only after confirmation.

[0063] S4 & S5: Assume that during execution, the personnel qualification verification API times out and fails. The system automatically executes S5, and the impact domain analyzer determines that the affected downstream node is "Submit for Approval". The alternative API retriever finds another backup personnel qualification verification API, the local DAG generator generates a new subgraph, and the interface aligner automatically converts the output format of the former to the format required by the latter. The entire process is completed within 2 seconds, and the workflow can continue to execute.

[0064] Assuming the subsequent "budget allocation" step fails, the compensation transaction manager will call the compensation operations of the successful nodes in reverse order. For example, it will call the "cancel contract" API of the contract management system and the "withdraw project application" API of the research system to ensure that the data of each system is eventually consistent.

[0065] S6: Finally, the system reports to Xiao Zhang: "The project 'Application of Artificial Intelligence in Medical Imaging' has been successfully approved, the contract has been signed, and the budget has been allocated. The total execution time was 5 minutes." Simultaneously, the system records the execution time and results of each API, and updates the reliability weights of each node in the API capability graph. For example, the failed personnel qualification verification API... The reduced weighting means that more reliable backup APIs will be prioritized during future workflow orchestration. A process that would traditionally take two hours manually can be completed in five minutes by this system.

[0066] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A cross-system dynamic workflow orchestration method based on user intent recognition, characterized in that, include: S1. Obtain the user's natural language request, perform confidence aggregation calculation on the structured sub-intent output by the large language model to obtain the overall confidence score, and when the overall confidence score is lower than a preset threshold, trigger multiple rounds of clarification dialogue, and re-send the context of the user's reply into the large language model for parsing until the overall confidence score reaches the target or the preset number of clarification rounds is reached. S2, the parsed user intent and API description are mapped to the same embedding space through a shared encoder to calculate semantic similarity, and combined with the reliability weights of each API node obtained from the API capability graph for comprehensive ranking, and the matching API node is retrieved from the vector index library; S3, based on the retrieved API nodes, constructs an initial directed graph by combining intent logic dependencies and API data dependencies. After redundancy pruning, parallel route identification, and topology sorting verification, it generates an executable directed acyclic graph workflow. S4. Schedule and execute API nodes according to the topological order of the directed acyclic graph workflow. If an API node fails to execute, call the compensation operations of the successfully registered API nodes in reverse topological order. S5. When an API node in the workflow fails to execute, a breadth-first search is used to determine the set of affected downstream nodes. After filtering out the failed APIs, the search is repeated. The workflow is regenerated only for the affected subgraphs, and a format conversion node is inserted to connect the existing execution results. S6 collects and aggregates the execution results of each node in topological order, and updates the reliability weight of the corresponding API node in the API capability graph using an exponential moving average formula based on the success or failure of this execution.

2. The method according to claim 1, characterized in that, The confidence aggregation calculation in S1 is performed using a weighted summation method, and its mathematical expression is as follows: ； in It is the confidence score of the i-th sub-intent field. The preset weight is the weight corresponding to the i-th sub-intent field.

3. The method according to claim 1, characterized in that, The scoring function of the comprehensive ranking in S2 ; in The cosine similarity function is used. and These are the intent vector and the API description vector, respectively. For balance coefficient, The reliability weight is persistently stored using the API identifier as the key, with an initial value of 1.

0.

4. The method according to claim 1, characterized in that, The parallel route identification in S3 includes: identifying API node pairs that have no path relationship and no resource contention, determining that they can be executed in parallel, and inserting virtual nodes representing the start of parallel branches in the directed acyclic graph. and virtual nodes representing the convergence of parallel branches ; and inserting conditional route virtual nodes carrying JSONPath conditional expressions. It is used to select the execution path based on the output data of the predecessor node at runtime.

5. The method according to claim 1, characterized in that, S4 specifically includes: Maintain a transaction log entry for each API node to record the correspondence between forward operations and compensation operations. Update the status after a node executes successfully, and trigger the compensation process when a node fails to execute. Traverse the transaction log in reverse order and call the compensation operation in reverse topology order.

6. The method according to claim 1, characterized in that, In step S4, for a node that fails to execute, if the API node is marked as idempotent, an exponential backoff strategy is adopted for retrying, with a maximum of 3 retries and a waiting time sequence of 1 second, 2 seconds, and 4 seconds; if a non-idempotent API node fails to call, it is directly marked as failed and a compensation process is triggered without retrying.

7. The method according to claim 1, characterized in that, In S5, the breadth-first search uses a forward traversal method to determine the set of all downstream nodes that directly or indirectly depend on the failed nodes; the format conversion nodes are automatically inserted based on the data type compatibility matrix, which contains the mapping relationship between JSON to XML conversion and basic numeric type conversion.

8. The method according to claim 1, characterized in that, The formula for the exponential moving average in S6 is as follows: ; in The attenuation coefficient is... This is the success label, set to 1 when the node executes successfully and 0 when it fails. and These are the reliability weights before and after the update, respectively. The updated reliability weights are persisted using Redis's hash table command.

9. The method according to claim 1, characterized in that, The method also includes setting up manual confirmation mechanisms at the following key decision points: displaying the parsing results to the user and requesting confirmation after the intent parsing is completed; displaying intermediate results and requesting confirmation after parallel nodes with no data dependencies have been executed; and generating an operation draft and requesting the user to review and confirm it before calling an API with a preset significant impact.

10. A cross-system dynamic workflow orchestration system based on user intent recognition, characterized in that, The system is used to perform the method according to any one of claims 1-9, and the system comprises: An intent recognition module, used to perform S1, includes at least a large language model parsing engine, a confidence aggregator, and a multi-turn clarification dialogue manager; The API semantic alignment module, used to perform S2, includes at least a shared language encoder, a vector index library, and an API capability graph maintainer. The workflow generation module, used to execute S3, includes at least an initial graph builder, a redundancy pruner, a parallel route identifier, and a topology sorting verifier. The execution engine module, used to execute S4, includes at least an execution scheduler, a compensation transaction manager, and a real-time status monitoring unit. An adaptive replanning module, used to perform S5, includes at least an influence domain analyzer, an alternative API retriever, a local DAG generator, and an interface aligner. The result aggregation module is used to perform S6, and it includes at least a result collector and aggregator, an execution report generator, and an API capability graph updater.

Images