Task processing methods, devices and products

Abstract

This disclosure provides a task processing method, apparatus, electronic device, storage medium, and computer program product, relating to the field of computer technology, specifically large-scale models, natural language understanding, and intelligent agents, and applicable to task processing scenarios. The specific implementation scheme is as follows: a static graph scheduling system determines the task dependency data of the natural language task; the static graph scheduling system processes the natural language task according to a static flowchart; based on the task dependency data and tool description data of tools in a tool set, a dynamic flowchart representing the processing logic of the natural language task is generated; according to the dependency relationships of operators in the dynamic flowchart, the operators in the dynamic flowchart are executed sequentially, generating operator execution results; combining the execution results of each operator, the task processing result of the natural language task is generated. This disclosure can quickly adapt to new tools and complex tool combinations, improving the flexibility of the task processing process and meeting the needs of different business scenarios.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to the fields of large models, natural language understanding, and intelligent agents, and particularly to a task processing method, apparatus, electronic device, storage medium, and computer program product that can be applied to task processing scenarios. Background Technology

[0002] With the widespread adoption of MCP (Model Context Protocol), the types and number of tools that intelligent systems can call have increased significantly. Existing intelligent agent frameworks, which process natural language tasks using static flowcharts adapted to natural language tasks, cannot meet the dynamic combination and invocation requirements of diverse tools. Summary of the Invention

[0003] This disclosure provides a task processing method, apparatus, electronic device, storage medium, and computer program product.

[0004] According to the first aspect, a task processing method is provided, comprising: determining task dependency data of a natural language task through a static graph scheduling system, wherein the static graph scheduling system is used to process the natural language task according to a static flowchart adapted to the natural language task; generating a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and tool description data of tools in a tool set; executing the operators in the dynamic flowchart sequentially according to the dependency relationships of the operators in the dynamic flowchart, and generating operator execution results; and combining the execution results of each operator to generate the task processing result of the natural language task.

[0005] According to a second aspect, a task processing apparatus is provided, comprising: a data determination unit configured to determine task dependency data of a natural language task through a static graph scheduling system, wherein the static graph scheduling system is used to process the natural language task according to a static flowchart adapted to the natural language task; a graph generation unit configured to generate a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and tool description data of tools in a tool set; an operator execution unit configured to execute operators in the dynamic flowchart sequentially according to the dependencies of operators in the dynamic flowchart, and generate operator execution results; and a result generation unit configured to combine the execution results of each operator to generate a task processing result for the natural language task.

[0006] According to a third aspect, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a method as described in any implementation of the first aspect.

[0007] According to a fourth aspect, a non-transitory computer-readable storage medium is provided that stores computer instructions for causing a computer to perform the method described in any implementation of the first aspect.

[0008] According to a fifth aspect, a computer program product is provided, comprising: a computer program that, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0009] According to the technology disclosed herein, a task processing method and apparatus are provided. The method determines the task dependency data of a natural language task using a static graph scheduling system. The static graph scheduling system processes the natural language task based on a static flowchart adapted to the task. Based on the task dependency data and tool description data of tools in a toolkit, a dynamic flowchart representing the processing logic of the natural language task is generated. Operators in the dynamic flowchart are executed sequentially according to their dependencies, generating operator execution results. The task processing result of the natural language task is generated by combining the execution results of each operator. This integrates a dynamic graph processing framework capable of dynamically generating flowcharts to process natural language tasks into the static graph scheduling system. This allows for rapid adaptation to new tools and complex tool combinations, improving the flexibility of the task processing process and meeting the needs of different business scenarios.

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

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is an exemplary system architecture diagram that can be applied to an embodiment of this disclosure; Figure 2 This is a flowchart of an embodiment of the task processing method according to the present disclosure; Figure 3 This is an execution flowchart based on this embodiment; Figure 4 This is a schematic diagram illustrating an application scenario of the task processing method according to this embodiment; Figure 5 This is a flowchart of yet another embodiment of the task processing method according to the present disclosure; Figure 6 This is a structural diagram of an embodiment of the task processing apparatus according to the present disclosure; Figure 7 This is a schematic diagram of the structure of a computer system suitable for implementing the embodiments of the present disclosure. Detailed Implementation

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

[0013] The technical solutions disclosed herein involve the collection, storage, use, processing, transmission, provision, and disclosure of various types of information, such as user personal information, in accordance with relevant laws and regulations and do not violate public order and good morals.

[0014] Figure 1 An exemplary architecture 100 is shown that can be applied to the task processing methods and apparatus disclosed herein.

[0015] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. The communication connections between terminal devices 101, 102, and 103 form a network topology. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0016] Terminal devices 101, 102, and 103 can be hardware or software that supports network connectivity for data acquisition, interaction, and processing. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices that support network connectivity, information acquisition, interaction, display, and processing functions, including but not limited to smartphones, tablets, e-book readers, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as, for example, multiple software programs or software modules used to provide distributed services, or as a single software program or software module. No specific limitations are imposed here.

[0017] Server 105 can be a server that provides various services. For example, for natural language tasks issued by users through terminal devices 101, 102, and 103, a dynamic graph processing framework that can dynamically generate flowcharts to process natural language tasks is integrated into the static graph scheduling system to process the natural language tasks. As an example, server 105 can be a cloud server.

[0018] It should be noted that a server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (such as software programs or software modules used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0019] It should also be noted that the task processing method provided in the embodiments of this disclosure is generally executed by a server, but the possibility of it being executed by a terminal device, or by a server and a terminal device cooperating with each other, is not excluded. Accordingly, the various parts (e.g., various units) included in the task processing device can be all located in the server, all located in the terminal device, or separately located in the server and the terminal device.

[0020] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Any number of terminal devices, networks, and servers can be included depending on implementation needs. When the electronic devices on which the task processing method runs do not require data transmission with other electronic devices, the system architecture may only include the electronic devices on which the task processing method runs (e.g., servers or terminal devices).

[0021] Please refer to Figure 2 , Figure 2 A flowchart illustrating a task processing method provided in an embodiment of this disclosure. (Continue to refer to...) Figure 3 The diagram illustrates an execution flowchart of a disclosed embodiment. Flowchart 200 includes the following steps: Step 201: Determine the task dependency data for the natural language task through a static graph scheduling system.

[0022] In this embodiment, the execution body of the task processing method (e.g., Figure 1 The server in the process determines the task dependency data of the natural language task through a static graph scheduling system. The static graph scheduling system is used to process the natural language task based on a static flowchart adapted to the task.

[0023] A static graph scheduling system is a task processing framework that pre-defines the task execution flow. Business personnel define fixed flowcharts for each business scenario in advance, such as DAG (Directed Acyclic Graph), which contains fixed nodes, execution order, dependencies, and tool call logic.

[0024] Specifically, the business team maintains multiple sets of fixed static flowcharts in advance, with each static flowchart corresponding to a fixed tool call path. After receiving a user's natural language request (natural language task), the system performs preprocessing such as semantic understanding and operational intervention, and matches and selects a predefined static flowchart according to the natural language task. The system uses the Plan component to arrange the execution order of plugins according to their own Intents. The Plugin component is responsible for selecting static flowcharts and managing multiple static flowcharts. Finally, the Merger component merges the execution results of each node and returns them.

[0025] The specific calling logic, scheduling strategy and core framework code are deeply coupled. Adding or modifying tools requires simultaneous modification of the predefined static flowchart and framework code, making it impossible to flexibly adapt to new tools and new combinations.

[0026] Static graph scheduling systems include, for example, the NewAgent static graph scheduling framework, the MetaGPT static process orchestration mode, the LangChain framework's predefined execution chain mode, and the AutoGPT fixed step execution mode.

[0027] Task dependency data is a set of basic information necessary to complete the current natural language task, obtained by the static graph scheduling system after preprocessing the natural language task through memory acquisition, operational intervention, semantic understanding, and intent recognition. It serves as the basis for generating dynamic flowcharts.

[0028] Task-dependent data includes user intent (such as query, calculation, reservation, analysis, etc.), user identifier / user profile, session history / context information, geolocation, time information, business configuration, operational strategy, key entities (location, date, object, value, etc.), and global common parameters.

[0029] As an example, after receiving a natural language task request submitted by a user, the static graph scheduling system first triggers the built-in preprocessing pipeline: (1) The natural language text is segmented, entity recognized, and intent classified through the semantic parsing module to extract core request elements (such as "Shanghai", "tomorrow", and "weather query" in "query the weather in Shanghai tomorrow"); (2) The memory management module is called to read the associated context data from the user's historical session cache (such as the implicit dependency that "the default city is Shanghai" is added because the user has queried the weather in Shanghai 3 times in the last 3 times); (3) Operational intervention rules are executed to match the preset business strategy (such as "the air quality dimension needs to be added for the weather query"); (4) The above parsing results, context data, and business strategy are integrated into structured task dependency data. The data format is JSON, which contains four core fields: intent, entities, context, and business_rule, to complete the determination of task dependency data.

[0030] As another example, after receiving a natural language task request, the static graph scheduling system first reads related data in batches from the system's multi-source data storage layer through request identifiers (such as user ID (Identity Document) and session ID): (1) Reads user fixed configurations (such as the city of residence and preferred information dimensions) from the user profile database; (2) Reads public dependency data (such as the basic URL (Uuniform Resource Locator) and timeout time of the weather query interface) from the global configuration center; (3) Reads the currently effective operational parameters (such as the temperature unit that the weather query results need to include) from the business parameter table; (4) Performs deduplication, format standardization (converts to key-value pair format), and validity verification (removes expired / invalid data) on the read multi-source data, and finally integrates it into task dependency data containing "user-specific dependencies + global public dependencies + business parameter dependencies" to complete the data determination.

[0031] Step 202: Generate a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and the tool description data of the tools in the tool set.

[0032] In this embodiment, the aforementioned execution entity generates a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and the tool description data of the tools in the tool set through the Planner component.

[0033] A tool is an independent capability unit / service / interface / function that can be invoked by a task processing system to complete a specific sub-function. It serves as the basic execution unit for the system to implement complex tasks. For different business scenarios, tool sets can be pre-defined for specific business scenarios. For example, in a travel service scenario, the tool set might include city location tools, real-time traffic query tools, ride-hailing interface tools, subway / bus route planning tools, parking space query tools, and flight / train ticket booking tools. In an enterprise office scenario, the tool set might include document content retrieval tools, meeting minutes generation tools, schedule reminder tools, email sending / receiving tools, enterprise address book query tools, and to-do list management tools. Tool sets include both local and remote tools.

[0034] As an example, firstly, a pre-defined process generation rule base is loaded, which includes "intent-tool mapping rules," "tool execution order rules," and "dependency verification rules." Then, the intent field in the task dependency data is matched with the intent-tool mapping rules in the rule base to filter out a list of tools suitable for the current task from the tool set (e.g., the intent of "weather query" matches "city location tool" and "weather interface call tool"). Based on the tool execution order rules, the execution logic of the tools is determined (e.g., "city location tool" is executed first, followed by "weather interface call tool"). Through dependency verification rules, the input-output matching between tools is verified (e.g., the input parameter "city code" of "weather interface call tool" can be provided by the output of "city location tool"). According to the DAG structure specification of "node (operator) + edge (dependency relationship)," the filtered tools are encapsulated as operators, and the dependency relationships between operators are defined according to the execution order. Finally, a dynamic flowchart stored in JSON (JavaScript Object Notation) format is generated, which includes three core modules: nodes (operator list), edges (dependencies), and start_node (starting operator).

[0035] As another example, multiple sets of general dynamic flowchart templates are predefined (such as "single tool execution template", "multi-tool serial execution template", and "multi-tool parallel execution template"). Then, the task dependency data is parsed to determine the complexity of the task (whether it can be completed by a single tool or by multiple tools working together); based on the complexity, a basic template is matched from the template library (e.g., "weather query" is a single tool task, so it matches the "single tool execution template"); the tool description data of the adapted tools in the tool set is read, and information such as tool name, input parameters, and output parameters is extracted; the tool description data is filled into the corresponding positions of the basic template (e.g., the information of "weather interface call tool" is filled into the "execution node" field of the template, and the tool input parameters are filled into the "parameter configuration" field); the filled template is syntax-validated (to ensure that the DAG structure has no closed loops and no missing parameters). After the validation is passed, the final dynamic flowchart is generated, and details not covered by the template (such as tool timeout time) are supplemented using system default values.

[0036] In some optional implementations of this embodiment, the execution entity performs step 202 as follows: it generates a dynamic flowchart based on task dependency data and tool description data using a large artificial intelligence model.

[0037] Large-scale artificial intelligence models refer to deep learning models pre-trained on large-scale corpora and data, possessing capabilities such as natural language understanding, logical reasoning, process planning, and structured output. They can automatically plan task execution processes and generate structured flowcharts based on input task and tool information. Examples include large language models and multimodal large-scale models.

[0038] As an example, the task dependency data and tool description data are standardized in format and concatenated into input information that the model can recognize. This information is then input into the large-scale artificial intelligence model. The large-scale artificial intelligence model reasones about the task intent, execution steps, and tool call logic, outputs a dynamic flowchart structure containing operators and dependencies, and performs structured parsing and verification on the output content to obtain a valid dynamic flowchart.

[0039] As another example, the task scenario is determined based on the task dependency data, and tool description data related to the current task is matched from the tool set. The task dependency data and tool description data are used as context input to the AI ​​big model. The AI ​​big model analyzes the dependencies and execution order between tools and automatically generates a dynamic flowchart in the form of a directed acyclic graph.

[0040] In this implementation, a dynamic flowchart is generated through a large artificial intelligence model, which can automatically plan the execution path of the tool without the need for pre-configuration of a fixed process, thereby improving the intelligence of process generation and the ability to adapt to different scenarios.

[0041] In some optional implementations of this embodiment, the execution entity performs the dynamic flowchart generation process in the following manner: by using an artificial intelligence big data model, a dynamic flowchart is generated based on task dependency data, tool description data, and a custom configuration strategy for the dynamic flowchart generation process.

[0042] Custom configuration strategies for the generation process of dynamic flowcharts refer to a set of rules and parameters pre-configured by users or the system to control and constrain the dynamic flowchart generation behavior, thereby improving the accuracy, stability and adaptability of flowchart generation.

[0043] Custom configuration strategies include, but are not limited to: Tool filtering strategies are rules used to filter and select available tools from a tool set, such as selecting only tools of a specified type or excluding unavailable tools.

[0044] Model selection specifies the type or version of the large AI model used to generate the dynamic flowchart.

[0045] Prompt assembly combines task dependency data and tool description data into model input prompts according to a fixed template.

[0046] Retry rules, including the number of retries, retry conditions, and retry intervals when process generation fails or the format is invalid.

[0047] As an example, the large AI model to be used is determined according to the model selection in the custom configuration strategy. The task dependency data and tool description data are combined into model input according to the Prompt assembly rules. The tool set is filtered according to the tool screening strategy, and then the model generation process is carried out. If the generation fails, the process generation is re-initiated according to the retry rules, and finally a dynamic flowchart is obtained.

[0048] As another example, the system reads the custom configuration strategy, preprocesses the tools according to the tool selection strategy in the strategy, loads the corresponding large artificial intelligence model according to the model selection, and constructs the standard input according to the Prompt assembly strategy. The relevant information is input into the model to generate a flowchart. If the flowchart format is invalid or does not meet the constraints, retry is performed according to the retry rules until a valid dynamic flowchart is generated.

[0049] This implementation introduces a custom configuration strategy, supporting custom configuration strategies such as tool filtering, model selection, prompt assembly, and retry control, which improves the stability, accuracy, and configurability of the generated process.

[0050] Step 203: Execute the operators in the dynamic flowchart sequentially according to their dependencies, and generate the operator execution results.

[0051] In this embodiment, the aforementioned execution entity executes the operators in the dynamic flowchart sequentially according to the dependencies between operators in the dynamic flowchart through the Executor component, and generates the operator execution results.

[0052] An operator is the smallest unit of execution in a dynamic flowchart, representing a specific execution action, which can correspond to operations such as tool invocation, large model inference, data processing, and logical judgment.

[0053] In a dynamic flowchart, a dependency relationship is a constraint on the order of execution among multiple operators, indicating that a certain operator can only begin execution after other specified operators have finished. For example, if operator B must be executed after operator A has finished, then B depends on A; if operator C has no preceding operator, then C has no dependency; if operator D depends on both operator B and operator C, then D depends on B and C in parallel.

[0054] As an example, the dependencies in the dynamic flowchart are first parsed to generate a list of operator execution priorities. Then, starting with the initial operator, operators without prerequisite dependencies are executed first (such as the "city positioning tool operator"). The corresponding execution interface of the operator is called, and preset basic parameters are passed in. The execution status of the operator (success / failure / timeout) is monitored. If the current operator executes successfully, its execution result is recorded and the global state is updated. According to the dependencies, the next operator with prerequisite dependencies is executed in sequence (such as the "weather interface call tool operator" which depends on the execution result of the "city positioning tool operator"). The execution result of the prerequisite operator is used as the input parameter of the current operator. The above steps are repeated until all operators are executed. The execution result of each operator is stored in a temporary result set in the format of "operator ID-execution result-execution time", thus completing the generation of operator execution results.

[0055] As another example, the dynamic flowchart is analyzed, dividing operators into "independent operator groups" and "dependent operator groups." Then, for all operators in the independent operator group (e.g., simultaneously executing the "city positioning tool operator" and the "date verification tool operator"), multi-threaded parallel execution is initiated, with each thread independently calling the operator interface. Distributed locks are used to avoid resource conflicts during execution. After all independent operator groups have been executed, their results are compiled and used as input for the dependent operator group. The dependent operator group is executed serially (e.g., the "weather interface call tool operator" depends on the results of the "city positioning tool operator" and the "date verification tool operator"), executing each operator sequentially and recording the results. If a parallel-executed operator fails, a local retry mechanism is triggered (only retrying failed operators). After a successful retry, subsequent operators continue to be executed. Finally, the execution results of all operators are summarized to generate a complete set of operator execution results.

[0056] In some optional implementations of this embodiment, the execution entity performs step 203 as follows: First step, determine the execution method of the operator based on the dependency relationship and type of the operator in the dynamic flowchart; Second step, execute the operator using the execution method and generate the operator execution result.

[0057] The type of the operator is, but is not limited to: Tool operators are operators used to call external tools / interfaces to complete specific functions, such as weather queries, currency conversions, and data queries.

[0058] Inference operators are operators that enable understanding, reasoning, judgment, and analysis through large models, such as intent deepening, parameter completion, and logical judgment.

[0059] Summarizing operators are those that summarize, organize, refine, and output multiple sets of execution results, such as result merging, natural language generation, and format conversion.

[0060] As an example, firstly, the execution timing rules are determined based on the operator dependencies.

[0061] Based on whether the operator has any prerequisite dependencies, the execution time trigger logic is first defined, corresponding to two basic execution methods: If an operator has no prerequisites (no upstream operators that need to be executed first), the execution timing is determined to be an immediate start execution mode. That is, after the flowchart is parsed, computing resources are immediately allocated to the operator, and the execution process is started directly without waiting for other operators. If an operator has a prerequisite (requiring the upstream operator to complete execution and output results), the execution timing is determined to be a dependency-triggered execution mode. A status monitoring thread is started, and the execution process of the operator is only triggered after all prerequisite operators have completed execution and returned valid results.

[0062] Then, based on the type of operator, the core execution logic is further clarified, corresponding to three core execution methods: If the operator is a tool operator, the core execution logic is executed via an external interface call. It connects to the corresponding external tool through a standardized interface protocol, such as HTTP (Hypertext Transfer Protocol), transmits the operator's basic parameters, receives the structured results returned by the tool, and completes the execution.

[0063] If the operator is an inference operator, the core execution logic is a large-scale model inference execution method. The inference requirements (such as intent deepening and parameter completion) are encapsulated as input instructions, which call the preset large-scale artificial intelligence model to obtain the inference results output by the model.

[0064] If the operator is a summary operator, the core execution logic is a multi-result integration execution method. The execution results of all preceding operators are collected, and multiple sets of results are summarized and organized according to the rule of "core information extraction + logical concatenation" to generate a structured summary result.

[0065] Then, the "execution timing rules + core execution logic" are combined into the complete execution method of the operator (for example, the execution method of a dependency-free tool operator is immediate startup + interface call, and the execution method of a dependent inference operator is dependency triggering + model inference), and then executed according to the following process: Prioritize the execution of all operators that start immediately, monitor their execution status in real time, and ensure that there are no abnormal interruptions; for operators that depend on trigger execution, automatically trigger the corresponding core execution logic after their preceding operators have been executed.

[0066] After each operator is executed, the execution result, execution time, and running status (success / failure) are recorded immediately, and the result is written to the global result cache. After all operators are executed, the results in the cache are summarized to generate a complete set of operator execution results.

[0067] In this implementation, the execution method is determined based on dependencies and types, so that different operators are executed with matching execution logic, ensuring that the process runs in an orderly, stable and efficient manner, and improving the rationality of execution.

[0068] In some optional implementations of this embodiment, the execution entity performs the first step described above to determine the execution method of the operator in the following manner: the execution method of the operator is determined based on the operator's dependency relationship, type, and custom configuration strategy for the operator's execution process.

[0069] Custom configuration strategies for the execution process of operators refer to a set of configuration rules pre-set for tool operators, inference operators, and summary operators, used to standardize and control the behavior of the entire operator execution process, and to achieve flexible management and adaptation of the operator execution process.

[0070] Custom configuration strategies for the execution process of operators include, but are not limited to: Configure pre- and post-processing diagrams according to operator type, and configure the pre-processing and post-processing flow or logic for different types of operators respectively; Configure retry strategies according to operator type, and configure the number of retries, intervals and triggering conditions for different types of operators in case of execution failure, timeout and other abnormal situations; Configure the model selector according to the operator type, and configure the large artificial intelligence model used for each operator type that requires model participation, such as inference operator and summarization operator.

[0071] As an example, the dependencies, operator types, and custom configuration strategies for the execution process of the currently pending operator are obtained. The custom configuration strategies are pre-configured with corresponding pre- and post-processing graphs, retry strategies, and model selectors for tool operators, inference operators, and summary operators, respectively.

[0072] Then, the execution sequence is determined based on the operator's dependencies. The pre- and post-processing graphs, retry strategies, and model selectors corresponding to the operator type are matched according to the operator type. Combined with the execution constraints specified in the custom configuration strategy, the complete execution mode of the operator is determined, including the execution sequence, pre-processing, post-processing, exception retry rules, and the model used for inference, thus completing the determination of the operator's execution mode.

[0073] This implementation introduces a custom configuration strategy for the execution process, which supports flexible configuration of processing logic, retry mechanisms and models according to operator type, thereby improving execution controllability and scalability.

[0074] In some optional implementations of this embodiment, the execution entity performs the second step described above and generates the operator execution result in the following manner: First, in response to the operator being a tool-free operator without any preceding dependent operators, the tool parameters of the tool-free operator are determined from the dynamic flowchart; then, the tool corresponding to the tool-free operator is called, the operator execution result is generated based on the tool parameters, and the operator execution result is added to the global context.

[0075] As an example, when the system determines that the current operator is a dependency-free tool operator without any prerequisites based on the operator type and dependency relationship, it first performs field parsing on the dynamic flowchart, extracts and determines all the tool parameters required to execute the tool from the node configuration information corresponding to the operator in the dynamic flowchart, and the tool parameters are the input information necessary to complete the current tool call.

[0076] Subsequently, based on the identifier of the tool-free operator, the corresponding tool pre-registered in the system is matched and invoked. The determined tool parameters are passed into the tool, triggering the tool's business execution logic. The tool then completes the corresponding processing based on the passed tool parameters and returns the execution result.

[0077] Finally, the system uses the execution result returned by the tool as the execution result of the operator that does not depend on the tool, and stores the execution result of the operator in the global context for maintenance and storage, so that other operators can read and use it during the execution process.

[0078] In this implementation, parameters are directly determined and executed for tool operators without prior dependencies, without waiting for other operators, which simplifies the execution process and improves the execution efficiency and response speed of dependency-free tools.

[0079] In some optional implementations of this embodiment, the execution entity performs the second step described above and generates the operator execution result in the following manner: First, in response to the operator being a dependent tool operator with a preceding dependent operator, the tool parameters of the dependent tool operator are determined based on the dynamic flowchart, the operator execution result of the preceding dependent operator, and the tool description data; then, the tool corresponding to the dependent tool operator is called, the operator execution result is generated based on the tool parameters, and the operator execution result is added to the global context.

[0080] As an example, when it is determined that the current operator to be executed is a dependent tool operator with a preceding dependent operator, the parameter definition, parameter source, and parameter format requirements corresponding to the dependent tool operator are first obtained from the dynamic flowchart. At the same time, the execution results of the operators already generated by the preceding dependent operators are read from the global context, and the input parameter specifications recorded in the tool description data corresponding to the tool are combined to parse and verify the parameter source, parameter type, and parameter value, and map the result data output by the preceding dependent operator to the tool parameters required for the execution of the current dependent tool operator.

[0081] After determining the tool parameters, the corresponding tool is called based on the identifier of the dependent tool operator. The determined tool parameters are passed to the tool execution environment, and the tool completes the business processing based on the tool parameters to obtain the corresponding operator execution result.

[0082] Finally, the system adds the result of the operator execution to the global context for saving, so that it can be called and reused by other operators during subsequent execution.

[0083] In this implementation, tool parameters are determined based on dynamic flowcharts, prerequisite results, and tool descriptions, enabling data transfer between tools, supporting multi-tool collaboration, and improving the ability to handle complex tasks.

[0084] In some optional implementations of this embodiment, the execution entity performs the process of generating operator execution results based on tool parameters in the following manner: combining global dependency data and tool-specific dependency data to construct the tool's runtime environment; and generating operator execution results based on tool parameters within the runtime environment.

[0085] Global dependency data refers to common dependency information shared by all tools within the current task and unchanged by tool. It represents the basic environment and common parameters used uniformly by various tools during execution. Examples include global interface domain names, common protocol headers, common authorization information, global timeouts, unified task identifiers, session information, global configuration parameters, and common path information.

[0086] Tool-specific dependency data refers to exclusive dependency information required only by the current tool for its own execution and unrelated to other tools. Different tools operate independently of each other and these dependencies are not interchangeable. Examples include tool-specific interface keys, tool-specific private call addresses, tool-specific configuration items, private parameters, and tool-specific business identifiers.

[0087] As an example, firstly, the global dependency data corresponding to the current tool and the tool's own unique dependency data are obtained. The two types of dependency data are parsed, merged and formatted. Based on the integrated dependency information, an execution environment adapted to the startup and operation of the current tool is constructed, including interface call channels, permission configuration, protocol encapsulation and runtime parameter configuration, etc.

[0088] After the tool runtime environment is built, the determined tool parameters are injected into the runtime environment. Based on the current runtime environment and tool parameters, the tool is driven to execute business logic, complete data processing and interface calls, and finally generate and return the execution result of the current operator.

[0089] In this implementation, global dependencies and tool-specific dependencies are managed in layers, which avoids the problem of accidentally deleting common dependencies when taking the tool offline, thus affecting system stability. The combination of global dependencies and tool-specific dependencies in the runtime environment ensures the normal and stable execution of the tool and improves the reliability of tool calls and environment adaptability.

[0090] In some optional implementations of this embodiment, the execution entity performs the second step described above in the following manner to generate the operator execution result: in response to the operator being an inference operator, the operator execution result is generated through a large artificial intelligence model, and the operator execution result is added to the global context.

[0091] As an example, when the operator to be executed is identified as an inference operator, the inference requirements and related context information corresponding to the inference operator are organized and input into the large-scale artificial intelligence model. The large-scale artificial intelligence model understands, analyzes and infers the input information, and outputs the corresponding inference result as the operator execution result of the operator. Finally, the obtained operator execution result is added to the global context for saving, so that the operator can be read and reused in the future.

[0092] In this implementation, the execution of inference operators is achieved through a large artificial intelligence model, which enriches the types of operator execution and enhances the system's logical reasoning and content generation capabilities.

[0093] Step 204: Combine the execution results of each operator to generate the task processing results for the natural language task.

[0094] In this embodiment, the aforementioned execution entity combines the execution results of each operator with the Generator component to generate the task processing result of the natural language task.

[0095] As an example, firstly, the task result integration rules are loaded, including a "result field mapping table," "data format conversion rules," and "redundant information filtering rules." Then, the operator execution result set is traversed, aligning the result fields of different operators according to the field mapping table (e.g., converting the "city code" of the "city positioning tool operator" to "city name"); according to the data format conversion rules, all results are unified to the output format required by the natural language task (e.g., converting JSON to plain text, and tables to text descriptions); redundant information filtering rules are executed to remove duplicate and invalid result fields (e.g., removing log information from the operator execution process). Finally, the integrated results are concatenated in logical order (e.g., describing the city first, then the weather, and finally the temperature) to generate a clearly structured and complete task processing result.

[0096] As another example, firstly, the business scenario to which the natural language task belongs (such as travel or finance) is identified, and the corresponding result generation template is loaded. Then, the core fields of the scenario are extracted from the operator execution result set (such as "city", "weather", "temperature", and "road conditions" for the travel scenario); the core fields are filled into the specified positions of the scenario template (such as "{city} today's {weather}, temperature {temperature}, {road conditions}" for the travel scenario template); the filled template is polished with natural language (such as adjusting the fluency of sentences and adding scenario-based prompts); if the result contains multiple sets of data (such as querying the weather of multiple cities at the same time), the results are sorted according to the sorting rules of user habits (such as sorting by city pinyin), and finally, a task processing result that conforms to the usage habits of the scenario is generated.

[0097] In some optional implementations of this embodiment, the execution entity performs step 204 as follows: based on the custom configuration strategy for the generation process of task processing results, and combined with the execution results of each operator, the task processing results are generated.

[0098] Custom configuration strategies for the task processing result generation process are pre-configured sets of execution rules used to standardize the entire process of task processing result generation, including but not limited to: Result preprocessing strategies include result concatenation, field filtering, data format conversion, and content anonymization. Post-processing strategies for results include natural language polishing, structured output, segmented display, and supplementary explanatory text. Retry rules include the number of retries, retry conditions, retry intervals, and exception judgment criteria when result generation fails.

[0099] As an example, a custom configuration strategy for generating task processing results is loaded. Based on the pre- and post-processing strategies, the results of each operator are sequentially subjected to pre-processing, including data cleaning, format standardization, and extraction of effective information. The processed results are then integrated, summarized, and structured according to preset rules. If an exception occurs during the integration process, a retry is performed according to the retry rules in the strategy. If the retry is successful or no retry is required, the content is optimized and improved through post-processing to finally generate task processing results that meet business requirements.

[0100] In this implementation, task processing results are generated based on a custom configuration strategy, which can flexibly implement pre- and post-processing of results and retrying of exceptions, improving the standardization, stability and ease of use of output, and adapting to diverse business display needs.

[0101] In this embodiment, based on the existing intelligent agent framework of the static graph scheduling system, a new dynamic_nodes configuration node is added. This node works in coordination with the original nodes of the framework, each performing its own function, to form a complete scheduling graph system, thereby achieving a decoupled design between business-side processing and dynamic tool scheduling.

[0102] The original nodes retain the framework's native business-side processing capabilities and serve as a bypass processing path, responsible for completing the pre-processing of business dependencies for user requests and the post-processing of task results through formatting and encapsulation. The newly added dynamic_nodes nodes serve as the core dynamic scheduling path, carrying all the execution logic of the PEG (Planner-Executor-Generator) three-level architecture, and are specifically designed to complete core operations such as dynamic flowchart generation, operator scheduling and execution, and result streaming processing.

[0103] The `nodes` node is a native configuration node of the framework. It undertakes auxiliary processing functions on the business side in the scheduling system and does not participate in the core dynamic scheduling logic. Its core execution flow and functions are as follows: Pre-processing of business dependencies: After receiving the user's original request, the system sequentially completes operations such as memory context acquisition, operational rule intervention, and semantic parsing of user requests to extract the core information required to generate task dependency data (such as user query, intent, and associated context). The standardized business dependency data is then passed to the dynamic_nodes node to provide basic input for the generation of dynamic flowcharts. Post-result return processing: Receives the task processing results output by the dynamic_nodes nodes, formats and encapsulates the results according to the format specifications and return protocol preset by the business side, and finally returns the results that meet the business requirements to the object to which the natural language task belongs (such as the user request end or the upstream calling system). Link compatibility and adaptation: The original node configuration and execution logic are fully preserved without modifying the framework's native business code, achieving seamless integration of the dynamic scheduling scheme of this invention with the existing framework and reducing system transformation and deployment costs.

[0104] The `dynamic_nodes` node is the core configuration node and the carrier of the PEG three-level architecture. It is specifically responsible for the dynamic scheduling and coordinated execution of tools. Its core execution flow and functions are as follows: Core components: The node is configured with three core components: Planner, Executor, and Generator, as well as a Replan (replanning) fault tolerance component. Each component works together in sequence according to the logic of "generation-execution-result processing-fault tolerance backup" to complete the entire dynamic scheduling process. Dynamic scheduling execution: Receives business dependency data from nodes and sequentially executes core operations such as dynamic flowchart generation, operator scheduling and execution according to dependencies, and streaming processing of execution results. The entire execution logic is controlled through a configuration-based strategy system, without the need to embed business-side code. Data interaction relay: Data transfer between components is completed through the framework's preset _planner_emit, _executor_emit, and _generator_emit interfaces. The unified storage and reuse of operator execution results are achieved through the global Context. Finally, the processed task results are passed to the nodes, which complete the subsequent business response. Flexible configurability and extensibility: Business users can configure Planner, Executor, and Generator components individually or in combination through configuration files. Node configurations can be flexibly adjusted according to actual business needs (simple tool calls / complex multi-tool collaboration) to adapt to diverse tool scheduling scenarios.

[0105] The `dynamic_nodes` and `nodes` nodes complete the processing of the entire natural language task through unidirectional data transfer and hierarchical functional collaboration. The specific interaction chain is as follows: User request initiated → existing nodes receive → preprocessing such as memory acquisition, operational intervention, and semantic parsing is completed → standardized business dependency data is generated → passed to dynamic_nodes nodes; The dynamic_nodes node receives business dependency data → starts the Planner component to generate a dynamic DAG graph → the Executor component executes operators according to dependencies → the Generator component streams the execution results → generates standardized task processing results → passes them to the original nodes; The existing nodes receive the task processing results → complete the business-side formatting and encapsulation → return the results to the task's object, completing the entire processing flow.

[0106] See also Figure 4 , Figure 4 This is a schematic diagram of an application scenario 400 of the task processing method according to this embodiment. User 401 sends the natural language task "How much RMB is 1 million Japanese Yen" to server 403 through terminal device 402. Server 403 preprocesses the user input through a static graph scheduling system, extracts the query statement "How much RMB is 1 million Japanese Yen", and generates task dependency data containing information such as task intent, currency, and amount. The Planner component loads the process planning strategy, inputs the task dependency data and tool description data of the exchange rate query tool and calculation tool into the artificial intelligence big model, and the big model analyzes and generates a dynamic flowchart containing operators and dependencies: the first step calls the exchange rate query tool, with no pre-dependencies; the second step calls the calculation tool, depending on the execution result of the first step. The Executor component executes the dynamic flowchart: first, the exchange rate query tool operator is executed, parameters are extracted and the exchange rate interface is called to obtain the current Japanese Yen to RMB exchange rate; then, based on the exchange rate result, the calculation tool operator is executed to complete the conversion calculation and obtain the corresponding RMB amount, and the execution results of each operator are generated in sequence. The Generator component integrates the exchange rate results with the calculation results to generate the task processing result in natural language form: "1 million Japanese Yen = XX Chinese Yuan (current exchange rate: XX)".

[0107] In this embodiment, a static graph scheduling system is used to determine the task dependency data of the natural language task. The static graph scheduling system is used to process the natural language task according to a static flowchart adapted to the natural language task. Based on the task dependency data and the tool description data of the tools in the tool set, a dynamic flowchart representing the processing logic of the natural language task is generated. According to the dependency relationship of the operators in the dynamic flowchart, the operators in the dynamic flowchart are executed sequentially to generate the operator execution results. The task processing result of the natural language task is generated by combining the execution results of each operator. Thus, a dynamic graph processing framework that can dynamically generate flowcharts to process natural language tasks is integrated into the static graph scheduling system. This can quickly adapt to new tools and complex tool combinations, improve the flexibility of the task processing process, and meet the needs of different business scenarios.

[0108] In some optional implementations of this embodiment, the execution entity may also perform the following operations: format and encapsulate the task processing results on the business side through a static graph scheduling system, and return the encapsulated results to the object to which the natural language task belongs.

[0109] The system obtains the generated task processing results through a static graph scheduling system, and formats and encapsulates the results according to the data format, field structure, and return protocol agreed upon by the business side to form a unified return data packet that conforms to the business interface specification. Then, the encapsulated results are returned to the requesting end or the object that initiated the natural language task through a preset communication interface to complete the result return.

[0110] In this implementation, the business formatting and encapsulation of the results are achieved through a static graph scheduling system, ensuring a unified output format, compatibility with existing business frameworks, reducing system integration costs, and improving the standardization and stability of the returned results.

[0111] In some optional implementations of this embodiment, the execution entity may also perform the following operation: in response to the achievement of a preset retry condition, regenerate a dynamic flowchart representing the processing logic of the natural language task based on task dependency data and tool description data.

[0112] When an abnormality is detected in the current dynamic flowchart execution, operator execution failure, or process interruption, and it is determined that the preset retry conditions are met, the process retry mechanism is triggered; the task dependency data corresponding to the current natural language task is re-acquired, and the tool description data in the corresponding tool set is loaded; based on the above information, the execution path is re-planned, and a dynamic flowchart representing the natural language task processing logic is generated again; and the task processing process is re-executed in accordance with the above implementation methods.

[0113] In this implementation, a dynamic flowchart is regenerated when the retry conditions are met, which can repair and retry abnormal processes, improve the fault tolerance and execution success rate of task processing, and enhance the robustness of the system.

[0114] In some optional implementations of this embodiment, the execution entity may also perform the following operations: in response to the number of retries exceeding a preset threshold and the failure to generate a task processing result, determine a static flowchart adapted to the natural language task from the static flowchart set based on the task dependency data; process the natural language task according to the static flowchart to obtain the task processing result.

[0115] As an example, when it is detected that the number of retries of the dynamic flowchart has exceeded the preset threshold and a valid task processing result has not yet been successfully generated, a downgrade execution mechanism is triggered. Based on the task dependency data corresponding to the current natural language task, a static flowchart suitable for the current task is matched and determined from the pre-configured set of static flowcharts. According to the execution flow and processing logic fixed in the static flowchart, the corresponding task processing steps are executed in sequence, and finally a stable and reliable task processing result is obtained.

[0116] In this implementation, when the dynamic process retry exceeds the limit and fails, it switches to the static flowchart execution to ensure that the task can be completed stably, improve the availability and reliability of the system in extreme scenarios, and avoid the complete failure of the task.

[0117] Continue to refer to Figure 5 The illustration shows a schematic flow 500 of yet another embodiment of the task processing method according to the present disclosure. Flow 500 includes the following steps: Step 501: Determine the task dependency data for the natural language task through a static graph scheduling system.

[0118] Static graph scheduling systems are used to process natural language tasks based on static flowcharts adapted to the natural language task.

[0119] Step 502: Using the large-scale artificial intelligence model, a dynamic flowchart is generated based on task dependency data, tool description data, and a custom configuration strategy for the generation process of the dynamic flowchart.

[0120] Step 503: Determine the execution method of the operator based on the operator's dependency relationship, type, and custom configuration strategy for the operator's execution process in the dynamic flowchart.

[0121] Step 504: Execute the operator using the execution method to generate the operator execution result.

[0122] Step 505: Generate the task processing result based on the custom configuration strategy for the generation process of the task processing result and the execution results of each operator.

[0123] Step 506: The task processing results are formatted and encapsulated on the business side through the static graph scheduling system, and the encapsulated results are returned to the object to which the natural language task belongs.

[0124] The task processing method in this embodiment, in process 500, compared to process 200 above, specifically describes the generation process of the dynamic flowchart, the determination process of the operator execution result, the generation process of the task processing result, and the post-processing process. This improves the recommendation accuracy. It integrates a dynamic graph processing framework that can dynamically generate flowcharts to process natural language tasks into the static graph scheduling system. This framework can quickly adapt to new tools and complex tool combinations, improve the flexibility of the task processing process, and meet the needs of different business scenarios.

[0125] Continue to refer to Figure 6 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a task processing device, which is similar to... Figure 2 Corresponding to the method embodiments shown, the system can be specifically applied to various electronic devices.

[0126] like Figure 6As shown, the task processing device 600 includes: a data determination unit 601, configured to determine the task dependency data of the natural language task through a static graph scheduling system, wherein the static graph scheduling system is used to process the natural language task according to a static flowchart adapted to the natural language task; a graph generation unit 602, configured to generate a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and the tool description data of the tools in the tool set; an operator execution unit 603, configured to execute the operators in the dynamic flowchart sequentially according to the dependency relationship of the operators in the dynamic flowchart, and generate the operator execution results; and a result generation unit 604, configured to combine the execution results of each operator to generate the task processing result of the natural language task.

[0127] In some optional implementations of this embodiment, the graph generation unit 602 is further configured to generate a dynamic flowchart based on task dependency data and tool description data using a large artificial intelligence model.

[0128] In some optional implementations of this embodiment, the graph generation unit 602 is further configured to generate a dynamic flowchart using an artificial intelligence big data model, based on task dependency data, tool description data, and a custom configuration strategy for the generation process of the dynamic flowchart.

[0129] In some optional implementations of this embodiment, the operator execution unit 603 is further configured to: determine the execution method of the operator based on the dependency relationship and type of the operator in the dynamic flowchart; execute the operator using the execution method and generate the operator execution result.

[0130] In some optional implementations of this embodiment, the operator execution unit 603 is further configured to: determine the execution method of the operator based on the operator's dependency, type, and a custom configuration strategy for the operator's execution process.

[0131] In some optional implementations of this embodiment, the operator execution unit 603 is further configured to: in response to the operator being a dependency-free tool operator without any preceding dependencies, determine the tool parameters of the dependency-free tool operator from the dynamic flowchart; call the tool corresponding to the dependency-free tool operator, generate the operator execution result based on the tool parameters, and add the operator execution result to the global context.

[0132] In some optional implementations of this embodiment, the operator execution unit 603 is further configured to: in response to the operator being a dependent tool operator with a preceding dependent operator, determine the tool parameters of the dependent tool operator based on the dynamic flowchart, the operator execution result of the preceding dependent operator, and the tool description data; call the tool corresponding to the dependent tool operator, generate the operator execution result based on the tool parameters, and add the operator execution result to the global context.

[0133] In some optional implementations of this embodiment, the operator execution unit 603 is further configured to: combine global dependency data and tool-specific dependency data to construct the tool's runtime environment; and generate operator execution results based on tool parameters within the runtime environment.

[0134] In some optional implementations of this embodiment, the operator execution unit 603 is further configured to: generate the operator execution result through the artificial intelligence big model in response to the operator being an inference operator, and add the operator execution result to the global context.

[0135] In some optional implementations of this embodiment, the result generation unit 604 is further configured to generate task processing results by combining the execution results of each operator according to a custom configuration strategy for the generation process of task processing results.

[0136] In some optional implementations of this embodiment, the above apparatus further includes: a post-processing unit (not shown in the figure), configured to perform business-side formatting and encapsulation of the task processing results through a static graph scheduling system, and return the encapsulated results to the object to which the natural language task belongs.

[0137] In some optional implementations of this embodiment, the above apparatus further includes: a retry unit (not shown in the figure), configured to regenerate a dynamic flowchart representing the processing logic of the natural language task based on task dependency data and tool description data in response to the achievement of a preset retry condition.

[0138] In some optional implementations of this embodiment, the above-mentioned device further includes: a fallback unit (not shown in the figure), configured to, in response to the number of retries exceeding a preset threshold and the failure to generate a task processing result, determine a static flowchart adapted to the natural language task from a set of static flowcharts based on task dependency data; process the natural language task according to the static flowchart to obtain the task processing result.

[0139] In this embodiment, a task processing device is provided. The data determination unit in the task processing device determines the task dependency data of a natural language task through a static graph scheduling system. The static graph scheduling system is used to process the natural language task according to a static flowchart adapted to the natural language task. The graph generation unit generates a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and the tool description data of the tools in the tool set. The operator execution unit executes the operators in the dynamic flowchart sequentially according to the dependencies between the operators in the dynamic flowchart, generating operator execution results. The result generation unit combines the execution results of each operator to generate the task processing result of the natural language task. Thus, a dynamic graph processing framework capable of dynamically generating flowcharts to process natural language tasks is integrated into the static graph scheduling system. This allows for rapid adaptation to new tools and complex tool combinations, improving the flexibility of the task processing process and meeting the needs of different business scenarios.

[0140] According to embodiments of the present disclosure, the present disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the task processing method described in any of the above embodiments when executed.

[0141] According to embodiments of the present disclosure, the present disclosure also provides a readable storage medium storing computer instructions that enable a computer to perform the task processing method described in any of the above embodiments when executed.

[0142] This disclosure provides a computer program product that, when executed by a processor, can implement the task processing method described in any of the above embodiments.

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

[0144] like Figure 7As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded into random access memory (RAM) 703 from storage unit 708. The RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

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

[0146] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as task processing methods. For example, in some embodiments, the task processing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the task processing method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform task processing methods by any other suitable means (e.g., by means of firmware).

[0147] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

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

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

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

[0151] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0152] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, also known as cloud computing servers or cloud hosts, which are hosting products within the cloud computing service system to address the management difficulties and weak business scalability inherent in traditional physical hosts and Virtual Private Servers (VPS) services; they can also be servers for distributed systems or servers incorporating blockchain technology.

[0153] According to the technical solution of the embodiments of this disclosure, a task processing method and apparatus are provided. The method determines the task dependency data of a natural language task using a static graph scheduling system. The static graph scheduling system processes the natural language task according to a static flowchart adapted to the task. Based on the task dependency data and tool description data of tools in a tool set, a dynamic flowchart representing the processing logic of the natural language task is generated. Operators in the dynamic flowchart are executed sequentially according to their dependencies, generating operator execution results. The task processing result of the natural language task is generated by combining the execution results of each operator. Thus, a dynamic graph processing framework capable of dynamically generating flowcharts to process natural language tasks is integrated into the static graph scheduling system. This allows for rapid adaptation to new tools and complex tool combinations, improving the flexibility of the task processing process and meeting the needs of different business scenarios.

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

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

Claims

1. A task processing method, comprising: The task dependency data of the natural language task is determined by a static graph scheduling system, wherein the static graph scheduling system is used to process the natural language task according to a static flowchart adapted to the natural language task. Based on the task dependency data and the tool description data of the tools in the tool set, a dynamic flowchart representing the processing logic of the natural language task is generated. According to the dependencies of the operators in the dynamic flowchart, the operators in the dynamic flowchart are executed sequentially to generate the operator execution results; The task processing result of the natural language task is generated by combining the execution results of each operator.

2. The method of claim 1, wherein, The step of generating a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and tool description data of the tools in the toolset includes: The dynamic flowchart is generated using a large-scale artificial intelligence model based on the task dependency data and the tool description data.

3. The method of claim 2, wherein, The process of generating the dynamic flowchart using a large-scale artificial intelligence model, based on the task dependency data and the tool description data, includes: The dynamic flowchart is generated using the AI ​​big data model, based on the task dependency data, the tool description data, and a custom configuration strategy for the generation process of the dynamic flowchart.

4. The method of claim 1, wherein, The step of executing the operators in the dynamic flowchart sequentially according to their dependencies and generating the operator execution results includes: Based on the dependencies and types of operators in the dynamic flowchart, the execution method of the operator is determined; The operator is executed using the aforementioned execution method, and the operator execution result is generated.

5. The method of claim 4, wherein, The step of determining the execution mode of the operator based on the dependencies and types of the operators in the dynamic flowchart includes: The execution method of the operator is determined based on the operator's dependencies, type, and custom configuration strategy for the operator's execution process.

6. The method of claim 4, wherein, The step of executing the operator using the aforementioned execution method and generating the operator execution result includes: In response to the operator being a dependency-free tool operator without any preceding dependencies, the tool parameters of the dependency-free tool operator are determined from the dynamic flowchart; The tool corresponding to the dependent tool operator is invoked, the execution result of the operator is generated based on the tool parameters, and the execution result of the operator is added to the global context.

7. The method of claim 4, wherein, The step of executing the operator using the aforementioned execution method and generating the operator execution result includes: In response to the operator being a dependent tool operator with a preceding dependent operator, the tool parameters of the dependent tool operator are determined based on the dynamic flowchart, the operator execution result of the preceding dependent operator, and the tool description data. The tool corresponding to the dependent tool operator is invoked, the execution result of the operator is generated based on the tool parameters, and the execution result of the operator is added to the global context.

8. The method according to claim 6 or 7, wherein, The process of generating the operator execution result based on the tool parameters includes: The runtime environment of the tool is constructed by combining global dependency data and the tool's unique dependency data; In the operating environment, the operator execution result is generated based on the tool parameters.

9. The method according to claim 4, wherein, The step of executing the operator using the aforementioned execution method and generating the operator execution result includes: In response to the operator being an inference operator, the execution result of the operator is generated through the large artificial intelligence model, and the execution result of the operator is added to the global context.

10. The method according to claim 1, wherein, The step of combining the execution results of each of the operators to generate the task processing result of the natural language task includes: The task processing result is generated based on the custom configuration strategy for the generation process of the task processing result and the execution results of each operator.

11. The method according to claim 1, wherein, Also includes: The task processing results are formatted and encapsulated on the business side using a static graph scheduling system, and the encapsulated results are returned to the object to which the natural language task belongs.

12. The method according to any one of claims 1-11, wherein, Also includes: In response to the achievement of preset retry conditions, a dynamic flowchart representing the processing logic of the natural language task is regenerated based on the task dependency data and the tool description data.

13. The method according to claim 12, wherein, Also includes: In response to the number of retries exceeding a preset threshold and the failure to generate the task processing result, a static flowchart adapted to the natural language task is determined from the static flowchart set based on the task dependency data. The natural language task is processed according to the static flowchart to obtain the task processing result.

14. A task processing apparatus, comprising: The data determination unit is configured to determine the task dependency data of the natural language task through a static graph scheduling system, wherein the static graph scheduling system is used to process the natural language task according to a static flowchart adapted to the natural language task. The graph generation unit is configured to generate a dynamic flowchart representing the processing logic of the natural language task based on the task dependency data and the tool description data of the tools in the tool set. The operator execution unit is configured to execute the operators in the dynamic flowchart sequentially according to the dependencies of the operators in the dynamic flowchart, and generate the operator execution result; The result generation unit is configured to combine the execution results of each of the operators to generate the task processing result of the natural language task.

15. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method of any one of claims 1-13.

16. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-13.

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

Images