Visual AI workflow arrangement method and system

Abstract

The invention discloses a visual AI workflow arrangement method and system, and the method comprises the steps: building a task dependence flow graph through extracting a manufacturing industry application scene demand and combining with a cue word template library, and determining a low-code arrangement standard; the AI node type is identified, the coupling strength between the nodes is detected, and a dynamic workflow topological graph is generated; multi-model interface configuration parameters are obtained, capacity matching is carried out, a scheduling opportunity atlas is formed through difference compensation factors, and multi-model collaborative scheduling is achieved; determining a dynamic analysis trigger condition based on the execution bottleneck position, identifying a failure node, performing path reconstruction, and generating a self-adaptive execution sequence; node execution efficiency analysis is carried out through manufacturing industry application verification, a graphical node library is constructed, and drag-and-drop arrangement interface data is generated. According to the method, the arrangement threshold of the AI workflow is reduced, the multi-model cooperation efficiency is improved, and the adaptive optimization capability of the workflow is enhanced.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence application technology, and in particular to a visual AI workflow orchestration method and system. Background Technology

[0002] As the intelligent transformation of the manufacturing industry deepens, more and more enterprises are beginning to apply AI technologies such as large language models to production scenarios such as intelligent quality inspection, predictive maintenance, and process optimization. However, these AI applications often involve the combination and arrangement of multiple task nodes, including data collection, model inference, result analysis, and process control, with complex data dependencies and control flow relationships between different nodes. Traditional AI workflow construction methods rely on professional algorithm engineers manually writing code, which is not only time-consuming and costly but also lacks flexibility and makes it difficult to quickly respond to changes in business needs.

[0003] While existing workflow orchestration tools offer some visualization capabilities, they still have significant shortcomings in AI task orchestration. These tools are primarily geared towards general business processes and lack node classification and orchestration specifications tailored to the characteristics of AI tasks, resulting in chaotic workflow structures that are difficult to maintain. Regarding multi-model scheduling, existing technologies generally do not support the collaborative scheduling of multiple large language models, and cannot dynamically allocate resources based on model capability differences and load conditions, easily leading to performance bottlenecks. More importantly, once a workflow is deployed and running, it remains fixed and cannot be adjusted at runtime based on bottleneck locations and failure scenarios during execution, lacking adaptive optimization capabilities.

[0004] Therefore, a method is urgently needed to solve at least one of the above problems. Summary of the Invention

[0005] This invention discloses a visual AI workflow orchestration method and system, aiming to achieve intelligent scheduling and load balancing of multiple models by establishing low-code orchestration standards and unified proxy layer rules; to generate adaptive execution sequences by dynamically analyzing execution bottlenecks and reconstructing runtime paths; and to lower the orchestration threshold of AI workflows by building a graphical node library and drag-and-drop orchestration interface, enabling business personnel to quickly build, deploy, and optimize AI application workflows in manufacturing scenarios without writing code, providing efficient, flexible, and easy-to-use orchestration services for applications such as intelligent quality inspection and predictive maintenance.

[0006] The first aspect of this invention proposes a visual AI workflow orchestration method, comprising the following steps: Obtain application scenario requirements and prompt word template library resources in the manufacturing industry, extract task logic dependencies through the application scenario requirements, and establish a low-code orchestration standard using the task logic dependencies and the prompt word template library resources. The AI ​​node type is identified using the low-code orchestration standard. The coupling strength between data flow and control flow between nodes is detected according to the AI ​​node type. The coupling strength is used to generate a dynamic workflow topology graph. The node orchestration priority table is determined based on the dynamic workflow topology graph. Obtain multi-model interface configuration parameters and unified proxy layer rules, perform model capability matching detection based on the unified proxy layer rules to generate a model allocation scheme, and perform collaborative analysis of the multi-model interface configuration parameters and the model allocation scheme to form multi-model proxy scheduling attributes; Based on the node orchestration priority table and the multi-model agent scheduling attributes, the execution bottleneck location is identified, the execution bottleneck location is used to determine the dynamic parsing trigger condition, and the dynamic parsing trigger condition is used to adjust the workflow structure during runtime to generate an adaptive execution sequence. The adaptive execution sequence is used to verify manufacturing applications and generate quality inspection response data and maintenance response data. Node execution efficiency analysis is performed on the quality inspection response data and maintenance response data to generate an orchestration optimization scheme. A graphical node library is constructed using the orchestration optimization scheme. Based on the graphical node library, drag-and-drop orchestration interface data is generated to complete the visualized AI workflow orchestration service.

[0007] A second aspect of this invention provides a visual AI workflow orchestration system, comprising: The requirement parsing module is used to obtain the application scenario requirements and prompt word template library resources of the manufacturing industry, extract the task logic dependency relationship through the application scenario requirements, and establish a low code orchestration standard using the task logic dependency relationship and the prompt word template library resources. The topology building module is used to identify AI node types using the low-code orchestration standard, detect the coupling strength between data flow and control flow according to the AI ​​node types, generate a dynamic workflow topology graph using the coupling strength, and determine a node orchestration priority table based on the dynamic workflow topology graph. The proxy scheduling module is used to obtain multi-model interface configuration parameters and unified proxy layer rules, perform model capability matching detection based on the unified proxy layer rules to generate a model allocation scheme, and perform collaborative analysis of the multi-model interface configuration parameters and the model allocation scheme to form multi-model proxy scheduling attributes. The dynamic parsing module is used to identify execution bottleneck locations based on the node orchestration priority table and the multi-model agent scheduling attributes, determine dynamic parsing trigger conditions using the execution bottleneck locations, and use the dynamic parsing trigger conditions to adjust the workflow structure during runtime to generate an adaptive execution sequence. The interface generation module is used to generate quality inspection response data and maintenance response data by performing manufacturing application verification using the adaptive execution sequence, analyze the node execution efficiency of the quality inspection response data and the maintenance response data to generate an orchestration optimization scheme, construct a graphical node library using the orchestration optimization scheme, generate drag-and-drop orchestration interface data based on the graphical node library, and complete the visual AI workflow orchestration service.

[0008] The beneficial effects of this invention are reflected in the following aspects: First, regarding the standardization and fault tolerance mechanism of workflow orchestration, the requirements of manufacturing application scenarios are transformed into a task-dependent flowchart, clarifying four core rules: sequence constraints, data dependency constraints, condition constraints, and parallel constraints. By identifying AI node types and detecting the coupling strength of data flow and control flow between nodes, functionally equivalent redundant branches are identified in the dependency analysis path and marked as fault-tolerant backup nodes, constructing a dynamic workflow topology graph containing primary execution nodes and backup nodes. This mechanism avoids workflow structure chaos and node connection errors, automatically switching to backup nodes to continue execution when the primary node fails, improving the standardization and reliability of orchestration. Second, for the multi-model collaborative scheduling problem, a difference compensation factor is introduced to quantify the capability differences of different models. Load matching is performed based on the compensation factor to form a load balancing metric, and a scheduling timing graph is generated through time window interpolation. The load ratio of the primary and backup models is dynamically adjusted during peak periods, and only the primary selected model is used during off-peak periods, achieving smooth scheduling switching across time windows. This mechanism rationally allocates the load of primary and backup models based on actual request volume, avoiding concurrency bottlenecks caused by a single model. When the response time of the primary model exceeds a threshold or the error rate is too high, it automatically increases the load ratio of the backup model or switches to the backup model, improving the workflow's concurrent processing capability and overall availability. Finally, it achieves adaptive optimization and low-threshold orchestration of the workflow. When the node waiting time or execution time exceeds the trigger threshold, it automatically generates adjustment requirements and restructures the path, switches nodes that fail to call the model to the backup model, and splits nodes with high computational complexity into parallel subtasks. AI nodes are classified into five types: data acquisition, model invocation, prompt word engineering, logical judgment, and data storage, and each type of node is configured with differentiated display attributes and interactive response mappings. The interface supports auxiliary functions such as automatic node alignment, connection point prompts, and data type compatibility checks, enabling business users to quickly build workflows through drag-and-drop operations, lowering the orchestration threshold for AI applications. Attached Figure Description

[0009] The accompanying drawings illustrate specific examples of the technical solutions described in this invention and, together with the detailed embodiments, form part of the specification, serving to explain the technical solutions, principles, and effects of this invention.

[0010] Unless otherwise specified or defined, the same reference numerals in different figures represent the same or similar technical features, and different reference numerals may be used to represent the same or similar technical features.

[0011] Figure 1 This is a flowchart illustrating a visual AI workflow orchestration method according to the present invention.

[0012] Figure 2 This is a structural block diagram of a visual AI workflow orchestration system according to the present invention. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0015] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0016] The technical solutions of the embodiments of this application will be described below.

[0017] like Figure 1 As shown, this embodiment of the invention provides a visual AI workflow orchestration method, including the following steps S110-S150: Step S110: Obtain the application scenario requirements and prompt word template library resources of the manufacturing industry, extract the task logic dependencies through the application scenario requirements, and establish a low-code orchestration standard using the task logic dependencies and prompt word template library resources.

[0018] Specifically, we acquire application scenario requirements and prompt word template library resources from the manufacturing industry. We collect business requirement documents for typical application scenarios such as intelligent quality inspection, predictive maintenance, process optimization, and production scheduling from factory business departments. For intelligent quality inspection scenarios, the requirement documents include product defect detection processes, defect classification standards, quality inspection report formats, and rules for handling defective products. For predictive maintenance scenarios, the requirement documents include equipment data acquisition requirements, fault prediction models, maintenance plan generation rules, and spare parts inventory management processes. We organize the requirement documents for each scenario, extracting key business processes, input / output requirements, execution conditions, and exception handling rules to form a structured application scenario requirement description. We acquire prompt word template library resources from the AI ​​model service platform. The template library contains prompt word templates, parameter configurations, and calling interfaces for large language models. For intelligent quality inspection scenarios, the template library resources include image description generation templates, defect classification templates, report summary generation templates, and process triggering templates. For predictive maintenance scenarios, the template library resources include data analysis templates, anomaly detection templates, fault prediction templates, and maintenance suggestion generation templates. The prompt word templates in the prompt word template library are categorized according to their functional type, including data processing, analysis and judgment, content generation, and flow control. The input parameters, output format, and calling method of each template are recorded to build a complete prompt word template library resource index.

[0019] Task logical dependencies are extracted based on application scenario requirements. The business process of the intelligent quality inspection scenario is analyzed to identify key task nodes and dependencies between tasks. The intelligent quality inspection scenario includes four core tasks: image acquisition, defect identification, report generation, and process triggering. The image acquisition task is the starting node, with no prerequisites, and outputs product image data. The defect identification task depends on the output of the image acquisition task, outputting defect type and location information. The report generation task depends on the output of the defect identification task, outputting a formatted quality inspection report. The process triggering task depends on the output of the report generation task, determining whether to trigger the defective product handling process based on the severity of the defect. The extracted task logical dependencies are: image acquisition → defect identification → report generation → process triggering, forming a linear dependency chain. Based on application scenario requirements, the business process of the predictive maintenance scenario is analyzed to identify dependencies including data acquisition, data preprocessing, anomaly detection, fault prediction, and maintenance plan generation tasks. The data acquisition task serves as the starting node. The data preprocessing task depends on the data acquisition task. The anomaly detection and fault prediction tasks both depend on the data preprocessing task but can be executed in parallel. The maintenance plan generation task depends on the outputs of both the anomaly detection and fault prediction tasks. The task logic dependencies for each scenario are extracted, and the data transfer direction, execution conditions, and synchronization points between tasks are marked. The convergence nodes and conditional branch judgment logic of parallel tasks are recorded, providing a basis for establishing workflow orchestration rules in the future.

[0020] In some embodiments, establishing a low-code orchestration standard using the task logic dependency relationship and the prompt word template library resources includes: generating a task dependency flowchart based on the task logic dependency relationship; forming a template-task mapping trajectory by combining the prompt word template library resources and the task dependency flowchart; extracting a programmable constraint range within the template-task mapping trajectory; and setting the rules of the programmable constraint range as a low-code orchestration standard.

[0021] A task dependency flowchart is generated based on the logical dependencies between tasks. The tasks in the intelligent quality inspection scenario are converted into a graph structure representation, with graph nodes representing tasks and directed edges representing the dependencies between tasks. A starting node `node_image_capture` is created for the image acquisition task, a node `node_defect_detection` for the defect detection task, a node `node_report_generation` for the report generation task, and a node `node_process_trigger` for the process triggering task. A directed edge is created between `node_image_capture` and `node_defect_detection`, with the edge attributes including data transmission type and execution condition. A directed edge is also created between `node_defect_detection` and `node_report_generation`, labeled with the data transmission type as `defect_info`, which contains defect type and location information. A directed edge is created between `node_report_generation` and `node_process_trigger`, labeled with the execution condition as defect severity threshold judgment. The task dependency flowchart for the intelligent quality inspection scenario is constructed, containing 4 nodes and 3 directed edges. Based on the task logic dependencies, the tasks in predictive maintenance scenarios are transformed into a graph structure, creating data acquisition nodes, data preprocessing nodes, anomaly detection nodes, fault prediction nodes, and maintenance plan generation nodes. Two parallel edges branch off from the data preprocessing node, connecting the anomaly detection node and the fault prediction node respectively. The output edges of these two nodes converge to the maintenance plan generation node. The task dependency flowcharts for each scenario are labeled with the node's task type, input / output data format, execution timeout, and anomaly handling strategy to ensure the graph contains complete task execution information.

[0022] A template-task mapping trajectory is formed by combining the prompt word template library resources and the task dependency flowchart. Each task node in the intelligent quality inspection scenario within the task dependency flowchart is traversed, and a corresponding prompt word template is matched for each task node. For the image acquisition task node `node_image_capture`, the data acquisition class template `template_data_capture` is matched from the prompt word template library resources; this template is responsible for acquiring image data generated by the device. For the defect detection task node `node_defect_detection`, the image analysis class template `template_image_analysis` and the defect classification template `template_defect_classification` are matched from the template library resources; the former describes the image content, and the latter identifies the defect type. For the report generation task node `node_report_generation`, the content generation class template `template_report_generation` is matched from the template library resources to generate a structured quality inspection report based on the defect information. For the process triggering task node `node_process_trigger`, the process control class template `template_condition_judge` is matched; this template determines whether to trigger subsequent processes based on the defect severity. The mapping relationship between each task node and the prompt word template is recorded, and the template calling order and parameter passing method are marked. A template-task mapping trajectory for the intelligent quality inspection scenario is constructed, described as: template_data_capture→template_image_analysis→template_defect_classification→template_report_generation→template_condition_judge. The nodes of the predictive maintenance scenario in the task dependency flowchart are traversed, matching data acquisition templates for data acquisition nodes, data cleaning and feature extraction templates for data preprocessing nodes, anomaly detection templates for anomaly detection nodes, time series prediction templates for fault prediction nodes, and plan generation templates for maintenance plan generation nodes.

[0023] Extract the programmable constraint range within the template-task mapping trajectory. Analyze the mapping trajectory of the intelligent quality inspection scenario, identify the constraint rules of template calls, and form the basic rules for the programmable constraint range. Identify sequence constraints: in the mapping trajectory, `template_data_capture` must be executed before `template_image_analysis`, and `template_image_analysis` must be executed before `template_defect_classification`, ensuring that data flows in the correct order. Identify data dependency constraints: in the mapping trajectory, the input parameters of `template_defect_classification` depend on the output of `template_image_analysis`, and the input parameters of `template_report_generation` depend on the output of `template_defect_classification`; data transfer between templates must meet type matching requirements. Identify condition constraints: in the mapping trajectory, the execution of `template_condition_judge` depends on the judgment result of the conditional expression; subsequent processes are only triggered when the defect severity is greater than the threshold. In the template-task mapping trajectory for predictive maintenance scenarios, `template_anomaly_detection` and `template_fault_prediction` can be executed in parallel, but both must be completed before `template_maintenance_plan`. The execution time of parallel tasks is not affected by each other. The constraint rules identified in each scenario mapping trajectory are integrated, including four core types of constraints: sequence constraints, data dependency constraints, conditional constraints, and parallel constraints, forming a complete orchestratable constraint range.

[0024] Define the rules of the orchestrable constraints as the low-code orchestration standard. Based on the constraint rules in the orchestrable constraints, develop operational guidelines for the visual orchestration interface. Define node drag-and-drop rules: users can drag task nodes from the template library to the canvas, but they must satisfy the order constraints in the orchestrable constraints. Subsequent task nodes will be grayed out and unavailable if no preceding task is added. Define connection rules: users can establish connections between task nodes by dragging and dropping. When establishing connections, the data dependency constraints in the orchestrable constraints are automatically verified. An error message is displayed when the output data type does not match the input data type, and invalid connections are prohibited. Define conditional branch rules: users configure judgment expressions for conditional nodes. Expressions must reference output variables of upstream nodes and support comparison operators, logical operators, and constant values. The configuration interface provides expression syntax checking and auto-completion functions. Define parallel execution rules: users can drag multiple connections from one node to different subsequent nodes to establish a parallel branch structure. The orchestration engine automatically recognizes parallel branches and creates multiple concurrent tasks during execution. The convergence node is triggered only after all parallel tasks are completed. The above operational guidelines are integrated into a low-code orchestration standard document. The orchestration standard includes interface layout guidelines, operation interaction guidelines, constraint verification guidelines, and error message guidelines, providing unified design guidance for the development of visual orchestration tools.

[0025] Step S120: Identify AI node types using low-code orchestration standards, detect the coupling strength between data flow and control flow according to AI node types, generate a dynamic workflow topology map using the coupling strength, and determine the node orchestration priority table based on the dynamic workflow topology map.

[0026] Specifically, low-code orchestration standards are used to identify AI node types. According to the low-code orchestration standards, workflow configuration files created by the user in the visual orchestration interface are read. These configuration files contain template references, parameter settings, and connection relationships for each task node. Based on the node type specifications defined in the low-code orchestration standards, the AI ​​node type of a node is identified by the prompt word template type referenced by the node. Nodes referencing data acquisition templates are identified as data acquisition nodes. Nodes referencing image analysis or text analysis templates are identified as model inference nodes. Nodes referencing classification judgment templates are identified as decision nodes. Nodes referencing content generation templates are identified as content generation nodes. Nodes referencing process control templates are identified as condition control nodes. In the intelligent quality inspection scenario, `node_image_capture` is identified as a data acquisition node, `node_defect_detection` as a combination of a model inference node and a decision node, `node_report_generation` as a content generation node, and `node_process_trigger` as a condition control node.

[0027] Based on AI node type, the coupling strength of data flow and control flow between nodes is detected. According to AI node type, the connection relationships between nodes in the intelligent quality inspection scenario workflow are analyzed to identify data transmission and control dependencies between nodes. The data flow between the data acquisition node `node_image_capture` and the model inference node `node_defect_detection` is detected; the image data output by `node_image_capture` serves as the input to `node_defect_detection`, indicating a data dependency between the two nodes. The data flow between the model inference node `node_defect_detection` and the decision node is detected; the defect identification result serves as the input to the decision node. The data flow between the decision node and the content generation node `node_report_generation` is detected; the `defect_info` data from the decision result is passed to the content generation node. The control flow between the content generation node and the condition control node `node_process_trigger` is detected; when the defect severity in the quality inspection report exceeds a threshold, the condition control node triggers the defective product processing flow. Based on the AI ​​node type, the data flow between the data preprocessing node, anomaly detection node, and fault prediction node in the predictive maintenance scenario is analyzed. The output of the data preprocessing node is simultaneously transmitted to two parallel model inference nodes. The coupling strength between each node pair is calculated. For node pairs with strong data dependencies that cannot be skipped, the coupling strength is set to high; for node pairs with conditional control dependencies, the coupling strength is set to medium; and for node pairs executing in parallel, the coupling strength is set to low.

[0028] In some embodiments, generating a dynamic workflow topology using the coupling strength includes: decomposing the coupling strength into data dependency strength and control dependency strength; constructing a dependency analysis path by combining the data dependency strength and the control dependency strength; identifying redundant execution branches in the dependency analysis path to determine fault-tolerant backup nodes; and selecting the nodes with the highest coupling degree among the fault-tolerant backup nodes to generate a dynamic workflow topology.

[0029] The coupling strength is decomposed into data dependency strength and control dependency strength. Analyzing the coupling strength between `node_image_capture` and `node_defect_detection`, there is image data transfer between the two nodes. `node_defect_detection` must wait for `node_image_capture` to complete before it can execute, and it cannot bypass the data acquisition step. Therefore, the data dependency strength of this node pair is set to strong dependency. Analyzing the coupling strength between `node_defect_detection` and `node_report_generation`, there is defect_info data transfer between the two nodes, but `node_report_generation` can handle empty defect_info (indicating no defects). Therefore, the data dependency strength of this node pair is set to medium dependency. Analyzing the coupling relationship between `node_report_generation` and `node_process_trigger`, there is no data transfer between the two nodes. `node_process_trigger` makes conditional judgments based on the defect severity field in the report. Therefore, the control dependency strength of this node pair is set to conditional dependency. In predictive maintenance scenarios, the coupling strength between data preprocessing nodes, anomaly detection nodes, and fault prediction nodes is analyzed. The output data of the data preprocessing node is transmitted to both nodes simultaneously, but the two nodes can be executed independently. The data dependency strength of both nodes is set to medium dependency, and the control dependency strength is set to no dependency.

[0030] Dependency analysis paths are constructed by combining data dependency strength and control dependency strength. Based on the node dependencies in the intelligent quality inspection scenario, each node is connected in series from the starting node to the ending node according to its data dependency strength and control dependency strength. Starting from the data acquisition node `node_image_capture`, which has no prerequisite dependencies, it serves as the starting point of the dependency analysis path. Based on the strong data dependency strength, `node_defect_detection` is connected to `node_image_capture`, establishing a strong dependency path segment between the two nodes. Based on the medium data dependency strength, `node_report_generation` is connected to `node_defect_detection`. Based on the conditional control dependency strength, `node_process_trigger` is connected to `node_report_generation`, and this path segment is marked as a conditional branch. The dependency analysis path for the intelligent quality inspection scenario is constructed as follows: `node_image_capture` → [Strong dependency] → `node_defect_detection` → [Medium dependency] → `node_report_generation` → [Conditional dependency] → `node_process_trigger`. Based on the node dependencies in a predictive maintenance scenario, a dependency analysis path with parallel branches is constructed. A strong dependency exists between the data acquisition node and the data preprocessing node. Two parallel paths branch off from the data preprocessing node, connecting to the anomaly detection node and the fault prediction node respectively; both paths have a medium data dependency strength. The two parallel paths converge at the maintenance plan generation node, which is marked as a synchronization node in the path.

[0031] For example, the step of identifying redundant execution branches and determining fault-tolerant standby nodes in the dependency analysis path includes: obtaining node execution branches in the dependency analysis path; identifying functionally equivalent redundant branches in the node execution branches; evaluating the fault tolerance capabilities of the redundant branches to generate fault tolerance priority identifiers; and marking the redundant branches as fault-tolerant standby nodes according to the fault tolerance priority identifiers.

[0032] Obtain the execution branches of nodes in the dependency analysis path. Traverse the dependency analysis path of the intelligent quality inspection scenario to identify task nodes with multiple implementation methods. Check the workflow configuration and find that the user has configured two parallel model inference nodes for the defect detection task: node_defect_detection_primary and node_defect_detection_backup. Identify two node execution branches between node_image_capture and node_report_generation, forming a primary and backup execution path structure. Traverse the dependency analysis path of the predictive maintenance scenario and check the workflow configuration. Find that the anomaly detection node is configured with two models, primary and backup, and identify two node execution branches for the anomaly detection task.

[0033] Identify functionally equivalent redundant branches in node execution branches. Analyze two node execution branches for a defect identification task in an intelligent quality inspection scenario, comparing their functional objectives and output results. Branch 1 uses a large visual model for defect identification, outputting defect type, location, and confidence score. Branch 2 uses a traditional image recognition algorithm for defect identification, outputting defect type and location. Comparing the output data formats of the two node execution branches, both output a `defect_info` data structure containing the same defect type and location fields, but Branch 1 additionally includes a confidence score field. The two branches are deemed to have the same functional objective—identifying defects in product images—and compatible output formats, satisfying the functional equivalence condition. Therefore, Branch 1 and Branch 2 are marked as redundant branches. Analyze the primary and backup node execution branches for an anomaly detection task in a predictive maintenance scenario, comparing their functional objectives and output results. The primary branch uses a deep learning model to output anomaly detection results and anomaly scores, while the backup branch uses statistical analysis methods to output anomaly detection results. The two branches are deemed to have the same functional objective and compatible output formats, satisfying the functional equivalence condition. Therefore, the primary and backup branches are marked as redundant branches.

[0034] Evaluate the fault tolerance capabilities of redundant branches and generate fault tolerance priority identifiers. Analyze the fault tolerance characteristics of branch 1 (large visual model). This branch relies on an external large model API service; when the API service is unavailable or times out, branch 1 fails. Analyze the fault tolerance characteristics of branch 2 (traditional algorithm). This branch executes locally, does not rely on external services, and has high availability, but its recognition accuracy is lower than branch 1. Based on the fault tolerance assessment results, assign the fault tolerance priority identifier "main execution branch" to branch 1 and "fault tolerance backup branch" to branch 2. Evaluate the fault tolerance capabilities of the main and backup redundant branches of the anomaly detection task in a predictive maintenance scenario. The main branch (deep learning model) has high detection accuracy but consumes a lot of computational resources and may fail when GPU resources are insufficient. The backup branch (statistical analysis method) consumes fewer computational resources and has high availability, but its detection accuracy is lower than the main branch. Assign the fault tolerance priority identifier "main execution branch" to the main branch and "fault tolerance backup branch" to the backup branch.

[0035] Based on the fault tolerance priority identifier, redundant branches are marked as fault-tolerant backup nodes. The `node_defect_detection_primary` node in branch 1 (large visual model) remains the primary execution node, and is invoked during normal workflow execution. Based on the fault tolerance priority identifier, the `node_defect_detection_backup` node in branch 2 (traditional algorithm) is marked as a fault-tolerant backup node, and is invoked when the primary execution node fails. Fault tolerance switching rules are set for `node_defect_detection_primary` in the workflow configuration; when this node fails or times out, execution automatically switches to the fault-tolerant backup node `node_defect_detection_backup`. Traversing the primary and backup redundant branches of the anomaly detection task in the predictive maintenance scenario, the anomaly detection node in the primary branch remains the primary execution node, and the anomaly detection nodes in the backup branches are marked as fault-tolerant backup nodes based on the fault tolerance priority identifier. Fault tolerance switching rules are set for the primary execution node in the workflow configuration; when GPU resources are insufficient or model loading fails, execution switches to the fault-tolerant backup node.

[0036] A dynamic workflow topology graph is generated by selecting the node combination with the highest coupling degree among the fault-tolerant backup nodes. The node combinations of the main execution path and fault-tolerant path in the intelligent quality inspection scenario are analyzed, and a topology structure including the main node and fault-tolerant backup nodes is constructed. `node_image_capture` is used as the starting node and connected to the main execution node `node_defect_detection_primary` and the fault-tolerant backup node `node_defect_detection_backup`, with the two nodes having a mutually exclusive execution relationship. Both `node_defect_detection_primary` and `node_defect_detection_backup` are connected to `node_report_generation`, forming two convergence paths. The coupling degree of the main execution path is calculated: `node_image_capture` and `node_defect_detection_primary` have a strong data dependency, and `node_defect_detection_primary` and `node_report_generation` have a medium data dependency, indicating a high overall coupling degree of the main execution path. The coupling degree of the fault-tolerant path is calculated. There is a strong data dependency between `node_image_capture` and `node_defect_detection_backup`, and a medium data dependency between `node_defect_detection_backup` and `node_report_generation`. The overall coupling degree of the fault-tolerant path is comparable to that of the main path. A node combination containing the main execution node and a highly coupled fault-tolerant backup node is selected to construct a dynamic workflow topology graph for the intelligent quality inspection scenario. The main execution node and fault-tolerant backup node in the predictive maintenance scenario are combined to construct a topology graph containing parallel branches and fault-tolerant paths.

[0037] A node orchestration priority table is determined based on the dynamic workflow topology graph. Based on the dynamic workflow topology graph of the intelligent quality inspection scenario, the position and dependencies of each node in the workflow are analyzed, and the orchestration priority of the nodes is calculated. The starting node `node_image_capture` is set to the highest priority (priority value 1), this node has no prerequisites and can be executed immediately. The main execution node `node_defect_detection_primary` is set to the second highest priority (priority value 2), this node depends on the output of the starting node and executes immediately after the starting node completes. The fault-tolerant backup node `node_defect_detection_backup` is set to the same priority value 2 as the main execution node, but marked as backup. The content generation node `node_report_generation` is set to a priority value of 3, this node depends on the output of the defect identification node. The condition control node `node_process_trigger` is set to a priority value of 4, this node depends on the output of the report generation node. Based on the topology graph of the predictive maintenance scenario, the orchestration priority of nodes containing parallel branches is calculated. The data acquisition node is assigned priority value 1, the data preprocessing node is assigned priority value 2, the anomaly detection node and the fault prediction node are both assigned priority value 3 and marked as parallel execution, and the maintenance plan generation node is assigned priority value 4 and marked as a synchronization node. A node orchestration priority table is constructed for each scenario, containing the node name, priority value, execution status, and dependencies.

[0038] Step S130: Obtain multi-model interface configuration parameters and unified proxy layer rules; perform model capability matching detection based on unified proxy layer rules to generate a model allocation scheme; and conduct collaborative analysis of multi-model interface configuration parameters and model allocation scheme to form multi-model proxy scheduling attributes.

[0039] Specifically, the system retrieves multi-model interface configuration parameters and unified proxy layer rules. It reads the list of integrated large language models and their interface configuration information from the platform configuration file. This configuration information includes the model service provider name, API endpoint address, authentication key, request format, and response format. For OpenAI models, it reads the API endpoint address, authentication method (BearerToken), and supported capabilities including text generation, image understanding, and function calls. For the Wenxin Yiyan model, it reads the model server endpoint address, authentication method (AccessToken), and supported capabilities including text generation and dialogue understanding. For the Tongyi Qianwen model, it reads the model server endpoint address, authentication method (APIKey), and supported capabilities including text generation and multi-turn dialogue. It records the interface protocol version, maximum input token count, maximum output token count, concurrent request limits, and billing methods for each model, compiling these into a multi-model interface configuration parameter table. The system reads the unified proxy layer rules from the platform configuration. These rules define the priority strategy, load balancing strategy, and fault tolerance switching strategy for model selection. The priority strategy of the unified proxy layer rules stipulates that for image analysis tasks, models supporting visual understanding capabilities are prioritized, and for text generation tasks, models with high generation quality are prioritized. The load balancing strategy stipulates that when multiple models have comparable capabilities, the load should be allocated based on the current load and response speed of each model.

[0040] A model allocation scheme is generated based on model capability matching and detection according to the unified agent layer rules. Each AI node in the intelligent quality inspection scenario workflow is traversed to identify its task type and capability requirements. For the image acquisition node `node_image_capture`, this node is a data acquisition node and does not require calling a large language model, so model allocation is skipped. For the defect detection node `node_defect_detection`, this node needs to analyze product images and classify defects, requiring image understanding and classification capabilities. Based on the priority strategy of the unified agent layer rules, models supporting image understanding capabilities are selected, and OpenAI's GPT-4V model and Wenxin Yiyan's visual understanding model are searched from the multi-model interface configuration parameters. Considering the unified agent layer rules and the requirements of the intelligent quality inspection scenario, GPT-4V is selected as the primary model, and the Wenxin Yiyan visual model is selected as the alternative model, forming the model allocation scheme for the defect detection node. For the report generation node `node_report_generation`, this node needs to generate a structured quality inspection report based on defect information, requiring text generation capabilities. Based on the priority strategy of the unified agent layer rules, models with strong text generation capabilities are selected, with GPT-4 chosen as the primary model and Tongyi Qianwen as the alternative model, thus forming a model allocation scheme for the report generation node.

[0041] In some embodiments, the step of performing collaborative analysis of the multi-model interface configuration parameters and the model allocation scheme to form multi-model agent scheduling attributes includes: performing capability difference analysis on the model allocation scheme to obtain difference compensation factors; performing load matching on the multi-model interface configuration parameters based on the difference compensation factors to form a load balancing metric; generating a scheduling timing map by interpolating the load balancing metric through a time window; and using the scheduling timing map to form multi-model agent scheduling attributes.

[0042] A capability difference analysis was conducted on the model allocation scheme to obtain the difference compensation factor. The primary and backup model configurations for defect identification nodes in the intelligent quality inspection scenario were analyzed. This scheme selects GPT-4V as the primary model and the Wenxin Yiyan visual model as the backup model. Capability parameters of the two models were extracted from the multi-model interface configuration parameters associated with the model allocation scheme. The capability indicators of the primary model GPT-4V are: recognition accuracy 95% and response time 2 seconds. The capability indicators of the backup model Wenxin Yiyan are: recognition accuracy 88% and response time 1 second. The impact of capability differences on task execution was evaluated. The difference in recognition accuracy affects the defect detection rate, and the difference in response time affects the quality inspection efficiency. The difference compensation factor was calculated using the capability ratio method, with the formula: Difference Compensation Factor = Backup Model Capability Value / Primary Model Capability Value. For recognition accuracy, the compensation factor = 88% / 95% = 0.93, indicating that the backup model's capability is 93% of the primary model's. For response time, the compensation factor = 1 second / 2 seconds = 0.5, indicating that the backup model's response speed is twice that of the primary model. The same method was used to analyze the model allocation scheme for the report generation nodes. This scheme selected GPT-4 as the primary model and Tongyi Qianwen as the alternative model. The calculated compensation factor for the difference in generation quality was 0.92, and the compensation factor for response time was 0.67.

[0043] Load balancing metrics are formed by matching the configuration parameters of multiple model interfaces based on the difference compensation factor. The model call demands during peak periods in intelligent quality inspection scenarios are analyzed, and load data is extracted from workflow execution logs. Statistics show that the defect identification node calls 100 times per minute during peak periods, requiring the processing of 100 product images. Concurrency limits are queried from the multi-model interface configuration parameters: the primary model GPT-4V has a concurrency limit of 60 times per minute, and the alternative model Wenxin Yiyan has a concurrency limit of 80 times per minute. The load when using the primary model alone is calculated; 100 requests exceed the 60-times concurrency limit, and the excess 40 requests will be queued. The feasibility of enabling the alternative model is evaluated based on the difference compensation factor. According to the recognition accuracy difference compensation factor of 0.93, the alternative model meets the quality inspection accuracy requirements. Load allocation is calculated using the capacity allocation method, with the formula: Primary model load = min(total requests, primary model concurrency limit), Alternative model load = total requests - primary model load. The calculated load for the primary model is min(100,60) = 60 calls, and the load for the alternative model is 100 - 60 = 40 calls, resulting in a load ratio of 6:4. This forms the load balancing metric for the defect identification node, with the primary model handling 60% of the load and the alternative model handling 40%. The same method is used to analyze the report generation node, which makes 50 calls per minute. The GPT-4 concurrency limit of 40 calls and the Tongyi Qianwen concurrency limit of 60 calls are extracted from the multi-model interface configuration parameters. Combined with a difference compensation factor of 0.92, the primary model is calculated to handle 40 calls and the alternative model 10 calls, forming the load balancing metric for the report generation node.

[0044] A scheduling timing graph is generated by interpolating load balancing metrics using time windows. The time window granularity is set to 1 minute, and model call requests for the intelligent quality inspection scenario are collected for each time window within a 24-hour period. Task arrival rates for each time window are statistically analyzed from workflow execution logs, revealing high arrival rates during 8:00-12:00 and 14:00-18:00, and low arrival rates during other times. Load balancing metric data for defect identification nodes in each time window is extracted. During peak hours, the load ratio of the primary to backup models is 6:4, while during off-peak hours, the primary model handles all requests independently. Interpolation is applied to the load balancing metric data for each time window. 30 minutes before the start of the peak period, the load ratio of the backup model is gradually increased, smoothly transitioning from 0% to 40%, avoiding service fluctuations caused by sudden switching. 30 minutes after the end of the peak period, the load ratio of the backup model is gradually decreased, smoothly transitioning from 40% to 0%. A scheduling timing graph for the defect identification node was constructed, with the horizontal axis representing a 24-hour timeframe and the vertical axis representing the load ratio of each model. The graph marked the scheduling strategies for different time periods. From 7:30 to 12:30, the load ratio of the primary model GPT-4V decreased from 100% to 60%, while the load ratio of the backup model Wenxin Yiyan increased from 0% to 40%. From 12:30 to 13:30, the load ratio of the primary model increased back to 100% from 60%, while the load ratio of the backup model decreased from 40% to 0%. A scheduling timing graph for the report generation node was also constructed, marking the changes in the load ratio of the primary and backup models for each time period.

[0045] Multi-model proxy scheduling attributes are formed using scheduling timing graphs. Based on the scheduling timing graphs of each node in the intelligent quality inspection scenario, model scheduling configurations for the proxy layer are constructed. Scheduling attributes are configured for the defect identification node, setting the primary model as GPT-4V, the backup model as Wenxin Yiyan visual model, and the scheduling strategy as dynamic load balancing. Scheduling timing parameters are configured according to the scheduling timing graph, enabling the backup model to share the load during the two time periods of 7:30-12:30 and 13:30-18:30, with the load ratio of the primary and backup models dynamically adjusted according to the graph. Switching conditions are configured: when the response time of the primary model exceeds 5 seconds or the error rate exceeds 5%, the load ratio of the backup model is automatically increased. Scheduling attributes are configured for the report generation node, setting the primary model as GPT-4V, the backup model as Tongyi Qianwen, and the scheduling strategy as prioritizing the primary model. Scheduling timing parameters are configured: during peak hours, the backup model is enabled to share 20% of the load, while during off-peak hours, only the primary model is used. Configure fault-tolerant switching parameters so that when the primary model fails, it immediately switches to the backup model to continue execution, with a switching delay of no more than 100 milliseconds. Integrate the scheduling attributes of each node, including model selection strategy, load distribution ratio, time window parameters, and switching conditions, to build a complete multi-model proxy scheduling attribute configuration file. Deploy the scheduling attribute configuration file to the proxy layer service. The proxy layer dynamically selects and schedules models at runtime based on the configuration, achieving collaborative work and load balancing among multiple models.

[0046] Step S140: Identify execution bottleneck locations based on node orchestration priority table and multi-model agent scheduling attributes; determine dynamic parsing trigger conditions using execution bottleneck locations; and use dynamic parsing trigger conditions to adjust the workflow structure during runtime to generate an adaptive execution sequence.

[0047] Specifically, execution bottlenecks are identified based on node orchestration priority tables and multi-model proxy scheduling attributes. Real-time operational data for the intelligent quality inspection scenario is obtained from the workflow execution monitoring service. This data includes the execution time, waiting time, success rate, and resource utilization of each node. Analyzing the execution of the defect detection node `node_defect_detection` reveals an average execution time of 2.5 seconds, with an average waiting time of 3 seconds during peak hours. Comparing this to the node orchestration priority table, this node has a priority value of 2. According to the priority table definition, this node should execute immediately after image acquisition, but the excessively long waiting time indicates execution delay. Analyzing the model scheduling configuration of this node in the multi-model proxy scheduling attributes shows that the primary model GPT-4V has a 60% load ratio during peak hours, with a concurrent request limit of 60 requests per minute. Statistical analysis of the actual request arrival rate reveals that 100 requests arrive per minute during peak hours, exceeding the concurrent processing capacity of the primary model configured in the multi-model proxy scheduling attributes. The defect detection node is identified as the execution bottleneck, caused by insufficient model concurrency leading to request queuing. The execution status of the report generation node was analyzed. Comparing its priority value of 3 in the node orchestration priority table, the execution efficiency met expectations. Traversing all nodes in the predictive maintenance scenario, the execution status of the data preprocessing node was analyzed. This node's average execution time was 8 seconds, significantly higher than other nodes with the same priority in the priority table. The data preprocessing node was identified as the execution bottleneck, caused by the high complexity of data processing.

[0048] Dynamic parsing trigger conditions are determined by identifying execution bottleneck locations. Analysis of the execution bottleneck characteristics of the defect identification node in the intelligent quality inspection scenario reveals that the bottleneck is characterized by insufficient concurrency, and its severity is related to the request arrival rate. Historical data analysis shows that when the request arrival rate exceeds 80 requests per minute, the node's waiting time at this bottleneck location exceeds 2 seconds; when the request arrival rate exceeds 100 requests per minute, the node's waiting time exceeds 3 seconds. Dynamic parsing trigger conditions are set: when the waiting time of the defect identification node exceeds 2 seconds, a load adjustment mechanism is triggered, increasing the load ratio of the alternative model (e.g., "Wenxin Yiyan"). When the waiting time exceeds 3 seconds, an emergency adjustment mechanism is triggered, increasing the load ratio of the alternative model to 50%. Analysis of the execution bottleneck characteristics of the data preprocessing node reveals that the bottleneck is characterized by high computational complexity, and its severity is related to the amount of input data. Historical data analysis shows that when the input data volume exceeds 10,000 records, the node's execution time exceeds 10 seconds; when the input data volume exceeds 50,000 records, the node's execution time exceeds 30 seconds. A dynamic parsing trigger condition is set. When the execution time of the data preprocessing node exceeds 10 seconds, a parallel processing mechanism is triggered to split the dataset into multiple subsets for parallel processing. When the execution time exceeds 30 seconds, a sampling processing mechanism is triggered to sample the dataset and reduce the processing load.

[0049] In some embodiments, the step of using the dynamic parsing trigger conditions to adjust the workflow structure during runtime and generate an adaptive execution sequence includes: detecting changes in the workflow structure based on the dynamic parsing trigger conditions to obtain node adjustment requirements; identifying failed nodes in the node adjustment requirements and generating failed node markers; using the failed node markers to perform path reconstruction analysis to generate optimized path configurations; and generating an adaptive execution sequence based on the optimized path configurations.

[0050] The workflow structure is changed based on dynamic parsing trigger conditions to obtain node adjustment requirements. During workflow execution, the execution status and performance indicators of each node are monitored in real time and compared with the dynamic parsing trigger conditions. In the intelligent quality inspection scenario, the waiting time of the defect identification node is detected to be 3.2 seconds, exceeding the 3-second trigger threshold set by the dynamic parsing trigger conditions, thus triggering an emergency adjustment mechanism. Based on the adjustment strategy of the trigger conditions, the current configuration of this node is analyzed: the load ratio of the primary model GPT-4V is 60%, and the load ratio of the alternative model Wenxin Yiyan is 40%. A node adjustment requirement is generated, requiring the load ratio of the alternative model to be increased to 50% to alleviate the concurrent pressure on the primary model. The execution time of the data preprocessing node is detected to be 12 seconds, exceeding the 10-second trigger threshold set by the dynamic parsing trigger conditions, thus triggering a parallel processing mechanism. Based on the adjustment strategy of the trigger conditions, the current configuration of this node is analyzed: the node is in single-threaded serial processing mode, and the input data volume is 15,000 records. The node generation needs adjustment, requiring switching the node to parallel processing mode, splitting the dataset into three subsets, each containing 5,000 records, and assigning them to three parallel processing tasks. The report generation node's response time was detected to be normal, and the dynamic parsing trigger condition was not triggered; therefore, no adjustment is required.

[0051] In the node adjustment request process, identify and generate failure node tags. During workflow execution, monitor the execution results of each node and identify failure nodes, including various failure scenarios such as execution anomalies, timeouts, and service unavailability. Analyze the execution status of each node's adjustment request and check whether the adjustment operation was successfully completed. For example, in the intelligent quality inspection scenario, a node adjustment request for the defect identification node was detected to have failed. This request required increasing the load ratio of the alternative model to 50%, but the primary model GPT-4V call failed due to model service timeout. This node was identified as a failure node, and a failure node tag was generated, containing the node name, failure reason, failure timestamp, and number of failures. If the primary model fails three times consecutively within 5 minutes, it is considered a serious fault, and the severity of the failure node tag is set to high. Similarly, a node adjustment request for the report generation node was detected to have failed due to API key authentication failure. This node was identified as a failure node, and a failure node tag was generated with a severity set to medium. An anomaly was detected in the execution of a node adjustment request for a fault prediction node in a predictive maintenance scenario. The node execution timed out, exceeding 60 seconds without completion. This node is identified as a failed node, a failed node marker is generated, and the marker severity is set to medium.

[0052] Path reconstruction analysis using failure node markers generates optimized path configurations. Analyzing the failure node markers of the defect identification node in an intelligent quality inspection scenario, the primary model GPT-4V for this node failed three consecutive times. Based on the high severity of the failure node markers, it was determined that an immediate switch in execution path was necessary. Checking the fault tolerance configuration of this node, a backup model, node_defect_detection_backup, was found to be available for fault tolerance switching. Path reconstruction analysis was performed, switching the primary execution path from node_image_capture→node_defect_detection_primary→node_report_generation to node_image_capture→node_defect_detection_backup→node_report_generation. The performance of the switched path was evaluated. The recognition accuracy of the backup model, Wenxin Yiyan, was 88%, lower than the primary model's 95%, but its response time was 1 second, faster than the primary model's 2 seconds. An optimized path configuration was generated, temporarily adjusting the model scheduling strategy of the defect identification node to prioritize the use of the backup model. The analysis report identifies a failed node marker for the generated node. The failure was attributed to API key authentication failure, which, based on the marker's type, indicates a configuration error. Path reconstruction analysis is performed, temporarily disabling the primary model GPT-4 and switching the execution path to the alternative model, Tongyi Qianwen. An optimized path configuration is generated, setting the alternative model as the sole execution path. The analysis also identifies a failed node marker for the fault prediction node. This node timed out, and the failure was determined to be due to excessive input data volume. Path reconstruction analysis is performed, adjusting the serial execution path to a parallel execution path. An optimized path configuration is generated, configuring the parallelism to 3, splitting the input data into three parts for separate processing.

[0053] An adaptive execution sequence is generated based on the optimized path configuration. Based on the optimized path configuration for the intelligent quality inspection scenario, the workflow execution sequence is regenerated. According to the path switching scheme of the optimized path configuration, the execution strategy of the defect identification node is adjusted to prioritize the use of the backup model `node_defect_detection_backup`, constructing a new adaptive execution sequence: `node_image_capture` (priority 1) → `node_defect_detection_backup` (priority 2) → `node_report_generation` (priority 3) → `node_process_trigger` (priority 4). The execution status of nodes is marked in the execution sequence: `node_defect_detection_primary` is marked as paused, and `node_defect_detection_backup` is marked as the primary execution state. A health check mechanism is configured to check the availability of `node_defect_detection_primary` every 5 minutes. When the node recovers, the load is gradually switched back to the primary model GPT-4V according to the recovery strategy. Based on the optimized path configuration for the predictive maintenance scenario, an adaptive execution sequence containing parallel execution is generated. Based on the parallelism settings configured in the path, the fault prediction node is split into three parallel subtasks. These three subtasks execute in parallel, and the results are aggregated at the synchronization node before being passed to the maintenance plan generation node. A timeout protection mechanism is configured in the sequence, with each subtask having an execution timeout of 20 seconds. After the timeout, the subtask is terminated and a partial result is returned. The new adaptive execution sequences generated for each scenario are deployed to the workflow engine. The workflow engine schedules task execution according to the sequence, achieving dynamic adaptation and self-optimization of the workflow.

[0054] Step S150: Adaptive execution sequence is used to verify manufacturing applications and generate quality inspection response data and maintenance response data. Node execution efficiency analysis is performed on the quality inspection response data and maintenance response data to generate an orchestration optimization scheme. A graphical node library is built using the orchestration optimization scheme. Based on the graphical node library, drag-and-drop orchestration interface data is generated to complete the visualized AI workflow orchestration service.

[0055] In some embodiments, the step of generating quality inspection response data and maintenance response data by using the adaptive execution sequence for manufacturing application verification includes: assigning tasks to the adaptive execution sequence to generate quality inspection execution instructions; using the quality inspection execution instructions to trigger multi-model parallel detection to generate multiple quality inspection results; extracting the detection output with the highest confidence from the multiple quality inspection results to form quality inspection response data; and performing equipment status correlation analysis based on the quality inspection response data to generate maintenance response data.

[0056] Task assignment and quality inspection execution instructions are generated for the adaptive execution sequence. The node definitions in the adaptive execution sequence configuration of the intelligent quality inspection scenario are extracted. This sequence includes the execution order of image acquisition nodes, defect identification nodes, report generation nodes, and process triggering nodes. Tasks are assigned to the corresponding execution nodes based on the priority and dependencies of each node in the execution sequence. The image acquisition task is assigned to the `node_image_capture` node, generating image acquisition instructions. The defect identification task is assigned to the `node_defect_detection_backup` node; according to the sequence configuration, this node uses the Wenxin Yiyan visual model as the main execution model. Quality inspection execution instructions are generated, including the detection model identifier, input image path, defect classification criteria, and confidence threshold. The report generation task and process triggering task are assigned to their respective nodes, generating corresponding execution instructions.

[0057] The process utilizes quality inspection execution commands to trigger parallel multi-model detection, generating multiple quality inspection results. The workflow engine receives product image data returned by the image acquisition node and, according to the configuration of the quality inspection execution commands, distributes the image data to multiple defect recognition models for parallel detection. The image data is sent to the main execution model, the Wenxin Yiyan visual model, which analyzes and identifies defects based on the defect classification criteria in the command. The Wenxin Yiyan model returns detection result 1, containing a defect type of "welding porosity," defect location coordinates (256, 384), defect area of ​​32 square pixels, and a confidence level of 0.89. The same image data is then sent to the backup model, GPT-4V, which returns detection result 2, containing a defect type of "welding porosity," defect location coordinates (258, 385), defect area of ​​35 square pixels, and a confidence level of 0.92. Finally, the image data is sent to the traditional image recognition algorithm model, which returns detection result 3, containing a defect type of "welding defect," defect location coordinates (255, 383), defect area of ​​30 square pixels, and a confidence level of 0.76. The detection results returned by the three models are combined to form a multi-channel quality inspection result set.

[0058] The highest-confidence inspection output from multiple inspection results is extracted to form the quality inspection response data. The three inspection records in the multi-channel inspection result set are traversed, and the confidence scores of each record are compared. The confidence score of inspection result 1 is 0.89, that of inspection result 2 is 0.92, and that of inspection result 3 is 0.76. The inspection record with the highest confidence score is identified as inspection result 2, which was generated by the GPT-4V model. Detailed information for this inspection record is extracted, including the defect type "welding porosity," defect location coordinates (258, 385), and defect area of ​​35 square pixels. The extracted inspection results are formatted, converting the defect location coordinates to the production line coordinate system and the defect area to the actual physical size of 0.7 square millimeters. Quality inspection response data is generated, with a data structure including product number, inspection time, defect type, defect location, defect size, defect severity, and handling recommendation. Based on the defect size and type, the defect severity is calculated as "medium," and the handling recommendation is "rework required."

[0059] Maintenance response data was generated based on equipment status correlation analysis using quality inspection response data. Product number and defect type information were extracted from the quality inspection response data. The product number was P20250131-0856, and the defect type was "welding porosity". The production history database was queried to trace the production process of this product based on the product number in the quality inspection response data, obtaining production equipment information. The query results showed that the welding process for this product was completed by welding robot WR-03, with a welding time of 2025-01-31 08:45:23. The quality inspection data was correlated with equipment operation records to analyze the operating parameters of welding robot WR-03 during this period. The equipment operation records revealed a welding current of 185A, a welding voltage of 24V, a welding speed of 25mm / s, and a shielding gas flow rate of 12L / min. Analysis of the correlation between welding parameters and defect type showed that welding porosity is usually caused by insufficient shielding gas flow. Compared with standard process parameters, the standard shielding gas flow rate should be 15L / min; the actual flow rate of 12L / min is lower than the standard requirement. An anomaly was detected in the shielding gas supply of welding robot WR-03. Maintenance response data was generated, with the data structure including equipment number WR-03, anomaly type "insufficient shielding gas flow", anomaly detection time, anomaly severity "moderate", and maintenance suggestion "check gas lines and flow control valves".

[0060] Node execution efficiency analysis was conducted on quality inspection response data and maintenance response data to generate orchestration optimization schemes. Statistics were compiled on the generation of quality inspection response data in the intelligent quality inspection scenario over the past 24 hours, processing 1000 products and detecting 50 defective products, resulting in a defect detection rate of 5%. The execution efficiency of each node was analyzed: image acquisition node averaged 0.5 seconds, defect identification node averaged 2.2 seconds, report generation node averaged 1.8 seconds, and process triggering node averaged 0.3 seconds. The defect identification node was identified as the execution bottleneck, accounting for 44% of the total process time. The multi-model parallel detection efficiency of the defect identification node was analyzed: the total execution time of the three parallel detection paths was 2.2 seconds, with the main execution model (Wenxin Yiyan) taking 1.0 second, the backup model (GPT-4V) taking 2.2 seconds, and the traditional algorithm taking 0.8 seconds. The execution time of the backup model (GPT-4V) was found to be the bottleneck for parallel detection. The maintenance response data generation for predictive maintenance scenarios was statistically analyzed, resulting in 50 equipment maintenance suggestions, including 20 emergency maintenance and 30 preventative maintenance. The execution efficiency of the equipment status correlation analysis node was analyzed; its average execution time was 3.5 seconds, with the majority of time consumed in querying the production history database and comparing parameters. An orchestration optimization scheme was generated, comprising three optimization measures: Optimization measure 1 reduces the number of parallel detection paths, retaining only the main execution model and one backup model; Optimization measure 2 introduces a caching mechanism to cache production history data, reducing database query time; Optimization measure 3 adjusts the node parallelism, splitting the equipment status correlation analysis node into multiple subtasks for parallel execution.

[0061] In some embodiments, constructing a graphical node library using the orchestration optimization scheme includes: using the orchestration optimization scheme to classify and identify nodes to obtain node type labels; using the node type labels to adjust node display attributes to form visual configuration rules; using the visual configuration rules to perform drag-and-drop interaction adaptation to generate interactive response mappings; and combining the node type labels with the interactive response mappings to construct a graphical node library.

[0062] For example, the step of using the orchestration optimization scheme to classify and identify nodes and obtain node type labels includes: performing cross-level node tracking for the orchestration optimization scheme and obtaining node execution statistics; analyzing the call frequency characteristics of each node attribute based on the node execution statistics and constructing a node priority association table, wherein each node attribute includes prompt word engineering nodes, model call nodes, and logic judgment nodes; and performing classification projection on the node priority association table to generate node type labels.

[0063] Cross-level node tracking was performed on the orchestration optimization scheme to obtain node execution statistics. The optimization measures configuration in the orchestration optimization scheme were analyzed, and the execution records of all nodes in intelligent quality inspection and predictive maintenance scenarios were tracked. Based on the statistical dimension requirements of the orchestration optimization scheme, execution logs of nodes at each level were collected, spanning the image acquisition layer, model inference layer, business logic layer, and data storage layer. Execution records of the `node_image_capture` node were extracted from the image acquisition layer, showing 1000 calls to this node within 24 hours, an average execution time of 0.5 seconds, and a success rate of 99.9%. Execution records of the defect identification node and report generation node were extracted from the model inference layer, showing 1000 calls to the defect identification node, an average execution time of 2.2 seconds, and a success rate of 98.5%. The report generation node was called 50 times, with an average execution time of 1.8 seconds and a success rate of 100%. Execution records of the process trigger node and device status correlation analysis node were extracted from the business logic layer. The execution data of each node level is summarized and compiled into a node execution statistics table, which includes node name, node level, number of calls, average execution time, success rate, and resource utilization rate.

[0064] Based on the node execution statistics, the frequency characteristics of each node's attributes are analyzed to construct a node priority association table. Each node attribute includes prompt word engineering nodes, model call nodes, and logical judgment nodes. The nodes in the node execution statistics table are traversed to analyze their call frequency and functional attributes. The `node_image_capture` node is identified as a data acquisition node with a high call frequency of approximately 42 times per hour. Based on the node execution statistics, the defect identification node is identified as a model call node, which calls a large language model for image analysis and is also a high-frequency node. The identification report generation node is identified as a prompt word engineering node, which uses a predefined prompt word template to generate a structured report and is a medium-frequency node. The identification process trigger node is identified as a logical judgment node, which determines whether to trigger subsequent processes based on conditional expressions and is also a medium-frequency node. A node priority association table is constructed, containing the node name, node attribute type, call frequency level, and priority score. Set the high-frequency data acquisition nodes and model call nodes to priority 1, set the medium-frequency prompt word engineering nodes and logic judgment nodes to priority 2, and set the low-frequency data storage nodes to priority 3.

[0065] Perform categorical projection on the node priority association table to generate node type labels. Extract node attribute types and priority scores from the node priority association table to classify nodes in multiple dimensions. Based on node attribute type, classify nodes in the association table into data acquisition, model invocation, prompt word engineering, logical judgment, and data storage. Mark `node_image_capture` as a data acquisition node, `defect identification` as a model invocation node, `report generation` as a prompt word engineering node, and `process triggering` as a logical judgment node. Based on priority, classify nodes into core nodes, frequently used nodes, and auxiliary nodes. Mark priority 1 nodes as core nodes, including data acquisition and model invocation nodes. Mark priority 2 nodes as frequently used nodes, including prompt word engineering and logical judgment nodes. Based on application scenario, classify nodes into quality inspection scenario nodes, maintenance scenario nodes, and general nodes. Generate node type labels in the format "node attribute type-priority-application scenario", such as "model invocation-core node-quality inspection scenario". Assign a corresponding node type label to each node for the construction of the graphical node library and interface display.

[0066] Visual configuration rules are formed by adjusting node display attributes using node type tags. The node type tags for each node are analyzed, and the display style of the nodes in the graphical interface is designed based on the node attribute type and priority information in the tags. For tags labeled "Model Call Class - Core Node", the node icon is set to a brain-shaped icon, the node color is blue, the node border is a thick solid line, and the icon size is a large 64×64 pixels. For tags labeled "Prompt Word Engineering Class - Commonly Used Node", the node icon is set to a document icon, the node color is green, the node border is a medium solid line, and the icon size is a medium 48×48 pixels. For node type tags labeled "Logic Judgment Class - Commonly Used Node", the node icon is set to a diamond-shaped judgment icon, the node color is yellow, and the node border is a thin solid line. For tags labeled "Data Acquisition Class - Core Node", the node icon is set to a database icon, the node color is purple, and the node border is a thick solid line. Based on the application scenario identifiers in the tags, the nodes are grouped and assigned to different groups. Nodes labeled "Quality Inspection Scenario" are assigned to the Quality Inspection Node Group, and nodes labeled "Maintenance Scenario" are assigned to the Maintenance Node Group. This creates a visual configuration rule set, including a node icon mapping table, a node color mapping table, a node border style table, and node grouping rules.

[0067] Drag-and-drop interaction adaptation generates an interaction response mapping through visual configuration rules. Based on these rules, drag-and-drop interactions for core nodes are defined. When a user drags a core node from the node library to the canvas, a dashed outline previews the node's position. Releasing the mouse fixes the node to the canvas and automatically aligns it to the grid. Drag-and-drop interactions for frequently used nodes are also defined. When a user drags a frequently used node close to an existing node on the canvas, a connection point tooltip is automatically displayed. Node connection interactions are defined. When a user drags a connection from the output port of a source node to the input port of a target node, the data type compatibility of the two nodes is checked. If compatible, a connection is established; otherwise, an error message is displayed. Node configuration interactions are defined. When a user double-clicks a node on the canvas, a node configuration panel pops up, displaying the node's parameter configuration items. Node deletion interactions are defined. When a user selects a node and presses the delete key, a confirmation prompt appears, and the node and its associated connections are deleted. An interaction response mapping table is generated, containing the interaction event type, trigger condition, response action, and feedback effect.

[0068] A graphical node library is constructed by combining node type labels with interactive response mappings. The node type labels, visual configuration rules, and interactive response mappings of each node are integrated to build a unified node data structure. Based on the node type label, a node definition object is created for each node. This object contains a node ID, node name, type label, node icon path, node color, node size, input port list, output port list, and interactive response mapping configuration. The definition object for the defect detection node is stored in the graphical node library. This object contains a node ID of "node_defect_detection", a type label of "Model Call Class - Core Node - Quality Inspection Scenario", a brain-shaped icon, a blue color, an image data port as the input port, a defect information port as the output port, and interactive response mappings including drag-and-drop, connection, configuration, and deletion behavior definitions. The definition objects for report generation nodes, process trigger nodes, and other nodes are stored in the node library. Node category directories are created in the graphical node library according to the node type label grouping rules, including model call class directories, prompt word engineering class directories, logical judgment class directories, and data acquisition class directories. Within each category directory, nodes are sorted by priority.

[0069] A drag-and-drop orchestration interface is generated based on a graphical node library. Node definitions and categories are extracted from the library to construct the left-side node panel data for the drag-and-drop interface. Within the node panel, categorized groups are created according to node type labels, including a "Model Call" group displaying core nodes such as defect identification and report generation nodes, and a "Logic Judgment" group displaying commonly used nodes such as process trigger nodes and conditional branch nodes. Each node displays an icon, name, and brief description. A central canvas area is created using a grid layout. The canvas loads user-saved workflow configurations and renders nodes and their connections based on the node type labels from the graphical node library. A right-side properties panel and a top toolbar are also created. The properties panel displays the parameter configuration items for the selected node, and the toolbar includes save, run, debug, and deploy buttons. The generated drag-and-drop orchestration interface data is deployed to a web server. Users can access the interface through a browser and orchestrate AI workflows using drag-and-drop, completing the delivery of a visual AI workflow orchestration service.

[0070] To implement the above method embodiments, a visual AI workflow orchestration method is provided to achieve the corresponding functions and technical effects. See also... Figure 2 , Figure 2 This diagram illustrates a structural block diagram of a visual AI workflow orchestration system 200 provided in an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The visual AI workflow orchestration system 200 provided in this embodiment includes: The requirement parsing module 201 is used to obtain the application scenario requirements and prompt word template library resources of the manufacturing industry, extract the task logic dependency relationship through the application scenario requirements, and establish a low-code orchestration standard by using the task logic dependency relationship and the prompt word template library resources. The topology building module 202 is used to identify AI node types using the low-code orchestration standard, detect the coupling strength between data flow and control flow according to the AI ​​node types, generate a dynamic workflow topology graph using the coupling strength, and determine a node orchestration priority table based on the dynamic workflow topology graph. The proxy scheduling module 203 is used to obtain multi-model interface configuration parameters and unified proxy layer rules, perform model capability matching detection based on the unified proxy layer rules to generate a model allocation scheme, and perform collaborative analysis of the multi-model interface configuration parameters and the model allocation scheme to form multi-model proxy scheduling attributes. The dynamic parsing module 204 is used to identify execution bottleneck locations based on the node orchestration priority table and the multi-model agent scheduling attributes, determine dynamic parsing trigger conditions using the execution bottleneck locations, and use the dynamic parsing trigger conditions to adjust the workflow structure during runtime to generate an adaptive execution sequence; The interface generation module 205 is used to generate quality inspection response data and maintenance response data by performing manufacturing application verification using the adaptive execution sequence, analyze the node execution efficiency of the quality inspection response data and the maintenance response data to generate an orchestration optimization scheme, construct a graphical node library using the orchestration optimization scheme, generate drag-and-drop orchestration interface data based on the graphical node library, and complete the visual AI workflow orchestration service.

[0071] The aforementioned visual AI workflow orchestration system 200 can implement a visual AI workflow orchestration method according to the above method embodiments. The options in the above method embodiments are also applicable to this embodiment, and will not be detailed here. The remaining content of this application embodiment can be referred to the content of the above method embodiments, and will not be repeated in this embodiment.

[0072] The above embodiments are not an exhaustive list based on the present invention, and there may be many other embodiments not listed. Any substitutions and improvements made without departing from the concept of the present invention are within the protection scope of the present invention.

Claims

1. A visual AI workflow orchestration method, characterized in that, include: Obtain application scenario requirements and prompt word template library resources in the manufacturing industry, extract task logic dependencies through the application scenario requirements, and establish a low-code orchestration standard using the task logic dependencies and the prompt word template library resources. The AI ​​node type is identified using the low-code orchestration standard. The coupling strength between data flow and control flow between nodes is detected according to the AI ​​node type. The coupling strength is used to generate a dynamic workflow topology graph. The node orchestration priority table is determined based on the dynamic workflow topology graph. Obtain multi-model interface configuration parameters and unified proxy layer rules, perform model capability matching detection based on the unified proxy layer rules to generate a model allocation scheme, and perform collaborative analysis of the multi-model interface configuration parameters and the model allocation scheme to form multi-model proxy scheduling attributes; Based on the node orchestration priority table and the multi-model agent scheduling attributes, the execution bottleneck location is identified, the execution bottleneck location is used to determine the dynamic parsing trigger condition, and the dynamic parsing trigger condition is used to adjust the workflow structure during runtime to generate an adaptive execution sequence. The adaptive execution sequence is used to verify manufacturing applications and generate quality inspection response data and maintenance response data. Node execution efficiency analysis is performed on the quality inspection response data and maintenance response data to generate an orchestration optimization scheme. A graphical node library is constructed using the orchestration optimization scheme. Based on the graphical node library, drag-and-drop orchestration interface data is generated to complete the visualized AI workflow orchestration service.

2. The method according to claim 1, characterized in that, The establishment of a low-code orchestration standard using the task logic dependencies and the prompt word template library resources includes: A task dependency flowchart is generated based on the aforementioned task logical dependencies; The template library resources and the task dependency flowchart are combined to form a template-task mapping trajectory; Extract the programmable constraint range within the template-task mapping trajectory; Set the rules for the programmable constraint range as a low-code programmability standard.

3. The method according to claim 1, characterized in that, The process of generating a dynamic workflow topology map using the coupling strength includes: The coupling strength is decomposed into data dependency strength and control dependency strength; A dependency analysis path is constructed by combining the data dependency strength and the control dependency strength; In the dependency analysis path, redundant execution branches are identified to determine fault-tolerant backup nodes; The nodes with the highest coupling degree among the fault-tolerant backup nodes are selected to generate a dynamic workflow topology graph.

4. The method according to claim 1, characterized in that, The step of collaboratively analyzing the multi-model interface configuration parameters and the model allocation scheme to form multi-model agent scheduling attributes includes: A capability difference analysis is performed on the model allocation scheme to obtain the difference compensation factor; Based on the difference compensation factor, the multi-model interface configuration parameters are load matched to form a load balancing metric; A scheduling timing graph is generated by interpolating the load balancing metric using a time window. The aforementioned scheduling timing graph is used to form multi-model agent scheduling attributes.

5. The method according to claim 1, characterized in that, The step of using the dynamically parsed trigger conditions to adjust the workflow structure during runtime and generate an adaptive execution sequence includes: Based on the dynamic parsing trigger conditions, workflow structure change detection is performed to obtain node adjustment requirements; In the node adjustment requirements, identify nodes that fail to execute and generate failure node markers; The failed node markers are used to perform path reconstruction analysis and generate optimized path configurations. An adaptive execution sequence is generated based on the optimized path configuration.

6. The method according to claim 1, characterized in that, The process of generating quality inspection response data and maintenance response data using the adaptive execution sequence for manufacturing application verification includes: Task assignment is performed on the adaptive execution sequence to generate quality inspection execution instructions; The aforementioned quality inspection execution command triggers multi-model parallel detection to generate multiple quality inspection results; The detection output with the highest confidence level is extracted from the multi-channel quality inspection results to form quality inspection response data; Based on the quality inspection response data, equipment status correlation analysis is performed to generate maintenance response data.

7. The method according to claim 1, characterized in that, The construction of the graphical node library using the aforementioned orchestration optimization scheme includes: The aforementioned orchestration optimization scheme is used to classify and identify nodes to obtain node type labels; The node type labels are used to adjust node display attributes to form visual configuration rules; The drag-and-drop interaction is adapted and an interactive response mapping is generated through the aforementioned visual configuration rules. A graphical node library is constructed by combining the node type labels with the interactive response mapping.

8. The method according to claim 3, characterized in that, The step of identifying redundant execution branches and determining fault-tolerant backup nodes in the dependency analysis path includes: Obtain the execution branches of the nodes in the dependency analysis path; Identify functionally equivalent redundant branches within the execution branches of the node; The fault tolerance capability of the redundant branches is evaluated to generate fault tolerance priority identifiers; The redundant branch is marked as a fault-tolerant standby node according to the fault tolerance priority identifier.

9. The method according to claim 7, characterized in that, The step of using the aforementioned orchestration optimization scheme to classify and identify nodes and obtain node type labels includes: Cross-level node tracking is performed on the aforementioned orchestration optimization scheme to obtain node execution statistics. Based on the statistical data analysis of the nodes, the frequency characteristics of the node attributes are analyzed, and a node priority association table is constructed. The node attributes include prompt word project nodes, model call nodes, and logic judgment nodes. Perform a classification projection on the node priority association table to generate node type labels.

10. A visual AI workflow orchestration system, characterized in that, include: The requirement parsing module is used to obtain the application scenario requirements and prompt word template library resources of the manufacturing industry, extract the task logic dependency relationship through the application scenario requirements, and establish a low code orchestration standard using the task logic dependency relationship and the prompt word template library resources. The topology building module is used to identify AI node types using the low-code orchestration standard, detect the coupling strength between data flow and control flow according to the AI ​​node types, generate a dynamic workflow topology graph using the coupling strength, and determine a node orchestration priority table based on the dynamic workflow topology graph. The proxy scheduling module is used to obtain multi-model interface configuration parameters and unified proxy layer rules, perform model capability matching detection based on the unified proxy layer rules to generate a model allocation scheme, and perform collaborative analysis of the multi-model interface configuration parameters and the model allocation scheme to form multi-model proxy scheduling attributes. The dynamic parsing module is used to identify execution bottleneck locations based on the node orchestration priority table and the multi-model agent scheduling attributes, determine dynamic parsing trigger conditions using the execution bottleneck locations, and use the dynamic parsing trigger conditions to adjust the workflow structure during runtime to generate an adaptive execution sequence. The interface generation module is used to generate quality inspection response data and maintenance response data by performing manufacturing application verification using the adaptive execution sequence, analyze the node execution efficiency of the quality inspection response data and the maintenance response data to generate an orchestration optimization scheme, construct a graphical node library using the orchestration optimization scheme, generate drag-and-drop orchestration interface data based on the graphical node library, and complete the visual AI workflow orchestration service.

Images