Multi-agent based workflow construction method, system and related device

CN123030165APending Publication Date: 2026-11-03BUSINESS LINE COMMERCIAL PTE LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611234075.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-08-14
Publication Date
2026-11-03

AI Technical Summary

Technical Problem

In e-commerce independent website operation scenarios, existing technologies have complex workflow construction methods with high learning costs, and the generated workflow configurations deviate significantly from the actual working mode of the platform, resulting in low accuracy and reliability, and failing to achieve fast and accurate construction.

Method used

A multi-agent-based workflow construction method is adopted. The first agent recognizes user input and delegates the specific construction tasks to the second agent. The second agent obtains the information of the workflow components and generates structured data through multi-stage tool calls. The server verifies the data and automatically corrects any errors until the verification is successful.

Benefits of technology

It improves the accuracy and reliability of workflow construction, avoids the problem of a single agent's context window being heavily occupied by the results of intermediate tool calls, reduces user intervention, and improves the user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123030165A_ABST
    Figure CN123030165A_ABST
Patent Text Reader

Abstract

Embodiments of the present application provide a kind of based on multi-agent's workflow construction method, system and related equipment, the method comprises: first agent obtains the input data of user, if determining input data and preset workflow operation have relevance, then call second agent, input data is transmitted to second agent;Second agent obtains the component information of the workflow corresponding to input data, generates the structured data of workflow, and the structured data is sent to server for checking;If the checking result indicates that there is error data in structured data, second agent corrects error data, and the modified data is re-sent to server for checking, until the checking result indicates that structured data is qualified;Based on the structured data of checking qualification, target workflow is constructed.The application realizes the automation workflow construction by master-slave agent responsibility separation, improves the efficiency and accuracy of workflow construction.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence technology, and in particular relates to a workflow construction method, system and related equipment based on multi-agent systems. Background Technology

[0002] In e-commerce independent website operation scenarios, merchants often describe their business automation needs in natural language, such as creating an automation rule that includes trigger conditions and execution actions to form a workflow. Related solutions typically require users to manually configure workflow nodes using a visual drag-and-drop editor. This method is complex, has a high learning curve, and cannot automate workflow construction, making it difficult to achieve fast and accurate workflow creation. Furthermore, workflow generation solutions based on artificial intelligence (AI) agents often face issues such as limited context windows and task illusions, resulting in significant deviations between the generated workflow configuration and the platform's actual working mode, leading to low accuracy and reliability in workflow construction. Summary of the Invention

[0003] In view of the above, it is necessary to provide a workflow construction method, system and related equipment based on multi-agent systems, which can solve the technical problem that the existing workflow construction methods are unable to achieve fast and accurate workflow construction.

[0004] The first aspect of this application provides a workflow construction method based on multiple agents, comprising: acquiring user input data using a first agent; if the first agent determines that the input data is related to a preset workflow operation, invoking a second agent using the first agent, and transmitting the input data to the second agent without transmitting the context data of the input data; acquiring component information of the workflow corresponding to the input data using the second agent, and generating structured data of the workflow corresponding to the input data based on the component information; sending the structured data to a server using the second agent, the server verifying the structured data; if the verification result returned by the server indicates that the structured data contains erroneous data, correcting the erroneous data using the second agent, and resending the corrected data to the server for verification until the verification result returned by the server indicates that the structured data is verified successfully; and constructing a target workflow corresponding to the input data based on the structured data if the verification result returned by the server indicates that the structured data is verified successfully.

[0005] According to an embodiment of this application, the step of using the second intelligent agent to obtain the component information of the workflow corresponding to the input data includes: using the second intelligent agent to call a task retrieval service to obtain the node tasks of the workflow corresponding to the input data; using the second intelligent agent to call a configuration query service to obtain the parameter format constraints of the node tasks; and using the second intelligent agent to call a path verification service to determine the existence of reference paths to business data fields in the structured data.

[0006] According to an embodiment of this application, the workflow corresponding to the input data includes multiple nodes, each node representing a sub-execution unit in the workflow corresponding to the input data; generating structured data of the workflow corresponding to the input data based on the component information includes: using the second intelligent agent to determine the operation type corresponding to the input data, the operation type representing the type of operation performed on the workflow corresponding to the input data; if the operation type is a modified workflow, using the second intelligent agent to obtain the historical structured data of the target workflow from the server, replacing and updating the parameter values ​​corresponding to the modified content indicated by the input data, while retaining other nodes not involved in the modified content and the original node numbers unchanged.

[0007] According to an embodiment of this application, the step of generating structured data for the workflow corresponding to the input data based on the component information further includes: if the operation type is the modified workflow and the modification method includes adding a node, using the second intelligent agent to increment the node number of the newly added node starting from the largest node number in the historical structured data; if the operation type is the modified workflow and the modification method includes deleting any node, using the second intelligent agent to delete the connection relationship associated with any node in the historical structured data.

[0008] According to an embodiment of this application, the step of generating structured data for the workflow corresponding to the input data based on the component information further includes: if the operation type is creating a workflow, using the second intelligent agent to set an incrementing node number for each node in the order of trigger node, condition judgment node, and action execution node, and establishing directed connection relationships between nodes.

[0009] According to an embodiment of this application, the step of sending the structured data to the server using the second intelligent agent includes: if the operation type is the modification workflow, the second intelligent agent sends the identifier of the workflow corresponding to the input data, the current version number, and the modified historical structured data to the server, so that the server verifies whether the current version number is consistent with the latest version number, and if the version numbers are inconsistent, returns version conflict information to the second intelligent agent.

[0010] According to an embodiment of this application, the step of using the second intelligent agent to correct the erroneous data includes: using the second intelligent agent to determine a correction strategy based on the error type corresponding to the erroneous data; and correcting the erroneous data according to the correction strategy, wherein the second intelligent agent does not output the erroneous data to the user terminal during the correction process.

[0011] According to an embodiment of this application, the method further includes: when the first agent calls the second agent, the first agent transmits an identifier to the second agent, the identifier being used to identify a workflow construction process of the second agent; in the storage space corresponding to the identifier, the second agent saves the query records and generated structured data during the current workflow construction process of calling the second agent; if the second agent receives the identifier again, the second agent loads the query records and structured data saved in the storage space according to the identifier, and continues to execute the workflow construction process corresponding to the identifier.

[0012] A second aspect of this application provides a workflow construction system based on a multi-agent architecture. The system includes: a first agent, configured to acquire input data input by a user on a user terminal; if the first agent determines that the input data is associated with a preset workflow operation, it invokes a second agent and transmits the input data to the second agent, wherein context data of the input data is not sent to the second agent along with the input data; and a second agent, configured to acquire component information of the workflow corresponding to the input data and generate the structure of the workflow corresponding to the input data based on the component information. The data is structured; the structured data is sent to the server, which verifies the structured data; if the verification result returned by the server indicates that there is erroneous data in the structured data, the second intelligent agent is used to correct the erroneous data, and the corrected data is resent to the server for verification until the verification result returned by the server indicates that the structured data has passed verification; if the verification result returned by the server indicates that the structured data has passed verification, the target workflow corresponding to the input data is constructed based on the structured data, wherein the verification result is not output to the user terminal during the correction process.

[0013] A third aspect of this application provides an electronic device, including: a memory and a processor, wherein the processor executes computer-readable instructions stored in the memory to implement the multi-agent-based workflow construction method.

[0014] The workflow construction method based on multi-agent provided in this application involves a first agent recognizing user input for workflow intent and, upon successful recognition, delegating the specific construction task to a second agent, thus achieving separation of responsibilities between master and slave agents. The second agent obtains workflow component information and generates structured data through multi-stage tool calls. The server validates the structured data, and if errors are found, the second agent automatically corrects and resubmits the data until it passes validation, at which point the target workflow is constructed. This master-slave agent delegation mechanism achieves context isolation, avoiding the problem of a single agent's context window being heavily occupied by intermediate tool call results. The closed-loop mechanism of server-side validation and automatic correction by the second agent allows for error correction without user intervention. By distinguishing between the different processing logics for creating and modifying workflows, the method retains manually configured content in modification scenarios, preventing data loss due to overall overwrite, thereby improving the accuracy and reliability of workflow construction and enhancing the user experience. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the application environment for a multi-agent-based workflow construction method provided in an embodiment of this application.

[0017] Figure 2 This is a flowchart illustrating a multi-agent-based workflow construction method provided in an embodiment of this application.

[0018] Figure 3 This is a flowchart illustrating a multi-agent-based workflow construction method provided in another embodiment of this application.

[0019] Figure 4 This is a structural diagram of a multi-agent-based workflow construction system provided in an embodiment of this application.

[0020] Figure 5 This is a schematic diagram of a multi-agent-based workflow construction device provided in an embodiment of this application.

[0021] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] It should be noted that in this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects, not to describe a specific order or sequence.

[0024] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner. Unless otherwise specified, the following embodiments and features described herein can be combined with each other.

[0025] In e-commerce independent website operation scenarios, merchants often describe their business automation needs in natural language, such as "automatically issue coupons and label customers as Very Important Persons (VIPs) when the order amount exceeds 500 yuan." This includes explicit trigger events (order amount exceeding 500 yuan), conditional judgments (amount threshold), and execution actions (issuing coupons and labeling), as well as implicitly the execution order and data dependencies of each node in the workflow. Related workflow construction methods based on visual drag-and-drop editors rely on merchants manually dragging and dropping nodes and configuring parameters one by one. This type of interaction requires merchants to have a high level of operational proficiency and business rule abstraction ability, and cannot fully understand the multi-layered intent behind the natural language description, resulting in a lengthy workflow configuration process and low construction efficiency.

[0026] Currently, there are some related solutions for automatic workflow generation, but they all have certain limitations.

[0027] In one example, a single Artificial Intelligence (AI) agent directly generates workflow configuration files (such as JavaScript Object Notation (JSON) or a Domain Specific Language (DSL)). Specifically, this approach constructs prompts from the user's natural language input, inputs them into a Large Language Model (LLM), which understands the user's intent and directly outputs a complete structured description of the workflow before submitting it to the platform for execution.

[0028] However, this solution faces serious accuracy issues in e-commerce workflow scenarios. Workflow tasks are diverse and continuously updated, with each task having different configurable fields, data return fields, and port identifiers. The LLM (Layered Query Language) cannot directly know which tasks are currently available on the platform and their precise parameter formats through pre-trained knowledge, leading to non-existent generated task identifiers (IDs) or parameter configurations that do not conform to platform constraints. Furthermore, when referencing business object fields in the workflow, the field path must strictly conform to the platform's GraphQL schema. The LLM often fills in non-existent paths based on guesswork, and such errors are often only discovered after the workflow has actually run, resulting in high trial-and-error costs.

[0029] In another example, a single AI agent dynamically retrieves a task list and configuration constraints by calling platform tools to generate a workflow. Specifically, this scheme allows the agent to call the platform's retrieval interface to obtain a list of available triggers, actions, and conditions, along with their parameter schemas, and then generate a workflow JSON that conforms to the required format based on the retrieved information.

[0030] However, the pure tool-calling approach still faces several technical drawbacks. When a single agent handles complex tasks like workflow construction that require multiple rounds of tool calls, intermediate results consume a large portion of the context window, impacting the quality of subsequent inference. Furthermore, this solution fails to differentiate between workflow creation and modification scenarios: workflow creation requires a complete build, while modifying an existing workflow only requires minor adjustments to user-specified parameters. If the same process is used interchangeably, modifications often overwrite existing content, resulting in the loss of manually configured nodes. Additionally, the platform's structured validation of workflow JSON returns error messages requiring manual parsing and repair, demanding a high level of technical expertise from merchants and reducing the practical value of automated workflow construction.

[0031] Furthermore, existing solutions generally focus only on the one-way generation process of "mapping a single user input to a workflow configuration," neglecting the "description, adjustment, and iteration" behavior pattern that merchants exhibit during workflow construction. After submitting their initial requirements, merchants often develop new adjustment requests after seeing the construction results (such as "changing the amount condition to 600 yuan" or "adding an inventory check"). Existing solutions lack the ability to maintain context across requests for such multi-round iterative needs, and can only passively respond to the current input. This results in merchants having to repeatedly describe the complete requirements for each adjustment, making it difficult to form a coherent construction experience.

[0032] To address the aforementioned issues, the workflow construction method based on a multi-agent approach provided in this application involves a first agent recognizing user input for workflow intent and, upon successful recognition, delegating specific construction tasks to a second agent, thus achieving separation of responsibilities between master and slave agents. The second agent obtains workflow component information and generates structured data through multi-stage tool calls. The server validates the structured data, and if errors are found, the second agent automatically corrects and resubmits the data until validation is successful, at which point the target workflow is constructed. This master-slave agent delegation mechanism achieves context isolation, preventing the single agent's context window from being heavily occupied by intermediate tool call results. The closed-loop mechanism of server-side validation and automatic correction by the second agent allows for error correction without user intervention. By differentiating between workflow creation and modification processing logic, user-configured content is retained in modification scenarios, preventing data loss due to overall overwrite. This improves the accuracy and reliability of workflow construction and enhances the user experience.

[0033] Please see Figure 1 This is a schematic diagram illustrating the application environment of the multi-agent-based workflow construction method provided in this application embodiment. Figure 1 As shown, the technical solution of this application uses the operating environment of an e-commerce platform (or simply e-commerce platform, platform, etc.) 10 as its application environment. The e-commerce platform 10 can be an e-commerce service platform with open independent site services. The e-commerce platform 10 can be used to provide merchants' goods and services to users. Among them, users can be merchant users (e.g., sellers or product providers), customer users (e.g., buyers or product users), potential users (e.g., users who are browsing but have not yet committed to purchasing, etc.).

[0034] E-commerce platform 10 can be implemented through a processing facility including a processor and memory. When instructions stored in the memory are executed, the e-commerce platform 10 performs the e-commerce functions and supporting functions described herein. The processing facility can be a server, client, network infrastructure, mobile computing platform, cloud computing platform, or other computing platform, and provides electronic connectivity and communication between electronic components of e-commerce platform 10, merchant devices 20, client devices 30, etc. E-commerce platform 10 can be implemented as a cloud computing service, Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Managed Software as a Service (MSaaS), Mobile Backend as a Service (MBaaS), IT Management as a Service (ITMaaS), etc.

[0035] E-commerce platform 10 can provide a centralized system for offering merchants online resources and facilities to manage their businesses. E-commerce platform 10 can provide communication facilities 101 and associated merchant interfaces to provide electronic communication and marketing, such as using electronic messaging aggregation facilities to collect and analyze communication interactions between merchants, customers, merchant devices 20, customer devices 30, etc., to aggregate and analyze communications. For example, in a real-world scenario, when a merchant inputs a workflow construction requirement in natural language on merchant device 20 (e.g., a user terminal) (e.g., "Automatically issue coupons when the order amount exceeds 500 yuan and label the customer as a Very Important Person (VIP)"), communication facility 101 can transmit the input data to the cloud server cluster of e-commerce platform 10 via Hypertext Transfer Protocol Secure (HTTPS). A first intelligent agent deployed in the cloud performs intent recognition and workflow operation correlation judgment, and finally returns the completed workflow to merchant device 20 for display and activation confirmation. During this process, communication facility 101 is also used to collect feedback from merchants on the construction results (such as confirmation of activation, requests for modification, etc.). This feedback data is of great significance for subsequent optimization of workflow construction strategies and implementation of multiple rounds of iterative adjustments.

[0036] The data facility 102 of the e-commerce platform 10 can store information about business and merchant transactions. The data facility 102 can enhance, contribute, refine, and extract data in various ways, allowing for improvements to various aspects of the e-commerce platform 10 over time. During the construction of a multi-agent workflow, the data facility 102 can store workflow node task information, including structured metadata such as configuration fields, return fields, and port identifiers for trigger tasks, conditional judgment tasks, and action execution tasks. Furthermore, the data facility 102 can store platform-pre-built workflow templates covering common business scenarios, as well as historical workflow definitions and versioned data created by merchants. This rich and structured data provides a solid data foundation for multiple agents to collaboratively execute multi-agent workflow construction. This enables the second agent to discover available tasks, obtain their precise parameter format constraints, and verify the existence of reference paths to business data fields in the workflow by dynamically calling task retrieval services, thereby significantly improving the accuracy and reliability of workflow construction.

[0037] E-commerce platform 10 may be configured with a business management engine 104 for content management, task automation, and data management. This engine can deploy multiple agents to support and serve multiple online stores 103. The business management engine 104 includes basic or "core" functionalities of e-commerce platform 10 (e.g., common to most online store activities, such as cross-channel, admin interface, merchant location, industry, product type, etc.) and can be reused across online stores 103 (e.g., functionalities that can be reused / modified across core functionalities).

[0038] In a specific example, the e-commerce platform 10 uses multiple agents to collaboratively execute a workflow construction process based on multiple agents. The first and second agents can both be deployed on a cloud server cluster, as can the server itself, together forming the cloud server. The merchant device 20 (user end) is only responsible for collecting input data and displaying the construction results, communicating with the cloud server cluster via HTTPS.

[0039] The first agent performs intent recognition on the input data entered by the merchant on the merchant device 20 to determine whether the input data is related to a workflow operation. If the input data is related to a workflow operation, the first agent invokes the second agent and transmits the input data to the second agent. Specifically, the parameters passed from the first agent to the second agent include at least the input data itself and an optional identifier (e.g., a dialogue continuation identifier), which identifies a workflow construction process of the second agent. The complete dialogue context information of the first agent is not transparently transmitted to the second agent; context isolation is achieved by only transmitting the input data. The first agent does not intervene in any intermediate processes of the second agent during its operation until the second agent returns the final processing result.

[0040] After the second agent is activated, it first determines the operation type corresponding to the input data. Operation types include creating a workflow or modifying a workflow (e.g., modifying an existing workflow). The second agent obtains the component information of the target workflow through multi-stage tool calls: calling the task retrieval service to obtain workflow node tasks matching the input data; calling the configuration query service to obtain the parameter format constraints of the node tasks; and calling the path verification service to confirm the existence of reference paths to business data fields in the structured data. The second agent generates structured data for the target workflow based on the obtained component information. If the operation type is creating a workflow, the second agent sets an incrementing node number for each node in the order of trigger node, condition judgment node, and action execution node, and establishes directed connections between nodes. If the operation type is modifying a workflow, the second agent obtains historical structured data of the target workflow from the server as the basis for modification, only replacing and updating the parameter values ​​corresponding to the modification content indicated by the input data, retaining other nodes not involved in the modification content and their original node numbers unchanged. If the operation type is to modify an existing workflow and the modification method includes adding a node, the second agent increments the node number of the new node, starting with the largest node number in the historical structured data; if the operation type is to modify an existing workflow and the modification method includes deleting any node, the second agent deletes the connection relationship associated with that node in the historical structured data.

[0041] The second agent sends the generated structured data to the server, which validates the data. If the server's validation result indicates errors in the structured data, the second agent determines a correction strategy based on the error type, corrects the errors according to the strategy, and resends the corrected data to the server for validation until the server returns a validation result indicating the structured data is valid. During the correction process, the second agent does not output any error data to the user. If the operation type is modifying an existing workflow, the second agent sends the target workflow's identifier, current version number, and modified historical structured data to the server. The server checks if the current version number matches the latest version number; if they do not match, it returns a version conflict message to the second agent. If the server's validation result indicates the structured data is valid, the target workflow is constructed based on the structured data.

[0042] The second agent also supports context preservation across requests. When the first agent invokes the second agent, the first agent transmits an identifier to the second agent. This identifier identifies a workflow construction process performed by the second agent. In the storage space corresponding to the identifier, the second agent saves the query records and structured data generated during this invocation. If the second agent receives the same identifier again, it loads the saved query records and structured data from the storage space based on the identifier and continues executing the workflow construction process corresponding to that identifier.

[0043] In some embodiments, merchants may use e-commerce platform 10 to manage business with customers, such as implementing e-commerce experiences with customers through online store 103 (e.g., independent website store), managing business through e-commerce platform 10, and interacting with customers through communication facilities 101 of e-commerce platform 10.

[0044] Merchants can manage one or more storefronts in online store 103 through, for example, merchant device 20 (e.g., computer, etc.) and offer goods to customers through different channels (e.g., online store 103). The terms "online store 103," "storefront," and "shop" are used synonymously and refer to the online e-commerce business unit provided by the merchant through e-commerce platform 10.

[0045] Merchants can log in to administrator 105 via merchant device 20 (e.g., from a desktop computer or mobile device) and manage various aspects of their online store 103. For example, merchants can customize the appearance of online store 103 through a theme system, or customize the presentation content of product detail pages (e.g., product titles, product details, product images, and other types of content). Merchants can also configure and manage automated business rules for online store 103 through administrator 105, such as creating workflow rules or modifying existing workflow rules. This configuration operation affects the workflow definition data stored in data facility 102, providing basic data support for the second agent to perform workflow construction and modification.

[0046] Online store 103 can support a large number of independently managed stores and process a large amount of data for each store every day. This data may include, for example, basic store data, customer contact information, information about purchased goods, information about presented services, and any other information related to business transactions conducted through e-commerce platform 10. For an online store 103 operating with automated workflow management, a large amount of order data, customer behavior data, inventory change data, etc., is generated daily. This data constitutes the context for workflow triggering conditions and action execution. In some embodiments, e-commerce platform 10 can store this data in data facility 102 and provide runtime data support for the workflow execution engine. This structured business data provides a schema basis for the second agent to perform data field path verification, enabling the system to promptly detect and correct field path errors during the workflow construction phase, avoiding runtime problems from being exposed only after the workflow is activated.

[0047] In some embodiments, customers can interact via customer device 30 (e.g., computer, mobile terminal, etc.) or any other business interface device known in the art. E-commerce platform 10 enables merchants to contact customers through online store 103, facilitate business with customers through dialogue via electronic communication facility 101, etc., thereby providing a system for contacting customers and facilitating merchant services for real or virtual paths that can be used to contact and interact with customers.

[0048] Online store 103 can be provided to customers by e-commerce platform 10, where customers can browse and purchase various available goods and conduct various transactions related to online store 103. For example, online store 103 can be made available to customer device 30 through web pages provided by the server of e-commerce platform 10. The server can receive requests for web pages from a browser or other application installed on customer device 30, and in response, the server sends back the requested web page, which is then displayed by the web browser (or other application) of customer device 30.

[0049] The following will refer to computer program products running on e-commerce platforms (such as...) Figure 1 Let's take an e-commerce platform (10) as an example to illustrate.

[0050] In one example, reference Figure 2 The diagram shown is a flowchart illustrating a multi-agent-based workflow construction method according to an embodiment of this application, including the following steps. These steps may be omitted, split, have more steps added, or have their execution order adjusted according to the actual application scenario; this embodiment does not limit this.

[0051] Step S201: Use the first intelligent agent to obtain the user's input data. If the first intelligent agent determines that the input data is related to the preset workflow operation, use the first intelligent agent to call the second intelligent agent and transmit the input data to the second intelligent agent.

[0052] In one embodiment of this application, the first intelligent agent can be deployed on a cloud server cluster (e.g., a server-side application) and can be used to obtain user input data from the user terminal. For example, the user terminal includes the terminal device used by the merchant. The input data obtained by the first intelligent agent comes from the information entered by the merchant on the user terminal, and its form includes, but is not limited to, text data or voice data. If the input data is voice data, the user's voice input can be converted into text data first, and then the converted text data can be used as input for subsequent steps. The specific form of the input data does not constitute a limitation on the technical solution of this application. Furthermore, the source of the input data is not limited to the information entered by the merchant in real time at the current interaction moment, but can also come from workflow requirements expressed in historical dialogues that have not yet been completed. For example, if the merchant initiated a workflow creation request in the previous round of dialogue but has not yet completed it, and continues to make adjustments to the workflow in the current round, the input data for this round is the text or voice information corresponding to that adjustment request. The specific source and timing of the input data do not constitute a limitation on the technical solution of this application.

[0053] Based on the above embodiments, multiple interaction methods and multiple sources of input data are supported, which can improve the convenience and flexibility of merchants' operations, adapt to the usage habits of different merchants and the interaction needs in different scenarios, and also provide a data source foundation for subsequent intent recognition by combining contextual information.

[0054] In one embodiment of this application, after acquiring input data using a first intelligent agent, the first intelligent agent is further configured to determine whether the input data is associated with a preset workflow operation. The preset workflow operation includes creating a workflow, modifying an existing workflow, querying workflow status, or auditing workflow modification records.

[0055] In one example, the first agent can directly make judgments using preset rules, including keyword matching rules, page matching rules, and context matching rules. The keyword matching rules are used to segment and match keywords in the input data, identifying whether the input data contains keywords related to workflow operations. For example, they check if the input data contains semantic keywords such as "automation," "workflow," "trigger," "condition," and "action." The page context rules are used to obtain information such as the Uniform Resource Locator (URL) and page title of the current page to determine whether the current page is a workflow management page. The context matching rules are used to determine whether a workflow-related context has been established in the historical dialogues of the input data. If the input data contains the aforementioned keywords, or the current page context is a workflow management page, or a workflow-related context has been established in the historical dialogues, then the first agent can determine that the input data is related to the workflow operation.

[0056] In another implementation, the first agent can also invoke a pre-defined Large Language Model (LLM) via a pre-defined prompt template. The LLM then performs intent recognition on the input data to determine whether it relates to workflow-related operations. In one example, the prompt template can instruct the LLM to perform the task of "determining whether the user input belongs to a workflow-related operation," and then fill the corresponding position in the prompt template with the input data before inputting it into the LLM. For example, if the input data is "automatically issue coupons and label customers as important customers when the order amount exceeds 500 yuan," the LLM, after understanding its semantics, can identify that it contains explicit triggering events, conditional judgments, and execution actions, implicitly indicating the execution order and data dependencies of each node in the workflow, thus determining that the input data is related to the workflow operation.

[0057] In another implementation, a combination of preset rules and preset language models can be used to determine whether the input data is related to the workflow operation. Preset rules include keyword matching rules and page context rules, which can quickly complete the initial judgment without increasing the model call cost. These rules can be executed in parallel with model calls, and the model judgment results are cross-validated with the rule judgment results. When the two results are consistent, the result is directly output; when there are differences, the model judgment result prevails, and the difference cases are recorded for rule optimization, thus balancing accuracy and efficiency.

[0058] Based on the above embodiments, the first intelligent agent performs workflow intent recognition on the input data through a hybrid approach that combines semantic models and rules. This approach can ensure rapid judgment of common workflow-related inputs, as well as classification coverage of long-tail new words and complex intents. While ensuring judgment accuracy, it reduces model call costs and improves the overall processing efficiency of the system.

[0059] In one embodiment of this application, if the first intelligent agent determines that the input data is related to the workflow operation, the first intelligent agent calls the second intelligent agent and transmits the input data to the second intelligent agent. For example, the first intelligent agent starts the second intelligent agent through a delegation interface. In another example, the first intelligent agent can call the second intelligent agent not only through direct invocation, but also through function calls, microservice RPC calls, asynchronous message queue distribution, and other implementations. The identifier (i.e., the session resume identifier) ​​can be implemented using a universally unique identifier (UUID), session token, or encrypted state snapshot, etc.

[0060] The parameters passed from the first agent to the second agent include at least the input data itself (e.g., a complete paraphrase of the merchant's original request) and an optional identifier (e.g., a dialogue continuation identifier). The identifier identifies a workflow construction process of the second agent, and the second agent stores the query records and generated structured data from this call in the storage space corresponding to the identifier. The complete dialogue context of the first agent is not transmitted to the second agent; context isolation is achieved by only transmitting the input data. The first agent does not intervene in any intermediate processes of the second agent during its operation until the second agent returns the final processing result.

[0061] In one embodiment of this application, if the first intelligent agent determines that the input data is not related to the workflow operation, such as the input data being a request unrelated to the workflow like "What's the weather like today?" or "Check my orders," the first intelligent agent does not invoke the second intelligent agent. Instead, the first intelligent agent directly responds to the merchant's request or the request is processed by another dedicated intelligent agent. Through the design of separating the responsibilities of the master and slave intelligent agents, the first intelligent agent only activates the second intelligent agent when it recognizes a workflow-related intent. This avoids the waste of resources caused by frequent and invalid invocations of the second intelligent agent, and also ensures that the workflow construction task is independently carried out by a dedicated intelligent agent, without affecting the response quality of the first intelligent agent to other types of requests.

[0062] Based on the above embodiments, by having a first agent identify the workflow intent of the input data and, upon successful identification, delegate the specific construction task to a second agent, the separation of responsibilities between the master and slave agents is achieved. This effectively avoids the problem of the context window being occupied by a large number of intermediate results when a single agent handles complex tasks such as workflow construction that require multiple rounds of tool calls. Simultaneously, by isolating the context data of the input data from the input data itself, the second agent can execute the workflow construction task in an independent and clean context, preventing irrelevant dialogue history from the master agent from interfering with the workflow construction process and improving the accuracy and reliability of workflow construction.

[0063] Step S202: Use the second intelligent agent to obtain the component information of the workflow corresponding to the input data, and generate structured data of the workflow corresponding to the input data based on the component information.

[0064] In one embodiment of this application, after the second intelligent agent is invoked by the first intelligent agent, it first determines the operation type corresponding to the input data. The operation type includes creating a workflow or modifying an existing workflow. This allows the second intelligent agent to use differentiated processing logic to generate structured workflow data based on the different operation types.

[0065] In one example, the second agent can determine the operation type based on the semantic representation of the input data. For instance, the judgment rules include: if the input data contains expressions such as "create," "new," or "generate," it is determined to be a workflow creation operation. If the input data contains expressions such as "modify," "update," or "edit," or describes a problem with an existing workflow (e.g., "change the amount condition to 500 yuan"), it is determined to be an existing workflow modification operation. Furthermore, when the second agent cannot clearly determine the operation type based on the input data, it can ask the user a query to clarify the operation type based on the user's response.

[0066] In another example, the second agent can also invoke a preset language model through a preset prompt word template. The preset language model performs semantic parsing on the input data to determine the operation type corresponding to the input data. For example, after inputting the data "Help me modify the automation I just created, change the amount condition to 500 yuan" into the preset language model, the model recognizes the action word "modify" and the referent "the automation I just created," determines that the input corresponds to modifying an existing workflow operation, and further extracts the modification target as "amount condition" and the modification value as "500 yuan."

[0067] In another example, the second agent can also determine the operation type by combining the identifier passed in by the first agent. For instance, if the first agent passes in an identifier, and the storage space corresponding to that identifier contains a previously incomplete workflow construction record, the second agent can determine that the current request is a continuation operation of the previous construction task, rather than a completely new workflow creation. Based on this, the second agent further combines the semantics of the current input data to determine whether it is a modification operation or a continuation of the previously incomplete creation operation.

[0068] Based on the above embodiments, the second intelligent agent can determine the operation type through a combination of semantic rules, preset language models and identifier states. It can accurately distinguish between two scenarios: creating a workflow and modifying an existing workflow. This lays the foundation for adopting differentiated construction logic in the future and avoids the problem of user configuration loss caused by the mixing of creation and update logic due to misjudgment of operation type.

[0069] In one embodiment of this application, after determining the operation type corresponding to the input data, the second intelligent agent obtains the component information of the workflow corresponding to the input data. The workflow corresponding to the input data includes multiple nodes, each node representing a sub-execution unit within the workflow, and each node corresponding to a workflow task (including trigger tasks, condition judgment tasks, and action execution tasks). Nodes are associated with the corresponding task definition through task identifiers and populated with the task's configuration parameters. The component information includes the basic structural information required to construct the workflow corresponding to the input data, including at least: the node tasks constituting the workflow (e.g., trigger tasks, condition judgment tasks, and action execution tasks), the configurable parameters and format constraints of the node tasks, the connection relationships between nodes, and the paths to business data fields referenced in the workflow.

[0070] In one embodiment of this application, when obtaining the above-mentioned information on various components, the second intelligent agent can sequentially complete the following operations through a multi-stage tool invocation.

[0071] In one example, the second agent can invoke a template retrieval tool to retrieve a reference workflow template matching the input data from the platform's pre-built workflow template library. Specifically, the second agent extracts keywords describing the user's business objectives (such as "order amount judgment" or "coupon issuance") from the input data as search criteria and invokes the template retrieval tool to perform a search in the pre-built template library. The template library contains pre-built reference workflows covering common business scenarios, with each template including complete node configurations and connections between nodes. If the search returns a template matching the user's business objectives, the second agent can reuse the structured data of that template as a foundation and adapt it based on the specific parameters in the input data to reduce the overhead and error rate of building from scratch. Template retrieval is typically performed when creating a workflow; this stage can be skipped when modifying an existing workflow.

[0072] Through a template-first retrieval mechanism, the second agent prioritizes reusing pre-built templates that match the user's intent when constructing new workflows. This effectively reduces the workload of configuring nodes from scratch, lowers the risk of node omissions or configuration errors due to completely autonomous generation, and improves the efficiency and accuracy of workflow construction. Template retrieval can be achieved based on keyword full-text search, vector semantic similarity search, or category tag filtering, as long as it can retrieve reference workflows related to the merchant's intent from the pre-built template library.

[0073] The second intelligent agent invokes the task retrieval service to obtain the node tasks of the workflow corresponding to the input data. Specifically, the second intelligent agent uses a natural language description of the user's business scenario as input, invokes the task natural language retrieval tool, and searches for trigger tasks, condition judgment tasks, and action execution tasks that match the current requirements. The task retrieval service recalls relevant tasks from the platform's pre-built task library based on semantic matching and returns a unique identifier and version number for each matching task. For example, for the input data "Automatically issue coupons when the order amount exceeds 500 yuan," the task retrieval service can recall node tasks such as "order amount trigger," "amount condition judgment," and "issue coupon action." When creating an operation, all necessary tasks are searched; when updating an operation, only tasks required for the newly added node are searched.

[0074] Through the task-based natural language retrieval service, the second agent can dynamically discover available workflow tasks on the platform by using natural language descriptions of business scenarios as input. This allows the second agent to perceive the platform's new or updated task capabilities without relying on pre-trained knowledge, effectively solving the problem of missing task identifiers or version mismatches caused by purely pre-trained knowledge. Task retrieval can employ methods such as vector embedding similarity search, label-based classification retrieval, or large language model (LLM) summarization followed by exact matching, as long as task identifiers and version numbers matching the natural language descriptions can be found from a large number of tasks.

[0075] The second agent invokes the configuration query service to obtain the parameter format constraints of the node tasks. After the second agent passes in a list of task identifiers, the configuration query service returns detailed configuration information for each task, including configurable fields and their data types and constraints, data return fields exposed downstream after task execution, and input / output port identifiers used when connecting nodes. The second agent generates parameter values ​​that conform to the constraints based on the configurable fields, establishes data reference relationships between nodes based on the returned fields, and constructs directed connection relationships between nodes based on the port identifiers. During a creation operation, the configuration information of all tasks is retrieved; during an update operation, only the configuration information of newly added tasks is retrieved.

[0076] By dynamically obtaining the precise parameter format constraints of node tasks through the configuration query service, the parameter values ​​of each node in the structured workflow data generated by the second agent conform to the platform constraints, effectively solving the problem of verification failure caused by parameter format not conforming to platform requirements when generating workflows from pure pre-trained knowledge.

[0077] The second agent invokes the path verification service to determine the existence of reference paths to business data fields in the structured data, such as whether they exist. The second agent takes the target business object type and field semantic description as input and invokes the data field path verification tool to obtain the available data field paths under that business object type. All references to business object fields made by the second agent during workflow construction must be confirmed by the path verification tool before use; they cannot be filled in based on speculation. For example, when configuring the "send email" action, if the email address of the order customer needs to be referenced as the email recipient, the second agent must confirm through the path verification tool that the "order.customer.email" path actually exists in the platform schema before entering the configuration parameters.

[0078] By employing a data field path mandatory verification mechanism, the second agent verifies the validity of all business object field references during the construction phase. This effectively solves the technical problem in existing solutions where field path errors can only be discovered after the workflow is activated, resulting in high trial-and-error costs. Field path verification can be implemented based on GraphQL pattern introspection, OpenAPI pattern parsing, or platform-defined path registry queries. The core constraint is that the second agent must not use paths based on speculation but must confirm them through querying.

[0079] Based on the above embodiments, through the rigid sequential arrangement of a multi-stage toolchain—template-first retrieval, task natural language discovery, dynamic acquisition of task configuration patterns, and mandatory verification of data field paths—the second intelligent agent can dynamically discover available workflow tasks on the platform and obtain their precise configuration constraints without the need for pre-trained knowledge. This effectively solves the problems of task identifier illusion and field path errors when generating workflows using pure pre-trained knowledge.

[0080] In one embodiment of this application, when the second intelligent agent fills in the node configuration parameters, it can determine the parameter values ​​according to the following priorities: first, use the store data obtained from the context; second, use the resource identifier found through the store resource retrieval service; if none of the above sources can be obtained, then use a placeholder and clearly inform the merchant of the location that needs to be replaced in the final response.

[0081] By setting a priority mechanism for parameter value filling, the second intelligent agent can automatically fill in valid parameter values ​​as much as possible when generating structured workflow data. Only when the parameter values ​​cannot be obtained will placeholders be used for manual supplementation by the vendor. This effectively avoids workflow validation failures caused by missing or incorrect parameter values ​​and improves the automation level of workflow construction.

[0082] In one embodiment of this application, the second intelligent agent can also invoke a store resource retrieval service as needed. When the input data mentions a specific store resource, the second intelligent agent uses a resource semantic description as input (such as natural language expressions like "classic running shoes" or "VIP customer group"), and invokes the store resource retrieval tool to obtain the unique identifier of the resource in the platform. If an exact match cannot be found, the second intelligent agent automatically generates a placeholder tag and informs the merchant of the placeholder content to be replaced in the final response. For example, if the merchant inputs "automatically tag when the order contains 'classic running shoes'", the second intelligent agent invokes the store resource retrieval tool to convert "classic running shoes" into the corresponding product ID and fills it into the workflow node configuration; if there is no product named "classic running shoes" in the platform, a new product ID is generated. Placeholders and inform the merchant that they need to be replaced manually.

[0083] Based on the above embodiments, through the store resource retrieval service, the second intelligent agent can automatically convert store resources mentioned in the merchant's natural language into platform internal resource identifiers. This solves the problem that Large Language Models (LLMs) sometimes create non-existent resource identifiers when generating resource references because they are unaware of the platform's resource distribution. Simultaneously, when an exact match cannot be found, a placeholder is automatically generated and the merchant is notified, allowing the workflow to be saved even if the configuration is incomplete, reducing the frequency of workflow construction interruptions due to resource deficiencies.

[0084] In one embodiment of this application, after obtaining the component information, the second intelligent agent executes differentiated structured data generation logic according to the operation type.

[0085] In one example, if the operation type is to create a workflow, the second agent sets an incrementing node number for each node and establishes directed connections between the nodes in the order of trigger node, condition judgment node, and action execution node.

[0086] For example, assuming the input data is "Automatically issue coupons when the order amount exceeds 500 yuan", the second agent, after task retrieval, identifies three node tasks: "Order Amount Trigger", "Amount Condition Judgment", and "Coupon Issuance Action". Following the topological order of trigger node, condition judgment node, and action execution node, the second agent assigns incremental node numbers to each node, starting from 1. For example, the trigger node is numbered 1, the condition judgment node is numbered 2, and the action execution node is numbered 3. Subsequently, based on the node port identifiers obtained during the configuration query phase, the second agent establishes directed connections between nodes: the output port of the trigger node (node ​​1) is connected to the input port of the condition judgment node (node ​​2), and the output port of the condition judgment node (node ​​2) is connected to the input port of the action execution node (node ​​3). Finally, the second agent generates structured workflow data containing five top-level fields: metadata field (recording workflow name, description, etc.), root trigger node reference field (pointing to node 1), ordered list field of all nodes (containing the complete configuration of nodes 1, 2, and 3), all connection relationship field (recording the connections from node 1 to node 2 and from node 2 to node 3), and the field marked for modification in this operation (empty for creation operation).

[0087] By assigning incremental numbers to each node according to the standard topological order of trigger node, condition judgment node, and action execution node and establishing directed connections, the second agent can build a complete and topologically clear workflow structured data from scratch, ensuring that the workflow JSON conforms to the platform format requirements and that the execution order between each node is correct.

[0088] In one example, if the operation type is to modify the workflow, the second agent obtains the historical structured data of the target workflow from the server, replaces and updates the parameter values ​​corresponding to the modification content indicated by the input data, and retains other nodes not involved in the modification content and the original node numbers unchanged.

[0089] For example, suppose a merchant has previously created an order coupon workflow, and the current input is "change the amount condition from 500 to 300". The second agent first retrieves the historical structured data of this workflow from the server, passing in the workflow's unique identifier and current version number. After parsing the historical structured data, the second agent finds that the workflow contains three nodes: a trigger node (number 1), an amount condition judgment node (number 2, current threshold is 500), and a coupon issuance action node (number 3). The second agent recognizes that the modification indicated by the input data is the parameter value corresponding to the "amount condition", so it only replaces the "threshold" field in the configuration parameters of node 2 from 500 to 300. The configurations of nodes 1 and 3 remain unchanged, and node numbers 1, 2, and 3 remain unchanged. After the modification is completed, the second agent records the field paths involved in this modification in the modified field marker field of the workflow structured data. In this way, the trigger conditions, coupon types, and other content previously manually configured by the merchant are completely preserved, and only the amount threshold is accurately replaced.

[0090] Through a surgical differential modification mechanism, the second agent only replaces the user-specified parameter values ​​while retaining other nodes and their original numbers. This effectively solves the technical problem in existing solutions where AI-modified workflows result in the loss of manually configured data due to overall overwrite. Simultaneously, the modified field paths are recorded in the modified field marker field, making the modification operations traceable and auditable, providing a data foundation for subsequent version comparisons and modification history queries.

[0091] In one example, if the operation type is to modify the workflow and the modification method includes adding a node, the second agent is used to increment the node number of the new node, starting with the largest node number in the historical structured data.

[0092] For example, suppose a merchant inputs "Add an inventory check; do not issue coupons if inventory is insufficient." The second agent retrieves historical structured data from the server and parses it to determine the current maximum node number is 3. The second agent then sets the newly added "Inventory Check" node to node number 4. Simultaneously, based on the port identifier obtained during the configuration query phase, the second agent establishes connections between the new node and existing nodes: connecting the output port of the condition check node (node ​​2) to the input port of the inventory check node (node ​​4), and connecting the output port of the inventory check node (node ​​4) to the input port of the coupon issuance action node (node ​​3). The existing node numbers and configurations remain unchanged.

[0093] By incrementally assigning new node numbers starting with the largest node number in the historical structured data, the new nodes are integrated into the existing workflow structure in an incremental manner, without affecting the numbering and configuration of existing nodes. This ensures the traceability of modification operations and the stability of the structure, and avoids the risk of connection relationship disorder caused by renumbering.

[0094] In one example, if the operation type is to modify the workflow and the modification method includes deleting any node, the second agent is used to delete the connection relationship associated with that node in the historical structured data.

[0095] For example, suppose the merchant inputs "delete the inventory judgment step". The second agent locates the inventory judgment node (node ​​number 4) from the historical structured data, removes this node from the workflow node list, and deletes all connections associated with this node, such as the connection from the condition judgment node (node ​​2) to node 4, and the connection from node 4 to the coupon issuance action node (node ​​3). After deletion, the second agent directly connects the output port of the condition judgment node (node ​​2) to the input port of the coupon issuance action node (node ​​3) to ensure the integrity of the workflow topology. The original node numbers and configurations remain unchanged.

[0096] By simultaneously removing the associated connections when deleting a node and rebuilding the topological connections between the remaining nodes, the second agent ensures that the directed graph structure of the workflow remains intact after the deletion operation, thus avoiding invalid routing or execution anomalies caused by residual connections.

[0097] Based on the above embodiments, through the rigid sequential arrangement of a multi-stage toolchain, such as template-first retrieval, task natural language discovery, dynamic acquisition of task configuration patterns, and mandatory verification of data field paths, the second intelligent agent can dynamically discover available workflow tasks on the platform and obtain their precise configuration constraints without the need for pre-trained knowledge. This effectively solves the problems of task identifier illusion and field path errors when generating workflows using pure pre-trained knowledge. Simultaneously, by clearly distinguishing between creation and update operation modes and adopting differentiated generation logic, the creation mode builds from scratch, while the update mode performs surgical differential modifications. This ensures that the modification operation only replaces the user-specified parameter values ​​while retaining other nodes and their original numbers, avoiding overall overwrite that could lead to the loss of manually configured data. The structured description format of the workflow, in addition to JSON, can also use YAML, XML, Protocol Buffers, or a custom Domain Specific Language (DSL), as long as it can fully express nodes, connection relationships, and configuration parameters and support versioned storage.

[0098] In step S203, the second intelligent agent sends the structured data to the server. The server verifies the structured data. If the verification result returned by the server indicates that there is erroneous data in the structured data, the second intelligent agent corrects the erroneous data and resends the corrected data to the server for verification until the verification result returned by the server indicates that the structured data has passed the verification.

[0099] In one embodiment of this application, after the second intelligent agent completes the construction of the workflow structured data, it calls the workflow persistence tool to submit the generated structured data to the server. After receiving the structured data, the server performs structure verification and configuration validity verification on it.

[0100] In one example, if the operation type is "create workflow," the second agent does not include the workflow identifier and version number parameters when calling the workflow persistence tool. For instance, suppose the input data is "automatically issue coupons when the order amount exceeds 500 yuan." After the second agent completes the structured data construction, it sends the complete workflow structured data to the server, which validates the data. If the validation passes, the server generates a new workflow identifier and assigns an initial version number, for example, version number 1. The creation operation does not involve version number validation, so there is no need to include the version number parameter; the structured data can be submitted directly.

[0101] Based on the above embodiments, the creation operation does not require carrying a version number parameter. The server automatically generates an identifier and assigns an initial version number, realizing the rapid registration and version initialization of new workflows.

[0102] In one example, if the operation type is to modify the workflow, the second agent sends the workflow identifier, current version number, and modified historical structured data corresponding to the input data to the server. The server then verifies whether the current version number is consistent with the latest version number. If the version numbers are inconsistent, the server returns version conflict information to the second agent.

[0103] For example, suppose a merchant has previously created an order coupon workflow with the identifier " The current version number is 3. After the merchant inputs "change the amount condition from 500 to 300", the second intelligent agent completes the modification and sets the workflow identifier to " The current version number 3 and the modified historical structured data are sent to the server. Upon receiving the modification request, the server first queries the local storage for the latest version number based on the workflow identifier "wf_123". If the latest version number is still 3, it means the workflow has not been overwritten by other modification operations since the second agent read it, and the server allows the write, updates the modified structured data to storage, and updates the version number to 4. If the latest version number has already become 4, it means the workflow has been updated by other modification operations, the server rejects this write operation, and returns a version conflict information to the second agent, indicating that the current version is outdated.

[0104] Based on the above embodiments, the optimistic locking mechanism of version number requires that the current version number be included when modifying the workflow. The server verifies the consistency of the version number and allows writing only when they are consistent, which effectively prevents data loss caused by overwriting the latest modification with an expired version in concurrent scenarios.

[0105] In one embodiment of this application, when the server performs validity verification on structured data, if the verification fails, the server returns error data. After receiving the error data returned by the server, the second agent determines a correction strategy based on the error type corresponding to the error data, and corrects the error data according to the correction strategy. The following describes each error type and its correction strategy with specific examples.

[0106] In one example, the error type is "configuration field error," indicating that the configurable parameter value of a node in the structured data does not conform to platform constraints. Examples include a threshold exceeding the allowed range, enumerated field values ​​not being within the selectable range, or a mismatch in field types. For this error type, the second agent determines the corresponding correction strategy as follows: based on the parameter format constraints obtained during the task configuration query phase, identify field values ​​exceeding the allowed range and correct them to the valid range.

[0107] For example, suppose a merchant inputs "automatically issue coupons when order amount exceeds 500 yuan." The second agent generates structured data and submits it to the server for verification. The server returns an error message indicating that the "discount rate" field in the "issue coupon" action node has a value of "105%", which exceeds the allowed range (0% to 100%). After parsing the error data, the second agent identifies the error type as a configuration field error, the error node as the "issue coupon" action node, the error field as "discount rate", and the current value as "105%". Based on this error type, the second agent determines a correction strategy and, according to the parameter format constraints obtained during the task configuration query phase, corrects the "discount rate" value from "105%" to "100%", then resubmits the data.

[0108] Based on the above embodiments, by configuring an automatic correction mechanism for field errors, the second intelligent agent can determine the corresponding correction strategy according to the error type, and accurately identify field values ​​that are out of range and correct them to the valid range according to the parameter format constraints obtained in the task configuration query phase. This allows the verification failure caused by improper parameter values ​​to be automatically repaired without the need for the merchant to manually check and adjust the configuration parameters.

[0109] In another example, the error type is a conditional statement syntax error, indicating that the conditional logical expression in the condition node does not conform to the platform domain-specific language (DSL) syntax specification, such as missing necessary operators, mismatched parentheses, or referencing undefined variables. For this error type, the second agent determines the corresponding correction strategy as follows: identify the missing or incorrect parts of the conditional expression and complete or correct the expression structure according to the platform DSL syntax specification.

[0110] For example, suppose a merchant inputs "change the amount condition to greater than 500 and less than 1000", the second agent modifies the condition judgment node and submits it to the server for verification. The server returns an error message indicating that the condition expression is "order amount". 500 and The error message "1000" does not conform to the platform's DSL syntax specification. After parsing the erroneous data, the second agent identifies the error type as a conditional statement syntax error, the erroneous node as a conditional statement node, and the error content as an incomplete expression syntax. Based on this error type, the second agent determines a correction strategy and rewrites the expression to "order amount" according to the platform's DSL syntax specification. 500 and order amount 1000”, then resubmit after making the corrections.

[0111] Based on the above embodiments, through the automatic correction mechanism for conditional syntax errors, the second intelligent agent can determine the corresponding correction strategy according to the error type, identify incomplete syntax problems in the conditional expression, and automatically complete the expression structure according to the platform's DSL syntax specifications. This allows syntax errors caused by LLM generation or merchant input to be automatically corrected, avoiding abnormal logical judgments during workflow execution due to non-standard conditional expressions.

[0112] In another example, the error type is "loop internal error," indicating a syntax or logic problem within the loop node's configuration, such as an invalid loop condition expression or a non-existent field being referenced within the loop body. For this error type, the second agent determines the corresponding correction strategy as follows: check the data dependency between the loop condition and the loop body action, and adjust the loop condition to a range that the loop body action can correctly reference.

[0113] For example, suppose a merchant inputs "send coupons to every order in the order list," the second agent generates structured data containing loop nodes and submits it to the server for validation. The server returns an error message indicating that the loop condition in the loop node is "order amount." The error message "500" indicates an incorrect configuration that cannot be applied to the "send coupon" action within a loop. After parsing the error data, the second agent identifies the error type as an internal loop error and the node containing the error as a loop node. Based on this error type, the second agent determines a correction strategy and, according to the platform's loop node configuration specifications, checks the data dependencies between the loop condition and the loop action. It adjusts the loop condition to a range that the loop action can correctly reference, completes the correction, and resubmits.

[0114] Based on the above embodiments, through the automatic correction mechanism for loop errors, the second intelligent agent can determine the corresponding correction strategy according to the error type, identify the data dependency mismatch between the loop condition and the loop body action, and automatically adjust the reference scope of the loop condition according to the platform loop node configuration specification, so that complex workflows containing loop logic can be automatically repaired and runtime execution anomalies caused by improper loop configuration can be avoided.

[0115] In another example, the error type is "task identifier not found," indicating that the task identifier referenced in the structured data does not exist in the platform's task library or has been removed. For this error type, the second agent determines the corresponding correction strategy as follows: re-invoke the task retrieval service, search for currently available tasks that semantically match the original task, and replace the original task identifier in the structured data with the new task identifier.

[0116] For example, suppose the second agent obtains a task identifier for the "issuing coupons" action after calling the task retrieval service. However, when it attempts to submit the task, it finds that the task has been removed from the platform, and the server returns error data indicating that the task identifier does not exist. After parsing the error data, the second agent identifies the error type as a "task identifier does not exist" error, determines the corresponding correction strategy, calls the task retrieval service again to search for available tasks that semantically match "issuing coupons," obtains a new task identifier, replaces the original task identifier in the structured data with the new task identifier, completes the correction, and resubmits.

[0117] Based on the above embodiments, through the automatic correction mechanism for errors in task identifiers, the second intelligent agent can determine the corresponding correction strategy according to the error type. When the referenced task has been removed or changed, it automatically retrieves and replaces it with a valid task identifier, thus automatically repairing verification failures caused by platform task updates. This ensures that the workflow always references the platform's currently valid task capabilities, avoiding workflow failures due to invalid task identifiers. Automatic error repair can employ methods such as rule engines (predefined repair rules for common error types), LLM secondary inference (using error information as context for further inference), or human-machine collaboration (only transferring errors that cannot be automatically repaired to the merchant for processing).

[0118] After the second agent completes the correction, it calls the workflow persistence tool again with the corrected structured data and resubmits, until the verification is successful or an informational prompt indicating that automatic correction is not possible is encountered. The second agent does not output erroneous data to the user during the correction process. Once the verification is successful, the target workflow is constructed based on the successful structured data.

[0119] Based on the above overall process, the server-side validation mechanism for structured workflow data enables the detection and location of configuration errors before workflow persistence, preventing problems from being exposed only during actual runtime after incorrect configurations have been written to storage. Through a version number optimistic locking mechanism, modifications to the workflow must include the current version number. The server verifies version number consistency and only allows writing when they match, effectively preventing data loss caused by expired versions overwriting the latest modifications in concurrent scenarios. A second intelligent agent automatically parses and corrects erroneous data in a closed loop, allowing platform-returned errors to be automatically identified and corrected without exposing the original error information to the merchant, thus lowering the barrier to entry and reducing frustration for merchants.

[0120] Step S204: If the verification result returned by the server indicates that the structured data verification is qualified, construct the target workflow corresponding to the input data based on the structured data.

[0121] In one embodiment of this application, after the server verifies the structured data submitted by the second intelligent agent, if the verification is successful, the server constructs the target workflow corresponding to the input data based on the structured data. The target workflow is an instance of automated business rules that can be actually run and invoked in the platform. It includes complete configurations of trigger nodes, condition judgment nodes, and action execution nodes, as well as directed connection relationships between nodes, which can be directly activated and used by merchants or subsequently edited and adjusted. While constructing the target workflow, the server persistently stores the structured data in the data infrastructure and generates a unique identifier and records version information for the workflow.

[0122] In one example, suppose a merchant inputs "automatically issue coupons when the order amount exceeds 500 yuan." The second agent generates, submits, and corrects errors in the structured data. After successful server verification, a coupon workflow is built based on the structured data. This workflow contains three nodes: an order amount trigger (node ​​number 1), an amount condition judgment node (node ​​number 2, threshold 500), and a coupon issuance action node (node ​​number 3, discount rate 10%), as well as directed connections between the nodes. The server generates a unique identifier for this workflow, assigns an initial version number 1, and saves it to the data infrastructure. Merchants can view this workflow on the workflow management page and choose to activate it so that it executes automatically when the trigger condition is met.

[0123] In another example, suppose a merchant inputs "change the amount condition from 500 to 300". After the second agent modifies, submits, and corrects errors in the existing workflow, the server verifies the changes and updates the workflow based on the modified structured data. The server locates the existing record using the workflow identifier, overwrites the original content with the modified structured data, and updates the version number from 1 to 2, completing the update and construction of the target workflow. The merchant can view the updated workflow on the workflow management page, where the amount condition threshold has changed from 500 to 300, while other node configurations and node numbers remain unchanged.

[0124] After confirming the successful construction of the target workflow, the second agent outputs feedback to the merchant. In one example, for creating a workflow, the second agent informs the merchant of the created workflow name, triggering conditions, execution actions, and any content that the merchant needs to manually supplement (if any) in concise language. For example, for the input data "Automatically issue coupons when the order amount exceeds 500 yuan", the second agent can output "An automated workflow for order coupons has been created for you: Automatically issue a 10% discount coupon when the order amount exceeds 500 yuan. Please go to the workflow management page to configure the coupon validity period and scope of use." Throughout the construction process, the merchant does not need to open a visual editor or drag and drop configuration nodes step by step; they can complete the core skeleton of the workflow simply through natural language description. In another example, for modifying a workflow, the second agent can output "The amount condition of the automated workflow for order coupons has been changed from 500 yuan to 300 yuan. Other configurations remain unchanged. You can view and adjust it at any time on the workflow management page." The second agent does not display the original JSON text of the workflow when outputting results, making the response concise and easy to read, allowing merchants to quickly confirm the construction or modification results.

[0125] Based on the above embodiments, the server automatically constructs a runnable target workflow from verified structured data, achieving a complete automated closed loop from natural language requirements to executable instances. Merchants only need to describe their business automation requirements in natural language, the second intelligent agent generates and corrects the structured data, and the server completes the final workflow construction and persistent storage. Throughout the process, merchants do not need to learn how to operate a visual editor or understand the platform's underlying data format, significantly reducing the technical threshold and operational costs of workflow configuration and improving the efficiency of building business automation rules.

[0126] In other embodiments, the second intelligent agent can directly construct the target workflow corresponding to the input data based on the validated structured data. Specifically, after receiving the validated result from the server, the second intelligent agent invokes a workflow persistence tool to store the structured data in the server's data infrastructure, thereby completing the persistent construction of the target workflow. In this embodiment, the second intelligent agent undertakes the role of initiating and executing the construction, while the server only provides storage functionality, returning a successful storage status and a workflow identifier to the second intelligent agent upon successful storage.

[0127] In other embodiments, the construction of the target workflow can also be achieved asynchronously via a message queue. After receiving the successful verification result, the second agent sends the structured data to the message queue, which triggers the server-side construction process to complete the persistent storage of the target workflow. After the server completes persistence, it returns the workflow identifier and storage status to the second agent via the message queue.

[0128] The above methods are all specific implementations of constructing a target workflow based on validated structured data. Whether the construction is performed directly by a second agent or asynchronously triggered via a message queue, the core principle is to convert validated structured data into a runnable workflow instance. Those skilled in the art will understand that any method can be adopted as long as the structured data can be persisted as a runnable workflow instance, and this should not be construed as a limitation on the scope of the technical solution of this application.

[0129] In one embodiment of this application, the workflow construction method based on multi-agents also supports context persistence across requests: when the first agent calls the second agent, the first agent transmits an identifier to the second agent, the identifier being used to identify a workflow construction process of the second agent; in the storage space corresponding to the identifier, the second agent saves the query records and generated structured data during the workflow construction process of this call to the second agent; if the second agent receives the identifier again, it loads the query records and structured data saved in the storage space according to the identifier and continues to execute the workflow construction process corresponding to the identifier.

[0130] In one example, suppose a merchant initially inputs, "Help me create an order coupon workflow that issues a 10% discount coupon when the order amount exceeds 500 yuan." After the first agent recognizes the relevance of this input to the workflow operation, it invokes the second agent and passes in an identifier (e.g., "... The second agent begins construction based on the input data, sequentially executing operations such as template retrieval, task retrieval, configuration query, and path verification, generating structured data containing trigger nodes, condition judgment nodes, and action execution nodes. During the construction process, the second agent saves the query records of this call (such as the retrieved task identifier and the obtained parameter format constraints) and the generated structured data to the identifier "". "In the corresponding storage space, the build task has not yet been submitted."

[0131] Subsequently, in the next round of dialogue, the merchant entered "Change the discount rate to 20%". The first agent then invoked the second agent again, reusing the same identifier. Upon receiving the identifier, the second agent loads the query records and generated structured data stored in the memory space. It then determines that an order coupon workflow is being built, and that the triggers, conditional statements, and action nodes have been identified. Only the "discount rate" parameter of the action node needs modification. The second agent adjusts the "discount rate" from 10% to 8%, and after completing the modification, continues with the subsequent submission and verification process.

[0132] In another example, suppose the merchant inputs "Add an inventory check in the second round; do not issue coupons if inventory is insufficient" in the second round. The second agent reuses the same identifier to load the previous build state, adds an inventory check node to the current workflow, assigns a new node number starting with the largest node number in the historical structured data, establishes a connection between the new node and existing nodes, and submits the changes after making the modifications.

[0133] Based on the above embodiments, through the identifier mechanism, the second intelligent agent can maintain the continuous state of workflow construction across multiple calls. After making an initial request, the merchant can continuously raise adjustment requests in subsequent dialogues. The second intelligent agent can load the intermediate state of the previous construction and continue to complete it using the same identifier, without having to start building from scratch each time, thus achieving a coherent construction experience of "description, construction, adjustment, and iteration".

[0134] In one embodiment of this application, the second intelligent agent also provides a version history list query tool. Merchants can ask in natural language "How many times has my automation been modified?" or "Who modified my workflow yesterday?" After receiving the input data, the second intelligent agent calls the version history list query tool, passes in the workflow identifier, returns the timestamps, statuses, and audit event summaries of all historical versions of the workflow, and summarizes the original audit data into a readable natural language description and returns it to the merchant.

[0135] In one example, the version history list query tool returns information including the version number, commit time, running status (e.g., draft, activated, deactivated) and a summary of the most recent audit event (e.g., "Zhang San modified the amount conditions on August 10, 2026"). The second agent summarizes the above information into a natural language description output.

[0136] In one embodiment of this application, the second intelligent agent also provides a version audit log query tool. The merchant can query "view the modification history of version 3" in natural language. The second intelligent agent calls the version audit log query tool, passes in the workflow identifier and the specified version number, and returns detailed audit events for that version, including a description of the modification content, the modifier's identifier, and the modification timestamp. The agent also summarizes the original audit data into a readable natural language description and returns it to the merchant.

[0137] Based on the above embodiments, through the version history list and audit log query tool, merchants can query the modification history of the workflow in natural language, and understand the change records and modification information of the workflow without entering a dedicated audit interface.

[0138] In one embodiment of this application, when a user request involves periodic data analysis and report sending, the second intelligent agent generates an analysis query statement that conforms to the platform's query language specifications. The second intelligent agent invokes a query field validation tool, inputs the analysis query statement, and obtains the actual field names and types output by the statement, ensuring the validity of references to the query result fields in subsequent workflow action nodes. The second intelligent agent embeds the validated analysis query statement and field references into the configuration parameters of the action execution task, thus creating a closed-loop integration between data analysis queries and workflow automation.

[0139] Based on the above embodiments, the output fields of the analysis query statement are verified by the query field verification tool to ensure that the query result fields can be correctly referenced in subsequent action nodes, and to avoid workflow failure due to incorrect analysis query field names.

[0140] The workflow construction method based on multi-agent provided in this application achieves a complete automated closed loop from natural language requirements to executable instances through the comprehensive application of mechanisms such as a collaborative architecture between the first and second agents, rigid sequential arrangement of multi-stage toolchains, differentiated processing of creation and update modes, server-side verification and automatic repair closed loop, and cross-request context maintenance. Specifically, the first agent is only responsible for coarse-grained intent recognition and delegating specific construction tasks to the second agent, achieving separation of master and slave responsibilities and effectively avoiding the problem of the context window being occupied by a large number of intermediate results when a single agent handles complex tasks. The second agent, through a multi-stage rigid sequential arrangement of template-priority retrieval, task natural language discovery, dynamic acquisition of task configuration patterns, mandatory verification of data field paths, and on-demand retrieval of store resources, can dynamically discover available tasks on the platform and obtain precise configuration constraints without the need for pre-trained knowledge, effectively solving the problems of task identifier illusion and field path inference errors. By clearly distinguishing between creating workflows and modifying existing workflows and employing differentiated generation logic, the update mode only replaces user-specified parameter values ​​while retaining other nodes and their original node numbers. Combined with an optimistic locking mechanism for version numbers, this effectively avoids data overwrite issues caused by manual configuration loss due to overall overwrite and data overwriting problems in concurrent scenarios. Through server-side validity checks and a second intelligent agent, the system automatically parses and corrects various error types, such as configuration field errors, conditional syntax errors, loop errors, and non-existent task identifiers, ensuring automatic repair of validation failures without manual intervention. An identifier mechanism enables cross-request context preservation, allowing merchants to continuously adjust their requirements across multiple rounds of dialogue without having to rebuild from scratch each time. In summary, merchants only need to describe their business automation needs in natural language, without needing to learn how to use a visual editor or understand the platform's underlying data format. This significantly reduces the technical threshold and operational costs of workflow configuration, improving the efficiency and accuracy of business automation rule construction.

[0141] The method provided in this application can be applied not only to the product operation workflow of e-commerce independent websites, but also to e-commerce business scenarios such as warehouse logistics automation (inventory changes trigger replenishment process), customer lifecycle management (customer behavior triggers personalized marketing), financial reconciliation automation (periodic data aggregation and report sending), and content operation automation (product listing triggers social media synchronization), as well as the general business rule automation scenario of Software as a Service (SaaS) platforms.

[0142] Please see Figure 3 This is a flowchart illustrating a multi-agent-based workflow construction method according to another embodiment of this application. The steps described may be omitted, split, have more steps added, or have their execution order adjusted or executed in parallel, depending on the actual application scenario. This embodiment of the application does not impose any limitations on this.

[0143] Step S301: Use the first intelligent agent to obtain the user's input data. If the first intelligent agent determines that the input data is related to the preset workflow operation, use the first intelligent agent to call the second intelligent agent and transmit the input data to the second intelligent agent.

[0144] For detailed implementation methods, please refer to the relevant description in step S201, which will not be repeated here. When the first agent calls the second agent, it passes in at least the input data itself and an optional identifier (i.e., the dialogue continuation identifier). The identifier is used to identify a workflow construction process of the second agent. The complete dialogue context of the first agent is not transparent to the second agent; context isolation is achieved by only passing the input data.

[0145] Based on the above embodiments, the first intelligent agent identifies the workflow intent of the input data, and after successful identification, the second intelligent agent is assigned to execute the specific construction task, thus realizing the separation of responsibilities between the master and slave intelligent agents.

[0146] Step S302: Use the second intelligent agent to determine the operation type corresponding to the input data. The operation type includes creating a workflow or modifying an existing workflow.

[0147] For detailed implementation methods, please refer to the relevant description of "determining the operation type corresponding to the input data" in step S202, which will not be repeated here.

[0148] Step S303: If the operation type is to modify an existing workflow, use the second agent to obtain the identifier and current version number of the workflow corresponding to the input data, and call the workflow definition query tool to obtain the historical structured data of the workflow corresponding to the input data.

[0149] In one example, suppose the merchant inputs "Change the amount condition of the order coupon workflow we just created from 500 to 300". The second agent first parses the input and identifies the target as the "order coupon workflow". The second agent obtains the workflow's identifier (e.g., "wf_123") and current version number (e.g., version 3), calls the workflow definition query tool, passes in the identifier and version number, and retrieves the complete historical structured data of the workflow, including the configuration of all existing nodes, the connection relationships between nodes, and the currently assigned maximum node number. If no identifier or version number is passed, the agent queries the merchant to clarify the target.

[0150] Based on the above embodiments, by obtaining the identifier and current version number of the target workflow and calling the definition query tool, the second intelligent agent can accurately obtain the complete definition of the existing workflow in the modification scenario, providing an accurate data foundation for subsequent surgical differential modifications and avoiding misoperations caused by unclear modification targets.

[0151] Step S304: If the operation type is to create a workflow, the second intelligent agent calls the template retrieval tool, using key phrases describing the user's business objectives as retrieval conditions, and retrieves reference workflow templates that match the user's intent from the platform's pre-built workflow template library.

[0152] For detailed implementation methods, please refer to the relevant description of "template retrieval" in step S202, which will not be repeated here.

[0153] Step S305: The second intelligent agent invokes the task natural language retrieval tool, using the natural language description of the user's business scenario as input, to search for trigger tasks, condition judgment tasks, and action execution tasks that match the current requirements.

[0154] For detailed implementation instructions, please refer to the description of "calling the task retrieval service" in step S202, which will not be repeated here. During a creation operation, all necessary tasks are searched; during an update operation, only the tasks required for adding a new node are searched.

[0155] Step S306: The second agent calls the task configuration query tool, passes in the list of task identifiers, and obtains detailed configuration information for each task, including configurable fields and their data types and constraints, data return fields exposed downstream after task execution, and input / output port identifiers used when connecting nodes.

[0156] For detailed implementation methods, please refer to the relevant description of "calling the configuration query service" in step S202, which will not be repeated here.

[0157] Step S307: The second intelligent agent calls the data field path verification tool, taking the target business object type and field semantic description as input, to obtain the available data field paths under the business object type and confirm whether the reference path to the business data field exists in the structured data.

[0158] For detailed implementation methods, please refer to the relevant description of "calling the path verification service" in step S202, which will not be repeated here.

[0159] Step S308: If the input data mentions a specific store resource, the second agent is used to call the store resource retrieval tool, and the resource semantic description is used as input to obtain the unique identifier of the resource in the platform.

[0160] For detailed implementation methods, please refer to the description of "calling the store resource retrieval service" in step S202, which will not be repeated here.

[0161] Step S309: The second intelligent agent generates structured data for the workflow corresponding to the input data based on the acquired component information.

[0162] If the operation type is workflow creation, the second agent assigns incremental node numbers to each node, starting from 1, according to the order of trigger node, condition judgment node, and action execution node. It then establishes directed connections between nodes based on the acquired port identifiers, generating structured workflow data containing five top-level fields. If the operation type is modifying an existing workflow, the second agent uses the acquired historical structured data as the modification template, only replacing and updating the parameter values ​​corresponding to the modifications indicated by the input data, while retaining other nodes not affected by the modifications and their original node numbers. When modifying an existing workflow requires adding nodes, the second agent increments the node number of the new node, starting with the largest node number in the historical structured data. When modifying an existing workflow requires deleting existing nodes, the second agent simultaneously deletes the connections associated with the existing nodes in the historical structured data. After modification, the second agent records the field paths involved in the modification in the modified field marker field of the workflow structured data.

[0163] For detailed implementation methods, please refer to the relevant descriptions of "creating a workflow scenario" and "modifying a workflow scenario" in step S202, which will not be repeated here.

[0164] Step S310: Use the second agent to call the workflow persistence tool to submit the structured data to the server.

[0165] If the operation type is creating a workflow, the second agent does not carry the workflow identifier and version number parameters when calling the workflow persistence tool. If the operation type is modifying an existing workflow, the second agent sends the workflow identifier corresponding to the input data, the current version number, and the modified historical structured data to the server when calling the workflow persistence tool.

[0166] For detailed implementation methods, please refer to the relevant descriptions of "creating a workflow submission" and "modifying a workflow submission" in step S203, which will not be repeated here.

[0167] Step S311: The server performs a validity check on the structured data and returns the check result.

[0168] For detailed implementation methods, please refer to the relevant description of "server-side verification" in step S203, which will not be repeated here.

[0169] Step S312: If the verification result returned by the server indicates that there is erroneous data in the structured data, the second agent determines the correction strategy based on the error type corresponding to the erroneous data, and corrects the erroneous data according to the correction strategy.

[0170] For detailed implementation methods, please refer to the relevant description of "error correction" in step S203, which will not be repeated here.

[0171] Step S313: The second intelligent agent resends the corrected structured data to the server for verification until the verification result returned by the server indicates that the structured data has passed the verification.

[0172] For detailed implementation methods, please refer to the relevant description of "resubmitting after correction" in step S203, which will not be repeated here.

[0173] Step S314: If the verification result returned by the server indicates that the structured data verification is qualified, construct the target workflow corresponding to the input data based on the structured data.

[0174] For detailed implementation methods, please refer to the relevant description in step S204, which will not be repeated here.

[0175] In step S315, after confirming that the target workflow has been successfully constructed, the second intelligent agent outputs the result feedback to the merchant.

[0176] In one example, for creating a workflow, the second agent informs the merchant of the created workflow name, trigger conditions, execution actions, and any content that the merchant needs to manually supplement (if any) in concise language. For example, for the input data "Automatically issue coupons when the order amount exceeds 500 yuan," the second agent can output "An automated workflow for order coupons has been created for you: Automatically issue a 10% discount coupon when the order amount exceeds 500 yuan. Please go to the workflow management page to configure the coupon's validity period and scope of use." In another example, for modifying a workflow, the second agent can output "The amount condition of the automated workflow for order coupons has been changed from 500 yuan to 300 yuan. Other configurations remain unchanged. You can view and adjust it at any time on the workflow management page." The second agent does not display the original JSON text of the workflow when outputting results, making the response concise and easy to read, allowing merchants to quickly confirm the construction or modification results.

[0177] Based on the above embodiments, the second intelligent agent outputs concise and clear result feedback to the merchant, allowing the merchant to quickly confirm the creation or modification results of the workflow without having to look at the technical details, reducing the merchant's understanding cost and improving the user experience of workflow construction.

[0178] In step S316, the first intelligent agent presents the final processing result returned by the second intelligent agent to the merchant.

[0179] In one example, after receiving feedback from the second agent, the first agent presents the result to the merchant. If the second agent outputs "An automated workflow for order coupons has been created for you: a 10% discount coupon will be automatically issued when the order amount exceeds 500 yuan," the first agent will directly present this information to the merchant without any additional processing.

[0180] Based on the above embodiments, by presenting the processing results of the second intelligent agent to the merchant through the first intelligent agent, it is ensured that the merchant receives the final result in the same interactive channel that initiated the request, thus avoiding the cumbersome operation of switching between different interactive interfaces.

[0181] Based on the above overall process, through a master-slave agent collaboration mechanism, the first agent performs coarse-grained intent recognition and delegation, while the second agent independently undertakes the entire workflow construction task, including operation type judgment, multi-stage toolchain orchestration, structured data generation, server-side submission and verification, automatic error correction, and result feedback output. This achieves separation of responsibilities between the master and slave agents, effectively avoiding the problem of the context window being occupied by a large number of intermediate results when a single agent handles complex tasks. At the same time, in update scenarios, surgical differential modification ensures the integrity of manually configured user data. Server-side verification and automatic repair closed loop lower the technical threshold for merchants, providing them with an efficient, reliable, and low-threshold automated workflow construction experience.

[0182] Figure 4 This is a structural diagram of a multi-agent-based workflow construction system provided in an embodiment of this application.

[0183] The multi-agent workflow construction system 40 may include multiple functional modules, such as agents, composed of computer program segments. The computer programs of each program segment in the multi-agent workflow construction system 40 may be stored in the memory of an electronic device and executed by at least one processor to perform the multi-agent workflow construction function.

[0184] In this embodiment, the multi-agent workflow construction system 40 can be divided into multiple agents based on the functions they perform. An agent is a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. Agents can interact and collaborate through preset interfaces. In this embodiment, the implementation methods of the functions of each agent in the multi-agent workflow construction system 40 can be found in the above-described limitations of the multi-agent workflow construction method, and will not be repeated here.

[0185] A first intelligent agent 401 is used to acquire input data input by the user on the user terminal. If the first intelligent agent determines that the input data is related to a preset workflow operation, it calls a second intelligent agent and transmits the input data to the second intelligent agent. The context data of the input data is not sent to the second intelligent agent along with the input data.

[0186] The second intelligent agent 402 is used to acquire the component information of the workflow corresponding to the input data, and generate structured data of the workflow corresponding to the input data based on the component information; send the structured data to the server, and the server is used to verify the structured data; if the verification result returned by the server indicates that there is erroneous data in the structured data, the second intelligent agent is used to correct the erroneous data, and the corrected data is resent to the server for verification until the verification result returned by the server indicates that the structured data is verified as qualified; if the verification result returned by the server indicates that the structured data is verified as qualified, the target workflow corresponding to the input data is constructed based on the structured data, wherein the verification result is not output to the user terminal during the correction process.

[0187] It should be noted that the first intelligent agent 401 and the second intelligent agent 402 can be implemented by independent computer program segments, or by different subroutine segments in the same computer program segment. The specific configuration can be made according to the actual deployment requirements, and this application embodiment does not limit this.

[0188] Furthermore, the division of the first intelligent agent 401 and the second intelligent agent 402 described above is merely an exemplary implementation of this application. In actual deployment, the number and functional division of each intelligent agent can be flexibly adjusted according to system design requirements. For example, the functions of acquiring user input data and determining whether the input data is related to the workflow operation in the first intelligent agent can be separated from the function of calling the second intelligent agent and executed by two independent intelligent agents respectively; alternatively, all functions of the first and second intelligent agents can be merged into one intelligent agent for execution. This application does not limit the specific number and functional division of intelligent agents; any module division method that can achieve the above-mentioned corresponding functions falls within the protection scope of this application.

[0189] Figure 5 This is a structural diagram of a multi-agent-based workflow construction device provided in an embodiment of this application.

[0190] In some embodiments, the multi-agent-based workflow construction apparatus 50 may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the multi-agent-based workflow construction apparatus 50 may be stored in the memory of an electronic device and executed by at least one processor to perform the function of multi-agent-based workflow construction.

[0191] In this embodiment, the multi-agent workflow construction device 50 can be divided into multiple functional modules according to the functions it performs. These functional modules may include: an intent recognition and delegation module 501, a component acquisition module 502, a structured data generation module 503, a data verification and correction module 504, and a workflow construction module 505. The term "module" in this application refers to a series of computer program segments that can be executed by at least one processor and perform a fixed function, and which are stored in memory. In this embodiment, the functional implementation of each module in the multi-agent workflow construction device 50 can be found in the above-described limitations of the multi-agent workflow construction method, and will not be repeated here.

[0192] The intent recognition and delegation module 501 is used to obtain input data input by the user on the user terminal. If it is determined that the input data is related to a preset workflow operation, the second intelligent agent is invoked and the input data is transmitted to the second intelligent agent. The context data of the input data is not sent to the second intelligent agent along with the input data.

[0193] The component element acquisition module 502 is used to acquire component element information of the workflow corresponding to the input data. Specifically, acquiring the component element information includes: calling the task retrieval service to acquire the workflow node task that matches the input data; calling the configuration query service to acquire the parameter format constraints of the node task; and calling the path verification service to confirm whether the reference path to the business data field exists in the structured data.

[0194] The structured data generation module 503 is used to generate structured data of the workflow corresponding to the input data based on the component information. The workflow corresponding to the input data includes multiple nodes, each node representing a sub-execution unit in the workflow corresponding to the input data. Generating structured data for the workflow corresponding to the input data based on the component information includes: using a second agent to determine the operation type corresponding to the input data, where the operation type represents the type of operation performed on the workflow corresponding to the input data; if the operation type is a modified workflow, obtaining historical structured data of the target workflow from the server, replacing and updating the parameter values ​​corresponding to the modification content indicated by the input data, while retaining other nodes not involved in the modification content and the original node numbers unchanged; if the operation type is a modified workflow and the modification method includes adding nodes, incrementing the node number of the new node starting from the largest node number in the historical structured data; if the operation type is a modified workflow and the modification method includes deleting any node, deleting the connection relationship associated with any node in the historical structured data; if the operation type is a created workflow, setting an incrementing node number for each node in the order of trigger node, condition judgment node, and action execution node, and establishing directed connections between nodes.

[0195] The data verification and correction module 504 is used to send the structured data to the server, and the server is used to verify the structured data; if the verification result returned by the server indicates that there is erroneous data in the structured data, the erroneous data is corrected and the corrected data is resent to the server for verification, until the verification result returned by the server indicates that the structured data has passed the verification.

[0196] The workflow construction module 505 is used to construct the target workflow corresponding to the input data based on the structured data if the verification result returned by the server indicates that the structured data has passed the verification.

[0197] In one embodiment, the device may further include a session resumption module. The session resumption module is configured to transmit an identifier when invoking the second agent, the identifier being used to identify a workflow construction process of the second agent; in the storage space corresponding to the identifier, query records and generated structured data from the current workflow construction process are stored; if the identifier is received again, the query records and structured data stored in the storage space are loaded according to the identifier, and the workflow construction process corresponding to the identifier is continued.

[0198] In one embodiment, the device may further include a version management module. The version management module provides a version history list query tool and a version audit log query tool. The version history list query tool receives a workflow identifier and returns the submission timestamps, running status, and audit event summaries of all historical versions of the workflow. The version audit log query tool receives a workflow identifier and a specified version number and returns detailed audit events for that version. Upon receiving a user's natural language audit query, the module invokes the aforementioned query tools to obtain raw audit data and summarizes the raw audit data into a natural language description, returning it to the user.

[0199] It should be noted that the intent recognition and delegation module 501, the component element acquisition module 502, the structured data generation module 503, the data verification and correction module 504, and the workflow construction module 505 can be implemented by independent computer program segments, or by different subroutine segments within the same computer program segment. The specific configuration can be made according to actual deployment requirements, and this application embodiment does not limit this.

[0200] Furthermore, the above-described module division is merely one exemplary implementation of this application. In actual deployment, the number and functional division of each module can be flexibly adjusted according to system design requirements. For example, the functions of task retrieval, configuration query, and path verification in the component acquisition module can be split into three independent modules for separate execution; alternatively, the data verification and correction module and the workflow construction module can be merged into one module to simultaneously perform verification, correction, and construction functions; or the functions of all modules can be merged into one module for execution. This application does not limit the specific number and functional division of modules; any module division method that can achieve the corresponding functions described above falls within the protection scope of this application.

[0201] Another embodiment of this application also provides an electronic device. Figure 1 The application environment described is merely one example. In other exemplary embodiments, computer program products implementing the multi-agent-based workflow construction method of this application can also run on any electronic device with sufficient computing power (such as...). Figure 6 In the electronic device shown, the various steps of the multi-agent-based workflow construction method are executed, thereby providing the functionality of multi-agent-based workflow construction.

[0202] Please see Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6As shown, in one embodiment of this application, the electronic device 8 can be a mobile phone, tablet computer, smart wearable device, augmented reality (AR) / virtual reality (VR) device, laptop computer, netbook, etc. This application embodiment does not impose any restrictions on the specific type of electronic device 8.

[0203] like Figure 6 As shown, the electronic device 8 may include, but is not limited to, a communication module 81, a memory 82, a processor 83, an input / output (I / O) interface 84, and a bus 85. The processor 83 is coupled to the communication module 81, the memory 82, and the I / O interface 84 via the bus 85.

[0204] Those skilled in the art will understand that the schematic diagram is merely an example of electronic device 8 and does not constitute a limitation on electronic device 8. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 8 may also include network access devices, etc.

[0205] The communication module 81 may include a wired communication module and / or a wireless communication module. The wired communication module may provide one or more wired communication solutions such as Universal Serial Bus (USB) and Controller Area Network (CAN). The wireless communication module may provide one or more wireless communication solutions such as Wireless Fidelity (Wi-Fi), Bluetooth (BT), mobile communication networks, Frequency Modulation (FM), Near Field Communication (NFC), and Infrared (IR) technologies.

[0206] The memory 82 can be used to store computer-readable instructions and / or modules. The processor 83 implements various functions of the electronic device 8 by running or executing the computer-readable instructions and / or modules stored in the memory 82 and by calling the data stored in the memory 82. The memory 82 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device 8, etc. The memory 82 may include non-volatile and volatile memory, such as: hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other storage devices.

[0207] The memory 82 can be the external memory and / or internal memory of the electronic device 8. Furthermore, the memory 82 can be a memory in physical form, such as a memory stick, a TF card (Trans-flash Card), etc.

[0208] Processor 83 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. Processor 83 is the computational core and control center of electronic device 8, connecting various parts of the entire electronic device 8 through various interfaces and lines, and executing the operating system of electronic device 8, as well as various installed application programs and program code.

[0209] For example, computer-readable instructions can be divided into one or more modules / submodules / units, which are stored in memory 82 and executed by processor 83 to complete this application. One or more modules / submodules / units can be a series of computer-readable instruction segments capable of performing a specific function, which describe the execution process of the computer-readable instructions in electronic device 8. For example, computer-readable instructions can be divided into the modules described above.

[0210] If the modules / units integrated in the electronic device 8 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium, and when executed by a processor, they can implement the steps of the various method embodiments described above.

[0211] Computer-readable instructions include computer-readable instruction code, which can be in the form of source code, object code, executable file, or some intermediate form. Computer-readable media can include: any entity or device capable of carrying computer-readable instruction code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), and random access memory (RAM).

[0212] In conjunction with the above embodiments, the memory 82 in the electronic device 8 stores computer-readable instructions, and the processor 83 can execute the computer-readable instructions stored in the memory 82 to implement the method described in the above embodiments. Specifically, the specific implementation method of the above computer-readable instructions by the processor 83 can be found in the description of the relevant steps in the above embodiments, and will not be repeated here.

[0213] I / O interface 84 is used to provide a channel for user input or output. For example, I / O interface 84 can be used to connect various input and output devices, such as mouse, keyboard, touch device, display screen, etc., so that users can enter information or visualize information.

[0214] Bus 85 is used at least to provide a channel for communication between communication modules 81, memory 82, processor 83, and I / O interface 84 in electronic device 8.

[0215] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0216] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0217] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0218] Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No appended diagram markings in the claims should be construed as limiting the scope of the claims.

[0219] Furthermore, it is clear that the word "including" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices can also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

[0220] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A workflow construction method based on multi-agent systems, characterized in that, The method includes: The first intelligent agent acquires the user's input data. If the first intelligent agent determines that the input data is related to a preset workflow operation, the first intelligent agent calls the second intelligent agent and transmits the input data to the second intelligent agent. The second intelligent agent is used to obtain the component information of the workflow corresponding to the input data, and the structured data of the workflow corresponding to the input data is generated based on the component information. The structured data is sent to the server using the second intelligent agent. The server verifies the structured data. If the verification result returned by the server indicates that there is erroneous data in the structured data, the second intelligent agent corrects the erroneous data and resends the corrected data to the server for verification until the verification result returned by the server indicates that the structured data has passed the verification. If the verification result returned by the server indicates that the structured data has passed verification, the target workflow corresponding to the input data is constructed based on the structured data.

2. The workflow construction method based on multi-agent technology according to claim 1, characterized in that, The step of using the second intelligent agent to obtain the component information of the workflow corresponding to the input data includes: The second intelligent agent is used to call the task retrieval service to obtain the node tasks of the workflow corresponding to the input data; The second intelligent agent is used to call the configuration query service to obtain the parameter format constraints of the node task; The second intelligent agent invokes the path verification service to determine the existence of reference paths to business data fields in the structured data.

3. The workflow construction method based on multi-agent technology according to claim 1, characterized in that, The workflow corresponding to the input data includes multiple nodes, each node representing a sub-execution unit in the workflow corresponding to the input data; generating structured data for the workflow corresponding to the input data based on the component information includes: The second intelligent agent is used to determine the operation type corresponding to the input data, where the operation type represents the type of operation to be performed on the workflow corresponding to the input data. If the operation type is to modify the workflow, the second agent obtains the historical structured data of the target workflow from the server, replaces and updates the parameter values ​​corresponding to the modification content indicated by the input data, and retains other nodes not involved in the modification content and the original node numbers unchanged.

4. The workflow construction method based on multi-agent technology according to claim 3, characterized in that, The step of generating structured workflow data corresponding to the input data based on the component information further includes: If the operation type is the modified workflow and the modification method includes adding a node, the second agent is used to increment the node number of the new node, starting with the largest node number in the historical structured data. If the operation type is the modified workflow and the modification method includes deleting any node, the second agent is used to delete the connection relationship associated with any node in the historical structured data.

5. The workflow construction method based on multi-agent technology according to claim 3, characterized in that, The step of generating structured workflow data corresponding to the input data based on the component information further includes: If the operation type is to create a workflow, the second agent sets an incrementing node number for each node and establishes directed connections between nodes in the order of trigger node, condition judgment node, and action execution node.

6. The workflow construction method based on multi-agent technology according to claim 3, characterized in that, The step of using the second intelligent agent to send the structured data to the server includes: If the operation type is the modified workflow, the second agent sends the workflow identifier, current version number, and modified historical structured data corresponding to the input data to the server, so that the server verifies whether the current version number is consistent with the latest version number. If the version numbers are inconsistent, the server returns version conflict information to the second agent.

7. The workflow construction method based on multi-agent technology according to claim 1, characterized in that, The step of using the second intelligent agent to correct the erroneous data includes: The second intelligent agent determines a correction strategy based on the error type corresponding to the erroneous data. The erroneous data is corrected according to the correction strategy, wherein the second intelligent agent does not output the erroneous data to the user terminal during the correction process.

8. The workflow construction method based on multi-agent technology according to claim 1, characterized in that, The method further includes: When the first agent calls the second agent, the first agent transmits an identifier to the second agent, the identifier being used to identify a workflow construction process of the second agent; In the storage space corresponding to the identifier, the second agent is used to save the query records and generated structured data during the workflow construction process of this call to the second agent; If the second agent receives the identifier again, it loads the query records and structured data stored in the storage space according to the identifier and continues to execute the workflow construction process corresponding to the identifier.

9. A workflow construction system based on multi-agent systems, characterized in that, The system includes: A first intelligent agent is used to acquire input data entered by the user on the user terminal. If the first intelligent agent determines that the input data is related to a preset workflow operation, the first intelligent agent calls a second intelligent agent and transmits the input data to the second intelligent agent. The context data of the input data is not sent to the second intelligent agent along with the input data. The second intelligent agent is used to acquire the component information of the workflow corresponding to the input data, and generate structured data of the workflow corresponding to the input data based on the component information; send the structured data to the server, and the server is used to verify the structured data; if the verification result returned by the server indicates that there is erroneous data in the structured data, the second intelligent agent is used to correct the erroneous data, and the corrected data is resent to the server for verification until the verification result returned by the server indicates that the structured data is verified as qualified; if the verification result returned by the server indicates that the structured data is verified as qualified, the target workflow corresponding to the input data is constructed based on the structured data, wherein the verification result is not output to the user terminal during the correction process.

10. An electronic device, characterized in that, include: Memory, and A processor that executes computer-readable instructions stored in the memory to implement the multi-agent-based workflow construction method as described in any one of claims 1 to 8.