Dsl-based code generation method and apparatus

Abstract

The application discloses a DSL-based code generation method and device, and relates to the technical field of computers.The method comprises the following steps: obtaining a workflow description defined according to a domain-specific language and user requirements; performing structural analysis on the workflow description to obtain a structured data set, wherein the structured data set comprises multiple nodes, a node type corresponding to each node, and a connection relationship between the multiple nodes; generating a code skeleton according to the multiple nodes and the multiple node types, and constructing a node graph structure according to the connection relationship; and performing compilation according to the code skeleton and the graph structure to obtain an executable code file.The method solves the problems that existing code generation technologies are difficult to manage in versions and difficult to guarantee semantic consistency and stability, reduces the complexity of workflow development, improves the development efficiency, and can realize complex functions by using the rich ecology of Python.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method and apparatus for generating code based on DSL. Background Technology

[0002] With the deepening of enterprise digital transformation, the demand for software development has exploded. Most new applications are now developed using low-code / no-code tools. Low-code platforms, through graphical interfaces and visual orchestration technology, abstract repetitive coding work in traditional development into drag-and-drop component configuration, significantly shortening application delivery cycles. Platforms such as Salesforce Lightning and Microsoft Power Apps already support the rapid construction of enterprise-level applications through process designers, enabling non-specialist developers to participate in software development.

[0003] Current low-code platforms typically rely on graphical orchestration as their core, completing processes through runtime interpretation and execution. Their core architecture uses visual modeling tools to convert business logic into an intermediate representation, which is then dynamically executed by the interpretation engine. However, this approach lacks "executable code artifacts" oriented towards engineering, and cannot directly generate versionable Python code. Furthermore, existing technologies mostly remain at the "orchestration-interpretation" stage, failing to form a complete closed loop. During interpretation and execution, key semantics such as variable scope mapping and template replacement rules differ between different nodes, making it difficult to guarantee semantic consistency and operational stability.

[0004] There is currently no effective solution to the problems of version management and semantic consistency and stability in existing technologies. Summary of the Invention

[0005] The main objective of this application is to provide a DSL-based code generation method and apparatus to solve the problems of difficulty in version management and semantic consistency and stability in the prior art, reduce the complexity of workflow development, improve development efficiency, and realize complex functions.

[0006] To achieve the above objectives, according to one aspect of the embodiments of this application, a code generation method based on a DSL is proposed, comprising: obtaining a workflow description defined according to a domain-specific language and user requirements; performing structured parsing on the workflow description to obtain a structured data set, the structured data set including multiple nodes, a node type corresponding to each node, and connection relationships between the multiple nodes; generating a code skeleton based on the multiple nodes and the multiple node types, and constructing a node graph structure based on the connection relationships; and compiling based on the code skeleton and the graph structure to obtain an executable code file.

[0007] According to another aspect of the embodiments of this application, a DSL-based code generation apparatus is also provided, comprising: an acquisition unit for acquiring a workflow description defined according to a domain-specific language and user requirements; a parsing unit for performing structured parsing on the workflow description to obtain a structured data set, wherein the structured data set includes multiple nodes, a node type corresponding to each node, and connection relationships between the multiple nodes; a generation unit for generating a code skeleton based on the multiple nodes and the multiple node types, and constructing a node graph structure based on the connection relationships; and a compilation unit for compiling based on the code skeleton and the graph structure to obtain an executable code file.

[0008] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, which stores computer instructions for causing a computer to perform the DSL-based code generation method described above.

[0009] According to another aspect of the embodiments of this application, an electronic device is also provided, the electronic device including: at least one processor, and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform the DSL-based code generation method described above.

[0010] In this application, the above-described DSL-based code generation method and apparatus solve the problems of difficulty in version management and difficulty in ensuring semantic consistency and stability in the prior art, reduce the complexity of workflow development, improve development efficiency, and can utilize Python's rich ecosystem to realize complex functions. Attached Figure Description

[0011] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings:

[0012] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 A schematic diagram of the hardware environment for an optional DSL-based code generation method provided in this application; Figure 2 A flowchart illustrating an optional DSL-based code generation method provided in this application; Figure 3A flowchart illustrating yet another optional DSL-based code generation method provided in this application; Figure 4 A schematic diagram of an optional DSL-based code generation device provided for this application; Figure 5 A schematic diagram of an optional electronic device provided in this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0014] It should be noted that the terms "first," "second," etc., in this application specification, claims, and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. Without conflict, the embodiments and features in the embodiments of this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0015] To address the challenges of version control and ensuring semantic consistency and stability in existing code generation technologies, this application provides a DSL-based code generation method and apparatus. As an optional embodiment, the DSL-based code generation method can be applied, but is not limited to, to applications such as... Figure 1 In the DSL-based code generation system shown, consisting of terminal device 102 and server 104, as follows: Figure 1As shown, terminal device 102 is connected to server 104 via network 110. Network 110 may include, but is not limited to, wired networks and wireless networks. The wired network includes local area networks (LANs), metropolitan area networks (MANs), and wide area networks (WANs). The wireless network includes Bluetooth, Wi-Fi, and other networks that enable wireless communication. Terminal device 102 may include, but is not limited to, at least one of the following: mobile phones (such as Android phones, iOS phones, etc.), laptops, tablets, handheld computers, MIDs (Mobile Internet Devices), tablets, desktop computers, smart TVs, in-vehicle devices, etc.

[0016] The aforementioned terminal device 102 is also equipped with a display 106, a processor 108, and a memory 112. The display 106 can be used to display the code generation process, the processor 108 can be used to process the collected data, and the memory 112 can be used to store relevant data. It is understood that when the terminal device 102 receives a user's code generation request, it sends the code generation request to the server 104 via the network 110. The server 104 responds to the code generation request and implements the specific code generation process.

[0017] The aforementioned server 104 can be a single server, a server cluster consisting of multiple servers, or a cloud server. The aforementioned server 104 includes a database 114 and a processing engine 116. The database 114 can be used to store data, models, etc., and the processing engine 116 is used to process the aforementioned data.

[0018] According to one aspect of the present invention, the above-described DSL-based code generation system may further perform the following steps: First, the terminal device 102 performs the following... Figure 1 As shown in S102; then, server 104 executes as follows Figure 1 As shown in S104 to S110, code generation is achieved.

[0019] In this embodiment of the invention, the above-described DSL-based code generation method solves the problems of difficulty in version management and difficulty in ensuring semantic consistency and stability in the prior art.

[0020] As an alternative implementation method, please refer to Figure 2 This document illustrates a flowchart of a DSL-based code generation method according to an embodiment of this application. The method includes at least one of the following steps (S202 to S208): S202, Obtain the workflow description defined according to the domain-specific language and user requirements; S204, Perform structured parsing on the workflow description to obtain a structured data set, which includes multiple nodes, the node type corresponding to each node, and the connection relationships between multiple nodes; S206, Generate a code skeleton based on multiple nodes and multiple node types, and construct a node graph structure based on the connection relationships; S208, Compile the code skeleton and graph structure to obtain an executable code file.

[0021] In S202 above, a Domain-Specific Language (DSL) is a computer language specifically designed for a particular application domain. Unlike general-purpose programming languages ​​such as Python and Java, it is not applicable to all domains but focuses on providing efficient and professional expressions within a specific domain, such as SQL for database queries and regular expressions for text matching. A workflow refers to a series of interconnected, logically ordered steps or tasks that work together to complete a business process. The execution order and conditions can be clearly defined. For example, a smart price comparison workflow can be described as: "Start Node - Vector Retrieval - Retrieval Results - Tool Instructions - Agent - Data Query Results - Summary Output - Output - End Node".

[0022] In S204, structured parsing involves analyzing text (such as DSL workflow descriptions) and converting it into a well-formatted data structure (structured data set) that is easily processed and understood by computer programs, such as lists, trees, and graphs. In S206, the code skeleton includes the framework or template of the code. It contains the main structure of the program (such as classes, methods, key variable definitions, and control flow statements), but may lack specific business logic implementation details. The node graph structure involves constructing a directed acyclic graph based on the input-output relationships between nodes (such as the output of node A serving as the input of node B). In S208, compilation based on the code skeleton and graph structure includes the entire process of combining the code skeleton and node graph structure to generate the final executable code.

[0023] Through the above-described embodiments of this application, the above-described DSL-based code generation method solves the problems of difficulty in version management and difficulty in ensuring semantic consistency and stability in the prior art. It reduces the complexity of workflow development, improves development efficiency, and can utilize the rich ecosystem of Python to realize complex functions. It can support auditing and reproduction, has low usability and learning cost, facilitates collaboration and version governance, and can achieve observability and cost control.

[0024] As an optional implementation, after performing structured parsing on the workflow description, the method further includes: S1, performing integrity verification on the workflow description to obtain workflow description integrity, wherein the integrity verification includes structural integrity verification; S2, performing consistency verification on the workflow description to obtain workflow description consistency, wherein the consistency verification includes type consistency verification; S3, performing semantic normalization on the workflow description to obtain normalized workflow; S4, unifying the scope of the normalized workflow to obtain a structured data set.

[0025] In S1 above, structural integrity verification ensures that the DSL file contains all necessary components. Structural integrity verification includes: 1. Basic field verification: verifying the existence of core fields such as version, kind, app, nodes, and edges; 2. Node integrity verification: checking the uniqueness of the start node, the reachability of the end node, and the uniqueness of the node ID; 3. Connection integrity verification: verifying that the source and target nodes of all edges actually exist, avoiding dangling connections; 4. Configuration integrity verification: checking the proprietary configuration fields for specific node types (LLM / tools / conditions, etc.).

[0026] In S2 above, type consistency verification ensures that data flows correctly between nodes. Type consistency verification includes: 1. Type mapping: Mapping common data types such as string, number, and object in the DSL to the internal VariableType enumeration, where the VariableType enumeration refers to a standardized set of variable types defined internally by the system; 2. Variable selector verification: Checking that the variables referenced by the variable reference path or locator class selector (such as ["conversation", "user_input"]) actually exist; 3. Input-output matching: Verifying that the input variable type of the node is compatible with the output type of the upstream node; 4. Default value type: Ensuring that the default value of the variable is consistent with the declared type, where the declaration includes specifying the type of the variable in advance when defining the workflow. In S3 above, semantic normalization involves performing semantic normalization on the parsed results of the workflow description, unifying diverse expressions into standard semantics. In S4 above, the scope unification operation clarifies and coordinates the scope of each element, specifically including unifying variable scopes and paths, and standardizing template placeholders. Scope includes global scope and node-specific scope. The core variables in the global scope include: conversation_variables: session-level input (data generated and used during specific, continuous interactions); memory_variables: long-term memory (historical data that is persistently stored and shared and accessed across multiple sessions); environment_variables: environment constants (relatively fixed configuration parameters or constants that are valid globally).

[0027] Variable naming and storage annotation within a node's local scope include: Start node input: Original names are not appended with any systematic prefixes, suffixes, or spaces to ensure the readability and intuitiveness of the workflow definition, such as Type, Name, Quantity, Cost, etc.; Path variable standardization: Generate a globally unique "path alias" for each node variable, such as N{nodeId}_{var_name}; State writing and synchronization: 1. Write rules: When a node generates a variable value, that value is written to two storage paths simultaneously, such as writing state[var_name] and state simultaneously. [N{nodeId}_{var_name}] facilitates both global and fixed-point access; 2. Runtime recovery: When it is necessary to resume workflow execution from a saved breakpoint, the system needs to rebuild the variable state at that time, such as silently synchronizing variables from the start node to state and N{start_node_id}_{name}; 3. Use "friendly variable placeholders" uniformly, such as {{N{nodeId}_{var_name}}}: {{Naaeaa97e46da4efbbcdd1cb2c5f4f637_output}}).

[0028] The above S1-S4 together form a preprocessing procedure for workflow description, which can provide reliable, standardized, and unambiguous input data for subsequent processing.

[0029] As an optional implementation, the above-mentioned generation of code skeleton based on multiple nodes and multiple node types includes: S1, generating a node sequence list using a graph algorithm based on multiple nodes and connection relationships; S2, parsing parameters of the workflow description to obtain node parameters corresponding to each node; S3, constructing a global variable table and a node local variable table based on multiple nodes using a variable selector; S4, generating a global code skeleton based on the global variable table, multiple node parameters, and the node sequence list; S5, generating a local code skeleton corresponding to each node based on the node sequence list, multiple node types, multiple node parameters, and the node local variable table. The code skeleton includes a global code skeleton and multiple local code skeletons.

[0030] Specifically, S1 above can construct a node execution graph based on multiple nodes and their connections, and then use a graph algorithm to perform a node-first search on the node execution graph to obtain a node sequence list, where the node sequence list includes the execution order of the nodes. The graph algorithms mentioned above include DFS (Depth-First Search) and BFS (Breadth-First Search). The node parameters in S2 above include input parameters and output parameters.

[0031] The variable selector in S3 mentioned above is a mechanism in DSL used to reference and extract variable values. It can analyze all the variables needed for the entire process and build a global variable table and a node local variable table. For example, the input variable selector of the LLM node: inputVariables: -name:"user_query"; selector:["conversation", "user_input"] (selected from session variables); -name:"context"; selector:["sys", "retrieval_result"] (selected from system variables). The above selectors are converted into expressions that can be directly used for code generation, including: N557408642e3b4e8ead07fb36f7cf0144_result:Optional[List[str]]=None;data=state.get("Naaeaa97e46da4efbbcdd1cb2c5f4f637_output",""). Additionally, the process of obtaining data using the above variable selectors includes: 1. Variable referencing – specifying the data source path, such as ["conversation", "user_input"]; 2. Dynamic binding – extracting the actual value from the state at runtime; 3. Multi-level access – supporting nested data structures, such as ["env", "config", "api_key"]; 4. Type safety – ensuring that the variable type matches the node requirements.

[0032] In S4-S5 above, the global code skeleton includes the overall framework and infrastructure of the entire workflow or system at the code level. It can define the program's entry point, core control flow, main data structures (such as global variables and context objects), and arrange the execution order and interaction methods of each node. The local code skeleton can correspond to the functional code block of each specific node in the workflow. Based on the node's type and parameters, it generates a function or method framework that implements the specific business logic of that node.

[0033] The above S1-S5 can automatically and systematically transform abstract business processes (nodes and connections) represented in diagram form into a program code framework with a clear structure, distinct hierarchy, and explicit data flow, which greatly reduces the conversion cost and error probability from design to implementation.

[0034] As an optional implementation, the above-mentioned method of constructing a global variable table and a node local variable table based on multiple nodes using variable selectors includes: S3-1, obtaining the application scenario corresponding to the workflow description, and obtaining the predefined rules corresponding to the application scenario; S3-2, constructing multiple variable selectors corresponding to each node based on the predefined rules and multiple nodes; S3-3, parsing variables in the workflow description based on multiple nodes to obtain multiple node variables corresponding to each node; S3-4, constructing a global variable table and a node local variable table based on multiple node variables, multiple variable selectors, and multiple nodes.

[0035] In S3-1 to S3-2, the application scenarios include different specific business domains or problem domains. Different application scenarios correspond to different predefined rules. Among them, the predefined rules include a set of pre-set rule bases or strategies that can be used to guide how to intelligently select and configure variables for each node in the workflow.

[0036] In S3-3 to S3-4 above, variable parsing includes identifying and extracting all defined or referenced variable information from structured data.

[0037] Through S3-1 to S3-4 above, the system can make the variable selector construction process intelligent and domain-adaptive based on application scenarios and predefined rules. Instead of mechanically processing variables, it can call the corresponding best practice rules according to specific business scenarios (such as finance, e-commerce, and data science), thereby automatically and accurately classifying the variables parsed in the workflow into the global scope or local scope.

[0038] As an optional implementation, the above-described method of constructing a global variable table and a node-local variable table based on multiple node variables, multiple variable selectors, and multiple nodes includes: S3-4-1, obtaining the variable scope corresponding to each node variable and determining the variable type corresponding to each node variable based on the variable scope; S3-4-2, obtaining the variable priority corresponding to each variable type; and S3-4-3, constructing a global variable table and a node-local variable table based on multiple nodes, multiple variable priorities, and the variable type corresponding to each node variable. In S3-4-1, variable scope indicates the range within which a variable can be accessed and used in the code, such as global scope and local scope; variable type can include global variables and local variables. In S3-4-2 and S3-4-3, variable priority indicates a decision-making mechanism used to resolve conflicts in variable scope partitioning. For example, when a variable may be simultaneously partitioned into global and local scopes according to different rules, the priority rule will determine which partitioning is ultimately adopted.

[0039] Through the above S3-4-1 to S3-4-3, the system can further ensure the accuracy and conflict-free nature of variable partitioning results through a refined judgment mechanism of variable scope and variable priority, thereby generating code with a clearer structure and more rigorous logic.

[0040] As an optional implementation, the above-described construction of a global variable table and a node local variable table based on multiple nodes, multiple variable priorities, and the variable type corresponding to each node variable includes: S1. Based on the variable type and priority of each node variable, divide the multiple node variables into multiple global node variables and multiple local node variables; S2. Construct a first variable table and a second variable table according to preset table building rules, and obtain the variable metadata corresponding to each node variable; S3. Map the node variables of the first variable table to multiple nodes, multiple variable metadata, and multiple global node variables to obtain a global variable table; S4. Map the node variables of the second variable table to multiple nodes, multiple variable metadata, and multiple local node variables to obtain a node local variable table.

[0041] S1 above categorizes multiple node variables based on variable type and variable priority. For example, if a node variable is both a global and a local variable, its priority determines whether it is a global or local node variable. S2 above's variable metadata includes data describing the variable's own attributes, going beyond the variable name and value itself, providing more detailed definition information. S3-S4 above's node variable mapping maps nodes, variable metadata, and corresponding global node variables to the first variable table, and local node variables to the second variable table.

[0042] Through the above S1-S4, the system clearly classifies variables through variable partitioning operations, enriches variable definitions by introducing variable metadata, and establishes a precise association between variables and nodes through node variable mapping. Finally, it systematically and automatically generates a global variable table and a node local variable table that can be directly used for code generation.

[0043] As an optional implementation, the above-mentioned generation of global code skeleton based on global variable table, multiple node parameters and node sequence table includes: S1, performing variable parsing on global variable table to obtain global variable metadata corresponding to multiple global node variables; S2, obtaining preset code generation type, and inputting the preset code generation type, multiple global node variables and multiple global variable metadata into global skeleton generation model to output global code skeleton.

[0044] The global variable metadata in S1 above includes the variable name, data type, and initial value. For example, the variable name is "result," the data type is "int," and the initial value is 0. The global skeleton generation model in S2 above is a model pre-trained using training samples.

[0045] Through S1-S2, the system automatically converts the finely processed global variables, parameters, and code type requirements into a well-structured global code skeleton using a global skeleton generation model. This achieves automated and standardized generation from data definition to code framework, significantly improving the accuracy and efficiency of code generation.

[0046] As an optional implementation, the above-mentioned generation of a local code skeleton corresponding to each node based on a node order list, multiple node types, multiple node parameters, and a node local variable table includes: S1, perform variable parsing on the node local variable table to obtain local variable metadata corresponding to multiple node local variables; S2, input the preset code generation type, node order list, multiple node types, multiple node parameters, and multiple local variable metadata into the local skeleton generation model, and output the local code skeleton corresponding to the node order list. The local code skeleton includes sub-code skeletons corresponding to multiple node types.

[0047] In S1, local variable metadata includes data parsed from the node local variable table, describing the detailed attributes of each local variable. In S2, the skeleton order of multiple sub-code skeletons corresponds to the node order list. The system integrates node order, type, parameters, and local variable information through a local skeleton generation model, automatically generating a highly customized local code skeleton for each node. This ensures that the code logic of each independent step in the workflow is accurate and complete, and matches the global structure.

[0048] As an optional implementation, the above-mentioned local skeleton generation model is input with a preset code generation type, node order list, multiple node types, multiple node parameters, and multiple local variable metadata, and outputs a local code skeleton corresponding to the node order list, including: S2-1, Generate a node order skeleton based on the preset code generation type, node order list, and multiple node types. The node order skeleton is used to indicate the execution order of the sub-code skeletons. S2-2, Generate a sub-code skeleton corresponding to each node type based on multiple node types, multiple node parameters, and multiple local variable metadata. S2-3, Map the sub-code skeleton corresponding to each node type to the node order skeleton to obtain the local code skeleton.

[0049] S2-1 above first ignores the specific internal logic of each node. For the overall control flow of the workflow, it generates a node sequence skeleton based on the preset code generation type, the order of nodes in the list, and the node type (e.g., decision branch, loop, sequential execution). S2-2 above performs in-depth processing on each individual node, determining the corresponding sub-skeleton template for each node type, and generating multiple sub-code skeletons based on node parameters, local variable metadata, and multiple sub-skeleton templates. S2-3 above can be understood as the assembly of the sub-code skeletons: according to the logical order and structure specified by the node sequence skeleton, the sub-code skeletons are precisely filled and mapped to the corresponding positions, thus obtaining the local code skeleton.

[0050] Through the progressive steps from S2-1 to S2-3, the system decouples and automates the complex task of generating local code. First, it generates a macro structure that ensures logical correctness, then it generates independent code modules with accurate details, and finally it performs precise assembly. This systematically ensures the dual quality and reliability of the generated code skeleton in terms of both overall logic and local implementation.

[0051] For example, in the specific implementation process, during the template rendering stage, the system generates standard Python function skeletons according to node types, including: constructing the main entry point and input parameter injection, execution and output mapping for code nodes; generating system / user prompt word assembly and result collection for LLM nodes (LLM nodes are core components in AI workflows or intelligent agent frameworks used to call large language models (LLM), responsible for processing text input, generating responses and performing specific tasks); completing text template replacement or JSON serialization for output nodes and uniformly inserting the minimum necessary trace record keys (in computer systems, trace record keys usually refer to key attributes or fields used to identify, filter or associate trace records) to ensure subsequent auditing and playback; and then compiling the graph structure and state type according to edge relationships: generating TypedDict - TypedDict is a dictionary structure constraint in Python type annotation, used to declare what keys the dict has and the type corresponding to each key.

[0052] As an optional implementation, the above-mentioned compilation based on the code skeleton and graph structure to obtain an executable code file includes: S1, fusing the global code skeleton and the local code skeleton to obtain reference code; S2, determining the entry point and the execution order of multiple nodes based on the graph structure; S3, compiling the reference code into an executable workflow object based on the entry point and the execution order; S4, exporting the workflow object according to a preset file format to obtain an executable code file.

[0053] In S1-S2 above, skeleton fusion can use a pre-trained skeleton fusion model; the entry point refers to the starting node where the entire workflow begins execution.

[0054] In S3 above, the workflow object refers to a runtime instance formed by compiling the "reference code," containing the complete logic, state, and context of the workflow. The compilation process refers to transforming the high-level, general "reference code" into an entity that can be directly scheduled and executed in a specific runtime environment. For example, compilation based on reflection and dynamic loading (common in strongly typed language platforms such as Java) includes the following steps: 1. Static compilation: First, a standard compiler (such as javac) is used to compile the "reference code" into bytecode files (such as .class files). 2. Dynamic loading and instantiation: Then, the system dynamically loads the class using Java's reflection mechanism (Class.forName("StartNode")) based on the "entry point" information (e.g., the class name corresponding to the entry point is StartNode). 3. Building the object graph: After loading, the system creates instances of all nodes according to the "execution order" (i.e., the graph structure) and connects them according to the connection relationship through setter methods or constructors, forming an object graph in memory. This object graph is a workflow object, and each node object contains its specific execution logic. The final result is an object network (workflow object) containing all node instances and correctly connected through reference relationships. In S4 above, the preset file formats include, but are not limited to: JAR / WAR files, Docker images, etc. S1-S4 generate complete code through skeleton fusion, then compile it into an in-memory workflow object based on the execution logic determined by the graph structure, and finally export it as a standardized file as needed. This achieves end-to-end fully automated generation of the entire DSL workflow description into a cross-platform, immediately executable file.

[0055] For example, the above compilation process specifically includes: class WFW570938State(TypedDict): (Procurement Details Intelligent Price Comparison Workflow Status Definition); # Basic Status Fields (Workflow Engine Core Status); question: str; answer: Optional[str]; current_node: Optional[str]; execution_id: str; error: Optional[str]; # Node Output Variables; # Input Parameter Fields (Initial Input of the Workflow); Type: Optional[str]; Neeb84e3bb2ae48cfb2e5c18fcda7ca1b_Type: Optional[str]; Name: Optional[str]; Neeb84e3bb2ae48cfb2e5c18fcda7ca1b_Name: Optional[str]; Quantity: Optional[str]; Neeb84e3bb2ae48cfb2e5c18fcda7ca1b_Quantity: Optional[str]; Cost: Optional[str]; Neeb84e3bb2ae48cfb2e5c18fcda7ca1b_Cost: Optional[str]; Total: Optional[str]; Neeb84e3bb2ae48cfb2e5c18fcda7ca1b_Total: Optional[str]; Supplier: Optional[str]; Neeb84e3bb2ae48cfb2e5c18fcda7ca1b_Supplier:Optional[str]; Model: Optional[str]; Neeb84e3bb2ae48cfb2e5c18fcda7ca1b_Model:Optional[str]; # Node output variables (intermediate data generated during workflow execution); N9448bf5b48ea459dbc5146ca1c4a2d1a_output: Optional[Any]= None; None; N7159f0c16172452f8e1110c385c84e94_output: Optional[Any] =None;N7e69f6d86e014528a4e4683e42a5a75e_output: Optional[Any]= None; Na26f22242fdf4cd98ab3d9f6ae1910ac_output: Optional[str]; Na26f22242fdf4cd98ab3d9f6ae1910ac_Name: Optional[str]) or equivalent state definitions, setting the entry point and node topology to form an executable workflow object.

[0056] Furthermore, to ensure a clear module organization in the generated Python files, the following steps are necessary: ​​centralized imports in the file header, state types and utility functions first, node functions and graph construction in the middle, and entry orchestration and exports last. This method ensures consistency between orchestration semantics and generated code: variable paths and template replacements are strictly aligned on both the generation and runtime sides; naming conventions are aligned: variable names on the orchestration side (front-end generating JSON) are free of spaces and have consistent capitalization; the types and keys on the generated Python side are strictly matched, such as Quantity / Cost and N{nodeId}_Quantity / N{nodeId}_Cost; the scopes of variables are aligned, including session variables, memory variables, and variables of the starting node: the starting node input simultaneously writes the global key and path key; reading methods are aligned: all cross-node reads are unified as state.get("N{nodeId}_{field}", default value), avoiding the mixing of multiple reading methods; node outputs are unified, improving the readability of cross-node data streams.

[0057] The benefits of the strict alignment mentioned above include: First, easy source identification: seeing N{nodeId}_xxx tells you which node produced the field; second, consistent cross-node references: the orchestration-side selector and the runtime-side state key have the same name, reducing mismatches like "selecting A and reading B"; third, higher troubleshooting efficiency: unified key names in logs / traces eliminate the need for reverse deduction to locate problems; fourth, more stable templates: friendly variables after template binding are read-only, and only the binding mapping needs to be changed when the source remains the same; and fifth, the final output is "executable and versionable" Python workflow code, facilitating project implementation, offline reproduction, and compliance auditing, while providing a stable foundation for subsequent execution and observation.

[0058] Optionally, the implementation methods of this application also include: 1. Using an interpreted workflow engine, the DSL is first converted into an intermediate semantic tree (IR), and the runtime interpreter executes the node logic according to the graph, generating Python source code without storing it on the disk, thereby obtaining cross-language and hot-update capabilities, while unifying variable scope, timeout, and error rollback at the engine layer; 2. Static templated code generation can also be used, but the target language and runtime can be changed, for example, using a unified JSON Schema and template rendering to generate server-side code (such as Java / C#), and the node logic is provided in the form of containerized function registration, and input injection, output mapping, and trace recording are implemented through a unified entry point wrapper, avoiding the limitations of language binding on system evolution; 3. The DSL can also be converted into a graph definition of a general orchestration engine (such as DAG / state graph / directed flow), and the nodes are attached as remote services, with the orchestration platform providing health checks, retry, and rollback strategies; type consistency verification and placeholder normalization are completed at the transformation layer, thereby reusing mature scheduling and observation capabilities. 4. No-code orchestration + service proxy mode: The front-end visual configuration is fixed as a DSL. At runtime, the service proxy selects the local / container / HTTP fast path for execution, unifying rate limiting and cost measurement. All observation audits (trace, tokens, latency) are archived in the proxy layer, realizing canary release and A / B testing without having to generate and maintain the local source code.

[0059] The above-described embodiments of this application solve the problems of difficulty in version management and difficulty in ensuring semantic consistency and stability in the prior art. It can calculate the association value between the user's uninstalled software and the user's installed software based on the user's installation information, and recommend software to the user to install based on the association value. Thus, it realizes intelligent and personalized software installation recommendations based on the software installation environment on the user's computer, so that the uninstalled software recommended to the user can well meet the needs of different users.

[0060] For example, such as Figure 3 As shown, in the specific implementation process, the DSL-based code generation method includes the following steps: S1, Acquiring and Parsing the DSL Model: This involves reading the workflow definition from a low-code orchestration DSL (such as JSON / YAML), extracting node types (start, code, LLM, tool, output), connection relationships, input / output parameters, and variable selectors; performing integrity and type consistency checks; and generating an intermediate semantic representation (IR), including node metadata, variable mappings, output format, and execution strategy. Variable selectors in the DSL are recorded as path arrays for direct conversion into expressions during subsequent generation.

[0061] S2, Semantic Normalization and Scope Unification: To ensure consistency between the generated state and the runtime state, the scope and path syntax of variables are unified: system variable sys. , conversation variable Memory variable. Environment variable env. The system also includes node output N{nodeId}_{var}; it standardizes template placeholders (supporting both {{...}} and {{#...#}} styles), converts selectors in the DSL into executable Python expressions, and provides natural representation and safe formatting for complex types such as booleans, null values, and objects / arrays.

[0062] S3, Node Template Binding and Code Snippet Generation: Binds standard Python function templates to node types to generate node execution skeletons; uses main(...) as the code entry point; automatically injects input parameters (constants / variables / system inputs), executes user logic or service calls, and maps the results to node outputs; uniformly inserts the minimum necessary trace record keys (N{nodeId}_trace_inputs and N{nodeId}_trace_outputs, recording the input parameters and output parameters after execution for each node) and error encapsulation to ensure auditability and replayability.

[0063] S4, Graph Compilation and State Type Construction: Compile graph structures (such as StateGraph) based on edge relationships, set entry points and execution order; automatically generate state types (such as TypedDict), including questions, answers, current nodes, errors, and output variables for each node; compile node functions and graph structures into executable workflow objects, ensuring topology consistency and type safety.

[0064] S5, runtime adaptation and unified execution protocol: unified result parsing (JSON / text), complex values ​​are serialized using natural text or JSON.

[0065] S6, Observation, Auditing and Replay: Node-level recording of input / output, latency and token increments, and disk trace logs; unified setting of answer fields and output formats; support for trace-based link replay and problem localization, meeting auditing and compliance requirements.

[0066] For example, a system for implementing the above-described DSL-based code generation method may include: 1. Input and Transformation: Receives JSON or DSL text from the front end, performs format conversion and basic validation, and outputs a unified workflow model, a fixed-structure object tree with complete fields, and a unified output appearance. The key field hierarchy of the unified model is as follows (consistent with DSL / YAML): version / kind / provider; app: name, code, id, mode, version, publishStatus…; sy_resources: llms, tools; workflow:; conversation_variables / memory_variables / environment_variables; graph:; nodes: [start node, LLM node, Agent node, output node…]; edges: [node connection relationships]; 2. Generation and Compilation: Renders Python node functions and graph structures based on the model, generates TypedDict state types, and compiles workflow instances; 3. Run Adaptation and Execution: Executes node code, with timeout and error rollback; 4. Observation and Logging: Node-level trace and token statistics, unified log archiving, and support for auditing and replay.

[0067] The above-mentioned technical means ensure semantic consistency throughout the entire chain of "orchestration → generation → compilation → execution → playback", and ensure stable and controllable behavior in a dual runtime environment, forming versionable, reproducible, and auditable Python code products that meet the requirements of project implementation and compliance.

[0068] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0069] According to another aspect of the present invention, an apparatus for implementing the above-described DSL-based code generation is also provided, such as... Figure 4 As shown, the device includes: an acquisition unit 402, used to acquire a workflow description defined according to a domain-specific language and user requirements; a parsing unit 404, used to perform structured parsing on the workflow description to obtain a structured data set, which includes multiple nodes, the node type corresponding to each node, and the connection relationships between the multiple nodes; a generation unit 406, used to generate a code skeleton based on the multiple nodes and the multiple node types, and to construct a node graph structure based on the connection relationships; and a compilation unit 408, used to compile the code skeleton and the graph structure to obtain an executable code file.

[0070] The specific methods of execution of each unit in the above device embodiments have been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0071] According to another aspect of the present invention, an electronic device for implementing a DSL-based code generation method is also provided, the electronic device being as follows: Figure 5 The terminal device or server shown. This embodiment uses this electronic device as an example for illustration. Figure 5 As shown, the electronic device includes: at least one processor 504; and a memory 502 communicatively connected to the at least one processor 504; wherein the memory 502 stores a computer program executable by the at least one processor 504, the computer program being executed by the at least one processor 504 to cause the at least one processor 504 to perform the steps in any of the above method embodiments. The electronic device may be located in at least one of a plurality of network devices in a computer network. The processor may be configured to execute a DSL-based code generation method via a computer program.

[0072] Alternatively, as those skilled in the art will understand, Figure 5 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic devices.

[0073] The memory 502 can be used to store software programs and modules, such as the program instructions / modules corresponding to the DSL-based code generation method and apparatus in this embodiment of the invention. The processor 504 executes various functional applications and data processing by running the software programs and modules stored in the memory 502, thereby implementing the aforementioned DSL-based code generation method. As an example, such as... Figure 5 As shown, the memory 502 may include, but is not limited to, the acquisition unit 402, parsing unit 404, generation unit 406, and compilation unit 408 in the DSL-based code generation device. Furthermore, it may include, but is not limited to, other module units in the DSL-based code generation device, which will not be elaborated upon in this example.

[0074] Optionally, the aforementioned transmission device 506 is used to receive or send data via a network. Specific examples of the aforementioned network may include wired networks and wireless networks. It should be noted that the aforementioned electronic device also includes a display 508 and a connection bus 510.

[0075] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices, which can be centralized on a single computing device or distributed across a network of multiple computing devices. Thus, this application is not limited to any particular combination of hardware and software.

[0076] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A code generation method based on DSL, characterized in that, include: Obtain workflow descriptions defined according to domain-specific languages ​​and user requirements; The workflow description is parsed in a structured manner to obtain a structured data set, which includes multiple nodes, the node type corresponding to each node, and the connection relationships between the multiple nodes. A code skeleton is generated based on the multiple nodes and the multiple node types, and a node graph structure is constructed based on the connection relationships; The executable code file is obtained by compiling the code skeleton and the graph structure.

2. The method according to claim 1, characterized in that, Generate a code skeleton based on multiple nodes and multiple node types, including: A node sequence list is generated using a graph algorithm based on the multiple nodes and the connection relationships; The workflow description is parsed to obtain the node parameters corresponding to each node; Based on the multiple nodes, a global variable table and a node local variable table are constructed using a variable selector; A global code skeleton is generated based on the global variable table, multiple node parameters, and the node sequence table. A local code skeleton corresponding to each node is generated based on the node order list, multiple node types, multiple node parameters, and the node local variable table. The code skeleton includes a global code skeleton and multiple local code skeletons.

3. The method according to claim 2, characterized in that, Based on the multiple nodes, a global variable table and a node-local variable table are constructed using a variable selector, including: Obtain the application scenario corresponding to the workflow description, and obtain the predefined rules corresponding to the application scenario based on the application scenario; Construct multiple variable selectors corresponding to each node based on the predefined rules and the multiple nodes; The workflow description is parsed based on multiple nodes to obtain multiple node variables corresponding to each node; Construct a global variable table and a node local variable table based on the multiple node variables, the multiple variable selectors, and the multiple nodes.

4. The method according to claim 3, characterized in that, Construct a global variable table and a node local variable table based on multiple node variables, multiple variable selectors, and multiple nodes, including: Obtain the variable scope corresponding to each node variable, and determine the variable type corresponding to each node variable based on the variable scope; Obtain the variable priority corresponding to each of the variable types; A global variable table and a node local variable table are constructed based on the multiple nodes, the multiple variable priorities, and the variable type corresponding to each node variable.

5. The method according to claim 4, characterized in that, A global variable table and a node local variable table are constructed based on multiple nodes, multiple variable priorities, and the variable type corresponding to each node variable, including: Based on the variable type and variable priority corresponding to each node variable, the multiple node variables are divided into multiple global node variables and multiple local node variables. Construct a first variable table and a second variable table according to preset table building rules, and obtain the variable metadata corresponding to each node variable; Based on the multiple nodes, the multiple variable metadata, and the multiple global node variables, the first variable table is mapped to node variables to obtain the global variable table; The second variable table is mapped to node variables based on the multiple nodes, the multiple variable metadata, and the multiple local node variables to obtain the node local variable table.

6. The method according to claim 2, characterized in that, A global code skeleton is generated based on the global variable table, multiple node parameters, and the node sequence list, including: The global variable table is parsed to obtain the global variable metadata corresponding to each of the multiple global node variables; Obtain a preset code generation type, and input the preset code generation type, multiple global node variables, and multiple global variable metadata into the global skeleton generation model, and output the global code skeleton.

7. The method according to claim 6, characterized in that, Based on the node order list, multiple node types, multiple node parameters, and the node local variable table, a local code skeleton corresponding to each node is generated, including: The local variable table of the nodes is parsed to obtain the local variable metadata corresponding to each of the multiple local variables of the nodes; The preset code generation type, the node order list, multiple node types, multiple node parameters, and multiple local variable metadata are input into the local skeleton generation model, and the local code skeleton corresponding to the node order list is output. The local code skeleton includes multiple sub-code skeletons corresponding to each node type.

8. The method according to claim 7, characterized in that, The local skeleton generation model is input with the preset code generation type, the node order list, multiple node types, multiple node parameters, and multiple local variable metadata. The model outputs the local code skeleton corresponding to the node order list, including: A node order skeleton is generated based on the preset code generation type, the node order list, and multiple node types. The node order skeleton is used to indicate the execution order of the sub-code skeleton. Generate the sub-code skeleton corresponding to each node type based on multiple node types, multiple node parameters, and multiple local variable metadata; The sub-code skeleton corresponding to each node type is mapped to the node sequence skeleton to obtain the local code skeleton.

9. The method according to claim 8, characterized in that, Compiling the code based on the code skeleton and the graph structure yields an executable code file, including: The global code skeleton and the local code skeleton are fused together to obtain the reference code; The execution order of the entry point and the multiple nodes is determined based on the graph structure. The reference code is compiled into an executable workflow object based on the entry point and the execution order. The workflow object is exported according to a preset file format to obtain the executable code file.

10. A code generation device based on DSL, characterized in that, include: The acquisition unit is used to acquire workflow descriptions defined according to domain-specific languages ​​and user requirements. The parsing unit is used to perform structured parsing on the workflow description to obtain a structured data set, which includes multiple nodes, the node type corresponding to each node, and the connection relationships between the multiple nodes. A generation unit is used to generate a code skeleton based on the plurality of nodes and the plurality of node types, and to construct a node graph structure based on the connection relationships; The compilation unit is used to compile the code skeleton and the graph structure to obtain an executable code file.

Images