A workflow code automatic generation method driven by a large model

Abstract

The application provides a workflow code automatic generation method driven by a large model, comprising: through multi-level agent cooperation, sequentially converting original requirements into a subtask set, a node relationship graph and structured workflow description data, wherein the last level agent forcibly checks the data closed loop between nodes; defining tool nodes and content generation nodes in the workflow description data to realize decoupling of content generation and tool calling; parsing the structured workflow description data, dynamically generating a strongly typed state class mapped with the description data, and automatically filling node calling logic and parallel routing rules based on a preset code template to generate workflow code; when code running errors and the number of retries exceeds a preset threshold, generating an execution track through an error positioning agent, generating candidate solutions in parallel by multiple repair agents, and after adaptive scoring by a scoring agent based on error types, verifying and executing the repair solutions in sequence.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence-driven software development technology, specifically relating to a method for automatically generating workflow code driven by a large model. Background Technology

[0002] With the rapid development of artificial intelligence technology, large-model-driven workflow automation tools have gradually become an important means to improve task processing efficiency. Currently, mainstream workflow orchestration frameworks generally face two core challenges: first, the contradiction between automation level and ease of use; and second, insufficient reliability and error correction capabilities in handling complex tasks. Regarding ease of use, most existing frameworks still require users to manually participate in node configuration or tool definition, such as by pre-setting process logic through drag-and-drop interfaces or code scripts. This presents a high learning curve for users without technical backgrounds and makes it difficult to adapt to rapidly changing needs. Even some solutions that claim to support "one-click generation" still rely on large models to directly generate code or task sequences, lacking a systematic decomposition of task structure and explicit management of data dependencies, resulting in logical gaps or missing parameters in the generated results.

[0003] At the task execution level, existing technologies have limited ability to manage the context of complex processes. For example, when using a "think-execute" loop interaction model, as the task steps increase, historical dialogues and intermediate results continuously occupy the context window, which may not only trigger the input length limit of large models but also lead to misunderstandings in subsequent steps due to information overload. In addition, the coupled design of tool calls and content generation makes it easy for errors at a single node to propagate to the entire process. Traditional error handling methods mostly rely on node-level retry mechanisms, which can only solve simple problems such as syntax errors, and are difficult to effectively deal with complex errors such as data dependency conflicts and multi-node collaboration failures. These problems together mean that existing solutions often require manual intervention and debugging when handling multi-step, highly dependent workflow tasks, making it difficult to achieve truly fully automated closed-loop execution.

[0004] From a technical implementation perspective, the core limitation of existing workflow frameworks lies in the lack of structured constraints on task programmability. Most solutions directly drive tool calls through natural language descriptions, ignoring data flow and type matching between subtasks, leading to frequent incompatibility between tool output and subsequent task requirements. Simultaneously, the lack of global state management forces data transfer between nodes to rely on implicit conventions rather than explicit definitions, further increasing process unpredictability. Although some frameworks attempt to introduce templates or configuration files to standardize processes, they haven't fundamentally solved the problem of automating the conversion of requirements into code, especially in dynamic task scenarios where balancing the generality of templates with personalized needs remains difficult. These technical bottlenecks mean that existing tools still cannot meet the efficiency and reliability requirements of practical applications when facing complex enterprise-level business processes or high-precision code generation tasks. Summary of the Invention

[0005] To address the shortcomings and deficiencies of existing technologies, this invention provides a method and system for automatically generating workflow code driven by a large model. It aims to solve problems such as high human intervention, immature task decomposition, chaotic data dependencies, lengthy contexts, and weak error correction capabilities in existing workflow frameworks. This method, through multi-level intelligent agent collaboration, progressively transforms the user's original requirements into a set of subtasks, a node relationship graph, and structured workflow description data. The final-level intelligent agent enforces data loop verification between nodes, ensuring that node input data originates from the output of preceding nodes or initial state parameters, and that output data is referenced by subsequent nodes or updated to state parameters, thus forming a clear and traceable data flow. In the workflow description, tool nodes and content generation nodes are clearly distinguished. Tool nodes execute operations through preset interfaces and update the output to global context state parameters. Content generation nodes use these state parameters as input to generate text content, decoupling content generation from tool calls and reducing context redundancy. Based on the aforementioned structured description data, the system dynamically generates strongly typed state classes that map to these classes and automatically fills in node call logic and parallel routing rules using preset code templates, efficiently generating executable workflow code and improving code generation speed and first-time success rate. To address errors during workflow execution, when the number of retries exceeds a preset threshold, an error-localizing agent generates an execution trajectory. Multiple repair agents then generate candidate repair solutions in parallel. A scoring agent adaptively scores these solutions based on the error type, and the solutions are verified and executed in score order, significantly improving the efficiency of repairing complex errors. This invention integrates incremental task optimization, decoupled architecture design, templated code generation, and a bidding-based long-process error correction mechanism to achieve fully automated workflow code generation, effectively reducing task failure rates and improving user experience.

[0006] The specific solutions adopted by this invention to solve its technical problems include:

[0007] A method for automatically generating workflow code driven by a large model includes:

[0008] Through multi-level intelligent agent collaboration, the original requirements are transformed into sub-task sets, node relationship diagrams, and structured workflow description data in sequence. The last level of intelligent agent enforces the verification of data closure between nodes: node input data must come from the output of the preceding node or the initial state parameters, and node output data must be referenced by subsequent nodes or updated to the state parameters.

[0009] In the workflow description data, tool nodes and content generation nodes are defined. Tool nodes perform operations through preset interfaces and update the output to the global context state parameters. Content generation nodes generate text content with the global context state parameters as input, thereby decoupling content generation from tool invocation.

[0010] The structured workflow description data is parsed, and a strongly typed state class that maps to the description data is dynamically generated. The state class contains message tuple fields and automatically fills in node call logic and parallel routing rules based on a preset code template to generate workflow code.

[0011] When the code runs into error and the number of retries exceeds a preset threshold, an execution trajectory is generated by an error location agent. Multiple repair agents generate candidate solutions in parallel. After the scoring agent adaptively scores the solutions based on the error type, the repair solutions are verified and executed in sequence.

[0012] Furthermore, the multi-level intelligent agent includes a task decomposition intelligent agent, a node orchestration intelligent agent, and a data closure intelligent agent, which perform the following operations in sequence:

[0013] The task decomposition agent performs a preliminary decomposition of the original requirements, generates a pre-decomposed set of subtasks, and extracts key data source information in parallel.

[0014] The node orchestration agent constructs a directed graph of node relationships based on a pre-decomposed set of subtasks, defining the upstream and downstream relationships and types of each node;

[0015] The data closed-loop intelligent agent performs rule verification on the directed graph of node relationships, forces the improvement of data dependencies between nodes, and generates structured workflow description data.

[0016] Furthermore, the types of nodes include tool parameterless nodes, tool parameterized nodes, and content generation nodes. The node orchestration agent determines the node type corresponding to each subtask through preset rules and explicitly marks it through the node type field.

[0017] Furthermore, the data closure verification rules include:

[0018] All parameter names are globally unique and must include the data type, purpose description, source of generated nodes, and list of nodes used;

[0019] The output data of a node must be referenced by the input data of other nodes or the global context state parameters to form a closed loop of data flow without redundancy;

[0020] The global context state parameters include the general message context, the user's original requirements, the precise subtask set, and the input and output parameters of each node. The general message context is a required field and is not associated with any specific node.

[0021] Furthermore, after the output of the tool node is updated to the global context state parameters, it is incorporated into the processing logic of the content generation node as an input parameter, and the tool node with parameters shall not be used as the starting node of the workflow.

[0022] Furthermore, the structured workflow description data is in JSON format, containing global context state parameter definitions, node attributes, and routing relationships between nodes. The node attributes include node name, type, description, input data, and output data.

[0023] Furthermore, the strongly typed state class is a custom class built on the Pydantic framework, with fields mapped one-to-one to global context state parameters in the structured workflow description data, and automatically inheriting the data type and constraint rules of the parameters;

[0024] The preset code template is a dynamic template based on the LangGraph framework. The parallel routing rules include: multiple nodes pointing to the same successor node are executed in parallel, or a single node pointing to multiple successor nodes are executed in parallel.

[0025] Furthermore, the error location agent generates complete console output by inserting print statements during the code execution phase, and locates the error location based on the output trajectory; the multiple repair agents are at least three, generating independent repair schemes in parallel.

[0026] Furthermore, when the structured workflow description data is generated incorrectly and retrying fails to resolve the issue, the error localization agent directly locates the error in the description data, and the subsequent repair solution is verified through data closed-loop verification rules.

[0027] After the workflow code is generated, it is tested through a code sandbox. Once the test is passed, the workflow code and structured workflow description data are stored in a vector database, and the tool code is stored in a tool server to achieve resource reuse.

[0028] And, a workflow code generation system driven by a large model, comprising:

[0029] The task structuring module is used to transform the original requirements into a set of subtasks, a node relationship diagram, and structured workflow description data through multi-level intelligent agent collaboration. The last-level intelligent agent forces the verification of data closure between nodes: the node input data comes from the output of the preceding node or the initial state parameters, and the node output data is referenced by subsequent nodes or updated to the state parameters.

[0030] The node decoupling module is used to define tool nodes and content generation nodes in the workflow description data. Tool nodes perform operations through preset interfaces and update the output to the global context state parameters. Content generation nodes generate text content with the global context state parameters as input, thereby decoupling content generation from tool invocation.

[0031] The code generation module is used to parse the structured workflow description data, dynamically generate a strongly typed state class that maps to the description data and contains message tuple fields, and automatically fill in the node call logic and parallel routing rules based on a preset code template to generate workflow code.

[0032] The error correction module is used to generate an execution trajectory through an error location agent when the code runs incorrectly and the number of retries exceeds a preset threshold. Multiple repair agents generate candidate solutions in parallel, and after the scoring agent adaptively scores the solutions based on the error type, the repair solutions are verified and executed in sequence.

[0033] And an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.

[0034] A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0035] Compared with the prior art, the present invention and its preferred embodiments have at least the following beneficial effects:

[0036] The incremental task decomposition and data closure mechanism achieved through multi-level intelligent agent collaboration effectively solves the problems of immature task decomposition and chaotic data dependencies in existing solutions. This makes the workflow's subtask sets more aligned with programming requirements, ensures clear and traceable data flow, and reduces the risk of task deviation due to unclear data sources or ambiguous destinations. The decoupled architecture of workflow content generation and tool invocation replaces the traditional continuous think-execution model, avoiding excessive accumulation of contextual information. This not only reduces the probability of accumulated errors in generated content but also enables workflow code to be executed with a single click, significantly improving operational efficiency and user experience. The template-based code generation method, based on structured descriptive data, fully utilizes the code generation capabilities of large models while ensuring the stability of workflow code through preset templates and dynamic filling logic. Compared to directly relying on large models to generate complete code, it shows significant improvements in both generation speed and first-time success rate. The long-process error correction mechanism based on the bidding model transforms the gradual localization, multi-solution trial, and dynamic verification behaviors of human debugging into an automated process. Through parallel generation and scoring of repair solutions by multiple agents, it overcomes the limitations of traditional single-node retries, significantly improving the efficiency and success rate of error repair in complex workflows and enhancing the system's robustness. In summary, this invention, by integrating the above innovative designs, achieves fully automated workflow code generation, effectively reducing task failure rates, simplifying user operations, and providing more reliable technical support for the automated processing of complex tasks. Attached Figure Description

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

[0038] Figure 1 This is a diagram illustrating the overall architecture of an embodiment of the present invention.

[0039] Figure 2 This is a flowchart of steps 1-3 in an embodiment of the present invention;

[0040] Figure 3 This is a flowchart of step 4 in an embodiment of the present invention;

[0041] Figure 4 This is a flowchart of the H-BLEC process according to an embodiment of the present invention;

[0042] Figure 5 This is a flowchart of step 6 in an embodiment of the present invention. Detailed Implementation

[0043] To make the features and advantages of the present invention more apparent and understandable, specific embodiments are described below in detail:

[0044] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0045] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0046] This invention aims to construct a method for automatically generating workflow code driven by a large model, to achieve fully automated workflow code generation tasks and solve problems such as high task failure rate, verbose context, and low success rate of large model error correction. First, an incremental evolution scheme and data closure strategy are used to generate a set of workflow subtasks suitable for programming tasks and with clear data flows. Next, a JSON data structure is used to describe the workflow, and workflow content generation is decoupled from the tool, designed to achieve efficient execution of the target workflow code. Simultaneously, parallel strategies are employed in task parsing, tool code generation, and target workflow content generation to further improve the speed of workflow code generation and its execution.

[0047] Its innovations include an incremental, progressive evolution strategy and a data closed-loop approach; a decoupled architecture for workflow content generation and tools; a templated code generation engine; and a long-process localization and error correction mechanism based on a bidding model and human debugging (Human-imitating Bid Long Error Correction, abbreviated as H-BLEC), including:

[0048] (1) Incremental evolution of solutions and data closure strategy: A hierarchical, multi-expert approach was adopted to improve the task execution plan and promote it towards programmability. This greatly reduced the situation where the details of the task set generated by the large model were not in place, and the sources and destinations of data dependencies of various solutions were unclear, making it difficult to programmatically solve the problem.

[0049] (2) Decoupled Architecture for Workflow Content Generation and Tools: The target code generated by this framework adopts an architecture that decouples LLM content generation from tool invocation. This enables tools to supplement LLM information and LLM to generate data that is not provided by the tools. At the same time, it replaces the direct invocation of tools by LLM through the pre-defined workflow process. This greatly reduces the execution time of the generated code and improves the user experience.

[0050] (3) Templated code generation engine: The tool code is generated from a large model, based on the JSON and strong data closure obtained above, which provides a precise and structured description of the workflow. It generates the global context parameter class `State` for the workflow based on the `state` parameter in the JSON data describing the workflow, and generates the complete workflow code by simply parsing the JSON parameters and filling in the tool code call code and parameters in sequence. Compared to the uncertainty and inefficiency of directly generating complete code from a large model, this engine offers significant improvements in speed and the success rate of completing the task on the first attempt.

[0051] (4) Human-imitating BidLong Error Correction (H-BLEC) mechanism based on bidding model and human debugging:

[0052] With a bidding mechanism as the core of the scheduling, and through the division of labor and cooperation among multiple intelligent agents, the human debugging process of "progressive localization → multi-solution trial → dynamic verification" is transformed into an automated and scalable long-process error correction system. Through three major design features—competitive task distribution, error type adaptation, and closed-loop verification—it significantly improves the efficiency and success rate of repairing complex errors.

[0053] This invention employs a template-based code generation engine during code assembly. Only the tools are generated using LLM, while the rest are dynamically generated using template code, rather than large chunks of generated LLM code. This fully utilizes the code generation capabilities of LLM while significantly ensuring the success rate of the entire workflow code. For error handling, a long-process error localization and correction mechanism based on a bidding model and human debugging is used to address issues related to repeated retries and code correction. Finally, a resource reuse mechanism is utilized, storing the workflow code and its JSON data in FAISS, and the tools in the MCP-Server. The overall architecture is as follows. Figure 1 As shown, the implementation process follows these steps:

[0054] Step 1: Initial task decomposition and data source structure extraction.

[0055] Step 2: Datafication of the process relationship structure of each node.

[0056] Step 3: Structure data closure and JSON data merging and validation.

[0057] Step 4: Parse the workflow_json_data obtained in Step 3 and generate tool code.

[0058] Step 5: Use the template method to build the workflow code.

[0059] Step 6: Test the code and persist it.

[0060] Note: This framework involves two types of state (context and global parameters). One is the runtime state of the framework, which has the scope of the entire framework. The other is the runtime state of the workflow generated by the framework, which has the scope limited to the workflow code. The latter's state will accept the final task set `state.precise_subtask_set` from the former and the user's original input `state.user_input` during the generation process.

[0061] The specific steps described above are explained below:

[0062] In step 1 above, the user's original requirements are initially broken down into multiple subtasks by `task_prede_agent`. Simultaneously, the intelligent agent `extract_key_data_agent`, which can invoke tools to access the user's data source table structure, removes useless columns based on the table structure and original requirements (without modifying the source data), retaining only relevant table and table structure data. The two sets of data are then merged.

[0063]

[0064] in, This represents the initial set of subtasks. This represents the user's original needs. This represents the task decomposition function. This represents the key data after filtering. This indicates a data filtering function (retaining relevant tables and fields based on requirements). Indicates the original data source. This represents the initial data after merging (subtask set + key data). This indicates a data merging operation.

[0065] In step 2 above, the content generation task and tool call are decoupled in the generated workflow code. The data obtained in step 1 and the node type descriptions tool_with_args (tool nodes with parameters), tool_without_args (tool nodes without parameters), and LLM nodes used for content generation are placed in the prompt of node_flow_agent. The use of agent_with_tools is abandoned. When content generation and tool call are interdependent, the tool node + LLM node scheme is automatically adopted. This avoids the inefficiency of the traditional LLM directly calling tools and the situation where the task granularity is too coarse, which causes the LLM-generated code to not meet the requirements well.

[0066] During processing, the node relationships in the JSON data are first generated:

[0067] The `node_flow_agent` primarily handles node orchestration, with data flow as a secondary focus. This allows it to specialize in node-related tasks while incorporating data flow hints. These hints inform the user that nodes are related to data flow and ensure that the generation of specific data flow loops in the next step is a refinement based on existing data, rather than abrupt generation. This incremental, information-driven, and focused generation significantly improves the quality of data generated by large models. The subtask set and key data generated in the previous step are fed into `node_flow_agent`. The pre-decomposed subtask content is combined with the key data, arranged one task per node. The specific subtasks are refined using key data, relevant parameters, and operations. The type and name of each node, along with its upstream and downstream relationships, are determined for each subtask. Next, node rules are validated, and a Directed Acyclic Graph (DAG) of the flow relationships between nodes is constructed based on `both_ends`, `node_parents`, and `next_nodes`.

[0068] Next, node relationship feasibility verification is performed: First, it goes through `node_rule_check`, a node relationship verification program designed according to Workflow node rules. Only after passing node rule verification can the next step, `data_flow` generation, proceed. After passing this, it enters the feasibility verification stage, namely `feasible_check`: This includes `closed_loop_agent`, which determines whether there are potential data loops related to the current critical data based on the node flow relationships and provides design suggestions; and `Programmable_agent`, which determines whether these nodes can be completed using simple programming tasks. Finally, `meet_recommend_agent` checks whether it meets the user's requirements.

[0069] Step 3 is used to generate JSON with data closure based on the previous step, and finally synthesize JSON.

[0070] To ensure the output task set and node parameter relationships form a data loop, and to guarantee the accuracy and completeness of the task set, the `data_flow_agent`, based on the tasks generated in step 2, will first refine the subtasks using methods that include data input and output, and generate corresponding node parameter information. Simultaneously, it will perform rule and data loop verification (`final_check`). At this point, the core workflow of the JSON data has been generated, and the parameters in the state only need to be retrieved from the `input / output_data` of each node. If the workflow passes the final verification, the JSON data generation is complete. If it fails, a simple retry is performed first; if it fails again, a longer error correction process is initiated.

[0071] Steps 1-3 above correspond to the implementation of the incremental evolution and data closed-loop strategy of this solution. For the overall process, please refer to [link / reference needed]. Figure 2 .

[0072] The following is the mathematical model for the rules of this scheme:

[0073]

[0074] in, Represents the global set of rules. Represents the set of State parameters. Represents a set of nodes. This represents the tuple data type. Represents a collection of data types. Representing a set of strings, Flow: acyclic∧closed-loop means simultaneously satisfying the finiteness at the control flow level and the closed-loop nature at the data flow level. Specifically, this includes:

[0075] Global State parameter rules:

[0076] 1. Must contain a messages field; type: tuple; description: general message context (required field); from and to must be null (not associated with specific nodes).

[0077] 2. User input parameters: user_input (original user requirement): type: str; from must be null (initial input); to must contain nodes that will use this parameter (such as LLM type nodes);

[0078] precise_subtask_set: Type: str; from must be null (initial input); to must contain nodes that will use this parameter (such as LLM type nodes).

[0079] 3. Other parameter definition rules:

[0080] Each parameter must include: type: a clear data type (e.g., str / DataFrame); description: a clear description of its purpose; from: the name of the node that generates this parameter; to: a list of node names that use this parameter (an array, or user if none is available).

[0081] 4. Parameter naming uniqueness: All parameter names must be globally unique (repeated definitions are prohibited; for example, duplicate region_data are invalid).

[0082] Workflow node rules:

[0083] Endpoint definition (both_ends):

[0084] begin_node: List of workflow start nodes (nodes without predecessor nodes, and cannot be nodes with too_with_args); final_node: List of workflow end nodes (nodes whose successor is ["end"].

[0085] 1. Node type (node_type): Only three values ​​are allowed: tool_without_args (tool node without parameters); tool_with_args (tool node with parameters); LLM (Large Model node, used only for content generation).

[0086] 2. Node name (node_name): must end with _node (e.g., get_sell_data_node).

[0087] 3. Node description: Must explicitly include: the implementation scheme (e.g., using pandas to merge data); the input parameters of the operation; the generated output; the output must be updated to the state.

[0088] Example: "Merge state.sell_data and state.region_data, calculate the total sales volume and total sales revenue for each region, write the results to sell_area.xlsx and update state.statistical_results".

[0089] 4. Input data (input_data): Must be an array or null (if no input); each input item must include: name: the parameter name corresponding to the state; type: data type; description and example (example value: output str according to the required data format).

[0090] Special rule: LLM type nodes must contain user_input and precise_subtask_set input items.

[0091] 5. Output data (output_data): Must be an array or null (if there is no output). Each output item must include: name: the parameter name that will be updated to the state; type / description / example; the output must be referenced by the to field in the state (for use by subsequent nodes).

[0092] 6. Next node: must be an array of node names (e.g., ["statistic_node"]); the next node of the end node must be ["end"].

[0093] Workflow structure rules:

[0094] 1. Data flow between nodes: The output_data of a node must be referenced by the input_data or the to field of the state of other nodes to form a closed loop.

[0095] 2. LLM node degradation strategy: If an LLM node fails to execute (e.g., due to data errors), global message degradation processing in state.messages must be used.

[0096] Step 4 above is as follows Figure 3 As shown, LLM is used in parallel and passed on to it, enabling the system to autonomously improve the efficiency of code generation by building an ecosystem:

[0097] The vector database searches for the tool nameplate (describing the tool's functionality, input and output parameters) that best matches its JSON tool parameters and points it to the MCP-Server's call path. Before generating code, gen_code_agent (an LLM-type agent) automatically determines which code can be reused or fine-tuned; if reused, it directly generates the remote tool call path method. Each node passes the generated code into the code sandbox.

[0098] The tool code generated by the sandbox rules uses three generated test cases. Only if all three test cases pass is the tool code considered correct. Only when all three test cases pass can a name card be created for the tool, and the code be packaged into an MCP Tool and written to the MCP Server. If an error occurs during the testing of a tool code, the error message node will be rolled back to the generation node for re-execution. If an error occurs twice, a long-process error localization and correction mechanism based on a bidding model and human debugging (Human-imitating Bid Long Error Correction, abbreviated as H-BLEC) will be triggered. Hereinafter referred to as H-BLEC.

[0099] The detailed process of long-process localization and error correction based on bidding model and human debugging is as follows:

[0100] This mechanism mimics human behavior: In actual software development, when developers encounter a particularly tricky bug, they typically first locate the relevant code based on the error message and make modifications. However, such direct fixes often lead to the system continuing to report errors. This strategy can be seen as a low-level error correction mechanism at the system level, i.e., reverting to the previous execution node and retrying. Subsequently, developers may resort to a large language model, providing the complete code and error message as input. However, due to the excessively large input range and the presence of redundant information, the model-generated solutions are often ineffective. It should be noted that this phenomenon does not stem from a lack of model capabilities, but rather from a lack of effective problem constraints and localization. Therefore, a better approach is for developers to first perform preliminary location and analysis of the error, and then provide the model with a filtered problem description, relevant code snippets, and error message to improve the accuracy of its judgment and reasoning.

[0101] H-BLEC incorporates an economics-based bidding model, which helps improve solution quality and system robustness while ensuring efficiency. Specifically, multiple modification agents generate candidate solutions independently and in parallel, ensuring diversity of solutions and reducing the risk of process interruption due to a single path failure. Then, a scoring agent evaluates and ranks the solutions, prioritizing the highest-scoring candidate to reduce invalid attempts and save computational resources. This mechanism combines parallel generation with centralized decision-making, not only improving success rate and execution efficiency but also possessing good scalability and replaceability. It allows for flexible adjustment of the number of agents, scoring criteria, or evaluation strategies in research scenarios. Its implementation process is as follows: Figure 4 As shown, the following mathematical models are included:

[0102]

[0103] in, This represents the i-th node. Represents a set of nodes. Represents a node Tool code, This indicates the generated code. , , These represent three test cases. This represents a code sandbox test function. Functions that indicate whether a tool is registered with the MCP-Server include:

[0104] Scenario 1: When an error occurs during code execution and cannot be resolved after two consecutive retries, the code and its test cases are first input into `gen_print_result_agent`. This agent automatically inserts `print` statements at each stage of code execution and runs them in a sandbox environment, generating complete console output. Then, the code containing the console output and messages from the State are passed to `locate_agent`, which analyzes the execution trajectory of the `print` statements and locates potential error locations. Next, the error information, the test code generated in the previous step, the console output data, and the error location results are distributed to three parallel modification agents (modifier_1_agent, modifier_2_agent, and modifier_3_agent) to fix the code respectively. After the modifications are completed, the three candidate code versions are submitted to `scorer_agent`, which scores each modification (scoring criteria: 10 points maximum, scoring rules mainly based on whether the modified code passes test cases (correctness) 60%, code quality 20%, efficiency 10%, robustness 10%), and generates a code queue sorted from highest to lowest score. Based on the principle of "highest bidder wins," the system prioritizes executing the code with the highest score in the sandbox. If the execution is successful, the process ends; if it fails, the system tries the next candidate solution in turn.

[0105] Scenario 2: When a JSON generation error occurs and two consecutive retries fail to resolve the issue, the system skips the first step and the `locate_agent` handles the error location and subsequent processing. However, the final code sandbox will be replaced by the `rule_check` method.

[0106] In step 5 above, a templated code generation engine is employed. Its core lies in using structured JSON workflow description data (including precise workflow definitions and a robust data closure mechanism) to drive the code generation process. Specifically, the system first parses the `state` parameter in the JSON data, dynamically generating the corresponding global context state class `State` for the workflow. Then, combined with a pre-designed workflow code template, the entire JSON-to-LangGraph code conversion process follows these core rules:

[0107]

[0108] in, This represents the generated workflow code. This represents the template filling function (based on the LangGraph framework). This represents a global state class generated based on a set of nodes. Represents a node The set of execution logic, Represents node routing rules (handling parallel / serial relationships), n a n b n cEach node represents an example node. Specifically, the process is as follows: First, a strongly typed Pydantic state class is generated based on the state definition in the JSON, automatically mapping field types and adding configurations. Then, an asynchronous function is created for each workflow node, generating corresponding remote call or model call logic based on the node type (parameterless tool / parameterized tool / LLM), automatically extracting input parameters from the state and updating output fields. Finally, a directed workflow graph is constructed, intelligently handling edge routing: single successor nodes are connected by direct edges, multiple successor nodes are parallelized using conditional edges, convergence nodes are processed by synchronous edges, starting nodes are triggered in parallel, and ending nodes are connected to END. Finally, the process is compiled and returns an executable workflow object. The entire process strictly maintains the message context, ensuring type safety and workflow integrity. The code generation engine dynamically generates code as follows: by injecting the workflow's JSON data as a context variable into the template, executable Python code is generated using Jinja2's control structures (such as loops and conditional statements). Specifically, the template first defines a Pydantic state class `WorkflowState`. By iterating through each field in the `state` dictionary, class attributes are dynamically generated: Jinja2's `{% for %}` loop iterates through field names and information, adapting type annotations based on field types (e.g., tuple or DataFrame), and setting default values ​​and descriptions to ensure type safety and documentation. Next, the template defines a workflow graph construction function `workflow_graph`, which again uses Jinja2 to iterate through `workflow.nodes`, generating a corresponding asynchronous function for each node: dynamically generating call logic based on node type (e.g., parameterless tool calls, parameterized tool calls, or LLM calls), including input parameter mapping and result updates. The graph structure uses Jinja2 conditional statements (e.g., `{% if %}`) to add edges and conditional edges, enabling flow between nodes (including parallel branching and termination processing), ultimately compiling into an executable state graph.

[0109] Compared to the uncertainty and inefficiency associated with directly generating complete code using large language models, this template-based approach significantly improves code generation speed and first-time success rate. Building upon this, the system leverages the built-in capabilities of the LangGraph framework to implement conditional parallel routing: when multiple nodes' `next_node` points to the same node, these nodes will be executed in parallel; when a node's `next_node` points to multiple nodes, these target nodes will also be executed in parallel. Finally, the system uniformly encapsulates the return type of each node into a `Command` class, ensuring that critical data is correctly updated in the workflow's `messages` list and related properties of the `State` class, thus forming a structurally complete and functionally robust LangGraph workflow code.

[0110] In step 6 above, such as Figure 5 As shown, the workflow code is written to a file and configured to run in Docker on the server:

[0111]

[0112] Specifically, the generated workflow code will strictly adhere to a decoupled architecture between workflow content generation and tools. The original agent_with_tool approach will be replaced by this architecture, exhibiting high robustness similar to that of large models calling tools, and capable of handling various situations. When a subtask is a content generation task that relies on the output of a tool as its input data, thanks to the data closure principle of this solution, steps 2 and 3 above will be designed to: place the tool node before the LLM node; the tool node's output will update the state parameter and be used as input to the LLM node and incorporated into the prompt. Since the starting node cannot be tool_with_args, errors due to this node being at the beginning, resulting in no data source, will not occur. Calling the multimodal large model's interface as an evaluation tool will trigger H-BLEC if both attempts fail.

[0113] The following specific embodiment will provide a more detailed demonstration of the solution provided by the present invention:

[0114] Suppose a user has linked to a MySQL data source and uploaded a sales region table (Excel) for each order. The system is required to analyze the relationship between sales volume and region, generate a report file and statistical chart, and obtain feedback on sales strategies.

[0115] Step 1: Initially decompose user requirements, extract key structures from data sources, and process them in parallel to obtain a pre-decomposed task set.

[0116] Acquire sales and regional data. Perform data analysis and statistics to generate reports. Generate statistical charts. Provide sales strategy analysis.

[0117] Key data examples are as follows:

[0118] data_source": "mysql","table_name": "sell","table_columns": "id","goods_name","num", "total_price" "data_source": "excel", "table_name": "region","table_columns":"id","sell_id","area".

[0119] Step 2: Analyze and obtain the execution order between nodes, and implement the main information of the code. Example:

[0120] "both_ends":

[0121] "begin_node": ["get_sell_data_node", "get_region_data_node"],

[0122] "final_node": ["chart_node", "suggestion_node"]

[0123] "nodes":

[0124] "node_name": "get_sell_data_node","node_type": "tool_without_args","node_parents": [],"next_nodes": ["statistic_node"]

[0125] "node_name": "get_region_data_node","node_type": "tool_without_args","node_parents": [],"next_nodes": ["statistic_node"]

[0126] "node_name": "statistic_node","node_type": "tool_with_args","node_parents": ["get_sell_data_node", "get_region_data_node"],"next_nodes": ["chart_node", "suggestion_node"]

[0127] "node_name": "chart_node","node_type": "tool_with_args","node_parents": ["statistic_node"],"next_nodes": ["end"]

[0128] "node_name": "suggestion_node","node_type": "agent","node_parents":["statistic_node"],"next_nodes": ["end"]

[0129] Step 3: Generate node data containing data loops and finally merge the generated JSON data. An example is shown below:

[0130] "state":

[0131] "messages": "type": "tuple","description": "General message context, required field","from": null,"to": null

[0132] / / There must be "user_input": "type": "str","description": "The user's original input request","from": null","to": ["suggestion_node"], / / Who needs this data

[0133] / / This must contain "precise_subtask_set":"type": "str","description": "User requirements are converted into a precise set of subtasks","from": null","to": ["suggestion_node"]

[0134] "sell_data":"type": "DataFrame","description": "Related data for the 'sell' table","from": "get_sell_data_node","to": ["statistic_node"]

[0135] "region_data":"type": "DataFrame","description": "Related data for the region table","from": "get_region_data_node","to": ["statistic_node"]

[0136] "statistical_results": "type": "DataFrame","description": "Data after merging statistics from the region and sell tables","from": "stastic_node","to": ["chart_node"]

[0137] "statistical_results_path": "type": "str", "description": "File address where final statistical data is stored", "from": "stastic_node", "to": ["suggestion_node"]

[0138] "chart_path": "type": "str","description": "File path of the final statistics table","from": "chart_node","to": ["user"]

[0139] "suggestion": "type": "str","description": "The large model provides sales strategy suggestions based on the current situation","from": "suggestion_node","to": ["user"]

[0140] "workflow":

[0141] "both_ends":"begin_node":["get_sell_data_node","get_region_data_node"],"final_node":["chart_node","suggestion_node"]

[0142] "nodes": "node_type": "tool_without_args", "node_name": "get_sell_data_node",

[0143] "node_description": "Read the three columns of id, num, and total_price from the sell table and update them to state.sell_data.", "input_data": null, "output_data": {"name": "sell_data","type": "DataFrame","description": "The id, num, and total_price of the sell table"},

[0144] "example": """ "next_node": ["statistic_node"],"node_type": "tool_without_args","node_name": "get_region_data_node",

[0145] "node_description": "","input_data": null,"output_data": {"name": "region_data","type": "DataFrame","description": "The data of the region table"},

[0146] "example": " " "next_node": ["statistic_node"],"node_type": "tool_with_args","node_name": "statistic_node",

[0147] "node_description": "",

[0148] "input_data": {"name": "region_data","type": "DataFrame","description": "The data of the region table"},

[0149] "example": " ""name": "sell_data","type": "DataFrame","description":"The data of the sell table", "example": ""

[0150] "output_data": "name": "statistical_results","type": "DataFrame","description": "Data after merging statistics from the region and sell tables", "example": "....""name": "statistical_results_path","type": "str","description": "File path where the final statistical data is stored", "example": "...."

[0151] "next_node": ["chart_node","suggestion_node"],

[0152] "node_type": "tool_with_args",

[0153] "node_name": "chart_node",

[0154] "node_description": "",

[0155] "input_data": "name": "statistical_results","type": "DataFrame","description": "Data merged from the region and sell tables", "example": "...."

[0156] "output_data": "name": "chart_path","type": "str","description": "path to the chart", "example": "D: / / a / xx.png"

[0157] "next_node": ["end"],

[0158] "node_type": "LLM",

[0159] "node_name": "suggestion_node",

[0160] "node_description": "",

[0161] "input_data": "name": "statistical_results","type": "DataFrame","description": "Data after merging and statistically analyzing the region and sell tables", "example": "....""name": "user_input","type": "str","description": "Purpose of the user workflow", "example": "...." "name": "precise_subtask_set","type": "str",

[0162] "description": "", "example": "...."

[0163] "output_data": "name": "suggestion","type": "str","description": "The large model proposes sales strategy suggestions based on the current situation", "example": "D: / / a / xx.png"

[0164] "next_node": ["end"],

[0165] Step 4: Parse the JSON data generated in Step 3. First, search for relevant tools and code in the MCP-Server and FAISS databases. If reusable tools or code are found, reuse them to generate the get_sell_data, get_region_data, and chart_node tool code. This can speed up tool code generation and improve accuracy. Next, perform parallel sandbox testing. After passing, use a template method to package them into MCP Tools and put them into the MCP-Server and FAISS vector databases.

[0166] Step 5: First, based on the state data generated in Step 3, use the template method to create a custom global information data state class (context) `WorkflowState` by filling in data. Then, use the Jinja2 template to build the LangGraph workflow code. An example of the main information in the implementation code is as follows:

[0167] Define the state class WorkflowState:

[0168] Includes fields:

[0169] sell_data: Optional data table;

[0170] region_data: Optional data table;

[0171] statistical_results: Optional data table;

[0172] statistical_results_path: Optional string;

[0173] chart_path: Optional string;

[0174] suggestion: Optional string;

[0175] user_input: Optional string;

[0176] precise_subtask_set: Optional string;

[0177] Define an asynchronous function `call_mcc_tool(client, tool name, parameters)`:

[0178] Print the call information;

[0179] Return simulation results based on the tool name:

[0180] If the tool name is "get_sell_data": it returns simulated sales data;

[0181] If the tool name is "get_region_data": it returns simulated region data;

[0182] If the tool is named "statistic": it combines sales and regional data and calculates statistical results.

[0183] If the tool name is "chart": Returns the path to the simulated chart;

[0184] If the tool name is "suggestion": Returns the simulation suggestion text;

[0185] Define an asynchronous function get_sell_data_node(state, client):

[0186] Use tools to obtain sales data;

[0187] Return the result;

[0188] Define an asynchronous function get_region_data_node(state, client):

[0189] Use tools to obtain regional data;

[0190] Return the result;

[0191] Define an asynchronous function `statistic_node(statistic, client)`:

[0192] Verify that the required data exists;

[0193] Use statistical tools to process data;

[0194] Return the statistical results;

[0195] Define an asynchronous function chart_node(state, client):

[0196] The statistical results have been verified.

[0197] Call the chart generation tool;

[0198] Return to the chart path;

[0199] Define an asynchronous function suggestion_node(state, client):

[0200] The statistical results have been verified.

[0201] Call the suggestion generation tool;

[0202] Return the suggested text;

[0203] Define the function create_async_workflow(client):

[0204] Create a workflow diagram;

[0205] Add functions to all nodes (binding client parameters);

[0206] Configure workflow structure:

[0207] The start node triggers in parallel the nodes for acquiring sales data and acquiring regional data;

[0208] The statistics node is triggered after both data nodes are completed;

[0209] After the statistical node is completed, chart generation and suggestion generation nodes are triggered in parallel.

[0210] The workflow ends once the charts and suggested nodes are completed.

[0211] Compile and return the workflow;

[0212] Define an asynchronous function run_workflow (client):

[0213] Create a workflow instance;

[0214] Initialization state;

[0215] Execute the workflow asynchronously and output the results of each node;

[0216] Define the main function main():

[0217] Create a simulated client;

[0218] Execute the workflow;

[0219] Close the client;

[0220] Program entry point:

[0221] Run the main function.

[0222] Step 6: Test the code generated in Step 5 using a code sandbox (the code sandbox has already built the necessary Python environment; it directly runs the generated code and passes all process data and results to a model specifically for evaluating the results). Based on user needs, a statistical data table and sales strategy suggestions will be generated. Here, the Tongyi Qianwen multimodal large model is used to evaluate the results. If it fails, DeepSeek R1 is used to find the problem and modify the code. If it fails more than twice, H-BLEC will be triggered, and the code will be re-executed. If it finally passes, a workflow card will be created, and the code and structured data will be persisted to FAISS.

[0223] Based on the same inventive concept, this invention also provides a computer device, comprising: one or more processors, and a memory for storing one or more computer programs; the programs include program instructions, and the processor executes the program instructions stored in the memory. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, used to implement one or more instructions, specifically for loading and executing one or more instructions stored in a computer storage medium to implement the above-described method.

[0224] It should be further explained that, based on the same inventive concept, the present invention also provides a computer storage medium storing a computer program, which, when executed by a processor, performs the above-described method. This storage medium can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0225] It should be noted that, unless otherwise defined, the technical or scientific terms used in this invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0226] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

[0227] This invention is not limited to the preferred embodiment described above. Anyone inspired by this invention can derive other forms of automated workflow code generation methods driven by large models. All equivalent changes and modifications made within the scope of this invention should be considered within the scope of this invention.

Claims

1. A method for automatically generating workflow code driven by a large model, characterized in that, include: Through multi-level intelligent agent collaboration, the original requirements are transformed into sub-task sets, node relationship diagrams, and structured workflow description data in sequence. The last level of intelligent agent enforces the verification of data closure between nodes: node input data must come from the output of the preceding node or the initial state parameters, and node output data must be referenced by subsequent nodes or updated to the state parameters. In the workflow description data, tool nodes and content generation nodes are defined. Tool nodes perform operations through preset interfaces and update the output to the global context state parameters. Content generation nodes generate text content with the global context state parameters as input, thereby decoupling content generation from tool invocation. The structured workflow description data is parsed, and a strongly typed state class that maps to the description data is dynamically generated. The state class contains message tuple fields and automatically fills in node call logic and parallel routing rules based on a preset code template to generate workflow code. When the code runs into error and the number of retries exceeds a preset threshold, the error location agent generates an execution trajectory, multiple repair agents generate candidate solutions in parallel, and after the scoring agent adaptively scores based on the error type, the repair solutions are verified and executed in sequence. The multi-level intelligent agent includes a task decomposition intelligent agent, a node orchestration intelligent agent, and a data closed-loop intelligent agent, which perform the following operations in sequence: The task decomposition agent performs a preliminary decomposition of the original requirements, generates a pre-decomposed set of subtasks, and extracts key data source information in parallel. The node orchestration agent constructs a directed graph of node relationships based on a pre-decomposed set of subtasks, defining the upstream and downstream relationships and types of each node; The data closed-loop intelligent agent performs rule verification on the directed graph of node relationships, forces the improvement of data dependencies between nodes, and generates structured workflow description data. The data loop verification rules include: All parameter names are globally unique and must include the data type, purpose description, source of generated nodes, and list of nodes used; The output data of a node must be referenced by the input data of other nodes or the global context state parameters to form a closed loop of data flow without redundancy; The global context state parameters include the general message context, the user's original requirements, the precise subtask set, and the input and output parameters of each node. The general message context is a required field and is not associated with any specific node. The strongly typed state class is a custom class built on the Pydantic framework. Its fields are mapped one-to-one with the global context state parameters in the structured workflow description data, and it automatically inherits the data type and constraint rules of the parameters. The preset code template is a dynamic template based on the LangGraph framework. The parallel routing rules include: multiple nodes pointing to the same successor node are executed in parallel, or a single node pointing to multiple successor nodes are executed in parallel. The error location agent generates complete console output by inserting print statements during the code execution phase, and locates the error location based on the output trajectory; the multiple repair agents are at least three, and generate independent repair schemes in parallel.

2. The method for automatically generating workflow code driven by a large model according to claim 1, characterized in that: The types of nodes include tool parameterless nodes, tool parameterized nodes, and content generation nodes. The node orchestration agent determines the node type corresponding to each subtask through preset rules and explicitly marks it through the node type field.

3. The method for automatically generating workflow code driven by a large model according to claim 1, characterized in that: After the output of the tool node is updated to the global context state parameters, it is used as the input parameter of the content generation node and incorporated into its processing logic. Tool nodes with parameters must not be used as the starting node of the workflow.

4. The method for automatically generating workflow code driven by a large model according to claim 1, characterized in that: The structured workflow description data is in JSON format and includes global context state parameter definitions, node attributes, and routing relationships between nodes. The node attributes include node name, type, description, input data, and output data.

5. The method for automatically generating workflow code driven by a large model according to claim 1, characterized in that: When the structured workflow description data is generated incorrectly and retrying fails to resolve the issue, the error localization agent directly locates the error in the description data, and the subsequent repair solution is verified through data closed-loop verification rules. After the workflow code is generated, it is tested through a code sandbox. Once the test is passed, the workflow code and structured workflow description data are stored in a vector database, and the tool code is stored in a tool server to achieve resource reuse.

6. A workflow code automatic generation system driven by a large model, used to implement the method as described in claim 1, characterized in that, include: The task structuring module is used to transform the original requirements into a set of subtasks, a node relationship diagram, and structured workflow description data through multi-level intelligent agent collaboration. The last-level intelligent agent forces the verification of data closure between nodes: the node input data comes from the output of the preceding node or the initial state parameters, and the node output data is referenced by subsequent nodes or updated to the state parameters. The node decoupling module is used to define tool nodes and content generation nodes in the workflow description data. Tool nodes perform operations through preset interfaces and update the output to the global context state parameters. Content generation nodes generate text content with the global context state parameters as input, thereby decoupling content generation from tool invocation. The code generation module is used to parse the structured workflow description data, dynamically generate a strongly typed state class that maps to the description data and contains message tuple fields, and automatically fill in the node call logic and parallel routing rules based on a preset code template to generate workflow code. The error correction module is used to generate an execution trajectory through an error location agent when the code runs incorrectly and the number of retries exceeds a preset threshold. Multiple repair agents generate candidate solutions in parallel, and after the scoring agent adaptively scores the solutions based on the error type, the repair solutions are verified and executed in sequence.

Images