Workflow generation execution method and device, computer device and storage medium

Abstract

The application relates to a workflow generation and execution method and device, computer equipment and a storage medium. The method is applied to the generation and execution of a scientific research computing workflow, and comprises the following steps: based on a scientific research computing task submitted by a user in a natural language instruction, calling a preset large language model to output a workflow plan; performing first static checking on the workflow plan to obtain a first checking result, and saving the workflow plan when there is no blocking saving item in the first checking result; when there is a missing tool item in the first checking result, calling a missing tool generation node to generate a target tool corresponding to the missing tool item; in response to a start instruction for the saved workflow plan, performing second static checking on the saved workflow plan to obtain a second checking result, and executing the saved workflow plan when there is no blocking execution item in the second checking result. The method can improve the stability and safety of the generation and execution of a scientific research computing workflow plan.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a workflow generation and execution method, apparatus, computer device, and storage medium. Background Technology

[0002] With the development of artificial intelligence technology, large language models have been applied to the field of automatic workflow generation, which can automatically generate workflow plans containing multiple nodes and dependencies based on users' natural language descriptions.

[0003] However, due to the uncertainty of the content generated by large language models, the generated workflow plans often suffer from problems such as loops, missing tools, and parameter errors. This is especially true in scientific computing scenarios such as computational biology, computational chemistry, molecular simulation, sequence analysis, structure prediction, and data processing. Workflow errors caused by these problems can lead to continuous consumption of computing resources on scientific computing platforms, resulting in resource waste. In traditional techniques, workflow plans are usually only subject to simple format validation. Once the validation is passed, they are saved and executed. This can lead to the incorrect execution of workflow plans with serious errors or that are not ready, still resulting in wasted computing resources and task failure.

[0004] This shows that existing technologies still suffer from low stability and security in the generation and execution of scientific computing workflow plans. Summary of the Invention

[0005] Therefore, it is necessary to provide a workflow generation and execution method, apparatus, computer equipment, and storage medium that can improve the stability and security of scientific research computing workflow plan generation and execution in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a workflow generation and execution method, applied to the generation and execution of scientific research computing workflows, the workflow generation and execution method comprising:

[0007] Based on the scientific computing tasks submitted by users in natural language commands, the system calls a preset large language model to output a workflow plan.

[0008] Perform a first static check on the workflow plan to obtain a first check result for the workflow plan, and save the workflow plan when there are no blocked items in the first check result;

[0009] When there is a missing tool item in the first verification result, the missing tool generation node is invoked to generate the target tool corresponding to the missing tool item;

[0010] In response to the start command for the saved workflow plan, a second static check is performed on the saved workflow plan to obtain a second check result of the saved workflow plan. If there are no blocking execution items in the second check result, the saved workflow plan is executed.

[0011] In one embodiment, the first static verification and the second static verification use the same preset verification rule, and the process of obtaining the preset verification rule includes:

[0012] Get the current user's permission information;

[0013] Based on the permission information, an index is created to determine a preset verification rule that matches the permission information; the preset verification rule includes blocking saved item verification and blocking executed item verification.

[0014] In one embodiment, the step of performing a first static verification on the workflow plan to obtain a first verification result for the workflow plan includes:

[0015] If there is a blocking execution item in the first verification result, the workflow plan is marked as an unexecutable plan.

[0016] In one embodiment, the first static verification and the second static verification each include one or more of the following verification items: directed acyclic graph structure verification, node connectivity verification, tool existence verification, tool permission verification, registration tool input / output contract verification, required parameter verification, variable reference verification, script node static verification, missing tool generated node verification, and verifier anomaly verification.

[0017] In one embodiment, the step of invoking the missing tool generation node to generate the target tool corresponding to the missing tool item includes:

[0018] Based on the expected inputs and expected outputs of the missing tool items, determine the expected input-output contract;

[0019] Input the expected input-output contract into the missing tool generation node;

[0020] Based on the missing tool generation node, a target tool corresponding to the missing tool item is generated.

[0021] In one embodiment, generating the target tool corresponding to the missing tool item based on the missing tool generation node includes:

[0022] Based on the missing tool generation node, the preset large language model is invoked to generate the tool file;

[0023] Based on the preset minimum commands, the tool file is tested in the runtime environment corresponding to the tool file, and the tool file that passes the test is determined as the target tool.

[0024] In one embodiment, after generating the target tool corresponding to the missing tool item based on the missing tool generation node, the method further includes:

[0025] Obtain the tool name and release status of the target tool;

[0026] Synchronize the tool name and the release status to the node status field of the missing tool generation node;

[0027] Update the node status of the missing tool-generated node to the completed status.

[0028] Secondly, this application provides a workflow generation and execution device for generating and executing scientific research computing workflows, the workflow generation and execution device comprising:

[0029] The workflow plan generation module is used to output a workflow plan based on the scientific research computing tasks submitted by the user in natural language commands, by calling a preset large language model.

[0030] The server-side plan verification module is used to perform a first static verification on the workflow plan and obtain a first verification result of the workflow plan.

[0031] The workflow plan storage module is used to save the workflow plan when there is no blocked save item in the first verification result;

[0032] The missing tool generation module is used to generate a target tool corresponding to the missing tool item when there is a missing tool item in the first verification result;

[0033] The access control module is configured to, in response to a start command for a saved workflow plan, perform a second static check on the saved workflow plan to obtain a second check result for the saved workflow plan, and execute the saved workflow plan when there are no blocking execution items in the second check result.

[0034] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0035] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0036] The aforementioned workflow generation and execution method, apparatus, computer equipment, and storage medium, based on scientific research computing tasks submitted by users in natural language commands, call a preset large language model to output a workflow plan, achieving automatic parsing and structured conversion of user intent; by performing a first static verification on the workflow plan, a first verification result is obtained, and when no blocking items are found in the first verification result, the workflow plan is saved, thereby effectively filtering malicious code, unauthorized behavior, and other plans that affect the normal operation of the server during the saving process, avoiding the occupation of storage resources and impacting server security; when missing tool items are found in the first verification result, a missing tool generation node is called to generate a target tool corresponding to the missing tool item, thereby enabling... Before executing a scientific computing workflow, missing or needing-to-be-fixed tools are identified in advance to avoid errors in the workflow and resource consumption of the scientific computing platform, thus improving energy efficiency. By responding to the start command of a saved workflow plan, a second static verification is performed on the saved workflow plan to obtain the second verification result. If no blocking execution items are found in the second verification result, the saved workflow plan is executed. Verifying the runtime environment conditions before execution avoids execution failures due to resource unavailability, abnormal parameters, etc., thereby intercepting potential risks at different stages and forming a multi-layered protection mechanism from generation to execution. This improves the stability and security of workflow plan generation and execution. Furthermore, due to the uncertainty of the content generated by the large language model, the probability of a fully generated workflow plan successfully running on the first attempt is low. By retaining and then fixing incomplete workflows with missing parameters, the need for a full regeneration of the plan after each failure is avoided, thus reducing the consumption of large language model calls and lowering model call costs. Attached Figure Description

[0037] Figure 1 This is an application environment diagram of the workflow generation and execution method in one embodiment;

[0038] Figure 2 This is a flowchart illustrating the workflow generation and execution method in one embodiment;

[0039] Figure 3 This is an application environment diagram for the workflow generation and execution method in another embodiment;

[0040] Figure 4 This is a flowchart illustrating the workflow generation and execution method in another embodiment;

[0041] Figure 5 This is a structural block diagram of a workflow generation execution device in one embodiment;

[0042] Figure 6This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] The workflow generation and execution method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Server 104, based on the scientific research computing task submitted by the user on terminal 102 using natural language commands, calls a preset large language model to output a workflow plan; performs a first static check on the workflow plan to obtain a first check result, and saves the workflow plan if there are no blocking items in the first check result; if there are missing tool items in the first check result, calls a missing tool generation node to generate a target tool corresponding to the missing tool item; in response to a start command for the saved workflow plan, performs a second static check on the saved workflow plan to obtain a second check result, and executes the saved workflow plan if there are no blocking execution items in the second check result. The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc., that support one or more interactive commands such as touch, voice, and visual tracking to generate natural language commands from the user. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. The server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0045] In one embodiment, such as Figure 2 As shown, a workflow generation and execution method is provided, applied to the generation and execution of scientific research computing workflows. Taking the application of this method to a server 104 scenario as an example, the workflow generation and execution method includes:

[0046] Step S100: Based on the scientific research computing task submitted by the user in natural language commands, the preset large language model is invoked to output the workflow plan.

[0047] Natural language instructions can be descriptive text input by the user in natural language form, and can include the need to establish or adjust workflows, such as the operational procedures that should be included and the task objectives that need to be achieved. This allows the pre-defined large language model to recognize the user's intent based on the natural language instructions and transform the user's intent into a structured plan.

[0048] Scientific computing tasks can be various computing-related tasks carried out around scenarios such as scientific research and technological development. Their purpose is to support the advancement of scientific research activities through data processing, model computation, and logical analysis. In this embodiment, scientific computing tasks can be proposed by users based on research objectives or by intelligent agents based on automatic identification of business scenarios, using natural language commands. For example, scientific computing tasks may include data cleaning and preprocessing tasks, numerical simulation computing tasks, algorithm optimization and verification tasks, and statistical analysis tasks of academic achievements.

[0049] The pre-defined large language model can be a deep learning language model pre-trained on large-scale text data. It can be trained on corpora such as internet text and technical documents through self-supervised learning. In this embodiment, the pre-defined large language model can be used to parse natural language instructions and transform them into structured workflow plans. The pre-defined large language model can be a local model, a cloud model, or a combination of multiple models. For example, the pre-defined large language model can be an existing large language model service, or it can be obtained by fine-tuning an existing large language model based on a workflow plan corpus, or it can be obtained by self-supervised learning training based on a workflow plan corpus. This embodiment does not limit the scope of the pre-defined large language model.

[0050] A workflow plan can be a structured task execution scheme composed of multiple nodes and their dependencies, which determines the order of task execution, parallel relationships, and data flow paths. For example, depending on the representation method, a workflow plan can adopt one or more of the following: DAG graph structure, JSON format description, YAML configuration, etc.

[0051] For example, calling a preset large language model to output a workflow plan can be achieved by taking the natural language instructions submitted by the user, representing the scientific computing task, as input text and passing them to the preset large language model through an API interface or a local inference interface. The model performs semantic parsing and task decomposition on the instructions, generates a structured workflow plan text containing information such as node definitions, inter-node dependencies, and tool call parameters, and returns it. This can achieve automatic conversion from unstructured natural language to structured workflow plans, reducing the cost of manually writing workflow plans.

[0052] Step S200: Perform a first static check on the workflow plan to obtain the first check result of the workflow plan, and save the workflow plan when there are no blocked items in the first check result.

[0053] The first static validation can be the initial check of the workflow plan after its initial generation. It can be used to identify obvious errors or incompleteness in the workflow plan, thereby determining whether the workflow plan can be saved. For example, the first static validation may include checking whether there are any items in the workflow plan that are serious enough to prevent the workflow plan from being saved.

[0054] The first verification result can be the set of check results output after the first static verification is completed, used to reflect whether there are serious problems in the workflow plan that need to be prevented from being saved. Correspondingly, the save-blocking item can be an error item that is determined to be serious enough to prevent the workflow plan from being saved in the first static verification, used to identify defects that must be corrected or regenerated before saving.

[0055] For example, matters sufficient to prevent the workflow plan from being saved may include matters that affect the normal operation of the server, such as whether there is malicious code in the workflow plan or whether the tools used exceed the current user's available permissions. They may also include matters that improperly operate on the user's files, such as deleting workspace files without the user's manual permission.

[0056] The workflow plan undergoes a first static validation. For example, this can be achieved by parsing the structured data of the workflow plan and checking the completeness of the definition of each node in the plan, the validity of the tool name, the correctness of the parameter format, and the rationality of the dependencies. The results of these checks are then summarized as the first validation result. This allows workflow plans with serious structural defects to be identified and filtered out before saving, preventing invalid plans from entering the storage process.

[0057] Step S300: When there is a missing tool item in the first verification result, call the missing tool generation node to generate the target tool corresponding to the missing tool item.

[0058] Among them, missing tool items can be tool nodes that are determined to be referenced in the workflow plan but are actually undefined or unusable in the first static validation result.

[0059] The missing tool generation node can be a node module in the workflow execution system used to automatically generate tools. For example, it can determine the input and output parameters that the target tool should have based on the missing tool items in the first static verification result, call the internal logic to generate an executable target tool, and register it in the tool library for subsequent use.

[0060] It is understandable that, in addition to checking for missing tool items in the first static check, the second static check can also check for missing tool items. In other words, missing tool items can also be obtained from the results of the second static check, and the missing tool generation node can generate target tools based on the missing tool items in the results of the second static check, thereby ensuring that there are no missing tools before the workflow plan is executed.

[0061] In step S400, in response to the start command for the saved workflow plan, a second static verification is performed on the saved workflow plan to obtain the second verification result of the saved workflow plan. If there are no blocking execution items in the second verification result, the saved workflow plan is executed.

[0062] The saved workflow plan can be a workflow plan that has passed the first static verification and been stored in the persistent medium.

[0063] A start command can be a command signal issued by a user, agent, or system to trigger the execution of a workflow plan, initiating the workflow from the pending state to the execution process. Accordingly, different triggering entities can use different triggering methods; therefore, start commands can include, but are not limited to, one or more of the following: manually clicking the execute button, API call triggering, and scheduled task triggering.

[0064] The second static validation can be a second check of the workflow plan before execution. It can be used to identify potential failures or anomalies that may occur during the execution phase, thereby determining whether the workflow plan can be executed. For example, the first static validation may include checking whether there are any items in the workflow plan that are serious enough to prevent the workflow plan from being saved. For example, depending on the validation dimensions, the second static validation may include, but is not limited to, one or more of the following: resource availability validation, dependent service connectivity validation, and parameter value range validation.

[0065] The second verification result can be a set of inspection conclusions output after the second static verification is completed, which can be used to reflect whether the workflow plan has the conditions for execution. Correspondingly, blocking execution items can be error items that are determined in the second static verification to be severe enough to prevent the workflow plan from executing, and can be used to identify defects that must be fixed before execution can begin. For example, depending on the error type, blocking execution items can include, but are not limited to, one or more of the following: tool service unavailability, parameter value out of bounds, missing environment configuration, etc. In this application, the danger of blocking save items to the server is higher than that of blocking execution items. When there are no issues affecting server execution in the workflow plan, but only repairable situations such as incomplete workflow plans, the plan can be saved first, and then the preset large language model or intelligent agent can be called again, or the user can manually adjust it.

[0066] Correspondingly, by listening to the start signal sent by the user, intelligent agent, or system, and based on the workflow plan identifier carried in the start command, the corresponding saved workflow plan data can be read from the storage medium. Then, a second static verification can be performed on the saved workflow plan. For example, the second static verification could involve reading the complete data of the saved workflow plan, performing availability checks on the external tools or services that each node depends on, validating the range and type of parameter values, and checking the consistency of data transmission paths between nodes. The results of these checks are then summarized as the second verification result. This allows for the identification and filtering of execution risks caused by changes in the operating environment or resource unavailability before execution, preventing immediate failure after startup.

[0067] Correspondingly, executing a saved workflow plan can be done by sequentially or in parallel calling the tools or services corresponding to each node according to the node order and dependencies defined in the workflow plan, passing the required parameters, collecting execution results, until all nodes have been executed or a termination condition is encountered. Since the executability has been verified before execution, the stability and effectiveness of the scientific computing workflow plan during execution can be improved.

[0068] This embodiment provides a workflow generation and execution method. Based on research computing tasks submitted by users using natural language commands, it calls a preset large language model to output a workflow plan, achieving automatic parsing and structured conversion of user intent. A first static check is performed on the workflow plan to obtain a first check result. If no blocking items are found in the first check result, the workflow plan is saved. This effectively filters malicious code, unauthorized behavior, and other plans that could affect the normal operation of the server during the saving process, avoiding the consumption of storage resources and impacting server security. When a missing tool item is found in the first check result, a missing tool generation node is invoked to generate a target tool corresponding to the missing tool item, thereby enabling the execution of the task. Before implementing a computational workflow, missing or needing-to-be-fixed tools are identified in advance to prevent errors from consuming resources on the research computing platform and improve energy efficiency. By responding to the start command of a saved workflow plan, a second static check is performed on the saved workflow plan to obtain the second check result. If no blocking execution items are found in the second check result, the saved workflow plan is executed. Verifying the runtime environment conditions before execution avoids execution failures due to resource unavailability, abnormal parameters, etc. This allows for the interception of potential risks at different stages, forming a multi-layered protection mechanism from generation to execution, thereby improving the stability and security of workflow plan generation and execution. Furthermore, due to the uncertainty of the content generated by the large language model, the probability of a fully generated workflow plan successfully running on the first attempt is low. By using a mechanism to retain and then fix incomplete workflows with missing parameters, the need for a full regeneration of the plan after each failure is avoided, thus reducing the overhead of calling the large language model and lowering model call costs.

[0069] In one embodiment, the process of obtaining the preset verification rules includes:

[0070] Get the current user's permission information;

[0071] Indexing is performed based on permission information, and preset verification rules that match the permission information are determined.

[0072] The current user's permission information can be a set of data describing one or more of the user's operation permissions, role level, access scope, etc. in the workflow system. It can be used as the basis for verifying rule matching, thereby distinguishing the scope of workflow plans that different users can execute or view.

[0073] In this embodiment, the first static verification and the second static verification can employ the same preset verification rules. These preset verification rules can be a predefined and stored set of rules used to check the correctness and completeness of the workflow plan, and can be used as the basis for executing the first and second static verifications. For example, depending on the verification dimension, the preset verification rules may include, but are not limited to, one or more of the following: node integrity rules, tool name validity rules, parameter format rules, dependency rules, and resource availability rules.

[0074] In this embodiment, the preset verification rules include blocking save item verification and blocking execution item verification. The blocking save item verification can be performed on items that are sufficient to prevent the workflow plan from being saved, including items that affect the normal operation of the server. The blocking execution item verification can be performed on items that are sufficient to prevent the workflow plan from being saved.

[0075] Understandably, the first and second static checks are based on preset check rules. The generation of blocked save items and blocked execution items can be checked and executed independently. There may be a long time interval between saving and execution. Therefore, rereading the latest plan, tool status, permissions and release status before execution for the second static check can effectively avoid malicious modification of the workflow plan or execution errors between saving and execution.

[0076] Indexing based on permission information determines preset verification rules that match that information. For example, the obtained permission information can be used as query conditions to perform a matching search in a preset verification rule base. The rules or rule sets in the rule base can be associated with one or more permission identifiers. By analyzing the correspondence between permission information and rule permission identifiers, a set of verification rules matching the current user's permissions is selected. This allows for dynamic adaptation of verification rules, enabling users with different permissions to use different verification standards when saving and executing workflow plans. For instance, ordinary users may be subject to stricter parameter ranges and limited available tools, while administrator users may have more lenient verification conditions, thus achieving the technical effect of providing flexible permission control capabilities while ensuring system security.

[0077] This embodiment provides a workflow generation and execution method that uses the same preset verification rules in the first and second static verifications, obtains the current user's permission information, and then indexes based on the permission information to determine the preset verification rules that match the permission information. It can dynamically select the applicable set of verification rules according to the current user's permissions, and realize role-based differentiated verification control at the system level. The use of the same preset verification rules in the first and second static verifications can ensure the consistency of the verification standards for the same user in the saving and execution phases, avoiding the situation where saving passes but execution fails due to inconsistent rules. This achieves the technical effect of further improving the security, controllability and stability of the workflow plan generation and execution process.

[0078] In one embodiment, after performing a first static verification on the workflow plan and obtaining the first verification result of the workflow plan, the process includes:

[0079] If a blocking execution item is found in the first verification result, the workflow plan will be marked as an unexecutable plan.

[0080] Among them, execution blocking items can be defects identified in the first static verification phase that are severe enough to cause the workflow plan to inevitably fail or produce errors in subsequent execution phases. They can be used to identify defects that, even if structurally complete, have execution risks, preventing the workflow plan from being marked as executable. For example, depending on the defect type, execution blocking items may represent situations such as tool service unavailability, parameter value out of bounds, or dependent nodes not existing.

[0081] An unexecutable plan can be a workflow plan marked as not meeting the execution conditions; that is, although it is successfully saved, it cannot be started and executed temporarily. Understandably, by preventing workflow plans with serious execution risks from entering the execution phase at the state level, we can avoid directly executing plans that have passed the first static validation as unexecutable and have not been modified. This also reduces unnecessary repeated validation of verification items and decreases server-side computing power consumption.

[0082] Marking a workflow plan as unexecutable can be achieved, for example, by parsing the first static validation result after completion. If a blocking execution item is detected, the unique identifier of the workflow plan is obtained, and its status field is set to "unexecutable" or an equivalent identifier in the system. Simultaneously, the problem tracing results of the blocking execution item are made available to the user. If the user subsequently corrects the relevant defects, the status can be updated to "executable" through re-validation. This method allows for a preliminary assessment of the workflow plan's execution feasibility during the saving phase. By using a status marking mechanism to isolate plans with execution risks from those that can be executed normally, it can prevent users or the system from accidentally starting unexecutable plans, reducing the failure rate and resource waste during the execution phase.

[0083] This embodiment provides a workflow generation and execution method. After the first static verification is completed, if there are blocking execution items in the first verification result, the workflow plan is marked as an unexecutable plan. When the rules of the first static verification and the second static verification are the same, the first static verification can further predict serious problems that may lead to execution failure, and the workflow plan with such problems is directly marked as an unexecutable plan after saving. This not only completes the initial filtering of execution risks, but also allows the system to automatically block the start entry of the unexecutable plan, avoiding invalid execution triggered by user misoperation or automated scheduling, thereby further reducing the waste of computing resources and achieving the technical effect of improving the stability and controllability of scientific research computing workflow plans from generation to execution.

[0084] In one embodiment, the first static verification and the second static verification each include one or more of the following verification items: directed acyclic graph structure verification, node connectivity verification, tool existence verification, tool permission verification, registration tool input / output contract verification, required parameter verification, variable reference verification, script node static verification, missing tool generated node verification, and verifier anomaly verification.

[0085] Directed acyclic graph (DAG) structure verification can be used to check the graph structure formed by the dependencies between nodes in a workflow plan, confirming that it does not contain loops. This can be used to ensure that the workflow plan can be executed sequentially in the topology, avoiding infinite loops or deadlocks caused by circular dependencies. For example, DAG structure verification can check for the existence of loops, entry nodes, and whether the downstream nodes of scatter nodes conform to rules.

[0086] Node connectivity verification can check whether all nodes in the workflow plan form a connected path through dependencies, and whether there are isolated or unreachable nodes. It can ensure that each node can be accessed from the starting node or input node, and avoid some nodes failing to trigger during execution due to the lack of prerequisites.

[0087] Tool existence verification can check whether the tool name or tool identifier referenced by each node in the workflow plan actually exists in the registered tool library, preventing execution failure due to the inability to find the corresponding executable program because a non-existent tool is referenced. For example, for a tool node, it can check whether the corresponding tool exists in the tool registry; for a completed missing tool generation node, it can check whether the generated tool name has been backfilled.

[0088] Tool permission verification checks whether the current execution context or user identity has the necessary access permissions to invoke various tools in the workflow plan. This prevents tool calls from being denied due to insufficient permissions, ensuring system security and resource access control. For example, tool permission verification might check whether the current user has permission to access the tool; if a missing tool generation node only allows developers to create or execute it, then the user type is checked.

[0089] Input / output contract validation for registration tools involves comparing the input parameter types, output result types, and data formats declared during tool registration to check whether the parameters actually passed in the workflow plan conform to the contract definition. This ensures that the parameter types and quantities passed when the tool is invoked are correct, and that subsequent nodes can correctly parse the output data of preceding nodes. For example, input / output contract validation for registration tools can read the input / output contracts in the tool's registry, check whether variable references and edges in the workflow plan reference actual existing output ports, and check whether required inputs are bound.

[0090] Required parameter validation checks whether all parameters marked as required have been filled in at each node of the workflow plan. This prevents errors caused by missing parameters leading to insufficient input during tool execution. For example, required parameter validation can read the tool form or parameter pattern to check if required fields exist and are not empty. For arrays or nested fields, it can be parsed according to their structural path.

[0091] Variable reference validation checks whether the variable names referenced in node parameters within a workflow plan can be found in the current scope, thus preventing undefined or misspelled variables from failing to resolve their values ​​during execution. For example, variable reference validation can recursively scan variable references appearing in node parameters, checking if the reference path conforms to syntax, if the referenced node exists, and if the referenced output port exists, etc.

[0092] Static validation of script nodes involves performing syntax checks and basic logic analysis on nodes composed of user-defined scripts within a workflow plan. This can proactively identify syntax errors, undefined variables, or potential runtime exceptions in the script, preventing script crashes during execution. For example, static validation can check whether imported modules are allowed in the runtime environment, whether the script reads non-existent parameter keys, whether the script contains return statements, whether the return dictionary contains declared output keys, and whether template syntax that should only appear in parameter fields has been incorrectly written in the script code.

[0093] Missing tool generation node verification can detect whether there are nodes in the workflow plan that reference unregistered tools, and determine whether the tool can be completed by automatically generating the node. This can identify blocking items caused by missing tools and provide the possibility of automatic node generation to reduce manual repair costs. For example, missing tool generation node verification can check whether the node is allowed for use by the current user, whether the tool generation session has been created, whether the generation status is complete, and whether the generation tool has been published to the tool registry. If it has not been completed, a warning or execution blocking issue will be generated.

[0094] Validator exception detection can detect whether the validator itself encounters an exception during operation, such as a validation logic crash, timeout, or unavailability of dependent resources. This prevents inaccurate validation results or interruption of the validation process due to validator exceptions, ensuring the reliability of the validation process. For example, if an exception occurs within the validator, the system can return a problem object that blocks execution, instead of defaulting to scheduled execution.

[0095] It is understandable that the first static validation and the second static validation can use different validation rules, or they can use the same validation rules. For example, the first static validation can be a validation of blocked saved items. Based on the criteria for determining normal server operation, validation items that may affect the normal operation of the server can be included in the validation rule set of the first static validation. The second static validation can be a validation of blocked execution items, or it can be a full validation. The first static validation can also use the same validation rules as the second static validation to ensure that the validation standards for generating and executing workflow plans are consistent.

[0096] Specifically, the first static check and the second static check can flexibly combine multiple check items and achieve a comprehensive check of different dimensions of the workflow plan through parallel, serial or mixed execution.

[0097] This embodiment provides a workflow generation and execution method that incorporates multiple verification items into the first and second static verification processes. These include directed acyclic graph structure verification, node connectivity verification, tool existence verification, tool permission verification, registration tool input / output contract verification, required parameter verification, variable reference verification, script node static verification, missing tool generation node verification, and verifyer anomaly verification. This allows the workflow plan to undergo systematic checks from multiple dimensions, such as graph structure integrity, tool resource availability, parameter contract consistency, variable parsing correctness, script syntax correctness, permission compliance, and the reliability of the verification process itself, before saving and executing. This overcomes the limitations of traditional simple format verification, which only checks... The analysis examines grammatical deficiencies. Specifically, checks on the directed acyclic graph structure and node connectivity ensure the executability of the workflow topology logic; checks on tool existence and permissions ensure the accessibility of tool resources during execution; checks on registered tool input / output contracts and required parameters ensure the accuracy of parameter passing; checks on variable references and static script nodes ensure potential errors during dynamic execution; checks on missing tool generation nodes automatically correct for missing tools; and checks on validators for anomalies ensure the robustness of the verification mechanism itself. Combining one or more of these checks further enhances the stability and security of workflow plan generation and execution.

[0098] In one embodiment, the missing tool generation node is invoked to generate the target tool corresponding to the missing tool item, including:

[0099] Determine the expected input-output contract based on the expected input and expected output of the missing tool item;

[0100] Input the expected input / output contract into the missing tool generation node;

[0101] Based on the missing tool generation node, generate the target tool corresponding to the missing tool item.

[0102] The expected input can be one or more of the data formats, types, and structure descriptions that the missing tool item in the workflow plan should receive. It can define the input parameter specifications that the target tool needs to receive when it is invoked. For example, depending on the data type, the expected input can include, but is not limited to, one or more of the following: JSON object structure, parameter list, file format specifications, etc.

[0103] The expected output can be one or more of the data format, type, and structure description that a missing tool item in the workflow plan should return. It can define the specifications of the results that the target tool should output after execution. For example, depending on the data type, the expected output can include, but is not limited to, one or more of the following: JSON object structure, return value type, and file format specifications.

[0104] Correspondingly, the expected input-output contract can be an interface specification description composed of the expected inputs and expected outputs of the missing tool item. As the input constraint condition when the missing tool generation node generates the target tool, it can ensure that the generated tool matches the data transfer requirements of the preceding and following nodes in the workflow plan.

[0105] In this embodiment, the missing tool generation node can be a node module in the workflow execution system used to automatically generate tools. By receiving expected input-output contracts as input, it can generate executable target tools according to internal logic and register them in the tool library for subsequent use.

[0106] A target tool can be a specific tool entity that can be invoked by a workflow plan and is automatically generated by a missing tool generation node based on the expected input-output contract. For example, depending on the implementation, a target tool can be one or more of the following: API interface, function module, script program, containerized service.

[0107] The system generates target tools corresponding to missing tool items. For example, after receiving the expected input-output contract, the missing tool generation node parses the input-output structure in the contract, automatically writes or assembles the code logic to implement the corresponding function based on the input-output structure, compiles or encapsulates the generated code to generate a tool entity that can be called by the workflow engine, and registers the tool in the tool library so that it can be referenced by nodes in the workflow plan. This can automatically complete the missing tools in the workflow plan, turning a workflow plan that could not be executed due to missing tools into a complete and executable state, reducing the workload of manual intervention in writing tools, and improving the automatic repair capability of the workflow plan.

[0108] This embodiment provides a workflow generation and execution method. After identifying missing tool items through the first static check, it determines the expected input-output contract of the missing tool item based on its context information in the workflow plan, and inputs the contract into the missing tool generation node to automatically generate the corresponding target tool. This method can automatically repair tool defects in the workflow plan, enabling the workflow plan to have complete execution capability without manual development of missing tools after saving. This reduces the repair cost when tool reference errors are caused by the uncertainty of content generated by large language models. At the same time, the expected input-output contract ensures the consistency of data interfaces between the generated tool and the preceding and following nodes in the workflow plan, avoiding execution failures caused by tool interface mismatches. This further improves the stability and security of workflow plan generation and execution.

[0109] In one embodiment, generating a target tool corresponding to a missing tool item based on a missing tool generation node includes:

[0110] Based on the missing tool generation node, the preset large language model is called to generate tool files;

[0111] Based on the preset minimum commands, the tool file is tested in the runtime environment corresponding to the tool file, and the tool file that passes the test is identified as the target tool.

[0112] The missing tool generation node can be a dedicated node module in the workflow execution system for automatically generating tools. It can receive expected input / output contracts as input, generate an executable target tool through internal logic, and register it in a tool library for later use. For example, depending on the generation method, the missing tool generation node can be a code template-based generation node or a large language model-based generation node; this embodiment does not impose any limitations.

[0113] The preset large language model can be the same as the preset large language model in any of the above embodiments, or it can be a dedicated large language model set according to actual needs.

[0114] Tool files can be executable files or scripts containing tool implementation code and configuration information. They can be generated by a pre-defined large language model based on expected input and output contracts, and can contain code modules such as input parsing, business logic processing, and output formatting.

[0115] The preset minimum command can be a minimal set of test instructions used to verify the basic functions of a tool file. It can automatically generate or predefine a set of minimal input parameters and corresponding expected outputs based on the expected input-output contract of the tool file, thereby enabling verification at the lowest cost whether the tool file can correctly parse the input and produce outputs that conform to the contract.

[0116] The runtime environment can be a set of software and hardware conditions required for the execution of a tool file. Depending on the type and dependency requirements of the tool file, one or more of the corresponding interpreter, compiler, dependency library, and system resources can be configured to provide the runtime conditions for the testing and execution of the tool file.

[0117] Testing tool files can be exemplified by calling the tool file in the runtime environment corresponding to the tool file using a preset minimal command as input parameters, capturing the execution result of the tool file, comparing the execution result with the expected output defined in the preset minimal command, and determining whether the tool file can correctly parse the input and generate output that conforms to the contract. This can verify the basic functional correctness of the tool file with minimal testing cost, prevent tool files that fail basic functional verification from being registered as target tools, and thus avoid workflow execution failure.

[0118] The target tool can be a verified tool entity that can be invoked by the workflow plan, enabling the originally incomplete workflow plan to have full execution capabilities.

[0119] The tool file that passes the test is identified as the target tool. For example, after the tool file passes the test of the preset minimum commands, it can be registered to the tool library. Furthermore, a tool file can be assigned a unique identifier that can be referenced by the workflow plan, making it a target tool that can be called by the workflow engine.

[0120] This embodiment provides a workflow generation and execution method that generates tool files by calling a preset large language model based on missing tool generation nodes. It automatically fills in tool deficiencies using the code generation capabilities of the large language model and tests the tool files within the runtime environment based on preset minimum commands to verify the basic functional correctness of the tool files at minimal cost. Finally, the tool files that pass the test are determined as the target tools, ensuring that only tools that have passed basic functional verification can enter the workflow execution stage. This achieves an automated generation and quality verification closed loop from interface contract to executable tool, filtering out erroneous tools caused by the uncertainty of large language model generation and preventing unverified tools from directly entering the workflow execution stage and causing execution failures. This method can improve the automation level of tool generation while ensuring the functional correctness of the generated tools, thereby further enhancing the stability and security of the workflow planning and execution phase.

[0121] In one embodiment, after generating the target tool corresponding to the missing tool item based on the missing tool generation node, the method further includes:

[0122] Obtain the tool name and release status of the target tool;

[0123] Synchronize the tool name and release status to the node status field of the missing tool generation node;

[0124] Update the node status of missing tool-generated nodes to "completed".

[0125] The tool name can be the identifier of the target tool in the tool library. It can be used to reference the tool in the workflow plan and to distinguish different tool entities in other modules.

[0126] Release status can be a status indicator of whether the target tool has been registered and is available for use by the workflow engine. It can be used to reflect whether the tool has moved from the generation phase to the usability phase. For example, depending on the granularity of the status, release status can include, but is not limited to, one or more of the following: released, not released, in the process of releasing, and release failed.

[0127] For example, obtaining the tool name and release status of the target tool can be done by reading the tool name and release status data from the tool library or the return result of the generation module after the target tool has been generated and registered in the missing tool generation node, thus ensuring that the generation and registration process is executed successfully.

[0128] The node status field can be a data field in the missing tool generation node used to record the current node running status. It is used to store relevant information about the target tool generated by the node and the node's own running progress, which can be queried by the workflow engine or other monitoring modules.

[0129] The "Completed" status can be the final status indicator after the missing tool generation node has completed all generation tasks. It can indicate that the node has successfully generated the target tool and completed information synchronization.

[0130] By updating the node status of a missing tool generation node to "completed," it can be clearly indicated that the generation task of that node has been fully completed. This avoids the workflow engine repeatedly triggering the generation logic of that node in subsequent processes. At the same time, it provides a signal that the preconditions for subsequent steps in the workflow plan that depend on this node have been met. For example, in the case of missing tool items, the "completed" status can serve as a prerequisite for triggering the start command. Thus, when it is clear that a tool is missing, there is no need to perform a second static check, avoiding the consumption of server-side check resources when the execution conditions are obviously missing.

[0131] This embodiment provides a workflow generation and execution method. After the target tool is generated, its tool name and release status are obtained and synchronized to the node status field of the missing tool generation node. Then, the node status is updated to the completed status. This can realize a two-way association between the tool generation result and the generation node status, avoid duplicate generation or process blockage caused by the status not being updated, and achieve the technical effect of improving the execution efficiency of the workflow automatic repair process and the accuracy of status management.

[0132] To more clearly illustrate the technical solution of this application, a detailed embodiment is also provided.

[0133] In scientific computing scenarios such as computational biology, computational chemistry, molecular simulation, sequence analysis, structure prediction, and data processing, users typically need to combine multiple computational tools, scripts, file inputs, model inference steps, and result analysis steps into workflows according to certain dependencies. For example, a workflow may include input file nodes, sequence processing tool nodes, structure prediction tool nodes, result evaluation script nodes, and report generation nodes. Dependencies exist between these nodes, such as file outputs, scalar parameters, directory outputs, and conditional branches. To lower the barrier for scientific users to configure workflows, some systems have begun to use large language models to automatically generate workflows based on natural language requirements, or allow intelligent agents to modify existing workflows during dialogue.

[0134] However, workflow plans generated directly from large language models typically have the following technical risks: loops may exist between nodes; upstream output ports and downstream input ports may not match; variable references may point to non-existent nodes or outputs; some tools may be missing, unpublished, or inaccessible to the current user; required inputs or parameters may be missing; script nodes may contain imported modules that are unavailable in the runtime environment; script return values ​​may be inconsistent with the declared output ports; large language models may mistakenly write template syntax that should only be written to parameter fields into the script code; even if missing tools can be generated by large language models, they may be inconsistent with the upstream and downstream input-output contracts of the workflow, resulting in the inability to pass files or parameters in subsequent execution stages.

[0135] Therefore, for scientific computing workflows, simply achieving "workflow generation based on natural language" is insufficient to guarantee workflow execution. The system also needs to perform structured validation on the plan output by the large language model, distinguishing which issues can be saved as drafts and which issues must be prevented from execution; perform mandatory secondary validation at the execution entry point to prevent the large language model from ignoring validation results and mistakenly triggering execution; when the plan contains missing tool nodes that need to be generated by artificial intelligence, it is also necessary to inject the expected input-output contract of that node into the tool generation prompt, ensuring that the code, configuration files, and port declarations of the generated tool are consistent with the workflow plan, and backfill its status into the workflow node after the tool is built, tested, fixed, and released.

[0136] Through research, the inventors discovered the following problems still exist in traditional techniques:

[0137] (1) Workflow plans generated by large language models lack mandatory security gates before execution. Although existing natural language to workflow generation technologies can automatically generate nodes, edges and parameter configurations, they usually only specify multiple validations or format checks, without forming a mandatory control mechanism for the execution entry point. If the large language model ignores validation feedback in the dialogue, it may still trigger workflow execution with loops, missing inputs, incorrect variable references, or unavailable tools.

[0138] (2) Existing workflow validation results make it difficult to distinguish between "saveable issues" and "non-executable issues". In actual R&D and editing processes, users or large language models may need to save a draft that is not fully configured. If all errors prevent saving, it will affect the editing experience; if all errors are only prompted without being prevented, it may lead to the execution of erroneous plans. Existing technology does not clearly distinguish between issues that block saving and issues that block execution, nor does it use this distinction as a workflow state control condition.

[0139] (3) Existing template validation schemes do not cover the specific engineering constraints of scientific computing workflows. Nodes in scientific computing workflows include not only general steps, but also file inputs, directory outputs, scalar parameters, script nodes, tool nodes, AI generation tool nodes, etc. Existing template validation technologies generally focus on path validation, quality scoring, causal evidence chains, or template optimization, but do not comprehensively check constraints such as tool existence, tool access permissions, tool input / output contracts, variable references, required parameters, script import modules, script return ports, template syntax misuse, and AI generation tool release status.

[0140] (4) Existing AI-generated code or tool technologies have not resolved the issue of inconsistencies between the generated tool and the upstream and downstream ports of the workflow. In scientific computing workflows, tools that generate code must be able to receive files or parameters output by upstream nodes and output the required files or parameters to downstream nodes according to specified ports. If tools are generated solely based on natural language descriptions, the parameter names in the generated code, the input / output keys in the configuration file, and the port names in the tool declaration may be inconsistent with the workflow plan, resulting in the inability to parse variables or pass files during subsequent execution.

[0141] (5) The existing tool generation process does not form a closed loop with the workflow execution status. AI generation tools typically include steps such as code generation, dependency installation, container building, testing, and release. If the tool has not been generated, tests have failed, it has not been released, or users do not have permission to use it, and the workflow execution entry point does not recognize these statuses, problems such as node scheduling failure, waste of task resources, and users not being able to understand the reasons for failure may occur.

[0142] (6) Existing technologies lack interpretable feedback and repair entry points when validation fails. After the large language model generates a plan, if only "validation failed" or "invalid format" is returned, it is difficult for the large language model or the user to locate the specific node, specific field, and specific repair method. A unified problem representation is needed so that the validation result can be displayed on the front end and can also be used by the large language model for further repair.

[0143] Therefore, existing technologies still do not provide a technical solution for enabling the structured verification of workflow plans generated or modified from large language models in scientific research computing workflow scenarios, and for forming an interpretable, recoverable, and enforceable closed-loop control between saving, tool generation, tool release, and execution entry points, thereby avoiding the execution of erroneous workflows or unready tools.

[0144] In one embodiment, a workflow generation and execution method is provided, specifically an LLM plan verification, missing tool generation, and execution gatekeeping method for scientific computing workflows. After the large language model generates or modifies the workflow plan, the server performs static verification on the plan and uniformly represents each verification issue as a problem object. The problem object includes fields such as problem type, severity, whether it blocks saving, whether it blocks execution, associated nodes, associated edges, and repair prompts. Based on this, the system distinguishes whether the workflow plan can be saved and whether it can be executed. For workflow nodes containing missing tools, the system creates a tool generation session and injects the expected input / output contract of the node into the large language model tool generation prompts, ensuring that the generated tool's code, configuration file, input / output declarations are consistent with the workflow port. Subsequently, the system performs code recycling, container construction, import testing, failure repair, and automatic deployment on the generated tool, and synchronizes the tool generation session status back to the workflow node. Before starting execution, the workflow execution entry point forces a rerun of the plan verification. Only after there are no issues blocking execution and the relevant tool nodes have been generated and deployed is the workflow execution phase allowed to begin. Through the above methods, this approach can form a complete technical closed loop for scientific computing workflows, including workflow plan verification, dual gates for saving and execution, missing tool generation, input / output contract injection, tool release status synchronization, and mandatory control of execution entry.

[0145] Understandably, this method is applicable to workflow platforms that require the combination of multiple scientific computing tools, scripts, or model services. Users can describe the scientific computing task to be completed in natural language, such as "perform preprocessing, structure prediction, result scoring, and output report on the input sequence file." The large language model or agent in the system generates a workflow plan based on this description. The workflow plan includes a set of nodes, a set of edges, node parameters, variable references, input / output ports, and optional missing tool generation nodes.

[0146] The workflow plan can be represented using a directed acyclic graph (DAG). Nodes can include input nodes, existing tool nodes, script nodes, condition nodes, template nodes, and missing tool generation nodes. Edges are used to represent execution order or data dependencies. Node parameters can contain variable references, such as referencing the output of an upstream node as the input of a downstream node. For existing tool nodes, the system can read their input / output contracts, access permissions, and required parameter definitions from the tool registry. For missing tool generation nodes, the system can generate new tool code and configuration using a large language model and publish the generated tool to the tool registry, enabling it to participate in subsequent execution as a regular tool node.

[0147] like Figure 3 As shown, the workflow generation and execution method in this embodiment can be applied to the following application scenarios: A user or agent input module receives user natural language tasks, existing workflow modification instructions, initial files, and context information. An LLM plan generation module generates or modifies a workflow plan based on the input. A server-side plan verification module reads the workflow plan and tool registry, and generates a structured verification result. When a blocking save item exists in the structured verification result, verification feedback is returned; otherwise, the workflow plan storage module saves the nodes, edges, node configurations, tool configurations, variable references, and tool generation node states. When a missing tool item exists in the structured verification result, a missing tool generation module creates a tool generation session for the missing tool node in the workflow. A tool build, test, and release module generates tool code, builds the runtime environment, performs import tests, repairs failures, and releases the tool. A node state synchronization module synchronizes the real state of the tool generation session to the workflow node. An execution access control module makes an allow or deny decision based on the verification result before saving or executing. The server plan verification module performs a second verification and generates structured verification results before execution. If any blocking execution items are found, a repair prompt is returned; otherwise, the workflow execution engine schedules each node to execute after the access control is passed. The verification and execution feedback module returns a list of issues, repair prompts, execution results, and node status to the front end or large language model.

[0148] The user or agent input module receives the user's natural language task description, modification requests for existing workflows, initial workflow files, and other contextual information. This module can be implemented through a front-end page, a dialog interface, or an embedded agent's call entry point. Input content can be, for example, "Create a workflow for processing a certain type of scientific data," or incremental modification instructions such as "Connect the output of a certain node to a downstream scoring node."

[0149] The LLM plan generation module is used to call a large language model to generate workflow plans. The generated results include at least a list of nodes, a list of edges, node types, node identifiers, tool names, tool parameters, variable references, and optional missing tool-generated nodes. To ensure the generated results can be processed by the server, this module outputs structured workflow plan data, rather than just natural language descriptions. For example, the LLM plan generation module can also be jointly generated by a rules engine and a large language model.

[0150] The workflow plan storage module is used to save the definition state of workflow plans. Plan definition and execution state are separated: the plan describes nodes and dependencies, while the execution record describes the node state, task directory, output file, and execution result of a specific run. This separation allows a plan to be executed multiple times and makes plan validation independent of any single execution process. For example, workflow plans can be represented using JSON, YAML, database records, or other structured formats, as long as they can express nodes, edges, parameters, variable references, and the node state generated by the tool.

[0151] The server-side plan validation module reads the workflow plan, tool registry, tool input / output contracts, user permissions, and missing tool generation status, and performs static validation on the plan. The validation results are uniformly represented as issue objects. Furthermore, each issue object can include issue type, severity, whether it blocks saving (i.e., blocked save item), whether it blocks execution (i.e., blocked execution item), associated node identifier or associated edge sequence number, issue description, whether it can be automatically repaired, and repair context. Issue types can include, for example, loops, missing entry nodes, non-existent tools, unknown variable references, missing required inputs, missing required parameters, unavailable script imports, missing script return keys, and tool generation nodes not ready.

[0152] Furthermore, the server-side plan verification module can centrally maintain verification rules in a rule metadata table. For each issue type, the rule metadata table defines its severity, whether saving is blocked, and whether execution is blocked. For example, DAG loops and non-developers creating high-privilege tool generation nodes can block both saving and execution; issues such as missing required parameters, unknown variable references, and unreleased tools can allow saving the draft but block execution; and missing nodes or tools still being generated can be displayed as warnings.

[0153] The missing tool generation module can create a tool generation session for a node when a missing tool generation node exists in the workflow plan. When creating the session, the system reads the expected inputs and outputs of that node in the workflow plan and injects them into the tool generation prompt. The expected input / output contract includes input key, output key, file type, parameter type, and port meaning. The tool generation prompt explicitly requires the generated tool's code to read input parameters with the specified key and return output results with the specified key, while also requiring that the tool input / output declarations in the configuration file be consistent with these keys. Through this method, even if a large language model tends to name its own input / output parameters, the system can constrain it to use port names from the workflow plan, thereby avoiding mismatches between the generated tool and upstream / downstream nodes.

[0154] The tool build, test, and release module is used to transform the tool code generated by the large language model into an executable tool. For example, this module may include the following steps: generating tool source code and configuration files; recycling the generated files; building a container image or runtime environment; executing import tests or minimal runtime tests; if tests fail, providing error information to the large language model for repair; recycling the code again after repair and testing; and publishing the tool to the tool registry after successful testing, which can further trigger the distribution of the image or runtime configuration. Furthermore, the tool build, test, and release module not only saves a snapshot of the generated tool's code but also saves information such as build status, image address, error messages, iteration count, and release status.

[0155] The node status synchronization module is used to synchronize the status between the tool generation session and workflow nodes. The tool generation session is the real status source, while the status fields in the workflow nodes are mirrored caches. The system can periodically or on-demand query the tool generation session status and synchronize statuses such as Not Started, Draft, Waiting, Running, Completed, Failed, and Cancelled to the workflow nodes. If tool generation is complete, information such as the tool name, release status, and runtime configuration is synchronized. If tool generation fails, the reason for the failure is synchronized. Furthermore, to avoid contention between concurrent node resets and status synchronization, the system can reread and lock the workflow node before writing the status back, confirming that the tool generation session currently associated with the node is still the expected session before writing the status.

[0156] The execution access control module operates in two phases. The first phase occurs when saving the workflow plan. If the validation results show a problem blocking saving, saving is refused; if only an execution-blocking problem exists, saving is allowed, but the plan is marked as unexecutable. The second phase occurs before starting workflow execution. This module forces a re-invocation of the server-side plan validation module, independent of front-end caching or the large language model's understanding of the previous validation results. Only when the validation results show no execution-blocking problems, and the relevant missing tool generation nodes have been completed and published, is entry into the execution engine permitted. If the server-side plan validation module encounters an internal exception, the execution access control module employs a failure-based shutdown strategy, treating the plan as unexecutable and returning a statement, thus preventing the system from mistakenly considering the plan executable due to validator anomalies.

[0157] The workflow execution engine creates execution records and execution nodes according to the workflow plan after the execution gate is cleared, and schedules nodes according to the DAG topology. During execution, file output or parameter output from upstream nodes can be passed to downstream nodes via variable references. The execution engine can record the status, input hash, output file, output parameters, and execution results of each execution node for subsequent debugging, retries, or caching and reuse.

[0158] The validation and execution feedback module is used to return structured feedback to the front-end or the large language model. For validation feedback, it returns a list of issues, saveable status, executable status, and fix suggestions; for tool generation feedback, it returns the generation stage, progress, error messages, and release results; for execution feedback, it returns the execution status, node status, and output results. The large language model can then use this feedback to further call workflow modification tools for fixes, and users can also view specific issues on the front-end.

[0159] like Figure 4 As shown, the workflow generation and execution method in this embodiment may include the following steps:

[0160] Step S1: Receive task description or modification instructions. The system receives the user's input in natural language, modification requirements for an existing workflow, initial files, or other context.

[0161] Step S2: LLM generates or modifies the workflow plan. The large language model outputs a structured workflow plan, including nodes, edges, tool parameters, variable references, and optional missing tool nodes.

[0162] Step S3: Server-side structured validation plan. The system reads the plan and tool registration information, performs multiple validations on the plan, and generates a unified list of issues and their saveable and executable statuses.

[0163] In step S4, if a blocking save issue exists, the save is rejected and the problem is returned. For example, the plan may contain a DAG loop, or a regular user may have created a missing tool generation node that is only allowed to developers.

[0164] Step S5: If there are no issues blocking the saving process, save the plan draft. Even if there are still issues such as missing required parameters or unknown variable references, it can still be saved as a draft, but the system will mark the plan as unexecutable.

[0165] Step S6: If there is a missing tool node in the plan, the system reads the expected input / output contract of the node, injects the contract into the tool generation prompt, and creates a tool generation session.

[0166] Step S7: The tool generates a session that calls the large language model to generate tool code and configuration files. Subsequently, the system recycles the code, builds a container or runtime environment, and executes tests.

[0167] In step S8, if the test or release fails, the system will send error information to the large language model, requesting it to fix the tool code and re-enter the build test process.

[0168] In step S9, if the test and release are successful, the system will generate the tool and publish it to the tool registry, and synchronize the tool name, generation status, release status, etc. back to the workflow node.

[0169] Step S10: When a user or agent requests to execute a workflow, the execution entry is forced to rerun the server-side plan verification.

[0170] Step S11: If an execution blocking issue exists, execution is disabled and a repair prompt is returned. Examples include: a tool not being released, required inputs not being bound, variable references pointing to non-existent output, or a script return value lacking a declared port.

[0171] Step S12: If there is no blocking execution problem, start the workflow execution engine, create execution records and execution nodes, and schedule execution according to DAG dependencies.

[0172] In step S13, the system returns the execution result, node status, output file, and feedback information that can be used for subsequent repair or re-execution.

[0173] For example, a workflow plan may include one or more of the following: plan identifier, node list, edge list, plan status, initial file, workflow-level input, plan owner, and other extended information.

[0174] For example, each node in the node list may include one or more of the following: node identifier, node type, tool name, tool parameters, agent configuration, tool-generated node configuration, node display information, and expected input / output contract.

[0175] For example, each edge in the edge list may include one or more of the following: source node identifier, target node identifier, source output port, target input port, and data type.

[0176] For example, the fields that a validation issue object may include are shown in Table 1:

[0177] Table 1. Validation issues may include the following fields.

[0178]

[0179] Understandably, fields in the validation problem object can be added or removed as needed by the system. For example, fields such as repair priority, front-end display location, and automatic repair commands can be added.

[0180] Accordingly, the system can calculate whether a plan can be saved and whether it can be executed based on all problem objects:

[0181] (1) If blocks_save is true for any problem object, the plan cannot be saved;

[0182] (2) If blocks_execute is true for any problem object, the plan is not executable;

[0183] (3) If there is no problem with blocks_save being true, then the plan can be saved;

[0184] (4) If there is no problem with blocks_execute being true, then the plan can be executed.

[0185] For example, a tool generation session may include one or more of the following: session identifier, associated workflow node, user identifier, tool name, tool description, expected input contract, expected output contract, generation status, generation stage, progress, error message, code snapshot, build image or runtime environment identifier, release status, and iteration number.

[0186] For example, the server-side plan verification module can perform at least the following verifications:

[0187] (1) DAG structure verification. Check whether there are loops, entry nodes, isolated nodes, and whether the downstream of scatter nodes conforms to the rules.

[0188] (2) Tool existence verification. For tool nodes, check if the corresponding tool exists in the tool registry; for completed missing tool generation nodes, check if the generated tool name has been backfilled.

[0189] (3) Tool access permission verification. Check whether the current user has permission to access the tool; if a certain type of missing tool generation node only allows developers to create or execute it, then check the user type.

[0190] (4) Input / output contract verification. Read the input / output contracts in the tool registry, check whether the variable references and edges in the workflow plan reference the actual output ports, and check whether the required inputs are bound.

[0191] (5) Validation of required parameters. Read the tool form or parameter pattern and check if the required fields in the tool parameters exist and are not empty. For arrays or nested fields, parse them according to their structural path.

[0192] (6) Variable reference validation. Recursively scan the variable references appearing in the node parameters, check whether the reference path conforms to the syntax, whether the referenced node exists, and whether the referenced output port exists.

[0193] (7) Static validation of script nodes. Check whether the modules imported in the script code are allowed to be used in the runtime environment; check whether the script reads a non-existent parameter key; check whether the script has a return statement; check whether the return dictionary contains the declared output key; check whether the script code has mistakenly written template syntax that should only appear in parameter fields.

[0194] (8) Missing tool generation node verification. Check if the node is allowed for use by the current user; check if the tool generation session has been created; check if the generation status is complete; check if the generation tool has been published to the tool registry; if not complete, generate a warning or block execution issue.

[0195] (9) Validator exception handling. If an exception occurs inside the validator, the system returns a problem object that is blocked from execution, instead of the default scheduled execution.

[0196] In this embodiment, the rules for blocking saving and blocking execution can be configured according to user role, tool type, or workflow type. For example, for ordinary users, missing tool generation nodes can block saving, while for developers, saving can be allowed but execution can be blocked.

[0197] Furthermore, missing tool generation nodes can be determined by the large language model based on the user's task. For example, a user might want to insert a new data format conversion tool among existing tools, but there's no corresponding tool in the tool registry. In this case, the system can create a tool generation node and record the expected input and expected output in that node. For example, the expected input could be `input_file`, and the expected output `converted_file`. Exemplarily, when creating a tool generation session, the system appends this expected input / output contract to the tool generation prompt. For example, the prompt could explicitly require:

[0198] (1) The main program of the generation tool must read the specified input key from the parameter dictionary;

[0199] (2) The return value of the generation tool must contain the specified output key;

[0200] (3) The tool_io.inputs and tool_io.outputs in the configuration file must use the same key;

[0201] (4) If the output is a file, the value of the corresponding key in the return value must be the path to the generated file;

[0202] (5) You may not replace it with a key that is semantically similar but different.

[0203] Therefore, the generation tool can maintain consistency with upstream variable references and downstream node ports in the workflow, avoiding port mismatches during workflow execution.

[0204] For example, the tool can build a test release module using the following process:

[0205] (1) Generate tool files. Tool files may include the main program, tool configuration, front-end form configuration, dependency files, demo cases, and instruction files.

[0206] (2) Reclaim code snapshots. The system collects tool code and configuration from the production environment and saves them as code snapshots.

[0207] (3) Building the runtime environment. The system generates a container image or other runtime environment based on the tool code. If the tool requires a GPU, a GPU-enabled basic environment is used; if it does not require a GPU, a general basic environment is used.

[0208] (4) Perform import test or minimal test. The system runs minimal commands to confirm that the tool code can be imported or started. If necessary, a demonstration input can also be performed.

[0209] (5) Error feedback and repair. If the test fails, the system will extract the error information and send it back to the large language model, requiring it to repair the code, and then recycle the code and test it again.

[0210] (6) Publish the tool. After the test is passed, the system publishes the tool configuration, code package, and runtime environment information to the tool registry, so that it can be discovered and called by the workflow execution engine.

[0211] (7) Synchronization status. After successful release, the system will synchronize the tool name, release status, and build information to the workflow node; if release fails, the reason for the synchronization failure will be provided.

[0212] Furthermore, tool generation can utilize container images, virtual environments, script packages, remote services, or other runtime formats. Tool distribution can also be done through tool registries, app stores, internal package repositories, or other tool discovery systems. Tool testing can include import tests, unit tests, demo test cases, sandbox tests, or a combination of these. State synchronization can be achieved using methods such as polling, message queues, event streams, database triggers, or callback interfaces.

[0213] Even if the access control plan has been validated when saved, the system still re-runs the server-side plan validation before each execution. The reasons for this include, but are not limited to:

[0214] (1) The tool registry may change after saving;

[0215] (2) User permissions may change;

[0216] (3) The status of the missing tool-generated node may change from running to completed or failed;

[0217] (4) Large language models may modify node parameters in subsequent dialogues;

[0218] (5) Script nodes or variable references may be incrementally modified;

[0219] (6) The status displayed on the front end may not be the authoritative status.

[0220] The entry gate can decide whether to initiate execution based on the latest verification results. If execution is blocked, the system returns a list of issues and repair suggestions; otherwise, an execution record is created and the system enters the execution engine. This mechanism prevents erroneous plans, unready tools, or plans with insufficient permissions from entering the computing resource scheduling phase.

[0221] For example, the validation response returned by the system to the front-end or agent may include a list of issues, whether the data can be saved (can_save), whether it can be executed (can_execute), a plan ID (plan_id), affected nodes (affected_nodes), and suggested actions (suggested_actions). The front-end can display issues near canvas nodes, configuration panels, or execute buttons based on the issues; the agent can continue to call the workflow modification interface based on the issues to fix variable references, supplement parameters, or wait for the tool to complete the generation. In this way, the validation results can serve both manual editing and automatic repair of large language models.

[0222] Furthermore, access control can be implemented at the HTTP API layer, the smart agent tool call layer, the workflow execution service layer, or multiple layers.

[0223] Furthermore, the workflow generation and execution method in this embodiment can also be combined with execution optimization techniques such as remote computing clusters, cloud containers, file caching, scatter fan-out, and sub-item-level caching.

[0224] In one specific embodiment, the workflow generation and execution method may be:

[0225] The user input task is: "Preprocess the uploaded scientific research data file, call the analysis tool to generate intermediate results, and output a readable report. If the format conversion tool is missing, please generate it automatically."

[0226] The system first generates a workflow plan from a large language model. The plan includes input nodes, existing analysis tool nodes, report generation nodes, and a missing tool generation node. The expected input for the missing tool generation node is `raw_data_file`, and the expected output is `normalized_data_file`. The server-side plan validation module detects that the missing tool generation node is incomplete, therefore returning a problem that does not block saving but blocks execution. The system allows saving the plan draft, but the execute button is disabled.

[0227] Subsequently, the missing tool generation module creates a tool generation session and injects `raw_data_file` and `normalized_data_file` into the generation prompts. The large language model generates the tool code and configuration files. The system builds the runtime environment and executes import tests. If the first test finds that the main program is missing necessary dependencies, the system reports the error information to the large language model, generates the fixed code, and retests. After the test passes, the system publishes the tool and synchronizes the generated tool name back to the workflow nodes.

[0228] When a user triggers execution again, the execution entry point forces a re-verification of the plan. At this point, the missing tool nodes have been completed and published, variable references and required inputs have all passed validation, and the system allows execution to begin. The execution engine creates an execution record, executes the input nodes, generated tool nodes, existing analysis tool nodes, and report generation nodes in DAG order, and finally returns the execution results.

[0229] It is evident that even if the initial plan generated by the large language model is incomplete, the system will not directly execute the erroneous plan. Instead, it will first save the draft, generate the missing tools, verify the tool status, and confirm at the execution entry point that all blocking execution issues have been eliminated.

[0230] The workflow generation and execution method provided in this embodiment can achieve at least the following technical effects:

[0231] (1) Improve the executable stability of the large language model generation workflow. By performing static verification on the server side and mandatory secondary verification before execution, problems such as DAG loops, variable reference errors, missing tools, and missing required parameters can be detected before entering the actual computing resource scheduling, thus avoiding the execution of erroneous plans.

[0232] (2) Balancing draft editing efficiency and execution security. By classifying validation issues into two categories—blocking saving and blocking execution—the system allows users or large language models to save workflow drafts that have not yet been configured, while preventing the draft from entering the execution stage.

[0233] (3) Improve the consistency between missing tool generation and workflow planning. By injecting the expected input and output contracts of missing tool nodes into tool generation prompts, the code, configuration, and port declarations of the generated tools can be kept consistent with the upstream and downstream ports of the workflow, reducing the probability of variable parsing failure and file transfer failure.

[0234] (4) Reduce tool generation rework. Through the build, test, error feedback and automatic repair process, the system can find import errors, dependency errors or configuration errors in the generated code before release and require the large language model to fix them, reducing manual debugging costs.

[0235] (5) Prevent incomplete tools from being executed by mistake. The tool generation status, release status and user permissions are included in the plan verification and execution gate, so that tool nodes that are not yet completed, have failed to be released or do not have the necessary permissions will not enter the execution engine.

[0236] (6) Improve problem location and automatic repair capabilities. A unified problem object includes the problem type, associated nodes, whether execution is blocked, and repair context, which is convenient for front-end display and also facilitates the large language model to continue to automatically repair the workflow plan.

[0237] (7) Enhance the resource protection capabilities of the scientific research computing platform. Erroneous workflows often consume remote computing resources, queue resources, or container building resources. This solution can reduce invalid task submissions and resource waste by implementing gate control to block erroneous plans before the task starts.

[0238] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0239] Based on the same inventive concept, this application also provides an apparatus for implementing the method described above. The solution provided by this apparatus is similar to the solution described in the above method; therefore, specific limitations in one or more apparatus embodiments provided below can be found in the limitations of the method described above, and will not be repeated here.

[0240] In one embodiment, such as Figure 5 As shown, this application provides a workflow generation and execution device for generating and executing scientific research computing workflows. The workflow generation and execution device includes:

[0241] The workflow plan generation module 100 is used to call a preset large language model to output a workflow plan based on the scientific research computing tasks submitted by the user in natural language commands.

[0242] The server-side plan verification module 200 is used to perform the first static verification on the workflow plan and obtain the first verification result of the workflow plan.

[0243] The workflow plan storage module 300 is used to save the workflow plan when there are no blocking items in the first verification result.

[0244] The missing tool generation module 400 is used to generate a target tool corresponding to the missing tool item when there is a missing tool item in the first verification result;

[0245] The access control module 500 is used to respond to the start command of the saved workflow plan, perform a second static verification on the saved workflow plan, obtain the second verification result of the saved workflow plan, and execute the saved workflow plan when there is no blocking execution item in the second verification result.

[0246] Furthermore, the workflow generation and execution device also includes a user or intelligent agent input module, which can send natural language instructions representing scientific computing tasks submitted by the user to the workflow plan generation module 100.

[0247] Furthermore, the missing tool generation module 400 is also used to: determine the expected input-output contract based on the expected input and expected output of the missing tool item; input the expected input-output contract into the missing tool generation node; and generate a target tool corresponding to the missing tool item based on the missing tool generation node.

[0248] Furthermore, the workflow generation and execution device also includes a tool building, testing, and release module, which is used to generate tool files by calling the preset large language model based on the missing tool generation node; test the tool files in the runtime environment corresponding to the tool files based on preset minimum commands; and determine the tool files that pass the test as the target tools.

[0249] Furthermore, the workflow generation and execution device also includes a node status synchronization module, used to obtain the tool name and release status of the target tool; synchronize the tool name and release status to the node status field of the missing tool generation node; and update the node status of the missing tool generation node to the completed status.

[0250] Furthermore, the workflow generation and execution device also includes a workflow execution engine, which, after the execution gate passes, creates execution records and execution nodes according to the workflow plan, and schedules the nodes according to the topological relationship of the directed acyclic graph of the workflow plan.

[0251] Furthermore, the workflow generation and execution device also includes a verification and execution feedback module, which is used to return structured feedback to the front end or large language model, and to provide feedback on one or more of the first verification result, the second verification result, and the execution result.

[0252] Each module in the aforementioned workflow generation and execution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0253] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a workflow generation and execution method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0254] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0255] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the workflow generation and execution method of any of the above embodiments.

[0256] Based on the scientific computing tasks submitted by users in natural language commands, the system calls a preset large language model to output a workflow plan.

[0257] Perform a first static check on the workflow plan to obtain a first check result for the workflow plan, and save the workflow plan when there are no blocked items in the first check result;

[0258] When there is a missing tool item in the first verification result, the missing tool generation node is invoked to generate the target tool corresponding to the missing tool item;

[0259] In response to the start command for the saved workflow plan, a second static check is performed on the saved workflow plan to obtain a second check result of the saved workflow plan. If there are no blocking execution items in the second check result, the saved workflow plan is executed.

[0260] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the workflow generation and execution method of any of the above embodiments:

[0261] Based on the scientific computing tasks submitted by users in natural language commands, the system calls a preset large language model to output a workflow plan.

[0262] Perform a first static check on the workflow plan to obtain a first check result for the workflow plan, and save the workflow plan when there are no blocked items in the first check result;

[0263] When there is a missing tool item in the first verification result, the missing tool generation node is invoked to generate the target tool corresponding to the missing tool item;

[0264] In response to the start command for the saved workflow plan, a second static check is performed on the saved workflow plan to obtain a second check result of the saved workflow plan. If there are no blocking execution items in the second check result, the saved workflow plan is executed.

[0265] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0266] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0267] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0268] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A workflow generation and execution method, characterized in that, This method is applied to the generation and execution of scientific research computing workflows, and includes: Based on the scientific computing tasks submitted by users in natural language commands, the system calls a preset large language model to output a workflow plan. Perform a first static check on the workflow plan to obtain a first check result for the workflow plan, and save the workflow plan when there are no blocked items in the first check result; When there is a missing tool item in the first verification result, the missing tool generation node is invoked to generate the target tool corresponding to the missing tool item; In response to the start command for the saved workflow plan, a second static check is performed on the saved workflow plan to obtain a second check result of the saved workflow plan. If there are no blocking execution items in the second check result, the saved workflow plan is executed.

2. The workflow generation and execution method according to claim 1, characterized in that, The first static verification and the second static verification use the same preset verification rules. The process of obtaining the preset verification rules includes: Get the current user's permission information; Based on the permission information, an index is created to determine a preset verification rule that matches the permission information; the preset verification rule includes blocking saved item verification and blocking executed item verification.

3. The workflow generation and execution method according to claim 2, characterized in that, After performing a first static verification on the workflow plan and obtaining a first verification result for the workflow plan, the process includes: If there is a blocking execution item in the first verification result, the workflow plan is marked as an unexecutable plan.

4. The workflow generation and execution method according to claim 1, characterized in that, The first static verification and the second static verification each include one or more of the following verification items: directed acyclic graph structure verification, node connectivity verification, tool existence verification, tool permission verification, registration tool input / output contract verification, required parameter verification, variable reference verification, script node static verification, missing tool generated node verification, and verifier anomaly verification.

5. The workflow generation and execution method according to claim 1, characterized in that, The process of calling the missing tool generation node to generate the target tool corresponding to the missing tool item includes: Based on the expected inputs and expected outputs of the missing tool items, determine the expected input-output contract; Input the expected input-output contract into the missing tool generation node; Based on the missing tool generation node, a target tool corresponding to the missing tool item is generated.

6. The workflow generation and execution method according to claim 5, characterized in that, The step of generating a target tool corresponding to the missing tool item based on the missing tool generation node includes: Based on the missing tool generation node, the preset large language model is invoked to generate the tool file; Based on the preset minimum commands, the tool file is tested in the runtime environment corresponding to the tool file, and the tool file that passes the test is determined as the target tool.

7. The workflow generation and execution method according to claim 5, characterized in that, After generating the target tool corresponding to the missing tool item based on the missing tool generation node, the process further includes: Obtain the tool name and release status of the target tool; Synchronize the tool name and the release status to the node status field of the missing tool generation node; Update the node status of the missing tool-generated node to the completed status.

8. A workflow generation and execution device, characterized in that, An apparatus for generating and executing scientific research computing workflows, comprising: The workflow plan generation module is used to output a workflow plan based on the scientific research computing tasks submitted by the user in natural language commands, by calling a preset large language model. The server-side plan verification module is used to perform a first static verification on the workflow plan and obtain a first verification result of the workflow plan. The workflow plan storage module is used to save the workflow plan when there is no blocked save item in the first verification result; The missing tool generation module is used to generate a target tool corresponding to the missing tool item when there is a missing tool item in the first verification result; The access control module is configured to, in response to a start command for a saved workflow plan, perform a second static check on the saved workflow plan to obtain a second check result for the saved workflow plan, and execute the saved workflow plan when there are no blocking execution items in the second check result.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images