Intelligent agent workflow rapid building method and system based on natural language understanding

Abstract

The application relates to the technical field of artificial intelligence and software engineering, and discloses an agent workflow rapid building method and system based on natural language understanding. The method first acquires target platform original metadata and converts the metadata into standardized platform capability data; receives user natural language input, analyzes the intention and entity by using a pre-training model and a hybrid extraction strategy, and performs real-time verification based on the standardized data; then, a general meta-model instance independent of the platform is generated by combining a structured prompt and driving a large language model; priority-based parameter completion and topological consistency verification are performed on the meta-model; finally, the meta-model is converted into a configuration file conforming to the target platform specification through an adapter and automatic deployment is completed. The application realizes automatic conversion from natural language to heterogeneous platform workflows through the general meta-model and the adapter mechanism, reduces the development threshold, and improves cross-platform compatibility and deployment efficiency.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and software engineering technology, specifically to a method and system for rapidly building intelligent agent workflows based on natural language understanding. Background Technology

[0002] With the rapid development of large language model technology, agent workflows have become a key bridge connecting large models with specific business scenarios. However, in current agent development and orchestration practices, the way workflows are constructed still faces many technical bottlenecks, which seriously restricts their popularization and application in non-technical fields.

[0003] Currently, mainstream workflow creation primarily relies on manually writing configuration files or programming code. This requires users to possess high technical skills, not only mastering specific data structure syntax rules such as JSON and YAML, but also having a deep understanding of complex workflow design patterns and API interface logic. For product managers or business personnel lacking a programming background, this high technical threshold makes it difficult for them to directly participate in workflow construction. Furthermore, different intelligent agent platforms typically define their own proprietary node type libraries and parameter specifications, resulting in significant learning costs for users when using new platforms. Even with code programming, while offering greater flexibility, the development complexity is high, the code logic is obscure and difficult to understand, and the lack of intuitive visual support poses significant challenges to subsequent maintenance and iteration.

[0004] To lower the barrier to entry, some platforms offer visual drag-and-drop configuration interfaces. However, while this interaction method is acceptable for handling simple linear logic, it becomes extremely cumbersome when dealing with complex workflows containing multiple branches, loops, or a large number of nodes. Furthermore, as the number of nodes increases, the canvas interface often becomes crowded and chaotic, with intricate connections, leading to low development efficiency and difficulty in maintenance.

[0005] More critically, existing workflow building tools generally lack a deep understanding of user intent and intelligent assistance capabilities. The system merely acts as a static configuration editor, unable to automatically generate corresponding logical structures through natural language or voice descriptions, and lacks intelligent parameter completion mechanisms. This results in errors generated during configuration (such as missing parameters or logical conflicts) often being delayed until the deployment stage or even runtime. This delayed error detection mechanism not only increases debugging costs but also severely impacts system stability.

[0006] Furthermore, due to the lack of unified industry standards, workflow definition formats vary significantly across different intelligent agent platforms, resulting in a severe platform lock-in effect. Workflows built by users on one platform cannot be seamlessly migrated to other environments. This lack of cross-platform compatibility forces any migration work to require reconfiguration and redevelopment, limiting business flexibility and scalability. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a method and system for rapidly building intelligent agent workflows based on natural language understanding. This solves the problems of high technical barriers, cumbersome and error-prone manual configuration, and poor compatibility due to platform heterogeneity in the existing cross-platform intelligent agent workflow construction process.

[0008] To achieve the above objectives, the present invention provides the following technical solution: The first aspect of the present invention provides a method for rapidly building an intelligent agent workflow based on natural language understanding. This method first establishes a standardized mapping mechanism for heterogeneous platform resources. The native resource metadata of the target intelligent agent platform selected by the user is obtained through the platform resource metadata layer module, and then converted into standardized platform capability data in a unified format for caching. The standardized platform capability data normalizes the node type definitions, tool function signatures, and parameter constraints of different platforms, providing a common verification benchmark for subsequent logic generation and achieving decoupling between upper-layer business logic and lower-layer platform implementation.

[0009] In the natural language processing stage, this method combines intent recognition with a hybrid extraction strategy. The natural language parsing layer receives user input, uses a pre-trained language model (such as BERT) to convert the text into feature vectors, and calculates the probability distribution of intent categories through a fully connected layer to determine the user's construction intent. Simultaneously, multi-dimensional entity extraction operations are performed in parallel: sequence labeling models are used to identify node names and tool identifiers; regular expressions are used for precise matching of display parameter assignments; and dependency parsing is used to parse the syntactic features of verb nodes and conjunctions to determine the topological relationships between nodes, such as serial, parallel, or conditional branching. Crucially, this step directly calls the cached standardized platform capability data for real-time validity verification during parsing, determining the existence of extracted tool identifiers and the completeness of required parameters. This prevents the downward propagation of invalid or misleading information at an early stage, generating highly confident preliminary structured information.

[0010] In the core structure transformation phase, this method introduces a structured transformation and general meta-model generation mechanism based on a large language model. The LLM interaction layer module receives preliminary structured information and constructs a three-part structured prompt by combining standardized platform capability data. This prompt text clarifies the schema format constraints of the task definition, injects serialized platform capability boundary descriptions, and fills in contextual intent data. The large language model generates an intermediate response based on this prompt, which the system parses into a platform-independent general meta-model instance. This process limits the generation scope of the large language model through strict prompt engineering, ensuring that the generated node types strictly fall within the set supported by the target platform. If the parsed result has missing parameters, the system generates follow-up prompts based on the missing parameter names through a multi-turn dialogue interaction mechanism until all required information is filled in.

[0011] To address potential logical oversights in the generated results of large language models, this method performs priority-based logical completion and consistency checks at the transformation layer. The system traverses general meta-model instances, automatically filling in unassigned parameters with final values ​​according to the priority order of "user-specified value, target platform default value, domain knowledge base recommended value, and system global default value," respecting user intent while ensuring configuration completeness. Simultaneously, the system performs rigorous graph theory checks, including topology consistency checks (verifying node existence and connectivity) and data reference checks (verifying the reverse topology sequence of variable references), ensuring that the generated workflow is logically an executable closed loop.

[0012] During the deployment phase, this method employs the adapter pattern for cross-platform deployment. The adapter layer module loads the corresponding adapter instance based on the target platform identifier, uses an internal mapping table to map nodes and parameters in the general metamodel to the target platform's unique identifiers and names, and resolves logical tool names into physical resource identifiers, ultimately generating a configuration file that conforms to the target specification. Furthermore, this method includes a secure serialization mechanism. Before generating the configuration file, it automatically scans and extracts sensitive field values ​​into encrypted memory, uses secure placeholders in the configuration file, and binds the actual values ​​to environment variables during deployment via a secure variable injection interface, effectively preventing the plaintext leakage of sensitive credentials.

[0013] A second aspect of the present invention provides a rapid construction system for intelligent agent workflow based on natural language understanding, which automates the above-mentioned process through modular design.

[0014] The system comprises a platform resource metadata layer module, a natural language parsing layer module, an LLM interaction layer module, a core transformation layer module, and an adapter layer module. The platform resource metadata layer module serves as the underlying support, connecting to the target intelligent agent platform and maintaining standardized platform capability data. The natural language parsing layer module acts as the input interface, responsible for accurate understanding of user intent and real-time compliance verification. The LLM interaction layer module, as the inference core, utilizes the generation capabilities of a large language model to construct intermediate structured data. The core transformation layer module, as the logic hub, is responsible for mapping structured data to rigorous general meta-model instances and performing logic completion and graph verification. The adapter layer module, as the execution terminal, is responsible for translating general meta-model instances into platform-specific configuration files and completing the final API deployment call. All modules communicate and connect through standardized data interfaces, collectively forming an end-to-end automated workflow construction pipeline.

[0015] This invention provides a method and system for rapidly building intelligent agent workflows based on natural language understanding. It offers the following advantages:

[0016] 1. This invention achieves automated generation of structured workflows from unstructured natural language text by working collaboratively with the natural language parsing layer module and the LLM interaction layer module, combined with pre-trained language models and standardized platform capability data. This construction method based on intent recognition and hybrid extraction eliminates the traditional cumbersome manual configuration of JSON / YAML or complex drag-and-drop operations, enabling non-technical personnel to quickly create intelligent agent workflows containing complex logic simply through natural language descriptions. This lowers the barrier to entry, improves development efficiency, and shortens the product iteration cycle.

[0017] 2. This invention establishes a multi-layered verification and completion mechanism, including entity legality verification based on standardized platform capability data in the parsing stage, automatic completion of logical parameters based on multi-source priority in the transformation stage, and topological consistency check at the graph theory level. Combined with the human-machine collaborative correction process supported by the visualization rendering engine, the system can comprehensively detect and correct missing parameters, incorrect data references, or logical silos before automated deployment, thereby effectively avoiding runtime failures caused by configuration errors and enhancing the stability and reliability of the intelligent agent workflow.

[0018] 3. This invention uses a platform-independent general meta-model instance as an intermediate representation, and utilizes the adapter layer module and resource mapping table to realize format conversion and dependency resolution for different target intelligent agent platforms. This decoupled architecture based on the intermediate meta-model and adapter factory breaks the closed limitation of a single platform, enabling the same set of workflow logic to flexibly adapt to multiple heterogeneous intelligent agent platforms by loading different adapter instances, thereby enhancing the cross-platform compatibility and scalability of the system. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the method flow of the present invention;

[0020] Figure 2 This is a schematic diagram of the system modules of the present invention. Detailed Implementation

[0021] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] See attached document Figure 2 This invention provides a rapid construction system for intelligent agent workflow based on natural language understanding. The system runs on a computing device equipped with a processor and memory, and its functions may include: an interaction layer module, a natural language parsing layer module, an LLM interaction layer module, a core transformation layer module, a general metamodel layer module, a platform resource metadata layer module, an adapter layer module, and a serialization layer module.

[0023] The interaction layer module in this system is configured to provide a user interface. This interface receives natural language input from the user and transmits it to the natural language parsing layer module. It also receives workflow data processed by other modules and presents it graphically. Furthermore, the interface allows users to modify the presented workflow using natural language commands or graphical operations.

[0024] The natural language parsing layer module in this system is configured to receive natural language input from the interaction layer module and perform structured parsing on that input. This module integrates an intent recognition unit, an entity and relation extraction unit, and a real-time verification unit. The intent recognition unit classifies the input text based on a pre-trained language model to determine the user's core task instructions. The entity and relation extraction unit uses named entity recognition technology and dependency parsing to extract workflow nodes, parameters, and logical relationships between nodes from the text. The real-time verification unit calls upon capability data obtained from the platform resource metadata layer module to perform instant verification of the extracted entities and relations. This module outputs the parsed and verified structured information to the LLM interaction layer module.

[0025] The LLM interaction layer module in this system is configured to receive structured information from the Natural Language Parsing layer module and communicate with an external Large Language Model (LLM) to generate a complete and formatted workflow definition. This module integrates a prompt engineering unit and a multi-turn dialogue management unit. The prompt engineering unit, based on a preset template, combines the task definition, format constraints, platform capability information (from the platform resource metadata layer module), and the user's structured information into a prompt sent to the Large Language Model. The multi-turn dialogue management unit, under the control of a state machine, analyzes the Large Language Model's return results. When missing information is detected, it generates follow-up questions, initiating a new round of interaction until all the information needed to build the workflow is obtained. This module ultimately outputs structured JSON data.

[0026] The core transformation layer module in this system is configured to receive JSON-formatted data output from the LLM interaction layer module and convert it into a platform-independent, general-purpose metamodel instance. This module integrates a structure mapping unit, a logic completion unit, and a consistency verification unit. The structure mapping unit maps each field in the JSON data to the data structure of the general-purpose metamodel. The logic completion unit is responsible for filling in parameters not specified by the user but necessary for workflow execution; the parameter values ​​are determined according to a preset priority decision rule.

[0027] Specifically, the final value of a parameter Determined by the following function:

[0028] ;

[0029] in, This represents the final value assigned to the parameter. COALESCE is a function that returns the first non-empty value in its list of input arguments. This represents the value that the user explicitly specifies for this parameter in the input. This represents the default value obtained from the platform resource metadata layer module, specific to the current target platform. This represents the recommended value obtained from a pre-built domain knowledge base, tailored to a specific business scenario. This represents the default value for the system's global configuration.

[0030] After mapping and completion, the consistency verification unit calls the logic rule engine in the general metamodel layer module to check the logical integrity and reference validity of the generated metamodel instance. This module ultimately outputs the verified general metamodel instance to the adapter layer module and the interaction layer module (for visual preview).

[0031] The general metamodel layer module in this system is a collection of data specifications and logical constraints used to define a platform-independent intermediate representation of workflows. This module defines the workflow's metadata, node arrays, edge arrays, and external dependencies data structures. Simultaneously, this module contains a logical rule engine that stores a series of rules to ensure the logical compliance of the workflow; for example, it ensures that conditional branch nodes must have two output edges corresponding to different conditions. This logical rule engine is invoked by the core transformation layer module.

[0032] The platform resource metadata layer module in this system is configured to acquire and manage the capability information of the target intelligent agent platform. This module communicates with the target platform through an interface provided by the adapter layer module to obtain its supported node types, tool list, parameter definitions for each tool, and platform-specific logical constraints. The acquired raw metadata is converted into a unified data format by a standardized processor and cached for querying by the natural language parsing layer module and the LLM interaction layer module.

[0033] The adapter layer module in this system is configured to convert generic metamodel instances into a format executable by a specific target platform and perform deployment operations. This module is designed using the factory pattern, instantiating the corresponding adapter based on the user-selected target platform identifier. Each adapter contains a format conversion engine that converts fields of the generic metamodel into fields of the platform's private configuration file according to preset mapping rules. The module also includes a dependency mapping unit for resolving logical resource names (such as tool names) in the metamodel into physical resource IDs within the platform. Finally, the module calls the target platform's API interface through its deployment execution unit to upload the converted configuration file.

[0034] The serialization layer module in this system is configured to persist general metamodel instances or platform-specific configurations generated by the adapter layer module into file formats (such as JSON or YAML). Before generating the file, this module starts a sensitive information filtering unit. This unit matches predefined field names (such as api_key, token) and replaces the corresponding sensitive data values ​​with secure placeholders. For example, it converts "api_key":"user_secret_key" to "api_key":"{{secret:api_key}}" to avoid storing sensitive information in plaintext in the configuration file.

[0035] See attached document Figure 1The first stage of the method in this embodiment is platform capability loading and user guidance. This stage is executed before the user engages in core interactions with the system. Its purpose is to enable the system to pre-acquire and understand the capability boundaries of the selected target intelligent agent platform, and to provide a data foundation for subsequent natural language parsing and user interaction. This stage specifically includes the following steps:

[0036] First, the system presents a list of selectable target intelligent agent platforms to the user through the interaction layer module. Upon receiving a user's instruction to select a specific platform, the system triggers the platform metadata retrieval process. This process is initiated by the platform resource metadata layer module, which sends a call request carrying the platform identifier to the adapter layer module.

[0037] Upon receiving a request, the adapter layer module instantiates a dedicated adapter corresponding to the target platform from its internal adapter registry, based on the platform identifier. The metadata acquirer component within this dedicated adapter is responsible for performing the actual data acquisition operation. One implementation involves the metadata acquirer sending an HTTP GET request to the target platform's pre-defined API endpoint (e.g., the / capabilities endpoint of a RESTful API). The target platform responds to the request, returning a structured data file containing descriptions of all its available capabilities, typically in JSON or XML format. Another implementation, if the target platform does not provide an API, involves the metadata acquirer reading a pre-configured capability definition file (e.g., platform_A_capabilities.yaml) associated with that platform from the local file system.

[0038] The platform's native metadata obtained in this step has a data structure defined by the target platform itself. For example, a set of native metadata in JSON format might contain a `tools` array, where each object represents an available tool. This object contains a `tool_id` (a unique identifier for the tool), a `description` (a functional description), and a `parameters` array. Each element in the `parameters` array defines a parameter, containing fields such as `param_name` (parameter name), `data_type` (data type, such as string, number, boolean), `is_required` (whether it is a required field), and `default_value` (default value).

[0039] Next, the standardization processor in the platform resource metadata layer module processes the acquired native metadata. This processor contains a set of predefined mapping rules used to convert heterogeneous metadata structures from different platforms into a unified, standardized metamodel format within the system. This process iterates through each capability item (such as a tool) in the native metadata and maps its fields to the standardized model. For example, the `tool_id` field in the native metadata is mapped to the `name` field in the standardized model, and the `is_required` field (a boolean value) is mapped to the `required` field. Through this process, tool capabilities from all platforms are transformed into a collection of objects with the same data structure and loaded into the system's cache manager.

[0040] Based on this standardized platform capability data, the system automatically generates validation rules for subsequent steps. Specifically, the system iterates through each standardized tool definition. If a tool's parameter is marked as `required: true`, the system generates a corresponding validation rule. This rule explicitly states that when the tool is used in the workflow, it is necessary to check if a corresponding parameter with a non-null value exists. These generated rules are stored for use by the real-time validation unit in the natural language parsing layer module in subsequent steps.

[0041] Finally, the platform resource metadata layer module sends the standardized platform capability data to the interaction layer module. Upon receiving this data, the interaction layer module dynamically updates its user interface. One concrete implementation involves a resource guidance sidebar on the interface displaying all available node types and tool names in a list or tree structure. When the user hovers their cursor over or clicks on a tool name, the interface further displays a detailed description of the tool, a list of all parameters, the data type of each parameter, and whether it is a required field. This provides users with clear guidance when entering natural language commands.

[0042] The second stage of this embodiment follows immediately after the first stage and is mainly completed collaboratively by the interaction layer module and the natural language parsing layer module. The task of this stage is to transform unstructured user input into structured intermediate data that can be processed by the computer, and to intercept non-compliant instructions in an early stage. This stage specifically includes the following steps:

[0043] The system initially enters a state of waiting for input. The interaction layer module receives a sequence of natural language text submitted by the user through an input device. This text sequence is defined as... Once input is received, the interaction layer module will immediately... It is sent to the intent recognition unit in the natural language parsing layer module.

[0044] The intent recognition unit performs a deep learning-based classification task. This unit first processes the text sequence... The text is segmented into words, with special markers (such as [cLs] and [sep]) added, and then converted into corresponding TokenID sequences. These sequences are fed into a pre-trained BERT (Bidirectional Encoder Representations from Transformers) encoder model. The encoder outputs a context-dependent feature vector representation of the input text, and the output vector corresponding to the [cLs] marker is taken as the feature vector for the entire sentence.

[0045] Subsequently, the feature vector is fed into a fully connected layer, where matrix multiplication maps the feature vector to the dimension space of the intent categories. The system then applies the Softmax activation function to calculate the probability distribution of the input text belonging to each predefined intent category (e.g., creating a new workflow, modifying node parameters, deleting a connection). The intent recognition unit selects the category with the highest probability value as the predicted intent. The system has a set confidence threshold. If the maximum probability value of the predicted intent is less than the threshold, the system determines that the intent is unclear and returns an instruction to ask the user to re-enter; if it is greater than or equal to the threshold, the intent is confirmed to be valid and the subsequent extraction process is triggered.

[0046] After confirming the intent, the entity and relation extraction unit extracts the text sequence. Parallel processing is performed, employing a hybrid strategy to extract workflow elements. The first strategy is Named Entity Recognition (NER) based on a sequence labeling model. This unit will... The input is fed into a fine-tuned sequence labeling model (such as a BiLSTM-CRF model or a Transformer-based NER model). The model predicts the label for each character or word in the text, identifying text segments belonging to predefined entity types. Predefined entity types include: NodeName, ToolID, ParamKey, and ParamValue.

[0047] The second strategy is rule matching based on regular expressions. This unit scans the text. It captures assignment statements in a specific format using a preset regular expression pattern.

[0048] The third strategy is relation extraction based on dependency parsing. This unit utilizes a parser to parse the text. The system constructs a dependency syntax tree based on the grammatical structure of the words. This tree structure describes the dominance and subdominance relationships between words. The system traverses this syntax tree, searching for specific verb nodes (such as connect, send, if) as core predicates, and analyzes their subject and object subtrees to determine the source and target nodes of the connections.

[0049] For logical relationships, the system makes judgments based on the syntactic features of the connectors: when sequential connectors (such as then, next) are identified, a serial connection relationship is established; when conditional connectors (if...otherwise...) are identified, a branch connection relationship with conditional attributes is established, marking the action of the clause introduced by if as the true branch and the action of the clause introduced by otherwise as the false branch; when parallel connectors (such as simultaneously, concurrently) are identified, multiple parallel edges originating from the same parent node are established.

[0050] After extracting the initial set of entities and relationships, the real-time verification unit immediately intervenes. This unit reads the standardized platform capability data that was loaded and cached in the platform resource metadata layer module during the first phase. The verification process includes the following two logical judgment steps:

[0051] The first step is validity verification. The real-time verification unit iterates through all extracted tool identifier entities. For each tool identifier, the unit searches for and matches it in the cached tool list. If a tool identifier does not exist in the cache list, the system determines that the instruction contains unsupported resources and generates a resource non-existent error code.

[0052] The second step is completeness verification. For tools that have been confirmed as legitimate, the real-time verification unit retrieves the parameter list defined in the tool's metadata and identifies all parameters marked as required (Required=True). The unit then checks whether the extracted parameter entity set contains the keys for these required parameters. If any required parameter is not extracted, the system determines that the instruction parameter is missing, generates a warning code for missing parameters, and lists the specific name of the missing parameter.

[0053] The real-time verification unit feeds back the verification results (including extracted structured data, error codes, or warning messages) to the interaction layer module. The interaction layer module updates the interface based on the feedback results: if the verification passes, the identified key information is highlighted on the interface; if there are errors or warnings, prompts are displayed in the corresponding text positions to guide the user to supplement or correct the input.

[0054] The third stage of the method in this embodiment is executed collaboratively by the LLM interaction layer module and the core transformation layer module. This stage transforms the preliminary structured information output from the second stage into a rigorous, complete, and platform-independent general meta-model instance, which is the core logical processing step for realizing automated workflow construction. This stage specifically includes the following steps:

[0055] The system first constructs a structured prompt to drive the Large Language Model (LLM). The prompt engineering unit receives intent categories, entity lists, and relational data from the Natural Language Parsing layer module, and combines this with platform capability definitions from the platform resource metadata layer module, assembling the prompt text according to a pre-defined three-part template. The first part defines the task role, explicitly indicating that the LLM's role is that of a workflow architect, and mandating that its output be in JSON format conforming to a specific schema definition, strictly prohibiting the inclusion of Markdown code blocks or other explanatory text. The second part injects capability boundaries and constraints, serializing all tool names, parameter lists, and parameter constraints (such as value ranges and required fields) supported by the current target platform into a text description injected into the prompt, explicitly instructing the model to only use tools present in the list, prohibiting the creation of non-existent node types. The third part is the context data input, filling the template with the user intent, entities (such as explicitly specified parameter values), and relational logic obtained from the second stage parsing, serving as the specific objects processed by the model.

[0056] After construction, the system sends the structured prompt to the Large Language Model (LLM) interface. The multi-turn dialogue management unit monitors the model's response process. Upon receiving the text response returned by the LLM, the system attempts to parse it into a JSON object. At this point, the system enters a state machine-based integrity check loop. The system compares the node parameters in the parsed JSON object with the required parameter rules in the platform's metadata. The system defines the missing set as: the set of parameters marked as required in the metadata, but whose corresponding fields are empty or nonexistent in the JSON object returned by the LLM.

[0057] If the missing set is not empty, the multi-turn dialogue management unit immediately freezes the current transformation process and automatically generates follow-up questions based on the elements in the missing set. These follow-up questions explicitly list the missing parameter names and require the LLM to infer or generate requests to obtain these values ​​from the context. The system sends the follow-up questions back to the LLM, proceeding to the next round of dialogue until the missing set becomes empty or a preset maximum dialogue round threshold is reached. If the threshold is reached and there are still missing parameters, the system marks this status as pending manual confirmation and retains the currently generated JSON structure.

[0058] Once the complete JSON structure is obtained, the core transformation layer module initiates the structure mapping procedure. This procedure first iterates through the `nodes` array in the JSON object, generating a globally unique identifier (UUID) for each node. Next, the procedure performs field mapping, copying the node type (`Type`) and parameter dictionary (`Parameters`) generated by the LLM into the corresponding data structure of the general metamodel. For the `edges` array in the JSON object, the procedure parses the `source` and `target` fields of each edge, replacing their values ​​with the corresponding node's UUID generated in the previous steps, thus establishing a defined topological connection. For logic containing conditional checks (e.g., if the weather is sunny), the procedure maps the conditional expressions generated by the LLM to the `condition` property of the metamodel edge object.

[0059] After the basic structure is established, the logic completion unit performs parameter filling operations on the metamodel instances. This operation targets parameters that are not mandatory but affect workflow operation (such as the temperature value or retries count of an LLM node). The logic completion unit executes a four-level priority judgment logic: First, it checks whether the user-specified parameter value exists in the general metamodel instance; if it exists, it is directly retained; if it does not exist, the system queries the platform resource metadata layer module to obtain the default configuration value of the parameter on the target platform and fills it in; if the platform does not define a default value, the system queries the built-in domain knowledge base to match the recommended parameter value under the current business scenario (such as email notification); if none of the above are found, the system fills in the system-level default value defined in the global configuration file. Each parameter that is automatically completed is marked with an auto_filled tag for differentiation and display in the subsequent visualization stage.

[0060] Finally, the consistency verification unit performs rigorous logical verification on the generated general metamodel instance. This verification includes topology consistency checks and data reference checks. The topology consistency check traverses all edge objects, verifying whether the UUIDs pointed to by their source and target actually exist in the node set, and checking for the existence of isolated nodes (i.e., non-starting / ending nodes without any incoming or outgoing edges). The data reference check analyzes the variable reference syntax in parameter values ​​(e.g., {{{NodeA.Output}}}}). The system verifies whether the referenced node NodeA is logically located on the preceding path of the current node by tracing back the topology. Only when the topology is complete and all data references are valid is the system marked as valid and output to the next stage.

[0061] The third stage of the method in this embodiment is executed collaboratively by the LLM interaction layer module and the core transformation layer module. This stage transforms the preliminary structured information output from the second stage into a rigorous, complete, and platform-independent general meta-model instance, which is the core logical processing step for realizing automated workflow construction. This stage specifically includes the following steps:

[0062] The system first executes the prompt building procedure. The prompt engineering unit reads the intent category output by the natural language parsing layer module. Entity set and relation set Simultaneously, this unit retrieves the set of capability descriptions for the current target platform from the platform resource metadata layer module. This collection contains definitions for all node types supported by the platform. and utility function signatures The prompting unit assembles the above data into input prompt text according to a preset three-segment structure. .

[0063] The first paragraph is the context constraint paragraph. The system will... and Serialize the string into a JSONSchema format and append it to the prompt text, explicitly specifying that the node type generated by the Large Language Model (LLM) must belong to... A subset of, and the tool call parameters must conform to Defined signature constraints. The system prompts for the addition instruction, prohibiting the generation of non-existent node types or fictitious parameters.

[0064] The second section is the task instruction section. The system inserts instruction text, requiring the LLM to infer the workflow topology based on user intent and entity information, and output the result as a specific JSON object containing nodes and edges fields.

[0065] The third section is the data injection section. The system will process the raw text input by the user. And the parsed and This is embedded at the end of the prompt as part of the data to be processed.

[0066] After the system is built, it will The data is sent to the large language model via the API interface. The multi-turn dialogue management unit receives the response text returned by the LLM. And attempt to convert it into a structured object using a JSON parser. During this process, the system performs state machine-based integrity checks. The system iterates through... For each node object in the array, obtain its corresponding tool type, and from... Find the set of required parameters for this tool in [the search bar]. The system checks the parameter dictionary of the node object. Calculate the set of missing parameters

[0067] ;

[0068] like If the message is not empty, the system determines that the current information is insufficient to construct an executable workflow. At this point, the multi-turn dialogue management unit pauses the transition process, based on... The element name in the code generates follow-up text, which is sent back to the LLM or directly to the interactive interface to obtain supplementary information. This process is repeated until... It is an empty set.

[0069] When the complete structured object is obtained Then, the core conversion layer module starts the mapping and completion process. First, the system... Each node in the system is assigned a globally unique identifier (UUID). Then, the system will... The mapping is performed as a generic metamodel instance. During the mapping process, the logical completion unit performs automatic filling for non-mandatory parameters. For any parameter... Its final value The determination follows the following priority logic:

[0070] FirstNonNull ;

[0071] in, From The user-specified value is directly extracted from the data. For the system to query The obtained parameter is the default value on the target platform (for example, the default temperature of an LLM node is 0.7). The system queries the built-in domain knowledge base to obtain specific scenario-specific recommended values ​​(for example, in a creative writing scenario, the recommended value for temperature is 0.9). This is a fallback default value from the system's global configuration table. The system checks each value in the above order and assigns the first non-empty value to the parameter. And record the source attribute of the value.

[0072] Finally, the system's consistency verification unit performs graph theory verification and reference verification on the generated general metamodel instance. In graph theory verification, the system constructs a directed graph representation of the workflow, traverses all edge objects, verifies whether the source (source node ID) and target (target node ID) of each edge exist in the node set, and checks for any unreachable isolated nodes. In reference verification, the system scans all variable reference expressions (such as {{NodeA.output}}) contained in all parameter values. The system performs a reverse topology search to verify whether the referenced node (such as Nodea) is a predecessor node of the current node in the topology. Only when the graph structure is complete and all variable references meet the topological temporal constraints is the system marked as valid and output to the next stage.

[0073] The fourth stage of the method in this embodiment is completed collaboratively by the interaction layer module and the core conversion layer module. This stage is executed after the general meta-model is generated but before formal deployment. Its technical goal is to provide an intermediate state verification and intervention mechanism to ensure that the machine-generated logic fully conforms to the user's true intent and corrects any potential inference biases. This stage specifically includes the following steps:

[0074] The system first launches the visualization rendering engine. This engine receives the general metamodel instance generated in the previous stage and reads its `nodes` and `edges` arrays. The engine uses a LayeredGraphDrawingAlgorithm to calculate the coordinates of each node on the two-dimensional plane, ensuring a clear left-to-right or top-to-bottom data flow and minimizing the number of intersections. The engine loads the corresponding graphical component template based on the node type field and binds the parameter data from the metamodel to the component's property panel. For parameters marked as `auto_filled` in the previous stage, the rendering engine renders specific visual identifiers (such as highlighted blocks or icons) next to the parameter's input box to indicate to the user that the value was inferred by the algorithm and requires careful confirmation.

[0075] For nodes or edges that fail the consistency check, the engine reads the error log, overlays the error status style on the corresponding graphical element, and displays the specific error code or description information.

[0076] Building upon the visualization, the system provides a natural language-based incremental correction mechanism. When a user inputs a natural language instruction to modify the current workflow (e.g., replacing an email sending node with an SMS notification) on the interactive interface, the interaction layer module captures the instruction and packages it together with the current general metamodel instance in memory. This data packet is then sent to the LLM interaction layer module. The prompting engineering unit constructs a new refinement prompt, which contains the serialized JSON structure text of the current metamodel, the user's modification instruction, and platform capability constraints. Based on this prompt, the large language model analyzes the incremental impact of the user instruction on the current structure and returns a difference data (Diff) containing only the changed parts or an updated complete JSON object. The core transformation layer module receives this returned data, performs a merge update operation on the metamodel instance in memory, modifies the corresponding node types, parameter values, or topological connections, and re-triggers consistency checks.

[0077] Meanwhile, the system provides a direct manipulation correction mechanism based on a graphical interface. The interaction layer module listens for user operation events on the visual canvas. When a user performs a reconnection operation (such as dragging the endpoint of an edge to another node), the system captures the event in real time, obtains the source node ID and target node ID of the newly connected node, and updates the source and target attributes of the corresponding element in the edges array of the metamodel instance. When a user clicks on a node and modifies the parameter value in the attribute panel, the system locates the corresponding node object in the nodes array of the metamodel, directly updates the key-value pairs in its parameters dictionary, clears the original auto_filled flag of the parameter (if it exists), and marks its status as user confirmation.

[0078] Upon completion of any correction operation (whether driven by natural language or graphical interface), the system immediately triggers the logical rule engine and consistency verification unit in the core transformation layer module. The logical rule engine rescans the updated metamodel instance and performs a full rule check. For example, if a user manually changes a serial connection to a parallel connection, the engine checks whether the parallel structure will cause data races or violate the concurrency limits of the target platform. If the verification passes, the system updates the status indicator on the interface to "ready"; if the verification finds new logical conflicts (such as loops or parameter type mismatches), the system prevents the submission of illegal states and provides real-time feedback on the new error location on the interface until the user completes all corrections and the metamodel satisfies all constraints.

[0079] The fifth stage of the method in this embodiment is executed collaboratively by the serialization layer module and the adapter layer module. This stage is responsible for transforming the general metamodel instance, which has been confirmed by the user and verified logically, into a dedicated configuration file that can be recognized by the target platform, and completing the final landing in the target environment through the network interface. This stage specifically includes the following steps:

[0080] The system first initiates a secure serialization process. The serialization layer module receives a generic metamodel instance in memory and, before generating the physical file, calls the sensitive information filtering unit to perform a scan. This unit traverses the parameter dictionary of all nodes in the metamodel, matching keys using a predefined list of regular expressions. The matching rules cover common sensitive field identifiers, including but not limited to api_key, secret_token, password, access_key, and private_key. When a match is found, the system extracts the plaintext value corresponding to the parameter and temporarily stores it in an encrypted temporary memory area, while simultaneously replacing the parameter value in the metamodel with a placeholder string of a specific format. This placeholder format is defined as {{{secRET:reference_id}}, where reference_id is the index key pointing to the encrypted data in the temporary storage area. This step ensures that the subsequently generated configuration file does not contain plaintext sensitive information.

[0081] After security processing is complete, the system enters the platform adaptation process. The adapter layer module retrieves and loads the corresponding adapter class from the adapter registry based on the target platform identifier selected by the user in the first phase. This adapter class internally maintains a format conversion engine specific to that platform. This engine performs mapping conversions in the following two dimensions:

[0082] The first dimension is the mapping between structure and fields. The transformation engine traverses the `nodes` array of the generic metamodel. For each node, the engine looks up the internal type mapping table, converting the generic node type (e.g., `type:llm_chat`) to a target platform-specific node type identifier (e.g., `type:completion-v2` defined on platform A or `kind:LLMNode` defined on platform B). Simultaneously, the engine maps generic parameter names to platform-specific parameter names (e.g., mapping `max_tokens` to `max_output_length`). If the parameter structure required by the target platform is inconsistent with the generic model (e.g., the target platform requires parameters to be nested within a `config` sub-object), the transformation engine reorganizes the JSON object hierarchy according to predefined structure transformation rules.

[0083] The second dimension is topology transformation. Because different platforms define workflow connections differently, the transformation engine reconstructs the connection data according to the target platform's specifications. If the target platform uses an independent edge list (EdgeList), the engine converts the edges array of the general metamodel into a list of edge objects conforming to the target platform's schema. If the target platform uses a nested definition (i.e., defining downstream node IDs within node objects), the engine iterates through the edge relationships of the general metamodel and writes the connection information into the next_steps or wires field of the source node.

[0084] Next, the adapter layer module performs dependency resource mapping operations. In the generic metamodel, external tools or plugins typically exist as logical names (e.g., weather$_tool). The adapter calls the resource mapping table cached in the platform resource metadata layer module to resolve these logical names to physical resource IDs in the target platform environment (e.g., plugin-7f8a9d2e-xxxxx). If a corresponding physical resource ID is not found in the mapping table, the system will automatically generate a resource registration request, attempt to dynamically register the tool on the target platform via API, and obtain the newly generated physical ID to fill in the configuration file.

[0085] Finally, the system performs deployment interactions. The deployment execution unit of the adapter layer module packages the converted platform-specific configuration file (usually in JSON or YAML format) with the extracted sensitive information credentials. The deployment execution unit establishes a connection with the open API of the self-defined intelligent agent platform via HTTPS protocol (e.g., calling the / api / v1 / workflows / import interface). This unit constructs an HTTP POST request, sends the configuration file as the payload, and injects the necessary authentication token into the request header. Simultaneously, for the previously replaced sensitive information placeholders, the deployment execution unit sends the temporarily stored sensitive data separately and binds it to the environment variables of this workflow through the security variable injection interface (SecretInjectionAPI) provided by the target platform.

[0086] The system synchronously awaits the API response from the target platform. Upon receiving a successful response with an HTTP status code of 200 or 201, the system parses the response body to obtain the instance ID and access link (Webhook URL) of the newly created workflow. The interaction layer module then updates the interface status, displays a notification of successful deployment to the user, and provides an entry point to directly jump to the target platform console or directly run the workflow. If an error response is received, the system parses the error code and rolls back the deployment operation.

Claims

1. A method for rapidly building intelligent agent workflows based on natural language understanding, characterized in that, Includes the following steps: S1: Obtain the native resource metadata of the target intelligent agent platform selected by the user, convert the native resource metadata into standardized platform capability data in a unified format and store it in the cache. The standardized platform capability data includes node type definitions, tool function signatures and parameter constraints. S2: Receive the user's natural language input, use a pre-trained language model and a hybrid extraction strategy to parse the intent, entities and logical relationships, and call the standardized platform capability data in the cache to perform legality verification on the parsed entities and generate preliminary structured information; S3: Receive the preliminary structured information, construct structured prompts by combining the standardized platform capability data, input the structured prompts into the large language model, and parse and convert the response returned by the large language model into a platform-independent general meta-model instance. The structured prompts are generated by the prompting engineering unit according to a preset template, combining task definition, format constraints, platform information capabilities, and user structured information. S4: Receive the general metamodel instance, perform priority-based logical parameter completion and consistency verification on the general metamodel instance, and generate a verified general metamodel instance; S5: Receive the verified general meta-model instance, convert the verified general meta-model instance into a configuration file that conforms to the target intelligent agent platform specification, and send the configuration file to the target intelligent agent platform through the API interface to complete automated deployment; In step S4, the step of performing consistency verification on the general metamodel instance specifically includes: Perform a topology consistency check by traversing all edges of the general metamodel instance, verifying that both the source node identifier and the target node identifier of the edge exist in the node set, and detecting whether there are any isolated nodes. Perform data reference checks, scan variable reference expressions in parameter values, and verify that the referenced node is located on the previous path of the current node in the topology through reverse topology search; After generating the validated general meta-model instance in step S4, and before performing the transformation in step S5, a human-machine collaborative correction step is also included: The validated general metamodel instance is read by the visualization rendering engine and rendered into a graphical workflow; In response to the natural language correction instruction input by the user, the large language model is invoked again based on the verified general meta-model instance and the correction instruction to obtain the difference data and update the general meta-model instance; In response to user operation events on the graphical interface, the topological connection relationships or parameter dictionary in the general metamodel instance are directly updated, and the consistency check is retried.

2. The method for rapid construction of intelligent agent workflow based on natural language understanding according to claim 1, characterized in that, In step S2, the steps of parsing intentions, entities, and logical relationships using a pre-trained language model and a hybrid extraction strategy specifically include: The natural language input is converted into a feature vector, and the probability distribution of the intent category is calculated through a fully connected layer to determine the predicted intent. The following extraction operations are performed in parallel: the node names and tool identifiers in the natural language input are identified using a sequence labeling model; the parameter assignment statements are displayed using regular expressions; and the verb nodes and conjunctions are parsed using dependency parsing, and the serial, parallel, or conditional branch connection relationships between nodes are determined based on the syntactic features of the conjunctions. The step of calling the standardized platform capability data to perform legality verification on the parsed entity specifically includes: determining whether the extracted tool identifier exists in the standardized platform capability data, and checking whether the parameters defined as required in the standardized platform capability data have been extracted.

3. The method for rapid construction of intelligent agent workflow based on natural language understanding according to claim 1, characterized in that, In step S3, the step of constructing structured prompts based on the standardized platform capability data specifically includes: Assemble the prompt text according to the preset three-segment template: The first section defines the task and format constraints, instructing the large language model to output JSON format data that conforms to the preset architecture definition. The second part is capability boundary injection, which serializes the standardized platform capability data into a text description and embeds it into the prompt text, limiting the node type generated by the large language model to belong to the set of the standardized platform capability data. The third section is the context data input, which fills in the preliminary structured information generated in S2.

4. The method for rapid construction of intelligent agent workflow based on natural language understanding according to claim 1, characterized in that, In step S3, the process of converting the response returned by the large language model into a platform-independent general meta-model instance also includes multi-turn dialogue interaction: Parse the JSON object returned by the large language model; The parameters in the JSON object are compared with the required parameter rules in the standardized platform capability data to calculate the set of missing parameters. If the set of missing parameters is not empty, a follow-up question is generated based on the name of the missing parameter, and the follow-up question is fed back to the large language model to obtain supplementary information until the set of missing parameters is empty, and then the conversion to the general meta-model instance is performed.

5. The method for rapid construction of intelligent agent workflow based on natural language understanding according to claim 1, characterized in that, In step S4, the step of performing priority-based logical parameter completion on the general metamodel instance specifically includes: Iterate through the node parameters in the general metamodel instance. For parameters that have not been assigned a value, check the values ​​from the following sources in sequence: the value explicitly specified by the user in the natural language input, the target platform default value obtained from the standardized platform capability data, the business scenario recommended value obtained from the pre-set domain knowledge base, and the general default value of the system's global configuration. The first non-empty value from the above sources is selected as the final value of the parameter, and an auto-completion flag is added to the parameters whose values ​​are obtained through non-user-specified means.

6. The method for rapid construction of intelligent agent workflow based on natural language understanding according to claim 1, characterized in that, In step S5, the step of converting the verified general meta-model instance into a configuration file conforming to the target intelligent agent platform specification specifically includes: Load the corresponding adapter instance based on the identifier of the target intelligent agent platform; The adapter instance is used to traverse the general metamodel instance, and the node type identifier and parameter name in the general metamodel instance are mapped to the identifier and name specific to the target intelligent agent platform using the internal mapping table. The adapter instance is used to query the resource mapping table to resolve the logical tool name in the general metamodel instance into a physical resource identifier in the target intelligent agent platform environment.

7. The method for rapid construction of intelligent agent workflow based on natural language understanding according to claim 1, characterized in that... S5 specifically includes a sensitive information processing step: Before generating the configuration file, the parameter dictionary of the general metamodel instance is scanned, and predefined sensitive field keywords are matched using regular expressions; The values ​​of the matched sensitive fields are extracted and temporarily stored in the encrypted memory area, while the values ​​are replaced with secure placeholders pointing to the temporary data in the configuration file. During automated deployment, the values ​​of the temporarily stored sensitive fields are bound to workflow environment variables through the security variable injection interface of the target intelligent agent platform.

8. A rapid workflow construction system for intelligent agents based on natural language understanding, characterized in that, The method for rapidly building an intelligent agent workflow based on natural language understanding, as described in any one of claims 1-7, includes: The platform resource metadata layer module is configured to connect to the target intelligent agent platform, obtain native resource metadata and convert it into standardized platform capability data, and send the standardized platform capability data to the natural language parsing layer module and the LLM interaction layer module. The natural language parsing layer module is configured to receive natural language input, parse it using a pre-trained language model to obtain preliminary structured information, and call the standardized platform capability data provided by the platform resource metadata layer module for verification during the parsing process, and send the verified preliminary structured information to the LLM interaction layer module. The LLM interaction layer module is configured to receive the preliminary structured information, combine it with the standardized platform capability data to construct a prompt-driven large language model to generate structured data, and send the structured data to the core conversion layer module. The core transformation layer module is configured to receive the structured data and map it into a general meta-model instance, perform parameter completion and consistency verification, and send the verified general meta-model instance to the adapter layer module. The adapter layer module is configured to receive the verified general meta-model instance, convert the verified general meta-model instance into a platform-specific configuration file, and call the interface of the target intelligent agent platform to perform deployment.

Images