A workflow parameter processing and management method and system supporting agent multiplexing

Abstract

The application provides a workflow parameter processing and management method and system supporting agent multiplexing, and belongs to the technical field of data processing, and specifically comprises the following steps: an instance construction module sets a static configured slot value in an execution instance or sets a corresponding slot value for a matching user according to a recognition result of the matching user; an agent binding module binds reusable agent units to each task node in the execution instance; a parameter injection module is used to merge the extracted parameter value and the slot value in the execution instance according to a priority before executing a current task node, so as to construct an execution context of the current task node; and a resource loading module is used to acquire actual data of the multimedia resource on demand according to resource meta-information injected in the execution context during execution of the current task node, thereby improving the multiplexing degree and the adaptation degree of the agent construction processing.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to a method and system for processing and managing workflow parameters that supports the reuse of intelligent agents. Background Technology

[0002] Agent workflow technology is a crucial component of agent systems. By organizing multiple agent nodes into a directed acyclic graph (DAG), it automates complex business processes. Currently, various agent workflow platforms exist on the market, supporting workflow construction through visual interfaces, including features such as task nodes, conditional routing, and loop execution. These platforms provide enterprises with low-code or no-code agent application development capabilities, lowering the development threshold for agent applications. However, the aforementioned technical solutions have the following drawbacks: Intelligent agents are not reusable, and repetitive configuration is labor-intensive. Existing systems require each intelligent agent node to be individually configured with large language model parameters, system prompts, tool lists, and other information when creating workflows. This design has the following problems: First, when multiple workflows need to use intelligent agents with the same configuration, existing intelligent agent configurations cannot be reused, requiring repeated configuration of the same parameters, resulting in high development and maintenance costs; second, intelligent agent configuration is tightly coupled with workflow definitions, making it difficult to achieve independent management and version control of intelligent agents.

[0003] Integrating external agents is difficult and costly. Existing systems primarily support building and executing agents within the local platform. When it's necessary to call existing agents or workflows from other platforms, the following problems arise: First, there's a lack of standardized integration mechanisms, requiring developers to write specialized adaptation code for different platform application programming interfaces (APIs), resulting in a large integration workload. Second, the interface formats, parameter passing methods, and return result structures differ across platforms, making it difficult to guarantee the stability and consistency of the calls. Third, it's impossible to directly reuse the capabilities of agents already built on other platforms, leading to redundant development and wasted resources.

[0004] Therefore, there is an urgent need for a workflow parameter processing and management method and system that supports the reuse of intelligent agents. Summary of the Invention

[0005] To achieve the objectives of this invention, the following technical solution is adopted: Specifically, this application provides a workflow parameter processing and management system that supports agent reuse, including: The instance building module is responsible for obtaining predefined workflow templates, creating independent execution instances based on the workflow templates, setting statically configured slot values ​​in the execution instances, or setting corresponding slot values ​​for matching users based on the identification results of matching users; The agent binding module binds reusable agent units to each task node in the execution instance. Each task node inherits the complete configuration of the agent unit by referencing the agent identifier, and dynamically injects specific task descriptions during execution. The parameter injection module is used to automatically parse the dependency relationship of the task node according to the edge structure defined in the workflow template before executing the current task node, extract parameter values ​​from the output data of the upstream task nodes that have been executed, and obtain the currently missing parameter values ​​from the user dialogue history using an incremental extraction method. The extracted parameter values ​​are then merged with the slot values ​​in the execution instance according to priority to construct the execution context of the current task node. The resource loading module is used to, during the execution of the current task node, when the intelligent agent unit needs to access multimedia resources, obtain the actual data of the multimedia resources as needed based on the resource metadata injected in the execution context.

[0006] Furthermore, the instance construction module includes: The template parsing unit is used to parse the node configuration, edge definition, and variable definition in the workflow template to generate a directed acyclic graph structure. An instantiation unit is used to create independent execution instances based on the directed acyclic graph structure and generate globally unique instance identifiers and execution identifiers; The slot configuration unit is used to receive static configuration parameters and persistently store them as slot values ​​of the execution instance.

[0007] Furthermore, the agent binding module supports two types of agents: built-in agents and external agents, wherein: For built-in agents, the agent binding module loads pre-configured inference and action agent instances from the local agent registry; For external intelligent agents, the intelligent agent binding module obtains the interface definition and parameter mode of the external intelligent agent through the standard protocol interface, and establishes a protocol adaptation layer to perform data format conversion.

[0008] Secondly, this invention provides a workflow parameter processing and management method that supports agent reuse, applied to the aforementioned workflow parameter processing and management system that supports agent reuse, specifically including: S1 determines the replacement data of the slot value of the execution instance based on the execution status of the execution instance, determines the replacement execution process of different slot values ​​based on the replacement data, and determines the matching analysis requirement instance in the execution instance based on the replacement execution process of different slot values ​​in different execution instances and the execution data of the execution instance. S2 determines the update identification scheme for the matching user of the matching analysis requirement instance based on the queuing processing delay of different execution instances and the replacement data of the slot value of the matching analysis requirement instance. S3 uses the instance update scheme to update the matching users of different matching analysis requirement instances, uses the matching users to determine the update matching instances and update deviation instances in the matching analysis requirement instances, and based on the composition of the update matching instances and update deviation instances, when it is determined that the update restriction processing of the matching users needs to be performed, proceed to the next step. S4 utilizes the update identification scheme of matching users for different matching analysis requirement instances to determine the monitoring and analysis method for the slot value of the updated matching instance.

[0009] Furthermore, the replacement data for the slot value of the execution instance is determined based on the number of times the slot value of the execution instance is replaced during the execution process.

[0010] Furthermore, the method for determining the matching analysis requirement instance in the execution instance is as follows: The replacement data in S11 determines the execution process in which the slot value of the execution instance is replaced during execution, and the execution process in which the replacement occurs is taken as the replacement execution process; S12 determines the replacement frequency coefficient of the execution instance at different slot values ​​based on the replacement execution process during the execution process of the execution instance at different slot values; S13 uses the replacement frequency coefficient of different execution instances in different slot values ​​and execution data to determine the matching analysis requirement instance in the execution instance.

[0011] The beneficial effects of this invention are as follows: Based on the shortcomings of existing technologies, this invention proposes an innovative solution that significantly improves the system's usability, development efficiency, and application value. Specific advantages are as follows: I. Template and Instance Separation Reduces Development Costs. By establishing a clear separation mechanism between templates and instances, this invention achieves efficient workflow reuse. Templates define reusable workflow structures and can be instantiated multiple times, each instantiation creating an independent execution instance. The same template can create multiple instances with different default configurations, meeting diverse usage needs through a slot value mechanism. Templates can be published to a template marketplace for other users, avoiding the duplication of developing identical workflows. Compared to existing systems that require recreating workflows for each scenario, the template and instance separation mechanism significantly reduces development and maintenance costs and improves workflow reusability.

[0012] II. Improved Configuration Efficiency Through Agent Reuse. This invention enables independent management and cross-workflow reuse of agents. Users can directly use pre-configured built-in agents without reconfiguring large language model parameters, system prompts, tool lists, etc. Integration with external agents is supported through standard protocols, allowing users to call existing agents or workflows from other platforms without writing adaptation code. The agent marketplace mechanism allows users to add marketplace agents to workflows via drag-and-drop, enabling rapid reuse. Compared to existing systems that require separate configuration for each agent node, the agent reuse mechanism significantly improves configuration efficiency and reduces repetitive configuration work.

[0013] III. Automatic Parameter Mapping Simplifies Development. This invention achieves automatic parameter mapping between nodes through automatic dependency resolution and context construction, eliminating the need for developers to manually configure parameter passing relationships. The system automatically resolves node dependencies, extracts the output of upstream nodes from the execution state, and constructs the node execution context, allowing nodes to directly access upstream data and resources. Intelligent reference resolution supports using concise reference syntax in node configurations to reference upstream data, which the system automatically parses and replaces. Compared to existing systems that require configuring the input parameter sources for each node individually, the automatic parameter mapping mechanism significantly simplifies development, reduces configuration errors, and improves development efficiency.

[0014] IV. Incremental Parameter Extraction Improves Response Speed. This invention employs an incremental extraction strategy to extract the parameters required for the workflow from multi-turn dialogues, analyzing only newly added message content and missing parameters, avoiding repeated analysis of already processed dialogue content. In a ten-turn dialogue scenario, the number of large language model call tokens extracted incrementally is approximately 30% of that in full analysis, reducing response latency by over 60%. The parameter locking mechanism prevents automatic re-extraction after complete parameter extraction, effectively preventing the large language model from misinterpreting user intent. The incremental parameter extraction mechanism significantly improves response speed and system reliability, enhancing the user experience.

[0015] V. Automated Resource Processing Simplifies Development. This invention utilizes a three-layer automatic identification mechanism (pattern marking, type detection, and heuristic recognition) to automatically identify and extract multimedia resources from node outputs, achieving a resource identification accuracy of over 95% and a coverage rate of over 98%. The system automatically handles resource format conversion, storage deduplication, and access address generation, eliminating the need for developers to write dedicated processing code. Resources flow automatically between nodes and can be accessed via reference syntax, without the need to manually pass resource identifiers or access addresses. Compared to existing systems that require writing dedicated identification and conversion code for different resource formats, the automated resource processing mechanism significantly simplifies the development process and reduces code complexity and maintenance costs.

[0016] VI. By utilizing the slot value replacement data of different execution instances, the frequency of slot value replacement processing for different execution instances is determined. Based on the frequency of slot value replacement processing for different execution instances, the matching analysis requirement instances are identified. This lays the foundation for building corresponding matching users for the matching analysis requirement instances, thereby reducing the frequency of slot value replacement processing and improving the execution efficiency of execution instances.

[0017] Other features and advantages will be set forth in the following description, and the objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] The above and other features and advantages of the present invention will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0020] Figure 1 This is a framework diagram of a workflow parameter processing and management system that supports agent reuse; Figure 2 This is a flowchart of the execution method of the intelligent agent compiler; Figure 3 This is a flowchart of the execution method for the incremental parameter extraction strategy; Figure 4 It is a flowchart of a workflow parameter processing and management method that supports the reuse of intelligent agents. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0022] Example 1 like Figure 1 As shown, this application provides a workflow parameter processing and management system that supports agent reuse, specifically including: The instance building module is responsible for obtaining predefined workflow templates, creating independent execution instances based on the workflow templates, setting statically configured slot values ​​in the execution instances, or setting corresponding slot values ​​for matching users based on the identification results of matching users; The agent binding module binds reusable agent units to each task node in the execution instance. Each task node inherits the complete configuration of the agent unit by referencing the agent identifier, and dynamically injects specific task descriptions during execution. The parameter injection module is used to automatically parse the dependency relationship of the task node according to the edge structure defined in the workflow template before executing the current task node, extract parameter values ​​from the output data of the upstream task nodes that have been executed, and obtain the currently missing parameter values ​​from the user dialogue history using an incremental extraction method. The extracted parameter values ​​are then merged with the slot values ​​in the execution instance according to priority to construct the execution context of the current task node. The resource loading module is used to, during the execution of the current task node, when the intelligent agent unit needs to access multimedia resources, obtain the actual data of the multimedia resources as needed based on the resource metadata injected in the execution context.

[0023] Furthermore, the instance construction module includes: The template parsing unit is used to parse the node configuration, edge definition, and variable definition in the workflow template to generate a directed acyclic graph structure. An instantiation unit is used to create independent execution instances based on the directed acyclic graph structure and generate globally unique instance identifiers and execution identifiers; The slot configuration unit is used to receive static configuration parameters and persistently store them as slot values ​​of the execution instance.

[0024] In one possible specific implementation, a clear separation mechanism between templates and instances is established to achieve efficient workflow reuse. The core includes: I. Template Definition: A template is a reusable workflow definition that contains structured information such as node configuration, edge definition, and variable definition. The template defines the execution logic and data flow rules of the workflow, but does not contain specific execution parameters. The template can be instantiated multiple times, and each instantiation creates an independent execution instance. The template supports version management and can be published to the template marketplace for other users to use. 2. Instance Creation: An instance is a specific execution object created based on a template. It contains the complete definition of the template and specific execution parameters. After the user selects a template, the system automatically creates an instance and generates a unique instance identifier. The instance inherits all the configurations of the template and can override some parameters to adapt to specific scenarios. The instance supports multiple executions, and each execution generates an independent execution identifier and session identifier. 3. Static configuration mechanism: Static configuration is a template-level parameter preset, called slot value. Slot value is set when the instance is created and takes effect on all executions of the instance. Slot value can contain information such as commonly used model parameters, tool configurations, and default variable values. Through the slot value mechanism, multiple instances with different default configurations can be created from the same template to meet differentiated usage needs. IV. Parameter Inheritance and Overriding: Instance parameters inherit the variable definitions of the template, including parameter name, parameter type, whether it is required, default value, etc. Instances can override the default values ​​of the template through slot values, and during execution, they can override slot values ​​through runtime parameter values. This layered parameter mechanism not only ensures the generality of the template, but also provides flexibility for instances and execution. Furthermore, the agent binding module supports two types of agents: built-in agents and external agents, wherein: For built-in agents, the agent binding module loads pre-configured inference and action agent instances from the local agent registry; For external intelligent agents, the intelligent agent binding module obtains the interface definition and parameter mode of the external intelligent agent through the standard protocol interface, and establishes a protocol adaptation layer to perform data format conversion.

[0025] Specifically, the agent binding module enables independent management and cross-workflow reuse of agents. Through the design of separating agents from tasks, it supports the unified integration of built-in and external agents. The core components include: I. Separation of Agent and Task: The system separates the capability definition of an agent from the specific task execution. The agent is a reusable capability unit, and the task is a specific execution target. The agent definition includes reasoning ability, tool ability and model configuration, but does not include a specific task description. The task node dynamically injects the task description during execution and calls the agent to complete the task. This separation mechanism allows the same agent to be reused in different task nodes without having to repeatedly configure the agent's basic capabilities.

[0026] II. Built-in Reasoning and Action Agents: The system provides pre-configured reasoning and action agents as the underlying capability engine, integrating standard system prompts and commonly used built-in tools. These agents implement complete reasoning loop logic, including three stages: thinking, acting, and observing. They support multi-round tool calls and autonomous decision-making. When creating an agent, users only need to configure three core parameters: model parameters (large language model type, temperature, maximum token count, etc.), goal definition (agent role and capability description), and tool capabilities (selecting the required tool list). The system automatically combines the user configuration with the underlying reasoning and action agents to generate executable agent instances. This mechanism significantly reduces the configuration complexity of agents; users do not need to understand the implementation details of the reasoning loop, but only need to focus on business goals and tool selection.

[0027] 3. Parameterized reuse of agents: The configured agents can be reused in multiple workflows and task nodes. When each task node references an agent, it only needs to specify the agent identifier and the specific task description. The agent's model parameters, tool list and other configurations are automatically inherited. The agent configuration is decoupled from the task execution. When it is necessary to adjust the agent's capabilities, only the agent configuration needs to be modified, and all task nodes that reference the agent will automatically take effect.

[0028] IV. External Agent Integration: The system supports the integration of external agents through standard protocols. It can call existing agents or workflows from other platforms. External agents register with the system via standard protocols, and the system automatically obtains information such as the external agent's interface definition, parameter mode, and return format. When configuring external agent nodes in a workflow, users only need to select the registered external agent; the system automatically handles protocol conversion and data adaptation, eliminating the need for writing adaptation code. External agents and built-in agents use a unified calling interface, achieving seamless integration.

[0029] V. Intelligent Agent Marketplace: The system establishes an intelligent agent market mechanism, where users can publish their configured intelligent agents to the market for use by other users. The intelligent agents in the market contain complete configuration information (model parameters, target definition, tool list) and usage instructions. Users can add intelligent agents from the market to their workflows by dragging and dropping, enabling rapid reuse. The intelligent agent market supports version management and access control to ensure the security and traceability of intelligent agents.

[0030] Specifically, such as Figure 2 As shown, the agent binding module includes an agent compiler, and the execution method of the agent compiler specifically includes: During the workflow construction phase, all task nodes in the execution instance are traversed. The corresponding agent type is determined based on the agent identifier referenced by each task node; Select a matching compiler according to the agent type, combine the agent's configuration with the underlying execution engine, and generate an executable agent instance; The compiled agent instances are cached in the execution engine for reuse by multiple task nodes within the same execution instance.

[0031] Specifically, the agent compilation mechanism is as follows: During the workflow construction phase, the system pre-compiles all agent nodes, loads the large language model configuration and tool list, and adopts the factory pattern to select the corresponding compiler according to the agent type (built-in agent, external agent) to generate executable agent instances. For built-in reasoning and action agents, the compiler combines the user-configured model parameters, target definitions, tool list and underlying reasoning loop logic to generate complete system prompts and tool call configurations. The compiled agents are cached in the execution engine to avoid repeated loading and improve execution efficiency.

[0032] Furthermore, the parameter injection module includes a dependency resolver, specifically comprising: Before the current task node is executed, the edge structure defined in the workflow template is parsed to identify all parent nodes pointing to the current task node; Extract the output data of each parent node from the node history of the execution state, and construct an upstream output mapping with the parent node identifier as the key and the node output object as the value; If the current task node does not have any parent node, then the upstream output mapping is empty.

[0033] Specifically, the automatic parameter mapping and extraction mechanism enables automatic parameter mapping between nodes and intelligent parameter extraction in multi-turn dialogues, eliminating the need for manual configuration of parameter passing relationships. The core of this mechanism includes: Before a node is executed, the system automatically resolves the node's dependencies, identifies all parent nodes pointing to the current node from the edges defined in the workflow, and the dependency resolver traverses the list of parent nodes, extracts the output data of each parent node from the node history of the execution state, and constructs an upstream output mapping. The upstream output mapping uses the node identifier as the key and the node output object as the value, containing the complete output content and resource list of the node.

[0034] Furthermore, the parameter injection module also includes a context builder, which is used for: The slot values ​​in the execution instance are merged with the parameter values ​​extracted from the dialogue history according to priority to generate workflow variables; Extract all resource objects from the upstream node output generated by the dependency resolver and flatten them into resource mappings from resource identifiers to resource objects; The workflow variables, the upstream output mapping, and the resource mapping are used to construct the execution context of the current task node.

[0035] Specifically, the system automatically constructs the execution context using the context builder. Based on the dependency resolution results, the system automatically constructs the node execution context. The node context includes workflow variables (the combined result of runtime parameter values ​​and slot values), upstream node outputs (the output mapping of all parent nodes), and resource mappings (all resources extracted from the upstream outputs, flattened into a mapping from resource identifiers to resource objects). When the node is executed, the system automatically injects the context into the node's execution environment. The node can directly access upstream data and resources without manual transfer.

[0036] Furthermore, such as Figure 3 As shown, the parameter injection module adopts an incremental parameter extraction strategy, and the execution method of the incremental parameter extraction strategy specifically includes: The parameter status recording unit is used to record the identifier of the last dialogue message corresponding to the last parameter extraction process and the set of parameters that have been extracted. The incremental analysis unit is used to obtain only the newly added message content after the last dialogue message identifier when parameter extraction is triggered, and to calculate the difference between the set of required parameters defined in the current workflow and the set of extracted parameters to obtain the missing parameter subset. A parameter extraction agent is used to call a large language model to extract parameter values ​​from the newly added message content only for the subset of missing parameters.

[0037] It's important to note that in multi-turn dialogue scenarios, the system employs an incremental extraction strategy to extract the parameters required for the workflow from the dialogue history. The system records the identifier of the last message processed during the previous parameter extraction. During the current extraction, only newly added message content is analyzed. The system compares the parameter list defined in the workflow with the already extracted parameter set to calculate the currently missing parameter subset. The parameter extraction agent only extracts the missing parameters. Incremental extraction avoids repeatedly analyzing already processed dialogue content, significantly reducing computational overhead and response latency.

[0038] Furthermore, the parameter injection module also includes a parameter locking unit, which is used for: When the missing parameter subset is empty and all required parameters have been extracted completely, the parameter validation completion flag is set to true in the metadata of the execution status and persistently stored in the checkpoint storage. Once the parameter verification is completed and marked as true, ignore the automatic parameter extraction requests triggered by subsequent user dialogues and directly use the locked parameter values ​​to construct the execution context.

[0039] It's important to note that the system maintains a parameter validation completion flag in the execution status metadata, initially set to false. Once all required parameters have been extracted, the system sets the flag to true and persists it to the checkpoint storage. After parameter locking, subsequent user input in the dialogue will no longer trigger automatic parameter extraction; the system directly uses the locked parameter values ​​to execute the workflow. This parameter locking mechanism effectively prevents the large language model from misinterpreting user intent, avoids accidental parameter modification, and improves the system's reliability and predictability.

[0040] Furthermore, the priority order when the parameter injection module performs priority merging is as follows: the parameter value extracted from the user's dialogue history has the highest priority, the slot value in the execution instance has the second highest priority, and the default value defined in the workflow template has the lowest priority; high-priority parameter values ​​override parameters with the same name in low-priority parameter values.

[0041] Specifically, the system supports merging parameters from multiple sources and processes parameter values ​​from different sources according to priority. Parameter values ​​extracted from the dialogue have the highest priority and can override slot values ​​and default values; slot values ​​have the second highest priority and can override default values; default values ​​have the lowest priority and are only used when parameters are missing. The system uniformly processes text parameters and file parameters to generate a complete set of runtime parameter values, ensuring the integrity and consistency of parameters.

[0042] Furthermore, the resource loading module includes: The three-layer resource identification unit is used to automatically identify resource candidates from the output data of task nodes, specifically including: The pattern tag recognition layer locates resource fields based on predefined field pattern tags in the output data; The type detection and recognition layer analyzes the format characteristics of field values ​​and identifies Uniform Resource Locators (URLs), Data Uniform Resource Locators (DURLs), or hexadecimal encoding formats. The heuristic recognition layer identifies resource candidates based on keyword matching of field names and statistical features of value formats. The resource conversion unit is used to convert resource candidates of different formats into a unified resource object, wherein the resource object includes resource identifier, file name, media type, file size and access address; The resource storage unit is used to persist the unified resource object to an object storage service or a local file system and generate a time-sensitive access address.

[0043] Establish a complete process for automatic resource identification, conversion, storage, and referencing, eliminating the need for manually writing resource processing code. The core components include: I. Three-Layer Automatic Identification: The system employs a three-layer identification mechanism to automatically identify and extract resources from node output. The first layer is pattern tag identification. When a node defines an output pattern, the system accurately locates resource fields based on the pattern tag and extracts the field values ​​as candidate resources, achieving the highest confidence score. The second layer is type detection identification. The system analyzes the format characteristics of field values, checking whether they conform to Uniform Resource Locator (URI) format, Data Uniform Resource Locator (DURI) format, hexadecimal encoding format, etc. Field values ​​matching these characteristics are considered candidate resources, achieving a medium confidence score. The third layer is heuristic identification. The system judges based on the statistical characteristics of field names and value formats. Field names containing specific keywords (such as "image," "file," "attachment," "resource," etc.) and values ​​of string type are considered candidate resources, achieving a lower confidence score. The three-layer identification mechanism works collaboratively to ensure the accuracy and coverage of resource identification.

[0044] II. Automatic Format Conversion: The system achieves unified conversion of resources in multiple formats, supporting various formats such as Uniform Resource Locators (URIs), Data URIs, hexadecimal encoding, and file paths. The URI converter downloads file content via network requests and automatically identifies the media type; the Data URI converter parses the media type declaration and hexadecimal encoded data, decoding it into binary content; the hexadecimal encoding converter identifies the encoded string, decodes it, and infers the media type; the file path converter reads files from the local file system. All converters output a unified resource object, containing core fields such as resource identifier, filename, media type, file size, and resource type, masking format differences. III. Structured Node Output: The system defines a unified format for node output, clearly distinguishing the use cases of content and resources. Content fields store lightweight data (less than ten kilobytes), such as text descriptions, small object representations, and numerical values; resource list fields store resource objects that require independent management, with each resource object containing complete metadata and an access address. This division avoids performance issues caused by excessively large execution states, ensuring lightweight execution states.

[0045] Furthermore, the resource loading module also includes a resource on-demand loading unit, which is used for: When constructing the execution context, only the metadata of the resource object is injected into the execution context, and the complete content of the resource object is not loaded. The metadata includes resource identifier, file name, media type and file size. In response to the intelligent agent calling the unified resource reading tool during execution, the complete content of the resource object is obtained from the resource storage unit according to the resource identifier; Based on the task requirements and resource types of the intelligent agent unit, the resource content is intelligently converted and returned. The conversion includes: returning the original text content of text files, returning hexadecimal encoding of image files, and extracting text content from portable document format files.

[0046] Specifically, the system employs an on-demand resource loading strategy. Only the resource's metadata (resource identifier, filename, media type, file size, access address, etc.) is injected into the node execution context; the complete content of the resource is not directly loaded. During execution, the agent acquires resource content on demand using a built-in resource reading tool. This tool locates the resource object from the context's resource mapping based on the resource identifier, downloads the resource content via the access address, and performs intelligent conversion based on the resource type: text files return the original content, image files return hexadecimal encoding (if the large language model supports visual capabilities), portable document format files extract text content, and large files support chunked reading or returning a summary. This on-demand loading mechanism significantly reduces token consumption, as the agent only loads resource content when truly needed, avoiding unnecessary resource transmission and processing overhead.

[0047] Furthermore, it also includes a state management and breakpoint recovery module, which is used for: Define the execution states of the hierarchical structure, which include the meta-information layer, static configuration layer, current input layer, message history layer, and node execution history layer; Using the session identifier as the thread identifier, the execution state of each node after execution is automatically persisted to the relational database checkpoint storage; In response to a recovery request following an execution interruption, the execution state is restored from the checkpoint memory using the same session identifier, and subsequent task nodes are resumed from the point of interruption.

[0048] Specifically, a unified state management mechanism is designed to support state persistence and breakpoint recovery, with the core components including: I. Execution State Structure: The system defines the complete execution state of the workflow, including the meta-information layer (execution identifier, session identifier, template identifier, instance identifier, parameter validation completion marker, etc.), the static configuration layer (workflow definition, slot value, etc.), the current input layer (user messages, runtime parameter values, etc.), the message history layer (dialogue records of the large language model), and the node execution history layer (input, output, and resources of each node). The execution state adopts a hierarchical structure, clearly distinguishing different types of data, which facilitates the management and persistence of the state.

[0049] II. Checkpoint Mechanism: The system integrates a relational database checkpoint storage, using session identifiers as thread identifiers to achieve automatic state persistence. After each node execution is completed, the state is automatically saved to the database, supporting resumption of execution from any interruption point. The checkpoint mechanism ensures the consistency and integrity of the state, eliminating the need for developers to write additional state management code. III. State Transition Rules: The system employs an annotation mechanism to define the merging strategy for state fields. Message history and node execution history use an append-only mode to ensure the integrity of historical records; current input uses an overwrite mode, supporting dynamic updates. These state transition rules guarantee the correct merging of states in multi-turn dialogue scenarios, avoiding information loss caused by state overwriting.

[0050] IV. Breakpoint Recovery: When the workflow is interrupted due to manual intervention or other reasons, the user can continue execution through the recovery interface. The system uses the same session identifier to restore the execution state from the checkpoint memory, injects the user-provided feedback, and continues to execute subsequent nodes. The breakpoint recovery mechanism enables the system to reliably support scenarios requiring manual intervention, allowing the user to intervene at any node and continue execution.

[0051] Furthermore, it also includes an event communication module, which includes: The event publisher, integrated into each task node and intelligent agent unit, is used to publish multi-level events during execution, including execution-level events, node-level events, and step-level events. An event bus is used to manage event subscribers and distribute events to all registered subscribers. Streaming subscribers are used to receive streaming output events and push them to the front end in real time via network sockets, enabling real-time interactive typewriter effects.

[0052] Specifically, an event system is implemented using a publish-subscribe pattern to decouple node execution from event consumption. The core components include: I. Event Publisher: The system provides a unified event publishing interface, supporting multi-level events such as execution-level events (execution start, execution completion, execution error), node-level events (node ​​start, node completion, node error), and step-level events (thinking, streaming output, tool call, tool result). During execution, nodes publish events through the event publisher, which then distributes the events to all subscribers.

[0053] II. Event Subscription Mechanism: The system supports multiple subscribers listening to events simultaneously. Subscribers consume events independently without affecting each other. Network socket subscribers provide streaming output, pushing events to the front end in real time; log subscribers record execution logs; and monitoring subscribers collect performance metrics. This event subscription mechanism allows the system to flexibly add new subscribers without modifying the core execution logic, significantly improving the system's scalability.

[0054] III. Streaming Output Implementation: During execution, nodes publish streaming output events via an event publisher, including real-time output content from the large language model. Network socket subscribers receive the events and immediately push them to the front end, achieving a typewriter effect. Nodes are unaware of the push mechanism, maintaining the purity of their execution logic. Streaming output latency is less than one hundred milliseconds, enabling a real-time interactive experience.

[0055] IV. Event Persistence: Critical events (such as node completion) carry complete input and output data. Subscribers can selectively persist events to the database, supporting querying and auditing of execution history. The event persistence mechanism provides the foundation for the system's traceability and auditing capabilities.

[0056] Furthermore, it also includes a tool management module, which includes: The tool registry center is used to maintain the mapping relationship between tool identifiers and tool instances, and to load tools in batches according to protocol server addresses; The tool cache unit is used to cache loaded tool instances and tool patterns, and supports a time-to-live expiration mechanism and a manual cleanup mechanism. The built-in tool registry is used to register commonly used tools pre-installed by the system. Users can load the corresponding built-in tools by providing the tool identifier.

[0057] Specifically, it features a framework-agnostic tool abstraction layer that supports unified management of various tool types. The core includes: I. Basic Tool Abstraction: The system defines a unified interface for tools, including core attributes and methods such as tool name, tool description, parameter patterns, and execution methods. All tools inherit from the basic tool class, implementing a unified calling interface. The tool system adopts a fully asynchronous design, supporting tool calls in high-concurrency scenarios; II. Standard Protocol Tool Adaptation; The system supports the integration of external tools through standard protocols, encapsulating tool calls within these protocols. It connects to the server via a protocol client, dynamically obtaining the tool list and modes, and automatically generating parameter models. It supports multiple transmission protocols, including Hypertext Transfer Protocol, server-sent events, and standard input / output, achieving seamless integration with standard servers. III. Built-in Tool Registration: The system establishes a built-in tool registry to maintain the mapping relationship between tool identifiers and tool classes. It supports two modes: simple tools (no initialization required) and complex tools (initialization parameters required). Tool loading and instantiation are achieved through a unified configuration format. Users only need to provide the tool identifier to load the tool, simplifying the configuration process. IV. Tool Caching Optimization: The system implements a singleton tool registry center to manage tool loading and caching. Tools are loaded in batches by protocol server address to reduce the number of connections; tool instances and modes are cached to avoid duplicate loading; time-to-live (TTL) expiration and manual cleanup are supported to ensure cache timeliness. The tool caching mechanism improves the system's response speed.

[0058] Furthermore, the resource loading module also has a resource deduplication mechanism, specifically including: During the resource conversion process, the hash value of the resource content is calculated as the resource fingerprint; Before persistent storage, query whether a resource object with the same content already exists based on the resource fingerprint; If it exists, the resource identifier and access address of the existing resource object will be reused to avoid storing resources with the same content repeatedly.

[0059] Specifically, establish a comprehensive error handling, performance optimization, and security mechanism: The core includes: I. Error Handling: The system implements a layered error handling mechanism, including errors in large language model invocation (timeout, formatting error), tool execution errors (parameter error, execution failure), and resource processing errors (download failure, storage failure). It supports error retries, degradation strategies, and user-friendly prompts. When a large language model invocation fails, the system activates a degradation strategy, employing a simple keyword matching-based extraction method to ensure basic system availability.

[0060] II. Performance Optimization: The system employs multiple performance optimization strategies, including tool list caching (with a five-minute lifespan), protocol connection reuse, batch resource uploading, and context compression. Performance monitoring collects metrics such as execution time and token consumption, supporting performance analysis and continuous optimization. These optimization strategies enable the system to maintain high throughput and low latency under high-concurrency scenarios.

[0061] III. Security Assurance: The system establishes a comprehensive security mechanism, including setting expiration times for Uniform Resource Locators (URLs) to prevent unauthorized access; parameter validation to prevent injection attacks; tool execution timeout control to prevent resource exhaustion; and log anonymization to protect sensitive information. This security mechanism ensures the system's security and reliability.

[0062] Example 2 Secondly, such as Figure 4 As shown, this invention provides a workflow parameter processing and management method that supports agent reuse, applied to the aforementioned workflow parameter processing and management system that supports agent reuse, specifically including: S1 determines the replacement data of the slot value of the execution instance based on the execution status of the execution instance, determines the replacement execution process of different slot values ​​based on the replacement data, and determines the matching analysis requirement instance in the execution instance based on the replacement execution process of different slot values ​​in different execution instances and the execution data of the execution instance. Furthermore, the replacement data for the slot value of the execution instance is determined based on the number of times the slot value of the execution instance is replaced during the execution process.

[0063] Specifically, the method for determining the matching analysis requirement instance in the execution instance is as follows: In this embodiment, the frequency of slot value replacement processing for different execution instances is determined by using the slot value replacement data of different execution instances. The frequency of slot value replacement processing for different execution instances is then used to determine the matching analysis requirement instances. This helps to build corresponding matching users for the matching analysis requirement instances, thereby reducing the frequency of slot value replacement processing and laying the foundation for improving the execution efficiency of the execution instances.

[0064] The core objective of this embodiment is to systematically analyze the slot value replacement status of execution instances, identify execution instances with high replacement frequency, and determine matching analysis requirement instances based on a comprehensive judgment of replacement frequency and execution data, thereby laying the logical foundation for the subsequent construction of matching users. Its core logic is as follows: first, obtain the slot value replacement execution process data; then, calculate the replacement frequency coefficient of each slot value; and finally, determine the matching analysis requirement instances through multi-dimensional judgment of the replacement frequency coefficient and execution data. The overall logic follows the process of "replacement process identification → frequency coefficient calculation → requirement instance determination".

[0065] The replacement data in S11 determines the execution process in which the slot value of the execution instance is replaced during execution, and the execution process in which the replacement occurs is taken as the replacement execution process; The replacement data refers to the operation data recorded in the running history of the execution instance, which records the replacement of each slot value from its original configuration value to other values; the replacement execution process refers to the specific execution process in which at least one slot value replacement operation occurred; the execution process refers to a complete running process of the execution instance from startup to completion.

[0066] Suppose that an execution instance completes multiple execution processes within a historical period. In some of these execution processes, slot value replacement operations occur, while in others, no slot value replacement occurs. In such cases, the execution processes in which replacement operations occur are identified as replacement execution processes.

[0067] This step provides the basic data for the subsequent calculation of the replacement frequency coefficient. Its significance lies in accurately filtering out the processes in which slot value replacement occurs from the entire execution process of the execution instance, avoiding the inclusion of execution processes that have not undergone replacement in subsequent analysis, thereby ensuring the accuracy and relevance of the replacement frequency calculation.

[0068] S12 determines the replacement frequency coefficient of the execution instance at different slot values ​​based on the replacement execution process during the execution process of the execution instance at different slot values; The replacement frequency coefficient refers to the ratio of the number of replacement execution processes that occur for a specific slot value in an execution instance to the total number of execution processes in that execution instance, reflecting the degree to which the slot value is frequently replaced.

[0069] Suppose an execution instance has multiple execution processes, and a certain slot value is replaced in some of these processes. The replacement frequency coefficient for that slot value is the number of execution processes in which that slot value is replaced divided by the total number of execution processes in that execution instance. A higher replacement frequency coefficient indicates that the slot value is replaced more frequently.

[0070] This step transforms the qualitative identification of the replacement execution process into a quantitative replacement frequency coefficient. Its significance lies in providing a standardized quantitative indicator for the subsequent judgment of matching analysis requirements and the comprehensive evaluation of the replacement degree of multiple slot values. This ensures that the replacement frequency between different slot values ​​and different execution instances is comparable, thereby improving the objectivity and consistency of the judgment results.

[0071] It is understood that the frequency coefficient of slot value replacement is determined based on the proportion of replacement execution processes during the execution of the slot value.

[0072] S13 uses the replacement frequency coefficient of different execution instances in different slot values ​​and execution data to determine the matching analysis requirement instance in the execution instance.

[0073] The matching analysis requirement instance refers to an execution instance in which the slot value is replaced frequently, and corresponding matching users and preset slot values ​​need to be built for such execution instances to reduce the frequency of replacement. It is the direct target object of matching user construction. The execution data refers to the running record of the execution instance in the historical period, including information such as the average number of executions per day and the distribution of the number of executions on each date.

[0074] Assuming there are multiple execution instances in the workflow, calculate the replacement frequency coefficient of different slot values ​​in each execution instance. Combine this with execution data such as the average daily execution count of each execution instance to comprehensively determine which execution instances need to build matching users due to excessively frequent slot value replacements. These execution instances are then identified as matching analysis requirement instances.

[0075] This step takes into account both the replacement frequency coefficient and the execution data. Its significance lies in avoiding the limitations of judging solely based on the replacement frequency coefficient. By introducing execution data (such as execution frequency) as a supplementary dimension, it ensures that the determination of matching analysis requirement instances takes into account both the actual replacement frequency of slot values ​​and the usage activity of execution instances, thereby improving the targeting and effectiveness of matching user construction.

[0076] Specifically, based on the replacement frequency coefficient of different execution instances at different slot values ​​and execution data, the matching analysis requirement instances in the execution instances are determined, including: The adjustment delay value of the execution instance is determined by the replacement frequency coefficient of the execution instance at different slot values ​​and in combination with the number of slot values; The adjustment delay value refers to a quantitative indicator that comprehensively measures the frequency of replacement of all slot values ​​in the execution instance. It is calculated by combining the replacement frequency coefficient of each slot value with the number of slot values, and reflects the overall adjustment burden of the execution instance caused by the frequent replacement of slot values.

[0077] Assuming an execution instance has multiple slot values, calculate the replacement frequency coefficient for each slot value, and combine it with the number of slot values ​​to calculate the adjustment delay value of the execution instance. The specific value is determined based on the sum of the replacement frequency coefficients of each slot value. A higher adjustment delay value indicates that the slot values ​​of the execution instance are replaced more frequently and the adjustment burden is greater.

[0078] This step aggregates the replacement frequency coefficients of multiple slot values ​​into a single comprehensive index. Its significance lies in providing a unified comparison benchmark for subsequent classification judgments of different situations, avoiding the decision-making complexity caused by the scattered judgments based on multiple slot value coefficients.

[0079] It should be noted that, in case 1: if there is no execution instance with an adjustment delay value greater than the preset delay threshold, then the frequency of replacement between different execution instances is not high and the data processing efficiency is relatively fast. Therefore, it is determined that the construction of matching analysis requirement instances is not required in the execution embodiment. The preset delay threshold refers to a preset standard value used to determine whether the adjustment delay value of the execution instance has reached the level that needs attention.

[0080] If the adjustment delay value of all execution instances in the workflow does not exceed the preset delay threshold, it indicates that the overall slot value replacement of all execution instances is at a low level, the data processing efficiency is fast, and there is no need to build a matching user for any execution instance.

[0081] This configuration reflects the management principle of build-on-demand. Its significance lies in avoiding unnecessary matching user build overhead while keeping the overall replacement frequency under control, thus ensuring the reasonable allocation of system resources and operational efficiency.

[0082] Additionally, it should be noted that in case 2: if there are execution instances with an adjustment delay value greater than the preset delay threshold, the execution instances with an adjustment delay value greater than the preset delay threshold will be used as delayed execution instances. Based on the execution data of the delayed execution instances, if the proportion of the number of executions of the delayed execution instances on different dates to the total number of executions of all execution instances is greater than the preset execution proportion threshold, then the matching analysis requirement instances in the execution instances will be determined as execution instances with a target number of slot values ​​whose replacement frequency coefficient is greater than the preset frequency coefficient threshold. The delayed execution instance refers to an execution instance whose delayed value is greater than the preset delayed threshold, representing an execution instance with a high frequency of replacements; the preset execution frequency percentage threshold refers to a preset proportion standard used to determine whether the execution activity of the delayed execution instance has reached a significant level; the target quantity refers to a preset slot value quantity standard used to measure the number threshold of high replacement frequency slot values ​​that need to be paid attention to in an execution instance; the preset frequency coefficient threshold refers to a preset standard value used to determine whether the replacement frequency coefficient of a single slot value has reached a high level.

[0083] Assuming there are multiple execution instances in the workflow whose adjusted delay values ​​exceed a preset delay threshold, these execution instances are identified as delayed execution instances. The number of times delayed execution instances are executed on different dates is counted, and their proportion of the total number of execution instances on each date is calculated. If this proportion exceeds a preset execution frequency proportion threshold, then execution instances with a replacement frequency coefficient of no less than the target number exceeding a preset frequency coefficient threshold are identified as matching analysis requirement instances.

[0084] This strategy addresses the handling of delayed execution instances with high execution activity. Its significance lies in focusing on execution instances that have multiple frequently replaced slot values ​​when the overall execution ratio of delayed execution instances is significant, thus ensuring the accuracy and effectiveness of matching user-built systems.

[0085] It also includes the following: Case 3: If the proportion of the number of times the delayed execution instance is executed on different dates to the total number of times all execution instances are not above the preset execution count proportion threshold, then the matching analysis requirement instance in the execution instance is determined to be an execution instance with a target number of slot values ​​whose replacement frequency coefficient is greater than the preset frequency coefficient threshold and whose average daily execution count is above the preset execution count threshold.

[0086] The preset execution count threshold refers to a preset standard value used to determine whether the average daily execution count of an execution instance has reached a high activity level.

[0087] If the proportion of the number of executions of delayed execution instances on each date to the total number of executions of all execution instances does not exceed the preset execution count percentage threshold, it indicates that the overall execution percentage of delayed execution instances is not significant. In this case, based on the existence of a target number of frequently replaced slots, the daily average execution count is further restricted, and only execution instances with a daily average execution count not lower than the preset threshold are identified as matching analysis requirement instances.

[0088] This situation complements situation 2. Its significance lies in the fact that when the overall execution rate of delayed execution instances is not high, the execution instances with higher activity can be further filtered by adding the condition of average daily execution times. This avoids unnecessary matching of users for low-frequency execution instances, thereby improving the input-output efficiency of matching user construction.

[0089] This embodiment achieves accurate identification of matching analysis requirement instances through systematic analysis of slot value replacement data of execution instances, calculation of replacement frequency coefficients, aggregation of adjustment delay values, and multi-case classification judgment. Its core value lies in three aspects: First, by accurately identifying the replacement execution process and standardizing the calculation of replacement frequency coefficients, a unified and comparable quantitative data foundation is provided for subsequent analysis; second, by comprehensively aggregating adjustment delay values, the replacement frequency of multiple slot values ​​is integrated into a single comprehensive indicator, simplifying the complexity of the judgment logic; third, through a three-level progressive classification of Case 1, Case 2, and Case 3, a clear strategy for determining matching analysis requirement instances is ensured under different combinations of replacement frequency and execution activity, effectively avoiding the blind construction and resource waste of matching users.

[0090] S2 determines the update identification scheme for the matching user of the matching analysis requirement instance based on the queuing processing delay of different execution instances and the replacement data of the slot value of the matching analysis requirement instance. Specifically, the method for determining the update identification scheme for the matching user of the matching analysis requirement instance is as follows: In this embodiment, the processing latency of the execution instance is determined based on the queuing processing latency of different execution instances. Furthermore, by combining the replacement data of the slot values ​​of the matching analysis requirement instance, the frequency of update processing of the matching analysis requirement instance is obtained. Based on the processing latency of the execution instance and the frequency of update processing of the matching analysis requirement instance, the update identification scheme for the matching user of the matching analysis requirement instance is determined. This lays the foundation for minimizing the execution latency during the execution instance invocation process while avoiding an excessive number of matching users for the matching analysis requirement instance.

[0091] S21 determines the queuing time of execution instances on different dates based on the queuing delay of different execution instances, and determines the execution delay date based on the average queuing time of different execution instances on the date. The queuing processing time refers to the length of time an execution instance spends waiting for the system to allocate resources and begin execution after submission; the average queuing processing time refers to the arithmetic mean of the queuing processing times of all execution instances on a certain date; the execution delay date refers to a date on which the average queuing processing time of each execution instance is greater than a preset processing time threshold, representing a date with a high overall processing delay for execution instances.

[0092] Assuming that the queuing time of each execution instance is counted daily within a historical period, the average queuing time of all execution instances is calculated for each date, and the date when the average exceeds the preset processing time threshold is marked as the execution delay date.

[0093] This step transforms the raw queuing data into structured execution delay date identifiers. Its significance lies in capturing the processing delay patterns of execution instances from a time dimension, providing key time-dimensional input data for the subsequent calculation of the proportion of execution delay dates and the classification judgment of the updated identification scheme.

[0094] It should be noted that, in the above steps, the execution delay date in the date refers to the date when the average queuing time of different execution instances is greater than the preset processing time threshold.

[0095] It should be noted that in the above steps, S211 determines whether the proportion of execution delay dates in the date is greater than the preset delay date proportion threshold. If so, the update identification scheme for the matching user of the matching analysis requirement instance is determined as follows: if the number of calls of the user in the matching analysis requirement instance is greater than the preset call count threshold, and the proportion of the consistent slot in all slots is greater than the preset slot value proportion threshold, then the user is regarded as the matching user of the matching analysis requirement instance, that is, the slot value of the consistent slot is used as the preset value of the corresponding slot of the user, thereby avoiding the occurrence of frequent adjustments. If not, proceed to step S212. The percentage of execution delay dates refers to the proportion of dates marked as execution delay dates in a historical period to the total number of dates in the historical period, reflecting the temporal coverage of the execution delay phenomenon; the preset threshold for the percentage of execution delay dates refers to a preset proportion standard used to determine whether the prevalence of execution delay dates reaches the level requiring the activation of an enhanced identification scheme; the consistent slot refers to a slot in which the percentage of calls with the same slot value is above the target proportion threshold in all call counts; the preset slot value proportion threshold refers to a preset proportion standard used to determine whether the proportion of consistent slots in all slots reaches a significant level.

[0096] Assuming a historical period of 90 days, with 30 days marked as execution delay dates, the percentage of execution delay dates is approximately 30 ÷ 90 ≈ 0.333. If this percentage exceeds a preset threshold for the percentage of delay dates, the call data for each user in the matching analysis requirement instance is checked one by one: if a user's call count exceeds a preset call count threshold, and the proportion of consistent slots to the total number of slots is not less than a preset slot value percentage threshold, then the user is identified as a matching user, and the slot value of the consistent slot is used as the preset value for the corresponding slot of that user.

[0097] This step employs an enhanced identification scheme when the delay phenomenon covers a wide range of time periods. Its significance lies in relaxing the judgment criteria for matching users when the overall system processing delay is widespread, so as to establish a matching user system as early as possible. By pre-setting slot values, the occurrence of subsequent replacement operations can be reduced, thereby fundamentally reducing the processing delay caused by frequent replacements.

[0098] It should be noted that the consistent slot is the slot whose percentage of calls with the same slot value is above the target percentage threshold among all call counts. When determining the preset value of the user's corresponding slot, the slot value with the highest percentage of calls is taken as the preset value of the user's corresponding slot.

[0099] S212 determines whether there is an execution delay date. If yes, proceed to step S22. If no, determine that the update identification scheme for the matching user of the matching analysis requirement instance is a general update identification scheme. If the number of calls by the user in the matching analysis requirement instance is greater than the preset call count threshold, the proportion of the consistent slot in all slots is greater than the first preset slot value proportion threshold, and the number of slots that do not belong to the consistent slot is less than the preset slot number value, then the user is regarded as the matching user of the matching analysis requirement instance, that is, the slot value of the consistent slot is used as the preset value of the corresponding slot of the user, thereby avoiding the occurrence of frequent adjustments. The general update identification scheme refers to an update identification scheme that adopts stricter matching user judgment conditions when the time coverage of the delay phenomenon is narrow or there is no delay phenomenon; the first preset slot value ratio threshold refers to the preset ratio standard used to judge whether the consistent slot ratio meets the standard under the general update identification scheme, which is usually more stringent than the preset slot value ratio threshold under the enhanced identification scheme (S211); the preset slot number value refers to the upper limit standard used to limit the number of inconsistent slots, further tightening the judgment conditions for matching users.

[0100] Assuming there are no execution delay dates, meaning that the queuing time for each date within the historical period does not exceed the threshold, a general update identification scheme is adopted to conduct a more rigorous check on the call data of each user in the matching analysis requirement instance: only when all three conditions are met simultaneously, the user is identified as a matching user, the user's call count exceeds the preset call count threshold, the proportion of consistent slots to all slots is not less than the first preset slot value proportion threshold, and the number of slots that do not belong to consistent slots is less than the preset slot number value.

[0101] This step employs strict judgment conditions when the latency phenomenon does not exist. Its significance lies in avoiding the increase in management complexity caused by excessive construction of matching users when the overall system processing latency is low. It ensures that the quality of matching user construction takes precedence over the quantity, thereby effectively reducing the frequency of replacement while controlling management costs.

[0102] S22 determines the adjustment delay value of the matching analysis requirement instance based on the replacement data of the slot value of the matching analysis requirement instance; The above steps include the following: Determine whether the adjustment delay value of the matching analysis requirement instance is greater than the preset delay threshold. If so, determine that the update identification scheme of the matching user of the matching analysis requirement instance is the fast update identification scheme. If the number of calls of the user in the matching analysis requirement instance is greater than the preset number of calls threshold, and the proportion of the consistent slot in all slots is greater than the preset slot value proportion threshold, then the user is regarded as the matching user of the matching analysis requirement instance, that is, the slot value of the consistent slot is used as the preset value of the corresponding slot of the user, thereby avoiding the occurrence of frequent adjustments. If not, proceed to step S23. The rapid update identification scheme refers to an update identification scheme that adopts relatively lenient matching user judgment conditions to quickly build a matching user system when the adjustment delay value of the matching analysis requirement instance is high.

[0103] Suppose that the adjustment delay value of a certain matching analysis requirement instance exceeds the preset delay threshold, it indicates that the overall frequency of slot value replacement in this instance is high and the replacement frequency needs to be reduced. At this time, a fast update identification scheme is adopted to perform relatively lenient condition checks on the calling user. Only the conditions of the number of calls and the consistent slot ratio need to be met to determine the user as a matching user.

[0104] This step prioritizes a fast solution when the instance itself has a high latency in matching and analysis requirements. Its significance lies in providing faster matching and user build responses for instances with high replacement frequency, ensuring that instances with high replacement burden are alleviated first, and effectively reducing system processing latency caused by frequent replacements.

[0105] S23 uses the distribution data of the execution delay date and the adjusted delay value of the matching analysis request instance to determine the update identification scheme of the matching user of the matching analysis request instance.

[0106] Specifically, in the above steps, the update identification demand value of the matching user of the matching analysis demand instance is determined based on the adjustment delay value of the matching demand instance and the proportion of the number of execution delay dates. It is then determined whether the update identification demand value of the matching user of the matching analysis demand instance is greater than a preset demand threshold. If so, the update identification scheme of the matching user of the matching analysis demand instance is determined to be a fast update identification scheme; otherwise, the update identification scheme of the matching user of the matching analysis demand instance is determined to be a general update identification scheme.

[0107] The update identification requirement value refers to a composite quantitative indicator that comprehensively measures the frequency of replacement of matching analysis requirement instances (adjustment delay value) and the overall system delay breadth (percentage of execution delay dates). Specifically, it is the product or average of the two, and it is the final judgment basis for distinguishing between fast update identification schemes and general update identification schemes.

[0108] Suppose that the adjustment delay value of a certain matching analysis requirement instance is 0.45 and the percentage of execution delay dates is 0.333. The update identification requirement value is obtained by comprehensively calculating the adjustment delay value and the percentage of execution delay dates. This value is then compared with the preset requirement threshold to determine whether to adopt the fast update identification scheme or the general update identification scheme.

[0109] This step achieves a refined determination of the update identification scheme by comprehensively quantifying the update identification requirement value. Its significance lies in integrating the frequency of replacement at the instance dimension and the breadth of time delay at the system dimension into a single decision indicator, ensuring that the selection of the update identification scheme takes into account both micro and macro dimensions, thereby improving the scientificity and comprehensiveness of the scheme selection.

[0110] This embodiment achieves a systematic selection of update identification schemes for matching users by identifying and calculating the proportion of execution delay dates, evaluating the adjustment of delay values ​​based on matching analysis of demand instances, comprehensively quantifying the update identification demand values, and classifying and determining three update identification schemes: enhanced, fast, and general. Its core value is reflected in three aspects: First, by using a hierarchical judgment of the proportion of execution delay dates, it distinguishes between widespread and localized delays in the system state from a time dimension, providing a macro-level basis for scheme selection; second, by using the adjustment of delay values ​​based on matching analysis of demand instances, it distinguishes between the frequency of replacements from an instance dimension, providing a micro-level basis for scheme selection; and third, by comprehensively quantifying the update identification demand values, it integrates information from both micro and macro dimensions into a single decision indicator, ensuring the accuracy and scientific nature of scheme selection.

[0111] S3 uses the instance update scheme to update the matching users of different matching analysis requirement instances, uses the matching users to determine the update matching instances and update deviation instances in the matching analysis requirement instances, and based on the composition of the update matching instances and update deviation instances, when it is determined that the update restriction processing of the matching users needs to be performed, proceed to the next step. Specifically, determining whether the update restriction processing for the matched users needs to be performed includes: S31, based on the number of matching users of different matching analysis requirement instances, identifies matching analysis requirement instances with a number of matching users greater than a preset threshold for the number of matching users as update matching instances, and identifies matching analysis requirement instances with a number of matching users less than a preset value for the number of matching users as update deviation instances. The preset threshold for the number of matched users refers to a preset standard value used to determine whether the number of matched users has reached a high level; the preset value for the number of matched users refers to a preset standard value used to determine whether the number of matched users is significantly low.

[0112] Assuming the preset threshold for the number of matched users is a certain value, and the preset value for the number of matched users is another value, matching analysis request instances with a number of matched users greater than the preset threshold for the number of matched users are classified as update matching instances, and matching analysis request instances with a number of matched users less than the preset value for the number of matched users (less than the preset threshold for the number of matched users) are classified as update deviation instances.

[0113] This step categorizes the instances after matching user updates. Its significance lies in distinguishing two types of instances with different characteristics based on the number of matching users, providing a clear classification basis for subsequent update restriction decisions, and ensuring that update restriction decisions have clear quantitative evidence.

[0114] Based on the composition of the update matching instance and the update deviation instance, S32 determines whether update restriction processing for the matching user is required.

[0115] Furthermore, when the proportion of updated matching instances in the execution instances and the proportion of updated deviation instances in the execution instances are both greater than the execution instance proportion threshold, in order to avoid the situation where a large number of matching users lead to excessive management difficulty, the updates of a large number of updated matching instances will result in a limited number of updates available to matching users for updated deviation instances. Therefore, it is determined that the update restriction processing of the matching users needs to be performed.

[0116] The phrase "both greater than the execution instance percentage threshold" refers to the condition that the percentage of update matching instances and the percentage of update deviation instances simultaneously exceed the preset execution instance percentage threshold. Update restriction processing is only triggered when this condition is met simultaneously.

[0117] Assuming that out of 15 execution instances, there are 3 instances of update matching (accounting for 3 ÷ 15 = 0.20) and 2 instances of update deviation (accounting for 2 ÷ 15 ≈ 0.133), and the preset execution instance percentage threshold is 0.10, then both percentages are greater than 0.10. In this case, it is determined that update restriction processing for matching users is required to avoid the management complexity from getting out of control due to the continuous growth of the number of matching users.

[0118] This step uses a dual-proportion condition to trigger the update restriction process. The significance of this is that the restriction process is only initiated when both update matching instances (with a large number of matching users) and update deviation instances (with a small number of matching users) are widely present. This ensures that the update restriction decision can prevent excessive growth in matching users without prematurely restricting the process and affecting normal update needs.

[0119] This embodiment achieves closed-loop control of user update management through systematic update processing of matching users, classification of updated matching instances and update deviation instances, and update restriction judgment based on dual proportion conditions. Its core value lies in two aspects: first, by classifying the number of matching users, managers can clearly understand the current user configuration status of instances; second, by setting dual proportion conditions, update restriction processing is triggered promptly when the distribution of the number of matching users becomes polarized, effectively preventing uncontrolled management complexity while protecting the limited update space of update deviation instances.

[0120] S4 utilizes the update identification scheme of matching users for different matching analysis requirement instances to determine the monitoring and analysis method for the slot value of the updated matching instance.

[0121] Specifically, the method for determining the monitoring and analysis method for the slot value of the updated matching instance is as follows: In this embodiment, based on the constituent data of the matching analysis requirement instance and the update identification scheme of the matching user of the matching analysis requirement instance, the potential update efficiency of the matching user under the current matching analysis requirement instance is determined. That is, the more matching analysis requirement instances there are and the higher the timeliness of the update identification scheme of the matching user of the matching analysis requirement instance, the higher the potential update efficiency of the matching user at this time. Using the potential update efficiency of the matching user at this time, the monitoring and analysis method for updating the slot value of the matching instance is determined, that is, under what circumstances monitoring and analysis processing is no longer performed, thereby avoiding the situation where the management difficulty is too high due to the large number of matching users.

[0122] S41 uses the matching analysis requirement instance to determine the proportion of the matching analysis requirement instance in the execution instance, and uses it as the requirement instance ratio. The requirement instance ratio refers to the proportion of the number of matching analysis requirement instances to the total number of execution instances, reflecting the breadth of coverage of the execution instances built by the user that need to be matched in the overall workflow.

[0123] Assuming the workflow has 15 execution instances, of which 4 are identified as matching analysis requirement instances, then the requirement instance ratio = 4 ÷ 15 ≈ 0.267.

[0124] This step quantifies the coverage of demand instances through demand instance ratio analysis. Its significance lies in providing basic ratio data for subsequent monitoring and analysis methods. The size of the demand instance ratio directly affects the selection tendency of subsequent judgment strategies.

[0125] Specifically, the above steps include the following: Determine whether the proportion of the demand instance is less than the preset demand instance proportion threshold. If so, the reliability of the update processing of the matching user is low, which may result in a small number of updates for the matching user. Therefore, as long as the matching analysis demand instance belongs to the update matching instance and the proportion of the matching user among the calling users in the matching analysis demand instance is above the preset matching user proportion, the monitoring and analysis processing of the slot value of the update matching instance will no longer be performed, that is, the update processing of the matching user is not required. If not, proceed to step S42. The preset demand instance ratio threshold refers to a preset ratio standard value used to determine whether the coverage breadth of the matching analysis demand instances has reached a significant level; the preset matching user ratio refers to a preset ratio standard value used to determine whether the ratio of matching users to calling users is sufficient.

[0126] If the proportion of demand instances is less than the preset threshold, it indicates that the coverage of matching analysis demand instances is narrow and the potential update efficiency and reliability of matching users are relatively low. In this case, a stricter judgment condition is adopted: monitoring and analysis will no longer be performed and the update of matching users for that instance will be stopped only when a matching analysis demand instance belongs to the update matching instance and the proportion of matching users to the calling users is not less than the preset proportion of matching users.

[0127] This step employs strict judgment conditions for situations with a low proportion of demand instances. Its significance lies in exempting only instances with sufficient matching user configuration from subsequent monitoring and analysis when the coverage of demand instances in the matching analysis is insufficient. This avoids the risk of insufficient matching user configuration caused by excessively stopping monitoring and analysis in low-coverage scenarios.

[0128] S42 determines the update timeliness weight value of the matching user of the matching analysis requirement instance based on the update identification scheme of the matching user of the matching analysis requirement instance; The update timeliness weight value refers to assigning different preset weight values ​​based on the type of matching user update identification scheme (fast update identification scheme or general update identification scheme) adopted by the matching analysis requirement instance, in order to quantify the timeliness level of matching user updates in that instance.

[0129] Assuming that the fast update recognition scheme has high timeliness, its update timeliness weight value is set to a larger preset value; while the general update recognition scheme has relatively low timeliness, its update timeliness weight value is set to a smaller preset value.

[0130] This step transforms the update identification scheme type into a standardized quantitative indicator of timeliness by updating the timeliness weight value. Its significance lies in providing a comparable and calculable data basis for the comprehensive evaluation of the potential update efficiency of matching users in the future.

[0131] It is understood that the update timeliness weight value of the matching user in the matching analysis requirement instance is determined according to the preset weight value corresponding to the update identification scheme of the matching user, wherein the update timeliness weight value of the fast update identification scheme is greater than the update timeliness weight value of the general update identification scheme.

[0132] The above steps include the following: Determine whether the average value of the update timeliness weight of the matching users of different matching analysis requirement instances is greater than the preset weight threshold. If so, the reliability of the update processing of the matching users is high, which may result in a large number of updates of the matching users. Therefore, as long as the matching analysis requirement instance belongs to the update matching instance, the monitoring and analysis processing of the slot value of the update matching instance will no longer be carried out, that is, the update processing of the matching users is not required. If not, proceed to step S43. The mean of the update timeliness weight value refers to the arithmetic mean of the update timeliness weight values ​​of all matching analysis request instances, reflecting the overall timeliness level of matching user updates; the preset weight threshold refers to a preset standard value used to judge whether the overall update timeliness has reached a high level.

[0133] Assuming that the update timeliness weight values ​​of the four matching analysis request instances are all a certain value, calculate their average value. If the average value exceeds the preset weight threshold, it indicates that the overall update timeliness is high and the potential update efficiency of matching users is sufficient. At this time, it is only necessary to determine whether the matching analysis request instance belongs to the update matching instance to decide whether to stop monitoring and analysis.

[0134] This step simplifies the judgment criteria when the overall update timeliness is high. Its significance lies in the fact that when the overall timeliness of the matching user update plan is high, the number of updates by the matching users tends to be sufficient, and appropriately relaxing the exemption conditions for monitoring and analysis can avoid excessive growth of the matching users.

[0135] S43 determines the monitoring and analysis method for the slot value of the update matching instance based on the ratio of the demand instances and the update timeliness weight value of the matching users of different matching analysis demand instances.

[0136] Specifically, the above steps include the following: S431 Determine whether the ratio of the required instances is above the preset instance ratio threshold. If yes, as long as the matching analysis required instance belongs to the update matching instance, the monitoring and analysis of the slot value of the update matching instance will no longer be performed, that is, the update processing of the matching user is not required. If no, proceed to step S432. The preset instance ratio threshold refers to a preset ratio standard value used to determine whether the required instance ratio has reached a high level, thereby simplifying the monitoring and analysis of exemption conditions.

[0137] If the proportion of demand instances exceeds the preset instance proportion threshold, it indicates that the matching analysis of demand instances has a wide coverage and the foundation of matching users is sufficient. In this case, instances belonging to the update matching instances are directly exempted from subsequent monitoring and analysis processing.

[0138] This step employs the most lenient monitoring and analysis exemption conditions when the proportion of demand instances is high. Its significance lies in the fact that when the demand instances for matching analysis have been widely covered, timely restrictions can effectively prevent the excessive growth of matching users, and direct exemption can effectively free up management resources.

[0139] S432 determines whether the update timeliness weight value of the matching user of the matching analysis request instance is above the preset timeliness weight threshold. If yes, as long as the matching analysis request instance belongs to the update matching instance, the monitoring and analysis processing of the slot value of the update matching instance will no longer be performed, that is, the update processing of the matching user is not required. If no, as long as the matching analysis request instance belongs to the update matching instance and the proportion of the matching user among the calling users in the matching analysis request instance is above the preset proportion of matching users, the monitoring and analysis processing of the slot value of the update matching instance will no longer be performed, that is, the update processing of the matching user is not required.

[0140] The preset timeliness weight threshold refers to a preset standard value used to determine whether the update timeliness weight value of a single matching analysis requirement instance has reached a high level, thereby simplifying the monitoring and analysis exemption conditions.

[0141] If the update timeliness weight value of a certain matching analysis requirement instance is high, it indicates that the update identification scheme adopted has good timeliness, and its subsequent monitoring and analysis processing is directly exempted; if the update timeliness weight value is insufficient, the matching user ratio condition needs to be added, and exemption will only be granted when the ratio of matching users to calling users reaches a preset standard.

[0142] This step achieves a refined, instance-by-instance determination of monitoring and analysis exemption conditions by updating the timeliness weight value of a single instance. Its significance lies in ensuring that each instance's monitoring and analysis exemption decision has sufficient and clear individual basis when the proportion of demand instances is generally low and the overall update timeliness is insufficient. This is achieved by judging the timeliness weight value at the instance level and matching the user proportion to supplement the conditions, thus preventing the omission of instances that need to continue monitoring and analysis.

[0143] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0144] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0145] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A workflow parameter processing and management system supporting agent reuse, characterized in that, Specifically, it includes: The instance building module is responsible for obtaining predefined workflow templates, creating independent execution instances based on the workflow templates, setting statically configured slot values ​​in the execution instances, or setting corresponding slot values ​​for matching users based on the identification results of matching users; The agent binding module binds reusable agent units to each task node in the execution instance. Each task node inherits the complete configuration of the agent unit by referencing the agent identifier, and dynamically injects specific task descriptions during execution. The parameter injection module is used to automatically parse the dependency relationship of the task node according to the edge structure defined in the workflow template before executing the current task node, extract parameter values ​​from the output data of the upstream task nodes that have been executed, and obtain the currently missing parameter values ​​from the user dialogue history using an incremental extraction method. The extracted parameter values ​​are then merged with the slot values ​​in the execution instance according to priority to construct the execution context of the current task node. The resource loading module is used to, during the execution of the current task node, when the intelligent agent unit needs to access multimedia resources, obtain the actual data of the multimedia resources as needed based on the resource metadata injected in the execution context; The agent binding module includes an agent compiler, and the execution method of the agent compiler specifically includes: During the workflow construction phase, all task nodes in the execution instance are traversed. The corresponding agent type is determined based on the agent identifier referenced by each task node; Select a matching compiler according to the agent type, combine the agent's configuration with the underlying execution engine, and generate an executable agent instance; The compiled agent instances are cached in the execution engine for reuse by multiple task nodes within the same execution instance; The parameter injection module also includes a context builder, which is used for: The slot values ​​in the execution instance are merged with the parameter values ​​extracted from the dialogue history according to priority to generate workflow variables; Extract all resource objects from the upstream node output generated by the dependency resolver and flatten them into resource mappings from resource identifiers to resource objects; The workflow variables, the upstream output mapping, and the resource mapping are used to construct the execution context of the current task node; The parameter injection module employs an incremental parameter extraction strategy, specifically including: The parameter status recording unit is used to record the identifier of the last dialogue message corresponding to the last parameter extraction process and the set of parameters that have been extracted. The incremental analysis unit is used to obtain only the newly added message content after the last dialogue message identifier when parameter extraction is triggered, and to calculate the difference between the set of required parameters defined in the current workflow and the set of extracted parameters to obtain the missing parameter subset. A parameter extraction agent is used to call a large language model to extract parameter values ​​from the newly added message content only for the missing parameter subset. The parameter injection module further includes a parameter locking unit, which is used for: When the missing parameter subset is empty and all required parameters have been extracted completely, the parameter validation completion flag is set to true in the metadata of the execution status and persistently stored in the checkpoint storage. Once the parameter verification is completed and marked as true, ignore the automatic parameter extraction requests triggered by subsequent user dialogues and directly use the locked parameter values ​​to construct the execution context.

2. The workflow parameter processing and management system supporting agent reuse as described in claim 1, characterized in that, The instance construction module includes: The template parsing unit is used to parse the node configuration, edge definition, and variable definition in the workflow template to generate a directed acyclic graph structure. An instantiation unit is used to create independent execution instances based on the directed acyclic graph structure and generate globally unique instance identifiers and execution identifiers; The slot configuration unit is used to receive static configuration parameters and persistently store them as slot values ​​of the execution instance.

3. The workflow parameter processing and management system supporting agent reuse as described in claim 1, characterized in that, The agent binding module supports two types of agents: built-in agents and external agents. For built-in agents, the agent binding module loads pre-configured inference and action agent instances from the local agent registry; For external intelligent agents, the intelligent agent binding module obtains the interface definition and parameter mode of the external intelligent agent through the standard protocol interface, and establishes a protocol adaptation layer to perform data format conversion.

4. The workflow parameter processing and management system supporting agent reuse as described in claim 1, characterized in that, The resource loading module includes: The three-layer resource identification unit is used to automatically identify resource candidates from the output data of task nodes, specifically including: The pattern tag recognition layer locates resource fields based on predefined field pattern tags in the output data; The type detection and recognition layer analyzes the format characteristics of field values ​​and identifies Uniform Resource Locators (URLs), Data Uniform Resource Locators (DURLs), or hexadecimal encoding formats. The heuristic recognition layer identifies resource candidates based on keyword matching of field names and statistical features of value formats. The resource conversion unit is used to convert resource candidates of different formats into a unified resource object, wherein the resource object includes resource identifier, file name, media type, file size and access address; The resource storage unit is used to persist the unified resource object to an object storage service or a local file system and generate a time-sensitive access address.

5. A workflow parameter processing and management method supporting agent reuse, applied to the workflow parameter processing and management system supporting agent reuse as described in any one of claims 1-4, characterized in that, Specifically, it includes: Based on the execution status of the execution instance, the replacement data for the slot value of the execution instance is determined. Based on the replacement data, the replacement execution process for different slot values ​​is determined. Based on the replacement execution process for different slot values ​​in different execution instances and the execution data of the execution instance, the matching analysis requirement instance in the execution instance is determined. Based on the queuing delay of different execution instances and the replacement data of the slot values ​​of the matching analysis requirement instance, the update identification scheme for the matching user of the matching analysis requirement instance is determined. The update identification scheme is used to update the matching users of different matching analysis requirement instances. The matching users are used to determine the update matching instances and update deviation instances in the matching analysis requirement instances. Based on the composition of the update matching instances and update deviation instances, when it is determined that the update restriction processing of the matching users needs to be performed, the process proceeds to the next step. By utilizing the update identification scheme of matching users for different matching analysis requirement instances, a monitoring and analysis method for the slot value of the updated matching instance is determined.

6. The workflow parameter processing and management method supporting agent reuse as described in claim 5, characterized in that, The method for determining the matching analysis requirement instance in the execution instance is as follows: The replacement data determines the execution process in which the slot value of the execution instance is replaced during execution, and the execution process in which the replacement occurs is taken as the replacement execution process; Based on the replacement execution process during the execution of the execution instance with different slot values, determine the replacement frequency coefficient of the execution instance with different slot values; Based on the replacement frequency coefficient of different execution instances in different slot values ​​and the execution data, the matching analysis requirement instance in the execution instance is determined.

Images