Multi-industry-oriented AI application development system
By constructing business process and tool graphs and using large-scale language models for automatic analysis and simulation verification, the problem of difficulty in modeling tool dependencies and costs in traditional AI application development systems has been solved, achieving an efficient and accurate AI application development process.
Patent Information
- Application Number
- CN202511752463.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-26
- Publication Date
- 2026-01-02
AI Technical Summary
Traditional AI application development systems for multiple industries rely on fixed programming frameworks and predefined model libraries, which requires developers to manually write a lot of low-level code. This makes it difficult to quickly respond to the specific needs of different industries, and the lack of explicit modeling and simulation verification of tool dependencies and execution costs makes it difficult to predict debugging rework and potential data dependency conflicts.
By constructing a business process and tool map, we obtain the vectors of preconditions, post-effects, and execution costs. We then use a large language model to automatically analyze business automation requirements, generate candidate tool call sequences, and discover potential data dependency conflicts or cost overruns through simulation verification. Finally, we iteratively adjust the tool sequences until the conflicts are eliminated.
It significantly improves the accuracy and efficiency of AI application development. Through structured business processes and tool graphs, it automatically analyzes and simulates verification, proactively identifies and resolves potential problems, and generates validated and cost-controlled automated AI application execution flows.
Smart Images

Figure CN121255162A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of emerging software technology, and in particular to a multi-industry-oriented AI application development system. BACKGROUND
[0002] The field of emerging software technology refers to a software product and service system constructed using new generation information technology such as graphical development, agile development, and intelligent development. This field covers the entire life cycle of software design, development, testing, and maintenance, aiming to improve the efficiency, quality, and intelligence level of software development to support the digital transformation and intelligent upgrading of various industries. Among them, the traditional multi-industry-oriented AI application development system refers to a software platform for building artificial intelligence applications. Traditional systems usually rely on fixed programming frameworks and predefined model libraries, and developers need to write a large amount of underlying code to implement data preprocessing, model training, and algorithm integration. This approach requires developers to have a deep programming and algorithm foundation, and the development process is rigid, making it difficult to quickly respond to specific needs of different industries.
[0003] The traditional multi-industry-oriented AI application development system has the disadvantage of relying heavily on fixed programming frameworks and predefined model libraries. When building applications, developers must manually write a large amount of underlying code to integrate algorithms, and the entire development process is rigid. In particular, when dealing with complex business logic, this approach lacks explicit modeling and simulation verification mechanisms for tool dependencies and execution costs, making it difficult for developers to predict the effectiveness of tool sequences before execution. For example, the output data format of a tool cannot match the input preconditions of subsequent tools, or the combination of multiple tools results in excessive total execution costs. These potential data dependency conflicts and cost risks are usually discovered during the late development or running phase, causing a lot of debugging and rework, making it difficult to quickly respond to specific needs of different industries. SUMMARY
[0004] The purpose of the present application is to solve the shortcomings in the prior art and to provide a multi-industry-oriented AI application development system.
[0005] To achieve the above-mentioned purpose, the present application adopts the following technical solution: a multi-industry-oriented AI application development system includes:
[0006] A business graph construction module acquires business process model data and tool capability description information, analyzes the tool capability description information to define preconditions, post-effects, and execution cost vectors, constructs a business process and tool graph, and transmits it to a tool sequence generation module and a sequence simulation verification module;
[0007] A tool sequence generation module obtains a business automation requirement, prompts a large language model to match a tool based on the business process and tool graph disassembling the business automation requirement, generates a candidate tool calling sequence, and transmits the candidate tool calling sequence to a sequence simulation verification module.
[0008] The sequence simulation verification module simulates execution based on the candidate tool calling sequence and the business process and tool graph, judges the precondition matching, accumulates the execution cost vector, calculates data dependency conflicts and cost overruns, generates a sequence conflict set, and transmits the sequence conflict set to an execution sequence correction module.
[0009] The execution sequence correction module calls the large language model, prompts the sequence conflict set, adjusts the tool according to the data dependency conflict or the cost overrun, iteratively adjusts the candidate tool calling sequence until the sequence conflict set is empty, and outputs an automated AI application execution flow.
[0010] As a further scheme of the present application, the business process and tool graph includes tool nodes, process dependency relationships, and data flow edges, the candidate tool calling sequence specifically refers to a sequence execution order, a tool identifier list, and a parameter binding set, the sequence conflict set includes missing data items, conflict tool indexes, and cumulative cost values, and the automated AI application execution flow specifically refers to a corrected tool order, a verified parameter set, and a total execution cost.
[0011] As a further scheme of the present application, the business graph construction module specifically functions as:
[0012] A process data acquisition sub-module acquires business process model data and tool capability description information.
[0013] A tool attribute analysis sub-module analyzes function constraints and resource consumption included in the tool capability description information, extracts tool input parameters, output parameters, the precondition, and the post-effect, quantifies the resource consumption, and generates the execution cost vector.
[0014] A business graph mapping sub-module analyzes the business process model data, identifies business nodes and business logic relationships, and constructs an initial business graph based on the business logic relationships and the process dependency relationship definition.
[0015] A graph fusion association sub-module maps the tool input parameters and the tool output parameters to the data flow edges, and mounts the tool nodes to the business nodes of the initial business graph according to the precondition and the post-effect, to generate the business process and tool graph.
[0016] As a further scheme of the present application, the process of generating the execution cost vector by the tool attribute analysis sub-module includes:
[0017] Obtaining original index data about computing resource occupation, API call frequency and expected execution duration in the tool capability description information;
[0018] Setting resource weight factors corresponding to the computing resource occupation, call weight factors corresponding to the API call frequency and time weight factors corresponding to the expected execution duration;
[0019] Performing normalization processing on the original index data to obtain normalized values of the computing resource occupation, the API call frequency and the expected execution duration;
[0020] The execution cost vector is calculated by weighted summation The calculation formula is:
[0021]
[0022] Among them, represents the execution cost vector, represents the normalized value of the computing resource, represents the resource weight factor, represents the normalized value of the API call frequency, represents the call weight factor, represents the normalized value of the expected execution duration, represents the time weight factor.
[0023] As a further scheme of the present application, the specific function of the tool sequence generation module is implemented as:
[0024] A demand semantic analysis submodule obtains the business automation demand, calls the large language model to analyze the semantic intention of the business automation demand, and disassembles it into multi-stage subtasks.
[0025] A graph tool matching submodule obtains the business process and tool graph, traverses the multi-stage subtasks, searches for tool nodes in the business process and tool graph that match the semantic intention and data demand of the multi-stage subtasks, and generates a candidate tool set.
[0026] A sequence path planning submodule sorts the tool nodes in the candidate tool set based on the process dependency relationship and the data flow direction edge, constructs an initial tool path, and generates the sequence execution order and the tool identifier list.
[0027] The parameter instance binding submodule parses specific parameter values carried in the multi-stage subtask, binds the specific parameter values with input parameters of corresponding tools in the tool identifier list according to the data flow direction edge, generates the parameter binding set, and combines the sequence execution order, the tool identifier list and the parameter binding set to obtain the candidate tool calling sequence.
[0028] As a further scheme of the present application, the process of searching for the tool nodes matched by the tool graph matching submodule includes:
[0029] The semantic intention of the multi-stage subtask is obtained, and the text embedding model is used to convert the semantic intention into a task demand vector;
[0030] The tool capability description information of the tool nodes in the business process and the tool graph is obtained, and the text embedding model is used to convert the tool capability description information into a tool capability vector;
[0031] The cosine similarity between the task demand vector and all tool capability vectors is calculated to obtain a similarity score;
[0032] A similarity matching threshold is set, the tool nodes with a similarity score greater than the similarity matching threshold are screened, and a preliminary candidate list is formed;
[0033] It is verified whether the required input parameters of the tool nodes in the preliminary candidate list are consistent with the available data output types of the multi-stage subtask, the tool nodes with unmatched data types are filtered, and the candidate tool set is generated.
[0034] As a further scheme of the present application, the specific function of the sequence simulation verification module is implemented as:
[0035] The simulation environment initialization submodule obtains the candidate tool calling sequence and the business process and tool graph, and initializes an empty simulation execution state and an empty sequence conflict set;
[0036] The tool step-by-step traversal submodule extracts the tool nodes from the tool identifier list one by one according to the sequence execution order, and obtains the corresponding preconditions and parameter binding set;
[0037] The precondition verification submodule judges whether the preconditions are satisfied by the simulation execution state, if not, records the index of the tool node as the conflict tool index, and records the missing preconditions in the simulation execution state as the missing data items;
[0038] The data dependency checking submodule checks whether the required data in the parameter binding set exists in the simulation execution state, and if not, records the index of the tool node as the conflict tool index and records the required data as the missing data item;
[0039] The execution cost accumulation submodule obtains the execution cost vector of the tool node, accumulates it to the global cumulative cost value, and judges whether the cumulative cost value exceeds the preset cost threshold, and if so, determines that the cost overrun occurs;
[0040] The simulation state updating submodule updates the post-effect of the tool node to the simulation execution state for the verification of the tool node if the verification passes;
[0041] The conflict set generation submodule summarizes all recorded missing data items, conflict tool indexes and cumulative cost values to generate the sequence conflict set.
[0042] As a further scheme of the application, the implementation process of the data dependency checking submodule and the execution cost accumulation submodule includes:
[0043] Obtain the parameter binding set of the tool node, and traverse each required data declared in the parameter binding set;
[0044] In the simulation execution state, query whether the required data exists, if not, identify the required data as the missing data item, and record the index of the tool node as the conflict tool index and store it in the sequence conflict set;
[0045] If the data dependency checking passes, obtain the execution cost vector of the tool node, and obtain the data criticality associated with the tool node output data in the business process and tool graph ;
[0046] Set the criticality influence factor , and update the cumulative cost value , the calculation formula is:
[0047] ;
[0048] Wherein, represents the cumulative cost value before updating, represents the execution cost vector of the tool node, represents the criticality influence factor, represents the data criticality;
[0049] Obtain the preset cost threshold, judge whether the cumulative cost value after updating whether greater than the preset cost threshold, if greater than, marking the cost overrun in the sequence conflict set.
[0050] As a further scheme of the present application, the specific function of the execution sequence correction module is implemented as:
[0051] a conflict information analysis submodule, obtaining the sequence conflict set, analyzing the missing data item, the conflict tool index and the cost overrun mark included in the sequence conflict set;
[0052] a correction prompt generation submodule, organizing the missing data item, the conflict tool index and the cost overrun mark into a correction prompt word, calling the large language model, taking the correction prompt word as input, obtaining a correction strategy for the data dependency conflict or the cost overrun;
[0053] a candidate sequence adjustment submodule, based on the correction strategy, adjusting the sequence execution order, the tool identifier list or the parameter binding set in the candidate tool call sequence, generating an updated candidate tool call sequence;
[0054] an iterative loop control submodule, passing the updated candidate tool call sequence back to the sequence simulation verification module for a new round of verification, obtaining a new sequence conflict set, and determining whether the new sequence conflict set is empty;
[0055] a sequence output submodule, if the new sequence conflict set is empty, terminating iteration, defining the sequence execution order included in the updated candidate tool call sequence as the corrected tool order, defining the parameter binding set included in the updated candidate tool call sequence as the verified parameter set, extracting the cumulative cost value as the total execution cost, and combining to generate the automated AI application execution flow.
[0056] As a further scheme of the present application, the process of adjusting the candidate sequence adjustment submodule based on the correction strategy includes:
[0057] obtaining the correction strategy and determining the type of the correction strategy;
[0058] if the type of the correction strategy is data dependency adjustment, analyzing the missing data item, searching for a supplementary tool node capable of generating the missing data item in the business process and tool graph, inserting the supplementary tool node before the position corresponding to the conflict tool index, and updating the sequence execution order, the tool identifier list and the parameter binding set;
[0059] if the type of the modification strategy is a cost overrun adjustment, identifying the tool node with the highest execution cost vector value in the candidate tool invocation sequence, searching for an alternative tool node with the same postconditions but a lower execution cost vector value in the business process and tool graph, replacing the tool node with the highest execution cost vector value with the alternative tool node, and updating the tool identifier list;
[0060] generating the updated candidate tool invocation sequence.
[0061] Compared with the prior art, the application has the advantages and positive effects that:
[0062] In the application, by adopting the business process model and tool capability description information, a business process and tool graph containing preconditions, postconditions and execution cost vectors is constructed to provide a structured basis for automated demand disassembly, a large language model is used to automatically analyze business automation requirements based on the graph, match corresponding tools and generate a candidate tool invocation sequence, which is different from direct execution, the scheme simulates and verifies the candidate sequence, actively discovers potential data dependency conflicts or cost overrun problems by judging the precondition matching and cumulative execution cost vector, and then drives the large language model to iteratively adjust the tool sequence with the generated sequence conflict set as a prompt until the conflicts are eliminated, and finally outputs an verified and cost-controllable automation AI application execution flow, which significantly improves the accuracy and efficiency of application construction. BRIEF DESCRIPTION OF DRAWINGS
[0063] Figure 1 The system architecture diagram for the AI application development system of the application is shown in the figure;
[0064] Figure 2 The business graph construction flowchart of the application is shown in the figure;
[0065] Figure 3 The tool sequence generation flowchart of the application is shown in the figure;
[0066] Figure 4 The sequence simulation verification flowchart of the application is shown in the figure;
[0067] Figure 5 The execution sequence modification flowchart of the application is shown in the figure. DETAILED DESCRIPTION
[0068] In order to make the purpose, technical scheme and advantages of the application clearer, the technical scheme realized based on software will be described in detail below in combination with the system architecture diagram and embodiments. It should be understood that the specific embodiments described herein are only used to explain the technical scheme of the application and do not constitute a limitation on the scope of protection.
[0069] In the description of the present application, the system architecture relationship or data processing flow indicated by the terms "hierarchy", "module", "interface", "data flow", "client", "server" and the like are defined based on the corresponding architecture diagram or flowchart of the embodiments. This way of expression is only used to clearly explain the logical relationship of each element in the technical solution, and is not limited to the physical deployment form. The "multiple" includes two or more technical units, including but not limited to multiple data nodes, processing threads, service instances or functional components, and other scalable elements. The specific number is determined according to the actual business scenario.
[0070] Please refer to Figure 1 and Figure 2 The present application provides a technical solution: a multi-industry-oriented AI application development system includes:
[0071] A business graph construction module acquires business process model data and tool capability description information, analyzes the tool capability description information to define preconditions, post-effects and execution cost vectors, constructs a business process and tool graph, and transmits it to a tool sequence generation module and a sequence simulation and verification module.
[0072] The business process and tool graph includes tool nodes, process dependency relationships, and data flow edges.
[0073] The specific function implementation of the business graph construction module is:
[0074] A process data acquisition submodule acquires business process model data and tool capability description information.
[0075] A tool attribute analysis submodule analyzes the functional constraints and resource consumption included in the tool capability description information, extracts tool input parameters, output parameters, preconditions and post-effects, and quantifies resource consumption to generate an execution cost vector.
[0076] A business graph mapping submodule analyzes business process model data, identifies business nodes and business logic relationships, and constructs an initial business graph based on business logic relationships and process dependency relationships.
[0077] A graph fusion and association submodule maps tool input parameters and tool output parameters to data flow edges, and mounts tool nodes to business nodes of the initial business graph according to preconditions and post-effects to generate a business process and tool graph.
[0078] The process of generating an execution cost vector by the tool attribute analysis submodule includes:
[0079] Obtain the original index data about computing resource occupation, API call frequency and expected execution time length in the tool capability description information.
[0080] Set the resource weight factor corresponding to the computing resource occupation, the call weight factor corresponding to the API call frequency and the time weight factor corresponding to the expected execution time;
[0081] The original index data is normalized to obtain the normalized value of the computing resource occupation, the normalized value of the API call frequency and the normalized value of the expected execution time;
[0082] The execution cost vector is calculated by weighted summation , and the calculation formula is:
[0083] ;
[0084] Among them, represents the execution cost vector, represents the normalized value of the computing resource, represents the resource weight factor, represents the normalized value of the API call frequency, represents the call weight factor, represents the normalized value of the expected execution time, represents the time weight factor.
[0085] The execution of the business graph construction module starts from the process data acquisition submodule, which calls the business process model data and tool capability description information from the API gateway and the business process management (BPM) system in the enterprise. For an "e-commerce guarantee transaction" business scenario, the acquired business process model data is a BPMN2.0 standard XML file describing "order creation", "inventory locking", "buyer payment", "platform capital verification" and "seller delivery". The acquired tool capability description information is a series of OpenAPI3.0 specification JSON files of RESTful API, which defines tool_processPayment (payment processing tool) and tool_verifySignature (payment signature verification tool).
[0086] The tool property analysis submodule receives the OpenAPI JSON file of tool_processPayment. Analyzing the components.schemas and paths fields, the functional constraints are extracted: the tool input parameters are order_id (string), amount (float), and payer_account (string); the tool output parameters are transaction_id (string) and payment_status (boolean). Analyzing the security field, the preconditions are extracted as user_session_active and order_stock_confirmed. Analyzing the responses."200".description, the post-effect is extracted as payment_transaction_generated. Subsequently, the quantification process of the execution cost vector is started. First, the original metric data of tool_processPayment is obtained from the x-performance-metrics custom field of the tool capability description information: the computing resource occupancy is CPU cores, the API call frequency is times / execution (referring to the number of microservice calls triggered inside the tool), and the expected execution duration is milliseconds.
[0087] The resource weight factor corresponding to the computing resource occupancy is set as , the call weight factor corresponding to the API call frequency is set as , and the time weight factor corresponding to the expected execution duration is set as . These weights are set in reference to the multiple regression analysis of the API gateway log and server monitoring data in the past 6 months (total of 50,000 times).
[0088] Table 1 Regression analysis verification table for weight factor setting
[0089] Experiment batch Normalized resource usage Normalized call frequency Normalized execution duration Observed normalized cost 1 0.20 0.50 0.30 0.365 2 0.80 0.20 0.10 0.390 3 0.50 0.70 0.80 0.695 ... ... ... ... ... 500 0.60 0.40 0.50 0.490
[0090] As shown in Table 1, by collecting a large amount of historical execution data, the indicators are normalized, and linear fitting is performed with the actual observed total cost (for example, the standardized value considering the server fee, API call fee, and SLA penalty). For a business scenario that prioritizes controlling API call overhead, the standardized regression coefficients obtained are set as the weights: , , .
[0091] Normalize the raw performance data of tool_processPayment. This process is based on the global benchmark range determined by statistical analysis of the performance indicators of all tools (350 in total) in the system. Compute resource occupancy Nuclei; API call frequency Executions / second; expected execution duration milliseconds. The raw performance data of tool_processPayment is: , , . Calculate the normalized values (Min-Max normalization):
[0092] Calculate the execution cost vector of tool_processPayment by weighted summation . The formula is as follows: represents the final calculated execution cost vector, a quantitative scalar value. represents the resource weight factor, with a set value of , reflecting the importance of computing resource cost in the total cost. represents the normalized value of computing resources, with the current calculation value being , indicating the relative position of the tool's resource consumption in the global tools. represents the call weight factor, with a set value of , reflecting the importance of API call overhead in the total cost. represents the normalized value of API call frequency, with the current calculation value being , indicating the relative position of the tool's call complexity in the global tools. represents the time weight factor, with a set value of , reflecting the importance of execution time (delay) cost in the total cost. represents the normalized value of expected execution duration, with the current calculation value being , indicating the relative position of the tool's execution time consumption in the global tools. The operation logic of this formula is to map the three different physical units (nuclei, executions, milliseconds) and dimensionally different raw performance indicators to the unified interval of to first, and then perform linear weighted summation on these three standardized indicators according to the business scenario (reflected by ), and finally output a single, comparable cost measurement value. Substitute the values for calculation: The benefit of this formula is that by introducing configurable weight factors , and performing linear weighted summation on heterogeneous raw indicators performing a weighted sum to unify the multi-dimensional performance consumption of the tool into a single execution cost vector The result indicates The execution cost vector value of This value will be stored in association with the tool node tool_processPayment.
[0093] The business graph mapping submodule parses the BPMN2.0 XML file of the "e-commerce guarantee transaction". By traversing the <task>Elements, identify business nodes, e.g., BN_LockStock (Business Node: Inventory Lock), BN_ProcessPayment (Business Node: Buyer Payment). By parsing <sequenceflow>Elements, such as <sequenceFlow sourceRef="BN_LockStock" targetRef="BN_ProcessPayment">, identify business logic relationships and define process dependency relationships (BN_LockStock, BN_ProcessPayment) accordingly. An initial business graph is constructed, which contains business nodes and process dependency relationship edges between them.
[0094] The graph fusion association submodule performs linking. The tool input parameters order_id, amount of tool_processPayment and the tool output parameters transaction_id, payment_status are mapped to data flow edges. Then, the tool_processPayment tool node is mounted to the business node BN_ProcessPayment of the initial business graph according to its preconditions user_session_active, order_stock_confirmed and post-effects payment_transaction_generated. When mounting, the system checks whether the post-effects of the upstream business node BN_LockStock (e.g. order_stock_confirmed:true) and the post-effects of the "user login" node (user_session_active:true) of BN_ProcessPayment satisfy the preconditions of tool_processPayment. After verification, the mapping relationship between tool_processPayment and BN_ProcessPayment is established, and the business process and tool graph are generated.
[0095] Please refer to Figure 1 and Figure 3 , the tool sequence generation module, acquires business automation requirements, prompts the large language model to match tools based on business process and tool graphs to disassemble business automation requirements, generates candidate tool call sequences, and transmits them to the sequence simulation verification module;
[0096] The candidate tool call sequence specifically refers to the sequence execution order, tool identifier list, and parameter binding set.
[0097] The specific function implementation of the tool sequence generation module is as follows:
[0098] The requirement semantic analysis submodule acquires business automation requirements, calls a large language model to analyze the semantic intent of business automation requirements, and disassembles them into multiple-stage sub-tasks.
[0099] The atlas tool matching submodule obtains the business process and the tool atlas, traverses the multi-stage subtasks, searches for tool nodes matching the semantic intent and data requirements of the multi-stage subtasks in the business process and the tool atlas, and generates a candidate tool set;
[0100] The sequence path planning submodule sorts the tool nodes in the candidate tool set based on the process dependency relationship and the data flow direction edge, constructs an initial tool path, and generates a sequence execution order and a tool identifier list;
[0101] The parameter instance binding submodule parses specific parameter values carried in the multi-stage subtasks, binds the specific parameter values and the input parameters of the corresponding tools in the tool identifier list according to the data flow direction edge, generates a parameter binding set, combines the sequence execution order, the tool identifier list, and the parameter binding set, and obtains a candidate tool calling sequence;
[0102] The process of searching for matching tool nodes by the atlas tool matching submodule includes:
[0103] The semantic intent of the multi-stage subtask is obtained, and a text embedding model is used to convert it into a task requirement vector;
[0104] The tool capability description information of the plurality of tool nodes in the business process and the tool atlas is obtained, and a text embedding model is used to convert the tool capability description information into a tool capability vector;
[0105] The cosine similarity between the task requirement vector and all tool capability vectors is calculated to obtain a similarity score;
[0106] A similarity matching threshold is set, tool nodes with a similarity score greater than the similarity matching threshold are screened, and a preliminary candidate list is formed;
[0107] It is verified whether the input parameters required by the tool nodes in the preliminary candidate list are consistent with the available data output types of the multi-stage subtasks, the tool nodes with unmatched data types are filtered, and a candidate tool set is generated.
[0108] The tool sequence generation module is started, and the requirement semantic analysis submodule obtains the business automation requirement, which is a natural language text: "Help me query the inventory of the product SKU-9001, and if the inventory quantity is more than 20 pieces, immediately place an order to purchase 20 pieces, with a total amount of 550.00 yuan". Then, a large language model is called to analyze the semantic intent of this requirement. The model parses the text and breaks it down into three sequential multi-stage subtasks, and outputs structured data: [{"task_id":1,"intent":"query product inventory level","params":{"item_sku":"SKU-9001"}},{"task_id":2,"intent":"conditional judgment","condition":{"variable":"ref:task_1.stock_level","operator":">","value":20}},{"task_id":3,"intent":"execute order payment","params":{"item_sku":"SKU-9001","quantity":20,"amount":550.00},"depends_on":"task_2"}]
[0109] The graph tool matching submodule obtains the business process generated in step S100 and the tool graph, and traverses the above multi-stage subtasks. For task_id:1 ("query product inventory level"), search is performed. First, the semantic intent "query product inventory level" of task_id:1 is obtained, and a 384-dimensional task requirement vector is converted using a text embedding model (such as Sentence-BERT) . At the same time, the tool capability description information (such as the description of tool_queryStock is "check the inventory of the specified SKU") of all tool nodes (such as tool_queryStock, tool_processPayment) in the business process and tool graph is extracted. The same text embedding model is used to convert these description information into tool capability vectors, such as and .
[0110] Next, the cosine similarity between the task requirement vector and all tool capability vectors is calculated:
[0111] The similarity matching threshold is set. The setting of this threshold refers to the test results on a labeled verification set containing 1000 "task-tool" matching pairs.
[0112] Table 2 Similarity threshold verification table
[0113] Tagged pair (task, tool) Semantic relevance (1 / 0) Compute similarity (queryStock, queryStock) 1 0.96 (queryStock, processPayment) 0 0.12 (processPayment, processPayment) 1 0.94 (queryStock, queryStock) 0 0.79 (processPayment, processPayment) 1 0.88
[0114] As shown in Table 2, by adjusting the threshold on the labeled validation set and computing the F1 score (F1-Score), when the threshold is set at , the F1 score reaches the maximum value . Therefore, the similarity matching threshold is set to . Tool nodes with similarity scores greater than are screened out. , tool_queryStock is retained; , tool_processPayment is discarded. The preliminary candidate list ["tool_queryStock"] is formed. Finally, it is checked whether the input parameter (item_sku) required by tool_queryStock is consistent with the available data output type (stock_level) of task_id:1. There is item_sku in the params of task_id:1, and the type matches. The output stock_level (integer) of tool_queryStock is also consistent with the data type required by the judgment condition of task_id:2. Tool nodes with data type mismatch (none here) are filtered out. The candidate tool set ["tool_queryStock"] of task_id:1 is generated. Repeat this process for task_id:3 ("execute order payment"), and match the candidate tool set ["tool_processPayment"].
[0115] The sequence path planning submodule sorts the candidate tool set ["tool_queryStock", "tool_processPayment"] based on the process dependency relationship in the graph (BN_LockStock->BN_ProcessPayment) and the data flow edge (task_id:3 depends on task_id:2, task_id:2 depends on task_id:1). Through topological sorting, the initial tool path is constructed, and the sequence execution order [1, 2] and the tool identifier list ["tool_queryStock", "tool_processPayment"] are generated.
[0116] The parameter instance binding submodule parses the specific parameter values carried in the multi-stage subtasks. The task_id:1 carries the item_sku: "SKU-9001". The task_id:3 carries the item_sku: "SKU-9001", quantity: 20, and amount: 550.00. According to the data flow direction edge, these specific parameter values are bound to the input parameters of the corresponding tool in the tool identifier list. The input item_sku of the tool_queryStock is bound to "SKU-9001". The input amount of the tool_processPayment is bound to 550.00, and the order_id is bound to "ORDER_NEW_001" through context association (or new creation). The parameter binding set is generated: [{"tool": "tool_queryStock", "bindings": {"item_sku": "SKU-9001"}}, {"tool": "tool_processPayment", "bindings": {"order_id": "ORDER_NEW_001", "amount": 550.00}}]. Finally, the sequence execution order, the tool identifier list, and the parameter binding set are combined to obtain the candidate tool invocation sequence.
[0117] Please refer to Figure 1 and Figure 4 The sequence simulation verification module simulates execution based on the candidate tool invocation sequence and the business process and tool graph, judges the precondition matching, accumulates the execution cost vector, calculates the data dependency conflict and cost overrun, generates a sequence conflict set, and transmits it to the execution sequence correction module.
[0118] The sequence conflict set includes missing data items, conflict tool indexes, and cumulative cost values.
[0119] The specific function implementation of the sequence simulation verification module is as follows:
[0120] The simulation environment initialization submodule obtains the candidate tool invocation sequence and the business process and tool graph, and initializes an empty simulation execution state and an empty sequence conflict set.
[0121] The tool step-by-step traversal submodule extracts tool nodes one by one from the tool identifier list according to the sequence execution order, and obtains their corresponding preconditions and parameter binding sets.
[0122] The precondition verification submodule judges whether the preconditions are satisfied by the simulation execution state. If not, the index of the tool node is recorded as the conflict tool index, and the missing precondition in the simulation execution state is recorded as the missing data item.
[0123] The data dependency checking submodule checks whether the required data in the parameter binding set exists in the simulation execution state. If not, the index of the tool node is recorded as a conflict tool index, and the required data is recorded as a missing data item.
[0124] The execution cost accumulation submodule obtains the execution cost vector of the tool node, accumulates it to the global cumulative cost value, and judges whether the cumulative cost value exceeds the preset cost threshold. If it does, it is determined that a cost overrun is generated.
[0125] The simulation state updating submodule updates the post-effect of the tool node to the simulation execution state for the verification of the tool node if the verification passes.
[0126] The conflict set generation submodule aggregates all recorded missing data items, conflict tool indexes, and cumulative cost values to generate a sequence conflict set.
[0127] The implementation process of the data dependency checking submodule and the execution cost accumulation submodule includes:
[0128] Obtain the parameter binding set of the tool node, and traverse each required data declared in the parameter binding set.
[0129] Query whether the required data exists in the simulation execution state. If not, identify the required data as a missing data item, and record the index of the tool node as a conflict tool index and store it in the sequence conflict set.
[0130] If the data dependency check passes, obtain the execution cost vector of the tool node, and obtain the data criticality associated with the output data of the tool node in the business process and tool graph .
[0131] Set the criticality influence factor , and update the cumulative cost value , the calculation formula is:
[0132] ;
[0133] Wherein, represents the cumulative cost value before updating, represents the execution cost vector of the tool node, represents the criticality influence factor, represents the data criticality.
[0134] Obtain the preset cost threshold, judge whether the updated cumulative cost value is greater than the preset cost threshold. If it is, mark the cost overrun in the sequence conflict set.
[0135] The sequence simulation verification module starts, and the simulation environment initialization submodule obtains the candidate tool invocation sequence (tool identifier list: ["tool_queryStock", "tool_processPayment"], sequence execution order: [1, 2], and the corresponding parameter binding set) generated in the previous step (S200), and obtains the business process and tool graph generated in step S100. Initialize an empty simulation execution state State = {} and an empty sequence conflict set Conflicts = {}. Set the global cumulative cost value .
[0136] The tool step-by-step traversal submodule extracts the first tool node Tool_1 = "tool_queryStock" according to the sequence execution order [1]. Obtain its corresponding preconditions PreCond_1 = ["user_session_active"] (assuming that this tool requires user login) from the graph. Obtain its parameter binding set Params_1 = {"item_sku": "SKU-9001"}.
[0137] The precondition verification submodule judges whether PreCond_1 is satisfied by State. State is {}, which does not contain user_session_active. Verification failed. The system records the index 1 of the tool node as the conflict tool index, and records the missing precondition "user_session_active" as the missing data item. Conflicts is updated to {"missing_data": ["user_session_active"], "conflict_index": [1]}.
[0138] (for demonstration of subsequent steps, it is assumed that the sequence has been modified to ["tool_authenticate", "tool_queryStock", "tool_processPayment"], and tool_authenticate has been successfully simulated, with a cost of and . The current State = {"user_session_active": true}. After the first step of calculation, it is . Now traverse to , Tool_2 = "tool_queryStock". The precondition PreCond_2 = ["user_session_active"] of Tool_2 exists in State and is true, and the verification is passed.
[0139] The data dependency check submodule and the execution cost accumulation submodule are initiated. The parameter binding set of Tool_2, Params_2 = {"item_sku": "SKU-9001"} is obtained. The required data item_sku is traversed, which is a literal, non-state reference, and the query exists. The data dependency check passes. Next, the execution cost vector of Tool_2 ("tool_queryStock") is obtained . The value has been determined in historical calculations (refer to the previous round of dialogue S100) as . The data criticality of the Tool_2 output data (stock_level) associated in the business process and tool graph . The data criticality quantification standard is set as follows: by analyzing the impact range and criticality of downstream dependencies of data in the business process, the levels are divided: {"non-critical data": 0.1, "internal operation data": 0.5, "core business data": 1.0, "financial / compliance data": 1.5}. stock_level is a key basis for subsequent payment decisions and is defined as "core business data", so .
[0140] The criticality impact factor is set. The setting of this factor refers to the root cause analysis (RCA) of 100 historical business interruption events. By statistically analyzing the relationship between the average loss ( ) caused by errors of different criticality data ( ) and the tool base cost ( ), a scaling coefficient is calibrated. Set . Update the cumulative cost value . The cumulative cost value before updating is obtained (from the tool_authenticate tool). The formula is explained in detail as follows: represents the updated cumulative cost value. represents the cumulative cost value before updating, the current value is , which is the risk-adjusted cost accumulated by the first tools in the sequence (tool_authenticate). represents the execution cost vector of the current tool (tool_queryStock), whose value is . represents the criticality impact factor, set to , used to scale the cost impact of data criticality. represents the data criticality, the current value is This quantifies the importance of the tool_queryStock output data. The calculation logic of this formula is to accumulate the base cost of the current tool. First, go through This item calculates a "risk inflation coefficient" ( Multiply this coefficient by the base cost. This yields the "risk-adjusted cost" of the tool. Finally, this risk-adjusted cost is added to the previously accumulated cost. Above. Substitute the values into the calculation:
[0141] Obtain the preset cost threshold. This threshold is set based on the "Real-time Order Processing" Service Level Agreement (SLA) budget for the business process, and is set to [value missing]. Determine the updated cumulative cost value. Is it greater than . No cost overruns occurred.
[0142] The simulation state update submodule is executed. The post-effect `order_stock_confirmed:true` of Tool_2 and its simulation output `stock_level:50` are updated to the simulation execution state. The State becomes `{"user_session_active":true,"stock_level":50,"order_stock_confirmed":true}`.
[0143] (Then, traverse) Precondition validation for Tool_3 ("tool_processPayment"): The preconditions ["user_session_active", "order_stock_confirmed"] of Tool_3 both exist in State and are true, so the validation passes. Data dependency check: The parameter amount(550.00) is a literal, so it passes. Execution cost accumulation: Get (fortool_processPayment), its value is calculated in S100: Get (transaction_id and payment_status) are defined as "financial / compliance data". Get (From the previous two steps). The advantage of the formula is that, through and The introduction of this makes cumulative cost to dynamically reflect the potential risk amplification effect brought by tools involving high criticality data (such as financial data ) in the execution sequence, rather than just the linear accumulation of the base cost. Determine whether . is greater than .
[0144] Mark the cost overrun in Conflicts. The result shows that, although the dependency relationship of the sequence is complete, the cumulative risk-adjusted cost exceeds the budget threshold of
[0145] . The sequence conflict set will be passed to the execution sequence modification module. Figure 1 Figure 5 Referring to and
[0146] , the execution sequence modification module calls a large language model to adjust the candidate tool invocation sequence according to data dependency conflicts or cost overruns based on the sequence conflict set as a prompt until the sequence conflict set is empty, and outputs the automated AI application execution flow.
[0147] The conflict information parsing submodule obtains the sequence conflict set and parses the missing data items, conflict tool indexes, and cost overrun markers included in the sequence conflict set;
[0148] The revision prompt generation submodule organizes the missing data items, conflict tool indexes, and cost overrun markers into revision prompt words, calls a large language model to obtain revision strategies for data dependency conflicts or cost overruns based on the revision prompt words as input;
[0149] The candidate sequence adjustment submodule adjusts the sequence execution order, tool identifier list, or parameter binding set in the candidate tool invocation sequence based on the revision strategies to generate an updated candidate tool invocation sequence;
[0150] The iterative loop control submodule passes the updated candidate tool invocation sequence back to the sequence simulation verification module for a new round of verification, obtains a new sequence conflict set, and determines whether the new sequence conflict set is empty;
[0151] The sequence output submodule terminates the iteration if the new sequence conflict set is empty, defines the sequence execution order included in the updated candidate tool call sequence as the corrected tool order, defines the parameter binding set included therein as the verified parameter set, and extracts the cumulative cost value as the total execution cost, and generates the automated AI application execution flow by combination;
[0152] The process of adjustment of the candidate sequence adjustment submodule based on the correction strategy includes:
[0153] The correction strategy is obtained, and the type of the correction strategy is judged;
[0154] If the type of the correction strategy is data dependency adjustment, the missing data item is parsed, the supplementary tool node capable of generating the missing data item is searched in the business process and the tool graph, the supplementary tool node is inserted before the position corresponding to the conflict tool index, and the sequence execution order, the tool identifier list and the parameter binding set are updated;
[0155] If the type of the correction strategy is cost overrun adjustment, the tool node with the highest execution cost vector value in the candidate tool call sequence is identified, the alternative tool node with the same post-effect but lower execution cost vector value is searched in the business process and the tool graph, the alternative tool node is used to replace the tool node with the highest execution cost vector value, and the tool identifier list is updated;
[0156] The updated candidate tool call sequence is generated;
[0157] The automated AI application execution flow is specifically the corrected tool order, the verified parameter set, and the total execution cost.
[0158] The execution sequence correction module is started, and the conflict information parsing submodule first obtains the sequence conflict set generated in the last step (S300): {"missing_data":[],"conflict_index":[],"cost_overrun":true,"cumulative_cost":0.315726}. The submodule parses the set and extracts: the missing data item list is empty, the conflict tool index list is empty, and the cost overrun flag is true.
[0159] The correction hint generation submodule organizes these parsed information into a structured correction hint word, which will be provided as input to the large language model. Hint word example: "Task":"Fix_Tool_Sequence","Current_Sequence":["tool_authenticate","tool_queryStock","tool_processPayment"],"Conflict":{"Type":"Cost_Overrun","Threshold":0.25,"Actual_Cost":0.315726},"Cost_Details":[{"Tool":"tool_authenticate","Inflated_Cost":0.022,"Base_Cost":0.02},{"Tool":"tool_queryStock","Inflated_Cost":0.051432,"Base_Cost":0.04286},{"Tool":"tool_processPayment","Inflated_Cost":0.242294,"Base_Cost":0.18638}],"Graph_Context":[{"Tool":"tool_processPayment","Post-Effect":"payment_transaction_generated","Base_Cost":0.18638},{"Tool":"tool_processPayment_async","Post-Effect":"payment_transaction_generated","Base_Cost":0.095}]The large language model is called, the model receives this input, analyzes the Conflict type as Cost_Overrun, and identifies tool_processPayment's Inflated_Cost(0.242294) as the largest cost contributor in Cost_Details. The model searches Graph_Context for tools with the same Post-Effect(payment_transaction_generated) but lower Base_Cost. The model identifies tool_processPayment_async (base cost 0.095) as a viable alternative.Generate the revised strategy: {"Strategy_Type":"cost_overrun_adjustment","Action":"replace","Tool_Index":3,"Replacement_Tool":"tool_processPayment_async"}.
[0160] The candidate sequence adjustment submodule obtains the revised strategy and determines that the type of the revised strategy is cost_overrun_adjustment. The submodule identifies the tool node tool_processPayment (the base cost ) with the highest execution cost vector value in the candidate tool invocation sequence (index 3). In the business process and tool graph, search for an alternative tool node with the same postcondition payment_transaction_generated but a lower execution cost vector value. The search result is tool_processPayment_async, which has a base cost (the value comes from the graph, assuming that it , is the same, and the calculated value is 0.5). , which satisfies the replacement condition. Replace tool_processPayment with tool_processPayment_async and update the tool identifier list. Generate the updated candidate tool invocation sequence ["tool_authenticate", "tool_queryStock", "tool_processPayment_async"].
[0161] The iteration loop control submodule returns the updated candidate tool invocation sequence to the sequence simulation verification module (S300) for a new round of verification. The sequence simulation verification module (S300) re-executes: Step 1 (tool_authenticate): . Update State. Step 2 (tool_queryStock): . Update State. Step 3 (tool_processPayment_async): . . (both output data criticality values are the same). . Determine whether is greater than . , the check passes. The sequence simulation check module returns a new sequence conflict set: {} (empty set). The iteration loop control submodule judges that the new sequence conflict set is empty.
[0162] The sequence output submodule terminates the iteration. The candidate tool invocation sequence that passed the last check is parsed. The sequence execution order [1, 2, 3] therein is defined as the corrected tool order. The parameter binding set (containing the bindings of tool_authenticate, tool_queryStock, and tool_processPayment_async) therein is defined as the verified parameter set. The cumulative cost value returned by the last successful check S300 is extracted as the total execution cost. The automated AI application execution flow is generated: {"Corrected_Order":["tool_authenticate","tool_queryStock","tool_processPayment_async"],"Verified_Params":[...bindings...],"Total_Cost":0.248932}.
[0163] The above embodiments demonstrate the preferred implementation of the present application, and any equivalent adjustment to the technical solution based on software engineering methods falls within the protection scope, including but not limited to: implementing algorithm logic in different programming languages, service-oriented reconstruction of functional modules, adjustment of data interaction protocols, optimization of resource scheduling strategies, etc. Any implementation derived through reasonable modification of the data processing flow, service invocation link, or system architecture level without deviating from the technical core of the present application shall be considered within the protection scope defined by the claims of the present application.< / sequenceflow> < / task>
Claims
1. An AI application development system for multiple industries, characterized in that, The system includes: The business graph construction module acquires business process model data and tool capability description information, analyzes the tool capability description information to define preconditions, post-effects and execution cost vectors, constructs a business process and tool graph, and transmits it to the tool sequence generation module and sequence simulation verification module. The tool sequence generation module obtains business automation requirements, prompts a large language model to decompose the business automation requirements based on the business process and tool graph, matches the tools, generates a candidate tool call sequence, and transmits it to the sequence simulation and verification module. The sequence simulation and verification module simulates execution based on the candidate tool call sequence and the business process and tool graph, judges the matching of the preconditions and accumulates the execution cost vector, calculates data dependency conflicts and cost exceedances, generates a sequence conflict set, and transmits it to the execution sequence correction module. The execution sequence correction module calls the large language model, uses the sequence conflict set as a prompt, and iteratively adjusts the candidate tool call sequence according to the data dependency conflict or the cost overrun adjustment tool until the sequence conflict set is empty, and outputs the automated AI application execution flow.
2. The AI application development system for multiple industries according to claim 1, characterized in that, The business process and tool graph includes tool nodes, process dependencies, and data flow edges. The candidate tool call sequence specifically refers to the sequence execution order, tool identifier list, and parameter binding set. The sequence conflict set includes missing data items, conflict tool indexes, and cumulative cost values. The automated AI application execution flow specifically includes the corrected tool order, verified parameter set, and total execution cost.
3. The AI application development system for multiple industries according to claim 2, characterized in that, The specific functional implementation of the business graph construction module is as follows: The process data acquisition submodule acquires business process model data and tool capability description information; The tool attribute parsing submodule analyzes the functional constraints and resource consumption included in the tool capability description information, extracts the tool input parameters, output parameters, the preconditions and the post-effects, quantifies the resource consumption, and generates the execution cost vector. The business graph mapping submodule parses the business process model data, identifies the business nodes and business logic relationships, and constructs an initial business graph based on the business logic relationships and the process dependency relationships. The graph fusion and association submodule maps the tool input parameters and the tool output parameters to the data flow edges, and attaches the tool nodes to the business nodes of the initial business graph according to the preconditions and post-effects, thereby generating the business process and tool graph.
4. The AI application development system for multiple industries according to claim 3, characterized in that, The process by which the tool attribute parsing submodule generates the execution cost vector includes: Obtain the raw indicator data regarding computing resource consumption, API call frequency, and expected execution time from the tool's capability description information; Set the resource weight factor corresponding to the computing resource usage, the call weight factor corresponding to the API call frequency, and the time weight factor corresponding to the expected execution time; The original indicator data is normalized to obtain the normalized values of computing resource usage, API call frequency, and expected execution time. The execution cost vector is obtained by weighted summation. The calculation formula is: ; in, Represents the execution cost vector, The normalized value representing the computing resources. Represents the resource weighting factor, A normalized value representing the frequency of the API calls. This represents the call weight factor. A normalized value representing the expected execution time. This represents the time weighting factor.
5. The AI application development system for multiple industries according to claim 4, characterized in that, The specific function of the tool sequence generation module is as follows: The requirement semantic parsing submodule obtains the business automation requirement, calls the large language model to analyze the semantic intent of the business automation requirement, and breaks it down into multi-stage sub-tasks; The graph tool matching submodule obtains the business process and tool graph, traverses the multi-stage sub-tasks, searches the business process and tool graph for tool nodes that match the semantic intent and data requirements of the multi-stage sub-tasks, and generates a candidate tool set. The sequence path planning submodule sorts the tool nodes in the candidate toolset based on the process dependency relationship and the data flow edge, constructs an initial tool path, and generates the sequence execution order and the tool identifier list; The parameter instance binding submodule parses the specific parameter values carried in the multi-stage subtasks, binds the specific parameter values with the input parameters of the corresponding tools in the tool identifier list according to the data flow direction edge, generates the parameter binding set, and combines the sequence execution order, the tool identifier list and the parameter binding set to obtain the candidate tool call sequence.
6. The AI application development system for multiple industries according to claim 5, characterized in that, The process by which the graph tool matching submodule searches for matching tool nodes includes: Obtain the semantic intent of the multi-stage sub-tasks and convert it into a task requirement vector using a text embedding model; Obtain the tool capability description information of multiple tool nodes in the business process and tool graph, and use the text embedding model to convert the tool capability description information into a tool capability vector; Calculate the cosine similarity between the task requirement vector and all tool capability vectors to obtain a similarity score; Set a similarity matching threshold, and filter the tool nodes whose similarity scores are greater than the similarity matching threshold to form a preliminary candidate list; Verify whether the input parameters required by the tool nodes in the preliminary candidate list are consistent with the available data output type of the multi-stage subtask, filter out the tool nodes with mismatched data types, and generate the candidate toolset.
7. The AI application development system for multiple industries according to claim 6, characterized in that, The specific functions of the sequence simulation verification module are as follows: The simulation environment initialization submodule obtains the candidate tool call sequence and the business process and tool graph, and initializes an empty simulation execution state and an empty sequence conflict set; The tool traverses the sub-modules level by level, extracts the tool nodes one by one from the tool identifier list according to the execution order of the sequence, and obtains the corresponding precondition and parameter binding set; The precondition verification submodule determines whether the precondition is satisfied by the simulated execution state. If not, it records the index of the tool node as the conflicting tool index and records the missing precondition in the simulated execution state as the missing data item. The data dependency checking submodule verifies whether the required data in the parameter binding set exists in the simulated execution state. If it does not exist, it records the index of the tool node as the conflicting tool index and records the required data as the missing data item. The execution cost accumulation submodule obtains the execution cost vector of the tool node, accumulates it to the global cumulative cost value, and determines whether the cumulative cost value exceeds a preset cost threshold. If it does, it determines that the cost has exceeded the limit. The simulation state update submodule, if the verification passes, updates the post-effect of the tool node to the simulation execution state for the verification of the tool node; The conflict set generation submodule summarizes the missing data items, conflict tool indexes, and cumulative cost values of all records to generate the sequence conflict set.
8. The AI application development system for multiple industries according to claim 7, characterized in that, The implementation process of the data dependency checking submodule and the execution cost accumulation submodule includes: Obtain the parameter binding set of the tool node, and traverse each required data item declared in the parameter binding set; In the simulated execution state, query whether the required data exists. If the data does not exist, mark the required data as the missing data item, record the index of the tool node as the conflict tool index, and store it in the sequence conflict set. If the data dependency check passes, the execution cost vector of the tool node is obtained, and the data criticality associated with the output data of the tool node in the business process and tool graph is obtained. ; Setting key influence factors and update the cumulative cost value. The calculation formula is: ; in, This represents the cumulative cost value before the update. The vector representing the execution cost of the tool node. This represents the key influence factor. This represents the criticality of the data. Obtain the preset cost threshold and determine the updated cumulative cost value. If the cost exceeds the preset cost threshold, then mark the cost exceeding the limit in the sequence conflict set.
9. The AI application development system for multiple industries according to claim 8, characterized in that, The specific function of the execution sequence correction module is as follows: The conflict information parsing submodule obtains the sequence conflict set and parses the missing data items, the conflict tool index, and the cost overrun flag included in the sequence conflict set. The correction suggestion generation submodule organizes the missing data item, the conflict tool index, and the cost exceedance marker into correction suggestion words, calls the large language model, and uses the correction suggestion words as input to obtain correction strategies for the data dependency conflict or the cost exceedance. The candidate sequence adjustment submodule, based on the correction strategy, adjusts the sequence execution order, the tool identifier list, or the parameter binding set in the candidate tool call sequence to generate an updated candidate tool call sequence; The iterative loop control submodule returns the updated candidate tool call sequence to the sequence simulation verification module for a new round of verification, obtains a new sequence conflict set, and determines whether the new sequence conflict set is empty. If the new sequence conflict set is empty, the sequence output submodule terminates the iteration, defines the sequence execution order included in the updated candidate tool call sequence as the corrected tool order, defines the parameter binding set included in it as the verified parameter set, extracts the cumulative cost value as the total execution cost, and combines them to generate the automated AI application execution flow.
10. The AI application development system for multiple industries according to claim 9, characterized in that, The process by which the candidate sequence adjustment submodule adjusts the sequence based on the correction strategy includes: Obtain the correction strategy and determine the type of the correction strategy; If the type of the correction strategy is data dependency adjustment, then the missing data item is parsed, a supplementary tool node that can generate the missing data item is searched in the business process and tool graph, the supplementary tool node is inserted before the position corresponding to the conflict tool index, and the sequence execution order, the tool identifier list and the parameter binding set are updated. If the type of the correction strategy is cost over-limit adjustment, then identify the tool node with the highest execution cost vector value in the candidate tool call sequence, search for an alternative tool node with the same aftereffect but a lower execution cost vector value in the business process and tool graph, replace the tool node with the highest execution cost vector value with the alternative tool node, and update the tool identifier list; Generate the updated candidate tool call sequence.