Workflow generation method and device, electronic equipment and computer program product
By fine-tuning the workflow generation model using RPA business datasets and combining unsupervised and supervised learning, user input is automatically converted into structured workflow descriptions. This solves the problem of high complexity in RPA system construction, achieves low-threshold and easy-to-use workflow generation, and adapts to multimodal inputs and intelligent fault tolerance.
Patent Information
- Application Number
- CN202511696508.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-18
- Publication Date
- 2026-03-03
AI Technical Summary
Existing RPA systems have complex workflow construction and high technical barriers, requiring professionals to configure graphical interfaces or write scripts, which limits their popularity and application efficiency.
The workflow generation model, fine-tuned with RPA business datasets, automatically converts user input data into structured workflow descriptions through unsupervised and supervised learning strategies, and constructs executable workflows by matching target standardized components from a pre-set RPA component library.
It significantly reduces the technical threshold and configuration complexity of workflow construction, improves the accuracy and ease of use of workflow generation, adapts to business logic in different fields, supports multimodal input of natural language, interface operation and graphical orchestration, and achieves intelligent fault tolerance and adaptive adjustment.
Smart Images

Figure CN121597255A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of computer technology, and in particular relates to a workflow generation method, apparatus, electronic device and computer program product. Background Technology
[0002] Robotic Process Automation (RPA) technology, as an effective tool for improving business process efficiency, has been widely used in many fields.
[0003] In related technologies, existing RPA systems typically require professionals to manually configure workflows through a graphical interface or to automate tasks by writing scripts. However, this workflow construction method involves complex configuration processes and high technical barriers, requiring operators to have professional programming knowledge or undergo extensive training, which greatly limits the popularization and application efficiency of RPA technology.
[0004] Therefore, how to reduce the difficulty of building RPA workflows has become a technical problem that urgently needs to be solved in this field. Summary of the Invention
[0005] This application provides a workflow generation method, apparatus, electronic device, and computer program product, which can reduce the technical threshold and configuration complexity of workflow construction.
[0006] The first aspect of this application provides a workflow generation method, including: step S1: acquiring user input data; step S2: inputting the user input data into a preset workflow generation model, wherein the workflow generation model outputs structured workflow description information, and the workflow generation model is pre-tuned using an RPA business dataset; step S3: matching target standardized components from a preset RPA component library based on the structured workflow description information, and constructing an executable workflow based on the target standardized components.
[0007] In the technical solution of this application, by adopting a workflow generation model finely tuned by RPA business dataset, user input data is automatically converted into a structured workflow description and an executable workflow is built, thereby significantly reducing the technical threshold and configuration complexity of workflow construction.
[0008] Optionally, in one possible implementation of the first aspect, the method further includes, before step S2: constructing an initial model; obtaining multiple sets of training samples based on the RPA business dataset, wherein each set of training samples includes reference input data and corresponding reference workflow description information; dividing the multiple sets of training samples into a training dataset and a validation dataset; performing a first-stage training on the initial model based on the training dataset to enable the initial model to learn the functions of RPA components through unsupervised learning, thereby obtaining a first intermediate model; performing a second-stage training on the first intermediate model based on the training dataset to enable the first intermediate model to learn the mapping from reference input data to reference workflow description information through supervised learning, thereby obtaining a second intermediate model; validating the second intermediate model based on the validation dataset, and obtaining a workflow generation model after the second intermediate model passes validation. Thus, by adopting a two-stage training strategy that includes both unsupervised and supervised learning, the model first understands the functions of RPA components and then masters the process mapping capability, thereby improving the domain adaptability and process generation accuracy of the workflow generation model.
[0009] Optionally, in another possible implementation of the first aspect, the user input data includes natural language data, and step S2 includes: inputting the natural language data into a workflow generation model, the workflow generation model parsing at least one core operation element from the natural language data, wherein the core operation element includes at least one of triggering conditions, operation objects, and output formats; and generating structured workflow description information including RPA component identifiers, parameter configurations, and execution order based on the at least one core operation element. Thus, by parsing core operation elements from natural language data and generating a structured workflow description, intelligent conversion from natural language to an executable workflow is achieved, improving the system's usability.
[0010] Optionally, in another possible implementation of the first aspect, the user input data includes interface operation demonstration data. Step S2 includes: inputting the interface operation demonstration data into a workflow generation model; the workflow generation model extracting a sequence of user operation events on the graphical user interface from the interface operation demonstration data; parsing the operation event sequence to identify the user-interacting interface elements and their corresponding operation types; generating atomic operation sequences based on the identified interface elements and operation types; and mapping the atomic operation sequences to structured workflow description information, wherein the structured workflow description information includes the RPA component identifiers and execution parameters corresponding to the atomic operation sequences. Thus, by parsing the interface operation demonstration data into atomic operation sequences and mapping them to standard components, the "Artificial Intelligence (AI) learning" function is realized, significantly reducing the learning cost of workflow creation.
[0011] Optionally, in another possible implementation of the first aspect, the user input data includes graphical orchestration instruction data. Step S2 includes: inputting the graphical orchestration instruction data into the workflow generation model; the workflow generation model extracting drag-and-drop and connection operations performed by the user on multiple RPA components in the process canvas from the graphical orchestration instruction data; generating initial flowchart data containing component topology relationships and data flow directions based on the drag-and-drop and connection operations; and converting the initial flowchart data into structured workflow description information, wherein the structured workflow description information includes component execution order, parameter passing relationships, and branch logic. Thus, by converting graphical orchestration instructions into a structured description containing topology relationships and data flow directions, a precise conversion from low-code visual programming to an executable workflow is achieved.
[0012] Optionally, in another possible implementation of the first aspect, the method further includes, after step S3: running the executable workflow through the RPA execution engine, and detecting the execution status of the executable workflow during its execution; if the execution status of the executable workflow is detected to be abnormal, obtaining abnormal context information; inputting the abnormal context information into a preset abnormality handling model, which, in conjunction with a preset domain knowledge base, outputs correction instructions corresponding to the abnormal context information; and adjusting the execution parameters of the executable workflow according to the correction instructions corresponding to the abnormal context information. Thus, by generating correction instructions through an abnormality handling model combined with a domain knowledge base when an exception occurs, intelligent fault tolerance and adaptive adjustment of the workflow execution process are achieved.
[0013] Optionally, in another possible implementation of the first aspect, the method further includes, after step S3: obtaining execution feedback data of the executable workflow, wherein the execution feedback data includes execution logs and user ratings; when the amount of execution feedback data reaches a preset threshold, incrementally fine-tuning the workflow generation model based on the execution feedback data; and updating the component configuration information in the RPA component library based on the incrementally fine-tuned workflow generation model. Thus, by incrementally fine-tuning the model and updating the component library based on execution feedback data, the continuous optimization and self-learning capabilities of the workflow system are achieved.
[0014] Optionally, in another possible implementation of the first aspect, the method further includes, after step S3: simulating the execution workflow and detecting whether there are logical conflicts or parameter errors in the execution workflow; if logical conflicts or parameter errors are detected, generating error messages and returning them to the user interface; receiving correction instructions input by the user based on the error messages, and updating the execution workflow based on the correction instructions corresponding to the error messages. Thus, by simulating the execution workflow for detection and interactive correction, the reliability and deployment success rate of the workflow are improved.
[0015] Optionally, in another possible implementation of the first aspect, the method further includes: establishing a process template library, wherein the process template library stores pre-configured standard workflow templates; upon receiving an instruction from a user to select a target workflow template from the process template library, generating an executable workflow corresponding to the target workflow template based on the target workflow template. Thus, by establishing a process template library, users can directly call standard workflow templates, thereby improving the deployment efficiency and standardization of common workflows.
[0016] A second aspect of this application provides a workflow generation apparatus, comprising: at least one processor coupled to a memory storing a program or instructions, the processor executing the program or instructions such that the workflow generation apparatus performs the method as described in the first aspect above.
[0017] Specifically, the aforementioned workflow generation device may include the following modules: The data acquisition module is used to acquire user input data.
[0018] The model processing module is used to input user input data into a preset workflow generation model. The workflow generation model outputs structured workflow description information. The workflow generation model is pre-tuned using RPA business datasets.
[0019] The workflow building module is used to match target standardized components from a preset RPA component library based on structured workflow description information, and to build an executable workflow based on the target standardized components.
[0020] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method of the first aspect described above.
[0021] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of the first aspect described above.
[0022] A fifth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method described in the first aspect.
[0023] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description
[0024] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0025] Figure 1 This is a schematic diagram of the architecture of a workflow generation system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a workflow generation method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a workflow generation method provided in an embodiment of this application. Figure 4 This is a schematic diagram of the structure of a workflow generation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0027] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0028] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0029] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."
[0030] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0031] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0032] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.
[0033] In related technologies, existing RPA systems typically require professionals to manually configure workflows through a graphical interface or to automate tasks by writing scripts. However, this workflow construction method involves complex configuration processes and high technical barriers, requiring operators to have professional programming knowledge or undergo extensive training, which greatly limits the popularization and application efficiency of RPA technology.
[0034] In view of this, embodiments of this application provide a workflow generation method, apparatus, electronic device, and computer program product. First, user input data is acquired; then, the user input data is input into a preset workflow generation model, which outputs structured workflow description information. The workflow generation model is pre-tuned using an RPA business dataset. Finally, based on the structured workflow description information, a target standardized component is matched from a preset RPA component library, and an executable workflow is constructed based on the target standardized component. Thus, by employing a workflow generation model fine-tuned using an RPA business dataset, user input data is automatically converted into a structured workflow description and an executable workflow is constructed, significantly reducing the technical threshold and configuration complexity of workflow construction.
[0035] The following examples illustrate the application scenarios of the workflow generation method provided in this application. In the production and quality management processes of medical device companies, processes such as equipment calibration, production line quality inspection, and compliance document approval are not only highly repetitive but also require strict adherence to the medical device quality management system. Traditional automation solutions are complex to configure, lack flexibility, and are difficult to adapt to frequent process changes and stringent compliance audit requirements. With the solution of this application, users only need to describe "complete daily calibration of the spectrometer and generate a compliance report" in natural language, or demonstrate the calibration process through actual operation, and the system can automatically generate a reliable workflow that combines execution steps and compliance judgment logic. This not only significantly reduces the threshold and time for validating and deploying automated processes but also ensures that every step complies with medical device regulatory standards, effectively improving production quality and compliance efficiency.
[0036] To illustrate the technical solution of this application, specific embodiments are described below.
[0037] Figure 1 A schematic diagram of the architecture of a workflow generation system provided in an embodiment of this application is shown. Figure 1 As shown, the workflow generation system adopts a layered design, specifically including an interaction layer, a Large Language Model (LLM) layer, a process orchestration layer, an RPA execution layer, and a data and optimization layer. This architecture achieves loose coupling between modules through clear hierarchical boundaries and standardized data interfaces, thereby ensuring that each layer can evolve and upgrade independently while maintaining the overall collaborative operating efficiency of the system. The following sections provide a detailed explanation of each layer in the workflow generation system.
[0038] The top layer of the system is the interaction layer, responsible for receiving and processing multimodal input from users. Multimodal input specifically includes natural language (including text and speech), interface operation demonstrations (i.e., user demonstrations of operations on the actual software interface), and graphical orchestration instructions (i.e., user drag-and-drop and connection operations of components in the workflow canvas). This layer integrates a speech recognition interface and a multimodal understanding module. Its core function is to transform heterogeneous user input into standardized intent representations that the system can recognize, ultimately driving the generation of a unified workflow configuration interface to adapt to the operating habits of different user groups. For example, if a user verbally commands "Perform positive ion calibration" or demonstrates a calibration operation on the actual interface, the interaction layer can convert it into the standardized data format required for subsequent processing.
[0039] The standardized data processed by the interaction layer is then passed to the large language model layer. This layer employs a "base model plus domain fine-tuning" approach. Specifically, a general large language model is selected as the foundation, and then supervised fine-tuning is performed on it using a custom RPA business dataset. This RPA business dataset typically includes process manuals, historical task logs, component function descriptions, etc., with the aim of enabling the model to deeply understand the semantics of business processes and component usage specifications in a specific domain, thereby enhancing its ability to understand RPA tasks and the accuracy of process generation.
[0040] The output of the large language model layer is sent to the workflow orchestration layer for parsing and translation. The workflow orchestration layer integrates a rule engine and a task decomposition module. Its core responsibility is to break down high-level structured workflow descriptions into linear or branching sequences composed of a series of "atomic operations." An atomic operation is the smallest indivisible execution unit of a software automation task, such as "entering data into a specified input box," "clicking a button labeled 'Confirm'," or "extracting a specific value from the returned result." The workflow orchestration layer needs to accurately map each atomic operation to specific standardized components in the pre-defined RPA component library, determining the execution order and parameter passing relationships of each component.
[0041] The atomic operation sequence assembled by the process orchestration layer is driven by the RPA execution layer. The RPA execution layer, based on self-developed or integrated RPA tools, communicates with the upper layer through a model control protocol. The RPA execution layer receives specific atomic operation instructions, manipulates the target software's graphical user interface or application programming interface to complete the simulated operation, and monitors the execution results of each step in real time, feeding back the execution status (success, failure, or specific exception type) to the upper system.
[0042] The system's underlying layer is the data and optimization layer, responsible for providing data support for the continuous operation and self-improvement of the entire system. This layer utilizes a vector database to efficiently store and manage structured information such as process definitions and component metadata. Simultaneously, it persistently records detailed logs of each process execution. Furthermore, the data and optimization layer maintains a domain knowledge base, storing common business rules, solutions to typical problems, and other knowledge. All this data collectively forms the data foundation for incremental fine-tuning of the workflow generation model, optimizing and updating the component library, and intelligently diagnosing and recovering from execution anomalies, thereby achieving closed-loop optimization and adaptive improvement of system performance.
[0043] exist Figure 1 Based on the system architecture shown, Figure 2 The illustration shows a flowchart of a workflow generation method provided in an embodiment of this application. This method can be executed by an electronic device, which can be implemented in software and / or hardware, and can be implemented as a terminal or a server.
[0044] like Figure 2 As shown, the workflow generation method may include the following steps: S1, Obtain user input data.
[0045] User input data refers to the input information generated by users through various interaction methods provided by the system's interaction layer. Specifically, user input data can include natural language data, interface operation demonstrations, and graphical programming instructions. These input methods together constitute the system's multimodal interaction capabilities.
[0046] S2, input the user input data into the preset workflow generation model, and the workflow generation model outputs structured workflow description information.
[0047] The workflow generation model is pre-tuned using the RPA business dataset.
[0048] In this embodiment, the workflow generation model can be based on a general large language model and subjected to supervised fine-tuning using an RPA business dataset. The RPA business dataset can include domain-specific data such as process manuals, historical task logs, and component descriptions. Through this domain-adaptive training, the workflow generation model can understand the user's business intent and transform it into a machine-readable structured workflow description. This structured workflow description is a standardized data structure, whose core elements typically include triggering conditions, operation objects, and output formats, and can be further refined into specific RPA component identifiers, parameter configurations, and the execution order between components.
[0049] In one embodiment, because general-purpose large language models lack a deep understanding of the functions and combination logic of RPA components in specific business domains (such as calibration and quality inspection processes for medical devices), directly using such models to map natural language requirements into executable workflows results in significant deficiencies in accuracy and feasibility. Therefore, a domain-adaptive workflow generation model can be constructed as follows: An initial model is built; multiple training samples are obtained based on the RPA business dataset, each including reference input data and corresponding reference workflow description information; these training samples are divided into training and validation datasets; the initial model is trained in the first stage based on the training dataset to learn the functions of RPA components through unsupervised learning, resulting in a first intermediate model; the first intermediate model is trained in the second stage based on the training dataset to learn the mapping from reference input data to reference workflow description information through supervised learning, resulting in a second intermediate model; the second intermediate model is validated based on the validation dataset, and the workflow generation model is obtained after the second intermediate model passes validation. Therefore, by adopting a two-stage training strategy that includes both unsupervised and supervised learning, the model first understands the functions of RPA components and then masters the process mapping capability, thereby improving the domain adaptability and process generation accuracy of the workflow generation model.
[0050] It should be noted that the workflow generation model described above employs a two-stage model training strategy. The first stage focuses on enabling the model to deeply understand the intrinsic functions and semantics of RPA components through unsupervised learning, laying a solid foundation of component knowledge for subsequent workflow generation. The second stage, through supervised learning, specifically trains the model to master how to accurately map diverse user inputs into standardized, structured workflow description information, thereby ensuring that the final generated workflow not only conforms to user intent but also possesses high executability.
[0051] To achieve the above model training, the primary task is to construct a high-quality, domain-specific fine-tuning dataset (i.e., the RPA business dataset, or RPA-WorkflowBench dataset). The RPA business dataset is a key source for the model to acquire domain knowledge. Constructing this dataset requires systematically collecting a large number of business process instances from real-world environments within a specific domain, covering typical RPA application scenarios such as calibration, data acquisition, data analysis, data filtering, and audit report generation. Each sample can include a "user requirement description," a "corresponding standard process step sequence," and a "mapping relationship between process steps and specific RPA components." For example, for a requirement sample of "performing positive ion calibration," the process steps would be recorded in detail as "login to the quality control system," "select calibration program," "confirm calibration solution is in place," "start calibration," and "record calibration results." The component mapping would clearly specify the specific RPA component called at each step (such as Login_Component, Click_Button_Component) and its parameter configuration. The construction process of the RPA business dataset involves cleaning historical task logs, parsing process manuals, and structurally extracting component documentation to ensure data coverage and accuracy.
[0052] After obtaining the RPA business dataset, the selected basic large language model can be fine-tuned for domain adaptation. The fine-tuning process is divided into two stages with different training objectives and learning paradigms. The first stage adopts an unsupervised learning strategy, aiming to enable the massive parameters to efficiently learn and memorize the functional definitions, applicable scenarios, and calling methods of various components in the RPA business domain. In specific implementation, self-supervised tasks such as masked language modeling or component functional description reconstruction can be used to enable the model to obtain good representations in the component semantic space. The second stage switches to supervised learning. In this stage, the model will learn the "requirement-process" mapping. At this time, the training objective function becomes a sequence-to-sequence generation task. Based on the first intermediate model obtained in the previous stage, using the "reference input data" and "reference workflow description information" in the dataset as input-output pairs, and through optimization methods such as minimizing cross-entropy loss, the model finally masters the ability to generate accurate and standardized structured workflow description information based on any user input, thus obtaining a second intermediate model that can be directly applied to the production environment, i.e., the final workflow generation model.
[0053] In one embodiment, due to the flexibility and unstructured nature of natural language expression, users may use diverse vocabulary and sentence structures to describe the same business process intent, making it difficult for computer systems to directly and accurately understand and convert it into executable machine instructions. Therefore, when user input data includes natural language data, deep semantic parsing of the natural language data can be performed using a domain-adjusted workflow generation model as follows: The natural language data is input into the workflow generation model, which parses at least one core operational element from the natural language data. This core operational element includes at least one of triggering conditions, operation objects, and output formats. Based on the at least one core operational element, a structured workflow description information including RPA component identifiers, parameter configurations, and execution order is generated. Thus, by parsing core operational elements from natural language data and generating a structured workflow description, intelligent conversion from natural language to executable workflows is achieved, improving the system's usability.
[0054] It's important to note that the workflow generation model extracts well-defined core operational elements from natural language descriptions. These elements form the skeleton of the business process, including the triggering conditions for initiating automated tasks (e.g., "every day at 9 AM" or "when a new order is received"), the specific objects the process needs to operate on (e.g., "quality control data sheet" or "calibration report"), and the final output format the process needs to achieve (e.g., "generate a report and send an email"). By identifying and structuring these elements, the system lays a precise and machine-understandable foundation for subsequent process assembly.
[0055] After successfully parsing the core operational elements, the workflow generation model then enters the process generation phase. In this phase, the model needs to transform these abstract business elements into concrete, executable workflow definitions. To achieve this, the model invokes a pre-built RPA component knowledge base. This knowledge base is a structured database that stores detailed information on all available standardized RPA components, including RPA component identifiers (unique identifiers for each component), descriptions of their executable functions, parameter configurations (a list of configurable parameters), and execution order (compatibility with other components). The model semantically matches and logically associates the parsed core operational elements with the component functions in the knowledge base, assigning appropriate RPA components to each step in the process. For example, for the "Generate Portable Document Format (PDF) report" element within the "Output Format" element, the model will retrieve and select a component from the knowledge base that has a "report generation" function and supports PDF as the output format.
[0056] Next, the workflow generation model generates a structured process script, which is the structured workflow description information. This script is described using a machine-readable standardized data format (such as JSON or XML). The process script fully defines at least three key aspects: first, a list of identifiers for all RPA components included in the process; second, the specific parameter configuration required for the execution of each component (for example, for a data filtering component, parameters may include the field names to be filtered and the filtering condition values); and third, the precise execution order and logical dependencies of these components, including possible sequential execution, parallel execution, or conditional branching (such as IF-ELSE judgments). Taking a specific medical scenario as an example, when a user inputs the natural language request "perform positive ion calibration," the workflow generation model will parse out the triggering conditions (such as "after the instrument is powered on"), the operation object ("positive ion calibration procedure"), and the output format ("record calibration results to a certain system"). Subsequently, it calls the RPA component knowledge base to match the "Start Calibration Program Component", "Confirm Calibration Parameter Component", "Execute Calibration Component" and "Submit Data to System Component", and generates a structured workflow description that includes the identifiers of these components, their respective parameters (such as the unique identifier of the calibration program and the address of a certain system interface), and a strict sequential order, thereby completing the intelligent conversion from natural language to an executable workflow.
[0057] In one embodiment, the creation of traditional RPA workflows heavily relies on users' understanding of components and manual orchestration, posing a high barrier to entry for business users unfamiliar with technical configurations. Furthermore, it's difficult to quickly capture the operational details and implicit logic of users on the actual software interface. Therefore, the automatic generation of workflows can be achieved by recording and analyzing user interface operation demonstration data as follows: When user input data includes interface operation demonstration data, this data is input into the workflow generation model. The model extracts the user's operation event sequence on the graphical user interface from the demonstration data. The operation event sequence is parsed to identify the user-interacted interface elements and their corresponding operation types. Based on the identified interface elements and operation types, atomic operation sequences are generated. These atomic operation sequences are mapped to structured workflow description information, which includes the RPA component identifiers and execution parameters corresponding to the atomic operation sequences. Thus, by parsing the interface operation demonstration data into atomic operation sequences and mapping them to standard components, an "AI-assisted learning" function is realized, significantly reducing the learning cost of workflow creation.
[0058] It's important to note that when a user enables the AI-guided learning mode and demonstrates actual operations on the target software interface, the system can capture all user operation event sequences on the graphical user interface through underlying interface automation monitoring technology. These operation events include, but are not limited to, mouse clicks, keyboard input, menu selections, and data copying, and accurately record the location of each operation, the attributes of the target interface element, and the content of the operation. Next, the workflow generation model, or a dedicated parsing module working in conjunction with it, performs in-depth analysis of the captured raw operation event sequences. This process aims to identify which specific interface elements the user interacted with (e.g., a button labeled "Start Calibration," an input box named "Sample ID"), and the type of operation performed (e.g., "click," "enter text," "select dropdown option"). Based on the analysis results, the system aggregates and abstracts a series of continuous low-level interface events into atomic operation sequences with clear semantics. An atomic operation is the smallest indivisible execution unit in an RPA automation task, such as "clicking the 'OK' button" or "entering the text '{variable}' in the 'User ID' field." This process strips away the variability of the specific operational environment (such as changes in window position) while retaining the core intent and logical relationships of the operation. Finally, the system maps this sequence of atomic operations into a structured workflow description. This mapping process relies on a predefined RPA component library, where each standardized component encapsulates the functionality to implement a specific atomic operation. The system matches the most suitable RPA component identifier for each atomic operation and fills in the specific parameters required for its execution (such as the button's positioning information, the text content to be entered, or variable names in the example above), thereby generating a complete, structured workflow description that can be directly understood and executed by the RPA execution engine. In this way, users can "teach" the system to build automated processes simply by operating the software as usual, greatly reducing the technical threshold and training costs.
[0059] In one embodiment, workflow generation methods relying solely on natural language or recorded demonstrations may have limitations when handling complex business logic, such as difficulty in accurately expressing multi-branch conditional judgments, parallel execution paths, or complex data flow relationships. Therefore, the following approach can be used to identify and analyze user orchestration instructions on a graphical flowchart to achieve the conversion from visual programming to an executable workflow: When user input data includes graphical orchestration instructions, this data is input into the workflow generation model. The model extracts drag-and-drop and connection operations performed by the user on multiple RPA components within the flowchart. Based on these operations, an initial flowchart containing component topology relationships and data flow directions is generated. This initial flowchart data is then converted into structured workflow description information, including component execution order, parameter passing relationships, and branch logic. Thus, by converting graphical orchestration instructions into a structured description containing topology relationships and data flow directions, a precise conversion from low-code visual programming to an executable workflow is achieved.
[0060] It's important to note that when users interact with the canvas, the workflow generation model or a dedicated parsing module extracts at least two key types of information from the graphical orchestration data: first, which specific RPA standardized components the user drags from the component library to the canvas, defining the nodes of the process; and second, how the user connects these components with connecting lines, defining the execution paths and dependencies between nodes, i.e., the component topology. Based on these operations, the system first generates initial flowchart data. This initial flowchart data is a logical description of the canvas visual model, not only recording the list of components but, more importantly, accurately depicting the connections between components, convergence points, branch points, and the data flow directions that may be indicated on the connecting lines. For example, the initial flowchart data can represent the output of a "data filtering" component, which will be passed as input parameters to two downstream parallel components: "report generation" and "data archiving." Next, the workflow generation model transforms this initial flowchart data into machine-executable structured workflow description information. The model needs to parse the component topology relationships inherent in the initial flowchart data, infer all possible execution paths, identify conditional branch nodes (such as IF...ELSE...) and loop nodes, and clarify the data objects passed between components and their flow. The resulting structured workflow description information is completely detached from its visual representation; instead, it uses a standardized data format (such as JSON or XML) to explicitly define the execution order of all components, the parameter passing relationships between components, and the branching logic of the entire workflow. This allows the RPA execution engine to execute automated tasks accurately and flawlessly according to the logical design without needing to understand the original graph.
[0061] S3 matches the target standardized component from the preset RPA component library based on the structured workflow description information, and builds an executable workflow based on the target standardized component.
[0062] In this embodiment, by parsing the structured workflow description information, the business logic it describes can be decomposed into a sequence of tasks composed of "atomic operations." An atomic operation is the smallest indivisible execution unit in a software automation task, such as "data entry" or "button click." The system then maps each atomic operation to a predefined, functionally corresponding standardized component in the RPA component library. Finally, by assembling these matched target standardized components in sequence and configuring their execution parameters and logical relationships, an executable workflow that can be run by the RPA execution engine is constructed.
[0063] In one embodiment, matching target standardized components from the RPA component library based on structured workflow description information is a crucial step in instantiating an abstract process definition into a concrete executable unit. This process begins with a deep analysis of the structured workflow description information. The system needs to accurately extract at least two core elements from the structured workflow description information: firstly, the unique identifiers of all components involved in the process; and secondly, the execution order and logical relationships of these components. Based on the parsed component identifiers, the system performs precise searches and matches in the RPA component library. This component library is a predefined and organized repository of standardized components, each encapsulating specific automated operation capabilities (such as data entry, button clicks, information extraction, etc.) and possessing a unique identifier, a clear functional description, and configurable parameter interfaces. By comparing identifiers, the system finds standardized component instances corresponding to the functions of each step in the process description. Based on successful component matching, the system further constructs dynamic collaborative relationships between the standardized components according to the parsed execution order. This includes determining the data transfer relationships between components, i.e., clarifying how the output data of the previous component serves as the input parameter of the next component, which typically involves parsing and binding data flow variable names. Simultaneously, the system also needs to establish the execution dependencies between components. This defines the control flow logic of the entire workflow, such as whether it is strictly sequential execution or whether there are conditional branches, loops, or parallel execution paths. Through this series of operations, the system ultimately transforms a structured process description into an executable workflow composed of concrete component instances, where the data flow and control flow between components are clearly defined.
[0064] In one embodiment, when an RPA workflow is executed in a real software environment, it inevitably encounters various unexpected runtime anomalies, such as the inability to locate target software interface elements due to version updates, temporary loss of necessary input data, and operation timeouts caused by network latency. If these anomalies are handled solely by preset fixed rules, not only is the coverage limited, but it is also difficult to cope with complex and ever-changing real-world situations, leading to frequent interruptions in the automated process and requiring significant manual intervention for recovery. Therefore, an intelligent anomaly self-healing mechanism based on an anomaly handling model and a domain knowledge base can be introduced as follows: The executable workflow is run through the RPA execution engine, and its execution status is detected during execution. If an anomaly is detected, the anomaly context information is obtained. This anomaly context information is input into a preset anomaly handling model, which, combined with the preset domain knowledge base, outputs correction instructions corresponding to the anomaly context information. The execution parameters of the executable workflow are adjusted according to the correction instructions corresponding to the anomaly context information. Thus, by generating correction instructions through the anomaly handling model combined with the domain knowledge base when runtime anomalies occur, intelligent fault tolerance and adaptive adjustment of the workflow execution process are achieved.
[0065] It's important to note that during the execution of an executable workflow by the RPA execution engine, the system continuously monitors and detects its execution status. Once an anomaly is detected, the system immediately captures and constructs a detailed exception context. This exception context is fundamental for intelligent diagnostics and includes not only the exception type (e.g., "element location failed," "data validation error"), but also the system environment state at the time of the exception (e.g., the title of the currently active application window, screenshot), the currently executing task objective, and relevant historical execution records. For example, when the workflow fails to execute the step of "clicking the 'Submit' button in the system," the captured exception context will explicitly record the exception type as "element not found," along with the current window identifier and the button's location descriptor.
[0066] Then, this structured exception context information is input into a pre-defined exception handling model. The exception handling model is a specially trained large language model designed to understand and handle RPA execution exceptions. Its core task is to retrieve and reason from a pre-defined domain knowledge base based on the input exception context. The domain knowledge base is a structured collection of knowledge storing historical exception cases, common problem solutions, business rules, and system operation guidelines. The exception handling model can use semantic matching and case comparison to find the most relevant solution to the current exception situation from the knowledge base. For example, for the exception "button location failed," the model might retrieve a solution recorded in the knowledge base: "When the 'Submit' button fails to locate due to changes in the interface layout, try using the relative coordinates of the adjacent 'Confirm' button for assisted location, or enable a visual location scheme based on image recognition."
[0067] Finally, based on the retrieved solution information, the anomaly handling model generates one or more specific, executable corrective instructions. These instructions need to be precise enough to directly drive the RPA execution engine to adjust its behavior. Corrective instructions may include, but are not limited to: adjusting the positioning strategy and locator parameters of interface elements, reconfiguring component input data or waiting timeouts, skipping the current failed step and logging it, or switching to an alternative execution subprocess. Finally, the RPA execution engine receives and executes these corrective instructions, dynamically adjusting the execution parameters or local paths of the executable workflow to bypass or repair the current anomaly, allowing the workflow to continue execution. Through this closed-loop "perception-diagnosis-decision-execution" mechanism, the system achieves a shift from passive interruption to proactive adaptation.
[0068] In one embodiment, the core mechanism by which the exception handling model generates corrective instructions relies on its collaboration with a domain knowledge base. The model matches and compares the real-time captured exception context information with a large number of pre-stored historical exception cases in the domain knowledge base. By analyzing the similarity between the characteristics of the current exception (such as error type, system environment, and task node) and historical cases, the model can retrieve validated and effective solutions. Based on this, the exception handling model performs adaptive reasoning to generate executable corrective instructions for the current specific exception situation. These instructions can specifically manifest as adjusting the positioning method of interface elements (e.g., switching from attribute-based positioning to image recognition-based positioning), reconfiguring the runtime parameters of components, skipping the current failed step under a specific fault-tolerance strategy, or switching to an alternative execution path when preset conditions are met. Furthermore, to improve the overall decision-making quality and long-term adaptability of the system, this embodiment also introduces a reinforcement learning model for auxiliary optimization. The training of this reinforcement learning model is guided by key business indicators, and its reward function is designed to directly relate to "process execution success rate" and "number of manual interventions," aiming to incentivize the model to select operational strategies that can successfully complete the process and minimize manual intervention. During the decision-making process, the input to the exception handling model includes the core objective of the current task, real-time status information of the system environment, and relevant historical execution records. In this way, the model can learn to dynamically select the optimal sequence of RPA components and operation execution paths in complex and ever-changing real-world environments, thereby continuously improving process execution efficiency and robustness.
[0069] In one embodiment, the performance of the initially deployed workflow generation model and its associated RPA component library gradually degrades when faced with continuously evolving business systems, emerging process patterns, or edge cases not covered by the initial training data. This prevents the system from maintaining optimal performance, and the static system struggles to adapt to dynamic business environments in the long term. Therefore, a data-driven closed-loop optimization mechanism can be established by continuously collecting runtime feedback data and periodically updating the core model and component library: acquiring execution feedback data for executable workflows, including execution logs and user ratings; incrementally fine-tuning the workflow generation model based on the execution feedback data when the amount reaches a preset threshold; and updating the component configuration information in the RPA component library based on the incrementally fine-tuned workflow generation model. Thus, by incrementally fine-tuning the model and updating the component library based on execution feedback data, continuous optimization and self-learning capabilities of the workflow system are achieved.
[0070] It's important to note that the aforementioned closed-loop optimization mechanism begins with the systematic collection of execution feedback data. When an executable workflow runs within the RPA execution engine, the system meticulously records its execution logs. These logs are structured data records containing objective operational metrics, such as the operation time for each step, the types of exceptions encountered during execution and their specific context, and any corrections made by human intervention. Simultaneously, the system proactively collects subjective user feedback, typically through a user rating mechanism. For example, after the process is completed, users are prompted to provide a quantitative or qualitative rating of whether the process met their requirements or whether they were satisfied with the execution results.
[0071] Furthermore, when the accumulated execution feedback data reaches a preset threshold (e.g., 1000 valid feedback entries), the system can automatically trigger the optimization process. The optimization process first involves filtering valid optimization samples from the raw feedback data. The selection criteria for valid optimization samples are based on their learning value, mainly including two categories: first, successful process samples with user ratings higher than the preset threshold, which represent recognized and efficient process patterns; second, process samples that, although encountering anomalies, were ultimately successfully executed after manual correction, containing valuable fault recovery knowledge and optimization directions.
[0072] Based on the selected effective optimization samples, the system constructs an incremental training dataset. Subsequently, this dataset is used to perform supervised incremental fine-tuning of the workflow generation model. The goal of this fine-tuning is to periodically inject new and effective process knowledge and correction patterns into the model. By updating its model parameters, the model learns to generate more accurate, robust, or tailored workflow descriptions to new requirements while maintaining its original capabilities. For example, the system might learn better parameter combinations from multiple successful "spectrometer calibration" processes, or learn to automatically select more stable components under specific conditions from manually corrected anomaly cases.
[0073] In one embodiment, the closed-loop optimization mechanism is not limited to updating the model. The system can synchronously update component configuration information in the RPA component library based on the new knowledge embodied in the incrementally fine-tuned workflow generation model, and the component usage and performance revealed in the execution feedback. This may include optimizing the default parameters of existing components, adding new component variants, marking or eliminating underperforming components, and updating compatibility rules between components. Through this collaborative iteration between the model and the component library, the system achieves full-stack optimization from process generation to component foundations, ensuring that the entire system can continuously evolve with usage time, improving its efficiency and accuracy in handling similar tasks.
[0074] In one embodiment, after constructing an executable workflow based on target standardized components and before deploying it to the actual production environment, the executable workflow can be simulated and run to detect any logical conflicts or parameter errors. If a logical conflict or parameter error is detected, an error message is generated and returned to the user interface. Correction instructions input by the user based on the error message are received, and the executable workflow is updated based on the corresponding correction instructions. Therefore, by simulating and interactively correcting the executable workflow, the reliability and deployment success rate of the workflow are improved.
[0075] It's important to note that the simulation run uses a dedicated simulator to model the step-by-step execution of the workflow, with the core purpose of identifying and eliminating potential defects in advance. During the simulation run, the system can dynamically detect potential logical conflicts or parameter errors in the workflow. Logical conflicts include, but are not limited to, unreachable infinite loops in the execution path, references to uninitialized variables, or mismatches in data flow types between components. Parameter errors may manifest as components being configured with invalid input values or pointing to non-existent system resources. Once such problems are detected, the system immediately interrupts the simulation process and generates a structured error message. This message details the error type, its location, and its possible causes, clearly and intuitively returning this information to the user interface. This allows users to quickly locate and understand the problem. The system then receives correction instructions from the user based on this error message. Users, using their business knowledge and technical understanding, make targeted adjustments to the identified logical conflicts or parameter errors. Finally, based on the user-provided correction instructions, the system dynamically updates the executable workflow and can usually trigger the simulation run again to verify the correction effect, forming a rapid local debugging loop. This mechanism ensures the correctness and robustness of the workflow to the greatest extent possible before deployment, thereby significantly improving its reliability and deployment success rate in the production environment.
[0076] In one embodiment, establishing and maintaining a centralized process template library can improve the deployment efficiency and standardization of common workflows. Specifically, a process template library can be established, storing pre-configured standard workflow templates. Upon receiving a user's instruction to select a target workflow template from the library, an executable workflow corresponding to the target workflow template is generated. Thus, by establishing a process template library, users can directly invoke standard workflow templates, thereby improving the deployment efficiency and standardization of common workflows.
[0077] It's important to note that the workflow template library stores a variety of pre-configured and validated standard workflow templates. These templates are ready-to-use automation solutions designed for high-frequency or critical business scenarios (such as medical device calibration or specific quality inspection processes), encapsulating best-practice workflow logic and component configurations. When a user needs to perform a common task, there's no need to build a workflow from scratch; they simply need to select a matching target workflow template from the library. Upon receiving the user's selection instruction, the system can quickly generate a corresponding executable workflow instance based on the template's predefined structure, component sequence, and parameter settings, greatly simplifying the deployment process.
[0078] Furthermore, this process template library supports dynamic version updates based on execution feedback data. The system analyzes execution logs and user ratings from the production environment to identify areas for template optimization. Specific version update operations include, but are not limited to: optimizing the operating parameters of components within the template to improve efficiency, adding or removing unnecessary execution steps to streamline the process, or adjusting conditional judgment logic to enhance its adaptability and accuracy. For example, for a "positive ion calibration" template, the system may automatically optimize the "stabilization waiting time" parameter from 5 seconds to 3 seconds based on feedback from multiple successful executions, thereby improving the overall execution speed without affecting the success rate. Through this continuous iteration mechanism, the process template library can evolve in sync with business practices, ensuring that the provided standard solutions always remain in optimal condition.
[0079] In one possible implementation, the aforementioned embodiments of the intelligent exception self-healing mechanism based on the exception handling model and domain knowledge base, the data-driven closed-loop optimization mechanism, the embodiment of simulating the execution of executable workflows, and the embodiment of rapidly generating executable workflows (where users can directly select target workflow templates from the process template library) are not isolated from each other in specific implementations. They can be flexibly and freely combined and integrated according to actual business needs. For example, an executable workflow quickly generated through a template library can first enter a simulated running environment for logic verification. Once it is put into formal operation, if an exception is triggered, the intelligent exception self-healing mechanism can be immediately activated for real-time repair. At the same time, all execution logs and user feedback generated by the workflow throughout its lifecycle will be collected by the closed-loop optimization mechanism and used to drive the iterative updates of the workflow generation model and component library.
[0080] The workflow generation method disclosed in the above embodiments of this application first obtains user input data; then, it inputs the user input data into a preset workflow generation model, which outputs structured workflow description information. The workflow generation model is pre-tuned using an RPA business dataset. Finally, based on the structured workflow description information, it matches target standardized components from a preset RPA component library and constructs an executable workflow based on these components. Therefore, by employing a workflow generation model fine-tuned using an RPA business dataset, user input data is automatically converted into a structured workflow description and an executable workflow is constructed, significantly reducing the technical threshold and configuration complexity of workflow construction.
[0081] To facilitate understanding of the above embodiments, the following is in conjunction with... Figure 3 The workflow generation example diagram shown illustrates the complete business process from workflow creation to execution. Figure 3As shown, users can choose to create a new workflow or directly select an existing calibration workflow from the workflow library. Creating a new workflow includes two modes: manual creation and AI learning. Before creating a new workflow, the judgment conditions must be constructed. This can be done through a prompt word fine-tuning method ("select input → input prompt word → tool library call → output judgment"), or by using logical relationships such as "AND, OR, NOT, greater than, less than, equal to, and contain" to build rule logic. In manual creation, users enter the process canvas, select the start condition "calibration failure," the judgment condition "no data acquisition is running, calibration solution is not expired," and the execution action "automatically register calibration and complete calibration." After construction, a simulation run is performed; errors are adjusted, and after successful verification, the workflow is saved. Synchronously saved to the workflow library; In AI follow-up mode, after the user enters the workflow canvas and selects this mode, they go to the corresponding operation page to start the follow-up and demonstration of the complete operation. After the demonstration, the AI automatically returns to the canvas to generate a workflow draft. After the user makes fine adjustments, it also needs to go through the stages of simulation, error adjustment, and verification before being saved to the workflow library; When the user directly selects an existing calibration workflow in the workflow library, or starts a newly created workflow, it will enter the AI anthropomorphic judgment stage. The AI combines software interface feedback, visual solution to check the spectrum, instrument error code, instrument notification information, etc. to comprehensively judge whether the task is completed. If it is completed, the process will stop automatically. If it is not completed, it will further judge whether the retry limit has been met. If not, it will continue to retry. If the limit is met, the process will terminate. Thus, by highly abstracting software function items, providing rich functional components, and supporting users to customize and build workflows, it can meet almost all the fixed tasks required by users in their daily lives, greatly liberating users' productivity. In addition, it supports AI learning, allowing users to manually perform an operation once and the AI will automatically generate an RPA operation template. Users only need to confirm and make minor adjustments before it can be put into use. It also supports inserting AI judgment branches into workflows, going beyond simple logical judgments to support advanced judgments, data processing report output, and other functions.
[0082] The present application can implement all or part of the processes in the methods of the above embodiments, or it can be accomplished by a workflow generation device. The workflow generation device includes: at least one processor, at least one processor coupled to a memory, the memory storing a program or instructions, and the processor executing the program or instructions, so that the workflow generation device can implement the steps in the above method embodiments when it is executed.
[0083] See Figure 4 The diagram shows a schematic of the workflow generation apparatus provided in the embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.
[0084] The workflow generation device may specifically include the following modules: The data acquisition module 401 is used to acquire user input data.
[0085] The model processing module 402 is used to input user input data into a preset workflow generation model, and the workflow generation model outputs structured workflow description information. The workflow generation model is pre-tuned by the RPA business dataset.
[0086] Workflow building module 403 is used to match target standardized components from a preset RPA component library based on structured workflow description information, and to build an executable workflow based on the target standardized components.
[0087] The workflow generation apparatus disclosed in the above embodiments of this application first acquires user input data; then, it inputs the user input data into a preset workflow generation model, which outputs structured workflow description information. The workflow generation model is pre-tuned using an RPA business dataset. Finally, based on the structured workflow description information, it matches target standardized components from a preset RPA component library and constructs an executable workflow based on these components. Therefore, by employing a workflow generation model fine-tuned using an RPA business dataset, user input data is automatically converted into a structured workflow description and an executable workflow is constructed, significantly reducing the technical threshold and configuration complexity of workflow construction.
[0088] Furthermore, in one possible implementation of this application embodiment, the workflow generation device may further include the following modules: The model building module is used to build an initial model. Based on the RPA business dataset, multiple sets of training samples are obtained, each set including reference input data and corresponding reference workflow description information. These training samples are divided into a training dataset and a validation dataset. The initial model is trained in the first stage based on the training dataset to learn the functions of RPA components through unsupervised learning, resulting in a first intermediate model. The first intermediate model is then trained in the second stage based on the training dataset to learn the mapping from reference input data to reference workflow description information through supervised learning, resulting in a second intermediate model. The second intermediate model is validated based on the validation dataset, and the workflow generation model is obtained after the second intermediate model passes validation.
[0089] Therefore, by adopting a two-stage training strategy that includes both unsupervised and supervised learning, the model first understands the functions of RPA components and then masters the process mapping capability, thereby improving the domain adaptability and process generation accuracy of the workflow generation model.
[0090] Furthermore, in another possible implementation of this application embodiment, the user input data includes natural language data, and the above-mentioned model processing module 402 may specifically include the following units: The first processing unit is used to input natural language data into the workflow generation model. The workflow generation model parses at least one core operation element from the natural language data. The core operation element includes at least one of triggering conditions, operation objects, and output formats.
[0091] The second processing unit is used to generate structured workflow description information, including RPA component identifiers, parameter configurations, and execution order, based on at least one core operational element.
[0092] Therefore, by parsing core operational elements from natural language data and generating structured workflow descriptions, the intelligent conversion from natural language to executable workflows is achieved, improving the system's usability.
[0093] Furthermore, in another possible implementation of this application embodiment, the user input data includes interface operation demonstration data, and the above-mentioned model processing module 402 may specifically include the following units: The third processing unit is used to input the interface operation demonstration data into the workflow generation model, and the workflow generation model extracts the user's operation event sequence on the graphical user interface from the interface operation demonstration data.
[0094] The fourth processing unit is used to parse the operation event sequence, identify the user interaction interface elements and corresponding operation types, and generate an atomic operation sequence based on the identified interface elements and operation types.
[0095] The fifth processing unit is used to map atomic operation sequences into structured workflow description information, wherein the structured workflow description information includes the RPA component identifier and execution parameters corresponding to the atomic operation sequence.
[0096] Thus, by parsing the interface operation demonstration data into atomic operation sequences and mapping them into standard components, the "AI follow-up learning" function was realized, which greatly reduced the learning cost of workflow creation.
[0097] Furthermore, in another possible implementation of this application embodiment, the user input data includes graphical arrangement instruction data, and the above-mentioned model processing module 402 may specifically include the following units: The sixth processing unit is used to input graphical orchestration instruction data into the workflow generation model. The workflow generation model extracts the drag-and-drop operations and connection operations performed by the user on multiple RPA components in the process canvas from the graphical orchestration instruction data.
[0098] The seventh processing unit is used to generate initial flowchart data containing component topology relationships and data flow directions based on drag-and-drop and connection operations; and to convert the initial flowchart data into structured workflow description information, wherein the structured workflow description information includes component execution order, parameter passing relationships and branch logic.
[0099] Thus, by converting graphical orchestration instructions into a structured description that includes topological relationships and data flow, a precise conversion from low-code visual programming to executable workflows is achieved.
[0100] Furthermore, in another possible implementation of this application embodiment, the above-mentioned workflow generation device may further include the following modules: The parameter adjustment module is used to run executable workflows through the RPA execution engine and detect the execution status of the executable workflows during their execution. If an abnormal execution status is detected, the module obtains the abnormal context information. The abnormal context information is then input into a preset abnormal handling model, which, in conjunction with a preset domain knowledge base, outputs correction instructions corresponding to the abnormal context information. Based on the correction instructions corresponding to the abnormal context information, the module adjusts the execution parameters of the executable workflow.
[0101] Therefore, by generating correction instructions through an exception handling model combined with a domain knowledge base when an exception occurs, intelligent fault tolerance and adaptive adjustment of the workflow execution process are achieved.
[0102] Furthermore, in another possible implementation of this application embodiment, the workflow generation device may further include the following modules: The information update module is used to obtain execution feedback data of executable workflows, including execution logs and user ratings. When the amount of execution feedback data reaches a preset threshold, the workflow generation model is incrementally fine-tuned based on the execution feedback data. Based on the incrementally fine-tuned workflow generation model, the component configuration information in the RPA component library is updated.
[0103] Thus, by incrementally fine-tuning the model and updating the component library based on execution feedback data, the workflow system achieves continuous optimization and self-learning capabilities.
[0104] Furthermore, in another possible implementation of this application embodiment, the workflow generation device may further include the following modules: The simulation execution module is used to simulate the execution of the executable workflow and detect whether there are logical conflicts or parameter errors in the executable workflow; if a logical conflict or parameter error is detected, it generates an error message and returns it to the user interface; it receives correction instructions input by the user based on the error message and updates the executable workflow based on the correction instructions corresponding to the error message.
[0105] Therefore, by simulating and interactively correcting executable workflows, the reliability and deployment success rate of workflows are improved.
[0106] Furthermore, in another possible implementation of this application embodiment, the above-mentioned workflow generation device may further include the following modules: The rapid generation module is used to establish a process template library, which stores pre-configured standard workflow templates. When a user is given an instruction to select a target workflow template from the process template library, the module generates an executable workflow corresponding to the target workflow template.
[0107] Therefore, by establishing a process template library to allow users to directly call standard workflow templates, the deployment efficiency and standardization of common workflows are improved.
[0108] The workflow generation apparatus provided in this application embodiment can be applied in the aforementioned workflow generation method embodiment. For details, please refer to the description of the above method embodiment, which will not be repeated here.
[0109] Figure 5 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 5 As shown, the electronic device 500 of this embodiment includes: at least one processor 510 ( Figure 5 The diagram shows only one processor, a memory 520, and a computer program 521 stored in the memory 520 and executable on the at least one processor 510, wherein the processor 510 executes the computer program 521 to implement the steps in the above-described workflow generation method embodiments.
[0110] The electronic device 500 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 510 and a memory 520. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 500 and does not constitute a limitation on electronic device 500. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.
[0111] The processor 510 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0112] In some embodiments, the memory 520 may be an internal storage unit of the electronic device 500, such as a hard disk or memory of the electronic device 500. In other embodiments, the memory 520 may be an external storage device of the electronic device 500, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 500. Furthermore, the memory 520 may include both internal and external storage units of the electronic device 500. The memory 520 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 520 can also be used to temporarily store data that has been output or will be output.
[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0114] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0115] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0116] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0118] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0119] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.
[0120] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps in the various method embodiments described above.
[0121] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A workflow generation method, characterized in that, include: Step S1: Obtain user input data; Step S2: Input the user input data into a preset workflow generation model. The workflow generation model outputs structured workflow description information. The workflow generation model is pre-tuned using an RPA business dataset. Step S3: Based on the structured workflow description information, match the target standardized component from the preset RPA component library, and construct an executable workflow based on the target standardized component.
2. The method according to claim 1, characterized in that, The method further includes the following steps before step S2: Build the initial model; Based on the RPA business dataset, multiple sets of training samples are obtained, wherein each set of training samples includes reference input data and corresponding reference workflow description information; The multiple sets of training samples are divided into training datasets and validation datasets; The initial model is trained in the first stage based on the training dataset to learn the functions of RPA components through unsupervised learning, thereby obtaining a first intermediate model. The first intermediate model is trained in the second stage based on the training dataset, so that the first intermediate model learns the mapping from the reference input data to the reference workflow description information through supervised learning, thereby obtaining the second intermediate model; The second intermediate model is validated based on the validation dataset, and the workflow generation model is obtained after the second intermediate model passes the validation.
3. The method according to claim 1, characterized in that, The user input data includes natural language data, and step S2 includes: The natural language data is input into the workflow generation model, and the workflow generation model parses at least one core operation element from the natural language data, wherein the core operation element includes at least one of triggering condition, operation object and output format; Based on the at least one core operational element, generate the structured workflow description information, including RPA component identifiers, parameter configurations, and execution order.
4. The method according to claim 1, characterized in that, The user input data includes interface operation demonstration data, and step S2 includes: The interface operation demonstration data is input into the workflow generation model, and the workflow generation model extracts the user's operation event sequence on the graphical user interface from the interface operation demonstration data. The sequence of operation events is parsed to identify the user interaction interface elements and their corresponding operation types; Generate an atomic operation sequence based on the identified interface elements and operation types; The atomic operation sequence is mapped to the structured workflow description information, wherein the structured workflow description information includes the RPA component identifier and execution parameters corresponding to the atomic operation sequence.
5. The method according to claim 1, characterized in that, The user input data includes graphical arrangement instruction data, and step S2 includes: The graphical orchestration instruction data is input into the workflow generation model, and the workflow generation model extracts the drag-and-drop operations and connection operations performed by the user on multiple RPA components in the process canvas from the graphical orchestration instruction data. Based on the drag-and-drop operation and the connection operation, an initial flowchart data containing component topology relationships and data flow direction is generated; The initial flowchart data is converted into the structured workflow description information, wherein the structured workflow description information includes the component execution order, parameter passing relationship and branch logic.
6. The method according to any one of claims 1-5, characterized in that, The method further includes the following after step S3: The executable workflow is run through the RPA execution engine, and the execution status of the executable workflow is detected during its execution. If the execution status of the executable workflow is detected to be abnormal, obtain the abnormal context information; The exception context information is input into a preset exception handling model, and the exception handling model, in conjunction with a preset domain knowledge base, outputs a correction instruction corresponding to the exception context information. The execution parameters of the executable workflow are adjusted according to the correction instructions corresponding to the abnormal context information.
7. The method according to any one of claims 1-5, characterized in that, The method further includes the following after step S3: Obtain execution feedback data of the executable workflow, wherein the execution feedback data includes execution logs and user ratings; When the amount of execution feedback data reaches a preset threshold, the workflow generation model is incrementally fine-tuned based on the execution feedback data. Based on the incrementally fine-tuned workflow generation model, update the component configuration information in the RPA component library.
8. The method according to any one of claims 1-5, characterized in that, The method further includes the following after step S3: The executable workflow is simulated and run, and any logical conflicts or parameter errors in the executable workflow are detected. If a logical conflict or parameter error is detected, an error message is generated and returned to the user interface; Receive correction instructions input by the user based on the error message, and update the executable workflow based on the correction instructions corresponding to the error message.
9. The method according to any one of claims 1-5, characterized in that, The method further includes: Establish a process template library, wherein the process template library stores pre-configured standard workflow templates; Upon receiving an instruction from a user to select a target workflow template from the process template library, an executable workflow corresponding to the target workflow template is generated based on the target workflow template.
10. A workflow generation device, characterized in that, The device includes at least one processor coupled to a memory storing a program or instructions, the processor executing the program or instructions to cause the workflow generation apparatus to perform the method as described in any one of claims 1 to 9.
11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 9.
12. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 9.