Workflow generation methods, devices, electronic equipment, and storage media

Abstract

This application discloses a workflow generation method, apparatus, electronic device, and storage medium, relating to the field of computer technology, particularly to artificial intelligence fields such as deep learning, large models, and intelligent agents. The specific implementation scheme is as follows: Obtaining user input of natural language business requirements related to the target business; performing task planning on the natural language business requirements to generate a task logical structure; wherein the task logical structure is used to represent the dependencies between subtasks; performing front-end component matching on the task logical structure to generate structured configuration information; wherein the structured configuration information is used to indicate the component binding information corresponding to the subtasks; and generating the target workflow for the target business based on the task logical structure and the structured configuration information.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to the fields of artificial intelligence such as deep learning, large models, and intelligent agents, specifically to a workflow generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] Workflow is a solution for automating business processes by coordinating multiple operations sequentially to achieve a specific goal. Through workflows, enterprises can significantly improve business response speed, reduce manual intervention, enhance process consistency and traceability, and achieve efficient integration across tools and platforms, thereby lowering the development and maintenance barriers of automated systems while ensuring reliability. Summary of the Invention

[0003] This application provides a workflow generation method, apparatus, electronic device, and storage medium. The application first performs task planning based on natural language business requirements, generates a task logic structure representing the dependencies between subtasks, and then performs front-end component matching to generate structured configuration information, thereby constructing the target workflow.

[0004] The specific plan is as follows:

[0005] According to one aspect of this application, a workflow generation method is provided, comprising: Obtain natural language business requirements related to the target business from user input; Task planning is performed on natural language business requirements to generate a task logic structure; the task logic structure is used to represent the dependencies between subtasks. The task logic structure is matched with front-end components to generate structured configuration information; the structured configuration information is used to indicate the component binding information corresponding to the subtask. Based on the task logic structure and structured configuration information, the target workflow for the target business is generated.

[0006] According to another aspect of this application, a workflow generation apparatus is provided, comprising: The acquisition module is used to acquire natural language business requirements related to the target business from user input. The first generation module is used to plan tasks based on natural language business requirements and generate task logical structures; the task logical structures are used to represent the dependencies between subtasks. The second generation module is used to match the front-end components of the task logic structure and generate structured configuration information; the structured configuration information is used to indicate the component binding information corresponding to the subtask. The third generation module is used to generate the target workflow for the target business based on the task logic structure and structured configuration information.

[0007] According to another aspect of this application, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in the above embodiments.

[0008] According to another aspect of this application, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause the computer to perform the method described in the above embodiments.

[0009] According to another aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the above embodiments.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein: Figure 1 A flowchart illustrating a workflow generation method provided in an embodiment of this application; Figure 2 A schematic diagram of a demand dialogue interface provided in an embodiment of this application; Figure 3 A flowchart illustrating a workflow generation method provided in another embodiment of this application; Figure 4 A flowchart illustrating a workflow generation method provided in another embodiment of this application; Figure 5 A flowchart illustrating a workflow generation method provided in another embodiment of this application; Figure 6 A flowchart illustrating a workflow generation method provided in another embodiment of this application; Figure 7 A schematic diagram of a process node provided for another embodiment of this application; Figure 8 This is a schematic diagram of a workflow generation process provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a workflow generation apparatus provided in an embodiment of this application; Figure 10 This is a block diagram of an electronic device used to implement the workflow generation method of the embodiments of this application. Detailed Implementation

[0012] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] It should be noted that the acquisition, storage, use, and processing of data in this application comply with the relevant provisions of national laws and regulations and do not violate public order and good morals.

[0014] The workflow generation method, apparatus, electronic device, and storage medium of this application are described below with reference to the accompanying drawings.

[0015] Figure 1 This is a flowchart illustrating a workflow generation method provided in an embodiment of this application.

[0016] The workflow generation method of this application embodiment can be executed by the workflow generation device of this application embodiment, which can be configured in an electronic device.

[0017] Among them, electronic devices can be any device with computing capabilities, such as personal computers, mobile terminals, servers, etc. Mobile terminals can be hardware devices with various operating systems, touch screens and / or displays, such as in-vehicle devices, mobile phones, tablets, personal digital assistants, wearable devices, etc.

[0018] like Figure 1 As shown, the workflow generation method includes: Step 101: Obtain the natural language business requirements related to the target business as input by the user.

[0019] In this application, the target business can be a business task to be completed by an intelligent agent or application, such as "medical Q&A" or "price monitoring and early warning".

[0020] In this application, natural language business requirements refer to the user's requirements for the workflow of generating the target business, described in natural language.

[0021] For example, the workflow requirements for generating a medical question-answering agent can be described using natural language. Similarly, the workflow requirements for generating an application can be described using natural language. For instance, the natural language business requirement is "Help me create an application that grabs the price of product A every morning at 8 AM and sends an email alert if the price drops by more than 5%." Grabbing the price and issuing alerts every day is the business objective of this application.

[0022] It should be noted that the same "target business" (such as price monitoring) can be implemented in different forms, such as a standalone application, an intelligent agent, or an automated process on a low-code platform. Therefore, "target business" can be understood as an abstract task objective.

[0023] For example, the target platform provides an intelligent agent orchestration and execution workbench. Users can input natural language business requirements related to the target business in the requirement dialogue interface of the workbench and trigger corresponding controls, so that the target platform can obtain the natural language business requirements related to the target business input by the user.

[0024] For example, the target platform can refer to a platform with intelligent agent orchestration capabilities, such as a low-code platform.

[0025] As an example, users can directly input their business requirements in natural language within the requirements dialogue interface.

[0026] As another example, the dialog interface displays requirement configuration options, allowing users to select the appropriate options or enter or upload the corresponding requirement configurations as needed.

[0027] for example, Figure 2 This is a schematic diagram of a request dialogue interface provided in an embodiment of this application. Figure 2 The system provides several questions, such as "What problem does this agent primarily solve?", "Does the agent need to incorporate knowledge?", and "Is there a template for the response format?". For each question, multiple configuration options are provided for users to choose from, and users can also customize them as needed. When a user selects or enters the corresponding configuration requirements, a "Generate Configuration" control is triggered, allowing the target platform to obtain the user's natural language business requirements related to the business the agent needs to perform.

[0028] Step 102: Perform task planning for natural language business requirements and generate task logic structure.

[0029] In this application, a first planning agent can be used to plan tasks for natural language business requirements and generate a task logic structure that conforms to the target platform's DSL (Domain-Specific Language) specification.

[0030] The First Planning Agent is an AI-driven agent whose core function is to understand user needs and intelligently generate task logic structures. It relies on AI technologies such as natural language processing to identify and understand user needs, break them down into original tasks (or sub-tasks), and determine the dependencies between tasks to generate the task logic structure. The First Planning Agent can be integrated into existing development environments as a plugin or tool, directly providing the function of automatically generating task logic structures.

[0031] The task logical structure can be used to represent the dependencies between subtasks. For example, it can be represented using a DAG (Directed Acyclic Graph) or a relation matrix. For example, dependencies can include parallel relationships, serial relationships, etc. This task logical structure not only describes the logical dependencies between tasks but also conforms to the target platform's Domain-Specific Language (DSL) specifications, serving as the structural skeleton of the workflow execution engine.

[0032] For example, user requirements can be broken down into sub-tasks based on the DAG (Directed Acyclic Graph) generation algorithm in graph theory, and the dependencies between tasks can be identified through logical reasoning to generate the task logical structure.

[0033] For example, if a user's requirement is "notify me via app1 when the price of product A drops by more than 5%", this requirement can be broken down into subtask 1 "fetch the price of product A", subtask 2 "compare the current price with the historical price", and subtask 3 "send a notification to app1 if the price drop is >5%". The logical relationship between these three tasks is: subtask 2 depends on subtask 1, and subtask 3 depends on subtask 2. It can be seen that the task logic structure of these three tasks is: subtask 1 -> subtask 2 -> subtask 3.

[0034] Step 103: Match the front-end components of the task logic structure to generate structured configuration information.

[0035] A workflow front-end component refers to a visual unit within the workflow building interface of a target platform, allowing users to construct tasks (such as agent tasks) through drag-and-drop, configuration, connection, and orchestration. Essentially, it's a front-end abstraction of backend execution capabilities, input / output constraints, interaction parameters, and display formats, used to transform complex task flows into graphical configuration objects that are understandable, operable, and maintainable by users. A front-end component is not simply a UI control, but a unified carrier of "visual nodes + configuration panels + connection relationships + runtime feedback." On one hand, it supports the user's operational experience on the page; on the other hand, it needs to maintain consistency with the backend workflow engine, component center, parameter system, variable system, and permission system to achieve a closed loop from "interface orchestration" to "flow execution."

[0036] In related technologies, the generated workflows may seem logically sound from a business logic perspective, but they may contain component calls that cannot be actually executed, incorrect parameters, etc., resulting in poor technical feasibility. Therefore, this application employs a second planning agent to perform front-end component matching on subtasks within the task logic structure, determine the matching front-end components for each subtask, and generate structured configuration information based on the matched front-end components.

[0037] Understandably, since the task logic structure is a conceptual graph, the second planning agent can transform the concept into practical front-end components and the relationships between them. In other words, based on the task logic structure, the second planning agent maps the abstract subtask semantics to the underlying executable front-end components, thereby completing the subtasks through the front-end components.

[0038] Among them, the second planning agent is an intelligent agent driven by artificial intelligence. Its core function is to transform the task logic structure into code and map the interface relationships between various subtasks.

[0039] The structured configuration information can be used to indicate the component binding information corresponding to the subtask. For example, the component binding information can be used to specify the executable front-end components bound to the subtask, the input parameter mapping relationship, the output parameter definition, and other information.

[0040] For example, the structured configuration information may include component binding information corresponding to each subtask. The component binding information may include, but is not limited to, the component identifier (such as component ID, name, etc.) of the front-end component matched by the subtask, the mapping relationship between the subtask input parameters and the interface input parameters of the matched front-end component (such as input parameter mapping), the naming of the output parameters of the matched front-end component and the rules for passing the output parameters (used for downstream task reference in the workflow), etc.

[0041] In this embodiment, not only can front-end components be matched based on semantic similarity, but structured validation can also be performed based on the interface definition of the front-end components, such as input parameter types, output variable structure (i.e., output parameter structure), and data dependencies between upstream and downstream tasks.

[0042] Step 104: Based on the task logic structure and structured configuration information, generate the target workflow for the target business.

[0043] In this application, the logical topology in the task logic structure can be merged with the component binding information in the structured configuration information to generate a target workflow for the target business. For example, the target workflow is a visual flowchart composed of target front-end components matched with subtasks connected sequentially, used to automatically execute tasks to complete the target business. This target workflow can be displayed in the workflow building interface. For example, the target workflow can be a workflow directly generated based on the task logic structure and structured configuration information, or it can be validated using test cases. If it passes the test case validation, this workflow is used as the target workflow; there is no limitation on this.

[0044] For example, a target workflow can be generated based on the dependencies between subtasks and the component bindings and parameter configurations corresponding to each subtask.

[0045] Understandably, the target platform uses the task logic structure as the execution skeleton and the structured configuration information as the functional filler, automatically assembling it into a complete workflow.

[0046] For example, if the task logic structure is: Task 1 -> Task 2 -> Task 3, this dependency relationship can be integrated with the call parameters and output parameters of each front-end component, and the target workflow can be generated according to the DAG definition syntax of the target platform.

[0047] For example, the target workflow is an executable workflow. The target workflow can be a task flowchart that connects the process nodes with arrows to show the execution order. One subtask corresponds to one process node. Each process node can be represented by a front-end component corresponding to the subtask. The front-end component can be displayed in the form of cards.

[0048] For example, the cards corresponding to each process node in the workflow can also display input parameters, output parameter specifications, references, etc. The target workflow can be understood as a low-code concatenation diagram built based on the input and output of the API (Application Programming Interface). The workflow generation method of this application embodiment can be used to generate intelligent agent workflows, application workflows, or workflows for other business needs, and is not limited thereto.

[0049] Intelligent agent workflow (also known as intelligent agent process flow) refers to an intelligent task organization method that structures and decomposes task logic and arranges various intelligent capability components (such as large model capabilities, knowledge retrieval capabilities, tool invocation capabilities, and logic control capabilities) according to a certain execution order and dependencies, thereby forming an executable task flow. In an intelligent agent system, workflow not only describes the execution path of a task, but also defines the data transfer relationships between task nodes, condition control logic, exception handling mechanisms, and runtime scheduling rules, enabling complex problems to be completed collaboratively by multiple capability modules.

[0050] For example, the agent workflow can be executed in the workflow engine of the target platform to complete the agent's target business. For instance, by using the method of the embodiments of this application to generate a workflow for a medical question-answering agent, and executing the agent's workflow in the workflow engine, the agent can answer medical-related questions and complete the medical question-answering task. That is, the agent can directly use the workflow to answer medical-related questions.

[0051] For example, the workflow generation method of this application embodiment can be used in the following fields: (1) Low-code or no-code development platform: allowing business personnel to directly generate or adjust business process applications through natural language; (2) Intelligent workflow automation (intelligent agent orchestration): quickly building complex, cross-system automated processes for enterprises, such as RPA (Robotic Process Automation) + AI (Artificial Intelligence) processes; (3) Enterprise-level application building: automatically assembling data dashboards, customer service assistants, internal approval systems, etc. according to the requirements description; (4) AI intelligent agent development ecosystem: serving as the execution planning and assembly hub connecting large language models with specific tools and APIs.

[0052] It should be noted that these application areas are merely examples and can also be applied to workflow generation in other fields; this application does not limit them.

[0053] In this embodiment, a task logic structure is first generated by task planning based on natural language business requirements. Then, front-end component matching is performed to generate structured configuration information, thereby constructing the target workflow. Thus, by explicitly modeling task dependencies and structurally configuring the binding relationships between subtasks and front-end components, the generated workflow has a clear execution structure and parameter constraints, enabling direct execution within the target platform's workflow engine to complete the target business, thereby improving the stability and executability of the generated process.

[0054] Furthermore, by automatically transforming user-input natural language business requirements into a task logic structure representing subtask dependencies, and further matching it with underlying executable front-end components to generate structured configuration information containing component binding information, end-to-end automated mapping from fuzzy, unstructured intents to clear, deployable workflows is achieved. This not only ensures the logical rationality of task orchestration but also guarantees its technical feasibility. Consequently, it effectively bridges the semantic gap between high-level business language and the underlying execution engine, significantly improving the reliability and efficiency of the generated workflows. Moreover, it greatly reduces users' dependence on programming skills or underlying platform details, enabling business personnel without technical backgrounds to efficiently and reliably build complex automated processes, significantly lowering the technical threshold for workflow development.

[0055] Figure 3 This is a flowchart illustrating a workflow generation method provided in another embodiment of this application.

[0056] like Figure 3 As shown, the workflow generation method includes: Step 301: Obtain the natural language business requirements related to the target business as input by the user.

[0057] Step 302: Perform task planning for natural language business requirements and generate task logic structure.

[0058] In this application, steps 301-302 can be implemented in any of the embodiments of this application, so they will not be described in detail here.

[0059] Step 303: Match the task description information of the subtask with the front-end components in the component library to determine the target front-end component that matches the subtask.

[0060] In this application, the task description information of the subtask is matched with the interface definition and functional semantics of the front-end components in the component library to determine the target front-end component that matches the subtask.

[0061] For example, a code semantic understanding model is used in advance to vectorize the interface definitions and functional semantics of the front-end components in the component library to establish a vectorized index of the underlying component library. The task description information of the subtask can be vectorized to obtain the task description vector. Based on the similarity between the task description vector and the interface semantic vector of the front-end components in the component library, the target front-end component matching the subtask can be determined.

[0062] For example, the similarity between the task description information and the interface definition and functional semantics of the front-end components in the component library can be determined, and the front-end component with the highest similarity can be identified as the target front-end component that matches the subtask.

[0063] In some embodiments, if the front-end component of any subtask fails to match, component matching feedback information for any subtask is generated, and based on the component matching feedback information, the task is replanned for the natural language business requirements, the task logic structure is regenerated, and the front-end component matching is performed on the regenerated task logic structure until a match is successful, and the target front-end component that matches the subtask in the regenerated task logic structure is determined.

[0064] The component matching feedback information can be used to indicate that the subtask failed to match with the front-end components in the component library. For example, the component matching feedback information may include the component matching failure result, the reason why the task failed to match with each front-end component, etc.

[0065] For example, if any subtask fails to match or the confidence level is too low, structured component matching feedback information can be generated and sent to the first planning agent. The first planning agent combines the feedback information to re-plan the task for the natural language business requirements, regenerate the task logic structure, and perform front-end component matching on the regenerated task logic structure until each subtask has a matching target front-end component.

[0066] In this embodiment, when the front-end component fails to match, feedback information is generated, and the task is replanned based on the feedback information. Thus, by introducing a closed-loop replanning mechanism based on front-end component matching feedback, the execution breakpoints caused by front-end component mismatch can be actively identified and repaired during the task orchestration stage, thereby ensuring the logical correctness of the final generated task logic structure.

[0067] Step 304: Parameterize the subtasks and target front-end components to generate structured configuration information.

[0068] In this application, subtasks can be parameterized and bound to target front-end components to generate structured configuration information.

[0069] For example, subtasks can be parameter-bound to target front-end components to generate structured configuration information that includes the component identifier of the front-end component, input parameter mapping relationships, output parameter definitions, etc.

[0070] For example, based on the interface definition of the front-end component, input parameter mapping, output variable declaration (i.e., output parameter declaration), execution context configuration, etc., can be performed to generate structured configuration information.

[0071] For example, bind the subtask 'send SMS verification code' to the front-end component sms_sender_v3, map its input parameter phone_number to the task variable {{user.phone}}, and declare the output variable sent_status.

[0072] In some embodiments, in order to improve the feasibility of the task logic structure, the feasibility of the task logic structure can be verified based on the target front-end components matched by each subtask. If the verification is successful, the subtasks are then parameterized and bound to the corresponding target front-end components to generate structured configuration information.

[0073] For example, for any subtask, determine whether the input and output of the subtask match the output of the previous task and the input of the next task, respectively. If they match, then parameterize the subtask to the target front-end component.

[0074] For example, matching the input and output of a subtask with the output of the preceding task and the input of the following task means that the input of the subtask matches the output of the preceding task, and the output of the subtask matches the input of the following task. In other words, the output of the preceding task can be used as the input of the subtask, and the output of the subtask can be used as the input of the next task. Here, the input and output of a subtask can be understood as the input and output of the front-end component that matches the subtask.

[0075] Therefore, when the input and output of a subtask match the output of the previous task and the input of the next task, respectively, the subtask is parameterized and bound to the target front-end component. Through the front-end component interface and parameter-level validation mechanism, it can be ensured that the input and output of the subtask match the input and output of the previous and next tasks, making the data flow between the front-end component interfaces of the subtask feasible, thereby improving the feasibility of the task logic structure.

[0076] Step 305: Based on the task logic structure and structured configuration information, generate the target workflow for the target business.

[0077] In this application, step 305 can be implemented in any of the embodiments of this application, so it will not be described in detail here.

[0078] In some embodiments, if component matching fails and multiple candidate task logic structures are replanned, resulting in multiple candidate workflows, a collaborative reward model can be adopted. Based on the confidence level of each process node in the candidate workflow, the score of the candidate workflow can be determined, and the workflow with the highest score can be selected as the target workflow. Alternatively, multiple workflows with the highest scores can be selected as the target workflows and displayed to the user for selection.

[0079] In this embodiment, by explicitly matching the subtask description with the actual executable front-end components in the component library and parameterizing the binding according to the front-end component interface definition, the generation space is fundamentally constrained to the actual supported capabilities. The resulting structured configuration information not only semantically aligns with user intent but also has strong technical feasibility. It can effectively avoid logical breaks or running failures caused by model illusions, and significantly improve the reliability of automated process generation.

[0080] Figure 4 This is a flowchart illustrating a workflow generation method provided in another embodiment of this application.

[0081] like Figure 4 As shown, the workflow generation method includes: Step 401: Obtain the natural language business requirements related to the target business as input by the user.

[0082] In this application, step 401 can be implemented in any of the embodiments of this application, so it will not be described in detail here.

[0083] Step 402: Semantically enhance the natural language business requirements to generate structured requirements.

[0084] In this application, natural language business requirements can be clarified and completed to determine user intent. Based on the user intent, relevant knowledge can be retrieved from the knowledge base. Then, based on the natural language requirements and relevant knowledge, the natural language business requirements can be transformed into structured requirements.

[0085] For example, the knowledge base can store user requirements and workflow pairs, functional boundaries corresponding to the workflow, etc. The functional boundaries can refer to the conditions that each front-end component in the workflow needs to meet.

[0086] For example, relevant knowledge may include, but is not limited to, at least one of the following: relevant cases, constraints, etc. For example, relevant cases may refer to successfully implemented similar requirement-workflow pairs, serving as reference templates for generating the current requirement; constraints may refer to constraint information related to the generation of workflows in relevant cases, such as constraints related to outputs, etc.

[0087] For example, structured requirements can include target descriptions, input constraints, expected outputs, performance metrics, etc.

[0088] For example, the following method can be used to clarify and complete natural language business requirements and determine user intent: the natural language business requirements can be identified, the task type can be determined, and the target role matching the task type can be determined from the role library. Then, based on the target role's thought process, the natural language business requirements can be clarified and completed to determine user intent.

[0089] For example, based on the target role's thought process, ambiguous business requirements can be clarified or automatically completed in multiple rounds to ensure that the understanding aligns with the user's true intent.

[0090] For example, the task type can indicate to the user what kind of agent or workflow they want to build. For instance, the task type could be building an agent focused on answering medical questions.

[0091] For example, the role library may include intelligent agent roles for performing various types of tasks. For instance, the target role is "senior product manager".

[0092] For example, when the user triggers Figure 2 After the "Generate Configuration" control shown, the target platform can clarify and complete the natural language business requirements input by the user, obtain the aligned user intent, and retrieve relevant knowledge from the knowledge base based on the user intent. Based on the relevant knowledge, the natural language business requirements are transformed into structured requirements, and the generated structured requirements are displayed in the dialog interface.

[0093] Therefore, through the dual mechanism of role-based thinking chain guidance and domain knowledge constraint, vague and open natural language business requirements can be accurately transformed into executable intentions with clear structure, well-defined boundaries and in line with platform capabilities. This can effectively bridge the semantic barriers between natural language business requirements and large model executable logic, thereby eliminating ambiguity at the source, suppressing the illusion of a large model, and providing a high-fidelity and highly feasible semantic foundation for the subsequent generation of automated workflows.

[0094] In this embodiment, by clarifying and completing the natural language business requirements to accurately capture the user's true intent, and based on the aligned intent to drive knowledge base retrieval, the ambiguous requirements are deeply integrated with structured domain knowledge such as relevant cases and constraints, thereby achieving accurate completion and standardized expression of requirements, effectively eliminating generation deviations caused by semantic ambiguity or missing information, and significantly improving the accuracy and reliability of subsequent workflow generation.

[0095] Step 403: Perform task planning for structured requirements and generate a task logic structure.

[0096] In this application, a first planning agent can be used to decompose the structured requirements into multiple sub-tasks, determine the dependencies between the sub-tasks, and generate the task logic structure based on the dependencies.

[0097] For example, the target platform can display the generated structured requirements in the requirements dialogue interface for user confirmation. If the user confirms that there are no problems, the workflow construction control can be triggered. If the target platform detects that the control has been triggered, it can enter the process of generating a workflow based on the structured requirements.

[0098] Step 404: Match the front-end components of the task logic structure to generate structured configuration information.

[0099] Step 405: Based on the task logic structure and structured configuration information, generate the target workflow for the target business.

[0100] In this application, steps 404-405 can be implemented in any of the embodiments of this application, so they will not be described in detail here.

[0101] In this embodiment, by semantically enhancing natural language business requirements, they are transformed into structured requirements with complete elements and clear boundaries. Based on this, task planning can generate a logically rigorous and clearly defined task logic structure. This not only effectively eliminates the ambiguity, vagueness, and missing information in the original requirements, but also provides a high-fidelity and computable semantic foundation for subsequent front-end component matching and workflow construction. This significantly improves the accuracy and overall reliability of the transformation from unstructured natural language requirements to executable automated processes.

[0102] Figure 5 This is a flowchart illustrating a workflow generation method provided in another embodiment of this application.

[0103] like Figure 5 As shown, the workflow generation method includes: Step 501: Obtain the natural language business requirements related to the target business input by the user.

[0104] Step 502: Perform task planning for natural language business requirements and generate task logic structure.

[0105] Step 503: Match the front-end components of the task logic structure to generate structured configuration information.

[0106] In this application, steps 501-503 can be implemented in any of the embodiments of this application, so they will not be described in detail here.

[0107] Step 504: Based on the task logic structure and structured configuration information, generate the initial workflow for the target business.

[0108] In this application, the method for generating an initial workflow based on the task logical structure and structured configuration information can be found in the above embodiments. For example, the logical topology in the task logical structure can be merged with the component binding information in the structured configuration information to obtain the initial workflow.

[0109] For example, the initial workflow can be understood as the initial workflow generated based on the task logic structure and structured configuration information, that is, the directly generated workflow.

[0110] Step 505: Extract key variables from the test cases and map the key variables to the input parameters of the initial workflow to obtain a workflow instance.

[0111] To further ensure the feasibility of the generated workflow, this application allows for verification of the feasibility of the initial workflow through test instances.

[0112] In this application, test cases can be generated, key variables can be extracted from the test cases using named entity recognition, and these key variables can be mapped to the input parameters of the initial workflow to obtain workflow instances. This enables the automatic assembly of requirements into component parameters, directly providing structured input to the initial workflow and simulating a real-world operating environment.

[0113] For example, if the test case is "Patient has headache and nausea, age 65", the key variables can be extracted as: "symptom": "headache, nausea" and "age": 65. These values ​​can then be populated into the initial context variables of the initial workflow.

[0114] In some embodiments, if ambiguity arises during the mapping of key variables to input parameters of the initial workflow, a context-based disambiguation algorithm can be used to eliminate the ambiguity.

[0115] For example, the test case is "The patient has a fever and headache, and a body temperature of 39 degrees Celsius". We extract two entities related to "temperature", "fever" and "39 degrees". In the workflow, a front-end component needs to input the parameter fever_temperature. This input parameter is numerical. Through context analysis, we determine that "body temperature 39 degrees" clearly points to a numerical value. Therefore, we fill and map "39 degrees" to this input parameter, that is, fever_temperature=39.0.

[0116] Step 506: Execute the workflow instance and obtain the execution result.

[0117] In this application, after mapping key variables to the input parameters of the initial workflow, the front-end components bound to each process node can be called sequentially according to the execution order of each process node in the workflow instance, and the input, output, execution status, etc. of each process node can be recorded to obtain the execution result.

[0118] For example, the execution result may include the execution status of each process node (such as input, output, execution status, etc.) and the final output.

[0119] Step 507: In response to the determination that the workflow instance was successfully executed based on the execution result, the initial workflow is identified as the target workflow.

[0120] In this application, if the execution result determines that the workflow instance has completed all process nodes and the output conforms to the expected format and is not a fallback response, the workflow instance can be considered to have executed successfully, and the initial workflow can be identified as the target workflow.

[0121] For example, if any process node in the workflow instance is abnormal, outputs a default error message, or the inference is interrupted, the workflow instance can be considered to have failed to execute. The workflow is then regenerated and verified using test cases until the verification passes, thus obtaining the final workflow.

[0122] To improve the comprehensiveness and accuracy of workflow verification and ensure its effectiveness, in some embodiments, during the execution of a workflow instance, a consistency check can be performed on the workflow instance. If the workflow instance fails the consistency check, the workflow can be regenerated, and a test instance can be used to continue to verify the regenerated workflow until the verification is successful. The successfully verified workflow is then identified as the target workflow.

[0123] For example, consistency checks may include, but are not limited to, at least one of the following: interface type matching checks of process nodes in a workflow instance, data flow loop checks of a workflow instance, etc.

[0124] For example, the interface type matching validation is used to check whether the data type of the input data of the process node matches the data type of the input parameters of the target front-end component to which the process node is bound.

[0125] For example, interface type matching verification can be performed on each process node in the workflow instance. If the data type of the input data of any process node does not match the data type of the input parameters of the target front-end component, it means that the process node has failed the interface type matching verification. A candidate front-end component for that process node is then selected, and the data type of the input data of the process node is checked against the data type of the input parameters of the candidate front-end component. If they match, the candidate front-end component is used as the front-end component for that process node, and the interface type matching verification continues for the next process node. Selecting a candidate front-end component for a process node here can be considered as regenerating the workflow.

[0126] Therefore, providing alternative front-end components for process nodes and automatically switching to alternative front-end components when the target front-end component fails to be instantiated can improve the robustness of the workflow.

[0127] For example, data flow loop verification is used to check whether the data flow of a workflow instance forms a loop. For instance, if the data flow is task a->task b->task c->task a, it shows that the data flow of this workflow instance forms a loop, indicating that the data flow of the workflow instance is abnormal and has failed the consistency check.

[0128] For example, if the data flow of a workflow instance forms a loop, task planning and front-end component matching can be re-performed, the workflow can be regenerated, and test instances can be used to continue to verify the regenerated workflow until a successfully verified workflow is obtained, which is then used as the target workflow.

[0129] Optionally, a test instance can be used to continue validating the regenerated workflow. If the maximum duration or maximum number of iterations is reached without generating a valid workflow, a workflow generation failure message can be generated and returned. For example, this message may include not only the result of the failed generation but also the reason for the failure.

[0130] In this embodiment, by performing consistency checks such as interface type matching and data flow loop detection during the execution of workflow instances, defects caused by incompatible interfaces or logical dependency conflicts of front-end components can be proactively identified during the verification of the workflow using test cases. If the verification fails, the workflow is automatically regenerated and iteratively verified. The workflow is automatically instantiated and executed through test cases, forming a closed-loop optimization process of "generation-execution-verification-repair". This not only enables self-handling of exceptions and significantly reduces the cost of manual configuration and debugging, but also ensures that the final output target workflow has end-to-end technical feasibility and execution robustness at the semantic and data flow levels. Through the process-level testing and verification mechanism, reliability checks can be achieved before the workflow goes live.

[0131] In this embodiment, by extracting key variables from test cases and accurately mapping them to the input parameters of the initial workflow, the automatic assembly of requirement variables into runtime parameters of front-end components is realized. On this basis, the actual execution result of the workflow instance is used as the verification basis. When the execution is successful, the workflow is determined as the target workflow. This transforms the "static configuration" mode that relies on manual debugging into a "dynamically verifiable" closed-loop generation mechanism, which not only significantly reduces the debugging cost before deployment, but also improves the reliability of workflow generation.

[0132] Figure 6 This is a flowchart illustrating a workflow generation method provided in another embodiment of this application.

[0133] like Figure 6 As shown, the workflow generation method includes: Step 601: Obtain the natural language business requirements related to the target business as input by the user.

[0134] Step 602: Perform task planning for natural language business requirements and generate task logic structure.

[0135] Step 603: Perform front-end component matching on the task logic structure to generate structured configuration information.

[0136] Step 604: Generate the target workflow based on the task logic structure and structured configuration information.

[0137] In this application, steps 601-604 can be implemented in any of the embodiments of this application, so they will not be described in detail here.

[0138] Step 605: Render and display the target workflow.

[0139] In this application, the target platform can render and display the target workflow on the front end.

[0140] For example, the target workflow shown may include, but is not limited to, one or more of the following: process nodes corresponding to subtasks, connection relationships between process nodes, component parameter information of process nodes, etc.

[0141] The component parameter information refers to the parameter information of the target front-end component that matches the subtask. For example, the component parameter information may include the input parameter information (such as the input parameter name and the data type of the parameter), output parameter information (such as the output parameter name and the data type of the parameter), and parameter mapping of the target front-end component.

[0142] For example, it can display the process nodes in the target workflow, the connection relationships between process nodes, and the component parameter information of process nodes.

[0143] For example, if a user's natural language input request is "Help me create an application that grabs the price of product B every morning at 8 AM and sends an email alert if the price drops by more than 5%", when displaying the target workflow, you can show the connection relationship between each process node, and you can also highlight the parameter mapping of the condition judgment component (front-end component): mapping "price drop by more than 5%" to the threshold parameter of the condition judgment component.

[0144] Taking the workflow of generating a medical question-answering agent as an example, the workflow includes the following process nodes: step1_query rewriting, step2_medical literature retrieval, step3_classifier, step4_medical question-answering generation, step5_output, step6_large model node, step7_output, etc. In this process, step1 points to step2, step2 points to step3, step3 points to step4 and step7 respectively, step4 points to step5, and step6 points to step7.

[0145] Taking step 4, medical question and answer generation, as an example, this illustrates the process nodes in the demonstrated workflow. Figure 7The workflow node "step4_Medical Q&A Generation" (i.e., the front-end component) shown in card format includes the node name "step4_Medical Q&A Generation", the front-end component's inputs (including the names and data types of input parameters such as parameter 1, parameter 2, and parameter 3, and the output parameters of the corresponding preceding nodes), and the front-end component's outputs (including the names and data types of output parameters such as parameter 4 and parameter 5). Users can trigger dropdown control 701 to display the output parameters of all preceding nodes. When generating the workflow, the system can automatically match parameters with the same data type as the current workflow node, making it easy for users to modify and reference them.

[0146] Therefore, displaying the process nodes in the target workflow and the connections between them makes it easier for users to understand whether the process meets expectations. Displaying component parameter information improves the interpretability and credibility of the workflow, and also allows users to quickly verify the rationality and feasibility of the front-end components.

[0147] Step 606: In response to receiving the adjustment instruction for the user's target workflow, adjust the target workflow according to the adjustment instruction and obtain the adjusted workflow.

[0148] Since the generated workflow may not fully meet the user's expectations, in order to meet the user's personalized needs, this application can adjust the displayed target workflow based on the user's adjustment instructions so that the adjusted workflow meets the user's needs.

[0149] For example, adjustment instructions may include, but are not limited to, at least one of the following: natural language adjustment instructions, visual operation instructions, etc.

[0150] For example, a user can input natural language adjustment instructions in the requirements dialogue interface and trigger the corresponding instruction submission control. The target platform can then obtain the natural language adjustment instructions input by the user, parse the instructions using the aforementioned role matching and mind chain methods, and perform adjustments to the workflow.

[0151] This demonstrates that users can directly describe their intention to modify the target workflow using natural language. For example, a user's natural language modification instruction could be: "Change the 'email sending' node to 'WeChat Work notification' and shorten the notification content."

[0152] For example, users can drag and drop to modify the connection relationships between process nodes or modify the parameters of front-end components on the visual interface of the target workflow.

[0153] For example, if a user inputs a natural language request like "Help me create an application that grabs the price of product B every morning at 8 AM and sends an email alert if the price drops by more than 5%", the workflow is generated and displayed. This workflow shows the parameter mapping of the conditional judgment component: mapping "price drop by more than 5%" to the threshold parameter of the conditional judgment component. The user can change the threshold parameter of the conditional judgment component from "5%" to "4%" on the visual interface.

[0154] Optionally, the target workflow before adjustment can be compared with the workflow after adjustment to determine the differences between the workflow before and after adjustment, and a difference log can be generated to record the user's behavioral preferences and intentions.

[0155] Optionally, multiple optional workflows with subtle differences at key nodes can be proactively generated, allowing users to choose their preferred workflow, thereby capturing user intent more efficiently.

[0156] In some embodiments, the planning agent can be adjusted according to adjustment instructions to obtain an adjusted planning agent, which can then be used to generate workflows. The planning agent can refer to the agent used to generate the target workflow, such as the first and second planning agents in the embodiments described above.

[0157] For example, by combining feedback data from visual operation instructions and natural language instructions, the generation strategy of the planning agent can be dynamically adjusted through one or more methods such as prompt tuning, direct preference optimization, and contrastive learning algorithms. Here, feedback data can refer to the objects or content of workflow modifications.

[0158] For example, based on the adjustment instruction, combined with the target workflow and the adjusted workflow, a prompt word can be determined, and the planning agent can be adjusted according to the prompt word to obtain the adjusted planning agent.

[0159] For example, the planning agent can be adjusted based on the adjustment instructions, combined with the target workflow and the adjusted workflow, through direct preference optimization to obtain the adjusted planning agent.

[0160] For example, the adjusted workflow and the target workflow can be used as positive and negative sample pairs. Based on the adjustment instructions, the planning agent can be adjusted through comparative learning to obtain the adjusted planning agent.

[0161] Therefore, by adjusting the planning agent according to the adjustment instructions, it can learn not only from "how to modify" but also from "why to modify" (such as by parsing the intent of the adjustment instructions in natural language), thereby improving its understanding of the user's deep needs and business logic and achieving a higher level of evolution of the planning agent.

[0162] In this embodiment, by rendering and displaying the process nodes, connection relationships, component parameter information, etc. of the target workflow, users can intuitively verify whether its logical structure meets expectations, thus improving the interpretability of the workflow. On this basis, users are supported to flexibly adjust the workflow through multimodal interaction methods such as natural language commands and visual operations. The intuitive visual operations and flexible natural language adjustment commands are unified into understandable feedback signals, which can adapt to the interaction preferences of different users. This not only reduces the operation threshold for non-technical users, but also realizes the paradigm shift from "passively accepting generated results" to "actively participating in collaborative optimization". This ensures that the adjusted workflow more accurately matches the user's real business intentions, significantly improving the efficiency of human-machine collaboration and the usability of the final solution.

[0163] To facilitate understanding of the workflow generation method in this application's embodiments, the following uses the generation of an application workflow as an example, combined with... Figure 8 To explain, Figure 8 This is a schematic diagram of a workflow generation process provided in an embodiment of this application.

[0164] like Figure 8 As shown, the user inputs natural language business requirements related to the target business. These requirements undergo semantic enhancement to obtain structured requirements, which are then displayed for user confirmation. The user can confirm or fine-tune these requirements. Next, based on the structured requirements, hierarchical logical planning is performed to generate the target workflow for the target business. This hierarchical logical planning includes generating a task logic structure based on the structured requirements, matching the task logic structure with front-end components to obtain structured configuration information, and generating the target workflow based on the task logic structure and structured configuration information. This target workflow is then visually presented on the front end. Afterwards, the target workflow undergoes multimodal adjustments and feedback, which can be made through natural language commands, drag-and-drop editing, etc. If the user is satisfied with the workflow, they can confirm the execution of the final workflow. The target platform instantiates and deploys the final workflow and continuously collects user feedback during application operation.

[0165] The following examples illustrate this: (1) Natural Language Input Requirements and Collaborative Clarification User front-end operation: Users describe their business needs in everyday language in a unified input box (e.g., "Help me make an application that grabs the price of product A every morning at 8 o'clock and sends an email if the price drops by more than 5%").

[0166] Front-end appearance: A simple chat or command input interface.

[0167] Function: This interaction transforms vague requirements into a structured requirement that is agreed upon by both humans and machines, and presents it to the user for confirmation. It can solve the pain point of "misunderstanding of requirements" and move communication costs from "rework later" to "efficient collaborative clarification".

[0168] (2) Visualized target workflow User front-end operations: Users browse the automatically generated target workflow.

[0169] Front-end architecture: The workflow nodes (such as "timed trigger", "price retrieval", "price comparison", "conditional judgment", "email sending", "DingTalk notification") and their dependencies are displayed in the form of a directed acyclic graph (DAG). Each workflow node has been automatically "assembled" with the icons of the platform's front-end components (such as a certain crawler component, a certain calculation component, a certain email API component), and the mapping of key parameters is displayed in a highlighted manner (such as mapping "price reduction of more than 5%" to the threshold parameter of the conditional judgment component).

[0170] Purpose: This interaction addresses the pain points of "logic-technology disconnect" and "uninterpretable results." Demonstrating the workflow allows business users to understand whether the process meets expectations, and displaying the parameter mappings of front-end components enables users to quickly verify the rationality and feasibility of these components. This significantly improves the credibility and collaborative nature of the generated results.

[0171] (3) Multimodal, low-threshold optimization and correction User front-end operations: Users can optimize the automatically generated workflow in two ways.

[0172] Front-end form: Method a: Natural language command adjustment: Users can directly input their modification intention in the chat window (e.g., "Change email alerts to WeChat notifications and send me a summary report every Friday.").

[0173] Method b: Visual direct operation adjustment: Users can adjust the connection order of nodes in the workflow by dragging and dropping, or directly modify the parameter form of component nodes by clicking on them.

[0174] Functions: Natural language optimization: Suitable for business users who pursue efficiency and are not familiar with technology, making iteration as natural as a conversation; Visual optimization: Suitable for technical users who need fine control, providing precise operation control.

[0175] Both types of feedback can be recorded by the human-machine collaboration feedback layer to drive the evolution of workflow generation. It can not only learn "what the user changed", but also understand "why the user changed", realizing the evolution from "passive modification" to "active understanding", fundamentally solving the shortcomings of "static solidification".

[0176] (4) One-click publishing and continuous feedback User front-end operation: After the user confirms the final solution, they can click the "Publish" control or the "Deploy" control to publish or deploy the final solution.

[0177] After the application is running, users can provide continuous feedback during application use (such as marking a warning message as inaccurate).

[0178] Purpose: To simplify the deployment process and incorporate real-world usage feedback into the learning cycle, forming a complete closed loop from design, deployment to operation.

[0179] The workflow generation method of this application embodiment has the following beneficial effects: (1) Conversational zero-threshold development: Users describe their needs in natural language, and the system actively clarifies and generates solutions, expanding the user group from developers to business personnel; (2) Dual-agent guarantee of reliability: The "planning-verification" collaborative mechanism outputs and displays the workflow, which can solve the black box and illusion problems generated by AI and ensure professional credibility; (3) Closed-loop self-evolution system: learns from each drag and drop and natural language adjustment by the user, and becomes more and more in line with the user's needs the more it is used.

[0180] The workflow generation method of this application embodiment can be applied to intelligent agent scenarios. This workflow generation and execution method for large model intelligent agent scenarios, while retaining the ability to understand and plan large model tasks, introduces structured process abstraction, component-level interface constraint verification, engineering executability checks, and test-driven verification mechanisms, thereby improving the executability, stability, reusability, and verifiability of intelligent agent workflows.

[0181] To implement the above embodiments, this application also proposes a workflow generation device. Figure 9 This is a schematic diagram of the structure of a workflow generation device provided in an embodiment of this application.

[0182] like Figure 9 As shown, the workflow generation device 900 includes: The acquisition module 910 is used to acquire the natural language business requirements associated with the target business input by the user; The first generation module 920 is used to perform task planning for natural language business requirements and generate a task logical structure; wherein, the task logical structure is used to represent the dependency relationship between subtasks. The second generation module 930 is used to perform front-end component matching on the task logic structure and generate structured configuration information; wherein, the structured configuration information is used to indicate the component binding information corresponding to the subtask. The third generation module 940 is used to generate the target workflow of the target business based on the task logic structure and structured configuration information.

[0183] Optionally, the second generation module 930 is used for: The task description information of the subtask is matched with the front-end components in the component library to determine the target front-end component that matches the subtask. Parameterize the subtasks and target front-end components to generate structured configuration information; The component binding information includes at least one of the following: the component identifier of the target front-end component, the mapping relationship between the input parameters of the subtask and the interface input parameters of the target front-end component, and the naming and passing rules of the output parameters of the target front-end component.

[0184] Optionally, the second generation module 930 is used for: In response to a failure to match any front-end component in any subtask, generate component matching feedback information for that subtask. Based on the component matching feedback information, the task planning for natural language requirements is re-executed, and the task logic structure is regenerated. Perform front-end component matching on the regenerated task logic structure until a match is found, and determine the target front-end component that matches the subtask in the regenerated task logic structure.

[0185] Optionally, the second generation module 930 is used for: In response to the input and output of a subtask being matched with the output of the previous task and the input of the next task, the subtask is parameterized and bound to the target front-end component to generate structured configuration information.

[0186] Optionally, the first generation module 920 is used for: Semantic enhancement is applied to natural language business requirements to generate structured requirements; Perform task planning for structured requirements and generate a task logic structure.

[0187] Optionally, the first generation module 920 is used for: Clarify and complete the natural language business requirements to determine user intent; Based on the user's intent, a search is conducted in the knowledge base to determine relevant knowledge; among which, relevant knowledge includes at least one of the following: relevant cases, constraints; Based on natural language requirements and related knowledge, natural language business requirements are transformed into structured requirements.

[0188] Optionally, the first generation module 920 is used for: Identify natural language business requirements and determine task types; Identify target roles that match the task type from the role database; Based on the target user's thought process, clarify and complete the natural language business requirements to determine the user's intent.

[0189] Optionally, the third generation module 940 is used for: Based on the task logic structure and structured configuration information, the initial workflow of the target business is generated. Extract key variables from test cases and map them to the input parameters of the initial workflow to obtain workflow instances; Execute the workflow instance and obtain the execution result; In response to the determination that the workflow instance has been successfully executed based on the execution result, the initial workflow is identified as the target workflow.

[0190] Optionally, the device may further include: The verification module is used to perform consistency verification on the workflow instance during the execution of the workflow instance; wherein, the consistency verification includes at least one of the following: interface type matching verification of process nodes in the workflow instance, and data flow loop verification of the workflow instance; In response to a workflow instance failing the consistency check, the workflow is regenerated through the first generation module 920 and the second generation module 930. The third generation module 940 is used to continue to verify the regenerated workflow using test instances until the verification is successful, and the successfully verified workflow is determined as the target workflow.

[0191] Optionally, the device may further include: The display module is used to render and display the target workflow; wherein the target workflow includes at least one of the following: the process nodes corresponding to the subtasks, the connection relationships between the process nodes, and the component parameter information of the process nodes.

[0192] Optionally, the device may further include: The first adjustment module is used to respond to the user's adjustment instruction for the target workflow, adjust the target workflow according to the adjustment instruction, and obtain the adjusted workflow; The adjustment instructions include at least one of the following: natural language adjustment instructions and visual operation instructions.

[0193] Optionally, the device may further include: The second adjustment module is used to adjust the planning agent according to the adjustment instructions and obtain the adjusted planning agent; wherein, the planning agent refers to the agent used to generate the target workflow.

[0194] It should be noted that the explanation of the aforementioned workflow generation method embodiment also applies to the workflow generation device of this embodiment, and therefore will not be repeated here.

[0195] In this embodiment, a task logic structure is first generated by task planning based on natural language business requirements. Then, front-end component matching is performed to generate structured configuration information, thereby constructing the target workflow. Thus, by explicitly modeling task dependencies and structurally configuring the binding relationships between subtasks and front-end components, the generated workflow has a clear execution structure and parameter constraints, enabling direct execution within the target platform's workflow engine to complete the target business, thereby improving the stability and executability of the generated process.

[0196] Furthermore, by automatically transforming user-input natural language business requirements into a task logic structure representing subtask dependencies, and further matching it with underlying executable front-end components to generate structured configuration information containing component binding information, end-to-end automated mapping from fuzzy, unstructured intents to clear, deployable workflows is achieved. This not only ensures the logical rationality of task orchestration but also guarantees its technical feasibility. Consequently, it effectively bridges the semantic gap between high-level business language and the underlying execution engine, significantly improving the reliability and efficiency of the generated workflows. Moreover, it greatly reduces users' dependence on programming skills or underlying platform details, enabling business personnel without technical backgrounds to efficiently and reliably build complex automated processes, significantly lowering the technical threshold for workflow development.

[0197] According to embodiments of this application, this application also provides an electronic device, a readable storage medium, and a computer program product.

[0198] Figure 10 A schematic block diagram of an example electronic device 1000 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0199] like Figure 10As shown, device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 1002 or loaded from storage unit 1008 into RAM (Random Access Memory) 1003. RAM 1003 may also store various programs and data required for the operation of device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. I / O (Input / Output) interface 1005 is also connected to bus 1004.

[0200] Multiple components in device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of monitors, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0201] The computing unit 1001 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above, such as workflow generation methods. For example, in some embodiments, the workflow generation method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by the computing unit 1001, one or more steps of the workflow generation method described above may be performed. Alternatively, in other embodiments, the computing unit 1001 may be configured to perform a workflow generation method by any other suitable means (e.g., by means of firmware).

[0202] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0203] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0204] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0205] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0206] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0207] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0208] According to an embodiment of this application, this application also provides a computer program product that, when an instruction processor in the computer program product is executed, performs the workflow generation method proposed in the above embodiments of this application.

[0209] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0210] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A workflow generation method, comprising: Obtain natural language business requirements related to the target business from user input; Task planning is performed on the natural language business requirements to generate a task logic structure; wherein, the task logic structure is used to represent the dependencies between subtasks; The task logic structure is matched with front-end components to generate structured configuration information; wherein, the structured configuration information is used to indicate the component binding information corresponding to the subtask; Based on the task logic structure and the structured configuration information, the target workflow for the target business is generated.

2. The method as described in claim 1, wherein, The step of matching the front-end components of the task logic structure to generate structured configuration information includes: The task description information of the subtask is matched with the front-end components in the component library to determine the target front-end component that matches the subtask. The subtasks are parameterized and bound to the target front-end component to generate the structured configuration information; The component binding information includes at least one of the following: the component identifier of the target front-end component, the mapping relationship between the input parameters of the subtask and the interface input parameters of the target front-end component, the naming of the output parameters of the target front-end component, and the transmission rules of the output parameters.

3. The method as described in claim 2, wherein, The step of matching the task description information of the subtask with front-end components in the component library to determine the target front-end component that matches the subtask includes: In response to the failure of matching any front-end component in any subtask, component matching feedback information for that subtask is generated; Based on the component matching feedback information, the task planning for the natural language business requirements is re-executed, and the task logic structure is regenerated. Perform front-end component matching on the regenerated task logic structure until a match is found, and determine the target front-end component that matches the subtask in the regenerated task logic structure.

4. The method of claim 2, wherein, The parameterized binding of the subtask to the target front-end component to generate the structured configuration information includes: In response to the subtask's input and output matching the output of the previous task and the input of the next task, the subtask is parameterized and bound to the target front-end component to generate the structured configuration information.

5. The method of claim 1, wherein, The step of planning tasks and generating task logic structures for the natural language business requirements includes: Semantic enhancement is performed on the natural language business requirements to generate structured requirements; The structured requirements are used for task planning to generate the task logic structure.

6. The method of claim 5, wherein, The semantic enhancement of the natural language requirements to obtain structured requirements includes: Clarify and complete the natural language service requirements to determine the user's intent; Based on the user intent, a search is performed in the knowledge base to determine relevant knowledge; wherein, the relevant knowledge includes at least one of the following: relevant cases, constraints; Based on the natural language requirements and related knowledge, the natural language business requirements are transformed into the structured requirements.

7. The method of claim 6, wherein, The process of clarifying and completing the natural language service requirements to determine user intent includes: The natural language service requirements are identified to determine the task type; Determine the target role that matches the task type from the role library; Based on the target role's thought process, the natural language service requirements are clarified and completed to determine the user's intent.

8. The method of claim 1, wherein, The step of generating the target workflow for the target business based on the task logic structure and the structured configuration information includes: Based on the task logic structure and the structured configuration information, an initial workflow for the target business is generated; Extract key variables from test cases and map the key variables to the input parameters of the initial workflow to obtain workflow instances; Execute the workflow instance to obtain the execution result; In response to determining that the workflow instance has been successfully executed based on the execution result, the initial workflow is identified as the target workflow.

9. The method of claim 8, further comprising: During the execution of the workflow instance, a consistency check is performed on the workflow instance; wherein, the consistency check includes at least one of the following: interface type matching check of process nodes in the workflow instance, and data flow loop check of the workflow instance; In response to the workflow instance failing the consistency check, the workflow is regenerated; Using the aforementioned test instance, continue to verify the regenerated workflow until verification is successful. The successfully verified workflow is then identified as the target workflow.

10. The method of any one of claims 1-9, further comprising: The target workflow is rendered and displayed; wherein the target workflow includes at least one of the following: the process node corresponding to the subtask, the connection relationship between the process nodes, and the component parameter information of the process node.

11. The method of claim 10, further comprising: In response to receiving the user's adjustment instruction for the target workflow, the target workflow is adjusted according to the adjustment instruction, and the adjusted workflow is obtained; The adjustment instructions include at least one of the following: natural language adjustment instructions and visual operation instructions.

12. The method of claim 11, further comprising: According to the adjustment instruction, the planning agent is adjusted to obtain the adjusted planning agent; wherein, the planning agent refers to the agent used to generate the target workflow.

13. A workflow generation apparatus, comprising: The acquisition module is used to acquire natural language business requirements related to the target business from user input. The first generation module is used to perform task planning on the natural language business requirements and generate a task logical structure; wherein, the task logical structure is used to represent the dependency relationship between subtasks. The second generation module is used to perform front-end component matching on the task logic structure and generate structured configuration information; wherein, the structured configuration information is used to indicate the component binding information corresponding to the subtask; The third generation module is used to generate the target workflow of the target business based on the task logic structure and the structured configuration information.

14. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-12.

15. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-12.

16. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-12.

Images