Workflow execution optimization method and apparatus, electronic device, and storage medium

Abstract

The application discloses a workflow execution optimization method and device, electronic equipment and a storage medium, and belongs to the technical field of computer process arrangement. A process analysis intelligent agent converts natural language into a process intermediate representation; a process intermediate representation that passes semantic verification is compiled into a process definition executable by a process engine; the context during workflow execution is collected through an intelligent hook of the current node, and at least one preset intelligent agent is called to generate an intelligent agent decision result according to the context during workflow execution, thereby improving the intelligent perception and adaptive ability of the process runtime. The intelligent agent decision result is subjected to multi-intelligent agent conflict arbitration to obtain a target process execution decision corresponding to the current node of the workflow; the current node of the workflow is executed by the process engine according to the target process execution decision; a process execution log corresponding to the target process execution decision is collected, and an optimization suggestion is generated, thereby avoiding the misapplication of expired decisions and the solidification of errors.

Description

Technical Field

[0001] This application belongs to the field of computer workflow orchestration technology, specifically relating to a workflow execution optimization method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the field of computer technology, workflow engines have been widely used for the automated execution and management of business processes. Mainstream solutions are usually based on the BPMN (Business Process Model and Notation) standard to predefine static process models. After the process instance is started, it strictly follows the predetermined path and can only make limited branch selections through preset condition expressions, and cannot make intelligent decisions.

[0003] In recent years, some solutions have attempted to utilize artificial intelligence (AI) to assist in process modeling. However, these solutions only apply AI to the design phase of modeling; once deployed, the generated model reverts to static execution, lacking intelligent perception and adaptive capabilities during runtime. Furthermore, the conversion accuracy from natural language to executable process models in these solutions is low, resulting in a high rate of syntax errors when directly generating process definitions. In addition, these solutions typically employ a single intelligent agent for decision-making, making it difficult to handle complex business scenarios. Moreover, optimization during process execution largely relies on post-process analysis by humans, potentially leading to the misapplication of outdated decisions and the solidification of erroneous rules. Summary of the Invention

[0004] This application provides a workflow execution optimization method, apparatus, electronic device, and storage medium.

[0005] In a first aspect, embodiments of this application provide a workflow execution optimization method, the method comprising: Obtain the user's natural language; the natural language is used to describe the workflow required by the user. The natural language is converted into an intermediate representation of the process by a process parsing intelligent agent; The intermediate representation of the process is partially repaired and semantically verified, and the intermediate representation of the process that passes the semantic verification is compiled into a process definition that can be executed by the process engine; the process definition includes smart hooks corresponding to each node of the workflow, and preset smart agents corresponding to the smart hooks. During the execution of the workflow by the process engine, the context of the workflow execution is collected through the smart hook of the current node, and at least one of the preset smart agents is invoked to generate smart agent decision results based on the context of the workflow execution. The decision results of the intelligent agents are arbitrated through multi-agent conflict arbitration to obtain the target process execution decision corresponding to the current node of the workflow; The process engine executes the current node of the workflow according to the target process execution decision; Collect the process execution logs corresponding to the target process execution decision, and generate optimization suggestions based on the process execution logs; the optimization suggestions are used to update the process parsing agent and / or the preset agent for executing the next node of the workflow.

[0006] Optionally, the step of converting the natural language into an intermediate representation of the process through the process parsing agent includes: The process parsing agent is fine-tuned and its parameters are constrained so that it learns the mapping rules from natural language to intermediate process representations. Retrieve a target process template that matches the natural language from a preset knowledge base; Input prompts are generated based on the target process template and the natural language; The input prompt is input into the process parsing agent, so that the process parsing agent outputs the intermediate representation of the process in natural language.

[0007] Optionally, the step of performing local repair and semantic verification on the intermediate representation of the process includes: Perform initial semantic verification on the intermediate representation of the process; If the initial semantic verification fails, a minimum error subgraph is generated based on the semantically erroneous nodes and connections on all executable paths in the intermediate representation of the process; the minimum error subgraph is the error subgraph containing the fewest nodes and connections with the semantically erroneous nodes and connections as its boundary. Repair prompts are generated based on the minimum error subgraph, and the repair prompts are input into the process parsing agent so that the process parsing agent can perform local repairs on the nodes and connections covered by the minimum error subgraph to obtain the partially repaired intermediate representation of the process. Perform semantic verification again on the intermediate representation of the process after partial repair.

[0008] Optionally, the step of performing multi-agent conflict arbitration on the agent's decision results to obtain the target process execution decision corresponding to the current node of the workflow includes: Obtain the preset rule priority of the workflow; Generate at least one multi-agent conflict graph corresponding to the preset agent based on the agent's decision-making results; Based on the multi-agent conflict graph, determine the conflict in the execution decisions of at least one of the preset agents at the current node; Based on the preset rule priority of the workflow and the conflict between the execution decisions of at least one preset intelligent agent at the current node, the target workflow execution decision corresponding to the current node of the workflow is determined.

[0009] Optionally, the operational dimensions of the workflow include at least one of: workflow variables, task assignment, workflow routing, and workflow patching; the step of executing the current node of the workflow according to the target workflow execution decision through the workflow engine includes: The process engine executes the process variables of the workflow according to the target process, thereby updating the business data generated during the current node of the workflow. And / or, The process engine executes the task assignment of the workflow according to the target process execution decision, so as to determine the task execution object of the current node of the workflow; And / or, The process engine executes the process routing of the workflow according to the target process execution decision to determine the flow branch of the current node of the workflow; the flow branch is used to indicate the next node of the workflow. And / or, The process engine executes process patches of the workflow according to the target process execution decision to update the next node of the workflow.

[0010] Optionally, generating optimization suggestions based on the process execution log includes: Based on the process execution log, determine the node data of the current node and previous nodes of the workflow; the node data includes: average node dwell time, node rejection rate, and average completion cycle; Obtain a preset standard line for judging whether the node data is normal, and determine candidate abnormal nodes from the node data according to the preset standard line; Extract the rejection history instances under the candidate exception nodes and the process variables of the rejection history instances from the process execution log; Based on the combination of values ​​of the process variables and the rejection results of the rejection history instances, determine the support and confidence of each combination of values ​​of the process variables in the rejection history instances. The combination of process variables whose support is greater than the preset support threshold and whose confidence is greater than the preset confidence threshold is used as the process variable combination related to rejection. Root cause analysis is performed on the candidate abnormal nodes and the combination of process variables to obtain the optimization suggestions.

[0011] Optionally, the method further includes: The optimization suggestions are transformed into static rules, and the rule base of the process parsing agent is updated using the static rules. And / or, The optimization suggestions are converted into prompt word patches, and the prompt word instruction set of the process parsing agent and the prompt word instruction set of the preset agent for executing the next node of the workflow are updated through the prompt word patches.

[0012] Optionally, updating the process parsing agent through the static rules includes: Determine the frequency of occurrence of candidate rules for the same preset agent in the static rules; the static rules are the condition judgment logic directly executed by the process engine; If the frequency of occurrence of a candidate rule exceeds a preset threshold, the candidate rule is written into the rule base of the process parsing agent.

[0013] Optionally, converting the optimization suggestions into prompt word patches includes: Obtain the preset prompts for the process parsing agent and the preset prompts for the preset agent to execute the next node of the workflow, as well as the historical requirements of the workflow; Generate candidate prompt word patches based on the optimization suggestions and the preset prompt words; The candidate suggestion patch is validated in a sandbox environment based on the historical requirements of the workflow. The verified candidate prompt word patch is used as the prompt word patch.

[0014] Secondly, embodiments of this application provide a workflow execution optimization apparatus, the apparatus comprising: The natural language acquisition module is used to acquire the user's natural language; the natural language is used to describe the workflow required by the user. The intermediate representation conversion module is used to convert the natural language into an intermediate representation of the process through the process parsing agent; The semantic verification and repair module is used to perform local repair and semantic verification on the intermediate representation of the process, and compile the intermediate representation of the process that passes semantic verification into a process definition that can be executed by the process engine; the process definition includes smart hooks corresponding to each node of the workflow, and preset smart agents corresponding to the smart hooks. The decision result generation module is used to collect the context of the workflow execution through the smart hook of the current node during the execution of the workflow by the process engine, and call at least one of the preset smart agents to generate smart agent decision results based on the context of the workflow execution. The decision conflict arbitration module is used to arbitrate multi-agent conflicts on the decision results of the intelligent agent to obtain the target process execution decision corresponding to the current node of the workflow; The target decision execution module is used to execute the current node of the workflow according to the target process execution decision through the process engine; An optimization suggestion generation module is used to collect process execution logs corresponding to the target process execution decision and generate optimization suggestions based on the process execution logs; the optimization suggestions are used to update the process parsing agent and / or the preset agent for executing the next node of the workflow.

[0015] Optionally, the intermediate representation conversion module includes: The analytical model fine-tuning submodule is used to fine-tune and constrain the parameters of the process parsing agent so that the process parsing agent learns the mapping rules from natural language to intermediate process representation; The process template retrieval submodule is used to retrieve target process templates that match the natural language from a preset knowledge base; The input prompt word generation submodule is used to generate input prompt words based on the target process template and the natural language. The intermediate representation output submodule is used to input the input prompt words into the process parsing agent, so that the process parsing agent outputs the intermediate representation of the process in the natural language.

[0016] Optionally, the semantic verification and repair module includes: The initial semantic verification submodule is used to perform initial semantic verification on the intermediate representation of the process; The error subgraph generation submodule is used to generate a minimum error subgraph based on the semantically erroneous nodes and connections on all executable paths in the intermediate representation of the process when the initial semantic verification fails. The minimum error subgraph is the error subgraph containing the fewest nodes and connections with the semantically erroneous nodes and connections as its boundary. The subgraph local repair submodule is used to generate repair prompt words based on the minimum erroneous subgraph, and input the repair prompt words into the process parsing agent, so that the process parsing agent can perform local repair on the nodes and connections covered by the minimum erroneous subgraph to obtain the partially repaired intermediate representation of the process; The semantic verification submodule is used to perform semantic verification on the intermediate representation of the process after partial repair.

[0017] Optionally, the decision conflict arbitration module includes: The priority acquisition submodule is used to acquire the preset rule priority of the workflow; The conflict graph generation submodule is used to generate at least one multi-agent conflict graph corresponding to the preset agent based on the agent's decision results. The current conflict determination submodule is used to determine, based on the multi-agent conflict graph, a conflict in the execution decisions of at least one of the preset agents at the current node. The execution decision determination submodule is used to determine the target process execution decision corresponding to the current node of the workflow based on the preset rule priority of the workflow and the conflict of execution decisions of at least one preset intelligent agent at the current node.

[0018] Optionally, the operational dimensions of the workflow include at least one of: process variables, task assignment, process routing, and process patching; the target decision execution module includes: The process variable execution submodule is used to execute the process variables of the workflow according to the target process execution decision through the process engine, so as to update the business data generated during the current node of the workflow. And / or, The task assignment and execution submodule is used to execute the task assignment of the workflow according to the target workflow execution decision through the workflow engine, so as to determine the task execution object of the current node of the workflow; And / or, The process routing execution submodule is used to execute the process routing of the workflow according to the target process execution decision through the process engine, so as to determine the flow direction branch of the current node of the workflow; the flow direction branch is used to indicate the next node of the workflow; And / or, The process patch execution submodule is used to execute process patches of the workflow according to the target process execution decision through the process engine, so as to update the next node of the workflow.

[0019] Optionally, the optimization suggestion generation module includes: The node data determination submodule is used to determine the node data of the current node and previous nodes of the workflow based on the process execution log; the node data includes: average node dwell time, node rejection rate, and average completion cycle; The abnormal node determination submodule is used to obtain a preset standard line for judging whether the node data is normal, and to determine candidate abnormal nodes from the node data according to the preset standard line. The rejection instance extraction submodule is used to extract the rejection history instances under the candidate abnormal nodes and the process variables of the rejection history instances from the process execution log; The process variable calculation submodule is used to determine the support and confidence of each process variable value combination in the rejection history instance based on the value combination of the process variable and the rejection result of the rejection history instance. The variable combination determination submodule is used to combine the values ​​of process variables whose support is greater than the preset support threshold and whose confidence is greater than the preset confidence threshold as process variable combinations related to rejection. The optimization suggestion generation submodule is used to perform root cause analysis on the candidate abnormal nodes and the combination of process variables to obtain the optimization suggestions.

[0020] Optionally, the device further includes: The rule base conversion and update module is used to convert the optimization suggestions into static rules and update the rule base of the process parsing agent through the static rules. And / or, The prompt word conversion and update module is used to convert the optimization suggestions into prompt word patches, and update the prompt word instruction set of the process parsing agent and the prompt word instruction set of the preset agent for executing the next node of the workflow through the prompt word patches.

[0021] Optionally, the rule base conversion and update module includes: The candidate rule determination submodule is used to determine the frequency of occurrence of candidate rules for the same preset intelligent agent in the static rules; the static rules are the condition judgment logic directly executed by the process engine. The rule base update submodule is used to write the candidate rule into the rule base of the process parsing agent when the occurrence frequency of the candidate rule exceeds a preset threshold.

[0022] Optionally, the prompt word conversion and update module includes: The historical requirements acquisition submodule is used to acquire the preset prompt words of the process parsing agent and the preset agent for executing the next node of the workflow, as well as the historical requirements of the workflow. The prompt word patch generation submodule is used to generate candidate prompt word patches based on the optimization suggestions and the preset prompt words; The prompt word patch verification submodule is used to verify the candidate prompt word patches in a sandbox environment based on the historical requirements of the workflow; The prompt word update submodule is used to use the verified candidate prompt word patch as the prompt word patch.

[0023] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0024] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0025] The embodiments of this application have the following advantages: This application's embodiments can acquire the user's natural language; natural language is used to describe the user's required workflow, enabling business personnel without a technical background to directly express their business process intent without learning BPMN modeling languages ​​or process design tools, significantly reducing the usage threshold and communication costs of process modeling. By using a process parsing intelligent agent to convert natural language into an intermediate process representation, a leap from human-readable business descriptions to machine-understandable formal representations is achieved. Local repair and semantic verification are performed on the intermediate process representation, and the semantically verified intermediate process representation is compiled into a process definition executable by the process engine. Before process deployment, process structure errors are proactively detected and intercepted, improving the reliability of process generation. Compiling the verified intermediate process representation into an executable process definition improves the conversion accuracy from natural language to an executable process model.

[0026] During the execution of workflows by the workflow engine, the context of workflow execution is collected through the smart hook of the current node, and at least one preset intelligent agent is invoked to generate intelligent agent decision results based on the context of workflow execution. The execution context of the current process instance is collected in real time by the smart hook embedded in the node lifecycle, and the preset intelligent agent is invoked to generate intelligent decision results based on the context, which improves the intelligent perception and adaptive capabilities of the process runtime. At the same time, different nodes can be pre-configured to invoke different types of intelligent agents, realizing on-demand and precise deployment of intelligent capabilities.

[0027] The decision-making results of the intelligent agents are arbitrated by multiple intelligent agents to obtain the target process execution decision corresponding to the current node of the workflow. When multiple intelligent agents make collaborative decisions, the candidate decision results returned by each intelligent agent are conflict identified and arbitrated, which reduces the problem of conflict between candidate actions in multi-agent collaborative scenarios.

[0028] The process engine executes the current node of the workflow according to the target process and makes decisions. It also performs corresponding operations on the current node according to the arbitrated target process, so that the intelligent decision results can drive the actual behavior of the engine and avoid the risk of inconsistency or concurrent conflict caused by external systems directly modifying engine data.

[0029] Collect process execution logs corresponding to the target process execution decisions, and generate optimization suggestions based on the process execution logs; the optimization suggestions are used to update the process parsing agent and / or the preset agent of the next node of the execution workflow, so that the process can be continuously optimized as business changes occur, and avoid the misapplication of outdated decisions and the solidification of erroneous rules. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the steps of a workflow optimization method according to an embodiment of this application; Figure 2 This is a flowchart illustrating the steps of another workflow optimization method according to an embodiment of this application; Figure 3 This is a logic diagram of a workflow execution optimization method according to an embodiment of this application; Figure 4 This is a structural block diagram of a workflow execution optimization device according to an embodiment of this application. Detailed Implementation

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

[0032] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0033] The workflow execution optimization method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0034] Reference Figure 1The diagram illustrates a flowchart of a workflow execution optimization method according to an embodiment of this application. The method may specifically include the following steps: Step 101: Obtain the user's natural language; natural language is used to describe the workflow required by the user. In this embodiment, the user's input natural language can be obtained through the user interaction interface provided by the core process control layer or the intelligent decision and orchestration layer. This natural language is used to describe the user's required workflow, including process requirements expressed by the user in everyday business terms, such as "a procurement approval process is needed; amounts less than 50,000 yuan require manager approval, otherwise approval by the director; if the applying department is IT, approval by the CTO is also required," etc.

[0035] This application enables business personnel without a technical background to describe business process requirements to the system in the most natural way by directly obtaining natural language instead of structured modeling language, without having to learn BPMN modeling language or process design tools. This significantly reduces the usage threshold and communication cost of workflow modeling and shortens the cycle of transforming business requirements into executable processes.

[0036] Meanwhile, natural language, as the most commonly used form of human expression, can fully preserve the business semantics, implicit rules, and contextual information in user requirements, including process steps, approval roles, flow conditions, branch logic, attachment requirements, urgency, and countersigning rules. This avoids the semantic distortion, information loss, or misunderstanding caused by the need for multiple rounds of translation of requirements into structured documents or BPMN diagrams in traditional solutions. It provides a high-quality, high-information-density input foundation for the subsequent process parsing agent to perform accurate process conversion based on the complete context.

[0037] Furthermore, the methods for obtaining natural language in this application may include text input boxes provided on the front-end page, text converted from voice input, or demand description text submitted by external systems through API interfaces. The natural language may be accompanied by business attachments (such as quotations, draft contracts, screenshots of complaints, etc.) so that the subsequent intelligent agent can make risk judgments and generate decisions based on richer context.

[0038] Step 102: The natural language is converted into an intermediate representation of the process by the process parsing agent; In this embodiment, the process parsing agent is a dedicated agent deployed in the intelligent decision-making and orchestration layer, used to automatically convert user-input natural language process requirements into a structured intermediate process representation. For example, the process parsing agent can receive natural language text transmitted from the core process control layer, retrieve process templates, regulations, approval chains, or countersigning patterns that semantically match the natural language process requirements, and generate a structured intermediate process representation conforming to a schema (predefined data structure) based on the retrieved and enhanced input from the large model.

[0039] The workflow intermediates can use structured data in JSON format, organized according to a predefined schema, and can include core modules such as node lists, connection lists, and hook configurations. The node list describes each task node in the workflow, along with its type, name, input / output variables, and execution role. The connection list describes the flow paths between nodes, gateway conditions, and routing expressions. The hook configurations mark the nodes that need to invoke agents, along with their corresponding agent types and invocation methods.

[0040] This application utilizes a process parsing intelligent agent to convert natural language into intermediate process representations, achieving automated conversion from unstructured natural language requirements to machine-understandable structured process descriptions. This avoids the inefficiencies and error-proneness associated with manually drawing BPMN flowcharts or writing XML definitions. Furthermore, enhanced retrieval through an enterprise knowledge base ensures that the generated intermediate process representations conform to existing enterprise policies and business practices, rather than being generalized suggestions detached from the enterprise's actual situation.

[0041] Step 103: Perform local repair and semantic verification on the intermediate representation of the process, and compile the intermediate representation of the process that passes semantic verification into a process definition that can be executed by the process engine; the process definition includes the smart hooks corresponding to each node of the workflow, and the preset smart agents corresponding to the smart hooks. In this embodiment of the application, after the process parsing agent converts natural language into an intermediate representation of the process, it does not directly compile the intermediate representation of the process into a final executable file. Instead, the semantic verification module in the core process control layer first performs multi-dimensional automated semantic verification on the intermediate representation of the process.

[0042] Semantic validation can include reachability validation, concurrency structure validation, variable dependency validation, compensation configuration validation, permission validation, and node lifecycle hook validation, among others. Reachability validation checks for unreachable nodes or paths to the termination node in the intermediate representation of the process, preventing the generation of invalid processes with dead nodes or infinite loops. Concurrency structure validation checks whether branches of parallel gateways have corresponding merging gateways, avoiding token hanging or duplicate triggering due to missing merging of concurrent branches. Variable dependency validation checks whether the input variables of each node have been correctly assigned values ​​in their predecessor nodes, preventing exceptions caused by reading undefined variables during process execution. Compensation configuration validation checks whether compensation nodes have corresponding compensable activities, preventing rollback failures due to missing targets when compensation actions are triggered. Permission validation checks whether the execution roles configured for each node are clearly defined in the enterprise permission system. Node lifecycle hook validation checks whether the agent type specified in the hook configuration is registered and available in the intelligent decision-making and orchestration layer, preventing process failures due to calling non-existent agents during runtime.

[0043] When semantic verification detects an error, the process parsing agent calls the larger model to locally regenerate the error, and then performs a second semantic verification. After the semantic verification passes, the template mapping engine deterministically compiles the verified intermediate process representation into a process definition that can be executed by the process engine.

[0044] The compilation process can convert each element in the intermediate representation into the corresponding BPMN 2.0 XML tag according to fixed mapping rules. For example, user task nodes in the node list are converted into BPMN user task tags, gateway nodes are converted into corresponding BPMN gateway tags, and connection conditions are converted into BPMN sequential flow condition expressions. This compilation process is a deterministic mechanical mapping, which ensures that the process definition output of each compilation is syntactically correct and structurally consistent.

[0045] In the compiled process definition, each node can be configured with corresponding smart hooks based on its type and business requirements. Smart hooks are custom logic extension points embedded in the lifecycle of process engine nodes, used to collect context, invoke smart agents, and intervene in the process flow during node execution. The process definition also pre-specifies the corresponding preset smart agent type for each node configured with smart hooks, so that the process is clear at deployment time which smart capabilities each node needs to invoke, eliminating the need for dynamic judgment at runtime and reducing runtime configuration overhead and decision latency.

[0046] Step 104: During the execution of the workflow by the workflow engine, the context of the workflow execution is collected through the smart hook of the current node, and at least one preset smart agent is invoked to generate smart agent decision results based on the context of the workflow execution. In this embodiment, after the process definition is compiled and deployed, an instance of the process definition is started and executed by the workflow engine in the core process control layer. During the execution of the process instance, when it reaches a node configured with a smart hook, the workflow engine automatically triggers the smart hook in the lifecycle events of that node. The lifecycle events may include: task creation event, task completion event, gateway arrival event, or node entry event.

[0047] As a custom logical extension component embedded in the workflow engine node lifecycle, the smart hook can collect the execution context of the current process instance. This execution context can include: process instance identifier (processInstanceId), business identifier (businessKey), current node identifier (currentActivityId), a snapshot of the process variables of the current node, and the attached text summary or attachment storage address associated with the task. The process variable snapshot can include structured business data such as application amount, application department, business type, risk score, and task priority. The attachment text summary is provided by the attachment storage service after extracting and summarizing the text of user-uploaded documents (such as quotations, draft contracts, and text in complaint screenshots).

[0048] After collecting the execution context, the smart hook determines the type of preset agent to be called based on the hook configuration of the current node, and constructs the collected execution context into an agent call request according to a unified input data format. The request is then sent to the corresponding preset agent by calling the unified interface (e.g., REST API) provided by the smart decision and orchestration layer.

[0049] After receiving a request, the pre-defined agent can perform a comprehensive analysis based on the business data and attached summary in the execution context to generate the corresponding agent decision result. This decision result can be returned in a standardized agent decision envelope format, which may include fields such as: action type, target node identifier, assignee, decision reason, parameters, and confidence.

[0050] Through the aforementioned mechanism, this application enables the process to make real-time intelligent decisions based on actual business data and unstructured attachment content during runtime, breaking through the limitation of traditional workflow engines that can only make branch selections based on preset numerical conditions, and realizing dynamic perception and adaptive adjustment during process execution. Simultaneously, since different nodes can be pre-configured to call different types of intelligent agents (e.g., approval nodes call risk assessment intelligent agents to evaluate business risks, and dispatch nodes call task dispatch intelligent agents to recommend the optimal handler based on personnel load), this application achieves on-demand and precise deployment of intelligent capabilities, avoiding the waste of computing resources and decision delays caused by calling a general large model at all nodes, thus improving the overall system efficiency. The intelligent hook communicates with the intelligent agent through synchronous HTTP calls or asynchronous message queues. In synchronous call mode, the intelligent agent's decision result is returned immediately, and the process engine continues execution after waiting for the result; in asynchronous mode, after the intelligent hook publishes the request to the message queue, the process engine does not block and wait, and the intelligent agent returns the decision result through a callback interface or polling method, suitable for scenarios with long decision-making times or high concurrency.

[0051] Step 105: Perform multi-agent conflict arbitration on the agent's decision results to obtain the target process execution decision corresponding to the current node of the workflow; In the embodiments of this application, multiple preset intelligent agents (e.g., risk assessment intelligent agents, task assignment intelligent agents, problem attribution intelligent agents, or compensation scheme intelligent agents) may be configured and invoked at the same node or stage of the workflow. Each of the multiple intelligent agents independently generates its own intelligent agent decision result based on the same execution context. Since different intelligent agents have different decision objectives and judgment logic, their respective output decision results may have direct or indirect conflicts in terms of target nodes, process variables, task handlers, patch operations, permission scope, or external side effects.

[0052] For example, the risk assessment agent might suggest inserting a financial review node after the current node, while the process optimization agent might suggest jumping directly to the next node to shorten the cycle. The two agents contradict each other regarding the flow of the process. Similarly, the task assignment agent recommends person A, while the risk assessment agent recommends person B due to permission verification requirements. There is a conflict between the two agents in personnel assignment.

[0053] To address the potential conflicts in multi-agent decision-making results, this application establishes a multi-agent conflict arbitration module in the core process control layer. This module performs unified conflict detection and arbitration on the candidate decision results returned by each agent, thus avoiding the problem of the process engine being at a loss or executing in a chaotic manner when multiple agents generate contradictory instructions due to their independent reasoning. This ensures the consistency of multi-agent collaborative decision-making and the stability of the system.

[0054] Step 106: Execute the current node of the decision-making workflow according to the target workflow using the workflow engine; In this embodiment, after the multi-agent conflict arbitration module outputs a unique target process execution decision, the core process control layer can pass this target process execution decision to the workflow engine, which then executes the current node according to the decision. The workflow engine executes the corresponding operation based on the action type contained in the agent decision envelope in the target process execution decision.

[0055] For example, when the action is routing (goto), the workflow engine sets process variables to change the subsequent flow direction of the current node, causing the process instance to jump to the target node; when the action is assignment (assign), the workflow engine sets the handler variable of the current task and assigns the task to the handler specified by the decision; when the action is inserting a node (insertNode) or adding a node (add_node), the workflow engine executes a two-phase commit mechanism for process patching, dynamically inserting new task nodes at the safe point of the process and legally connecting the new nodes with the existing process structure; when the action is updating a rule (update_rule), the workflow engine or process parsing agent updates the decision rules in the rule base; when the action is setting a service level agreement (set_sla), the workflow engine adds a timing boundary event or timeout handover strategy to the current node; when the action is modifying a prompt word (modify_prompt), the workflow engine triggers the process optimization agent to generate a prompt word patch, which is then deployed after testing and verification.

[0056] Through the aforementioned execution mechanism, the workflow engine can accurately execute the arbitrated target process execution decision. It supports not only lightweight variable modifications and personnel adjustments but also heavyweight dynamic changes to the process structure (such as inserting new task nodes at runtime), ensuring consistency, transactionality, and security during process state transitions. This avoids the risk of inconsistencies or concurrent conflicts caused by external systems directly modifying engine data. Simultaneously, it reliably transforms the agent's analysis results into the engine's actual execution behavior, forming a complete closed loop between intelligent decision-making and process execution. Once the arbitrated target process execution decision is completed, the workflow engine writes the execution trajectory, decision result, and execution result of that node to the log collector for use in subsequent process log collection and optimization suggestion generation.

[0057] Step 107: Collect the process execution log corresponding to the target process execution decision, and generate optimization suggestions based on the process execution log; the optimization suggestions are used to update the process parsing agent and / or the preset agent of the next node of the execution workflow.

[0058] In this embodiment, after the workflow engine completes the execution of the current node according to the target process, the log collector can automatically collect the process execution logs generated during the execution of that node. The log collector is a component deployed in the core process control layer, used to persist the process execution trajectory, node status, process variables, and agent decision records to the process log library.

[0059] After the process log database stores the aforementioned log data, the process optimization agent is triggered at a preset time period (e.g., 02:00 AM daily) to read all process instance records and their associated node records from the previous period in the process log database via a database connection. The process optimization agent can perform root cause analysis based on the log data to obtain specific, actionable optimization suggestions. These generated optimization suggestions can be used to update the decision logic of the process parsing agent and / or the decision-making capabilities of the preset agent for executing the next node of the workflow.

[0060] This application's embodiments enable business personnel without technical backgrounds to directly express business process intent without learning BPMN modeling languages ​​or process design tools, significantly reducing the usage threshold and communication costs of process modeling. By using a process parsing agent to convert natural language into an intermediate process representation, it achieves a leap from human-readable business descriptions to machine-understandable formal representations. Proactively identifying and intercepting process structure errors before deployment improves the reliability of process generation. The verified intermediate process representation is compiled into an executable process definition for the process engine, improving the accuracy of the conversion from natural language to an executable process model. Intelligent hooks embedded in the node lifecycle collect the execution context of the current process instance in real time and call preset agents to generate intelligent decision results based on this context, improving the intelligent perception and adaptive capabilities during process runtime. Simultaneously, different nodes can be pre-configured to call different types of agents, achieving on-demand and precise deployment of intelligent capabilities. When multiple agents collaborate on decision-making, conflict identification and arbitration are performed on the candidate decision results returned by each agent, reducing the problem of conflicting candidate actions in multi-agent collaborative scenarios. The process engine executes corresponding operations on the current node according to the arbitrated target process execution decision. This allows the intelligent decision results to drive the engine's actual behavior, avoiding the risks of inconsistencies or concurrent conflicts caused by external systems directly modifying engine data. By collecting process execution logs corresponding to the target process execution decisions and generating optimization suggestions based on these logs, the process can be continuously optimized as business changes occur, preventing the misapplication of outdated decisions and the solidification of erroneous rules.

[0061] Reference Figure 2 The diagram illustrates a flowchart of another workflow optimization method according to an embodiment of this application. The method may specifically include the following steps: Step 201: Obtain the user's natural language; the natural language is used to describe the workflow required by the user. Step 202: The natural language is converted into an intermediate representation of the process by the process parsing agent; In one embodiment, the step of converting natural language into an intermediate representation of the process by the process parsing agent may further include the following sub-steps: Sub-step S11 involves fine-tuning and parameter constraints on the process parsing agent to enable it to learn the mapping rules from natural language to intermediate process representations. In the embodiments of this application, fine-tuning and parameter constraints can be performed on the large model on which the process parsing agent relies, so that the process parsing agent learns the mapping rules from natural language to intermediate process representations. The fine-tuning process can adopt the LoRA parameter efficient fine-tuning method, and is trained based on the basic large model (such as Llama or ChatGLM).

[0062] For example, the training dataset may contain manually labeled “natural language requirements - correct JSON intermediate representation” pairing samples, covering multiple business scenarios such as procurement approval, expense reimbursement, and customer complaints, with a quantity of approximately 1,000 to 2,000 pairs, and expanded to approximately 5,000 pairs through data augmentation methods such as back translation.

[0063] LoRA fine-tuning can update only some low-rank adapter parameters of a large model. While maintaining the general semantic understanding capabilities of the base model, it enables the model to learn to convert business semantics such as process steps, approval roles, flow conditions, and branching logic from natural language into a structured intermediate process representation. After fine-tuning, the `guided_json` parameter is set when calling the large model API to enforce that the output of the large model conforms to the predefined schema. This ensures that the output intermediate process representation meets the requirements of subsequent automated validation and compilation in terms of field completeness, data type, and format specifications, thus preventing model output format errors or missing fields from the outset.

[0064] Sub-step S12: Retrieve the target process template that matches the natural language from the preset knowledge base; In this embodiment, a target process template matching the natural language input by the user can be retrieved from a preset knowledge base. The preset knowledge base can be an enterprise knowledge base, storing knowledge assets such as existing process templates, regulations, approval chain configurations, countersigning modes, and historically deployed correct process definitions.

[0065] Upon receiving a natural language request, the process parsing agent uses that natural language as a query vector to perform a vector retrieval in a pre-defined knowledge base, recalling one or more target process templates that are semantically most similar to the natural language. This enhanced retrieval mechanism ensures that the process parsing agent can reference and reuse existing enterprise process design experience and institutional requirements when generating intermediate process representations. This avoids the model generating process definitions based on general knowledge that do not meet the actual management requirements of the enterprise, thus improving the enterprise adaptability and standardization of the generated results.

[0066] Sub-step S13: Generate input prompts based on the target process template and natural language. In this embodiment, input prompts can be generated based on the retrieved target process template and the user's input natural language. Specifically, the process parsing agent will concatenate the retrieval results, such as process templates, regulations, or approval chains, from a preset knowledge base with the original natural language requirements according to a predefined prompt template format to construct a complete input prompt containing task description, retrieval context, and requirements to be converted.

[0067] This prompt tells the large model that the task it needs to perform is to convert natural language into a structured JSON intermediate representation that conforms to a predefined schema. It also provides a retrieved process template as a reference example, so that the large model can learn from the structure and rules of the existing template during the generation process, thereby improving the quality and consistency of the generated results.

[0068] Sub-step S14: Input the input prompt words into the process parsing agent so that the process parsing agent outputs the intermediate representation of the process in natural language.

[0069] In this embodiment, the constructed input prompt word input flow parsing agent (i.e., the large model fine-tuned by LoRA) can output a structured JSON intermediate representation conforming to a predefined schema based on the natural language requirements in the input prompt words and the retrieved flow template context.

[0070] This intermediate representation can include three core modules: a node list, a connection list, and a hook configuration. The node list describes the type, name, input / output variables, and execution role of each task node; the connection list describes the flow paths and conditional expressions between nodes; and the hook configuration describes the nodes that need to call the smart hook, their corresponding agent types, and the calling method. After output, this intermediate representation can be used for subsequent semantic verification, local repair, and deterministic compilation steps, thus completing the entire conversion process from user natural language to a structured intermediate representation.

[0071] Through the combined steps of fine-tuning constraints, knowledge retrieval, prompt word construction, and model reasoning described above, this application achieves high-quality and highly stable automatic conversion from natural language to intermediate representations of the process, providing reliable structured input for the subsequent executable deployment of the process engine.

[0072] Step 203: Perform local repair and semantic verification on the intermediate representation of the process, and compile the intermediate representation of the process that passes semantic verification into a process definition that can be executed by the process engine; the process definition includes the smart hooks corresponding to each node of the workflow, and the preset smart agents corresponding to the smart hooks. In one embodiment, the step of performing local repair and semantic verification on the intermediate representation of the process may further include the following sub-steps: Sub-step S21: Perform initial semantic verification on the intermediate representation of the process; In this embodiment, semantic verification is performed by the semantic verification module in the core process control layer. This module performs multi-dimensional automated checks on the intermediate representation of the process according to a predefined set of verification rules.

[0073] Semantic validation can include: reachability validation, used to check if there are nodes in the intermediate representation of the process that cannot be reached from the starting node or paths that cannot be reached from the ending node, to prevent the generation of invalid processes with isolated nodes, unreachable branches, or infinite loops; concurrency structure validation, used to check if the branches of the parallel gateway have corresponding merging gateways, to avoid token hanging or repeated triggering due to missing merging of concurrent branches; variable dependency validation, used to check if the input variables of each node have been correctly defined and assigned values ​​in the output variables of its predecessor nodes, to prevent variable not found exceptions from being thrown during process execution due to reading undefined variables; and compensation configuration validation, used to check if the compensation node is... The semantic verification module checks whether corresponding compensable activities and their compensator processors exist and are correctly defined to prevent rollback failures due to missing targets when compensation actions are triggered. It also verifies permissions to check whether the execution roles or candidate processors configured for each node are clearly defined in the enterprise permission system and have the authority to execute tasks for that node, preventing task assignment failures due to incorrect permission configurations during process execution. Finally, it verifies node lifecycle hooks to check whether the agent type specified in the hook configuration is registered and available in the intelligent decision-making and orchestration layer, and verifies the completeness of the hook configuration's invocation method and callback strategy, preventing process failures due to invoking non-existent agents or invalid callback addresses. The semantic verification module checks each of the above verification rules, records all failed verification items and their corresponding node identifiers, connection identifiers, and error types, and generates an initial semantic verification report.

[0074] Sub-step S22: If the initial semantic verification fails, generate a minimum error subgraph based on the semantically erroneous nodes and connections on all executable paths in the intermediate representation of the process; the minimum error subgraph is the error subgraph containing the fewest nodes and connections with the semantically erroneous nodes and connections as its boundary. In the embodiments of this application, if the initial semantic verification fails, that is, if there are one or more semantic errors in the intermediate representation of the process, a minimum error subgraph can be generated based on the nodes and connections of semantic errors on all executable paths in the intermediate representation of the process.

[0075] Specifically, the semantic verification module marks all erroneous nodes and connections from the initial semantic verification report in the graph structure of the intermediate flow representation. Then, using these marked erroneous nodes and connections as boundaries, it defines a subgraph in the flow diagram containing the minimum number of nodes and connections, serving as the minimum error subgraph. This minimum error subgraph covers all nodes and connections directly involved in the error, as well as the necessary connection structures between them, but excludes correct parts unrelated to the error, thus minimizing the scope of repair. By defining the minimum error subgraph, the entire intermediate flow representation is avoided from being fed back to the large model for regeneration, significantly reducing the computational load and generation latency of the large model inference required for subsequent repairs.

[0076] Sub-step S23: Generate repair prompts based on the minimum error subgraph and input the repair prompts into the process parsing agent so that the process parsing agent can perform local repairs on the nodes and connections covered by the minimum error subgraph to obtain the intermediate representation of the process after local repair. In this embodiment, repair prompts can be generated based on the minimum error subgraph, and the repair prompts can be input into the process parsing agent so that the process parsing agent can perform local repairs on the nodes and connections covered by the minimum error subgraph to obtain the partially repaired intermediate representation of the process.

[0077] Specifically, the semantic verification module formats the node list, connection list, hook configuration, and corresponding error type and error location description in the initial semantic verification report contained in the minimum error subgraph according to the predefined repair prompt word template, constructs a repair prompt word containing error context, error cause and repair task, and then inputs the repair prompt word into the process parsing agent.

[0078] After receiving the repair prompt, the process parsing agent calls the large model to regenerate and correct only the nodes and connections covered by the smallest erroneous subgraph, while retaining the other correct parts of the intermediate process representation unchanged. Based on the error description and context information in the repair prompt, the large model outputs the JSON structure of the corrected smallest erroneous subgraph, which has the same schema specification as the original intermediate process representation.

[0079] Through the aforementioned local repair mechanism, this application enables the repair operation to be precisely applied to the erroneous region, avoiding new errors that may be introduced due to global regeneration, while reducing the computational cost of large model inference.

[0080] Sub-step S24 involves performing semantic verification again on the intermediate representation of the process after partial repair.

[0081] In this embodiment, the semantic verification module fills the corrected minimum error subgraph returned by the process parsing agent back into the corresponding position of the original process intermediate representation to form a complete locally repaired process intermediate representation. Then, the same multi-dimensional verification rule set as the initial semantic verification is executed on the complete process intermediate representation to confirm that the original error has been corrected and that the correction process has not introduced new errors.

[0082] If the semantic verification passes again, the process proceeds to the subsequent deterministic compilation step. If the semantic verification fails again, the application repeats the iterative process of defining the minimum error subgraph, generating repair prompts, performing local repair, and re-verifying semantics until the semantic verification passes or the preset retry threshold is reached. When the preset retry threshold is reached and the semantic verification still fails, a process generation failure message can be returned to the user or administrator, along with the current verification report for manual intervention.

[0083] Through the iterative mechanism of initial verification, minimum error subgraph delineation, local repair, and re-verification, this application reduces the dependence on the complete regeneration of the large model while ensuring the correctness of the intermediate representation structure in the process, thereby improving the efficiency and stability of process generation.

[0084] Step 204: During the execution of the workflow by the workflow engine, the context of the workflow execution is collected through the smart hook of the current node, and at least one preset smart agent is invoked to generate smart agent decision results based on the context of the workflow execution. Step 205: Perform multi-agent conflict arbitration on the agent's decision results to obtain the target process execution decision corresponding to the current node of the workflow; In one embodiment, the process of arbitrating multi-agent conflicts to obtain the steps for the target process execution decision corresponding to the current node of the workflow may further include the following sub-steps: Sub-step S31: Obtain the preset rule priority of the workflow; In this application embodiment, the preset rule priority can be a set of mandatory constraints and their sorting rules pre-configured by the system for use as the basis for decision-making in multi-agent conflicts. These may include: security compliance rules (e.g., necessary compliance approval nodes must not be skipped under any circumstances), process integrity rules (e.g., branches of parallel gateways must be fully merged before they can continue), permission constraint rules (e.g., certain sensitive operations can only be performed by specific roles), business priority rules (e.g., approval processes for urgent projects can be accelerated), and system stability rules (e.g., long-term blocking operations are prohibited within the transaction boundary).

[0085] Pre-defined rule priorities can be stored in the configuration center or rule engine of the core process control layer. Different types of rules have a clear priority order to ensure that the arbitration result meets the system's most basic security and compliance requirements. By pre-setting rule priorities, it can be ensured that the arbitration process will not fail due to a lack of judgment basis or output decisions that violate basic business principles under any circumstances, while also making the arbitration result certain and interpretable.

[0086] Sub-step S32: Generate at least one multi-agent conflict graph corresponding to a preset agent based on the agent's decision results; In this embodiment, a multi-agent conflict graph corresponding to at least one preset agent is generated based on the agent decision results returned by each preset agent. Specifically, the conflict arbitration module extracts key attributes from the candidate execution decisions from each agent's decision envelope, such as action type, target node identifier, assignee, process variables to be modified and their values, patch operation content, permission scope, external systems involved, and side effect types. Then, based on the execution context of the current process instance, each candidate decision is used as a node in the conflict graph, and the conflict relationships between candidate decisions on various attributes are used as edges in the conflict graph to construct the multi-agent conflict graph.

[0087] The process of constructing a conflict graph includes: identifying whether two candidate decisions point to different target nodes (one decision requires jumping to node A, and the other requires jumping to node B); whether different values ​​are assigned to the same process variable (one decision sets the risk level to low risk, and the other to high risk); whether different task handlers are assigned (one decision recommends handler A, and the other recommends handler B); whether mutually exclusive patching operations are performed (one decision requires inserting node Y after node X, and the other requires deleting node X or inserting node Z at the same position); whether incompatible permission scopes are involved (one decision requires approval permission, and the other requires financial review permission, but the current user does not have the permission to execute both simultaneously); and whether conflicting external side effects are generated (one decision notifies system A, and the other decision notifies system B, and there is a risk of data inconsistency between the two).

[0088] By constructing the aforementioned conflict graph, this application makes the implicit conflicts between multiple agents explicit and structured, providing a clear panoramic view of the conflicts for subsequent deterministic arbitration.

[0089] Sub-step S33: Based on the multi-agent conflict graph, determine the conflict in the execution decisions of at least one preset agent at the current node; In this embodiment, a conflict in the execution decision of at least one preset agent at the current node can be determined based on the multi-agent conflict graph. Specifically, the conflict arbitration module traverses all edges in the multi-agent conflict graph, identifies and classifies the conflict type and degree between each candidate decision, and divides the conflict into global conflict (two decisions are inconsistent across all comparable dimensions and are completely mutually exclusive) and local conflict (two decisions are inconsistent across one dimension but compatible across other dimensions), as well as hard conflict (violation of preset mandatory rules and must be excluded) and soft conflict (does not violate mandatory rules but has priority differences and can be selected through trade-offs).

[0090] Through the above classification and quantification, this application can accurately define the scope and severity of conflict between candidate decisions, providing a quantitative basis for the final selection based on preset rule priorities and business benefits.

[0091] Sub-step S34: Based on the preset rule priority of the workflow and the conflict between the execution decisions of at least one preset intelligent agent at the current node, determine the target workflow execution decision corresponding to the current node of the workflow.

[0092] In this embodiment, the target process execution decision corresponding to the current node of the workflow can be determined based on the preset rule priority of the workflow and the conflict between the execution decisions of at least one preset intelligent agent at the current node. Specifically, the conflict arbitration module uses the preset rule priority as a filtering condition, first excluding all candidate decisions that violate mandatory rules (e.g., decisions that attempt to skip legally compliant nodes, decisions that attempt to assign tasks to unauthorized personnel, decisions that attempt to modify process variables that are being locked by other transactions), and retaining only candidate decisions that satisfy all preset mandatory constraints as a qualified candidate set.

[0093] In the qualified candidate set, the arbitration module comprehensively scores each candidate decision based on the strength of the evidence chain (the number and quality of the search cases on which the decision is based), confidence (the degree of confidence of the agent in its decision results), action priority (the predefined priority order of different types of actions, such as security-related insertion node operations may take precedence over performance optimization-related routing operations), process security (whether the process is still in an accessible and stable execution state after executing the decision), and business benefits (the degree of improvement expected to be made to key indicators such as process rejection rate, average completion cycle, and resource utilization rate after executing the decision). The candidate decision with the highest comprehensive score is selected as the target process execution decision.

[0094] When two or more candidate decisions have the same overall score, the arbitration module can make a final judgment based on preset tie rules (such as prioritizing candidate decisions with more complete evidence chains, or prioritizing candidate decisions with higher confidence levels, or prioritizing candidate decisions with higher priority of action types), ensuring the uniqueness and certainty of the arbitration result.

[0095] Through the arbitration mechanism based on preset rule priorities and multi-dimensional comprehensive scoring, this application outputs a unique, secure, efficient, and business-rule-compliant target process execution decision in multi-agent collaborative decision-making scenarios, ensuring the consistency of decisions and system stability in multi-agent collaborative scenarios. The target process execution decision determined by arbitration is then passed to the workflow engine for execution, and the conflict diagram and arbitration basis generated during the arbitration process are written to the process log library for subsequent auditing, tracing, and process optimization analysis.

[0096] Step 206: Execute the current node of the decision-making workflow according to the target workflow using the workflow engine; In one embodiment, the operational dimensions of the workflow include at least one of the following: workflow variables, task assignment, workflow routing, and workflow patching. In this embodiment, the operational dimensions of the workflow include at least one of process variables, task assignment, process routing, and process patching. Process variables refer to key-value pair data carried by the workflow instance during execution, used to store business data and process status information, such as application amount, application department, handler identifier, risk level, approval opinion, and attachment storage address. Task assignment refers to determining the execution object of each user task node in the workflow, that is, specifying which individual or group of handlers is responsible for completing the task at that node. Process routing refers to determining the flow branch of the workflow at the gateway node, that is, which subsequent node the workflow instance should flow to next. Process patching refers to the dynamic modification of the workflow structure during workflow execution, such as inserting new nodes, deleting existing nodes, or adjusting the connections between nodes. The above four dimensions correspond to the data layer, personnel layer, path layer, and structure layer in the workflow execution process, respectively, and together constitute the complete operational surface that the workflow engine can control when making execution decisions.

[0097] The process engine executes the current node of the decision-making workflow according to the target process, and may also include the following sub-steps: Sub-step S41 involves using the process engine to execute the process variables of the target process according to the decision-making process, in order to update the business data generated during the current node of the process. In this embodiment, the workflow engine can execute workflow variables according to the target workflow execution decision to update the business data generated during the current node of the workflow. Specifically, when the action type in the target workflow execution decision is to update variables or when other actions include modifying variable parameters, the workflow engine calls the variable setting method (e.g., setVariable) through the workflow engine's execution context interface (e.g., Activiti's DelegateExecution or Camunda's DelegateTask) to write the variable key-value pairs carried in the target workflow execution decision into the variable space of the current workflow instance.

[0098] The updated process variables will affect the subsequent processing logic of the current node (for example, changes in risk scores may alter the information displayed to the processor), and will be collected and persisted by the log collector as part of the process variable snapshot. They can also serve as input data for subsequent gateway condition judgments or agent decisions, thereby ensuring the real-time updating and accurate transmission of business data during process execution.

[0099] Sub-step S42 involves assigning tasks to the workflow according to the target workflow execution decision through the workflow engine, in order to determine the task execution object of the current node of the workflow; In this embodiment, the workflow engine can determine the task execution object of the current node of the workflow by assigning tasks according to the target workflow execution decision. Specifically, when the action type in the target workflow execution decision is assignment, the workflow engine extracts the assignee field from the decision envelope and sets the value of this field as the assignee of the current user task.

[0100] In engine implementations that support candidate users or candidate groups, it is also possible to set a set of candidate users (candidateUsers) or a set of candidate groups (candidateGroups) so that a task can be pushed to one of multiple qualified handlers.

[0101] Through this task assignment mechanism, this application enables the dynamic designation of process participants, allowing task assignment to be based on real-time analysis and recommendation results of intelligent agents rather than pre-fixed roles or personnel, thereby providing greater flexibility and rationality in personnel resource scheduling.

[0102] Sub-step S43: The process engine executes the decision-making process routing of the workflow according to the target process to determine the flow branch of the current node of the workflow; the flow branch is used to indicate the next node of the workflow. In this embodiment, the workflow engine can determine the flow branch of the current node of the workflow by executing the decision according to the target workflow, thereby indicating the next node of the workflow. Specifically, when the action type in the target workflow execution decision is routing (goto), the workflow engine extracts the target node identifier (targetNodeId) from the decision envelope and sets the target node identifier as the next hop node of the current workflow instance, so that the workflow instance jumps to the target node after leaving the current node instead of following the default branch path preset in the workflow definition.

[0103] Through this process routing mechanism, this application enables the flow direction of the process to no longer be limited by the pre-defined condition expressions in the BPMN process definition, but to dynamically change the process direction based on the real-time judgment of the agent during runtime, thereby flexibly responding to business scenarios outside the scope of the preset conditions and enhancing the process's adaptability to uncertainty and emergencies.

[0104] Sub-step S44 involves using the process engine to execute decision-making process patches according to the target process, thereby updating the next node of the workflow.

[0105] In this embodiment, the workflow engine can perform process patching according to the target workflow execution decision to update the next node of the workflow. Specifically, when the action type in the target workflow execution decision is an insert node (insertNode or add_node), the workflow engine starts the process patching execution process, which includes two phases: preparation and submission.

[0106] During the preparation phase, the workflow engine first freezes a snapshot of the current process instance's state, recording the current process version, the token position of the current node, and the complete set of current process variables. Then, it performs joint verification on the patch to be inserted, including: verifying whether the flowchart structure remains reachable and acyclic after patch insertion; whether the data dependencies involved in the patch are satisfied (the input variables of the new node are defined in the output of its predecessor nodes); whether the concurrent tokens affected by the patch are at a transferable safe point; whether the user or agent performing the patch operation has the corresponding permissions; and whether the patch produces the expected side effects on the external system and whether these side effects are acceptable. After successful joint verification, the engine locates the patch insertion anchor point in the flowchart (i.e., after the current node or between specified nodes) and prepares the complete definition of the new node and its associated connections.

[0107] During the commit phase, the workflow engine commits process patches (including the definition of new nodes, inter-node connections, gateway conditions, etc.), process state transitions (moving the current token from the anchor point to the new node's preceding position), and process variable updates (such as passing necessary input variables to the new node) as an atomic transaction to the engine's persistent storage (e.g., the process instance table, task table, and variable table in the database). If the commit phase succeeds, the new node becomes the actual next node in the workflow, and the process instance will subsequently enter that new node to continue execution. If the commit phase fails for any reason (e.g., database write exception, state consistency check failure), the workflow engine immediately performs a rollback based on the snapshot recorded during the preparation phase and the compensation actions in the decision envelope, restoring the process version, token position, task assignment, and process variables to the safe state before patch execution, ensuring that the process instance is never in an inconsistent or incomplete state under any circumstances.

[0108] Through this process patching mechanism, this application realizes the ability to dynamically modify the runtime structure of the workflow, enabling the process to flexibly adjust its node composition and execution path according to runtime business needs without stopping the system or redeploying, fundamentally breaking through the limitation that the traditional BPMN engine process definition cannot be modified once deployed.

[0109] Step 207: Collect the process execution logs corresponding to the target process execution decision, and generate optimization suggestions based on the process execution logs; In one embodiment, the step of generating optimization suggestions based on the process execution log may further include the following sub-steps: Sub-step S51: Based on the process execution log, determine the node data of the current node and previous nodes in the workflow; the node data includes: average node dwell time, node rejection rate, and average completion cycle. In this embodiment, node data for the current and previous nodes of a workflow can be determined based on the workflow execution log. This node data includes the average dwell time, rejection rate, and average completion cycle. Specifically, after the workflow optimization agent is triggered according to a preset time period, it reads the workflow instance records and node records from the workflow log library via a database connection.

[0110] For each node, the process optimization agent calculates the average dwell time of that node across all process instances. The formula is the sum of the dwell times of all instances of that node divided by the total number of instances. Dwell time equals the node's departure time minus its entry time. The agent also calculates the rejection rate of that node, calculated as the number of rejections divided by the total number of arrivals at that node. For each process definition, the process optimization agent calculates the average completion cycle of all complete instances under that process definition, calculated as the sum of the times each instance takes from start to finish divided by the total number of instances. This node data is grouped and aggregated based on process definition identifier, node identifier, and time period, providing a quantitative basis for subsequent bottleneck identification.

[0111] Sub-step S52: Obtain a preset standard line for judging whether node data is normal, and determine candidate abnormal nodes from the node data according to the preset standard line; In this embodiment of the application, the preset standard line is a performance baseline pre-configured by the system, including the time baseline of the average dwell time of the node (e.g., 2 days) and the quality baseline of the node rejection rate (e.g., 20%). The standard line can be configured differently according to different process types, different business scenarios and different time periods.

[0112] The process optimization agent can compare the average dwell time of each node with the time consumption baseline and the rejection rate with the quality baseline. When any indicator exceeds the corresponding preset standard, the node is marked as a candidate abnormal node. Through the threshold triggering mechanism of the preset standard, this application realizes the automatic screening of bottleneck nodes, avoiding the inefficiency of manual node-by-node inspection.

[0113] Sub-step S53: Extract the rejection history instances under the candidate exception nodes and the process variables of the rejection history instances from the process execution log; In this embodiment, rejection history instances under candidate exception nodes and process variables of the rejection history instances can be extracted from the process execution log. Specifically, for each candidate exception node, the process optimization agent queries the process log library for all historical instance records under that node with a rejection flag of 1 (i.e., rejected), and extracts a snapshot of the process variables of each rejection instance when it reaches that node.

[0114] Process variable snapshots can include structured fields such as application amount, application department, attachment upload status, risk score, task priority, and business type. These fields record the full picture of the business status of the instance when rejection occurs.

[0115] Sub-step S54: Based on the combination of values ​​of process variables and the rejection results of rejection history instances, determine the support and confidence of each combination of values ​​of process variables in the rejection history instances. In this embodiment, the support and confidence of each process variable's value combination in the rejection history instances can be determined based on the combination of process variable values ​​and the rejection results of rejection history instances. Specifically, the process optimization agent can employ an association rule mining algorithm (such as the Apriori algorithm or the FP-Growth algorithm) to treat each rejection history instance as a transaction, and the specific value combinations of each process variable in that instance as itemsets in the transaction. Then, frequent itemset mining is performed on the itemsets of all rejection instances.

[0116] For each combination of variable values ​​mined, the support is defined as the proportion of rejection instances containing that combination to the total number of rejection instances, reflecting the prevalence of that combination among rejection instances; the confidence is defined as the proportion of rejections among instances containing that combination, reflecting the conditional probability relationship between that combination and rejection.

[0117] Sub-step S55: The combination of process variables whose support is greater than the preset support threshold and whose confidence is greater than the preset confidence threshold is used as the process variable combination related to rejection. In this embodiment, a combination of process variables whose support is greater than a preset support threshold and whose confidence is greater than a preset confidence threshold can be used as a combination of process variables related to rejection. The preset support threshold and preset confidence threshold can be configured by the system administrator according to the business scenario. In one implementation, the support threshold can be set to 0.05 (i.e., the combination appears in at least 5% of rejection instances), and the confidence threshold can be set to 0.65 (i.e., at least 65% of instances containing the combination are rejected).

[0118] By using this threshold screening, this application excludes variable combinations that are co-occurring by chance or have insufficient sample size, and retains only combinations that are statistically significant and related to rejection, as structured evidence input for subsequent root cause analysis.

[0119] Sub-step S56 involves performing root cause analysis on the candidate abnormal nodes and combinations of process variables to obtain optimization suggestions.

[0120] In this embodiment, root cause analysis can be performed on candidate abnormal nodes and combinations of process variables related to rejection to obtain optimization suggestions. Specifically, the process optimization agent formats the structured statistical results of candidate abnormal nodes, such as process definition identifiers, node identifiers, average time consumption, rejection rate, rejection reason distribution, and combinations of process variables related to rejection, according to a predefined prompt word template to construct prompt words containing complete bottleneck data, and then calls the large model via HTTP API to perform root cause analysis.

[0121] Based on the statistical data and variable combinations in the prompt words, the large model outputs 2 to 3 specific and actionable optimization suggestions, such as "Add attachment integrity verification at the application node, because 70% of the rejection cases have the combined characteristics of attachments not being uploaded and the amount being greater than 50,000 yuan".

[0122] The process optimization agent parses the text returned by the large model using regular expressions or structured extraction rules, extracts optimization suggestions, and records each suggestion as a structured optimization form containing a process definition identifier, suggestion content, action type, expected effect, and confidence score. This optimization suggestion can then be used to update the prompts of the process parsing agent or the decision rules of the preset agent, thus forming a complete closed loop from log collection, bottleneck location, correlation mining to root cause analysis and optimization suggestion generation.

[0123] Step 208: Convert the optimization suggestions into static rules and update the rule base of the process parsing agent through static rules; and / or, convert the optimization suggestions into prompt word patches and update the prompt word instruction set of the process parsing agent and the preset prompt word instruction set of the agent for the next node of the execution workflow through prompt word patches.

[0124] In this embodiment, the process optimization agent can statistically analyze the frequency of decision suggestions from similar agents. When this frequency exceeds a preset threshold (e.g., 70%) and meets screening criteria such as sample size, confidence level, effect gain, drift degree, and conflict degree, the suggestion is identified as a candidate rule, generating a structured JSON rule entry. After passing historical playback verification and gray-scale verification, the JSON rule entry is written into the rule engine relied upon by the process parsing agent. This allows subsequent process parsing agents to directly generate the corresponding process structure based on the static rule without calling a large model when parsing natural language requirements containing the same conditions, thereby reducing the number of repeated large model calls and inference waiting time. When a fixed rule causes anomalies or a decrease in effect during gray-scale execution, it can be automatically rolled back to the previous version.

[0125] The process optimization agent can also obtain the system prompt words currently used by the target agent from the configuration center, call the large model to generate instruction-style prompt word difference patches based on optimization suggestions. The patch describes the specific prompt word constraints that need to be added, deleted or modified. The difference patch is applied to the original prompt words to generate a new version and published to the configuration center of the target agent, so as to achieve precise adjustment of the behavior logic of the process parsing agent or the preset agent of the next node.

[0126] In one embodiment, the step of resolving the agent through the static rule update process may further include the following sub-steps: Sub-step S61: Determine the frequency of occurrence of candidate rules for the same preset agent in the static rules; static rules are the condition judgment logic directly executed by the process engine. Sub-step S62: If the frequency of occurrence of a candidate rule exceeds a preset threshold, the candidate rule is written into the rule base of the process parsing agent.

[0127] In this embodiment of the application, static rules refer to condition judgment logic that can be directly executed by the process engine or rule engine. They are described in a structured format (e.g., JSON condition-action pairs) and can be matched and triggered without calling a large model.

[0128] The candidate rules are derived from similar optimization suggestions repeatedly generated by the process optimization agent in historical log analysis. For example, the risk assessment agent outputs the structured suggestion of "adding a financial review node" in multiple large-scale procurement approvals.

[0129] The process optimization agent can count the number of times each candidate rule appears in historical decision records according to a preset period and calculate its frequency. The frequency is calculated by dividing the number of times the decision suggestion corresponding to the candidate rule appears by the total number of decisions in similar business scenarios. The frequency reflects the general applicability and recurrence probability of the candidate rule in actual business scenarios and is the primary quantitative indicator for determining whether it is worthwhile to solidify it into a static rule.

[0130] For example, the preset threshold can be 70%. When the frequency of occurrence of a candidate rule exceeds this threshold, it indicates that the decision pattern corresponding to the rule is repeating frequently. Maintaining it as a dynamic AI reasoning method will lead to a large number of repeated large model calls, causing unnecessary waste of computing resources and inference delays.

[0131] Therefore, the candidate rule can be compiled into a static condition-action pair and written into the rule base on which the process parsing agent depends. When a subsequent process instance encounters a business scenario that meets the condition of the rule, the process parsing agent or the rule engine directly matches and executes the rule, without calling the large model for real-time reasoning.

[0132] Through the aforementioned frequency statistics and threshold triggering mechanisms, a data-driven transformation from dynamic AI decision-making to deterministic static rules is achieved. This effectively reduces the number of repeated calls to large models and inference waiting time while ensuring decision quality. Before writing candidate rules into the rule base, multi-dimensional screening can be performed, including sample size verification, confidence assessment, effect gain prediction, drift detection, and conflict checks, to ensure that the static rules written into the rule base have sufficient statistical significance and business effectiveness. Static rules written into the rule base support canary-scale verification and automatic rollback. When a rule produces anomalies or a decline in effect during canary-scale execution, it can be automatically removed from the rule base or marked as disabled to control the impact of erroneous rules and ensure the continuous reliability of the rule base.

[0133] In one embodiment, the step of converting the optimization suggestion into a prompt word patch may further include the following sub-steps: Sub-step S71: Obtain the preset prompts for the process parsing agent and the preset agent for the next node of the workflow, as well as the historical requirements of the workflow; Sub-step S72: Generate candidate prompt word patches based on optimization suggestions and preset prompt words; Sub-step S73: Verify the candidate suggestion patch in the sandbox environment based on the historical requirements of the workflow; Sub-step S74: The verified candidate prompt word patch is used as the prompt word patch.

[0134] In this embodiment, the preset prompt words refer to the system-level instruction text currently being used by the process parsing agent or each preset agent. These are stored in the configuration center and used to guide the agent on how to convert natural language requirements into intermediate process representations or how to execute specific decision-making tasks. The historical requirements of the workflow refer to samples of natural language requirements that have successfully generated correct intermediate process representations in the past, along with their corresponding correct intermediate process representations. These samples are stored in the process log library or training dataset for subsequent sandbox validation.

[0135] After obtaining the complete text of the preset prompts, the process optimization agent takes the behavioral adjustments involved in the optimization suggestions (such as "when generating the procurement process, attachments should be required to be uploaded and their integrity verified by default") as the modification targets, calls the large model or the dedicated prompt optimization model, and generates an instruction-style prompt difference patch. This patch can use an instruction language to describe the specific operations of adding, deleting or modifying the existing preset prompts.

[0136] The process optimization agent applies candidate prompt word patches to preset prompt words, generates modified new prompt words, and then uses the historical requirements of the workflow as test input to call the process parsing agent or the target preset agent to regenerate the intermediate representation or decision result of the process based on the modified new prompt words. It checks whether the output result meets the expected behavior change of the optimization suggestion (e.g., whether the output contains an attachment integrity verification node) and whether the output still maintains the original functional correctness (e.g., the original approval chain configuration has not been lost due to the modification).

[0137] When a candidate prompt patch passes all test cases in the sandbox environment (i.e., the modified prompt achieves the expected behavior adjustment without breaking the original function), the candidate prompt patch is officially confirmed as a prompt patch, which can be used for subsequent deployment to the configuration center of the process parsing agent or the preset agent, and a change log is recorded for version traceability and exception rollback.

[0138] Through the above steps of acquisition, generation, verification, and confirmation, this application achieves secure and controllable management of prompt word changes, ensuring that only verified prompt word modifications can be implemented online, effectively reducing the risk of prompt word changes introducing new errors.

[0139] This application's embodiments enable business personnel without technical backgrounds to directly express business process intent without learning BPMN modeling languages ​​or process design tools, significantly reducing the usage threshold and communication costs of process modeling. By using a process parsing agent to convert natural language into an intermediate process representation, it achieves a leap from human-readable business descriptions to machine-understandable formal representations. Proactively identifying and intercepting process structure errors before deployment improves the reliability of process generation. The verified intermediate process representation is compiled into an executable process definition for the process engine, improving the accuracy of the conversion from natural language to an executable process model. Intelligent hooks embedded in the node lifecycle collect the execution context of the current process instance in real time and call preset agents to generate intelligent decision results based on this context, improving the intelligent perception and adaptive capabilities during process runtime. Simultaneously, different nodes can be pre-configured to call different types of agents, achieving on-demand and precise deployment of intelligent capabilities. When multiple agents collaborate on decision-making, conflict identification and arbitration are performed on the candidate decision results returned by each agent, reducing the problem of conflicting candidate actions in multi-agent collaborative scenarios. The process engine executes corresponding operations on the current node according to the arbitrated target process execution decision. This allows the intelligent decision results to drive the engine's actual behavior, avoiding the risks of inconsistencies or concurrent conflicts caused by external systems directly modifying engine data. By collecting process execution logs corresponding to the target process execution decisions and generating optimization suggestions based on these logs, the process can be continuously optimized as business changes occur, preventing the misapplication of outdated decisions and the solidification of erroneous rules.

[0140] In one embodiment, the workflow execution optimization method of this application can adopt a three-layer collaborative architecture, including: an intelligent decision-making and orchestration layer, a core process control layer, and a knowledge enhancement and optimization layer. The intelligent decision-making and orchestration layer is used to deploy multiple dedicated intelligent agents (process parsing, task assignment, risk assessment, and process optimization), providing a unified REST API for lower layers to call. The intelligent agents collaborate through the orchestration capabilities of the Dify platform. The core process control layer is built on the Activiti engine and adds three extension modules: an intelligent hook module, which intercepts and calls upper-layer intelligent agents during the node lifecycle; a dynamic process definition parser, which receives and deploys the BPMN model generated by the upper layer; and a log collector, which persists the execution trajectory to a log library. The knowledge enhancement and optimization layer includes an enterprise knowledge base (for RAG retrieval enhancement) and a process log library (for offline analysis of optimized intelligent agents).

[0141] The data flow between the three layers is as follows: user natural language input, the first layer generates the BPMN model, the second layer deploys and executes it, during execution, the first layer obtains real-time decisions through smart hooks, the execution log flows into the third layer, the third layer periodically analyzes and feeds back the optimization results to the first layer.

[0142] Furthermore, the core process control layer is not limited to the Activiti engine. Workflow engines that support business process modeling and execution standards (such as BPMN 2.0, XPDL, etc.) can be used as alternatives, for example: Flowable: As a branch of Activiti, it has a highly compatible API and can be directly replaced. The implementation of smart hooks is similar, requiring only adjustments to the corresponding listener class name and configuration.

[0143] Camunda BPM: Also based on BPMN 2.0, it provides a powerful REST API and event mechanism, and can implement smart hooks through its DelegateTask and ExecutionListener interfaces.

[0144] jBPM: Red Hat's open-source workflow engine, supports BPMN 2.0, and can be used to integrate agent calls using its WorkItemHandler mechanism.

[0145] Self-developed lightweight process engine: For specific scenarios, a transactional process engine containing only the core state machine can also be developed, as long as it can realize the flow of tasks and the persistence of states, and reserve extension points at key nodes.

[0146] Furthermore, the intelligent decision-making and orchestration layer is not limited to the Dify platform; any system capable of creating, orchestrating, and running large model agents can be used for implementation, for example: LangChain + LangServe: Utilize LangChain to build dedicated intelligent agents, deploy RESTful API services through LangServe, and interact with the workflow engine.

[0147] AutoGen: Microsoft's open-source intelligent agent framework that supports multi-agent collaboration. It can simulate the decision-making process through its UserProxy and Assistant agents and exposes HTTP interfaces for external calls.

[0148] Semantic Kernel: Microsoft's lightweight SDK that supports combining large models with traditional programming languages. It can be embedded in the workflow engine process for direct invocation, reducing network latency. Enterprise-level AI platforms: such as Baidu Wenxin Qianfan and Alibaba Lingjie, provide model service and agent orchestration capabilities, and can be directly connected to their APIs.

[0149] Completely self-developed: Based on open-source large models (such as Llama and ChatGLM), we can deploy and fine-tune them ourselves, and use FastAPI to encapsulate them into services, which can also achieve the functions described in this invention.

[0150] Furthermore, the communication method between the smart hook and the smart agent can be flexibly selected according to real-time requirements and system architecture, for example: Synchronous HTTP calls (RESTful API): As described in the preferred embodiment, this is suitable for scenarios with high real-time requirements, where decision results are returned immediately and the process continues to execute.

[0151] Asynchronous message queues: Utilizing message middleware such as RabbitMQ and Kafka, smart hooks publish decision requests to the queue. The agent service consumes these requests, processes them asynchronously, and writes the results to a callback queue or updates the database. The engine retrieves the results through polling or listening. This approach is suitable for scenarios with long decision-making times or high concurrency, avoiding blocking engine threads.

[0152] gRPC calls: For internal systems with higher performance requirements, the gRPC protocol can be used to achieve low-latency decision communication by leveraging its efficient serialization and bidirectional streaming characteristics.

[0153] In-process function calls: If the agent and the workflow engine are deployed in the same process space (e.g., using the Semantic Kernel), they can communicate directly through method calls without network overhead.

[0154] Furthermore, the knowledge base storage and retrieval technologies upon which the knowledge enhancement layer relies can be implemented in various ways, such as: Vector databases: In addition to FAISS, dedicated vector databases such as Milvus, Qdrant, Weaviate, and Pinecone can also be used, supporting distributed storage and massive data retrieval.

[0155] Traditional search engines: use Elasticsearch's BM25 algorithm for keyword retrieval, combine it with an inverted index to achieve fast retrieval, and then use a large model to rearrange the candidate results.

[0156] Hybrid retrieval: Combining vector retrieval and keyword retrieval leverages their strengths and compensates for their weaknesses to improve recall accuracy. Examples include using Elasticsearch's kNN plugin or Alibaba Cloud's OpenSearch.

[0157] Graph databases: For scenarios that require reasoning about related knowledge (such as corporate organizational structure and product relationships), graph databases such as Neo4j can be used to store knowledge graphs, and agents can obtain structured knowledge through graph query languages ​​(such as Cypher).

[0158] Furthermore, the process definitions generated by the process parsing agent are not limited to the BPMN XML format, but may also include: JSON format: Lightweight JSON is used to describe the process structure (such as node list, connection line, gateway conditions), and then a custom parser is used to convert it into an internal model that the engine can recognize.

[0159] DSL script: Defines a domain-specific language (DSL) to describe business processes, such as a Python-like script, which is compiled into an executable process by a parser.

[0160] Direct API manipulation: The agent does not generate model files, but instead directly calls the workflow engine's API to dynamically create process instances and add task nodes, such as dynamically starting sub-processes via RuntimeService. However, this method is more complex and suitable for simple processes.

[0161] Process fragment combination: Commonly used process fragments (such as approval chains and countersigning blocks) are predefined as templates. Intelligent agents can generate complete processes by combining these templates, thereby improving generation efficiency and stability.

[0162] Reference Figure 3 The diagram illustrates a logic diagram of a workflow execution optimization method provided in an embodiment of this application. To enable those skilled in the art to better understand the embodiments of this application, the following explanation is provided... Figure 3 The embodiments of this application are described below.

[0163] Step 301, Data Collection and Preprocessing.

[0164] In this embodiment, the process optimization agent is triggered at a preset time period (e.g., 02:00 AM daily) and reads all process instance records from the previous period in the process log database via a JDBC connection. Each log record includes at least: process instance ID, process definition ID, start time, end time; node ID, node type (user task / service task / gateway), entry time, exit time, handler ID, rejection flag (Y / N), rejection reason (if any); snapshot of process variables (e.g., application amount, department, risk score, etc.); agent decision record (which agent was called, input / output summary, and time consumed).

[0165] The data preprocessing process is as follows: Calculate the average dwell time for each node (avg_dwell = SUM(departure time - entry time) / number of instances). Calculate the rejection rate for each node (reject_rate = number of rejections / number of arrivals). Calculate the average cycle time for each process definition (avg_cycle = SUM(end time - start time) / number of instances). Group and aggregate data by process definition ID, node ID, and time period (day / week / month).

[0166] The implementation and orchestration of intelligent agents are as follows: Based on the Dify platform, multiple dedicated agents are created, each consisting of a prompt, a knowledge base, and tools.

[0167] The process parsing agent is guided by prompts to convert natural language into BPMN XML. The knowledge base stores commonly used process fragments (such as standard approval chains and countersigning models) for reuse. For tools, BPMN model validation tools can be called to ensure the generated XML syntax is correct. Risk assessment agent: Input includes current process business data and attachment summaries; outputs risk level and corresponding handling suggestions (such as adding a review node). This agent utilizes a risk case database in the knowledge base for enhanced retrieval: 1. Risk quantification and scoring: a weighted sum of three factors—amount risk, historical case matching degree, and keyword risk; 2. Risk level classification: low risk, medium risk, and high risk; 3. Handling suggestion generation: inputting the risk level, high-risk factors (e.g., exceeding the amount limit), and historical handling methods of recalled cases into the large model, outputting structured suggestions: add a review node, change the approver, or focus on reviewing a specific attachment.

[0168] Task assignment agent: Based on task content, personnel skill tags, current workload, and other information, recommends the most suitable person to handle the task. Real-time data can be obtained by calling the enterprise's human resources system API: 1. Capability matching degree; 2. Real-time workload assessment; 3. Comprehensive recommendation score, selecting the person with the highest score; 4. Outputting the recommender ID, score, and reason (e.g., "Capability matching 0.9, current workload is relatively light").

[0169] Step 302, Bottleneck Analysis and Root Cause Locator.

[0170] In this embodiment, the statistical results of the intelligent agent after preprocessing are optimized, and a large model (LLM) is invoked for multi-dimensional analysis. The specific analysis logic includes: threshold triggering, setting a performance baseline (e.g., average node latency > 2 days or rejection rate > 20%), and marking nodes exceeding the threshold as candidate bottlenecks; association rule mining, using SQL queries to find combinations of process variables strongly correlated with rejection; and large model root cause analysis, constructing prompt words from the above statistical results (including specific values ​​and sample instance process variables) and inputting them into the large model.

[0171] The optimization agent formats the statistical results according to a predefined prompt word template (containing five fields: process definition ID, bottleneck node, average time, rejection rate, and rejection reason distribution), calls the large model service via HTTP API, and parses the returned results according to predefined regular expression rules to extract optimization suggestion items.

[0172] Step 303: Generation of optimization suggestions.

[0173] In this embodiment, the suggestions output by the large model are unstructured text, and the optimization agent is responsible for converting them into executable optimization instructions. The optimization agent records each generated optimization suggestion as a structured optimization sheet, which includes: process definition ID, suggestion content, action type, expected effect (e.g., "expected rejection rate to drop below 10%), and confidence score (self-evaluated by the large model).

[0174] Step 304: Automatically adjust the prompts for the process parsing agent.

[0175] In this embodiment, when the action type of the optimization suggestion is `modify_prompt`, the optimization agent performs the following steps: locating the prompt word, generating a patch, verifying, and deploying. Specifically, the system prompt text used by the current process parsing agent is obtained from the configuration center. This prompt word guides the agent on how to convert user natural language requirements into a BPMN model. A large model (which can be the same model or a dedicated prompt word optimization model) is called to generate a difference patch for the prompt word. The new prompt word is tested in a sandbox environment (e.g., regenerating the process for 10 historical requirements to check if it includes attachment verification nodes). After successful testing, the new prompt word version is published to the configuration of the process parsing agent, and a change log is recorded.

[0176] Step 305: Automatically adjust the dynamic assembly logic.

[0177] In this embodiment, when the optimization suggestion involves structural modifications to a process segment, the optimization agent can adjust the dynamic assembly logic within the process parsing agent. This logic is essentially a set of "intent-template" mapping rules or a lightweight decision tree. Adjustment methods include rule base updates and template library enhancements. Rule base updates involve the optimization agent generating new JSON rule entries and inserting them into the rule engine relied upon by the process parsing agent; these rules will be automatically applied when parsing similar requirements later. Template library enhancement involves adding the optimized complete BPMN segment to the template library and tagging the template. The process parsing agent can prioritize retrieving the template based on keywords in the user description during generation.

[0178] This application uses an intelligent procurement approval process as an example. The example workflow is as follows: Suppose a company uses this system to process purchase requests. Employee Zhang submits a purchase request stating: "Request to purchase 10 laptops, total budget 80,000 yuan, supplier: XX Company. Due to the urgency of the project, approval is required as soon as possible." He also uploaded a price quote as an attachment.

[0179] 1. Dynamic Process Generation: The user inputs a natural language request. After receiving the request, the process parsing agent, combined with the company's procurement policy knowledge base, generates the following BPMN process definition (simplified description): Start; User task "Fill out the purchase order" (already completed by Xiao Zhang); Smart gateway (routes based on factors such as amount and department); If the amount is <50,000, manager approves; If the amount is >=50,000, director approves; If the department is IT, CTO approval is also required; End.

[0180] Meanwhile, smart hooks were configured at the "Manager Approval" and "Director Approval" nodes to invoke the "Risk Judgment Smart Agent" and the "Task Assignment Smart Agent".

[0181] 2. Process Instance Startup: The system automatically deploys the process definition and starts the instance, passing Zhang's application content as a process variable.

[0182] 3. Task Assignment: The process reaches the "Manager Approval" node. A smart hook is triggered, collecting context (amount 80,000, attachment summary "quotation shows unit price 8,000 yuan"), and invoking the task assignment agent. Based on the handler's skills and current workload, the agent recommends manager "Li Si" and returns the result. The engine assigns the task to Li Si.

[0183] 4. Risk Assessment: When Li Si approves the application, he clicks "Approve," triggering a smart hook that invokes the risk assessment agent. Following the process described in Section 3 above—"Vector Retrieval → Multi-dimensional Risk Scoring (R_total = 0.4×R_amount + 0.4×R_cases + 0.2×R_keyword) → Risk Level Determination → Recommendation Generation"—this agent calculates R_total = 0.74 (high risk) and outputs the recommendation "Add a Financial Review Node." Based on this result, the engine dynamically inserts a "Financial Review" task into the process and assigns it to finance specialist Wang Wu.

[0184] 5. Self-Optimization: One week later, the process optimization agent extracts all 120 procurement instances (amount > 50,000 RMB) from the log database within the last 30 days. The proportion of instances where the risk assessment agent suggested "adding financial review" is calculated as P = 96 / 120 = 0.8. With a preset threshold T = 0.7, P ≥ T satisfies the trigger condition. Further comparison reveals that the rejection rate for instances without a recommendation to add review is 35%, while the rejection rate for instances with a recommendation is only 8%, indicating the effectiveness of the recommendation. The update_rule action is triggered, writing the rule "Amount > 50,000 RMB, automatically add financial review" into the rule base of the process parsing agent.

[0185] This application uses an intelligent customer complaint handling process as an example. The example workflow is as follows: The difference between the intelligent customer complaint handling process and the intelligent procurement approval process is that the application scenario changes from procurement approval to customer complaint handling; the intelligent agent type is replaced with "problem attribution intelligent agent" and "compensation plan intelligent agent"; and the knowledge base content is switched from the procurement policy database to the customer service knowledge base and product fault database.

[0186] The user inputs natural language: "Mr. Wang, the customer, complained about product quality issues and requested compensation. Order number 12345." The process parsing agent generates a BPMN process containing four nodes: "Acceptance, Investigation, Negotiation, and Compensation." Smart hooks are configured in the "Investigation" and "Negotiation" nodes to specify the invocation of the "Problem Attribution Agent" and the "Compensation Solution Agent," respectively.

[0187] When the process reaches the "Investigation" node, the smart hook submits the complaint description text ("Product Quality Issue") to the problem attribution agent. This agent retrieves similar failure cases (such as "Batch A Product Overheating Failure") from the product failure database through vector retrieval, outputs a list of possible failure causes and their confidence levels, and writes the investigation conclusions into process variables for use in subsequent negotiation nodes.

[0188] When the process reaches the "negotiation" stage, the compensation solution agent reads the investigation results and customer information (obtaining the customer level from the CRM system via the order number), and combines the customer level (high-value customer, preferring a fast compensation plan) and the severity of the fault (serious fault, replacement preferred), to output a structured compensation suggestion (such as "suggest replacement and compensation with coupons"). The engine pushes the suggestion to customer service personnel, who then confirm and execute it.

[0189] The process optimization agent, while analyzing logs, discovered that the average processing time for complaints from high-value customers was 60% longer than for ordinary customers. Further analysis revealed that the compensation scheme agent had a larger list of alternative solutions for high-value customers. The optimization agent triggered a `modify_prompt` action, modifying the prompt text for the compensation scheme agent and adding the constraint: "For high-value customers, prioritize outputting the most efficient solution, reducing the number of candidate solutions." The modified prompt text was then tested in a sandbox before being deployed online.

[0190] This application's embodiments address the system scalability issue of requiring different parsing codes for different AI services by using a unified data structure. Through a two-stage transformation and the introduction of intermediate representations, it solves the problem of excessively high syntax error rates when directly generating XML. Employing a single-threshold triggering mechanism based on statistical frequency enables lighter and faster automatic rule solidification, reducing reliance on repeated calls to large models.

[0191] It should be noted that the workflow execution optimization method provided in this application embodiment can be executed by a workflow execution optimization device, or a control module in the workflow execution optimization device for executing the loading workflow execution optimization method. This application embodiment uses the execution of the loading workflow execution optimization method by a workflow execution optimization device as an example to illustrate the workflow execution optimization method provided in this application embodiment.

[0192] Reference Figure 4 This diagram illustrates a structural block diagram of a workflow execution optimization apparatus provided in an embodiment of this application. The apparatus includes: Natural language acquisition module 401 is used to acquire the user's natural language; the natural language is used to describe the workflow required by the user. The intermediate representation conversion module 402 is used to convert the natural language into an intermediate representation of the process through the process parsing agent; The semantic verification and repair module 403 is used to perform local repair and semantic verification on the intermediate representation of the process, and compile the intermediate representation of the process that passes semantic verification into a process definition that can be executed by the process engine; the process definition includes smart hooks corresponding to each node of the workflow, and preset smart agents corresponding to the smart hooks. The decision result generation module 404 is used to collect the context of the workflow execution through the smart hook of the current node during the execution of the workflow by the process engine, and call at least one of the preset smart agents to generate smart agent decision results based on the context of the workflow execution. The decision conflict arbitration module 405 is used to perform multi-agent conflict arbitration on the decision results of the intelligent agent to obtain the target process execution decision corresponding to the current node of the workflow; The target decision execution module 406 is used to execute the current node of the workflow according to the target workflow execution decision through the workflow engine; The optimization suggestion generation module 407 is used to collect the process execution log corresponding to the target process execution decision, and generate optimization suggestions based on the process execution log; the optimization suggestions are used to update the process parsing agent and / or the preset agent for executing the next node of the workflow.

[0193] In one embodiment, the intermediate representation conversion module 402 includes: The analytical model fine-tuning submodule is used to fine-tune and constrain the parameters of the process parsing agent so that the process parsing agent learns the mapping rules from natural language to intermediate process representation; The process template retrieval submodule is used to retrieve target process templates that match the natural language from a preset knowledge base; The input prompt word generation submodule is used to generate input prompt words based on the target process template and the natural language. The intermediate representation output submodule is used to input the input prompt words into the process parsing agent, so that the process parsing agent outputs the intermediate representation of the process in the natural language.

[0194] In one embodiment, the semantic verification and repair module 403 includes: The initial semantic verification submodule is used to perform initial semantic verification on the intermediate representation of the process; The error subgraph generation submodule is used to generate a minimum error subgraph based on the semantically erroneous nodes and connections on all executable paths in the intermediate representation of the process when the initial semantic verification fails. The minimum error subgraph is the error subgraph containing the fewest nodes and connections with the semantically erroneous nodes and connections as its boundary. The subgraph local repair submodule is used to generate repair prompt words based on the minimum erroneous subgraph, and input the repair prompt words into the process parsing agent, so that the process parsing agent can perform local repair on the nodes and connections covered by the minimum erroneous subgraph to obtain the partially repaired intermediate representation of the process; The semantic verification submodule is used to perform semantic verification on the intermediate representation of the process after partial repair.

[0195] In one embodiment, the decision conflict arbitration module 405 includes: The priority acquisition submodule is used to acquire the preset rule priority of the workflow; The conflict graph generation submodule is used to generate at least one multi-agent conflict graph corresponding to the preset agent based on the agent's decision results. The current conflict determination submodule is used to determine, based on the multi-agent conflict graph, a conflict in the execution decisions of at least one of the preset agents at the current node. The execution decision determination submodule is used to determine the target process execution decision corresponding to the current node of the workflow based on the preset rule priority of the workflow and the conflict of execution decisions of at least one preset intelligent agent at the current node.

[0196] In one embodiment, the operational dimensions of the workflow include at least one of: process variables, task assignment, process routing, and process patching; the target decision execution module 406 includes: The process variable execution submodule is used to execute the process variables of the workflow according to the target process execution decision through the process engine, so as to update the business data generated during the current node of the workflow. And / or, The task assignment and execution submodule is used to execute the task assignment of the workflow according to the target workflow execution decision through the workflow engine, so as to determine the task execution object of the current node of the workflow; And / or, The process routing execution submodule is used to execute the process routing of the workflow according to the target process execution decision through the process engine, so as to determine the flow direction branch of the current node of the workflow; the flow direction branch is used to indicate the next node of the workflow; And / or, The process patch execution submodule is used to execute process patches of the workflow according to the target process execution decision through the process engine, so as to update the next node of the workflow.

[0197] In one embodiment, the optimization suggestion generation module 407 includes: The node data determination submodule is used to determine the node data of the current node and previous nodes of the workflow based on the process execution log; the node data includes: average node dwell time, node rejection rate, and average completion cycle; The abnormal node determination submodule is used to obtain a preset standard line for judging whether the node data is normal, and to determine candidate abnormal nodes from the node data according to the preset standard line. The rejection instance extraction submodule is used to extract the rejection history instances under the candidate abnormal nodes and the process variables of the rejection history instances from the process execution log; The process variable calculation submodule is used to determine the support and confidence of each process variable value combination in the rejection history instance based on the value combination of the process variable and the rejection result of the rejection history instance. The variable combination determination submodule is used to combine the values ​​of process variables whose support is greater than the preset support threshold and whose confidence is greater than the preset confidence threshold as process variable combinations related to rejection. The optimization suggestion generation submodule is used to perform root cause analysis on the candidate abnormal nodes and the combination of process variables to obtain the optimization suggestions.

[0198] In one embodiment, the device further includes: The rule base conversion and update module is used to convert the optimization suggestions into static rules and update the rule base of the process parsing agent through the static rules. And / or, The prompt word conversion and update module is used to convert the optimization suggestions into prompt word patches, and update the prompt word instruction set of the process parsing agent and the prompt word instruction set of the preset agent for executing the next node of the workflow through the prompt word patches.

[0199] In one embodiment, the rule base conversion and update module includes: The candidate rule determination submodule is used to determine the frequency of occurrence of candidate rules for the same preset intelligent agent in the static rules; the static rules are the condition judgment logic directly executed by the process engine. The rule base update submodule is used to write the candidate rule into the rule base of the process parsing agent when the occurrence frequency of the candidate rule exceeds a preset threshold.

[0200] In one embodiment, the prompt word conversion and update module includes: The historical requirements acquisition submodule is used to acquire the preset prompt words of the process parsing agent and the preset agent for executing the next node of the workflow, as well as the historical requirements of the workflow. The prompt word patch generation submodule is used to generate candidate prompt word patches based on the optimization suggestions and the preset prompt words; The prompt word patch verification submodule is used to verify the candidate prompt word patches in a sandbox environment based on the historical requirements of the workflow; The prompt word update submodule is used to use the verified candidate prompt word patch as the prompt word patch.

[0201] This application's embodiments enable business personnel without technical backgrounds to directly express business process intent without learning BPMN modeling languages ​​or process design tools, significantly reducing the usage threshold and communication costs of process modeling. By using a process parsing agent to convert natural language into an intermediate process representation, it achieves a leap from human-readable business descriptions to machine-understandable formal representations. Proactively identifying and intercepting process structure errors before deployment improves the reliability of process generation. The verified intermediate process representation is compiled into an executable process definition for the process engine, improving the accuracy of the conversion from natural language to an executable process model. Intelligent hooks embedded in the node lifecycle collect the execution context of the current process instance in real time and call preset agents to generate intelligent decision results based on this context, improving the intelligent perception and adaptive capabilities during process runtime. Simultaneously, different nodes can be pre-configured to call different types of agents, achieving on-demand and precise deployment of intelligent capabilities. When multiple agents collaborate on decision-making, conflict identification and arbitration are performed on the candidate decision results returned by each agent, reducing the problem of conflicting candidate actions in multi-agent collaborative scenarios. The process engine executes corresponding operations on the current node according to the arbitrated target process execution decision. This allows the intelligent decision results to drive the engine's actual behavior, avoiding the risks of inconsistencies or concurrent conflicts caused by external systems directly modifying engine data. By collecting process execution logs corresponding to the target process execution decisions and generating optimization suggestions based on these logs, the process can be continuously optimized as business changes occur, preventing the misapplication of outdated decisions and the solidification of erroneous rules.

[0202] The workflow execution optimization device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0203] The workflow execution optimization device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0204] The workflow execution optimization device provided in this application embodiment can achieve... Figures 1 to 3 The various processes implemented by the workflow optimization device in the method embodiment are not described in detail here to avoid repetition.

[0205] Optionally, embodiments of this application also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described workflow optimization method embodiments and achieve the same technical effects. To avoid repetition, further details are omitted here. It should be noted that the electronic device in the embodiments of this application includes the aforementioned mobile electronic device and non-mobile electronic device.

[0206] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described workflow execution optimization method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0207] In this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0208] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0209] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A workflow execution optimization method, characterized in that, The method includes: Obtain the user's natural language; the natural language is used to describe the workflow required by the user. The natural language is converted into an intermediate representation of the process by a process parsing intelligent agent; The intermediate representation of the process is partially repaired and semantically verified, and the intermediate representation of the process that passes the semantic verification is compiled into a process definition that can be executed by the process engine; the process definition includes smart hooks corresponding to each node of the workflow, and preset smart agents corresponding to the smart hooks. During the execution of the workflow by the process engine, the context of the workflow execution is collected through the smart hook of the current node, and at least one of the preset smart agents is invoked to generate smart agent decision results based on the context of the workflow execution. The decision results of the intelligent agents are arbitrated through multi-agent conflict arbitration to obtain the target process execution decision corresponding to the current node of the workflow; The process engine executes the current node of the workflow according to the target process execution decision; Collect the process execution logs corresponding to the target process execution decision, and generate optimization suggestions based on the process execution logs; the optimization suggestions are used to update the process parsing agent and / or the preset agent for executing the next node of the workflow.

2. The workflow execution optimization method according to claim 1, characterized in that, The process of converting the natural language into an intermediate representation of the process through a process parsing agent includes: The process parsing agent is fine-tuned and its parameters are constrained so that it learns the mapping rules from natural language to intermediate process representations. Retrieve a target process template that matches the natural language from a preset knowledge base; Input prompts are generated based on the target process template and the natural language; The input prompt is input into the process parsing agent, so that the process parsing agent outputs the intermediate representation of the process in natural language.

3. The workflow execution optimization method according to claim 1, characterized in that, The process of performing local repair and semantic verification on the intermediate representation includes: Perform initial semantic verification on the intermediate representation of the process; If the initial semantic verification fails, a minimum error subgraph is generated based on the semantically erroneous nodes and connections on all executable paths in the intermediate representation of the process; the minimum error subgraph is the error subgraph containing the fewest nodes and connections with the semantically erroneous nodes and connections as its boundary. Repair prompts are generated based on the minimum error subgraph, and the repair prompts are input into the process parsing agent so that the process parsing agent can perform local repairs on the nodes and connections covered by the minimum error subgraph to obtain the partially repaired intermediate representation of the process. Perform semantic verification again on the intermediate representation of the process after partial repair.

4. The workflow execution optimization method according to claim 1, characterized in that, The step of arbitrating multi-agent conflicts in the decision-making results of the intelligent agents to obtain the target process execution decision corresponding to the current node of the workflow includes: Obtain the preset rule priority of the workflow; Generate at least one multi-agent conflict graph corresponding to the preset agent based on the agent's decision-making results; Based on the multi-agent conflict graph, determine the conflict in the execution decisions of at least one of the preset agents at the current node; Based on the preset rule priority of the workflow and the conflict between the execution decisions of at least one preset intelligent agent at the current node, the target workflow execution decision corresponding to the current node of the workflow is determined.

5. The workflow execution optimization method according to claim 1, characterized in that, The operational dimensions of the workflow include at least one of the following: workflow variables, task assignment, workflow routing, and workflow patching; the step of executing the current node of the workflow according to the target workflow execution decision through the workflow engine includes: The process engine executes the process variables of the workflow according to the target process, thereby updating the business data generated during the current node of the workflow. And / or, The process engine executes the task assignment of the workflow according to the target process execution decision, so as to determine the task execution object of the current node of the workflow; And / or, The process engine executes the process routing of the workflow according to the target process execution decision to determine the flow branch of the current node of the workflow; the flow branch is used to indicate the next node of the workflow. And / or, The process engine executes process patches of the workflow according to the target process execution decision to update the next node of the workflow.

6. The workflow execution optimization method according to claim 1, characterized in that, The step of generating optimization suggestions based on the process execution log includes: Based on the process execution log, determine the node data of the current node and previous nodes of the workflow; the node data includes: average node dwell time, node rejection rate, and average completion cycle; Obtain a preset standard line for judging whether the node data is normal, and determine candidate abnormal nodes from the node data according to the preset standard line; Extract the rejection history instances under the candidate exception nodes and the process variables of the rejection history instances from the process execution log; Based on the combination of values ​​of the process variables and the rejection results of the rejection history instances, determine the support and confidence of each combination of values ​​of the process variables in the rejection history instances. The combination of process variables whose support is greater than the preset support threshold and whose confidence is greater than the preset confidence threshold is used as the process variable combination related to rejection. Root cause analysis is performed on the candidate abnormal nodes and the combination of process variables to obtain the optimization suggestions.

7. The workflow execution optimization method according to claim 1, characterized in that, The method further includes: The optimization suggestions are transformed into static rules, and the rule base of the process parsing agent is updated using the static rules. And / or, The optimization suggestions are converted into prompt word patches, and the prompt word instruction set of the process parsing agent and the prompt word instruction set of the preset agent for executing the next node of the workflow are updated through the prompt word patches.

8. The workflow execution optimization method according to claim 7, characterized in that, The step of updating the process parsing agent through the static rules includes: Determine the frequency of occurrence of candidate rules for the same preset agent in the static rules; the static rules are the condition judgment logic directly executed by the process engine; If the frequency of occurrence of a candidate rule exceeds a preset threshold, the candidate rule is written into the rule base of the process parsing agent.

9. The workflow execution optimization method according to claim 7, characterized in that, The step of converting the optimization suggestions into prompt word patches includes: Obtain the preset prompts for the process parsing agent and the preset prompts for the preset agent to execute the next node of the workflow, as well as the historical requirements of the workflow; Generate candidate prompt word patches based on the optimization suggestions and the preset prompt words; The candidate suggestion patch is validated in a sandbox environment based on the historical requirements of the workflow. The verified candidate prompt word patch is used as the prompt word patch.

10. A workflow execution optimization device, characterized in that, The device includes: The natural language acquisition module is used to acquire the user's natural language; the natural language is used to describe the workflow required by the user. The intermediate representation conversion module is used to convert the natural language into an intermediate representation of the process through the process parsing agent; The semantic verification and repair module is used to perform local repair and semantic verification on the intermediate representation of the process, and compile the intermediate representation of the process that passes semantic verification into a process definition that can be executed by the process engine; the process definition includes smart hooks corresponding to each node of the workflow, and preset smart agents corresponding to the smart hooks. The decision result generation module is used to collect the context of the workflow execution through the smart hook of the current node during the execution of the workflow by the process engine, and call at least one of the preset smart agents to generate smart agent decision results based on the context of the workflow execution. The decision conflict arbitration module is used to arbitrate multi-agent conflicts on the decision results of the intelligent agent to obtain the target process execution decision corresponding to the current node of the workflow; The target decision execution module is used to execute the current node of the workflow according to the target process execution decision through the process engine; An optimization suggestion generation module is used to collect process execution logs corresponding to the target process execution decision and generate optimization suggestions based on the process execution logs; the optimization suggestions are used to update the process parsing agent and / or the preset agent for executing the next node of the workflow.

11. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein when the program or instructions are executed by the processor, they implement the steps of the workflow execution optimization method as described in any one of claims 1-9.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the workflow execution optimization method as described in any one of claims 1-9.

Images